Стала актуальной проблема выбора компилятора под C++. Кто что может посоветовать и назвать плюсы и минусы...
Сразу могу сказать: Конечно MS Visual C++ 6.0SE. Это практически стандарт. На нем написаны почти все игры, исходники которых уменя есть. Оговорю: ЭТО тебе не в делфи кнопочку сделать, тут ты сталкнешся с ресурсами, ID и всем прочим - потом будеш знать как работает Windows. Кто хочет заниматься реверсингом тоже надо потренироваться на VC++ (ИМХО конечно же) Вообще можно использовать MFC но ИМХО это маздай. Наконецто ктото забил на дурацкий делфи и занялся делом ))0 ОПЯТЬЖЕ И-М-Х-О (madnet, не обижайся!!!)))
Ниче не хотел говорить в этой теме, дабы не флеймить, но Kez, не трогай делфу, здесь вопрос о вариациях компиляторов построенных на С - делфа ни причем =)))
Конечно заденет!!! Вот тебе за это, облажаю твою горячо любимую VC по отношению к Борланду С++(для информации кто не знает Боранд выпустили Делфу =))) ) Итак почему VC отс*%№:ает у BC начнем: Причина первая Borland C++Builder предоставляет средства быстрой разработки приложений (RAD) "Visual C++ имеет существенный недостаток - отсутствие по-настоящему мощной среды разработки." - Larry Perlstein, Dataquest. Как программисты, так и аналитики согласны с утверждением, что наличие RAD-средства обеспечивает резкое повышение производительности при использовании C++ и способствует созданию более качественных программ за более короткое время. Тем не менее, в силу ряда причин Microsoft ориентируется на традиционный, "ресурсно-ориентированный" способ построения программ, в то время как программисты препочитают RAD-подход, под которым понимается наличие компонентной модели, использование drag-and-drop инструментов. "Превратить Visual C++ в RAD-инструмент создания программ - значит просто продублировать средства, уже присутствующие в Visual Basic." Даже если это и так, то не хочет же, в самом деле, Microsoft предложить разрабатывать прототип C++ проекта на Visual Basic - с последующим кодированием уже на C++? Скорее всего, Microsoft стремится из чисто коммерческих соображений избежать конкуренции своих продуктов друг с другом, что, в общем-то, вполне понятно. "Visual C++ слишком стремится выполнить слишком многое." - John Milam, Nations Bank. Microsoft доказывает, что добавление RAD средств приведет к потере эффективности в случае, когда требуется низкоуровневое программирование, что недопустимо для решения большого класса задач. Возможно, это так и есть на самом деле для Visual C++, и добавление RAD-технологии не в ущерб производительности потребовало бы переработки самой архитектуры Visual C++. В C++Builder 4, Inprise обеспечил сочетание RAD инструментов, их высокой эффективности и управляемости. Borland C++Builder 4 на 100% совместим со стандартом ANSI C++, имеет высокую степень оптимизации и не содержит "черных ящиков". В то же время, Borland C++Builder 4 не требует отказа от использования Visual C++. Хотя Borland C++Builder 4 умеет делать все, что и Visual C++, а также многое сверх того, многие программисты выбирают его при переходе на C++ от Visual Basic. Убедившись, что он более эффективен в работе, многие из них начинают рассматривать C++ Builder как основной инструмент для создания программ. "Borland C++Builder является первым инструментом из всех, с которыми мы знакомы, который действительно реализовал RAD-стиль разработки приложений применительно к самым различным классам задач, включая работу с Internet, ActiveX, с проектами уровня предприятия, и все это - с использованием стандартного C++." - Eric Binary Anderson, Ent Magazine. Причина вторая Borland C++Builder 4 тесно интегрирован с обеими базовыми технологиями создания распределенных систем - CORBA и СОМ Обе технологии играют ключевую роль при создании распределенных систем. Если СОМ доминирует в продуктах Microsoft (на платформе Windows), то CORBA это самое правильное решение в многоплатформенных системах. Сейчас совершенно очевидно, что Microsoft ставит задачу обеспечения функционирования СОМ во взаимодействии и "поверх" CORBA - просто вследствие того, что большинство организаций работают в гетерогенных средах, что исключает (или, по крайней мере, сильно затрудняет применение СОМ "в чистом виде"). Значительные усилия были приложены к тому, чтобы создать API, обеспечивающего взаимодействие СОМ и CORBA. К сожалению, такой подход, приводит с существенной потере производительности и что еще хуже, к ухудшению управляемости создаваемых систем. Кроме того, с появлением СОМ+ многие из таких разработок просто устарели. Borland выбрал подход, который позволяет разработчику оставаться в стороне от "войны стандартов". Borland C++Builder 4 обеспечивает лучшую в компьютерной индустрии поддержку как CORBA, так и СОМ. Некоторая ирония судьбы заключается в том, что Borland C++Builder 4 обеспечивает лучшую поддержку технологий Microsoft, чем Visual C++ - например, поддержка "одношаговой" разработки приложений, созданных для Microsoft Transaction Server (MTS). При работе с C++ Builder программисты на Visual C++ могут легко преобразовать код для поддержки СОМ для взаимодействия с CORBA, тем самым позволяя своим программам выйти на другой уровень - уровень Предприятия. Конечно, с чисто технической стороны дела, любое средство разработки на C++ (при наличии необходимых h-файлов, библиотек, продуктов третьих фирм и запаса терпения) способны создавать CORBA объекты как клиентские, так и серверные, но на практике успех вряд ли достижим без соответствующих интегрированных средств разработки. Образно говоря, разработка CORBA проекта на Visual C++ похоже на выбор автомобиля, а не самолета, как средства добраться из Сан-Франциско до Нью-Йорка. С Borland C++Builder 4 программисты на Visual C++ могут выйти за его пределы и дать своему коду жизнь на уровне Предприятия. Причина третья Borland C++Builder 4 полностью совместим с Visual C++ не только на уровне исходных текстов, но и по файлам проектов и бинарным библиотекам Многие организации уже сделали огромные инвестиции в проекты на Visual C++, в том числе на подготовку и обучение персонала. C++Builder 4 может подхватить эстафету от Visual C++, позволяя разработчикам использовать уже написанный код и свои навыки, но уже с RAD-средствами и другими дополнительными возможностями, а также с поддержкой технологии CORBA. Проект на Visual C++ может быть импортирован в Borland C++Builder 4 и тут же откомпилирован. Обеспечена полная поддержка MFC и ODBC. Borland C++Builder 4 полностью совместим с Visual C++, экономя и время на разработку, и деньги на обучение. Причина четвертая Borland C++Builder 4 содержит много нового и интересного для программистов на Visual C++ В то время, как Borland C++Builder 4 содержит большинство из средств Visual C++, которые содействуют повышению эффективности разработки приложений. Visual C++ 6.0 существенно отстает в следующих ключевых областях: Настоящая RAD-технология создания приложений Встроенная визуальная поддержка CORBA Полная поддержка MTS Создание многозвенных систем, взаимодействующих с БД Удаленная отладка Высокопроизводительные средства доступа к БД Объектно-ориентированная компонентная модель Включив Borland C++Builder 4 в набор используемых инструментов, программисты на Visual C++ смогут оценить новый уровень производительности при написании программ без принесения в жертву эффективности кода, управляемости и без отказа от совместимости с Visual C++. Надеюсь тебе достаточно. Я не стал писать своими словами, а вставил эту цитатку, хотя х3 кто ее написал, но думаю все согласятся =))) KEZ Respect =)
madnet, прости что не читал все что ты написал... несмог... лично я всегда за VC. я не говорю что это легко.
Блин, а я так старался для тебя =( YooogI, по поводу Делфи ты не прав, но с тобой мне спорить лень мы уже на 10 страниц спор раздули с КЕЗом, но ворос не в этом, сейчас про С говорим. Обоснуй ответ.
То что ты на нем пишешь не доказывает его привосходства, если ты написал что он лучше, будь добр аргументируй.
А нафиг мне знать как работает Windows? Если я всю жизнь занимаюсь, например, статистическими рассчетами? Ты еще скажи что оптимальный вариант будет ассемблер - тогда ты виндовс знать не будешь (ты до него просто не дойдешь))) зато будешь знать как работают процессоры и контроллеры ))) Это я все к тому, что ботанику не нужно знать как работают ядерные реакторы. Каждый специалист в своей области выбирает тот инструмент, который больше всего ему подходит. Кроме того не нужно говорить что VC++ это стандарт. Стандарт чего? Приведи соответсвующий RFC. Посмотрим. И уж тем более не нужно говорить, что VC++ это стандрат в .NET. Он к дот нету вообще отношения никакого не имеет.
Algol "Стандарт" - это значит что он удобен, и универсален. Игрухи например (которые имеются) сделаны на VC Я бы даже сказал (уже говорил) что он ЕСТЕСТВЕННЕН )) Если ты будеш писать на ASM ты как рас будеш отлично знать работу винды. Если честно я считаю что .NET и VC это почти одно и тоже. Однако проголосовал за VC он мне ближе.
Хоть я и в Сии (Борланде) пишу но чаще всего на Дельфии Хотя многие правы это дела вкуса если одного устраивает зачем ему вдалбливать что то другое лучше? =)
.NET это языконезависимая технология.... Во-первых она работает практически с любыми процедурными языками, а во-вторых ее нельзя сранивать с VC просто потому, что VC это язык, а .NET это технология (почувствуй разницу))). Это все равно что сравнивать протокол HTTP с VisualBasic и выяснять что из них лучше)) Нет в нем ничего естественного )) Например что естественного в таком фрагменте while (*p!=0) *q--=*p++; ?? Что тут можно понять ?? Уж если на то пошло, то более естественнен паскаль (с его жестким синтакисом), в котором такую абракадабру не напишешь. А игры пишут на VC потому, что он более производителен, когда речь идет о тесной работе с виндой и железом.
имхо тема тоже глупая.... кез со своим плохим делфи=) вообщем пошёл флейм. 1) Я люблю делфи за то что н нужно замарачиваться на однообразном создании тех же самых кнопочек и окошечек, здесь все сделано для удобства программиста, опять таки - не нужно каждый раз изобретать велосипед! То же можно и про билдер сказать который впринципе умеет создавать действительно качественные и оптимизированые программы, по производительности почти ничем не отличающиеся от VC. 2) Насчет компилятора... я бы оставил билдер и VC. Собственно почему два? потому что настроек у компилятора билдера признаюсь меньше чем VC и большенство примеров на си подготовлены специально для VC, хоть madnet и сказал о полной совместимости, то иногда чтобы не марачиться легче все подогнать под VC. Ну и VCL от делфи... это огромный плюс см 1) =). А dot Net не люблю и все я всю эту новую технологию.... пока я не готов к такой перемене, должно пройти время что бы все подсели на firework и тд...
