Комментарии 109
Спасибо разработчикам компиляторов!
Надеюсь и мои руки когда-нибудь будут расти из нужного места.
Надеюсь и мои руки когда-нибудь будут расти из нужного места.
В очередной раз убедился, что программисты пишут программы совершенно безалаберно. И работают они не благодаря их заслугам, а благодаря удачному стечению обстоятельств и заботе разработчиков компиляторов в Microsoft или Intel
Может не надо всех под одну гребёнку то, а?
Надо, чтобы не было потом sAddr.Format(_T("\\\\%s\\mailslot\\%s"), sTo, (LPCTSTR)m_sName);
Вот когда индусов станет столько, сколько сейчас аккуратных и качественных в каждом байте программистов, тогда и не надо будет.
Вот когда индусов станет столько, сколько сейчас аккуратных и качественных в каждом байте программистов, тогда и не надо будет.
Вообще да, вы правы, но я смотрю как пользователь/начинающий программист на многие проекты и оказывается, что они написаны школьниками/студентами. Ну и как следствие, в таких программах не учтены различные случаи. Так что, индусы размножаются!
Я много слышал, про правильные программы и про правильный код, но ни разу не видел. Я верю (хочу верить), что он есть. Но эти брильянтовые исключения только подтверждают правила.
И как же звучит правило? ) сформулируйте, пожалуйста
Правило. Программисты как правило пишут плохой, безалаберный код.
У автора синдром д`Артаньяна (как писали в соседнем комменте). Подтверждаю как коллега автора, и как обладатель такого же синдрома :-).
Постараюсь развить мысль, чтобы она не была обидна. За время жизни программного проекта в нем рано или поздно получается код, который сложен в поддержке и понимании. В этом никто не виноват (так происходит исторически), но поскольку с кодом кроме программистов никто не работает, то выглядит это как-будто виноваты программисты.
НЛО прилетело и опубликовало эту надпись здесь
Как показывает практика, многие начинающие программисты на C++ работают по принципу: «Eсли программа скомпилировалась и кое-как работает — значит все нормально». Сам всегда под рукой держу книжку Страуструпа.
правое дело делаете! ждём ваших новых статей на эту тему!
и да благославят электроны вашу программу :)
и да благославят электроны вашу программу :)
«И они тихо совершили священный ритуал экзорцизма, изгнав зло из CString» еще сильнее расслабив безолаберных прогеров, а потом плюнули и сделали C#.
Сталкивался с такими ситуациями, что Микрософтовский компилятор хавал такой безобразный код, что потом приходилось ошибки пачками исправлять при переносе программы на Linux. Я очень долго матерился и слал проклятия своему коллеге =D ( Привет Алекс ;) не обижайся тока ).
Как выясняется, не со зла разработчики компиляторов делают, что плохой код работает.
А чего обижаться ) после того как код под mingw перенес сам (первую половину), стал писать аккуратней и перестал доверять компилятору
И не так уж много там ошибок было ) больше связанные с тем что писалось под Win с иным набором инклудов.
PS может тебе просто не нравились классы контейнеры и тд и тп?;)
И не так уж много там ошибок было ) больше связанные с тем что писалось под Win с иным набором инклудов.
PS может тебе просто не нравились классы контейнеры и тд и тп?;)
Возможно, это сознательная попытка хотя бы иногда сделать неработоспособную программу работоспособной.
Самое ужасное — это когда прога «иногда работает».
А вот в С# (и наверное еще где-нибудь) есть просто класс строки. Которому не надо вызывать .c_str(). Который не надо преобразовывать к LPCTSTR. Который нормально грузит строки из ресурсов. Который нормально передаётся в функции форматирования. Который юникодный. Для которого не надо использовать\писать костыли в компиляторах.
Сам писал на С++ почти 15 лет. Но вот сейчас после С# ну просто не могу заставить себя возвращаться ко всем этим граблям и шишкам.
Сам писал на С++ почти 15 лет. Но вот сейчас после С# ну просто не могу заставить себя возвращаться ко всем этим граблям и шишкам.
С# — это что-то типа Java?
Вместо нерасширяемого класса строки лучше сделать простой и однообразный синтаксис и примитивный тип данных. Как в Tcl или Common Lisp, например. Иначе получается такой вот бардак
StringUtil.doSometing(mystring.doSomethingElse());
Вместо
do-something [do-something-else $mystring]
StringUtil.doSometing(mystring.doSomethingElse());
Вместо
do-something [do-something-else $mystring]
или как расширение прототипов в JS
Очевидного бреда или троллинга не вижу. Если у Вас другое мнение — поделитесь с народом, сделайте мир лучше.
Я давно уже с надеждой смотрю в сторону LISPа, глядя на такие ООП-монстры, как C# и Java. Они удобны, надежны, но… очень уж неповоротливы и громоздки. Ведь действительно, зачем писать 10 строк кода, когда при поддержке функционального синтаксиса хватило бы и одной?
А вот в Qt есть просто класс строки. Которому тоже ни хрена вызывать не надо, и уж тем более преобразовывать к LPCTSTR. Который нормально грузит строки из ресурсов. И с форматированием у которого всё в порядке. И который юникодный, разумеется, от самого рождения. И тем не менее, это C++.
Так может не надо угрёбищность микрософтовской реализации строк (CString, LPCSTR, LPCTSTR и пр.) экстраполировать на язык в целом?
Статья автора имеет неверный посыл: разработчики компиляторов решают не проблемы криворуких кодеров, а проблемы криворуких создателей шлака под названием MFC и прочего WinAPI, само существование которых порождает кривой код, рассмотренный в статье.
Так может не надо угрёбищность микрософтовской реализации строк (CString, LPCSTR, LPCTSTR и пр.) экстраполировать на язык в целом?
Статья автора имеет неверный посыл: разработчики компиляторов решают не проблемы криворуких кодеров, а проблемы криворуких создателей шлака под названием MFC и прочего WinAPI, само существование которых порождает кривой код, рассмотренный в статье.
Расскажите тогда, каким образом в нем решена проблема с printf? Интересно просто )
Ну, начнём с того, что для вывода в консоль есть специальный класс, и printf для этой цели лучше не использовать. Да, и форматирование тоже делается «более другими» средствами (хотя с тем же самым синтаксисом), поэтому sprintf тоже не нужен :)
Но если уж сильно надо получить именно const char* и запулить в printf, то сначала QString приводится к QByteArray (преобразовав в нужную кодировку), из которого уже извлекается const char*. Чаще всего выглядит как str.toLocal8Bit().constData();
Но повторю, использование printf (и наличие необходимости делать подобное приведение) чаще всего свидетельствует от том, что программист делает что-то неправильно :)
Но если уж сильно надо получить именно const char* и запулить в printf, то сначала QString приводится к QByteArray (преобразовав в нужную кодировку), из которого уже извлекается const char*. Чаще всего выглядит как str.toLocal8Bit().constData();
Но повторю, использование printf (и наличие необходимости делать подобное приведение) чаще всего свидетельствует от том, что программист делает что-то неправильно :)
D Way. Делать что-то страшное и неправильное можно, но выглядеть код будет таким же страшным и неправильным, каким является.
Если вы пишете кросс-платформенный код и используете студию для компиляции, никаких printf и snprintf в коде быть не должно в принципе, если не хотите огрести по полной.
CRT от Microsoft интерпретирует %s в зависимости от наличия макроса UNICODE. И формат %s у них может означать как char const* (в ansi-режиме), так и wchar_t const* (если UNICODE определено). Аналогично, %S в unicode-режиме означает char const*. В gcc и mingw %s всегда означает char const *.
Некая известная компания сделала это для того, чтобы можно было компилировать сразу и ansi, и unicode-версию программы без ее переписывания, используя костыли _T(). Если вы в студии пишете printf("%s", _T(...)), вы всегда можете быть уверены, что передается строка нужного типа, но если вам нужно передать _именно_ char const*- начинаются танцы с бубном.
В свое время налетели.
CRT от Microsoft интерпретирует %s в зависимости от наличия макроса UNICODE. И формат %s у них может означать как char const* (в ansi-режиме), так и wchar_t const* (если UNICODE определено). Аналогично, %S в unicode-режиме означает char const*. В gcc и mingw %s всегда означает char const *.
Некая известная компания сделала это для того, чтобы можно было компилировать сразу и ansi, и unicode-версию программы без ее переписывания, используя костыли _T(). Если вы в студии пишете printf("%s", _T(...)), вы всегда можете быть уверены, что передается строка нужного типа, но если вам нужно передать _именно_ char const*- начинаются танцы с бубном.
В свое время налетели.
QString sText = tr( L"Строка %1 содержит %2 элементов" ).arg( sString).arg( nItems );
Ссылки на Алексея Пахунова, да и на остальных через ваш линкер — это отвратительно.
Обоснуйте!
Как по мне — так это супер. Когда меняется ссылка на чьем-то сайте, можно просто изменить ее в одном месте и все опять заработает. А иначе все ссылки протухают.
Как по мне — так это супер. Когда меняется ссылка на чьем-то сайте, можно просто изменить ее в одном месте и все опять заработает. А иначе все ссылки протухают.
Инкапсуляция йоптыть =D
Обоснование очень простое: когда я навожу мышь на ссылку я хочу видеть, куда она ведёт. И в этом смысл гиперссылок — ссылаться, которые всякие сокращатели ссылок разрушают.
Ну я думаю всем и так всё понятно, особенно Вам, коллеге топикстартера, что я тут распинаюсь :)
Ну я думаю всем и так всё понятно, особенно Вам, коллеге топикстартера, что я тут распинаюсь :)
Ох уж мне эти шпионские теории…
Вот была раньше ссылка:
www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_AMD64_PortApp.pdf
А месяц назад стала такой:
118.67.120.137/CHCN/assets/content_type/DownloadableAssets/dwamd_AMD64_PortApp.pdf
Но так как у нас везде прописано:
www.viva64.com/go.php?url=61
то статьи не превращаются в помойку битых ссылок, а всегда указывают на корректные документы.
Но это же скучное объяснение, теория загавора намного интереснее, ведь правда?
Вот была раньше ссылка:
www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_AMD64_PortApp.pdf
А месяц назад стала такой:
118.67.120.137/CHCN/assets/content_type/DownloadableAssets/dwamd_AMD64_PortApp.pdf
Но так как у нас везде прописано:
www.viva64.com/go.php?url=61
то статьи не превращаются в помойку битых ссылок, а всегда указывают на корректные документы.
Но это же скучное объяснение, теория загавора намного интереснее, ведь правда?
Да понятен этот аргумент, можно было и не расписывать.
Давайте я тогда ещё пару аргументов добавлю: вы можете посчитать переходы по ссылкам, увеличить цитирование вашего сайта, а также когда-нибудь в будущем перенаправить все ссылки на себя, например, мол, «страница не найдена».
И понятно, что никто из нас не сможет доказать или опровергнуть чистоту ваших намерений. Я свою позицию объяснил, и Вы вроде тоже, так что предлагаю на этом дискуссию закончить.
Давайте я тогда ещё пару аргументов добавлю: вы можете посчитать переходы по ссылкам, увеличить цитирование вашего сайта, а также когда-нибудь в будущем перенаправить все ссылки на себя, например, мол, «страница не найдена».
И понятно, что никто из нас не сможет доказать или опровергнуть чистоту ваших намерений. Я свою позицию объяснил, и Вы вроде тоже, так что предлагаю на этом дискуссию закончить.
а что мешает в случае изменения ссылки менять саму ссылку в статье? или этот такая экстремальная забота о тех, кто читает через веб-архив? х)
1. Одна и та же ссылка может быть как в русской статье, так и в английской.
2. Одна и та же ссылка может быть в нескольких документах.
3. Статьи часто опубликованы в разных местах — соответственно пришлось бы еще и по нескольким сайтам ходить.
Кто может предложить лучший вариант — буду рад обсудить.
2. Одна и та же ссылка может быть в нескольких документах.
3. Статьи часто опубликованы в разных местах — соответственно пришлось бы еще и по нескольким сайтам ходить.
Кто может предложить лучший вариант — буду рад обсудить.
1,2 — роботу пох
3 — не публикуйте статьи в нескольких местах. а если публикуете, то где гарантия, что ваш сайт не переедет и не ляжет?
3 — не публикуйте статьи в нескольких местах. а если публикуете, то где гарантия, что ваш сайт не переедет и не ляжет?
1,2 роботу может и все равно, но мы то для людей, а не для роботов пишем.
3 — не публикуйте в разных местах — мы заинтересованы в том, чтобы статьи читались
4 — где гарантия, что ваш сайт не переедет и не ляжет — наш сайт «переезжает» значительно реже, чем меняются ссылки на других сайтах.
3 — не публикуйте в разных местах — мы заинтересованы в том, чтобы статьи читались
4 — где гарантия, что ваш сайт не переедет и не ляжет — наш сайт «переезжает» значительно реже, чем меняются ссылки на других сайтах.
1,2. роботу, меняющему ссылки в статьях
3. публикуйте ссылки. пользователям всё-равно где читать интересующий их материал
4. статистику в студию
3. публикуйте ссылки. пользователям всё-равно где читать интересующий их материал
4. статистику в студию
Ссылки меняет человек, конечно же. Причем сначала надо найти новую ссылку.
А статистика очень проста. Наш сайт пока не переезжал, а ссылки мы раз в месяц (в среднем) да меняем где-то.
А статистика очень проста. Наш сайт пока не переезжал, а ссылки мы раз в месяц (в среднем) да меняем где-то.
сделайте ему робота, пусть не мучается
а когда ваш сайт переедет, вообще все ссылки сломаются
а когда ваш сайт переедет, вообще все ссылки сломаются
А кто будет следить за их актуальностью?
Я написал пост касательно всех этих обертований. Зачем и почему. habrahabr.ru/company/intel/blog/101957/
Статья, в целом, полезная, но добивает стиль ее изложения. Складывается впечатление, что автор статьи немного повержен синдрому д`Артаньяна. Боюсь его разочаровать, так как среди разработчков компиляторов есть очень много хороших и гениальных людей, которые, наверняка, знали, что они делали.
Например, советую почитать блог Эрика Липперта, который очень часто объясняет, почему и зачем в том или ином месте компилятор ведет себя неадекватным способом. И тогда глупых фраз о криворукости станет намного меньше.
Например, советую почитать блог Эрика Липперта, который очень часто объясняет, почему и зачем в том или ином месте компилятор ведет себя неадекватным способом. И тогда глупых фраз о криворукости станет намного меньше.
А по-моему автор как-раз и говорит, что разработчики компиляторов молодцы. Разве нет?
Он об этом говорит в контексте борьбы с «плохими разработчиками», в то время когда более частая причина несоблюдения спецификаций и прочих «уступок» вызваны желанием сделать код более логичным и понятным — для того, чтобы программист не сидел и не ломал полдня голову, почему лишние скобки или точка в специфическом месте вызвали аномальное поведение. Ни один — даже самый идеальный ЯП и компилятор — не научит всех поголовно писать правильно.
Непонятно, причем тут разработчики компиляторов
Описаное поведение CString — результат хорошей работы головы у разработчиков библиотеки, а не разработчиков компиляторов
«Специальная реализация CString не достаточна, теоретически передача не POD-типа приводит к непредсказуемому поведению». Только теоретически. На практике, для того, чтобы при дизайне, как у CString поведение было непредсказуемым, нужно специально что-то делать. А если ничего не делать и интерпретирвоать экземпляр CString как POD-тип, все работает, как ожидалось.
Можете попробовать скомпилировать класс с похожим дизайном, используя GCC или Comeau — результат будет тот же.
использование 64-биотного регистра для unsigned в релизе вообще имеет целью оптимизацию по скороста, а никак не «делание неработающей программы работающей»
Вот за что реально стоит уважать разработчиков С/С++ компилятора — так это за вещи вроде Code Analysis for C/C++ (http://msdn.microsoft.com/en-us/library/d3bbz7tz.aspx) или 64-bit portability warnings — здесь без поддержки со стороны компилятора мало что можно было бы сделать
Описаное поведение CString — результат хорошей работы головы у разработчиков библиотеки, а не разработчиков компиляторов
«Специальная реализация CString не достаточна, теоретически передача не POD-типа приводит к непредсказуемому поведению». Только теоретически. На практике, для того, чтобы при дизайне, как у CString поведение было непредсказуемым, нужно специально что-то делать. А если ничего не делать и интерпретирвоать экземпляр CString как POD-тип, все работает, как ожидалось.
Можете попробовать скомпилировать класс с похожим дизайном, используя GCC или Comeau — результат будет тот же.
использование 64-биотного регистра для unsigned в релизе вообще имеет целью оптимизацию по скороста, а никак не «делание неработающей программы работающей»
Вот за что реально стоит уважать разработчиков С/С++ компилятора — так это за вещи вроде Code Analysis for C/C++ (http://msdn.microsoft.com/en-us/library/d3bbz7tz.aspx) или 64-bit portability warnings — здесь без поддержки со стороны компилятора мало что можно было бы сделать
>> 64-bit portability warnings — здесь без поддержки со стороны компилятора мало что можно было бы сделать
В поддавки играть не интересно, но и мимо пройти нельзя. Как раз «64-bit portability warnings» в компиляторах-то и не очень. Или может приведете примеры?
В поддавки играть не интересно, но и мимо пройти нельзя. Как раз «64-bit portability warnings» в компиляторах-то и не очень. Или может приведете примеры?
что значит «не очень» и примеры чего вам нужны?
size_t n = 0xFFFFFF;
n = n
size_t n = 0xFFFFFF;
n = n
Правильно ли я понял, что Вы говорите, будто компиляторы легко решают проблемы «64-bit portability warnings». Я говорю, что это не так. Мои слова подтверждает существование анализатора кода PVS-Studio (viva64.com).
Я не утверждаю, что «компиляторы легко решают проблемы «64-bit portability warnings»». Я говорил, что «реально стоит уважать разработчиков С/С++ компилятора — так это за вещи вроде Code Analysis for C/C++ (http://msdn.microsoft.com/en-us/library/d3bbz7tz.aspx) или 64-bit portability warnings »., это немного разные фразы.
То, что есть инструменты, которые анализ кода делают лучше, чем компилятор (ваш анализатор в этом плане далеко не удинственный), я знаю.
Предыдущий комментарий вставился не полностью.
что значит «не очень» и примеры чего вам нужны?
size_t n = 0xFFFFFF;
n = n << 16;
unsigned int i = n;
warning C4267: 'initializing': conversion from 'size_t' to 'unsigned int', possible loss of data
в реальной жизни вместо size_t может быть std::string::size_type, а вместо int — какой-нибдуь свой typedef, что делает обнаружение такого кода «на глаз» пробелматичным.
Аналогично с вещами вроде кастов указателей к int и обратно, которыми изобилует куча legacy кода
void func(int param)
{
MyClass * c = (MyClass *)param;
}
warning C4312: 'type cast': conversion from 'int' to 'MyClass *' of greater size
То, что есть инструменты, которые анализ кода делают лучше, чем компилятор (ваш анализатор в этом плане далеко не удинственный), я знаю.
Предыдущий комментарий вставился не полностью.
что значит «не очень» и примеры чего вам нужны?
size_t n = 0xFFFFFF;
n = n << 16;
unsigned int i = n;
warning C4267: 'initializing': conversion from 'size_t' to 'unsigned int', possible loss of data
в реальной жизни вместо size_t может быть std::string::size_type, а вместо int — какой-нибдуь свой typedef, что делает обнаружение такого кода «на глаз» пробелматичным.
Аналогично с вещами вроде кастов указателей к int и обратно, которыми изобилует куча legacy кода
void func(int param)
{
MyClass * c = (MyClass *)param;
}
warning C4312: 'type cast': conversion from 'int' to 'MyClass *' of greater size
Жесть, а почему не void* param?
(комментарий был пропущен, поэтому и непонимание было, вопрос снимается).
Ну такие «основные» варнинги компилятор просто не может не выдавать, это уж очень близко к ошибкам в программе.
По поводу Code Analysis — фича классная, но к сожалению пока не доведенная до ума. Одно то, что для 64-битной сборки не запускается, уже говорит о недоделанности.
Ну такие «основные» варнинги компилятор просто не может не выдавать, это уж очень близко к ошибкам в программе.
По поводу Code Analysis — фича классная, но к сожалению пока не доведенная до ума. Одно то, что для 64-битной сборки не запускается, уже говорит о недоделанности.
Я бы не сказал, что если фича откючена по маркетинговым соображениям в не-x86 версиях студии, это говорит о ее «недоделанности». Вполне работающая вещь, довольно нетривиалньые баги с ее помощью можнонайти. Не Сoverity конечно, но все же неплохо :)
А в чем маркетинговые соображения? Нам не удалось найти нигде обоснования разумного, почему ее нету. Поэтому кажется, что «просто не сделали».
>> Не Сoverity конечно, но все же неплохо :)
О! А Вы видели Coverity?
>> Не Сoverity конечно, но все же неплохо :)
О! А Вы видели Coverity?
Маркетинговые соображения в том, чтобы заставить всех, кому эта (и еще ряд фич) нужна, купить MS VS TeamSystem x86. а не ее x64 или Itanium версии.
С Itanium все, вроде понятно — подержку прекращают
С x64, видимо, то же самое, потому что, по-видимому, следующих версий студии под 64 бита или не будет, или они будут с сильным опозданием и лучше, чтобы народ на них пока не торопился переходить
blogs.msdn.com/b/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx
С Itanium все, вроде понятно — подержку прекращают
С x64, видимо, то же самое, потому что, по-видимому, следующих версий студии под 64 бита или не будет, или они будут с сильным опозданием и лучше, чтобы народ на них пока не торопился переходить
blogs.msdn.com/b/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx
Про 64-битную версию студии у нас на сайте тоже написано, как раз на основе в том числе и Вашей же ссылки.
Но Ваш ответ что-то странный. То ли Вы не поняли, то ли я не уловил о чем Вы.
Visual Studio Team System всех версий содержит компиляторы под x64 и под Itanium. Сама Visual Studio при этом является в основном x86. А никакой отдельной версии под x64 и Itanium вроде бы нету. Разве не так?
Но Ваш ответ что-то странный. То ли Вы не поняли, то ли я не уловил о чем Вы.
Visual Studio Team System всех версий содержит компиляторы под x64 и под Itanium. Сама Visual Studio при этом является в основном x86. А никакой отдельной версии под x64 и Itanium вроде бы нету. Разве не так?
>> О! А Вы видели Coverity?
Видел. При желании, у них триальную версию не особо сложно получить.
Видел. При желании, у них триальную версию не особо сложно получить.
Существование вирусов под линукс подтверждается ссылкой на антивирус?
Ой, только не надо про «64-bit portability warnings» :). Я уже писал, писал, что это маркетинговая фича и не более, но все равно ее вспоминают.
64 бита, /Wp64, Visual Studio 2008, Viva64 и все, все, все...
Аннотация. Данная статья ставит своей задачей ответить на ряд вопросов, касающихся безопасного переноса Си/Си++ кода на 64-битные системы. Статья написана как ответ на часто обсуждаемую в форумах тематику, связанную с использованием ключа /Wp64 и инструмента Viva64.
А тут и про Code Analysis for C/C++ будет:
Сравнение возможностей PVS-Studio и Visual Studio 2010 по выявлению дефектов в 64-битных программах.
Аннотация. В статье сравниваются три механизма анализа кода с точки зрения выявления 64-битных ошибок: компилятор Visual C++2010, компонент Code Analysis for C/C++ входящий в состав Visual Studio 2010 Premium/Ultimate и анализатор Viva64 входящий в состав PVS-Studio 3.60. Показаны возможности как по выявлению дефектов в 64-битных проектах, так и предварительной диагностики 64-битных ошибок еще в 32-битном проекте.
64 бита, /Wp64, Visual Studio 2008, Viva64 и все, все, все...
Аннотация. Данная статья ставит своей задачей ответить на ряд вопросов, касающихся безопасного переноса Си/Си++ кода на 64-битные системы. Статья написана как ответ на часто обсуждаемую в форумах тематику, связанную с использованием ключа /Wp64 и инструмента Viva64.
А тут и про Code Analysis for C/C++ будет:
Сравнение возможностей PVS-Studio и Visual Studio 2010 по выявлению дефектов в 64-битных программах.
Аннотация. В статье сравниваются три механизма анализа кода с точки зрения выявления 64-битных ошибок: компилятор Visual C++2010, компонент Code Analysis for C/C++ входящий в состав Visual Studio 2010 Premium/Ultimate и анализатор Viva64 входящий в состав PVS-Studio 3.60. Показаны возможности как по выявлению дефектов в 64-битных проектах, так и предварительной диагностики 64-битных ошибок еще в 32-битном проекте.
Люди, ну зачем так топорно пиарить здесь свой продукт, еще и искажая факты? :)
Цитата с сайта «братите внимание, что колонка относящаяся к Code Analysis for C/C++ пуста. Причина в том, что на данный момент Code Analysis for C/C++ не работает с 64-битными проектами.»
Code Analysis for C/C++ не «не работает с 64-битными проектам», (что вообще такое «64-битные проекты»?), его работоспособность зависит только от версии студии — фича Code Analisys есть только в MS VS TeamSystem x86 и прекрасно работает как 32-битными, так и с 64-битными конфигурациями билда, запускается на 32-битных и 64-битных ОС.
Непонятно, для кого на сайте эта красивая «покупайте наших слонов». Неужели вы потенциальных клиентов за идиотов держите?
Цитата с сайта «братите внимание, что колонка относящаяся к Code Analysis for C/C++ пуста. Причина в том, что на данный момент Code Analysis for C/C++ не работает с 64-битными проектами.»
Code Analysis for C/C++ не «не работает с 64-битными проектам», (что вообще такое «64-битные проекты»?), его работоспособность зависит только от версии студии — фича Code Analisys есть только в MS VS TeamSystem x86 и прекрасно работает как 32-битными, так и с 64-битными конфигурациями билда, запускается на 32-битных и 64-битных ОС.
Непонятно, для кого на сайте эта красивая «покупайте наших слонов». Неужели вы потенциальных клиентов за идиотов держите?
Внимательно перечитайте статью. Сравнение с Code Analysis for C/C++ производилось и на 32-битных проектах. И Code Analysis for C/C++ не помог выявить ни одной 64-битной ошибки.
Боле того добавлю, что я сам лично просмотрел все диагностические правила Code Analysis for C/C++ и не увидел относящихся к поиску 64-битных дефектов. Таким образом, Code Analysis for C/C++ никак не помогает в выявлении 64-битных ошибок, что нисколько не умоляет полезность самого Code Analysis for C/C++. Таблица совершенно честна. Если не ясно, какие 64-битные проблемы мы пытаемся ловить, то — habrahabr.ru/blogs/cpp/97751/
Боле того добавлю, что я сам лично просмотрел все диагностические правила Code Analysis for C/C++ и не увидел относящихся к поиску 64-битных дефектов. Таким образом, Code Analysis for C/C++ никак не помогает в выявлении 64-битных ошибок, что нисколько не умоляет полезность самого Code Analysis for C/C++. Таблица совершенно честна. Если не ясно, какие 64-битные проблемы мы пытаемся ловить, то — habrahabr.ru/blogs/cpp/97751/
Я читал статью целиком перед тем, как писать комментарий выше.
Фраза из статьи, которая не соотвествуюет действительности
«на данный момент Code Analysis for C/C++ не работает с 64-битными проектами.»
В статье не написано явно, что такое «64-битные проекты, на которых не работает Code Analysis for C/C++», но из другйо статьи можно понять, что речь идет просто о 64-битной версии студии, где нет поддержки Code Analysis. Т.е. налицо явная подмена понятий, причем довольно топорная.
Ну а насчет того, что с помощью Code Analysis for C/C++ нельзя что-то выявить — вы абсолютно правы. Так же как и спомощью вашего инструмента нельзя выявить ошибки, выявляемые с помощью Code Analysis for C/C++.
«я сам лично просмотрел все диагностические правила Code Analysis for C/C++ и не увидел относящихся к поиску 64-битных дефектов. Таким образом, Code Analysis for C/C++ никак не помогает в выявлении 64-битных ошибок,»
«Опустим обычную газету в серную кислоту, а ТВ-парк в дистилированную воду. Почувствовали разницу? С журналом ничего не произошло!» (с) реклама начала 90х
Зачем вы их между собой сравниваете, если они решают разные задачи?
Я уже молчу про то, сколько ваш инструмент дает false positives в отличие от ворнингов студии :)
Фраза из статьи, которая не соотвествуюет действительности
«на данный момент Code Analysis for C/C++ не работает с 64-битными проектами.»
В статье не написано явно, что такое «64-битные проекты, на которых не работает Code Analysis for C/C++», но из другйо статьи можно понять, что речь идет просто о 64-битной версии студии, где нет поддержки Code Analysis. Т.е. налицо явная подмена понятий, причем довольно топорная.
Ну а насчет того, что с помощью Code Analysis for C/C++ нельзя что-то выявить — вы абсолютно правы. Так же как и спомощью вашего инструмента нельзя выявить ошибки, выявляемые с помощью Code Analysis for C/C++.
«я сам лично просмотрел все диагностические правила Code Analysis for C/C++ и не увидел относящихся к поиску 64-битных дефектов. Таким образом, Code Analysis for C/C++ никак не помогает в выявлении 64-битных ошибок,»
«Опустим обычную газету в серную кислоту, а ТВ-парк в дистилированную воду. Почувствовали разницу? С журналом ничего не произошло!» (с) реклама начала 90х
Зачем вы их между собой сравниваете, если они решают разные задачи?
Я уже молчу про то, сколько ваш инструмент дает false positives в отличие от ворнингов студии :)
Еще раз Code Analysis — не позволяет проверять 64-битне сборки. И все тут. Ну если только это на днях сделали, а я еще не знаю про это. Попробуйте.
Зачем вы их между собой сравниваете, если они решают разные задачи?
Да мы бы и не стали сравнивать, но потенциальные пользователи неоднократно хотели видеть сравнение Viva64 с Code Analysis for C/C++. Вот и «сравнили».
Я уже молчу про то, сколько ваш инструмент дает false positives в отличие от варнингов студии :)
Специфика такая. Ибо не понятно, int это хорошо в данном месте или плохо. А вот статический анализатор общего назначение, который появится в PVS-Studio, будет выдавать мало ложных срабатываний.
Зачем вы их между собой сравниваете, если они решают разные задачи?
Да мы бы и не стали сравнивать, но потенциальные пользователи неоднократно хотели видеть сравнение Viva64 с Code Analysis for C/C++. Вот и «сравнили».
Я уже молчу про то, сколько ваш инструмент дает false positives в отличие от варнингов студии :)
Специфика такая. Ибо не понятно, int это хорошо в данном месте или плохо. А вот статический анализатор общего назначение, который появится в PVS-Studio, будет выдавать мало ложных срабатываний.
MS VS TeamSystem x86 прекрасно работает как 32-битными, так и с 64-битными конфигурациями билда, запускается на 32-битных и 64-битных ОС — ВЕРНО.
Code Analysis for C/C++ анализирует 64-битные билды — НЕВЕРНО. Он выдает D9040. См. Visual Studio Team System, /analyze and D9040.
Code Analysis for C/C++ анализирует 64-битные билды — НЕВЕРНО. Он выдает D9040. См. Visual Studio Team System, /analyze and D9040.
>> Люди, ну зачем так топорно пиарить здесь свой продукт,
Кто бы научил делать это не топорно. Я серьезно.
Кто бы научил делать это не топорно. Я серьезно.
мне одному только вспоминается чудный for-scope у старых MSVC? Именно такие «поблажки» пограммистам и рождают отвратительный, плохо портируемый код.
С каких это пор MS беспокоит портируемость?
Оу, отчётливо помню, как пришлось переносить курсовик из Borland C++ в MSVC (а может, и наоборот, но не в этом суть). Когда увидел количество ошибок, связванных с этим долбаным for-scope, то очень долго перечислял всех родственников разработчиков. В том числе и дальних.
Полностью поддерживаю.
Писаки компиляторов/интерпретаторов помогая программисту очень сильно снижают внимательность программиста, и даже подстёгивает его писать неправильно. Сегодня они помогают нам сделать чтоб программа работала, а завтра программист будет думать «работает значит я всё сделал правильно».
За примерами далеко ходить не надо, 80% OpenSource проектов так или иначе можно встретить на форумах/сайтах в обсуждениях говнокода, а когда тычешь носом автора в ошибку, то чаще всего слышишь только «а у меня всё работает»
Писаки компиляторов/интерпретаторов помогая программисту очень сильно снижают внимательность программиста, и даже подстёгивает его писать неправильно. Сегодня они помогают нам сделать чтоб программа работала, а завтра программист будет думать «работает значит я всё сделал правильно».
За примерами далеко ходить не надо, 80% OpenSource проектов так или иначе можно встретить на форумах/сайтах в обсуждениях говнокода, а когда тычешь носом автора в ошибку, то чаще всего слышишь только «а у меня всё работает»
Золотые слова. Мы вот с неверными представлениями о 64-битности бьемся. Microsoft убедил мир, что в начале достаточно включить /Wp64, ну а чуть позже перекомпилировать проект в 64-битном режиме и получите 64-битную программу. И теперь доносить мысль, что не все так хорошо, очень сложно. А тем более если у кого то что-то «работает».
Разработчики компиляторов, конечно, молодцы, но лучше бы они занимались отловом багов в своих продуктах, чем плюшками для лентяев и неучей. За время работы только на одном проекте компилятор от Visual Studio 2008 порадовал «оптимизацией» цикла путём выбрасывания его тела (дизассемблирование подтвердило), и двумя Internal Compiler Error на совершенно обычных применениях шаблонов.
О соблюдении стандартов я уж и не мечтаю (:
О соблюдении стандартов я уж и не мечтаю (:
Прикольно.
А в Delphi нет таких «танцев с бубнами» для строк. И в отличии от прочих языков, где их нет (all .Net, Java, perl, php, python...) на выходе компилятора нативный код. Которому не надо тащить за собой .Net Framework, JRE, интерпретатор.
Ну да, ну да — забыл — паскаль это же не модно. И вообще там все время надо писать begin-end. Все, все — полез обратно в свое «болото».
А в Delphi нет таких «танцев с бубнами» для строк. И в отличии от прочих языков, где их нет (all .Net, Java, perl, php, python...) на выходе компилятора нативный код. Которому не надо тащить за собой .Net Framework, JRE, интерпретатор.
Ну да, ну да — забыл — паскаль это же не модно. И вообще там все время надо писать begin-end. Все, все — полез обратно в свое «болото».
Скорее всего действительно «просто не модно». Библиотек то меньше, чем на Си/Си++.
Отсутствие интерпретатора в некоторых случаях может стать большой проблемой. Что если вы нашли в компилирующемся двое суток монстрике досадное недоразумение, приводящее к некритической ошибке раз в неделю? Исправлять, перекомпилировать, деплоить новую версию, убивая старую. А тащила бы компилятор/интерпретатор с собой — исправили бы ошибочную функцию в работающей системе.
Вообще-то в статье не упоминалось никаких «танцев с бубнами для строк». В статье описана проблема непроверки типа функции при использовании элипсиса. Просто воды и рекламы столько налито, что все решили что в чем-то виноват толи std:: толи CStrng толи MS (причем два последних виновны в том, что у них никаких проблем в рассматриваемом случае не возникло).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Большой брат помогает тебе