Я за компилятор M$. Он хоть не очень строго следует стандарту, но работает явно лучше, компилирует быстрее, оптимизация лучше (есть ли возможность с gcс использовать Profile-Guided Optimizations). Те отступления от стандарта, которые есть, не ограничивают возможностей компилятора (как в случае с компилятором фирмы borland), а наоборот позволяют больше чем нужно.  
к тому-же оптимизация кода на уровне компоновщика есть только у msvc

не аргумент
вообще абстрактная фраза
без аргументации незачет

примеры в студию
иначе голословно

есть

какая связь между стандартом и оптимизацией?

причем здесь GCC?
в чем конкретно состоит оптимизация кода на уровне компоновщика?
компоновщик, вообще говоря, с кодом не работает и ничего про него не знает
это так, к слову   

Это сообщение отредактировал(а) MAKCim - 11.2.2008, 13:14

Google link-time optimization

ты про это?
но это уже не совсем компоновка

я здесь не об этом, а о том, что msvc не нарушает стандарт так, что-бы что-то не компилировалось.


есть такие вещи как Link-time Code Generation и Whole Program Optimization   


можно попробовать поискать в интернете тесты, я сам одно время пользовался gcc (MinGW) для сборки одного проекта, при переходе на visual studio 8 скорость компиляции заметно возросла, причем даже не "заметно" а на порядок))

Я не только про LLVM (кстати, есть llvm-gcc — порт с фротнэндом gcc и бэкэндом LLVM), LTO умеют ICC, MSVC, возможно ещё какие-то компиляторы.

Тем не менее, принято называть именно так.

Вот здесь недавно обсуждали пример, который может служить иллюстрацией. VS компилирует не правильный код, gcc не компилирует. 

ну допустим
в итоге все равно аргумент Lazin разбит

ну и?
приведи примеры того, как можно нарушить стандарт, добиться успешной компиляции и получить при этом оптимизацию
возможно, примеры есть, но я сходу придумать не могу

вот и поищи
иначе разговор неконструктивен

Добавлено через 4 минуты и 21 секунду

я не понимаю, в чем здесь у MSVC преимущество?

Внесу аргумент в спор: GCC, согласно http://en.wikipedia.org/wiki/GNU_Compiler_...n#Architectures, поддерживает 43 архитектуры официально (ещё 9 штук - неофициально), среди них powerpc (ppc), arm, m86k, alpha, armel, ia64, sparc, mips. 

MSVS поддерживает, согласно http://en.wikipedia.org/wiki/Visual_C_Plus_Plus, помимо ia32, x86_64 и ia64, да и то - со скрипом, подробности, на этой же странице.

Gcc умеет компилить как минимум под: GNU/Linux, *BSD, Windows(mingw, частично), mac.
MSVS - только линейка windows.

Вывод: MSVS - нерасширяемое [censored33! Пожалуйста, соблюдайте элементарные правила приличия при общении на форуме].

Размер откомпиленного файла.
У gcc больше раза в 4.

Пример: KDE4(версия для винды).

Какого именно и как скомпилированного?  

присоединяюсь к вопросу 
nickless, 

118 против 293
KDE4 для винды. набор пакетов


Для примера:
kdebase-mingw-3.97.20071231-bin.tar.bz2 85.7мб
kdebase-msvc-3.97.20071231-bin.tar.bz2 37.3мб

MinGW, который при установки Qt скачивается и ставится, уж абсолютно точно сливает полностью MSVC 2005: собирает Qt дольше раза в 2-3, и размер скомпиленного почти в три раза больше.

По скорости компиляции ИМХО гцц проигрывает, но msvc давное не видел - фиг его как там у него щас 

По "платформенности". Вообщем, msvc де-факто стандартный компилер для винды, гцц для всего остального (ну... почти мб).


Просто MS не заинтересованы в vc для не-винды. А так, возможно ли это (всмысле насколько просто) - мы не можем судить 


  

ЗЫ интел рулит  

например можно не всегда писать typename и компилятор проглотит (при этом выдаст предупреждение, что использовано нестандартное расширение), или вложенный шаблон
вместо
Foo::template bar<>....
можно просто написать
Foo::bar<>....

где Foo это какой-то класс а bar вложенный в него шаблонный класс...

ps
это наверное не есть хорошо   

Ну... Это расширение, а не отступление от стандарта  В гцц тоже полно расширений.

После того как Qt-OSE стала без каких-либо хаков доступна для MSVC я стал больше склоняться именно к MSVC... Наверное не потому что "быстрее, лучше и т.п.", а потому что она говтовенька: только установи - и тебе редактор с хорошей подсветкой(VAssist) и отладчик и профилировщик и чё только хош... Это я в том плане, что MSVC хороша как IDE. Как tool-chain, боюсь, что она проиграет GNU-шному почти по всем аспектам, но... мне лишний такт процессора не жалко .

Просто, когда я пользовался GCC, я почти забыл что такое JIT отладка, что такое code-comlete, class-view и проч. вкусности только лишь потому, что не нашёл нормальной IDE под этот тулчайн. Всё какое-то "недо"рабочее, всё, что сложнее хэловорлда не работает и т.д.
Я так скажу: GCC хорош при разработке под *nix... MSVC - под виндой.

да

Скучный у вас холивар   

Подбрось дровишек 

компоновщик MSVC умеет создавать нативные бинарные файлы вне формата PE?

нет  пролистни предыдущую страницу, у меня этот аргумент уже был 

А что тогда? Учитывая что кроме Win/WinCE ему ничо не надо?

Добавлено через 11 минут и 16 секунд

JIT-отладка - эт когда приложение крашнулось и ты его отлаживаешь?  Или я не в теме?

Всё остальное _названное_ - меня отлично эклипс устраивает. Из минусов навскидку (не вообще - а по сравнению с MSVC) - родная его билд-система (для небольших ведь проектов, согласитесь, удобней при юзание ИДЕ юзать родную билд-систему) недоделанная. По сравнению с VC++ 2005 и *.rule-файлами. Комплит есть, оутлайн есть. Проч. - о чём речь? Кстати, если интересно - прочитай ревью CDT 5.0 (к лету обещают). Мне так оч понравилось 


Вообще, если посмотреть как развивается MSVS (как ИДЕ) для шарпа/вб или плюсов... Хочется сказать, что именно MSVC (как иде) застряла...

Профайлеры... С меня valgrind хватает. Особо критичным чем-то в этом плане просто не занимался 

Оптимизация... Фиг его. Меня мало волнует 

Скорость сборки - если честно, не нравится больше всего. Можно потестить что-нить на базе boost::spirit, boost::lambda и пр., что _должно_ собираться подольше  Я считаю, что msvc выиграет. Прилично причём. Но... конкретику немного интересно было бы увидеть 


А эт чо-т не понял... О чём речь?

слив по функционалу

JIT расшифровывается just in time... Эт когда можно бряк поставить, step-in/over/out сделать, run to cursor, watch и т.д. - т.к. gdb постоянно зависал и падал мне пришлось перейти к отладке в виде анализа логов.


Комплит не работает, аутлайн не работает(в большом кол-ве случаев).


valgrind - это вроде memory-leeks отлавливать? Ну, даже если это профайлер - не суть важно, ибо ты не заметил ключевую фразу в моём посте: она готовенькая - установи и работай.


Ну, как набор компилятор + компоновщик + ... + система сборки(вместе называемое тулчайном - термин из того же эклипса ) MSVC выйграет разве что в скорости сборки.

До кучи, edit-and-continue (/ZI) очень удобная вещь, не нужно сто раз перекомпилировать код, почти всё можно отредактировать не выходя из отладчика.

и не только.


эээ... ну вот valgrind установил и тоже работаю. Разница?

Понятно. Давным-давно глюки были. Сейчас вроде проблем нет. Правда речь про никсовый гдб (и экипсовый форнтенд). За виндовый  не ручаюсь 


Работает. Всегда. Обещают развивать (новые возможности комплита - вроде инклюд-заголовков, улучшение сканера и пр.).


Нет - это много чего: http://valgrind.org/info/tools.html


Готовенький профайлер в студии вроде только в тим-эдишн и то какой-то слабенький. Всё равно что-то стороннее юзать. Или я что-то упустил?


Компилятор - ну собсно его в первую очередь, наверно, обсуждаем.

Компоновщик - во вторую ))

Система сборки - чем так nmake, vcbuild не угодили? Я бы не сказал (да простят меня...) что GNU Make радикально лучше. Юзаю waf преимущественно.  Иногда qmake, иногда Eclipse MBS.


А в чём проиграет?  Если учитывать, что ему плевать на "невинду".


Ну... Не стоит преувеличивать... Но да - удобно. Факт. А в гцц точно ничо такого нет?

Добавлено через 27 секунд

  

1. Найти.
2. Установить.
3. Разобраться как, в каком порядке и с какими аргументами запускать и т.д.

                        vs

Тыкнул в менюшку и профилирую на здоровье. Правда, как заметил Любитель, только тим... хотя, возможно, что есть в про.


Жму ctrl+space - в 90% случаев не получаю ничего, в 5% - получаю не то, что нужно, в оставшихся 5% - да, работает. Мне казалось, что в целом эта картина называется "не работает"  




В функционале, широте применения и т.д.
Как кто-то когда-то сказал: "линукс - это IDE для GCC"... комментарии излишни.

p.s. Я чё т не врублюсь, Любитель, ты на какой стороне? Или ты по совету Джекифа решил дровишек подбросить? 

Добавлено через 1 минуту и 46 секунд

Она разве для цпп работает?

Ещё с 6-ой студии  Для шарпа AFAIK с 2005-ой (я про эдит энд континуе).


Ну, честно сказать, сколько видел автокомплитов дял плюсов - идеального ничего не видел (по сравнению с ява + эклипс или шарп + VS). Но эклипсовский автокомплит студийному явно не проигрывает... Можно, конечно, заняться конкретными примерами, но стоит ли?  Тем более, как я говорил выше - эклипс развивается. Студия (для плюсов) не особо...


В широте применения - да, безусловно. Но токалько MS широта нафиг не нужна. В функционале - можно точней?


А фиг его знает ))) Если говорить про ИДЕ - я выбираю эклипс. Уже сейчас он даёт некторые вещи, отсутствующие в студии и он перспективней (в плане плюсов). Эклипс AFAIK поддерживает msvc как компилер - но без дебага (что есть огромнейший минус...). Как компилер - тут интересней. Если не винда - сомнений нет. Винда - я больше склоняюсь к msvc, ибо он (a) быстрей собирает и (b) "родной" (меньше тупых проблем с бинарной несовместимостью с готовыми либами и пр.). Но он не интегрируется нормально в эклипс. Потому ещё один вариант - icc  Если у него с эклипс-дебагом нормально под виндой - то это почти мой выбор. Почему почти? Цена хотя б  Да и некоторые вещи напротив (портированные с никсов) собираются только под МинГВ, а не msvc. Вот.

PS А вообще я за справедливость!!!


Ну и эт тоже   

Посмотри в сторону VisualAssistX - комплит как у шарпа(это помимо того, что он разукрашивает код, лучше чем в шарпе... правда шарп он тоже разукрашивает неплохо).


Эмм... Я тебе навскидку не скажу, но точно помню, что были вещи, которые в *nix делались лёгким движением руки, тогда как в винде это либо сделать невозможно, либо нужно много напрягаться.



Не, так не интересно...  

Когда-т давно видел. Во времена 6-ой студии... Что сейчас - фиг его. Будет винда/студия/VA - мож и гляну 


Эт почему? А зачем же тогда холивары нужны?  Кстати - в голосовалке я не отметился.

что мне никогда не нравилось в эклипсе (раз уж начали про IDE), так это то, что CDT толком не работает, отладчик MinGW - gdb постоянно падает, короче одним словом, это все не работает "из коробки" как VS, мне не танцами с бубном нужно заниматься а работой, поэтому я выбираю не Open Source ПО, а ПО которое работает   

кстати на Windows 2003 Server у меня при попытке запустить отладчик, еклипс страшно ругался, не помню на что, в общем, там вообще ничего не работало, а допиливать напильником фанатизма не хватило... так-то   



Это сообщение отредактировал(а) Lazin - 6.4.2008, 22:20

ИМХО - это скорей претензии к виндовому порту гдб, чем к цдт. Насчёт остального "из коробки" - уже вроде обсудили 

Ну насчёт этого - я никакой разницы между w2k3 и wxp не заметил - работало в обоих случаях одинаково плохо  

Так. Вопрос такой виндовый гдб  без эклипса нормально пашет?

Не знаю, у меня на mingw (code::blocks) в своё время нареканий не было 

Надо потестить...

Нажимаю F11 и


Добавлено через 4 минуты и 10 секунд
меня одного раздражают эти непонятные банеры?

иногда мне кажется что M$VS умнее меня :'(
я еще функцию не закончил писать, а она уже за меня все решила =)

функции с таким именем у меня в проекте небыло...

Кину камень в сторону еклипсы, эдитор (сам эдитор) там - хуже чем отстой, по фичам находится на уровне notepad-а, разве что код форматировать помогает, а так... 
Хачу vim в еклипсе  

для студии есть addon добавляющий режимы vi но он платный.
и работает она не в зуб ногой... очень неудобно, когда у тебя выскакивает окошко inteliscense ты нажимаешь esc и тебя выбрасывает в нормальный режим опыт показывает что без него лучше чем с ним =)

nickless, а что _именно_ ты хочешь от эдитора?
Мож я идиот - но привык к стандарт-стайл эдиторам...

и я, и я. Я вообще был бы не против vim'а в чём-нибудь. Но эти студии доиграются  . В конце концов я на виме буду вообще всё писать и мне станет пофиг 

Добавлено через 16 секунд

vim он хочет. И я его понимаю 

Клуб фанатов вима . А есть где-нибудь руководство "vim для чайников"? А то вижу как у вас глаза горят при упоминании этого наименования и аж завидно .

Как минимум макросы. Во всех нормальных (если кто не знает, в мире их всего 2  ) эдиторах они есть и здорово ускоряют процесс. Они есть даже в VS и BDS, а в eclipse уже 2 (!) года висит баг с просьбой добавить хотя бы простые макросы, и ни какого прогресса  

Еще я хочу удобства, простые программисткие удобства. В vim-e они есть, он для этого сделан, после привыкания к нему отвыкать ужасно не хочется. Возможно это звучит странно для тех, кто привык к более убогим эдиторам, но это так. Точно такое же чувство у меня возникает, когда после долгого использования линукса запускаю винду, или bash после zsh, но это уже флейм

Что я понимаю под удобствами, в эклипсе конечно есть подсветка, интеллисенс, форматирование кода, парочка удобных шорткатов итд, но этого мало, я хочу иметь возможность с наименьшими усилиями отформатировать выделенный участок кода, в том числе и комментарии. Почему я должен выравнивать большие блоки комментариев по ширине вручную? Почему нельзя нормально соединить две строки?

В vim-е любая операция по удалению копирует удалённый текст, и его можно вставить в другом месте. Это удобно! Не нужно специально копировать или вырезать его, он всегда там.

Где в этом эдиторе блок-модус? Как переходить не только между {}, () и методами, но и между /* */? Как удалять текст в () {} [] /* */ "" ? Этот список можно продолжать бесконечно.
И это я еще и 10% возможностей вима не знаю  


Vim используют не (только) потому что он модальный, а потому, что он функциональный.


Что я по большей части и делаю  

Да, забыл, нафига еклипс постоянно меняет порядок не видимых в данный момент табов? Ну не влазят у меня на экране 6 табов, между 5 я могу переключится по Ctrl+PageDown/PageUp, а для остальных двух вылазит список, там надо до них стрелочками добираться... Бесит... 

Добавлено через 1 минуту и 3 секунды

Запусти в консоли vimtutor

Добавлено через 8 минут и 5 секунд
А, вот еще вспомнил must have фичу  Как там можно вставить в текст вывод любой шелл команды?  

для еклипса AFAIK есть плагин(платный) добавляющий режимы vi, но я его в глаза не видел, слышал только (что есть)...
для студии аналогичный плагин - полный трэш, неделю на нем еле протянул =)
и кстати, зачем вообще ide в linux-e?

 чтобы удобнее было. Например  рефакторинговые подсказки или умное дополнение кода ;)

Всмысле встроенный скриптовый язык? Или запись действий (потыкал кнопки - хочу повторить). Кстати, вот что-т нашёл - https://macroshmacro.dev.java.net/



Вот к zsh привык быстро. А удобства вима - хоть убейте, не оценил....


Потому что ещё не сделали встроенной возможности )))


Ну... Не сказал бы, что это плюс. Удалить - это удалть! И не надо поганить мне буфер.

ЗЫ Мы ушли от темы 

У тебя буферов в vim'е 10 штук минимум. Предыдущий при этом не затирается. Так что мимо 

Добавлено через 21 секунду

Нет, ну личное дело каждого 

Всё равно. Удалить - это удалить! Мне это текст - аюсолютно не нужен. Зачем его оставлять?! Cut - на то и cut, а delete - на то и delete  

Добавлено через 3 минуты и 27 секунд
vim мне не нравиться именно в палне "модальности" (или как это там?). Скрипты, команды - я только за (ну с соответствующими хоткеями).

Желательно и то и другое  


О, спс, надо будет попробовать...


А вдруг понадобится? Памяти жалко?  


  


Попробуй emacs, там функционал практически такой же, правда об шорткаты можно пальцы сломать  


Да, надо прекращать флудить  

vim.org

Насчет "автокомплита для плюсов". Сейчас занимаюсь всякими архитектурными исправлениями и рефакторингами для одной библиотеки в проекте. В этой библиотеке > 500 файлов исходников. Так вот ни Visual Assist, ни SlickEdit, ни, тем более, Eclipse не могут правильно распарсить код. Правильно - это чтобы работала навигация по коду (поиск defenition and references) и был корректный автокомплит. На части кода они довольно хорошо подсказки выдают, но вот с навигацией у всех плохо... 

Правильно у меня заработал только XRefactory в Emacs, и то только после долгой и упорной настройки. Томозит он еще здоровски, когда индексирует исходники. Но зато все очень честно делает и всегда корректно выдает то, что нужно. Так что рефакторить и писать код для меня получается удобнее в Emacs (ну и компилировать тоже). Отлаживаться, конечно, удобнее в студии. А для профайлинга и слежения за памятью использую Rational Purify & Quantify.

P.S. На vim еще даже не смотрел особо, знаю только как из него выходить и текст начать править  И, кажется, что для C++ в нем ничего подобного XRefactory по корректности работы с C++ кодом нет. Или знатоки vim могут что-то посоветовать?

Специально для эстетов! 


урра! 

exuberant-ctags + ОmniCppComplete + SuperTab
XRefactory не видел, сравнивать не могу.

Сам по себе ctags для c++ явно недостаточен, т.к. он только индексирует исходники и строит тэги для "глобальных" объектов, и то с проблемами (см. caveats и bugs в мане). Только по тэгам можно сделать браузер классов. 

А вот для навигации и автокомплита уже нужно полностью учитывать правила языка, чтобы определять какого типа объект или что стоит за вызовом функции. А это уже совсем нетривиальная задача: нужно учитывать что попало в область видимости, какие глобальные символы перекрыты локальными, а так же то, что стоит за #include, #define, typedef, templates...  Например, чтобы корректно переходить к defenition в случае, когда имеются перегруженные функции или просто функции с одинаковыми именами в разных классах, необходимо весь этот анализ в каком-то виде проделывать. 

Неужели в этих небольших скриптах для vim все это работает, даже для нетривиальных случаев? С помощью них можно, например, правильно найти все места в коде, где вызывается функция класса, имя которой совпадает с именами функций из других классов?

В XRefactory, скорее всего, уже встроен почти front end компилятора для C++, поэтому он так долго и честно парсит исходники (да еще и по нескольку раз, если встречаются директивы условной компиляции)..

Хотя надо будет найти время и попробывать на реальном проекте, вдруг и вправду все так замечательно работает...

Фтопку XRefactory!   С вашим подходом надо:

1. Утилу, строящую синтаксическое дерево кода + позволяющую обратно получить код (из изменённого дерева). В идеале двойное преобразование возвращает к исходному коду - т. е. храним также все отступы, что в каком файле и т. д.

2. АПИ для работы с этим деревом. + биндинги для питона и пр. + команд-лайн утилы для простых модификаций.

3. Пишем скрипты для вима и пр. для всяких рефакторингов.


Вообщем что-т такое...

Ага, EDG, который используется в Comeau и Intel C++.

Любитель, полный разбор исходного текста неизбежен для нормальной IDE. Так поступают (не для C++) и Eclipse, и Visual Studio.

и кучу рисков вроде ARM он уж точно поддерживает, не надо дезынформации ;)

В идеале так и надо, конечно  Только необязательно в пункте 3 vim, можно и другие "IDE" рассматривать  
Вон, мозилловцы чем-то подобным занимаются уже: http://wiki.mozilla.org/Dehydra_GCC. Может быть когда-нибудь в далеком (или не очень) будущем именно по такой схеме и будут с (тогда уже legacy?) с++ кодом работать..

А пока всего этого в полноценной реализации нету. И самое удобное из того, что я пробывал - Emacs+XRefactory. Когда корректно находятся все reference для символа, то часто можно автоматизировать работу по изменению кода с помощью макросов. Ну и встроенные рефакторинги тоже есть.  И автокомплит корректный (правда не быстрый), т.к. честно парсится весь код, который подключается через хедеры. 

Vim'у пока такое вроде и не снилось, только "костыли" в виде скриптов и ctags... Еще хорошо развивается Eclipse+CDT, может когда-нибудь и они подойдут вплотную к  front end компилятора для c++

Повторюсь, что не знаю возможностей XRefactory, по этому сравнивать не могу.


Нет, не во всех, парсинг довольно простой и неточностей там тоже хватает, но в большинстве случаев этого вполне достаточно.


Нет, они для этого и не предназначены (насколько я знаю).


И не будет снится, он не для этого предназначен. Vim это не IDE, это просто очень навороченый универсальный эдитор с кучей возможностей, которых имхо очень не хватает в "настоящих" IDE, направленых больше на визуализацию структуры проекта и различного рода рефакторинги.

Без сомненья. Речь об отделении этого в отдельные утилы.

На мой взгляд глупо выбирать из платформо-превязанного компилятора MSVC и платформо-независимого GCC. Если писать кросс-платформенное приложение, однозначно GCC. Если же под Win32, то однозначно MSVC (более шустрый и оптимизированный).
Хотя я сам, под Win32, юзаю Code::Blocks-8.02 + GCC-4.1

Банальный вопрос после столь бурного обсуждения: 

А можно GCC в MSVC-оболочку  встроить? 
веть можно как-то... раз интел встраивается.... 

Банальный вопрос, а зачем?  

Банальный ответ: а шоб було! 

Правильный ответ - можно. VS SDK в руки. В студию можно встроить, что угодно, но мутно (ну не люблю я COM).