Здравствуйте, Аноним, Вы писали:
R>>Что Вам мешает в С++?
А>Как ни парадоксално — свобода в выборе стиля. Можно писать в стиле старого доброго С, можно использовать шаблоны и прочие прелести ФП, можно ООП, можно даже автоматическое управление памятью, которое по мне так даже удобнее GC. Проблема в том что когда проект пишет сотня человек у каждого из который свое понятие "правильности" — вот это то и мешает в С++.
Вот про инлайнинг никто еще вроде не говорил. Вроде полезная вещь, но
способ ее реализации (проистекающий из принятой в С++ модели трансляции)
заслуживает всяческого порицания. На практике это приводит к тому, что в
моем текущем проекте более 90% кода в объектных файлах — это многократно
повторенные инлайн-методы (привет шаблонам). Соответственно, более 90%
времени линковки уходит на то, чтобы из нескольких гигабайт объектных
файлов сделать несколько десятков мегабайт екзешников/длл.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Roman Odaisky, Вы писали:
RO>>>1. Библиотеки. Нужны комментарии?
R>>Нужны. Желательно с учётом 2 указанных пунктов.
RO>Их нет.
Вообще-то библиотек навалом. В чём заключается претензия?
RO>>>2. IDE. Нужны комментарии?
R>>Нужны. Желательно с учётом 2 указанных пунктов.
RO>Их нет.
Здравствуйте, StevenIvanov, Вы писали:
SI>Здравствуйте, remark, Вы писали:
R>>Что Вам мешает в С++?
SI>если вкратце — отсутствие мощности и выразительности лиспа. Насколько это красивый язык — и не описать.
SI>подробнее -
SI>1) Очень высокая сложность языка. SI>следствия: SI>— сложность обучения => сложность подготовки специалистов (контрпример — тот же Lisp, который описывается несколькими предложениями и вообще прост как 3 рубля. Либо тот же VB ) SI>— сложность написания спец тулов (для С# и рефакторер нормальный есть и форматтер и дебаггер и код-эксплорер в одной IDE и еще куча всего. Для С++ тоже вроде как есть, но какое-то некрасивое все) SI>— сложность написания компилятора 100% соответствующего стандарту (только Comeau C++ 100% ISO compliant). Из за этого еще одно "под-следствие" — internal compiler error'ы Я лично сталкивался несколько раз SI>— сложность в разработке coding standards/coding practices
OK
SI>2) Устаревшая система сборки сложного проекта (#include/подключение сторонних библиотек/build проекта) — уже упоминалось. Решено в C#.
OK
SI>3) Непродуманная стандартизация. SI>— Включены малополезные вещи типа экспорта шаблонов и теневой системы типов, исключено такое, как например стандарт на манглер, что не позволяет по-человечески экспортировать класс в библиотеке, который можно использовать в проекте, собираемом другим компилятором (этой частной проблемы нет, например в C#). SI>— Можно еще много чего вспомнить, надо только вот полазить по этому форуму, но лень что-то.
По поводу манглинга имен — OK
По поводу экспорта шаблонов и теневой системы типов — а с какой периодичностью это мешает в работе — приводит к ошибкам или существенно увеличивает время разработки?
з.ы. а что такое теневая система типов?
з.з.ы. а для C# много компиляторов? Их действительно можно использовать так что одним скомпилировали, а используем с другим?
SI>4) Невозможность быстро экспортировать в С++ крупный проект на С — возникает куча утомительных ошибок с преобразованием типов и проч. Не совсем недостаток, просто drawback из-за того, что в С++ введены такие вещи, как строгая типизация
Тут непонятно. А в какой язык будет легче экспортировать крупный проект на С?
SI>5) Макросы, живущие отдельно от языка. Причина многих бед и катаклизмов Контрпример — в LISP макросы не являются злом, напротив придают языку колоссальную мощь.
Тут тоже не понятно. Если они для тебя причина постоянных бед, то зачем ты их используешь?
SI>6) По сравнению с С# нет вкусностей типа делегатов и потрясающе мощного рефлекшна.
Alexander G пишет:
> 3. Я не могу клепать формы на WTL так быстро, как это получалось в Delphi
А что, если не секрет, заставило выбрать наиболее бесполезную (ну по
крайней мере из виденных мной) оконную библиотеку? Почему бы не взять
QT, wxWidgets или MFC?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, remark, Вы писали:
R>>>>Что Вам мешает в С++?
RO>>>1. Библиотеки. Нужны комментарии?
R>>Нужны. Желательно с учётом 2 указанных пунктов.
RO>Их нет.
RO>>>2. IDE. Нужны комментарии?
R>>Нужны. Желательно с учётом 2 указанных пунктов.
RO>Их нет.
Мне кажется, что в общем случае, без каких-то либо комментариев, оба утверждения ложны...
Здравствуйте, Sergey, Вы писали:
S>remark пишет: >> *Что Вам мешает в С++?*
S>Вот про инлайнинг никто еще вроде не говорил. Вроде полезная вещь, но S>способ ее реализации (проистекающий из принятой в С++ модели трансляции) S>заслуживает всяческого порицания. На практике это приводит к тому, что в S>моем текущем проекте более 90% кода в объектных файлах — это многократно S>повторенные инлайн-методы (привет шаблонам). Соответственно, более 90% S>времени линковки уходит на то, чтобы из нескольких гигабайт объектных S>файлов сделать несколько десятков мегабайт екзешников/длл.
Не очень понятно. Моё представление о модели компиляции С++ такое, что инлайнинг — это дело исключительно компилятора. Что делает линкер с инлайнингом? И как связано с инлайнингом уменьшение размера исполняемых файлов по сравнению с объектными файлами? Не выинлайнивает же линкер функции обратно. Инлайнинг должен уменьшать нагрузку на линкер, т.к. функция фактически "растворяется" на этапе компиляции...
Здравствуйте, merk, Вы писали:
M>проблема в том, что других "промышленных" особо и нет. хотя есть языки просто красивые. например Mоdula-2.
M>недостатки с++
Хммм... я уже потерял логическую линию. Вроде как после утверждения, что других промышленных языков нет, в контексте текущего топика неминуемо должен следовать ответ "Ничего". Соотв. для меня смысл всего поста пока потерян...
M>1. совместимость с С. в С просто видна история развития и затыкание синтаксических дыр. M>например значок -> как сокращение косорукой(из-за лексики С) необходимой записи (*p).name. M>авторы С явно сначала и не думали использовать структурные типы, и видимо клепали точное подобие какого-нить ассемблера PDP-11. по крайней мере чтобы при не особосложном компиляторе получить прямое отображение С в ассемблер. хвосты автоинкрементов и автодекрементов просто торчат оттуда. там была такая мода адресации — автодекремент и автоинеркемент.
Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки?
M>2. аццки подозрительная форма записи типов. когда я переходил с модулы на с, долго не мог понять — какая вообще в С схема записи сложного типа. каша какая-то. оказалось проще. в сущности принята идиотская форма записи - M>базовый тип, использование переменной с именем name. M>int *name просто следует читать как — если взять переменную name и ее значение считать как указатель, то он будет указывать на нечто типа int. массив например int name[10] нужно читать как — если взять name c неким индексом в виде name[x] получишь int. вы чувствуете косорукость подхoда? тип в данном определении раскидан по декларации и понять что он массив, можно только после прочтения что там стоит за именем переменной? M>сравните нормальную декларацию, она должна быть локальной. M>var: ARRAY OF INT. скажите длинно? но это лишь символы. перелицуйте в такое []int. M>получится вроде M>var:[]int M>обьявление шиворот навыворот приводят к необходимости просмотра компилятором на несколько символов вперед, чтобы понять что делать ему в данном месте. M>это явно какая-то дырозатыкательная эволюция еще внутри C.
M>форма преобразования типа — (typename) var. че за конструкция? преобразование типа можно считать как вызов функции с именем типа, возвращающей значение нужного вам типа. то есть должна быть форма typename(var).
Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки?
По поводу того, что компилятору требуется просматривать на несколько символов вперёд, вообще совсем не понятно. Как это связано с вопросом?
M>3. нет четкого понятия модуля с импортом и экспортом. хидеры — чисто инклудные файлы для обработки препроцессором. препроцессирование вещь иногда необходимая, но нельзя на нее перекладывать например обьявления обычных констант. ну наконец "модули" ввели в java и c# через uses и пакеты. в C++ ввели namespace. но это не модули в нормальном понимании. В С и C++ силу излишней свободы фактически нет средства вытоматически собирать программу, поскольку вообще неясно из каких файлов она состоит! появились даже профессии писателей make файлов — ненужная профессия для нормального языка. автоматизация сборки привела к рождению аж внеязыковых специальных тулов. M>вообще по С++ проходится сам страуструп. с его советами, что не стоит делать в С++. M>ну и выкиньте это на помойку. и сделайте нормальный синтаксис. и получите нормальный язык. M>только это невыгодно промышленности. M>обрушатся мегатонны вымученных текстов на этом сверх-типо языке. а это огромные затраты.
Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки?
Здравствуйте, merk, Вы писали:
M>арзхаичная форма оператора if M>if (condition) operator M>else operator;
M>из за этого многовариантные if оказываются вложенными, возможны ошибки из за пропуска ; M>вложенные операторы с отступами не читаются и приходится их выравнивать слева, нарушая "вложенность".
M>тогда как очевидно, что if — просто форма short sircuit evaluation в булевских выражениях. M>и форма должна быть такой M>if (condition) operator M>elsif (condition) operator M>... M>else (condition) operator
Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки?
M>далее. язык то не строго типизированный! иначе в нем бы не было стольких символов разнообразных операций M>вроде логическое OR, битовое OR и так далее. M>оказывается в логическом выражении можно писать и так и так, нормальный новый компилятор даст варнинг, что мол битовая операция вместо логической — вы уверены? тогда как для логического типа применимы только логические операции. хотите битовую? преобразуйте к множеству. M>короче число операций вздуто в силу корявой типизации. унаследованной от нетипизированного всерьез С.
Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки?
постам у меня складывается впечатление, что ты отвечаешь на какой-то другой вопрос, а не на мой...
Либо это высказывания в стиле тех, что царят в Философии Программирования, типа "С++ — отстой, бла-бла-бла". Именно от таких высказываний я бы и хотел уйти в данном топике. Т.е. как часто лично тебе момент причиняет проблемы (провоцирует ошибки, увеличивает время разработки) в твоей личной повседневной практике программирования на С++? Как этот момент решён в другом языке, на котором ты потенциально мог бы программировать вместо С++, так что там бы тебе этот момент не причинял проблем?
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, remark, Вы писали:
А>>Ничего не мешает из того что есть, даже наоборот много чего не хватает
R>Отсутствие тоже вполне может мешать. Так что прошу высказываться по существу, отсутствие чего мешает, как часто, в каких языках это есть?
Не хватает:
1. Делегатов на уровне языка;
2. Полной информации о типах в runtime опционально;
3. Что то типа C++Scripts для кодогенерации и выполнения его же на лету в runtime c возможностью cross objects, то есть объявил обьект в основной проге, а в скрипте мог обратиться к нему и наоборот;
4. Сборщик мусора в принципе не нужен, от него больше проблем чем пользы;
Здравствуйте, remark, Вы писали:
R>Мне кажется, что в общем случае, без каких-то либо комментариев, оба утверждения ложны...
Конечно :-)
Библиотек, собственно, много. Наверное, больше, чем для любого другого языка. Не хватает грамотно спроектированных качественных библиотек. Почему-то C++ провоцирует библиотекописателей делать продукты, которые заставляют писать всю программу каким-то определенным способом. Например, Qt несовместима с исключениями и созданием объектов не по new. Или музеи грабель вроде упоминавшейся здесь Reason
, которые несовместимы с мозгами. То ли дело, например, в Java: все библиотеки похожи одна на другую, даже стиль оформления кода один и тот же.
IDE тоже много. Но всё равно стоит только подключить что-нибудь из Boost.MPL, и автодополнялка сдается. Вот философский такой вопрос: стоит ли включать в библиотеку фичу, которую автодополнялка гарантированно не прожует? А если только 10% пользователей используют IDE, которая с этой фичей справится?
Здравствуйте, Аноним, Вы писали:
А>Не хватает: А>1. Делегатов на уровне языка;
В C++09 будут.
А>2. Полной информации о типах в runtime опционально;
Рефлексия?
А>3. Что то типа C++Scripts для кодогенерации и выполнения его же на лету в runtime c возможностью cross objects, то есть объявил обьект в основной проге, а в скрипте мог обратиться к нему и наоборот;
Это противоречило бы принципу «плати только за то, что используешь».
А>4. Сборщик мусора в принципе не нужен, от него больше проблем чем пользы;
Я считаю, что сборка мусора правильно сделана в C++/CLI с помощью другого типа указателей и ссылок.
До последнего не верил в пирамиду Лебедева.
Re[5]: Что Вам мешает в С++?
От:
Аноним
Дата:
21.06.08 21:05
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, Аноним, Вы писали:
А>>Не хватает: А>>1. Делегатов на уровне языка; RO>В C++09 будут.
Отлично!
А>>2. Полной информации о типах в runtime опционально; RO>Рефлексия?
Да.
А>>3. Что то типа C++Scripts для кодогенерации и выполнения его же на лету в runtime c возможностью cross objects, то есть объявил обьект в основной проге, а в скрипте мог обратиться к нему и наоборот; RO>Это противоречило бы принципу «плати только за то, что используешь».
В смысле?
А>>4. Сборщик мусора в принципе не нужен, от него больше проблем чем пользы; RO>Я считаю, что сборка мусора правильно сделана в C++/CLI с помощью другого типа указателей и ссылок.
Нееет, без полной интеграции в язык неудобно. Нужно что бы из unmanaged кода было сделать managed без всякого переписывания старого кода.
Здравствуйте, Аноним, Вы писали:
А>>>Ничего не мешает из того что есть, даже наоборот много чего не хватает
R>>Отсутствие тоже вполне может мешать. Так что прошу высказываться по существу, отсутствие чего мешает, как часто, в каких языках это есть?
А>Не хватает: А>1. Делегатов на уровне языка; А>2. Полной информации о типах в runtime опционально; А>3. Что то типа C++Scripts для кодогенерации и выполнения его же на лету в runtime c возможностью cross objects, то есть объявил обьект в основной проге, а в скрипте мог обратиться к нему и наоборот;
remark пишет:
> Не очень понятно. Моё представление о модели компиляции С++ такое, что > инлайнинг — это дело исключительно компилятора.
В результате компиляции каждой единицы трансляции образуется объектный
файл. Инлайн функция должна быть определена в каждой единице трансляции,
в которой она используется. Соответственно, если она используется в 200
единицах трансляции — компилятор 200 раз сгенерирует ее тело (хотя тут,
если я не ошибаюсь, тот же MSVC умеет "халтурить") и поместит его в 200
объектников.
> Что делает линкер с инлайнингом?
Да ничего особенного — большую часть просто выкидывает. Но ему банально
приходится перелопачивать на порядки больший объем файлов, чем мне бы
хотелось.
> И как связано с инлайнингом уменьшение размера исполняемых > файлов по сравнению с объектными файлами? Не выинлайнивает же линкер > функции обратно. Инлайнинг должен уменьшать нагрузку на линкер, т.к. > функция фактически "растворяется" на этапе компиляции...
Пример из жизни — в директории debug некоего проекта 1 532 246 717 байт
объектников. Из них получается dll размером 41 693 184 байт. Линкуется
это счастье 4-5 минут. Я заглядывал в объектники дизассеблером — большую
часть занимают, как мне показалось, приготовленные к употреблению тушки
методов шаблонных классов. Реальная инлайн-подстановка делается далеко
не для всех инлайн-функций, однако все они присутствуют в десятках
объектников.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, remark, Вы писали:
R>>Мне кажется, что в общем случае, без каких-то либо комментариев, оба утверждения ложны...
RO>Конечно
RO>Библиотек, собственно, много. Наверное, больше, чем для любого другого языка. Не хватает грамотно спроектированных качественных библиотек. Почему-то C++ провоцирует библиотекописателей делать продукты, которые заставляют писать всю программу каким-то определенным способом. Например, Qt несовместима с исключениями и созданием объектов не по new. Или музеи грабель вроде упоминавшейся здесь Reason
, которые несовместимы с мозгами. То ли дело, например, в Java: все библиотеки похожи одна на другую, даже стиль оформления кода один и тот же.
Ок. Засчитывается.
Было абсолютно не понятно, что именно с библиотеками не так. В принципе я думаю, что потенциально я мог бы обосновать любую из точек (1) библиотек слишком много, (2) библиотек слишком мало, (3) библиотеки слишком простые, (4) библиотеки слишком сложные
RO>IDE тоже много. Но всё равно стоит только подключить что-нибудь из Boost.MPL, и автодополнялка сдается. Вот философский такой вопрос: стоит ли включать в библиотеку фичу, которую автодополнялка гарантированно не прожует? А если только 10% пользователей используют IDE, которая с этой фичей справится?
А неработа автодополнялки для некоторых библиотек действительно является существенной повседневной проблемой? Если да, то не вопрос. Я спорить не буду. Просто хочу отсечь утверждения типа того, что синтаксис записи массивов "int name[10] ", или что есть автодекремент и автоинеркемент. Возможно, если исписать 3 тетради математическими формулами, то действительно докажешь, что синтаксис объявления массивов очень не удачный. Но то, что это серьёзная повседневная проблема для С++ программиста, мне лично, верится с трудом.
Здравствуйте, Sergey, Вы писали:
S>remark пишет:
>> Не очень понятно. Моё представление о модели компиляции С++ такое, что >> инлайнинг — это дело исключительно компилятора.
S>В результате компиляции каждой единицы трансляции образуется объектный S>файл. Инлайн функция должна быть определена в каждой единице трансляции, S>в которой она используется. Соответственно, если она используется в 200 S>единицах трансляции — компилятор 200 раз сгенерирует ее тело (хотя тут, S>если я не ошибаюсь, тот же MSVC умеет "халтурить") и поместит его в 200 S>объектников.
А ну да, понял. Проблема, если компилятор *не* инлайнит инлайн функцию.
Особая засада для дебаг сборки, когда компилятор вообще ничего не инлайнит, просто тупо кладёт каждую функцию в каждый объектный файл.
А какой промышленный язык справляется с этой задачей лучше? Т.е. какой язык способен быстро сгенерировать эквивалент 40Мб нативного кода?
)
Контрпример — в LISP макросы не являются злом, напротив придают языку колоссальную мощь.
