Обилием костылей, отсутствием базового класса, разношерстными строками, хидерами.
(а Дельфийский принцып объявления объектов в interface и initialization даже удобнее, чем объявление не отходя от кассы типа C#, т.к. все автоматизировано горячими клавишами)

Asteroid ©   (28.08.08 20:54) [31]
Отсутствием аналога "function of object",
В Managed c++, вроде, есть такое.

> GrayFace ©   (28.08.08 23:39) [40]


см. СBuilder.

> Чем вам лично не нравится CPP?


> XentaAbsenta ©   (28.08.08 17:55) [4]
>
> тьфу блин... я рассчитывал увидеть конкретные вещи, а не
> начинать новую священную войну.
>

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

> Германн  (29.08.2008 1:26:42)  [42]

> есть понятие "кривой". Но уж С++ сделан точно не на коленке.

Но кривой.

> oxffff ©   (28.08.08 23:32) [39]

:)
Фишка вот в чём - я, собственно, С++ программист. С++ сейчас - этой мой основной инструмент (в загашнике у меня ещё есть Дельфя и Шарп). Так что я могу долго распространяться о свойстах этого языка, его недостатках и достоинствах. Мастер должен знать свой инструмент :)

XentaAbsenta ©   (28.08.08 18:43) [14]
#define abstract
#define TVariant
Так можно весь VCL переписать ))

subj
Непривычность, а так язык как язык.

Чем вам не нравится delphi ?

Букв в название мало.

> Зависит от порядка вычисления выражений (аргументов при
> вызове функции), а он стандартом языка не регламентирован.
>

- это как это? Во первых соглашение о вызовах указывается в опциях командной строке(настройках проектах) - которые являются неотделимой частью проекта, во вторых явный квалификатор (Ms - __declspec())...
> 1. Вычисляется значение ВТОРОГО аргумента. Оно будет равно 1.
> 2. Переменная i УЖЕ использована (для вычисления значения второго аргумента) и поэтому будет инкрементирована СРАЗУ после вычисления выражения.
> 3. Первый аргумент получится равным 2.
> 4. Результат будет равен 1.
>

- а вот тут начинается бардак, потому как в Ms VC(как минимум с VC6) все пост..кременты - выносятся за выражение наглухо...


- выродится в



долго я глюк ловил с подобной конструкцией:


только что проверил(MsVC 2008 Express):


c оптимизацией, вырождается в

> Чем вам не нравится delphi ?


Говорю про семёрку, ибо более поздние не щупал:

1. Нет множественного наследования и шаблонов.
2. Нет статических и автоматических объектов. Идиома RAII не применима.
(Тончее применима, но через извраты с интервейсами).
3. Нет reflection.
4. Нет лямбд.
5. Нет метапрограммирования.

Синтаксис и прочее - фигня, дело привычки.

> han_malign ©   (29.08.08 10:39) [48]

Приводимые тобой выражения не корректны с точки зрения стандарта С++.
Легально только ОДНО изменение состояния объекта между двумя точками следования. А в простом выражении таких точки две - до и после.
Если же ты нарушаешь это правило, то можешь ловить UB и ругать злые компиляторы. Стандарт надо знать :)

> 1. Нет множественного наследования и шаблонов.
> 2. Нет статических и автоматических объектов. Идиома RAII
> не применима.
> (Тончее применима, но через извраты с интервейсами).
> 3. Нет reflection.
> 4. Нет лямбд.
> 5. Нет метапрограммирования.


И нахрен это все простому народу надо ?

Желательно с показательным примером, чтобы те, у кого в их используемом языке нету лямбд и идиом RAII сразу могли посыпать голову пеплом и сожалеть о том, что всю жизнь жили напрасно.
Я серьезно - пример желателен из реальной жизни, с постановкой задачи и реализацией ее с помощью метапрограммирования, шаблонов, reflection всяких и т.п., причем, желательно, чтобы вся эта хрень использовалась так, чтобы было ясно, что без нее решение получается кривым и уродливым, а вот с ней - ну все кульно и рульно.

А то развели creeping featurism и пальцы гнут, панимаешь

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

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

По начальному сабжу - до сих пор не могу понять какого хрена приоритет побитовых операции ниже логических - оно ж в таком порядке никуда, никак и никаким боком...
классика - (2 & dw == 2)
- хорошо хоть ругается...

А вообще по поводу языков я склонен к той банальной мысли, что универсальных языков не только нет, но и быть не может.

Если на кону стоит производительность, то я предпочту либо delphi с inline-ами, либо чистый C, (точнее ограниченное подмножество, которое я называю C++ с классами). Тут сказывается тот факт, что C++ является наследником C. Почему я не использую высокоуровневые средства вроде перегрузки операций? Потому что потом приходится все равно выполнять работу компилятора и смотреть, а в состоянии ли компилятор раскрутить это выражение так, как я хочу. Получается что писать меньше, но проще написать лишние пару строчек чтобы ясно выразить свои намерения.

Если на кону стоит ООП архитектура, я выберу какой-нить скриптовый язык вроде Python. При этом если надо будет добавить новый атрибут, я не буду ломать себе голову над тем, в какое место в иерархии его надо воткнуть. Ну и вообще утиный полиморфизм гибче. Получение метаинформации про тип проще.

Если у меня будут математические вычисления, я возьму MATLAB. Никакая перегрузка операторов C++ не обеспечит мне настолько удобный синтаксис для операций с матрицами.

В случае, когда выполнить, проверить и протестировать большую части кода проблематично, я выберу что-нить вроде Delphi или Ada.

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

Вот, например, XML. Универсальное средство представления. Но текстовый DFM выглядит намного читабельнее. А если представить, как в XML будет представлена математическая формула, то волосы встают дыбом: TeX (LaTeX) намного приятнее в этом плане.

> han_malign ©   (29.08.08 11:44) [52]

Спорить не буду. Чем больше компилятор выдаёт варнингов - тем лучше.

> Чем больше компилятор выдаёт варнингов - тем лучше.

О! Тогда параноидальный режим выдачи предупреждений в gcc для тебя :)

> Игорь Шевченко ©   (29.08.08 11:19) [51]
> И нахрен это все простому народу надо ?

Простому народу это нужно.
Особенно учитывая, что я не занимаюсь чистым ООП, а больше склоняюсь к функциональному стилю с элементами ООП (или ООП с большой долей ФП).

> > 1. Нет множественного наследования и шаблонов.
Множественное наследование и шаблоны позволяют делать очень красивые с лаконичные решения.
Пример: недавно рефакторил большую бибилотеку в которой было дохрена функций вида "ConvertXIdToYId". Например, строковый идентификатор файловой системы в численный, да ещё в численный по двум разным системам идентификации. Плюс к этому ещё "GetReadableNameFor", а потом "GetMaxLabelLengthFor" и т.п.
Родилась идея - организовать справочные таблицы по этим данным. Таблицы на основе статических массивов. Фукнция выборки - 8 строк шаблонного кода.
Без шаблонов пришлось бы на КАЖДУЮ таблицу писать свои функции и смысла не было бы. А так - сократил код почти в 3 раза, да ещё убрал кучу несоответсвий между разнонаправленными функциями конверсии.
Это за шаблоны.

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

> > 2. Нет статических и автоматических объектов. Идиома RAII
> > не применима.
В языках без GC подобная идиома РЕЗКО сокращает количество утечек памяти.
Очень удобно для управления примитивами синхронизации. Настолько распространено в реальной жизни, что конкретные примеры приводить не буду.
В C#, языке с GC, кстати, идиома RAII тоже никуда не делась, только она там реализуется через специальную конструкцию языка. Использование внешних ресурсов, которые требуют явного закрытия, не может быть привязано к времени жизни объектов, ибо сборщик мусора ничего не гарантирует. Для таких объектов ввели спец. интерфейс IDisposable с методом Dispose. Т.е. сборщик мусора - это хорошо, но ЭТОТ мусор уберите за собой сами. Уборка "самим" показалась неудобной и ввели конструкцию using() {} - частный случай RAII.

> > (Тончее применима, но через извраты с интервейсами).
> > 3. Нет reflection.
> > 5. Нет метапрограммирования.
Пример из реального проекта - пишут наши хлопцы сериализатор. Что бы данные между процессами кидать. А как сериализовать структуру, если нет доступа к её метаинформации? Ответ - писать код сериализации/десериализации ручками. Муторно, громоздко, подвержено ошибкам. Наши пошли по другому пути - забабахали свой вариант IDL с кодогенератором. Т.е. реализовали свой вариант метаданных и метапрограммирования. Тока вариант не очень хороший и завязанный на использование в сборке нестандартных тулзов. А это минус. И мучаемся мы сейчас с их решениями, поскольку вынуждены сами синхронизировать описания в IDL и объявления в заголовках.  Было бы реализовано в самом языке - было бы гораздо лучше.

> > 4. Нет лямбд.
Лямбы + замыкания в С++ были бы ОЧЕНЬ ХОРОШИМ синтаксическим сахаром для написания классов-функторов, которые уже используются очень широко. Собственно, начиная с STL. Т.е. лямбы по сути уже используются, но как смоделированное программистом свойство, а не поддерживаемое языком напрямую.

Вот примеры из реальной жизни.

> О! Тогда параноидальный режим выдачи предупреждений в gcc
> для тебя :)

Типа того :)

Alkid ©   (29.08.08 12:14) [56]

Как я пишу на Delphi без всех этих синтаксических сахаров - ума не приложу. И вроде оно без ошибок получается.

> > > (Тончее применима, но через извраты с интервейсами).
>
> > > 3. Нет reflection.
> > > 5. Нет метапрограммирования.
> Пример из реального проекта - пишут наши хлопцы сериализатор.
>  Что бы данные между процессами кидать. А как сериализовать
> структуру, если нет доступа к её метаинформации? ...


А зачем структуру? Наследуем класс от TPersistent и сериализуем. Есть RTTI. Сериализация уже есть в VCL.