Comments 42
Тихоходка из любви к искусству присутствует? :)
Другой вариант — включить /Wall. Сообщения будут выданы, но это путь, как вы понимаете, только для отважных.
Без холивара, но в *nix код, собирающийся с -Wall без ругани, считается хорошим тоном. А ядро FreeBSD вообще собирается с -Werror (любое предупреждение = ошибка).
Если бы ещё ядро Линукса собиралось в таком же режиме :-)
Это и в некоторых коммерческих виндузовых приложениях так, если у команды есть время следить за чистотой кода, а не только бегать от релиза к релизу. Плюс, низкоуровневые вещи обычно пишут с -werror
Почему обязательно *nix код, я и в винде при использовании mingw ставлю -Wall -Werror и иногда -Wextra
Лучше решать проблемы по мере их возникновения, а не копить их.
Лучше решать проблемы по мере их возникновения, а не копить их.
Не к вам лично, а вообще: И где же все эти замечательные программы, собираемые разными компиляторами и с разными -Wall? Я где не посмотрю код, г*вно, г*вном. И у меня в общем то тоже код не лучше выходит… :)
P.S. А у Вас есть готовый проект (.vcproj) для разрабатываемого Вами qutIMа? А то я бы прям сейчас попробовал на нем разрабатываемый статический анализатор общего назначения. Посмотрим, как там с -Wall и смогу ли я что-то найти своим изделием. :)
P.S. А у Вас есть готовый проект (.vcproj) для разрабатываемого Вами qutIMа? А то я бы прям сейчас попробовал на нем разрабатываемый статический анализатор общего назначения. Посмотрим, как там с -Wall и смогу ли я что-то найти своим изделием. :)
Готового нету, но можно легко сгенерить при помощи cmake'а, впрочем для студии, к сожалению, все доп варнинги не включены, ибо студийным компилером почти не пользуемся.
Я не уловил перехода от «я всегда ставлю -Wall» до «даже не пытаемся собрать студийным компилятором»…
Оборот, при использовании MinGW, ни о чем не говорит, да? Есть у нас человечек, который студийным компилером собирает и иногда присылает пачку варнингов, но код вообще без предупреждений собирается при помощи gcc и clang (за исключением пары модулей, но там уже проблемы с шаблонами в самом clang'е). За студийный полностью отвечать не могу, мне проще и быстрее собирать при помощи кросскомпилятора. Тем не менее, в результате выходят полностью рабочие бинари. Опять же ввиду отсутствия прекомпиленых либ Qt под W64 и отсутствия же поддержки W64 в MSVS Express Edition я просто физически не имею возможности собирать под W64. Кому интересно, можете конечно заморочится, собрать целиком Qt под W64, потом все зависимые библиотеки, а потом еще подправить cmake скрипты на предмет всяких странных неожиданностей.
-WAll прежде всего от детских и тупых ошибок спасает
жесть, что варнинги привязаны к deprecated ключу — еще один гвоздь в планы перехода на vs2010 до появления первого сервис пака — у нас всяких проблем с переходом просто вагон — vs2003 -> vs2005 мигрировалось просто на ура — ни одного исправления или отваливания фич. vs2008 -> vs2010 просто epic fail.
Где-то Я это уже видел
Не совсем понятно, почему варнинги вообще генериться должны.
Ведь в озвученных примерах приведение типов — явное.
То есть программист так задумал. Ему так надо.
Ведь в озвученных примерах приведение типов — явное.
То есть программист так задумал. Ему так надо.
Тема хорошая, правильная — но глаза зацепили «младшие 4 гигабайта памяти». my ass, младшие четыре гигабайта… (ушел посыпать голову пеплом и вспоминать XMS).
Я не сишник, но разве int не должен быть платформозависимым типом?
A «plain» int object has the natural size suggested by the architecture of the execution environment
Соответственно int должен быть 16битным на 16 разрядной платформе, 32 битным на 32х и 64битным на 64х разрядной платформе соответственно. Почему вдруг в виндовсе решили его оставить 32битным мне непонятно.
Фактически мы имеем лишь такую схему chat<=short<=int<=long<=long long
Соответственно int должен быть 16битным на 16 разрядной платформе, 32 битным на 32х и 64битным на 64х разрядной платформе соответственно. Почему вдруг в виндовсе решили его оставить 32битным мне непонятно.
Фактически мы имеем лишь такую схему chat<=short<=int<=long<=long long
*не int, а long разумеется, который в Unix'е таки стал 64 битным
Ну, насколько я понял из поиска, сделано это для прикрытия задниц криворуких программистов, которые полагали, что размер int заведомо 4 байта, и вместо чего-то такого SizeOf(Integer) — это у меня на Delphi так — писали тупо константу.
Получается, что режим поддержки кривых рук прошит намертво, и только define может помочь?
Получается, что режим поддержки кривых рук прошит намертво, и только define может помочь?
Главное — чтобы был хоть какой-то способ написать исходный код явно так, чтобы предупреждений не было.
Классический способ — приведение через интегральный тип с размером указателя:
void *ptr = x;
int y = (int)(size_t)ptr;
int i = x;
return (void*)(size_t)i;
Классический способ — приведение через интегральный тип с размером указателя:
void *ptr = x;
int y = (int)(size_t)ptr;
int i = x;
return (void*)(size_t)i;
Если очень хочется, то для этого существуют функции вида PtrToInt.
Подробнее см. запись в нашей базе знаний: "Как корректно привести указатель к int в 64-битной программе?".
Подробнее см. запись в нашей базе знаний: "Как корректно привести указатель к int в 64-битной программе?".
Sign up to leave a comment.
Поиск явного приведения указателя к 32-битному типу