Писали про чрезмерную оптимизацию, и что она во вред пойти может. Но по идее здесь ведь ещё такое обстоятельство, с одной стороны можно компилировать программу для любого процессора, с другой выбрать конкретную модель. Вот если бы я распространял клиентскую программу в бинарных кодах, то естественно отдал бы предпочтения универсальности. А если бы захотел быстрый сервер, то предпочтительнее было бы компилировать её под конкретную машину.

Лог файл как и cat/grep/tail/... средства универсальные и от ОС не зависят. Только вот в MSVC плюс к этим средствам есть еще и нормальный отладчик, а не консольный gdb и куча кривых front-end к нему. И чего же такого другого есть в линукс?
.

Есть, например, Rational Purify for Windows с нормальным GUI и возможностью интеграции в студию (правда только в старые версии). А какой есть нормальный GUI для valgrind? Чтобы при ошибке обращения к памяти сработал breakpoint, подключился отладчик и можно было прям сразу посмотреть значения переменных?

cygwin + gdb (от него). У него даже GUI встроенный   

вообще, мы говорили здесь о компиляторах, затем речь зашла о отладчике, ну и теперь ты свел все к разговорам о AStyle  
все это можно использовать и в винде, но почему-то мало кто использует, насчет bash, в windows есть windows script host, пусть для него можно писать скрипты только на vbscript и на javascript, зато возможностей у него масса, можно юзать любой COM объект, поддерживающий автоматизацию, думаю bash так не умеет...
кстати я использую в винде cygwin bash, по привычке, но скрипты на нем писать, необходимости не возникало  
Про AStyle ты вообще к чему сказал? такой инструмент встроен в студию, да и к программированию он имеет не самое прямое отношение.
cscope - можно собрать под windows, правда толку от этого, если ту-же самую визуальную трассировку вызовов может делать студия  
В общем, все эти крутые фишки может и работают, но, нужно в каждой из них разбираться, нужно с ними возиться. Тот-же функционал как правило доступен другими способами.

просто у тебя нет серьезных аргументов  


если ты этми все пользуешься, то чувствуешь себя Дейкстрой? 

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

Дык, icc тоже на месте не стоит   По поводу 9% - на www.spec.org заходили? Или Linux kernel - это наше все?

В смысле? Вы не в курсе, что у компиляторов есть ручки, которыми можно настраивать оптимизации? 

А что, Intel начал все это выпускать? Или вы обвиняете его, что он не делает компиляторы для других процессоров?

А вы видимо предпочитаете трепаться в эхах?
Для того, что бы иметь право писать предпочитаю, надо иметь выбор. Вы видимо предпочитаете Linux+gdb из Linux+gdb?

Ой! А давно целью программирования стало уменьшить потребность RAM?

Есть, но и Винде это тоже есть.

Гы гы, а вам эти 'нытики' уже поведали, над проектами какого уровня они работают?

Не умеет, да от нее этого и не требуют. doxygen замечательно из под Win работает. У gdb со всеми его мордами есть один недостаток - это не готовый дебагер, а набор 'собери себе дебагер' (как и все в *nix   )

предпочитаю Perl, в том числе и на Виндах

Это выливается (в основном) в огульное охаивание того, о чем охаивающий не имеет никакого понятия

По поводу 'предпочитаю писать на Виндах', хочу уточнить - предпочитаю на Виндах, но пишу в основном на Linux'е (так надо). А сейчас у меня проект вообще на голой машине, без ОС (x86 64бита). В качестве cross платформы используется Linux, компилятор gcc, дебагер gdb (через remote stub). Тексты (С++) пишу в Виндах в far'е   

empty

Это сообщение отредактировал(а) Леопольд - 20.6.2009, 11:35

В виндоуз нет таких мощных утилит для работы с консолью. Или вы станете спорить что виндоуз консоль может сравнится с юниксовской? Они и рядом не стояли. Линукс в своей консоли дает всю мощь операционной системы.


Давайте не забывать что purify и под линукс есть (и даже если не ошибаюсь он сначала под линукс был создан).
Насчет valgrind. Выбирайте что по душе
http://valgrind.org/downloads/guis.html


можно, можно, уж поверьте. Если вы не знаете как, это не значит что этого нельзя сделать.

Можно сколько угодно твердить о том что в линукс программировать неудобно. Но это значит что вы просто не привыкли.
Пишите кому как угодно.

Кстати, valgrind умеет работать с Windows приложениями (под Wine). Несколько через ж... , но все же  

Добавлено через 2 минуты и 22 секунды
Нравится мне эта тема   
Вопрос:

ответ:

  

Ну да..требуете от него черт знает чего а потом удивляетесь что через ж...  

А ведь я в самом первом посте предупреждал

  

помимо студии я попробовал несколько других IDE: CodeBlocks, CodeLight, Qt Creator.
и сразу бросилось в глаза, что STL контейнеры отображаются не так, как в Студии. вот и выдвинул требование 

Вот так расколбас от xvr



Не знаю как в студии сделано, наверное и дебагер работает без этих самых команд и гуй у него встроенный. РЖУНИМАГУ
(наверное он телепат.....)


Надеюсь, что студия - достаточно большой телевизор для размещения всех кнопочек. (Или достаточный для размещения всех кнопок, коих возможно не так много как в ждб, поэтому и телевизор не такой большой нужен)

Добавлено @ 14:30
Автор тот же

Невозможно не согласиться.

Добавлено @ 14:35
xvr

Вы видимо не работали под нормальным дистрибутивом линукса. Без обид.
Такая хрень, которую вы описали, осталась наверное в BSD системах, не думаю что под ними сидят программисты, и linux'ах типа "собери конструктор".

Это сообщение отредактировал(а) fry - 20.6.2009, 14:36

Логично!   

Я это сказал в контексте того, что IDE в nix это не программа которую нужно проинсталить с коробки, а просто GUI обычно с открытым инструментарием — утилиты, плагины и т.д.. Добавив 2-3 десятка утилиток получаем возможности близкие к студии - причем на 101% достаточные для эффективной работы.

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

Вау! Во времена моей молодости она такого не могла - честно!  Никак сперли идею у GNU...


Дык один седовласый дедушка-приколист сказал что все в этом мире относительно. Потому icc точно на месте не стоит а движется в зад  ...

 Нет не заходил. Потому как пропуская произвольный сигнал через произвольную дискретную цепь мы получаем произвольный результат. Это я о том, что все эти тесты это попытка аппроксимировать прямой линией систему более высокого порядка - и это не метафора. А вот ядро Linux это О-О-ОЧЕНЬ показательный пример. Там находятся практически все встречаемые в реальном программировании структуры данных - и лучший практический тест тяжело придумать. Кстати, а Вы утрируете - 9% это относительно уже морально устаревших версий gcc. Почти у всех кто сейчас работает на Linux-машинах даже более новый компилятор.

Мы в курсе что это был тест по одновременной оптимизации - время исполнения и размер. Очень малое подмножество всех опций компилятора. А где результаты для остальных? Также мы вкурсе, что для того же GCC помимо обыкновенных "уровней оптимизации" есть еще уйма ключей для каждой отдельной архитектуры - от AMD64 до AVR8 манипулировать которыми нужно еще уметь, потому как некоторые опции взаимоисключающие. Как с ними поступить? Получился тест мотороллера с мотоциклом - но зато оба на второй передаче. 


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


Признаюсь - грешен. Но как видите делаю это в пятницу по-ночам, и днем в субботу   . 


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


Да, и даже с избытком. Но звезды от этого не становятся ближе. 


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


Да много что в ней из nix-инструментария замечательно работает. Но никак не благодаря MS - но это отдельный разговор, не надо еще одного холивара в холиваре...


Именно.  

А нету у него команд, совсем   Все по кнопочкам и менюшкам развешано.
А ей не надо столько кнопочек, не умеет она столько, сколько умеет gdb
Золотые слова   

RH и SUSE устроят? Правда я с ними работаю исключительно в командной строке (через ssh). C GUI'ями разбираться лень, да и не приспичило пока.

Сколько тут было перечисленно GUI к gdb? С десяток наверное будет. И всяких IDE тоже с десяток (начиная от VIM и до eclipse)
Так что все таки конструктор   

gdb ОЧЕНЬ мощный дебагер, студия с ним и рядом не стояла. С другой стороны, за эту мощность надо платить - либо досконально знать его команды (его командная строка доступна в любом его GUI), либо заниматься раскопками среди его GUI, т.к. единого мнения по поводу того, какой из них самый самый - нету.
С другой стороны студия гораздо более user-friendly, чем gdb

Кстати, в Виндах есть дебагер сравнимой с gdb мощности - windbg. От так же с командной строкой, и такой же неудобный в использовании как и gdb без GUI   И команды у них не совпадают   

И с чего бы это?          

Факты есть, или просто потрепаться вышел?

А стоило бы. Хотя бы посмотрел, что это такое. Не стал бы своё дремуче невежество выставлять
Мы в 21 веке живем, не забыл? Drystone'ы в прошлом веке остались   
Это вообще не пример. Прикладные программы не в ядре сидят, они работать должны.

Что такое SPEC (конкретно SPECCPU)
Это набор РЕАЛЬНЫХ программ (в частности, туда входят gcc, bzip, xerces, и много других, всего около 2х десятков). Их компилируют и исполняют на тестируемой системе. Все параметры присутствуют в отчете, включая конфигурацию компьютера и компилятор. Результатом является скорость исполнения (среднее геометрическое по всем тестам).
Есть 2 режима тестирования - base и peak. При base для ВСЕХ тестов выставляются одинаковые опции компилятора, при чем их количество ограниченно. При peak опции выставляются индивидуально на каждый тест, их количество не ограничено.
Все результаты публикуются на www.spec.org
Абсолютно не практичный тест, мне честно говоря начхать насколько быстрее будет исполняться ядро. Если программа сидит в ядре, то с этой программой что то не так (или с программистом)
А icc версии 9.1 (с которой там сравнивали) - это не 'морально устаревший'? Сейчас icc уже 11.1

Размер тут никого не интересует
  Зачем вам опции, с которыми результаты хуже? Или специально, что бы было с чем gcc сравнивать?

бла бла бла. Тестировали 2 компилятора на одной и той же машине. Или это не понятно?

Правда 2й ножик резать разучился, а так да, выбор есть   
Если вас интересует ПРОИЗВОДИТЕЛЬНОСТЬ на x86 машине (КОНКРЕТНОЙ), так и надо выбирать компилятор под нее. Если вас не интересует производительность, а интересует многоплатформенность - надо брать gcc. Если вас интересует и то, и другое вместе - надо сразу застрелится   

Их 3 - скорость, скорости и еще раз скорость (для x86 по крайней мере)

Да уж, и вы к нему тоже руку приложили (и не одну   )

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

Потому что он не gdb а dbg (от MS)