» хочу начать учить с++

сабж собственно.
Причем хотелось бы еще применить такую градацию компиляторов- для начинающего(учить язык) и для собственно работы(писать проф.программы).

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

какую выучу на такой и буду работать. Я в них просто АБСОЛЮТНО не бум-бум.

А универсальной среды для с++ нет?

ironwit
Если ты хочешь учить язык то рекоммендую gcc, т.к. он из известных мне наиболее "правильный" и безглючный.
Альтернативный вариант - Intel C++ Compiler. Про всякие там Borland забудь как про страшный сон
Если же ты собираешься учить конкретный фреймворк (MFC итд) то соответствующую среду (VC++ или что-то там).
ПМСМ, начинать надо именно с языка

ЛАДНО, давай так. Есть у меня книга Lippman, Stanley"С++ для начинающих". Какой лучше всего компилятор для решения примеров из этой книги?


Цитата:

Если же ты собираешься учить конкретный фреймворк

подробнее можно? Представь что общаешься к полным чайником.

ironwit
Да любой покатит. Я несколько лет пишу на Сях и со своего опыта настоятельно рекоммендую gcc или Intel.
На худой конец Microsoft.
Только НЕ Borland!


Цитата:

подробнее можно?

Можно. Фреймворк - это набор классов (компонентов), которые ты можешь использовать для ускорения разработки приложений, чтобы не писать все с нуля. Наиболее известный сегодня под форточку - MFC (Microsoft Foundation Classes), он идет в комплекте с Microsoft Visual C++. Очень глючный Еще есть популярный (и еще более глючный и галимый) VCL - Visual Components Library. Поставляется с Borland C++ Builder / Delphi. Ну и так далее... Так вот чтобы программить под этот фреймворк, нужно его подробно изучить. Программирование под фреймворк от чистых АПИ очень сильно отличается. Поэтому, выучив одно, совершенно не в состоянии браться за другое. Ну в общем, в любом случае, сначала учи собственно язык.

mymuss
Интеловский компилятор лучше не использовать в коммерческих продуктах. В нем слишком много ошибок. Обновляется примерно каждые две-три недели, и постоянно в списке пофиксенных багов идет куча ошибок, связанных с неправильной генерацией кода. Польза от него весьма сомнительная.

Если интересует 100% ANSI-компилятор, лучше использовать Comeau - он полностью соответствует стандарту. Но опять же, по-моему это скорее академический пакет, чем для коммерческой разработки.

Если предполагается разработка только в Windows, то лучше использовать VC++. Тем более, в последней версии сделаны существенные улучшения в плане поддержки стандарта языка - практически не отличается от GCC и ICL.

Для кроссплатформенной и юних-разработки лучше компилить в GCC.


Добавлено

Цитата:

Наиболее известный сегодня под форточку - MFC (Microsoft Foundation Classes), он идет в комплекте с Microsoft Visual C++. Очень глючный

В MFC как раз минимум глюков по сравнению с другими библиотеками - за десяток лет ее вылизали как следует. Другое дело, что она не является строго объектно-ориентированной и самые интересные возможности C++ и ООП в целом там отсутствуют. Но явных глюков там нет.

Цитата:

Если предполагается разработка только в Windows, то лучше использовать VC++.

если я правильно понял - учить можно по vc++, если захочу писать под *nix то позже изучить GCC?

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

dremon
ок. Спасибо. Буду искать visual c++ и учить. 10х.

Вопрос - по среде visual c++ нет никаких доков? Типа как там проект создать...

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

dremon

Цитата:

В MFC как раз минимум глюков

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


Цитата:

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

ну, особенно если с Borland'овскими сравнивать...

Цитата:

Ого-го... Там глюков что в винде. Начиная от явных, типа, отсутствия вызова деструктора, где необходимо

Мы о каком языке говорим?

Цитата:

и до серьезных труднонаходимых, которые всплывают при работе с потоками

Хм-хм. Большинство проблем, связанных с потоками, возникает из-за их неправильного использования. На библиотеку пенять не нужно. Я работаю с проектом размером около полутора млн. строк, значительная часть которого написана с использованием MFC. Мне очень не нравится эта библиотека тем, что она несет в себе огромный груз совместимости со старыми приложениями, тем, что она нарушает все три принципа ООП и тем, что она не поддерживает самые интересные возможности C++ (главным образом опять же из-за уже никому не нужной совместимости со старыми версиями компиляторов). Но уж поверь мне - глюков в ней минимум. Да, много чего приходится делать через ж**у, много чего в ней недокументировано, много чего не хватает, но в плане надежности она вовсе неплоха.

dremon

Цитата:

Мы о каком языке говорим

Ну я так понял о VC++...


Цитата:

Большинство проблем, связанных с потоками, возникает из-за их неправильного использования

Ага. Остальная же часть (меншинство ) из-за кривого кода в MFC

Цитата:

поверь мне - глюков в ней минимум

Дабы не быть голословным:
мамба намба ван: http://www.codeproject.com/buglist/bug_cbytearray_serialize.asp
мамба намба ту: http://www.codeproject.com/buglist/mfcdockingstylebug.asp

Я на дотнет перешел сравнительно недавно, а вот в предыдущей версии... Реализация CSocket чего стоит! (сколько ж я с ней намучался, пока не прочитал что там весь код кривой!). Ну про треды я уже сказал... Насчет груза с совмеситимостью я согласен: как раз же и получается отдельные куски кода остались еще с времен win16! Другие их используют. Пи...ц! (простите за грубость).

А вообще если в гугле в groups поискать, то дофига еще найдешь

вообще вы меня запугали. Хоть из DELPHI НЕ уходи

ironwit

Цитата:

вообще вы меня запугали. Хоть из DELPHI НЕ уходи

Я вспоминаю свою студенческую "молодость", когда я программил на Дельфе... Блин, что тебе сказать... По сравнению с VC/MFC, Delphi/VCL - это ТАКОЙ рассадник глюков, что просто диву даешься как ее еще покупают :-\
Вот уже несколько лет прошло, а я еще ни разу не пожалел что не продолжил в свое время заниматься Дельфой, а занялся С...

Цитата:

а я еще ни разу не пожалел что не продолжил в свое время заниматься Дельфой, а занялся С...

посмотрим....

ironwit
Лично я начинал с интеловского компилера и настольная книга у меня была "дохлого страуса"...
Потом пришлось кодить на бульдере, тк. VC++ на тот момент был ну очень глючный по сравнению с бульдером.

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

Как пример только на интеловском компилере получал продукт наиболее коректно работающий на 384 DX от ALI... Тогдаэто было необходимо как воздух, программа крутится уже более 5-и лет без единого сбоя или перезагрузки, и это несмотря на то что половину векторов было перехвачено, а вектор на спикер вообще направлен в какую то дыру (времени небыло разбираться куда я его заслал)....
Последнее время я кодил на VC/MFC вроде ничего.....Потом вернулся к бульдеру, фирма подписала договор с Борланд на потдержку и разработку компонент....

dremon

Цитата:

Хм-хм. Большинство проблем, связанных с потоками, возникает из-за их неправильного использования. На библиотеку пенять не нужно. Я работаю с проектом размером около полутора млн. строк, значительная часть которого написана с использованием MFC. Мне очень не нравится эта библиотека тем, что она несет в себе огромный груз совместимости со старыми приложениями, тем, что она нарушает все три принципа ООП и тем, что она не поддерживает самые интересные возможности C++ (главным образом опять же из-за уже никому не нужной совместимости со старыми версиями компиляторов). Но уж поверь мне - глюков в ней минимум. Да, много чего приходится делать через ж**у, много чего в ней недокументировано, много чего не хватает, но в плане надежности она вовсе неплоха.

Согласен, что потоки надо уметь использовать - это конечно не искусство, но очень тонкая работа. А вот про управление потоками через MFC это ты конечно махнул! Некто Джеффри Рихтер (надеюсь в программировании потоков на Win он для тебя непререкаемый авторитет?) утверждает и вполне обоснованно, что MFC с этим справляется отвратно. В потоках следует использовать Win API методы _beginthreadex и _endthreadex. И вообще, мое ИМХО, что MFC следует использовать только в GUI - в остальных участках программы он не нужен и даже вреден! Отсылаю к тому же Джеффри Рихтеру - у него нет ни строчки кода с использованием MFC!

Лучше использовать COM + ATL, правда это совсем другая история

mymuss

Цитата:

Я вспоминаю свою студенческую "молодость", когда я программил на Дельфе... Блин, что тебе сказать... По сравнению с VC/MFC, Delphi/VCL - это ТАКОЙ рассадник глюков, что просто диву даешься как ее еще покупают :-\
Вот уже несколько лет прошло, а я еще ни разу не пожалел что не продолжил в свое время заниматься Дельфой, а занялся С...

Угу
Я тоже до курса третьего писал на Delphi и только из-за того, что не хотел возиться с GUI. Однако со временем столкнулся с проблемами Pascal в качестве языка ООП и понял, что там совсем базовая модель классов и ушел на C++.

ironwit

Цитата:

посмотрим....

А что тут смотреть? Для начала найди любую базовую книгу по С++, а затем бери Бьерна Страуступа и штрудируй его - ты поймешь всю силу этого языка. В чем сила, брат?

Цитата:

ты поймешь всю силу этого языка.

Это точно, я когдапервую чепочку потоков создал, радовался как дитя

ЛАДНО, ладно. Уговорили, Начинаю читать липпмана. И ищу по городу компилятор vc++ . А дальше будет видно

Peroon_N

Цитата:

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

Слушай, что Pascal, что С++ - универсальные языки. И в принципе одного и того же результата можно добиться в их обоих. Вопрос лишь в методах решения задачи средствами конкретного языка. Компилятор тут ни при чем (правда с некоторыми оговорками) - он лишь переводит твою программу в исполняемый код.

Borland - лучшая СУБД??? Для чего??? У них есть Paradox, который слабее MS Access, и Interbase/Firebird, которые значительно уступают промышленным СУБД MS SQL/Oracle/DB2/Informix/Sybase и даже простому MySQL/mSQL! Какое тут может быть лидерство??? Проблема в том, что разработчики Delphi/C Builder очень сильно привязаны к BDE и практически не используют ODBC/ADO/OLE DB. Компиляторов embeded sql я вообще никогда не видел для pascal - даже для modula/fortran есть встроенный SQL!!!

Меня конечно забросают камнями, но Borland - тупиковая линейка продуктов.

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

Bloody_Nokia_Adept

Цитата:

Меня конечно забросают камнями, но Borland - тупиковая линейка продуктов.

первый камень - VisiBroker - хорошая весчь.


Цитата:

даже простому MySQL/mSQL

все таки не стоит их ставить в одну категорию.

ironwit

Цитата:

ЛАДНО, ладно. Уговорили

Тебя не уговаривали. Тебе говорили, что С++ на голову выше Object Pascal.


Цитата:

Начинаю читать липпмана

Слова не юноши, но мужа


Цитата:

ищу по городу компилятор vc++

Учти. Не все примеры из Страуструпа (не знаю как у Липпмана - не читал) на нем работают - я уже говорил, что там есть проблемы с шаблонами. Для академичности лучше всего брать GCC. Посиди, попиши простые констольные проги с использованием <stdio.h> - разберись с возможностями самого языка. Затем лишь переходи на VC++ (обязательно на 6 - 5 слишком кривой, а .NET тебе пока рано) и ковыряйся с программированием под Win.

Надеюсь ты в прошлой жизни кодера Delphi использовал COM? Пригодится. А от MFC лучше воздержись. COM/ATL/WTL - вот истинный путь MFC там и рядом не валялся!

Добавлено
Ryback

Цитата:

первый камень - VisiBroker - хорошая весчь

Приехали... Один из коммерческих ORB. Лучше использовать free'шный OmniORB.

Цитата:

Дабы не быть голословным:

Блин, я же не говорю, что там совсем нету глюков - говорю, что их там минимум. Я сам могу привести еще пару примеров. Покажи мне библиотеку, где их меньше, чем в MFC и которая так же хорошо протестирована за столько лет на десятках тысяч приложений. Я такой не знаю (STL не в счет). Кстати, 7-я версия MFC и VS.NET в частности была выпущена ну уж совсем недоделанной. Поспешили.

Цитата:

А вот про управление потоками через MFC это ты конечно махнул

Я про это ничего не говорил.

Цитата:

И вообще, мое ИМХО, что MFC следует использовать только в GUI

А мое ИМХО - ее вообще не нужно использовать в новых проектах

А как насчет .NET? Кто-нибудь считает что у данной платформя есть будушее? Сказали что она очень сильно отличаетcя от 6.0...

Цитата:

А как насчет .NET?

ПРИсоединяюсь к вопросу.


Цитата:

COM/ATL/WTL - вот истинный путь

подробнее или урлы.

Цитата:

Посиди, попиши простые констольные проги с использованием <stdio.h>

А вот этого не надо Надо сразу с STL и iostream начинать.

Bloody_Nokia_Adept

Цитата:

Приехали... Один из коммерческих ORB. Лучше использовать free'шный OmniORB.

А с каких это пор коммерческая оценка продукта влияет на его функциональность? И почему в таком случае ты VC не трогаешь? Или сам занисаешься коммерческой разработкой именно под ним и с использованием коммерческого софта, такого как Oracle/mssql/прочее?

VisiBroker обладает хорошей поддержкой спецификаций и набором сервисов. OmniORB тоже качественный продукт, один из самых ( если не самый ) шустрый, но ведь разговор был не про сравнение брокеров, а про про cемейство продуктов борланд/inprise...