|
Секция 1 из 2 - Предыдущая - Следующая
From: FAQ Daemon <FAQ.Daemon@f133.n5020.z2.fidonet.org>
Date: Sat, 09 Sep 2000 23:01:06 +0400
Добрый день, уважаемый почитатель языков C и C++!
Перед Вами - сборник часто задаваемых вопросов и ответов к ним
эхоконференции SU.C_CPP. *Пожалуйста*, постарайтесь прочесть этот
список перед тем, как задавать вопросы в конференции, особенно если Вы
подозреваете, что Ваш вопрос из регулярно задаваемых. *Спасибо*!
>>Замечания/дополнения просьба присылать только мылом
>>по адресу 2:5020/133, FAQ Daemon.
*NB*
- В данном письме находится только список вопpосов. Ответы на них
пpиведены в нескольких следующих письмах.
- Данный лист распространяется как freeware и на манипуляции над ним нет
ограничений - трите, конвертируйте, распространяйте дальше, можно даже
отлить скрижали. Единственная просьба: ссылайтесь на авторов при
цитировании.
- За основу данного листа был взят старый FAQ List эхи SU.C_CPP, который
вел Аркадий Белоусов (Arkady V.Belousov, ark@mos.ru).
- GoldEd 3.0.1 имеет режим расцветки по-разному отмеченных строк и стили
выделения, используемые в данном FAQ List.
- Если Вы нашли ошибку или устаревшую информацию и готовы ее исправить,
присылайте, пожалуйста, свой вариант соответствующей статьи. Желательно -
полностью заменяющий оригинал.
- Последние редакции этого FAQ List распространяются в эхоконференции
su.c_cpp на еженедельной основе.
Internet-зеpкало этого FAQ List поддеpживает Igor Krassikov (2:463/59.1).
Оно находится по адpесу http://fido.materials.kiev.ua/cppfaq.html
====
*Содержание* (пометки перед вопросами: * -- изменен/дополнен, + -- добавлен)
+ 000. Какой компилятор C (C++) лучше всех?
001. Что есть stack overflow и как с этим бороться
002. Есть ли в Watcom встроенный ассемблер?
003. Где в Watcom библиотека doscalls.lib?
004. BC не хочет понимать метки во встроенном ассемблере
005. Редактирование исходников и исчезновение глюков в BC++
006. Что значит "Null pointer assignment"
007. Проблемы с запуском программы вне среды в BC++ под Windows
008. Почему инспектор в BC++ ругается на inactive scope
009. Почему не работает виртуальность в конструкторе и деструкторе
010. Что есть NAN
011. Возврат адреса/ссылки локальных переменных
012. Ограничение на имена с подчёркиванием
013. Поведение переменных, описанных в заголовке цикла for
014. Что есть const после имени метода
015. Выключение оптимизации, volatile и longjmp
016. Как получить адрес члена класса
017. Зачем for при живом while
018. Зачем нужен NULL при живом 0
019. Как должен себя вести оператор delete
020. Соответствие конструкторов и деструкторов
021. Как инициализировать статические члены класса
022. Как не ошибиться в размере аллокируемого блока
023. Почему findfirst/findnext выдают не только каталоги, но и файлы?
024. Почему в файле мусор появляется?
025. "Уезжает" экран при выводе в последнюю позицию экрана
026. Как очистить экран?
027. Почему курсор мыши не рисуется?
028. Существует ли TV для других компиляторов и платформ?
029. Освобождается ли память при определении переменной внутри блока?
030. Проблемы с функциями выделения памяти в BC++ 3.1
031. Отличие typedef struct от struct
032. Проверка целостности хипа
033. Работа с массивами более 64K
034. Работа со строками в хипе
035. Доступ к полям структуры из встроенного asm в BC++ 3.1
036. k[++j] = k[j-- - 1] + k[++j]; Как это считается?
037. Перегрузка функции предка, но с другим числом параметров.
038. Как узнать размер функции?
039. Стандарты и иже с ними -- где их взять?
040. Как вызвать метод объекта C++ из ассемблера или из C
/------/
>> 000. Какой компилятор C (C++) лучше всех?
> Q: Что лучше: Watcom C++ или Borland C++?
> Q: Посоветуйте самый крутой компилятор?!
A: (Viktor Ostashev) - 01.08.2000
Смотpя для чего. Если нyжна многоплатфоpменность и хоpошая кодогенеpация,
то лyчше - Ватком. Но следyет yчитывать, что пpоизводство Ваткома пpекpащено
и компилятоp yже не соответствyет в полной меpе стандаpтy C++, и yже никогда
не бyдет соответствовать. А вот для pазpаботки пpиложений под Win32 лyчше
бyдет Borland C++ Builder, хотя качество кодогенеpации y него ниже и
ни о какой многоплатфоpменности говоpить не пpиходится. Что же касается
BC++ 3.1 - это не более, чем yчебный компилятоp, и он yже давно в гpобy.
Не следyет забывать и о gcc, котоpый есть подо все мыслимые платфоpмы и
почти полностью поддеpживает стандаpт, однако он (точнее, его Win32
веpсия - cygwin) не слишком yдобна для создания оконных Win32 пpиложений,
с консольными - все в поpядке, пpичем консольные пpиложения можно создавать
и досовой веpсией - djgpp, дополненной пакетом rsxnt.
А вообще - pассyждать, какой компилятоp лyчше, достаточно бесполезное
занятие. Идеального компилятоpа не сyществyет в пpиpоде. Совеpшенно
негодные компилятоpы не имеют шиpокого pаспpостpанения, а тот десяток
компилятоpов (не считая специфических кpосс-компилятоpов под pазные
встpоенные системы), котоpые имеют шиpокое pаспpостpанение, имеют свои
достоинства и недостатки, так что пpиходится подбиpать компилятоp,
наиболее подходящий для pешения конкpетной задачи.
/------/
>> 001. Что есть stack overflow и как с этим бороться
> Q: Скажите почему возникает stack overflow и как с ним бороться
A: (Vadim Bugrov) - 23.02.97
Причины:
1) велика вложеность функций
2) слишком много локальных переменных (или большие локальные массивы)
3) велика глубина рекурсии (например, по ошибке рекурсия бесконечна)
4) используется call-back от какого-то драйвера (например, мыши)
пп. 1-3 - проверить на наличие ошибок, по возможности сделать массивы
статическими или динамическими вместо локальных, увеличить стек через
_stklen (для BC++), проверять оставшийся стек самостоятельно путем
сравнения _stklen с регистром SP.
п. 4 - в функции, использующей call-back, не проверять стек; в связи с
тем, что он может быть очень мал - организовать свой.
/------/
>> 002. Есть ли в Watcom встроенный ассемблер?
> Q: Любители Ватсона! А че, у него встроенного ассемблера нет что-ли?
> Конструкции типа asm{} не проходят :(
A: (Vlad Bulatov) - 27.12.95
Встроенного asm'a у него на самом деле нет. Есть правда возможность
писать asm-функции через '#pragma aux ...'. Например:
#pragma aux DWordsMover =
"mov esi, eax",
"mov edi, ebx",
"jcxz @@skipDwordsMover",
"rep movsd",
"@@skipDWordsMover:",
parm [ebx] [eax] [ecx] modify [esi edi ecx]
void DWordsMover(void* dst, void* src, size_t sz);
A: (Igor Krassikov) - 04.05.99
Уже есть. В веpсии 11.0 точно имеется asm{}.
/------/
>> 003. Где в Watcom библиотека doscalls.lib?
> Q: При создании 16-bit OS/2 executable Watcom требует либу DOSCALLS.LIB.
> Причем ее нет ни в поставке Ваткома ни в OS/2. Что это за либа и где
> ее можно поиметь?
A: (Sergey Cremez) - 04.02.96
Кличут ее теперь по другому. В каталоге LIB286 и LIB386 есть такая
OS2286.LIB. Это то, что тебе нужно. Обзови ее DOSCALLS.LIB и все.
/------/
>> 004. BC не хочет понимать метки во встроенном ассемблере
> Q: BC не хочет понимать метки в ассемблерной вставке - компилятор сказал,
> что не определена энта самая метка. Пришлось определить метку за
> пределами ASM-блока. Может быть есть более корректное решение?
A: (Michael Yutsis) - 27.12.95
Загляни в исходники RTL от BC++ 3.1 и yвидишь там нечто красивое,
например:
#define I asm
//........
I or si,si
I jz m1
I mov dx,1
m1:
I int 21h
и т.д.
A: (Vadim Gaponov) - 06.01.96
Есть - компилировать с ключом '-B' (via Tasm) aka '#pragma inline'.
Правда, при этом могут возникнуть другие проблемы: если присутствуют имена
read и _read (например), то компилятор в них запутается :).
BTW: Было замечено, что борланд (3.1, например) иногда генерит разный
код в зависимости от ключа -B. Как правило, при его наличии он становится
"осторожнее" - начинает понимать, что не он один использует регистры.
A: (Victor Pomortseff) - 23.02.96
В документации по BC 3.1 я нашёл то место, где описано использование
меток в inline assembler.
Borland C++ version 3.1 Programmer's Guide.
Chapter 12. BASM and inline assembly,
Using jump instructions and labels, p.406.
You can use any of conditional and unconditional jump inctructions, plus
the loop instructions, in inline assembly. They are only valid inside a
function. Since no labels can be defined in the `asm` statements, jump
instruction must use C `goto` labels as the object of the jump. If the
label is too far away, the jump will be automatically converted to a
long-distance jump. Direct far jumps cannot be generated.
In the following code, the jump goes to the C `goto` label "a".
int x(){
a: /* This is the goto label "a" */
...
asm jmp a /* Goes to label "a" */
...
}
Indirect jumps are also allowed. To use an indirect jump, you can use a
register name as the operand of the jump instruction.
/------/
>> 005. Редактирование исходников и исчезновение глюков в BC++
> Q: Прошу прощения, но глюк пропал сам собой! Только что вернул назад
> исходный текст и глюка пропала. Но ведь _была_. Правда я перелопатил
> основательно исходник к тому времени. Похоже действительно дар :)
A: (Arkady Belousov) - 23.02.97
На полном серьёзе - в Борланде это один из главных способов борьбы с
его глюкогенератором. Видимо, там есть какие-то неинициализированные
переменные. Я лично сталкивался с подобными плавающими глюками, когда
после некоторых манипуляций над исходниками в других местах листинг
менялся к лучшему (в смысле баг исчезал).
С другой стороны, я сталкивался с глюком, когда скомпилированная
прога на моей машине при специальном наборе данных работала неправильно,
а на другой машине, или при другом наборе данных, или после неменяющей
результат перестановке операторов или даже вставке отладочного вывода в
проивольном месте глюк исчезал.
Кстати, иногда здесь может быть доля и твоей вины - я однажды забыл в
хедере поставить ; после определения последнего класса, и из-за этого IDE
отваливал, а bcc выдавал GPF. И, поскольку у bcc по меньшей мере видно
последние сообщения, да и GPF обычно не приводит систему в нестабильное
состояние, я практически полностью перешёл на bcc в одном окне Windows, и
thelp в другом.
И последнее. Оптимизатор в Борланде никоим образом нельзя считать
полноценным - гарантированные глюки при компиляции для 386+ и возможные
глюки при прочих опциях. Я это наглядно наблюдал на работоспособности
окна со списком файлов в перекомпилированном TV (тогда использовался TVOS2
Ильфака Гильфанова со всеми применёнными багфиксами).
/------/
>> 006. Что значит "Null pointer assignment"
> Q: А почему при выходе из программы под BC++ 3.1 выскакивает "Null
> pointer assignment"?
A: (Eugene Paderin) - 12.10.96
Это ты попытался что-то записать по нулевому адресу памяти, чего
делать нельзя. Типичные причины:
1) используешь указатель, не инициализировав его. Например:
char *string; gets(string);
2) запрашиваешь указатель у функции, она тебе возвращает NULL в качестве
ошибки, а ты этого не проверяешь. Например:
FILE *f = fopen("gluck", "w"); putc('X', f);
Это сообщение выдаётся только в моделях памяти Tiny, Small, Medium.
Механизм его возникновения такой: в сегменте данных по нулевому адресу
записан борландовский копирайт и его контрольная сумма. После выхода из
main контрольная сумма проверяется и если не совпала - значит нагажено по
нулевому адресу (или рядом) и выдаётся сообщение. Как отловить смотри в
HELPME!.DOC - при отладке в Watch поставить выражения:
*(char*)0,4m
(char*)4
потом трассировать программу и ловить момент, когда значения изменятся.
Первое выражение - контрольная сумма, второе - проверяемая строка.
/------/
>> 007. Проблемы с запуском программы вне среды в BC++ под Windows
> Q: При запуске программы из BC (Ctrl-F9) все работает нормально, а если
> закрыть BC, то программа не запускается. Что делать?
A: (Jouri Mamaev) - 12.10.96
Если используешь BWCC, то эту либу надо грузить самому - просто среда
загружает BWCC сама и делаёт её доступной для программы. Я пользую такой
макрос:
#define _BEST EnableBWCC(TRUE);
EnableCtl3d(TRUE);
EnableCtl3dAutosubclass(TRUE)
Потом в InitMainWindow пишешь:
_BEST;
и все путем. Вообще-то правильнее OWL-евые ексепшены ловить и выдавать
сообщение самостоятельно. Заодно и понятнее будет отчего оно произошло:
int OwlMain(int /*argc*/, char* /*argv*/[]){
int res;
TRY{ res = App().Run(); }
CATCH((xmsg &s) //Какие хочешь ексепшены
{ MessageBox(NULL, "Message", s.c_str()); }
return res;
}
/------/
>> 008. Почему инспектор в BC++ ругается на inactive scope
> Q: Почему иногда пытаешься проинспектировать переменную в BC++ во время
> отладки, а он ругается на inactive scope
A: (Elijah Merkin) - 23.02.97
Вот пример отлаживаемой программы. Компилил так: bcc -v is.cpp
=== Cut ===
#include <iostream.h>
void a(){
int b = 7;
cout << b << endl;
}
void main(){
a();
}
=== Cut ===
Входим в TD. Нажимаем F8, оказываемся на строке с вызовом a().
Пытаемся inspect b. Естественно, не находим ничего. А теперь перемещаем
курсор в окне исходника на строку с cout, но трассировкой в a() не входим
и пробуем посмотреть b. И вот тут-то и получаем inactive scope.
/------/
>> 009. Почему не работает виртуальность в конструкторе и деструкторе
> Q: Я наследовал из абстрактного класса A класс B и определил все
> pure-методы. А она при выполнении ругается, что в конструкторе A по
> прежнему зовётся абстрактный метод? Почему и что делать?
A: (Arkady Belousov) - 06.02.96
Так и должно быть - в C++ конструкторы предков вызываются только до
конструктора потомка, а вызов методов не инициализированного потомка может
окончиться катастрофически (это верно и для деструкторов). Поэтому и была
ограничена виртуальность при прямом или косвенном обращении в конструкторе
(деструкторе) предка к виртуальным методам таким образом, что всегда будут
вызваны методы предка, даже если они переопределены в потомке. (Замечание:
это достижимо подменой VMT).
A: (Arkady Belousov) - 17.08.96
Практически принятое ограничение поначалу сбивает с толку, а проблемы
с TV (созданным в Турбо Паскале, где конструктор сам зовёт нужные методы и
конструкторы предков) доказывают незавершённость схемы конструкторов C++,
в котором из-за автоматического вызова конструкторов подобъектов (предков)
сложно описать конструирование объекта как целого в одном месте, поэтому
конструкторы C++ правильнее называть инициализаторами.
Таким образом, логичнее было бы иметь два шага: автоматический вызов
инициализаторов предков (например, с обнулением указателей) и последующий
автоматический же вызов общего конструктора. И в C++ это реализуемо! Для
этого во всех классах нужно ввести инициализаторы (защищённые конструктор
по умолчанию или конструкторы с фиктивным параметром) и в конструкторах
потомка явно задавать именно их (чтобы подавить вызов конструкторов вместо
инициализаторов предков). Если же код конструкторов выносить в отдельные
[виртуальные] методы, то можно будет вызывать их в конструкторах потомков.
С деструкторами сложнее, поскольку в классе их не может быть более
одного, поэтому можно ввести отдельные методы (типа shutdown и destroy в
TV). Теперь остаётся либо убрать деструкторы (хотя придётся явно вызывать
методы деструкции), либо ввести общий признак, запрещающий деструкторам
предков разрушать, и при переопределении метода деструкции переопределять
также деструктор. И не забывайте делать их виртуальными!
A: (Arkady Belousov) - 17.08.96
//--- В качестве примера можно привести преобразование следующего
//--- фрагмента, содержащего типичную ошибку, в правильный:
class PrintFile{
public:
PrintFile(char name[]) { Печать(GetFileName(name, MyExt())); }
virtual const char *MyExt() { return "xxx"; }
};
class PrintAnotherTypeOfFile :public PrintFile{
public:
PrintAnotherTypeOfFile(char name[]) :PrintFile(name) {}
const char *MyExt() { return "yyy"; }
};
//--- После прообразования получаем следующее:
class PrintFile {
enum Init_ {Init}; // Тип фиктивного параметра
protected:
//... Инициализатор; здесь можно заменить на дефолт конструктор
PrintFile(Init_) {}
//... Можно добавить несколько "конструкторов" с другими именами, или,
//... если "конструкторы" не виртуальные, можно использовать полиморфизм
bool construct(char name[]){
return Печать(GetFileName(name, MyExt()));
}
public:
//... Код вынесен в отдельный метод для использования в потомках
PrintFile(char name[]) { construct(name); }
virtual const char *MyExt() { return "xxx"; }
};
class PrintAnotherTypeOfFile :public PrintFile {
//... Здесь инициализатор пропущен (никто не наследует)
public:
//... Конструктор; использует "конструктор" предка, с виртуальностью;
//... указание инициализатора обязательно
PrintAnotherTypeOfFile(char name[]) :PrintFile(Init) {
construct(name);
}
const char *MyExt() { return "yyy"; }
};
/------/
>> 010. Что есть NAN
> Q: Кто подскажет, что такое NAN.
A: (Eugene Alekhin) - 27.12.95
Это специальное значение вещественного числа, обозначающее НЕ_ЧИСЛО -
Non-a-Number. Имеет характеристикy (смещенный порядок) из всех единиц,
любой знак и любyю мантиссy за исключением .00__00 (такая мантисса
обозначает бесконечность). Имеются даже два типа НЕ_ЧИСЕЛ:
1) SNAN - Signalling NAN (сигнализирyющие не_числа) - старший бит мантиссы=0
2) QNAN - Quiet NAN (тихие не_числа) - старший бит мантиссы = 1.
SNAN никогда не формирyется FPU как резyльтат операции, но может слyжить
аргyментом команд, вызывая при этом слyчай недействительной операции.
QNAN=11__11.100__00 (называется еще "вещественной неопределенностью"),
формирyется FPU при выполнении недействительной операции, делении 0 на 0,
yмножении 0 на бесконечность, извлечении корня FSQRT, вычислении логарифма
FYL2X отрицательного числа, и т.д. при yсловии, что обработчик таких особых
слyчаев замаскирован (регистр CW, бит IM=1). В противном слyчае вызывается
обработчик прерывания (Int 10h) и операнды остаются неизменными.
Остальные НЕ_ЧИСЛА могyт определяться и использоваться программистом для
облегчения отладки (например, обработчик может сохранить для последyющего
анализа состояние задачи в момент возникновения особого слyчая).
/------/
>> 011. Возврат адреса/ссылки локальных переменных
> Q: Почему возвращает фигню:
> char* myview() { char s[SIZE]; ... return s; }
A: () - 27.12.95
Нужно поставить static char s[SIZE]; чтобы возвращался адрес всегда
существующей (статической) переменной, а автоматические переменные исчезают
при выходе из функции - освобождается и может быть замусорено место из-под
этих переменных на стеке.
/------/
>> 012. Ограничение на имена с подчёркиванием
> Q: А я все время наивно полагал, что только *не_рекомендуется*
> использовать имена с подчёркиванием...
A: (Steve Clamage) - 04.02.96
>> That is a bad example, since the name `_BOOL_H_' (like others starting
>> with an underscore and an uppercase letter) is reserved for use by the
>> implementation. You should use plain `BOOL_H' or, if you must,
>Is this defined in the standard (draft), ...
Yes. It is the same rule as in C.
>Does it only apply to macros, or are all identifiers starting with
>underscore and uppercase letter reserved?
All identifiers starting with an underscore and an uppercase letter
are reserved to the implementation for all purposes.
Other categories of identifiers are also reserved in some contexts.
It takes almost a full page in the standard to detail all the rules.
Here are three rules for happy living:
1. Don't use double underscores in your own identifiers.
2. Don't use leading underscores in your own identifiers.
3. Don't use identifiers found in the standard headers (the ones you
include with angle brackets) for any other purpose, ever, and
never define them yourself.
These rules are more restrictive than required by the standard,
but are easier to remember.
A: (Arkady Belousov) - 04.02.96
Пpи использовании заpезеpвиpованных имён (то есть с подчёpкиваниями)
возможен самый pазный undefined behavior. Напpимеp, в компилятоpе все слова
с двойным подчёpкиванием могут использоваться для упpавления файловой
системой. Именно поэтому вполне допустимо (по стандаpту), если Боpландюк в
своём компилятоpе, напpимеp, пpи встpече *НЕСТАНДАРТНОЙ* лексемы __asm из
сорца для VC++ пpосто потpёт какой-нибудь файл. 8^) На пpактике такого pода
ваpиации undefined behavior встpетить сложно, но вполне возможно.
Дpугие ваpиации undefined behavior - это всякие глюки пpи pаботе
пpогpаммы. То есть, если мы, напpимеp, в printf задействуем неизвестный
библиотеке (нестандаpтный) флаг, то по стандаpту вполне допустимо не
пpовеpять в библиотеке подобную фигню и пеpедать упpавление куда-нибудь в
область данных (ну нет в таблице пеpеходов такого флага!).
/------/
>> 013. Поведение переменных, описанных в заголовке цикла for
> Q: Ходют шлюхи, что конструкция
> for(int i=0;i<n;i++){}
> for(i=0;i<n;i++){}
> теперь приведет к ошибке?
A: (Arkady Belousov) - 04.02.96
Да, решено (утверждено), что переменная, объявленная в заголовке цикла
(и прочих операторов!) действительна только внутри этого цикла (и я с ними
согласный!). И если перед процитированными циклами не стоит int i, то да,
процитированный пример должен в новых компилерах привести к ошибке.
Тем, кто хочет заставить вести себя также свои старые компилеры, это
можно сделать следующим способом через define:
//--- Новые редакции C++ область видимости определённой в заголовке
//--- for переменной ограничивают телом цикла. Следующая подстановка
//--- ограничивает область видимости и для старых редакций, в которых
//--- она распространяется за пределы цикла...
#define for if(0);else for
//--- ...а также для BC++ выключим вызываемые if(0) предупреждения
//--- "Condition is always false"
#pragma warn -ccc
/------/
>> 014. Что есть const после имени метода
> Q: const char* GetName() const; - что значит последнее const?
A: (Dima Maloff) - 17.08.96
Это означает, что этот метод не будет менять данные класса.
A: (Akzhan Abdulin) - 27.04.99
Методы с модификатором const могут изменять данные обьекта, помеченные
модификатором mutable.
class Bart
{
private:
mutable int m_iSomething;
public:
void addToSomething( int iValue ) const
{
m_iSomething += iValue;
}
Bart()
{
m_iSomething = 0;
}
};
const Bart bartObject;
bartObject.addToSomething( 8 );
Будет скомпилировано и выполнено.
/------/
>> 015. Выключение оптимизации, volatile и longjmp
> Q: Как выключить оптимизацию и как longjmp может привести к баге без
> этого?
A: (Arkady Belousov) - 17.08.96
Иногда бывает необходимо проверить механизм генерации кода, скорость
работы с какой-нибудь переменной или просто использовать переменную в
параллельных процедурах (например, обработчиках прерываний). Чтобы
компилятор не изничтожал такую переменную и не делал её регистровой
придумали ключевое слово volatile.
A: (Vadim Gaponov) - 17.08.96
longjmp получает переменную типа jmp_buf, в которой setjmp сохраняет
текущий контекст (все регистры), кроме значения переменных. То есть если
между setjmp и longjmp переменная изменится, её значение восстановлено не
будет.
Содержимое переменной типа jmp_buf никто никогда (кроме setjmp) не
модифицирует - компилятор просто не знает про это, потому что все это не
языковое средство. Поэтому при longjmp в отличие от прочих регистровые
переменные вернутся в исходное состояние (и избежать этого нельзя). Также
компилятор обычно не знает, что вызов функции может привести к передаче
управления в пределах данной функции. Поэтому в некоторых случаях он может
не изменить значение переменной (например, полагая ее выходящей из области
использования).
Модификатор volatile в данном случае поможет только тем переменным, к
к которым он применён, поскольку он никак не влияет на оптимизацию работы
с другими переменными...
/------/
>> 016. Как получить адрес члена класса
> Q: Как получить адрес члена класса
A: (Arkady Belousov) - 31.08.96
Эта тема подробно рассматривается в СРуК (ARM) Строуструпа - см.
список страниц в предметном указателе на тему "Указатель на член". Кратко
это выглядит так.
Поскольку указатель на член, в отличие от простого указателя, должен
хранить также и контекстную информацию, поэтому его тип отличается от
прочих указателей и не может быть приведён к void*. Выглядит же он так:
int i; int f();
struct X { int i; int f(); } x, *px = &x;
int *pi = &i; i = *pi;
int (*pf)() = &f; i = (*pf)();
int X::*pxi = &X::i; i = x.*pxi;
int (X::*pxf)() = &X::f; i = (px->*pxf)();
/------/
>> 017. Зачем for при живом while
> Q: Зачем нужен for, если он практически идентичен while?
A: (Arkady Belousov) - 16.10.96
С любезной подачи Anve Netch уточним различие циклов for и while:
- for позволяет иметь локальные переменные с инициализацией;
- continue не "обходит стороной" выражение шага, поэтому
for(int i = 0; i < 10; i++) { ... continue; ... }
не идентично
int i = 0; while(i < 10) { ... continue; ... i++ }.
/------/
>> 018. Зачем нужен NULL при живом 0
> Q: Зачем нужен NULL?
A: (Arkady Belousov) - 16.10.96
Формально стандарты утверждают, что NULL идентичен 0 и для обоих
гарантируется корректное преобразование к типу указателя. Но разница есть
для случая функций с переменным числом аргументов (например, printf) - не
зная типа параметров компилятор не может преобразовать 0 к типу указателя
(а на писюках NULL может быть равным 0L).
С другой стороны, в нынешней редакции стандарта NULL не спасёт в
случае перегрузки (совместного использования, overloading): когда
параметр в одной функции int, а в другой указатель,
при вызове и с 0, и с NULL будет вызвана первая.
/------/
>> 019. Как должен себя вести оператор delete
> Q: Безопасно ли delete NULL? Можно ли применять delete[]var после
> new var[]? А что будет при delete data; delete data?
A: (Arkady Belousov) - 16.10.96
- delete NULL (как и free(NULL)) по стандарту безопасны;
- delete[] после new, как и delete после new[] по стандарту применять
нельзя. Если какие-то реализации допускают это - это их проблемы;
- повторное применение delete к освобождённому (или просто не выделенному
участку) обладает "неопределённым поведением" и может вызвать всё, что
угодно - core dump, сообщение об ошибке, форматирование диска и проч.;
- последняя проблема может проявиться следующим образом:
new data1; delete data1;
new data2;
delete data1; delete data2;
/------/
>> 020. Соответствие конструкторов и деструкторов
> Q: Что за чехарда с конструкторами? Деструкторы явно вызываются чаще...
A: (Arkady Belousov) - 23.02.97
А на это существует неписанное Правило Большой четвёрки (блин, что за
манера - создавать сложности, а потом придумывать пути их обхода): если ты
сам не озаботишься о дефолтном конструкторе, конструкторе копирования,
операторе присваивания и виртуальном деструкторе, то либо Старший Брат
озаботит тебя этим по умолчанию (первые три), либо через указатель будет
дестроиться некорректно (четвёртый).
Я сам так напарывался:
struct String1 { ... char *ptr; ... String1 &operator = (String1&); ... };
struct String2 { ... char array[lala]; ... };
В результате отсутствия оператора присваивания в String2 происходило
_лишнее_ копирование String2::array в дефолтном операторе присваивания,
поскольку String1::operator = и так уже дублировал строку ptr. Пришлось
вставить. (В принципе это было неважно, но влияло на производительность).
Так же часто забывают про конструктор копирования, который вызывается
для передачи по значению и для временных объектов. А ещё есть чехарда
с тем, что считать конструктором копирования или операторами присваивания:
struct C0 { C0 &operator = (C0 &src) { puts("C0="); return *this; } };
struct C1 :C0 { C0 &operator = (C0 &src) { puts("C1="); return *this; } };
int main(){
C1 c1, c2;
c1 = c2;
}
Некоторые считают, что здесь должен быть вызван _дефолтный_ оператор
присваивания `C1::operator=(C1&)' (а не `C1::operator=(C0&)'), который,
собственно, уже вызовет C0::operator=(C0&).
/------/
>> 021. Как инициализировать статические члены класса
> Q: Нужно сделать статические элементы структуры (класса) на C++. Но при
> линковке идёт ругань. К чему бы это?
A: (Natalia Miroshnichenko) - 13.03.97
struct a { static int i; };
int a::i; //нахрена это нужно?
int main() { a::i = 11; return 0; }
А вот зачем (нахрена):
struct b { int n; b(int i) :n(i) {} };
struct a { static b i; };
b a::i(0);
int main() { printf("%in",a::i.n); return 0; }
Описание некоего типа и переменная этого типа - не одно и то же. Где
Вы предлагаете размещать и конструировать статические поля? Может быть, в
каждом файле, который включает заголовок с описанием класса? Или где?
/------/
>> 022. Как не ошибиться в размере аллокируемого блока
> Q: Были у меня две структуры подобные, но вторая длиннее. Сначала в
> функции одна была, я на ней отлаживался, а потом поменял на вторую, да
> только в malloc-е где sizeof(struct ...) старое оставил, и налазили у
> меня данные на следующий кусок хипа.
A: (Arkady Belousov) - 17.08.96
Для избежания подобной баги можно в Си сымитировать Сиплюсный new:
#define tmalloc(type) ((type*)malloc(sizeof(type)))
#define amalloc(type, size) ((type*)malloc(sizeof(type) * (size)))
Более того, в последнем define можно поставить (size) + 1, чтобы
гарантированно избежать проблем с завершающим нулём в строках.
A: (Vadim Gaponov) - 17.08.96
Я делаю иначе. Поскольку присвоение от malloc() как правило делают на
типизованную переменную, то прямо так и пишу:
body = malloc(sizeof(*body));
теперь я спокойно могу менять типы не заботясь о malloc(). Но это верно
для Си, который не ругается на присвоение void* к type* (иначе пришлось бы
кастить поинтер, и компилятор изменения типа просто не пережил бы).
A: (Alexander Krotoff) - 31.08.96
Вообще в C нет смысла ставить преобразования от void* к указательному
типу явно. См ANSI C 3.3.2.3 (Pointers). Более того, этот код не переносим
на C++ - в проекте стандарта C++ нет malloc() и free(), а в компиляторе,
которым я пользуюсь, их нет даже в hosted с++ заголовках. Проще будет:
#ifdef __cplusplus
# define tmalloc(type) (new type)
# define amalloc(type, size) (new type[size])
#else
# define tmalloc(type) malloc(sizeof(type))
# define amalloc(type, size) malloc(sizeof(type) * (size))
#endif
A: (Arkady Belousov) - 07.06.99
Суммируя вышеперечисленное, отмечу следующее. Мой вариант может быть
не переносим на C++ из-за malloc и free. Вариант Гапонова замечателен, но
в C++ ему нельзя поставить альтернативой new, поскольку в new обязательно
задание типа, который из имени стандартно не извлечь. Наконец, вариант
Кротова вновь поднимает исходный вопрос, поскольку опять не типизирован.
Поэтому я считаю, что необходимо скомбинировать все варианты:
Секция 1 из 2 - Предыдущая - Следующая
|
