alzt пишет:
>
> 3. Препроцессор. Сильно не нравится, источник ошибок, но к сожалению не
> всё можно сделать без него.

Мне кажется, проблема не в самом языке, а в менталитете и в средах
разработки. В мире C++ автоматически генерируемые исходники — это нечто
неординарное. А среды разработки, как правило, не Makefile-based, и в
них не пропишешь, что часть файлов генерится из других. Плоские проекты.
Сейчас вроде получше стало, но уже поздно. Разрабы библиотек считают,
что либо всё нестандартное должно делаться макросами, либо никак. В
итоге макросы есть в Qt, есть в wx, есть в ATL.

--
ISO/IEC 8652:1995/Amd 1:2007

Здравствуйте, remark, Вы писали:

R>Тут непонятно. А в какой язык будет легче экспортировать крупный проект на С?

На Objective-C

Здравствуйте, 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>По поводу делегатов — не соглашусь.

почему?

Здравствуйте, 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.

OCTAGRAM пишет:

>> > А какой промышленный язык справляется с этой задачей лучше? Т.е. какой
>> > язык способен быстро сгенерировать эквивалент 40Мб нативного кода?
>>
>> Да известно какой — Паскаль. Но, там объем исходников бы в разы больше
>> получился, по моим прикидкам.
>
> A из–за чего? Отсутствие шаблонов?

Да, в основном. Хотя begin Тоже свою лепту бы внес

Здравствуйте, 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.

Здравствуйте, remark, Вы писали:

R>А какой промышленный язык справляется с этой задачей лучше? Т.е. какой язык способен быстро сгенерировать эквивалент 40Мб нативного кода?

Кроме паскалеобразных еще Objective-C.
А не майнстримных вообще полно.

Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, Аноним, Вы писали:

А>>1. Делегатов на уровне языка;
NBN>А зачем они на уровне языка?

Наглядность + не нужно возни с шаблонными параметрами как сейчас

class A
{
private:
   long value;

public:
   A():value(0);

   void MyFunction1(long pValue){ value = pValue; };
   void MyFunction2(long pValue){ value -= pValue; };

   virtual ~A();
};

A* _a = new A();

public delegate void MyDelegate(long pValue);

MyDelegate* _delegate_ptr = 0;

_delegate_ptr = new MyDelegate(_a, A::&MyFunction1); 

*_delegate_ptr(100);

_delegate_ptr += new MyDelegate(_a, A::&MyFunction2);

*_delegate_ptr(1);

_delegate_ptr -= new MyDelegate(_a, A::&MyFunction1); 
 
*_delegate_ptr(10);

_delegate_ptr->Invoke(10);

delete _a;

Здравствуйте, 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 — не на уровне языка, поэтому не отвечают на ответ

Всётаки — зачем нужны делегаты на уровне языка? Они вообще-то не попадают в концепцию С++ой лаконичности.

Здравствуйте, NikeByNike, Вы писали:

NBN>Всётаки — зачем нужны делегаты на уровне языка? Они вообще-то не попадают в концепцию С++ой лаконичности.

Делегаты на уровне языка может и не нужны, но лямбда функции на этом уровне не помешали бы, так же как строки и динамические массивы.

Здравствуйте, NikeByNike, Вы писали:

NBN>Всётаки — зачем нужны делегаты на уровне языка?

Мне не нужны, кому нужны ответил здесь

Автор:
Дата: 22.06.08

Здравствуйте, 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 чуть чуть удобнее каркас делать. Например реализацию сплиттера на голом винапи все равно надо во что оборачивать, иначе пользовать не сильно удобно. А тут уже есть.

Sergey пишет:
>
> Под виндой — макросами удобнее, чем скажем перлом. Потому что перл
> сначала поставить надо, потом пути настроить...
>
Под виндами можно было .exe поставлять

--
ISO/IEC 8652:1995/Amd 1:2007