alzt пишет: > > 3. Препроцессор. Сильно не нравится, источник ошибок, но к сожалению не > всё можно сделать без него.
Мне кажется, проблема не в самом языке, а в менталитете и в средах
разработки. В мире C++ автоматически генерируемые исходники — это нечто
неординарное. А среды разработки, как правило, не Makefile-based, и в
них не пропишешь, что часть файлов генерится из других. Плоские проекты.
Сейчас вроде получше стало, но уже поздно. Разрабы библиотек считают,
что либо всё нестандартное должно делаться макросами, либо никак. В
итоге макросы есть в Qt, есть в wx, есть в ATL.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, StevenIvanov, Вы писали:
SI>>Здравствуйте, remark, Вы писали:
R>>>Что Вам мешает в С++?
... R>По поводу манглинга имен — OK R>По поводу экспорта шаблонов и теневой системы типов — а с какой периодичностью это мешает в работе — приводит к ошибкам или существенно увеличивает время разработки?
это неиспользуется практически. R>з.ы. а что такое теневая система типов?
в специальной литературе (встречал, по-моему, у Саттера, Стандарты программирования на С++) так называют функции со спецификацией исключений. Насколько я знаю спецификация исключений полностью не поддерживается MSVC, а так же ее советуют избегать (тот же Саттер, стандарты программирования на С++). R>з.з.ы. а для C# много компиляторов? Их действительно можно использовать так что одним скомпилировали, а используем с другим?
Mono C#, Microsoft C#. Да.
SI>>4) Невозможность быстро экспортировать в С++ крупный проект на С — возникает куча утомительных ошибок с преобразованием типов и проч. Не совсем недостаток, просто drawback из-за того, что в С++ введены такие вещи, как строгая типизация
R>Тут непонятно. А в какой язык будет легче экспортировать крупный проект на С?
SI>>5) Макросы, живущие отдельно от языка. Причина многих бед и катаклизмов Контрпример — в LISP макросы не являются злом, напротив придают языку колоссальную мощь.
R>Тут тоже не понятно. Если они для тебя причина постоянных бед, то зачем ты их используешь?
я их использую и все ок. Однако они живут отдельно от языка; признаются многими специалистами (в т.ч. Бьярном Страустрапом) крупным недостатком языка.
SI>>6) По сравнению с С# нет вкусностей типа делегатов и потрясающе мощного рефлекшна.
R>ОК
R>
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, StevenIvanov, Вы писали:
SI>>6) По сравнению с С# нет вкусностей типа делегатов и потрясающе мощного рефлекшна.
NBN>По поводу делегатов — не соглашусь.
почему?
Re[7]: Что Вам мешает в С++?
От:
Аноним
Дата:
22.06.08 10:57
Оценка:
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Аноним, Вы писали:
А>>Нееет, без полной интеграции в язык неудобно. Нужно что бы из unmanaged кода было сделать managed без всякого переписывания старого кода.
E>Зачем? А что делать с RAII например или с явными вызовами delete?
Delete == C# Dispose, можна удалить сразу или поставить в очередь на удаление в зависимости от состояния сборщика в текущий момент.
CreatorCray пишет:
> S>а вот с какой целью изготовили похожую на нее WTL и, особенно, почему > S>люди ей пользуются — для меня загадка. > WTL ИМХО больше на MFC похожа.
Ну не знаю. Внутри она устроена как оконная часть ATL, из которой
собственно и сделана — с чего бы ей быть похожей на MFC? DDX разве что
приделали MFC-образный.
> Пользуются потому, что удобнее чем MFC. > Не требует ничего тащить с программой — никаких dependencies.
Что тащить ничего не надо — это замечательно. Но вот что она
обеспечивает такого, чего нет в винапи? Докинг там скажем или что-нибудь
подобное wxSizer? Или GDI объекты умеет правильно уничтожать, как та же
wxWidgets? Или куча стронних контролов под нее есть, как под MFC?
IMHO, без разницы — на голом винапи писать или с WTL.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
OCTAGRAM пишет:
>> > А какой промышленный язык справляется с этой задачей лучше? Т.е. какой >> > язык способен быстро сгенерировать эквивалент 40Мб нативного кода? >> >> Да известно какой — Паскаль. Но, там объем исходников бы в разы больше >> получился, по моим прикидкам. > > A из–за чего? Отсутствие шаблонов?
Да, в основном. Хотя begin Тоже свою лепту бы внес
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, remark, Вы писали:
R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>Что Вам мешает в С++?
Вот тут http://www.digitalmars.com/d/2.0/overview.html создатель языка D описывает в том числе и что ему мешало в C++ (Features To Drop) что он (зубр съевший на создании C++ компиляторов не одну собаку http://www.walterbright.com/) решил создать свой язык, получше, вроде у него это неплохо получается, жаль только никак ни может остановится в процессе совершенствования
OCTAGRAM пишет:
> Мне кажется, проблема не в самом языке, а в менталитете и в средах > разработки. В мире C++ автоматически генерируемые исходники — это нечто > неординарное. А среды разработки, как правило, не Makefile-based, и в > них не пропишешь, что часть файлов генерится из других.
В VC — вполне пропишешь.
> Плоские проекты. > Сейчас вроде получше стало, но уже поздно. Разрабы библиотек считают, > что либо всё нестандартное должно делаться макросами, либо никак.
Под виндой — макросами удобнее, чем скажем перлом. Потому что перл
сначала поставить надо, потом пути настроить...
> В итоге макросы есть в Qt, есть в wx, есть в ATL.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, remark, Вы писали:
R>А какой промышленный язык справляется с этой задачей лучше? Т.е. какой язык способен быстро сгенерировать эквивалент 40Мб нативного кода?
Кроме паскалеобразных еще Objective-C.
А не майнстримных вообще полно.
Здравствуйте, remark, Вы писали:
R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>Что Вам мешает в С++?
Больше всего мешает необходимость практически всегда помнить о кучи мелочей которые в большинстве случаев, в высокоуровневом языке должны быть скрыты и которые обычно абсолютно не важны (кроме редких случаев). Например нужен динамический массив, берем std::vector. Я должен помнить что его итераторы легко убить любым неосторожным движением, я могу с легкостью перепутать итераторы от разных массивов, у меня нет режима (кроме отладочных версий) с постоянной проверкой индексов на выход за пределы, если я хочу получить указатель на буфер я должен это делать одним не совсем очевидным способом, притом я должен помнить что у пустого вектора этот указатель невалидный, если я хочу освободить память занимаемую вектором я тоже должен это делать через жо(swap).
В общем голова оказывается забита совершенно не нужными и мешающими мелочами, если еще сюда добавить некторые особенности некторых компиляторов (привет C++ Builder) то бывает совсем грустно.
И эти мелочи во многом "просаживают" высокоуровневость языка.
Ну и сюда же и возможности метапрограмирования, которые вроде бы и есть, но из-за этих самых "мелочей" сложность написания на них растет просто экспоненциально, из-за чего в прикладном коде метапрограммирование просто напросто реально не доступно.
Здравствуйте, Alexander G, Вы писали:
А>>>Не хватает: А>>>1. Делегатов на уровне языка; RO>>В C++09 будут.
AG>Да ? Покажите пропозл. AG>Я не особо слежу, но насколько я помню, там только сделают boost::function как std::function (ну так это не "на уровне языка") и добавят лямбды в язык, с помощью которых эмулировать замыкания в С++ будет легче чем сейчас (это утилита для делегатов но не сами делегаты).
Объясни, пожалуйста, что именно могут делегаты и не могут лямбда-функции и std::function.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Объясни, пожалуйста, что именно могут делегаты и не могут лямбда-функции и std::function.
std::function — не на уровне языка, поэтому не отвечают на ответ А>>>>Не хватает: А>>>>1. Делегатов на уровне языка;
Собственно и function не совсем делегат, на делегат больше похожи signals, которые ещё не std (а threadsafe версия ещё и не boost)
Здравствуйте, Alexander G, Вы писали:
RO>>Объясни, пожалуйста, что именно могут делегаты и не могут лямбда-функции и std::function. AG>std::function — не на уровне языка, поэтому не отвечают на ответ
Всётаки — зачем нужны делегаты на уровне языка? Они вообще-то не попадают в концепцию С++ой лаконичности.
Здравствуйте, remark, Вы писали:
R>Что Вам мешает в С++?
Уже было, но ещё раз: хидеры вместо нормальной модульности.
Вместе с препроцессором (а, возможно, и с помощью опций компилятора) позволяют легко сломать ODR.
Примеры:
1. Вот в либе есть класс с TCHAR содержащими структурами. Собираем либу в юникоде, используем в другой либе, уже не unicode и получаем, что классу выделено меньше памяти, чем он использует. Мемберы приватные, а экспротируются всегда-ansi строки, поэтому всё слинковалось.
2. STL у MSVC секъюрная. Допустим нам не нужен этот оверхед, и мы пишем #define _SECURE_SCL 0 в опциях проекта. Теперь если подключить собранную без этой опции библиотеку (например, что-то из буста), то часть в .lib и часть в .pch не будут соответствовать. Проблема в том, что оно скомпилится, слинкуется, и не факт что упадёт сразу.
Повторная компиляция хидеров библиотек приводит и к другим неудобствам. Например, ворнинги, которые не нужны. Библиотека уже собрана, я просто включаю её хидер и вижу ворнинги снова. Ок, отключаю прагмой вокруг инклада либы. Не отключаются, т.к. источник ворнинга не код либы а код STL. Надо ещё эту либу выше инклада STL ставить, чтобы она первая STL подключала. И тогда тот ворнинг будет отключен и у меня также.
Здравствуйте, Sergey, Вы писали:
S>Что тащить ничего не надо — это замечательно. Но вот что она S>обеспечивает такого, чего нет в винапи?
Я ее пользовал потому, что она обеспечивает несколько большее удобство чем все писать на голом WinAPI, и при этом не громоздкая и нету ничего лишнего.
Собственно ее как обертку WinAPI в шаблоны надо рассматривать.
S>IMHO, без разницы — на голом винапи писать или с WTL.
С WTL чуть чуть удобнее каркас делать. Например реализацию сплиттера на голом винапи все равно надо во что оборачивать, иначе пользовать не сильно удобно. А тут уже есть.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Sergey пишет: > > Под виндой — макросами удобнее, чем скажем перлом. Потому что перл > сначала поставить надо, потом пути настроить... >
Под виндами можно было .exe поставлять