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

R>Просто хочу отсечь утверждения типа того, что синтаксис записи массивов "int name[10] ", или что есть автодекремент и автоинеркемент. Возможно, если исписать 3 тетради математическими формулами, то действительно докажешь, что синтаксис объявления массивов очень не удачный. Но то, что это серьёзная повседневная проблема для С++ программиста, мне лично, верится с трудом.
+10

R>
ЗЫ: Ты хоть подытоживай периодически что именно засчитано, с краткой аннотацией.
ЗЗЫ: Флеймовый топик изначально, ИМХО...

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

R>А как часто это вызывает ошибки?
Всё реже. Но всё равно, это из тех ошибок, которые часто трудно отловить (в этом напоминают ошибки с with из Delphi).

R>'if (a = b)' ловится msvc как 'assignment inside if, don't you mean ==?'. Поэтому лично на такое давно не натыкался, хотя по привычке пишу нелепое '2 > x'
Этот ворнинг сильно помогает, однако не всегда такое inside if:

#define BOOL int
BOOL main()
{
  int a = 42, b = 18;
  return a = b;
}

Насчёт нелепого стравнения. "Антикоммутативные" сравнения < > <= и >= в антиинтуитивном порядке напрягают, однако сравнения = пишу так чтобы слева было rvalue, причём лучше если не константа, а выражение. Ну вот в примере выше и a и b — lvalue.

AG>>3. Я не могу клепать формы на WTL так быстро, как это получалось в Delphi

R>А в чём причина?

Вы Delphi не видели? Там можно накидать на форму всяких визуальных/невизуальных компонентов, настроить их свойства — и уже мышкой написан почти весь UI

VCL — это фреймворк, абстрагирущийся достаточно хорошо от неудобств WinAPI. У компонент понятный и единообразный интерфейс, например строки в листбоксе, комбобоксе и закладки табконтрола — это тот же TStrings. Кстати, наличие в языке свойств тоже способствует единобразию — не надо выдумывать соглашения насчёт геттеров/сеттеров. WTL — это продуманная, настраиваимая и расширяемая система костылей, на половину состоящая из тривиальных врапперов для винапи. Например, как закрыть диалог в винапи зависит от того модальный ли он — и WTL никак не инкаспулирует эту неприятность.
Возможно, это не аргумент, т.к. сущесвуют хорошие UI библиотеки, а я кроме WTL и MFC ничего не видел.

Вот ещё поддержка COM. Достаточно "магии" встроено в язык Delphi. Вызов QI/_AddRef/_Release автоматом без всяких CComPtr — труднее ошибится. Поддержка QI со стороны компилятора и рантайма (не нужно никаких MAP-ов). Поддержка "эксепшн файрвола" в языке (safecall). Тип Variant, позволяющий работать с IDispatch как в Visual Basic. Даже такие мелочи, как поддержка GUIDов const X: GUID = ['{7A98DA3E-2096-4894-A439-418D5C61D886}']; , а не DEFINE_GUID.
То же самое про поддержку сообщений Windows. То же самое про встроеные строки/дин. массивы/многомерные массивы.
Понятно, что это не делает язык "общим". Для более общих решений в языке есть макросы, шаблоны, классы и поддержка COM, сообщений и массивов/строк может быть сделана в библиотеках. Но "мэджики" существенно удобнее, а главное дают меньше возможности ошибиться при их применении.

remark пишет:

>> > Не очень понятно. Моё представление о модели компиляции С++ такое, что
>> > инлайнинг — это дело исключительно компилятора.
>
> S>В результате компиляции каждой единицы трансляции образуется объектный
> S>файл. Инлайн функция должна быть определена в каждой единице трансляции,
> S>в которой она используется. Соответственно, если она используется в 200
> S>единицах трансляции — компилятор 200 раз сгенерирует ее тело (хотя тут,
> S>если я не ошибаюсь, тот же MSVC умеет "халтурить") и поместит его в 200
> S>объектников.
>
> А ну да, понял. Проблема, если компилятор *не* инлайнит инлайн функцию.

Де-факто это значительная часть STL. Вообще, нужно стандартное средство
подавления неявного инстанцирования шаблонов.

> Особая засада для дебаг сборки, когда компилятор вообще ничего не
> инлайнит, просто тупо кладёт каждую функцию в каждый объектный файл.

Да, в релизе соотношение получше, но незначительно. Типа 750 Мб/25 Мб


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

Да известно какой — Паскаль. Но, там объем исходников бы в разы больше
получился, по моим прикидкам.

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

S>А что, если не секрет, заставило выбрать наиболее бесполезную (ну по
S>крайней мере из виденных мной) оконную библиотеку? Почему бы не взять
S>QT, wxWidgets или MFC?

Выбор был не мой, поинтересуюсь.
Ок, какая из названных библиотек по юзабельности сравнима или лучше VCL ?
Если есть такая, то аргумент снимается.

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

R>Что Вам мешает в С++?

Не то чтобы мешает (ибо не часто я C++ использую), но несколько пугает модель "выполнения" (я имею в виду порядок выполнения, порядок вступления в силу сайд-эффектов и т.п.) и памяти. Я понимаю, что все эти пляски с точками следования (это к модели выполнения), с volatile-членами (это к модели памяти в многопоточной среде) сделаны для того, чтобы дать больший простор для оптимизации, но модель памяти и модель выполнения в Java и C# значительно проще для освоения.

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

А>Нееет, без полной интеграции в язык неудобно. Нужно что бы из unmanaged кода было сделать managed без всякого переписывания старого кода.

Зачем? А что делать с RAII например или с явными вызовами delete?

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

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

S>>А что, если не секрет, заставило выбрать наиболее бесполезную (ну по
S>>крайней мере из виденных мной) оконную библиотеку? Почему бы не взять
S>>QT, wxWidgets или MFC?

AG>Выбор был не мой, поинтересуюсь.
AG>Ок, какая из названных библиотек по юзабельности сравнима или лучше VCL ?
AG>Если есть такая, то аргумент снимается.

.NET WinForms Да и QT рулит + кроссплатформенность

R>Честно говоря, по этому и этому

Автор: merk
Дата: 21.06.08

постам у меня складывается впечатление, что ты отвечаешь на какой-то другой вопрос, а не на мой...
R>Либо это высказывания в стиле тех, что царят в Философии Программирования, типа "С++ — отстой, бла-бла-бла". Именно от таких высказываний я бы и хотел уйти в данном топике. Т.е. как часто лично тебе момент причиняет проблемы (провоцирует ошибки, увеличивает время разработки) в твоей личной повседневной практике программирования на С++? Как этот момент решён в другом языке, на котором ты потенциально мог бы программировать вместо С++, так что там бы тебе этот момент не причинял проблем?

R>

вопрос дурацкий. можно и на ассемблере программировать без ошибок.
на самом деле излишняя широта языка приводит к разнообразному набору стилей(если это не регулируется принудительно внутренними правилами разработки в команде), отчего люди перестают друг друга понимать.
все известные правила разработки на С++ по сути сводятся к набору мер по предолению изьянов, сужению возможностей и приведению языка к некоему диалекту. если в фирме нет правил разработки — это команда начального уровня. то есть тот, кто подвергает сомнению, что у языка есть изьяны...против сужения языка и таким образом — за команды начального уровня.
далее. слишком большой набор синтаксикских правил и излишняя мощь, часто приводят
1. к трудностям реализации языка
2. к трудностям обучению языку

пункт 1 ведет к недостаточно конкуренции среди самих средств раработки(грубо говоря мало вариантов для команды в выборе средств разработки на данном языке), недостатку сопутствующих тулов, вроде анализаторов исходного кода, и прочая-прочая. если для языков более регулярных даже небольшая академическая команда может выдать набор интересных продуктов, то для с++ потребные для этого человекогоды, такому варианту не оставляют места.
сколько вообще в мире компиляторов с++? а свободных? это типа gcc? почему? насколько они зрелы и сколько уже развиваются? каков скорость роста зрелости таких продуктов, то есть насколько быстро их можно довести до ума?

отсутствие импорта вообще вопиюще.
прямая текстовая подстановка неких кусков текста, что многомудро называются заголовочными файлами приводит например к косвенной видимости ненужных в контексте компилируемого файла обьектов. при реализации же языков с модулями, видимы только обьекты прямо импортированного модуля. даже если импортированные модули видят еще что-то, этого не видно импортирующему. хочешь увидеть — прямо об этом заяви. через декларацию импорта. хочешь экспортировать что-то — прямо об этом заяви, через декларацию экспорта. и в языке не может быть средств нарушить этот контракт.
смешно! в С++ класс имеет право обьявлять public, protected, private. А набор классов, переменных, функций, типов и все такое...не имеет средств это сделать. че за ерунда???

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

условная компиляция! кто не наталкивался тут на проблемы? где-то(не пойми где, в силу косвенной видимости через инклуды) кто-то что-то написал, и черти где в коде, все стало по другому работать. во!

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

module MyModule;
specialization RulesFileA,RulesFileB...; //список файлов специализации(это откуда берутся значения для условной компиляции например)
from ModuleA import .... ; //что ипортируется из модуля ModuleA
from ModuleB import ... ;
export A,B,C,D...;

....

end SomeName //конец модуля MyModule

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

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

AG>BOOL main()
AG>{
AG> int a = 42, b = 18;
AG> return a = b;
AG>}[/ccode]

В паскале

 A := B; { операция с A.}
 Result := A = B; { выражение с A и B.}
 A = B; { не скомпилится.}
 Result := A := B; { не скомпилится.}

С путает выражение и операцию, a = b это и выражение и операция.
То же самое с ++i. В паскале если нужно увеличить Inc(i), если нужно вернуть увеличеное — Succ(i).

Причём реально применять выражение с побочными эффектами как и выражения и операции не получается:
1. обычно надо что-то одно for (size_t i = 0; i != _countof(a); ++i) // мы не хотели вернуть увеличенное i, просто надо было увеличить.
2. операции часто требуют чтобы порядок был задан. Известный баян:

int i = 5; return ++i + ++i; // 13 или 14 ? а вот UB.

3. WTF/min. Выпендриваться немотивированно нельзя.

С++ унаследовал эту проблему С. Ну и не только С++.

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

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

А>>Не хватает:
А>>1. Делегатов на уровне языка;
RO>В C++09 будут.

А>>2. Полной информации о типах в runtime опционально;
RO>Рефлексия?

А>>3. Что то типа C++Scripts для кодогенерации и выполнения его же на лету в runtime c возможностью cross objects, то есть объявил обьект в основной проге, а в скрипте мог обратиться к нему и наоборот;
RO>Это противоречило бы принципу «плати только за то, что используешь».

А>>4. Сборщик мусора в принципе не нужен, от него больше проблем чем пользы;
RO>Я считаю, что сборка мусора правильно сделана в C++/CLI с помощью другого типа указателей и ссылок.

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

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

R>Что Вам мешает в С++?

Это имеет только косвенное отношения к самому языку — небольшие (и это самое неприятное) платформозависимые отличия в реализации, причём эти отличия норовят проявиться в основном в не совсем тривиальном коде (это касается как чистого языка, так и stl).
Ещё смущает (именно так — это расплата за тот самый принцип оплаты только за то, что нужно) наличие некоторого количества библиотек с перекрывающейся функциональностью (вот, например, почему libpthread и libthr по-разному ведут себя при fork'е? а уж про какие-нибудь корутины и вообще страшно говорить)

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

Хотя ++i не по теме — он ни разу не навредил мне.
А вот с a = b вместо a == b бывало.

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

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

А>>>>Ничего не мешает из того что есть, даже наоборот много чего не хватает

R>>>Отсутствие тоже вполне может мешать. Так что прошу высказываться по существу, отсутствие чего мешает, как часто, в каких языках это есть?

А>>Не хватает:
А>>1. Делегатов на уровне языка;
А>>2. Полной информации о типах в runtime опционально;
А>>3. Что то типа C++Scripts для кодогенерации и выполнения его же на лету в runtime c возможностью cross objects, то есть объявил обьект в основной проге, а в скрипте мог обратиться к нему и наоборот;

R>Ок. Засчитывается.

R>

а функциональный тип или тип — метод не спасут отца русской демократии.
от делегатов первой государственной думы?

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

SI>— Включены малополезные вещи типа экспорта шаблонов и теневой системы типов, исключено такое, как например стандарт на манглер, что не позволяет по-человечески экспортировать класс в библиотеке, который можно использовать в проекте, собираемом другим компилятором (этой частной проблемы нет, например в C#).
SI>— Можно еще много чего вспомнить, надо только вот полазить по этому форуму, но лень что-то.

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

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

Немного отклонюсь от темы, и приведу то, что немного мешает:
1. Отсутствие стандартного типа строки. Я знаю про stl, но практически каждая крупная библиотека имеет свой тип строки, который лучше использовать при её использовании (большинство функций используют либо строки своего формата, либо Си-шные строки). Т.е. std::string стандартная только на бумаге.

2. Работа с памятью. Создание\Удаление небольших объектов в С++ неэффективно. При этом можно сделать настроить операторы new\delete для своих нужд. Но сделать это достаточно сложно, есть множество ограничений, в итоге — чтобы включить какую-то свою стратегию — нужно переписать множества кода.

3. Препроцессор. Сильно не нравится, источник ошибок, но к сожалению не всё можно сделать без него. inline, шаблоны, константы сильно улучшают ситуацию, но не решают проблему полностью.
В идеале — нужно полностью заменить препроцессор другими более безопасными средствами.

4. отсутствие в стандартной библиотеке множества интеллектуальных указателей на все случаи жизни. auto_ptr явно недостаточно. Хотя вроде эту проблему в скором времени должны решить.

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

6. Слишком здоровый стандарт. На рсдн иногда появляются некоторые вопросы, которые вроде бы и знаешь, а почитав ответы, узнаёшь, что сильно заблуждался.

Alexander G пишет:

> S>А что, если не секрет, заставило выбрать наиболее бесполезную (ну по
> S>крайней мере из виденных мной) оконную библиотеку? Почему бы не взять
> S>QT, wxWidgets или MFC?
>
> Выбор был не мой, поинтересуюсь.
> Ок, какая из названных библиотек по юзабельности сравнима или лучше VCL ?

Не знаю, я с VCL более 10 лет назад работал, не слишком много, и особо
ей не впечатлился.

> Если есть такая, то аргумент снимается.

Да не, меня просто выбор именно WTL удивил. ATL то понятно зачем нужна,
а вот с какой целью изготовили похожую на нее WTL и, особенно, почему
люди ей пользуются — для меня загадка.

Все уже сказано. Подчекрнуть хочется именно то, что C++ имеет удручающее наследие от СИ.
Язык слишком сложный, — это главный недостаток, контекстно-зависимость толкования,
многообразность выразить одно и то же.
К языку не относится, но является следствием вышесказанного, — это
несовместимость библиотек, компиляторов в отношении одного и того же
исходного кода. Какие муки мы принимаем из-за этого — известно.
Так что, желающим упростить язык, и как следствие — облегчить разработку,
есть широкое поле для деятельности. Но ребенок-то уже родился, придется любить его
такого как есть, слишком сложного и порой — непредсказуемого.

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

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

А>>Не хватает:
А>>1. Делегатов на уровне языка;
RO>В C++09 будут.

Да ? Покажите пропозл.
Я не особо слежу, но насколько я помню, там только сделают boost::function как std::function (ну так это не "на уровне языка") и добавят лямбды в язык, с помощью которых эмулировать замыкания в С++ будет легче чем сейчас (это утилита для делегатов но не сами делегаты).

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

S>а вот с какой целью изготовили похожую на нее WTL и, особенно, почему
S>люди ей пользуются — для меня загадка.
WTL ИМХО больше на MFC похожа.
Пользуются потому, что удобнее чем MFC.
Не требует ничего тащить с программой — никаких dependencies.

Sergey пишет:

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

A из–за чего? Отсутствие шаблонов?

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