Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
Что Вам мешает в С++?
Моменты можно приводить любые от ядра языка и до инструментальных средств, но при этом накладываются следующие ограничения:
1. Мешать это должно регулярно. Т.к. если это мешает эпизодически, например, раз в год, то это не интересно, т.к. раз в год можно и потерпеть, и на общей эффективности разработки это не сказывается.
2. Это должно быть решено в других промышленных языках. Т.к. если это не решено хотя бы в одном другом промышленном языке, то это не интересно, т.к. это не проблема С++, а просто общая проблема. Если не очевидно, то желательно указывать языки, в которых это решено.
Ответ "Ничего" тоже принимается, что бы можно было получить более точную количественную характеристику. Но тут надо учитывать следующий момент. Что бы дать ответ "Ничего", надо быть знакомым с другими промышленными языками, дабы это не был ответ "Ничего, т.к. я просто не знаю, как бывает".
R>Что Вам мешает в С++?
Как ни парадоксално — свобода в выборе стиля. Можно писать в стиле старого доброго С, можно использовать шаблоны и прочие прелести ФП, можно ООП, можно даже автоматическое управление памятью, которое по мне так даже удобнее GC. Проблема в том что когда проект пишет сотня человек у каждого из который свое понятие "правильности" — вот это то и мешает в С++.
Есть большой опыт работы на Java, C#, Fotran, Algol, PL/1 и еще много чего было.
Язык программирование выбираю по обстоятельствам (задача, среда, ОС, условия, время написания, доп. требования заказчика и т.д и т.п). Или мне его уже выбрали.
А еще эти две проблемы взаимосвязаны, т. к. разработчики библиотек избегают использования некоторых фич, вроде макросов и метапрограммирования, потому что юзеры-индусы, не получая поддержки от IDE, не осилят такую библиотеку. А можно было бы сделать много интересного, включая рефлексию и обнаружение циклических ссылок.
Здравствуйте, remark, Вы писали:
R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>Что Вам мешает в С++?
R>Моменты можно приводить любые от ядра языка и до инструментальных средств, но при этом накладываются следующие ограничения: R>1. Мешать это должно регулярно. Т.к. если это мешает эпизодически, например, раз в год, то это не интересно, т.к. раз в год можно и потерпеть, и на общей эффективности разработки это не сказывается. R>2. Это должно быть решено в других промышленных языках. Т.к. если это не решено хотя бы в одном другом промышленном языке, то это не интересно, т.к. это не проблема С++, а просто общая проблема. Если не очевидно, то желательно указывать языки, в которых это решено.
R>Ответ "Ничего" тоже принимается, что бы можно было получить более точную количественную характеристику. Но тут надо учитывать следующий момент. Что бы дать ответ "Ничего", надо быть знакомым с другими промышленными языками, дабы это не был ответ "Ничего, т.к. я просто не знаю, как бывает".
R>
проблема в том, что других "промышленных" особо и нет. хотя есть языки просто красивые. например Mоdula-2.
недостатки с++
1. совместимость с С. в С просто видна история развития и затыкание синтаксических дыр.
например значок -> как сокращение косорукой(из-за лексики С) необходимой записи (*p).name.
авторы С явно сначала и не думали использовать структурные типы, и видимо клепали точное подобие какого-нить ассемблера PDP-11. по крайней мере чтобы при не особосложном компиляторе получить прямое отображение С в ассемблер. хвосты автоинкрементов и автодекрементов просто торчат оттуда. там была такая мода адресации — автодекремент и автоинеркемент.
2. аццки подозрительная форма записи типов. когда я переходил с модулы на с, долго не мог понять — какая вообще в С схема записи сложного типа. каша какая-то. оказалось проще. в сущности принята идиотская форма записи —
базовый тип, использование переменной с именем name.
int *name просто следует читать как — если взять переменную name и ее значение считать как указатель, то он будет указывать на нечто типа int. массив например int name[10] нужно читать как — если взять name c неким индексом в виде name[x] получишь int. вы чувствуете косорукость подхoда? тип в данном определении раскидан по декларации и понять что он массив, можно только после прочтения что там стоит за именем переменной?
сравните нормальную декларацию, она должна быть локальной.
var: ARRAY OF INT. скажите длинно? но это лишь символы. перелицуйте в такое []int.
получится вроде
var:[]int
обьявление шиворот навыворот приводят к необходимости просмотра компилятором на несколько символов вперед, чтобы понять что делать ему в данном месте.
это явно какая-то дырозатыкательная эволюция еще внутри C.
форма преобразования типа — (typename) var. че за конструкция? преобразование типа можно считать как вызов функции с именем типа, возвращающей значение нужного вам типа. то есть должна быть форма typename(var).
3. нет четкого понятия модуля с импортом и экспортом. хидеры — чисто инклудные файлы для обработки препроцессором. препроцессирование вещь иногда необходимая, но нельзя на нее перекладывать например обьявления обычных констант. ну наконец "модули" ввели в java и c# через uses и пакеты. в C++ ввели namespace. но это не модули в нормальном понимании. В С и C++ силу излишней свободы фактически нет средства вытоматически собирать программу, поскольку вообще неясно из каких файлов она состоит! появились даже профессии писателей make файлов — ненужная профессия для нормального языка. автоматизация сборки привела к рождению аж внеязыковых специальных тулов.
вообще по С++ проходится сам страуструп. с его советами, что не стоит делать в С++.
ну и выкиньте это на помойку. и сделайте нормальный синтаксис. и получите нормальный язык.
только это невыгодно промышленности.
обрушатся мегатонны вымученных текстов на этом сверх-типо языке. а это огромные затраты.
Re[2]: Что Вам мешает в С++?
От:
Аноним
Дата:
21.06.08 16:48
Оценка:
Здравствуйте, merk, Вы писали:
M>форма преобразования типа — (typename) var. че за конструкция? преобразование типа можно считать как вызов функции с именем типа, возвращающей значение нужного вам типа. то есть должна быть форма typename(var).
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, merk, Вы писали:
M>>форма преобразования типа — (typename) var. че за конструкция? преобразование типа можно считать как вызов функции с именем типа, возвращающей значение нужного вам типа. то есть должна быть форма typename(var).
А>Так ведь есть такая форма. А>
А>int i = int(1.2);
А>
и что? для любой фичи должно быть четкое обоснование. поскольку любая возможность в языке ложится в стандарт и код компилятора. ну написшите еще 8 способов записи преобразования и обьявите это свободой. потом ищите компилятор соответсвующий стандарту.
арзхаичная форма оператора if
if (condition) operator
else operator;
из за этого многовариантные if оказываются вложенными, возможны ошибки из за пропуска ;
вложенные операторы с отступами не читаются и приходится их выравнивать слева, нарушая "вложенность".
тогда как очевидно, что if — просто форма short sircuit evaluation в булевских выражениях.
и форма должна быть такой
if (condition) operator
elsif (condition) operator
...
else (condition) operator
далее. язык то не строго типизированный! иначе в нем бы не было стольких символов разнообразных операций
вроде логическое OR, битовое OR и так далее.
оказывается в логическом выражении можно писать и так и так, нормальный новый компилятор даст варнинг, что мол битовая операция вместо логической — вы уверены? тогда как для логического типа применимы только логические операции. хотите битовую? преобразуйте к множеству.
короче число операций вздуто в силу корявой типизации. унаследованной от нетипизированного всерьез С.
Но нужно обязательно оговорится, что пока лучше, чем C++ для себя я пока не нашел. Хотя ближе всего к тому, что хотелось бы -- Eiffel. Еще бы найти время на Ada2005 посмотреть
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Что Вам мешает в С++?
От:
Аноним
Дата:
21.06.08 18:13
Оценка:
Здравствуйте, eao197, Вы писали:
E>Но нужно обязательно оговорится, что пока лучше, чем C++ для себя я пока не нашел. Хотя ближе всего к тому, что хотелось бы -- Eiffel. Еще бы найти время на Ada2005 посмотреть
E>Во-вторых, не верится, что в обычных условиях программирование без побочных эффектов может быть эффективным. Например, в разработанном мной SMS-шлюзе используются списки транзакций. При возникновении каких-то событий эти списки или элементы этих списков модифицируются. Программирование без побочных эффектов подразумевает, что при каждой модификации нужно получать новую копию списка. Но как это может быть эффективно для списков, содержащих тысячи, а то и десятки тысяч элементов, и обновляются они сотни раз в секунду?
Здравствуйте, remark, Вы писали:
R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>Что Вам мешает в С++?
Я начинал с Delphi, поэтому что мешает:
1. Отуствие finally. Да, я в курсе про RAII, смарт-поинтеры в т.ч. с кастомными деаллокаторами и скоп гарды. Но меня не устраивает навязывание ООП здесь. Выходит, что С++ не поддершивает стиль старого дорбого С (хотя вроде как пытается поддерживать и С и ООП и даже ФП). Сюда же то, что деструктор не вызовется для недоделаных объектов (в Delphi — вызовется), что требует не только помещать ресурсы в классы, но и помещать кажды ресурс в свой класс. If I hear the phrase``everything is an object'' once more, I think I will scream.
2. Наследие С. Выражается в недостаточной типизации. Пример: '\0' NULL и 0 — совместимы, причём последние 2 вообще одно и то же. В паскале nil 0 и #0 компилятор не даст попутать if (p) p = 0 /* я пропустил * перед p но компилятор не проглотил, т.к. nil и 0 одно и то же */. Также в С путают указатель с массивом. И выражение с операцией. Возможностью написать короче пользоваться не приходится, т.к. требуется написать понятнее, но ошибки типа if (a = b) сделать всё равно можно.
3. Я не могу клепать формы на WTL так быстро, как это получалось в Delphi
Здравствуйте, Roman Odaisky, Вы писали:
RO>А еще эти две проблемы взаимосвязаны, т. к. разработчики библиотек избегают использования некоторых фич, вроде макросов и метапрограммирования, потому что юзеры-индусы, не получая поддержки от IDE, не осилят такую библиотеку. А можно было бы сделать много интересного, включая рефлексию и обнаружение циклических ссылок.
Тут не очень понятно. Можешь это явно связать с вопросом.
RO>(Например, можно было бы из кода
merk пишет:
> 2. аццки подозрительная форма записи типов. когда я переходил с модулы > на с, долго не мог понять — какая вообще в С схема записи сложного типа. > каша какая-то. оказалось проще. в сущности принята идиотская форма записи — > базовый тип, использование переменной с именем name. > int *name просто следует читать как — если взять переменную name и ее > значение считать как указатель, то он будет указывать на нечто типа int. > массив например int name[10] нужно читать как — если взять name c неким > индексом в виде name[x] получишь int. вы чувствуете косорукость подхoда?
BiDi, но не Юникод Говорят, дизайнеры этих языков не только писали в
разные стороны, но и думали таким же образом.
> тип в данном определении раскидан по декларации и понять что он массив, > можно только после прочтения что там стоит за именем переменной? > сравните нормальную декларацию, она должна быть локальной. > var: ARRAY OF INT. скажите длинно? но это лишь символы. перелицуйте в > такое []int. > получится вроде > var:[]int
> обьявление шиворот навыворот приводят к необходимости просмотра > компилятором на несколько символов вперед, чтобы понять что делать ему в > данном месте.
Парсер там в том числе на семантику идентификаторов завязан. Самое
обидное, что хедеры в–основном, для этих языков. Вот любой другой язык
какой ни возьми, биндиться к нему 90 против 10 будет одно удовольствие.
Ан нет, по закону подлости нужно нырять именно в это болото.
Здравствуйте, remark, Вы писали:
R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>Что Вам мешает в С++?
отсутствие мощности и выразительности лиспа. Насколько это красивый язык — и не описать.
Если сравнивать с другими императивными языками —
1) Очень высокая сложность языка.
следствия:
— сложность обучения => сложность подготовки специалистов (контрпример — тот же Lisp, который описывается несколькими предложениями и вообще прост как 3 рубля. Либо тот же VB )
— сложность написания спец тулов (для С# и рефакторер нормальный есть и форматтер и дебаггер и еще куча всего. Для С++ тоже вроде как есть, но какое-то некрасивое все)
— сложность написания компилятора 100% соответствующего стандарту (только Comeau C++ 100% ISO compliant). Из за этого еще одно "под-следствие" — internal compiler error'ы Я лично сталкивался несколько раз
— сложность в разработке coding standards/coding practices
2) Устаревшая система сборки сложного проекта (#include/подключение сторонних библиотек/build проекта) — уже упоминалось. Решено в C#.
3) Непродуманная стандартизация.
— Включены малополезные вещи типа экспорта шаблонов и теневой системы типов, исключено такое, как например стандарт на манглер, что не позволяет по-человечески экспортировать класс в библиотеке, который можно использовать в проекте, собираемом другим компилятором (этой частной проблемы нет, например в C#).
— Можно еще много чего вспомнить, надо только вот полазить по этому форуму, но лень что-то.
4) Невозможность быстро экспортировать в С++ крупный проект на С — возникает куча утомительных ошибок с преобразованием типов и проч. Не совсем недостаток, просто drawback из-за того, что в С++ введены такие вещи, как строгая типизация
5) Макросы, живущие отдельно от языка. Причина многих бед и катаклизмов Контрпример — в LISP макросы не являются злом, напротив придают языку колоссальную мощь.
Здравствуйте, remark, Вы писали:
R>Что Вам мешает в С++?
если вкратце — отсутствие мощности и выразительности лиспа. Насколько это красивый язык — и не описать.
подробнее —
1) Очень высокая сложность языка.
следствия:
— сложность обучения => сложность подготовки специалистов (контрпример — тот же Lisp, который описывается несколькими предложениями и вообще прост как 3 рубля. Либо тот же VB )
— сложность написания спец тулов (для С# и рефакторер нормальный есть и форматтер и дебаггер и код-эксплорер в одной IDE и еще куча всего. Для С++ тоже вроде как есть, но какое-то некрасивое все)
— сложность написания компилятора 100% соответствующего стандарту (только Comeau C++ 100% ISO compliant). Из за этого еще одно "под-следствие" — internal compiler error'ы Я лично сталкивался несколько раз
— сложность в разработке coding standards/coding practices
2) Устаревшая система сборки сложного проекта (#include/подключение сторонних библиотек/build проекта) — уже упоминалось. Решено в C#.
3) Непродуманная стандартизация.
— Включены малополезные вещи типа экспорта шаблонов и теневой системы типов, исключено такое, как например стандарт на манглер, что не позволяет по-человечески экспортировать класс в библиотеке, который можно использовать в проекте, собираемом другим компилятором (этой частной проблемы нет, например в C#).
— Можно еще много чего вспомнить, надо только вот полазить по этому форуму, но лень что-то.
4) Невозможность быстро экспортировать в С++ крупный проект на С — возникает куча утомительных ошибок с преобразованием типов и проч. Не совсем недостаток, просто drawback из-за того, что в С++ введены такие вещи, как строгая типизация
5) Макросы, живущие отдельно от языка. Причина многих бед и катаклизмов Контрпример — в LISP макросы не являются злом, напротив придают языку колоссальную мощь.
6) По сравнению с С# нет вкусностей типа делегатов и потрясающе мощного рефлекшна.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Что Вам мешает в С++?
E>Позволю себе дать ссылку на самого себя: E>Что не так с C++ E>Почему я ищу новый язык?
[Оффтоп]
То, что в Ruby пишется так:
a = [ ... ]
b = []
c = []
a.each do |item|
if item > 0
b << item
else
c << item
end
end
Здравствуйте, Alexander G, Вы писали:
AG>Здравствуйте, remark, Вы писали:
R>>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>>Что Вам мешает в С++?
AG>Я начинал с Delphi, поэтому что мешает:
AG>1. Отуствие finally. Да, я в курсе про RAII, смарт-поинтеры в т.ч. с кастомными деаллокаторами и скоп гарды. Но меня не устраивает навязывание ООП здесь. Выходит, что С++ не поддершивает стиль старого дорбого С (хотя вроде как пытается поддерживать и С и ООП и даже ФП). Сюда же то, что деструктор не вызовется для недоделаных объектов (в Delphi — вызовется), что требует не только помещать ресурсы в классы, но и помещать кажды ресурс в свой класс. If I hear the phrase``everything is an object'' once more, I think I will scream.
Ок. Принимается.
AG>2. Наследие С. Выражается в недостаточной типизации. Пример: '\0' NULL и 0 — совместимы, причём последние 2 вообще одно и то же. В паскале nil 0 и #0 компилятор не даст попутать if (p) p = 0 /* я пропустил * перед p но компилятор не проглотил, т.к. nil и 0 одно и то же */. Также в С путают указатель с массивом. И выражение с операцией. Возможностью написать короче пользоваться не приходится, т.к. требуется написать понятнее, но ошибки типа if (a = b) сделать всё равно можно.
А как часто это вызывает ошибки?
'if (a = b)' ловится msvc как 'assignment inside if, don't you mean ==?'. Поэтому лично на такое давно не натыкался, хотя по привычке пишу нелепое '2 > x'
А вот 'p = 0' вместо '*p = 0' наверное в С++ действительно невозможно отловить...
AG>3. Я не могу клепать формы на WTL так быстро, как это получалось в Delphi
Здравствуйте, Аноним, Вы писали:
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Мб нативного кода?
Здравствуйте, remark, Вы писали:
R>Просто хочу отсечь утверждения типа того, что синтаксис записи массивов "int name[10] ", или что есть автодекремент и автоинеркемент. Возможно, если исписать 3 тетради математическими формулами, то действительно докажешь, что синтаксис объявления массивов очень не удачный. Но то, что это серьёзная повседневная проблема для С++ программиста, мне лично, верится с трудом.
+10
R>
ЗЫ: Ты хоть подытоживай периодически что именно засчитано, с краткой аннотацией.
ЗЗЫ: Флеймовый топик изначально, ИМХО...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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Мб нативного кода?
Да известно какой — Паскаль. Но, там объем исходников бы в разы больше
получился, по моим прикидкам.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>А что, если не секрет, заставило выбрать наиболее бесполезную (ну по S>крайней мере из виденных мной) оконную библиотеку? Почему бы не взять S>QT, wxWidgets или MFC?
Выбор был не мой, поинтересуюсь.
Ок, какая из названных библиотек по юзабельности сравнима или лучше VCL ?
Если есть такая, то аргумент снимается.
Здравствуйте, remark, Вы писали:
R>Что Вам мешает в С++?
Не то чтобы мешает (ибо не часто я C++ использую), но несколько пугает модель "выполнения" (я имею в виду порядок выполнения, порядок вступления в силу сайд-эффектов и т.п.) и памяти. Я понимаю, что все эти пляски с точками следования (это к модели выполнения), с volatile-членами (это к модели памяти в многопоточной среде) сделаны для того, чтобы дать больший простор для оптимизации, но модель памяти и модель выполнения в Java и C# значительно проще для освоения.
Здравствуйте, Аноним, Вы писали:
А>Нееет, без полной интеграции в язык неудобно. Нужно что бы из unmanaged кода было сделать managed без всякого переписывания старого кода.
Зачем? А что делать с RAII например или с явными вызовами delete?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: Что Вам мешает в С++?
От:
Аноним
Дата:
21.06.08 21:56
Оценка:
Здравствуйте, Alexander G, Вы писали:
AG>Здравствуйте, Sergey, Вы писали:
S>>А что, если не секрет, заставило выбрать наиболее бесполезную (ну по S>>крайней мере из виденных мной) оконную библиотеку? Почему бы не взять S>>QT, wxWidgets или MFC?
AG>Выбор был не мой, поинтересуюсь. AG>Ок, какая из названных библиотек по юзабельности сравнима или лучше VCL ? AG>Если есть такая, то аргумент снимается.
.NET WinForms Да и QT рулит + кроссплатформенность
постам у меня складывается впечатление, что ты отвечаешь на какой-то другой вопрос, а не на мой... 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.
Здравствуйте, 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, и я вижу, что синтаксический сахар в самом языке — это не всегда зло.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Аноним, Вы писали:
А>>>>Ничего не мешает из того что есть, даже наоборот много чего не хватает
R>>>Отсутствие тоже вполне может мешать. Так что прошу высказываться по существу, отсутствие чего мешает, как часто, в каких языках это есть?
А>>Не хватает: А>>1. Делегатов на уровне языка; А>>2. Полной информации о типах в runtime опционально; А>>3. Что то типа C++Scripts для кодогенерации и выполнения его же на лету в runtime c возможностью cross objects, то есть объявил обьект в основной проге, а в скрипте мог обратиться к нему и наоборот;
R>Ок. Засчитывается.
R>
а функциональный тип или тип — метод не спасут отца русской демократии.
от делегатов первой государственной думы?
Здравствуйте, StevenIvanov, Вы писали:
SI>— Включены малополезные вещи типа экспорта шаблонов и теневой системы типов, исключено такое, как например стандарт на манглер, что не позволяет по-человечески экспортировать класс в библиотеке, который можно использовать в проекте, собираемом другим компилятором (этой частной проблемы нет, например в C#). SI>— Можно еще много чего вспомнить, надо только вот полазить по этому форуму, но лень что-то.
манглинг имен вам ничего не даст. нужно сообщать наружу саму структуру обьекта в памяти. что является частным делом разработчиков компилятора. например чтоб сторонний компилятор вызвал ваш виртуальный метод ему нужно точно знать как добраться до виртуальной таблицы и под каким смещением лежит метод данного имени.
то есть нужно некое общее соглашение о представлении обьектов от какого-нить консорциума.
в сишарпе такое соглашение есть. оно дается в стандарте на среду.
Немного отклонюсь от темы, и приведу то, что немного мешает:
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 и, особенно, почему
люди ей пользуются — для меня загадка.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Все уже сказано. Подчекрнуть хочется именно то, что C++ имеет удручающее наследие от СИ.
Язык слишком сложный, — это главный недостаток, контекстно-зависимость толкования,
многообразность выразить одно и то же.
К языку не относится, но является следствием вышесказанного, — это
несовместимость библиотек, компиляторов в отношении одного и того же
исходного кода. Какие муки мы принимаем из-за этого — известно.
Так что, желающим упростить язык, и как следствие — облегчить разработку,
есть широкое поле для деятельности. Но ребенок-то уже родился, придется любить его
такого как есть, слишком сложного и порой — непредсказуемого.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, Аноним, Вы писали:
А>>Не хватает: А>>1. Делегатов на уровне языка; RO>В C++09 будут.
Да ? Покажите пропозл.
Я не особо слежу, но насколько я помню, там только сделают boost::function как std::function (ну так это не "на уровне языка") и добавят лямбды в язык, с помощью которых эмулировать замыкания в С++ будет легче чем сейчас (это утилита для делегатов но не сами делегаты).
Здравствуйте, Sergey, Вы писали:
S>а вот с какой целью изготовили похожую на нее WTL и, особенно, почему S>люди ей пользуются — для меня загадка.
WTL ИМХО больше на MFC похожа.
Пользуются потому, что удобнее чем MFC.
Не требует ничего тащить с программой — никаких dependencies.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Sergey пишет:
>> А какой промышленный язык справляется с этой задачей лучше? Т.е. какой >> язык способен быстро сгенерировать эквивалент 40Мб нативного кода? > > Да известно какой — Паскаль. Но, там объем исходников бы в разы больше > получился, по моим прикидкам.
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 поставлять
Здравствуйте, Sergey, Вы писали:
S>CreatorCray пишет:
>> S>а вот с какой целью изготовили похожую на нее WTL и, особенно, почему >> S>люди ей пользуются — для меня загадка. >> WTL ИМХО больше на MFC похожа.
S>Ну не знаю. Внутри она устроена как оконная часть ATL, из которой S>собственно и сделана — с чего бы ей быть похожей на MFC? DDX разве что S>приделали MFC-образный.
>> Пользуются потому, что удобнее чем MFC. >> Не требует ничего тащить с программой — никаких dependencies.
S>Что тащить ничего не надо — это замечательно. Но вот что она S>обеспечивает такого, чего нет в винапи? Докинг там скажем или что-нибудь S>подобное wxSizer? Или GDI объекты умеет правильно уничтожать, как та же S>wxWidgets? Или куча стронних контролов под нее есть, как под MFC? S>IMHO, без разницы — на голом винапи писать или с WTL.
Вот разница как раз есть. Лично для меня WTL — это как очень удобная обертка для WinAPI. Некоторые библиотеки представляют обертку над WinAPI, скрывая тонкости программирования на голой платформе, а вот WTL упрощает программирование на этой платформе.
Так что ИМХО — WTL лишь обертка над WinAPI(именно на том уровне, что надо его знать, что бы писать на WTL).
Лично мне все время мешает то, что в С++ нет понятия "просто имя", которое можно было бы свободно передавать в шаблоны и уже при инстанцировании бы компилятор разбирался, что я туда засунул — функцию, класс, шаблон, перегруженную функцию, объект...
Это из того, что почти повседневно мешает в коде, поэтому сразу приходит на ум.
А из общего:
1. Препроцессор, убогий и отвязанный от С++ (нет доступа ни к синтаксису, ни к системе типов, ни к чему). Как надо — см. макросы в Немерле.
2. Подключение хедеров через препроцессор. Решено, наверное, почти везде текстовым включением сейчас разве что скриптовые языки только пользуются типа bash/make. А из этого следует безумное время компиляции и геморрой с созданием нормальной IDE.
3. Нет нормальных IDE, которые понимали бы все, что умеет С++ (т.е. препроцессор, шаблоны, перегрузку и т.д.). Решено в Java и C#.
4. Стилистический разнобой в имеющихся библиотеках (причем в каждой все реализовано по-своему). Решено в централизованных языках типа Java и C#. Сейчас решается посредством STL и буста, но как-то очень неспешно (хотя некоторые библиотеки уже предоставили STL-совместимые интерфейсы доступа).
5. Отсутствие нормальной мета-информации во время компиляции (a.k.a API компилятора, доступный из самой программы, с информацией обо всем — о типах, объектах, функциях, свойствах всего этого, в общем, все, что знает о программе сам компилятор, должно быть доступно и самой программе, причем желательно не только read-only). Из-за этого приходится извращаться с шаблонами, а все в систему типов ведь не запихнешь (например, генерацию именованных членов), не говоря уже об удобстве. В каком-то смысле связано с п.1, ну и решение там же
Да! Язык сложный.
И не каждый скоро освоит его, я сам еще иногда натыкаюсь на интересные приемы, по большей части касающихся шаблонного программирования.
Но это скорее + чем -.
a = [ ... ]
b = []
c = []
a.each do |item|
if item > 0
b << item
else
c << item
end
end
R>
vector_t a, b, c;
BOOST_FOREACH(SOME_TYPE item, a)
(item > 0 ? b : c).push_back(item);
Я не знаю Ruby и (надеюсь) знаю C++, тем не менее пример на Ruby прочитал быстрее чем пример на C++, несмотря на то что последний читал после первого и соответственно уже знал, о чем речь. Как будто вовсе не Ruby, а C++ был изобретен человеком какой-то другой, далекой культуры; японцем каким-нибудь что ли...
PS. Наверное и на Ruby при желании можно заменить if-else-end на что-нибудь вроде ?:.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Что Вам мешает в С++?
Отсутствие безопасного режима...
а разве msvc8, 9 не позволяет генерировать CLR код? Вроде quake 2 портировали полностью — и работает полностью на .NET (сорри если ошибся — честно говоря в код портированной кваки не лазил, однако сомневаюсь что ее переписывали с C на C#).
1. Допустимость переменных с одинаковыми именами во вложенных областях видимости. Даже варнинги на четвертом уровне не выдает, зараза.
int i = 0;
{
int i = 0;
... код ...
обратимся к i. Угадай с трех раз к какому при быстром просмотре кода :(
}
2. Отсутствие полиморфизма времени компиляции в макросах. В С99 конечно вариадики ввели, но все равно не айс
3. Невозможность вложенного препроцессора.
4. Возврат функцией только одного значения. Бесконечные ссылочные и указательные аргументы — лишний код . Возврат классов не панацея
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, Alexander G, Вы писали:
RO>>>Объясни, пожалуйста, что именно могут делегаты и не могут лямбда-функции и std::function. AG>>std::function — не на уровне языка, поэтому не отвечают на ответ
NBN>Всётаки — зачем нужны делегаты на уровне языка? Они вообще-то не попадают в концепцию С++ой лаконичности.
Хотя бы для удобства отладки, чтобы можно было проваливаться сразу в слот.
Видели размер стека между точкой вызова сигнала и вызовом подписанной функции ?
Не говоря уже о том, что реализация в том же boost глючная — там автоотписка не работает.
Здравствуйте, Alexander G, Вы писали:
AG>Я начинал с Delphi, поэтому что мешает:
AG>1. Отуствие finally. Да, я в курсе про RAII, смарт-поинтеры в т.ч. с кастомными деаллокаторами и скоп гарды. Но меня не устраивает навязывание ООП здесь. Выходит, что С++ не поддершивает стиль старого дорбого С (хотя вроде как пытается поддерживать и С и ООП и даже ФП). Сюда же то, что деструктор не вызовется для недоделаных объектов (в Delphi — вызовется), что требует не только помещать ресурсы в классы, но и помещать кажды ресурс в свой класс. If I hear the phrase``everything is an object'' once more, I think I will scream.
Одна из причин "невызова" деструктора в том, что в плюсах объект никак не инициализирован на момент вызова конструктора.
В Delphi производится инициализация по умолчанию нулями до вызова конструктора, потому в деструкторе вполне можно писать x.Free для всех динамически аллоцированных членов класса.
В плюсах же, если даже деструктор и вызывался бы, все равно было бы не понятно что там делать.
Ибо часть объектов инициализирована, а часть содержит мусор. Но кто есть кто — не понять.
Потому даются лишь гарантии для списка инициализации, а в теле конструктора контроль можно производить вручную.
AG>2. Наследие С. Выражается в недостаточной типизации. Пример: '\0' NULL и 0 — совместимы, причём последние 2 вообще одно и то же. В паскале nil 0 и #0 компилятор не даст попутать if (p) p = 0 /* я пропустил * перед p но компилятор не проглотил, т.к. nil и 0 одно и то же */. Также в С путают указатель с массивом. И выражение с операцией. Возможностью написать короче пользоваться не приходится, т.к. требуется написать понятнее, но ошибки типа if (a = b) сделать всё равно можно.
+
AG>3. Я не могу клепать формы на WTL так быстро, как это получалось в Delphi
R>Что Вам мешает в С++?
R>1. Мешать это должно регулярно. Т.к. если это мешает эпизодически, например, раз в год, то это не интересно, т.к. раз в год можно и потерпеть, и на общей эффективности разработки это не сказывается. R>2. Это должно быть решено в других промышленных языках. Т.к. если это не решено хотя бы в одном другом промышленном языке, то это не интересно, т.к. это не проблема С++, а просто общая проблема. Если не очевидно, то желательно указывать языки, в которых это решено.
Первое, что приходит в голову -- работа с памятью. Указатели, преобразование указателей, выделение и освобождение памяти... Ускорение разработки при переходе на C# (к примеру для GUI) из-за этого поразительное.
Еще, пожалуй, обилие диалектов. Когда при обновлении Visual Studio перестает компилироваться код, это очень огорчает. Думаю, ни в одном другом языке эта проблема не цветет таким махровым цветом.
Здравствуйте, s.ts, Вы писали:
AG>>Сюда же то, что деструктор не вызовется для недоделаных объектов (в Delphi — вызовется), что требует не только помещать ресурсы в классы, но и помещать кажды ресурс в свой класс.
А как, по-твоему, деструктор мог бы вызываться для объекта, который никогда не существовал?!
Здравствуйте, remark, Вы писали:
R>Что Вам мешает в С++?
Не доконца продуманная, на мой взляд, поддержка исключений.
Хотелось бы, например, такую как в Jave. Было бы не плохо, если бы компилятор мог сказать: "Вот это я компилировать не буду, так как у вас тут исключение не обрабатывается". Ато приходится лазить по исходникам и смотреть, кто какие исключения генерирует, какие либы используются и что они выплёвывают.
Здравствуйте, Pasternak, Вы писали:
P>Не доконца продуманная, на мой взляд, поддержка исключений. P>Хотелось бы, например, такую как в Jave. Было бы не плохо, если бы компилятор мог сказать: "Вот это я компилировать не буду, так как у вас тут исключение не обрабатывается". Ато приходится лазить по исходникам и смотреть, кто какие исключения генерирует, какие либы используются и что они выплёвывают.
Это мешало бы вызывать из C-функций C++-функции (переданные, например, в качестве callback'а).
Здравствуйте, Alxndr, Вы писали:
A>Здравствуйте, Pasternak, Вы писали:
P>>Не доконца продуманная, на мой взляд, поддержка исключений. P>>Хотелось бы, например, такую как в Jave. Было бы не плохо, если бы компилятор мог сказать: "Вот это я компилировать не буду, так как у вас тут исключение не обрабатывается". Ато приходится лазить по исходникам и смотреть, кто какие исключения генерирует, какие либы используются и что они выплёвывают.
A>Это мешало бы вызывать из C-функций C++-функции (переданные, например, в качестве callback'а).
Вообще выпускать какие-либо исключения за пределы функций callback-ов мне кажется не очень хорошо. Тот кто вызывает эту С-функцию понятия не имеет какие исключения могут генерироваться. Лучшее, что он может сделать это перехватить всё и сообщить об ошибке.
Но и в этом случае можно было бы решить вопрос генерации исключений в callback-ах например, через тип указателя на функцию.
Например как то так (первое что пришло в голову):
Здравствуйте, Pasternak, Вы писали:
P>Но и в этом случае можно было бы решить вопрос генерации исключений в callback-ах например, через тип указателя на функцию. P>Например как то так (первое что пришло в голову):
P>
Здравствуйте, StevenIvanov, Вы писали:
SI>а разве msvc8, 9 не позволяет генерировать CLR код? Вроде quake 2 портировали полностью — и работает полностью на .NET (сорри если ошибся — честно говоря в код портированной кваки не лазил, однако сомневаюсь что ее переписывали с C на C#).
Насколько я понимаю, для CLR нужно писать на C++/CLI, а это несколько иной язык.
Да и MS и Win ведь дело не ограничивается. Люди годами пишут исключительно под Unix и даже не имеют необходимости портироваться под Windows.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pasternak, Вы писали:
P>Не доконца продуманная, на мой взляд, поддержка исключений. P>Хотелось бы, например, такую как в Jave. Было бы не плохо, если бы компилятор мог сказать: "Вот это я компилировать не буду, так как у вас тут исключение не обрабатывается". Ато приходится лазить по исходникам и смотреть, кто какие исключения генерирует, какие либы используются и что они выплёвывают.
RO>где один плагин пишет в файл, другой — в БД, третий — еще куда-нибудь.
RO>Как здесь определить функцию Document::save(Plugin &) throw(а вот что здесь?)?
В общем случае — что угодно, а в данном случае что-то типа DocumentSaveError. Пускай плагины смотрят за тем, что они выбрасывают и подстраиваются под требования функции Document::save. В Jave такая проблема ведь как-то решается.
RO>По-моему, checked exceptions à la Java мешают расширять программы в будущем.
Возможно, но хотелось бы хотя-бы ворнинги какие-то, если эксепшн пропущен.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, s.ts, Вы писали:
AG>>>Сюда же то, что деструктор не вызовется для недоделаных объектов (в Delphi — вызовется), что требует не только помещать ресурсы в классы, но и помещать кажды ресурс в свой класс.
RO>А как, по-твоему, деструктор мог бы вызываться для объекта, который никогда не существовал?!
Что значит "никогда не существовал" ?
Я имел в виду следующее.
Память уже выделена до вызова конструктора, так что там есть что проинициализировать и что деинициализировать.
Что и происходит с членами класса из списка инициализации.
Если бы была инициализация по умолчанию до вызова конструктора, то можно было бы просто звать деструктор в случае исключения.
Почему нет ?
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, StevenIvanov, Вы писали:
SI>>6) По сравнению с С# нет вкусностей типа делегатов и потрясающе мощного рефлекшна.
NBN>По поводу делегатов — не соглашусь.
Здравствуйте, Pasternak, Вы писали:
P>В общем случае — что угодно, а в данном случае что-то типа DocumentSaveError. Пускай плагины смотрят за тем, что они выбрасывают и подстраиваются под требования функции Document::save. В Jave такая проблема ведь как-то решается.
Если мне не изменяет память , то в JAVA давно хотят от этого избавиться
Здравствуйте, s.ts, Вы писали:
ST>Если бы была инициализация по умолчанию до вызова конструктора, то можно было бы просто звать деструктор в случае исключения. ST>Почему нет ?
Чем здесь инициализировать m_fd? Нулем? Тогда деструктор недоделанного объекта закроет нулевой дескриптор, т. е., stdin, а это совсем не то, что нужно. (В WinAPI была бы аналогичная ситуация, потому что HANDLE() != INVALID_HANDLE_VALUE.)
Суть в том, что для многих классов нет приличного дефолтного конструктора. Когда конструктор создал один объект, второй не смог (исключение) и до третьего так и не добрался, то третий объект еще не существует, и вызывать какие бы то ни было его функции, в т. ч. деструктор, лишено смысла.
Можно было бы попытаться реализовать это на уровне языка. Но это нарушило бы принцип «платишь только за то, что используешь», и нарушился бы баланс между конструкторами и деструкторами.
Мораль сей басни такова: или класс управляет ровно одним ресурсом и, соответственно, закрывает его в деструкторе (std::*stream, std::tr1::unique_ptr), или все члены класса сами заботятся об освобождении своих ресурсов.
Здравствуйте, <Аноним>, Вы писали:
А>Не хватает: А>1. Делегатов на уровне языка;
Вобще говоря делегат (если мы говорим про те что в .NET) тот еще мутант.
Просто функции должны быть первокласными функциями как во всех нормальных функциональных языка. Правда для этого нужен GC.
Кстати boost::function + лямбды гораздо точнее эмулируют первокласные функции чем делегаты в .NET.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, merk, Вы писали:
M>сборка мусора чрезвычайно нехороша тем, что ею трудно управлять. это некий процесс идущий параллельно, и горе тому боингу, бортовая аппаратура которого займется сборкой мусора, во время посадки. когда у него вдруг отнимутся шасси и элероны — никому мало не покажется.
Только есть алгоритмы работающие с гарантиями жесткого реального времени...
А если еще будет небольшая поддержка со стороны железа то он будет работать ваще паралельно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Pasternak, Вы писали:
P>>В общем случае — что угодно, а в данном случае что-то типа DocumentSaveError. Пускай плагины смотрят за тем, что они выбрасывают и подстраиваются под требования функции Document::save. В Jave такая проблема ведь как-то решается.
M>Если мне не изменяет память , то в JAVA давно хотят от этого избавиться
Да, вроде ходят споры на эту тему. Тут немного об этом можно почитать.
Я не предлагаю клонировать реализацию поддержки исключений из Javы, мне просто в С++ не хватает инструмента который бы мог определить, что какое-то исключение оставлено без внимания. Об этом я пытался написать. Как это будет реализовано, большой разници нет, но мне кажется, если бы это было встроено в язык — было бы не плохо.
Здравствуйте, remark, Вы писали:
R>По поводу того, что компилятору требуется просматривать на несколько символов вперёд, вообще совсем не понятно. Как это связано с вопросом?
Усложнение и замедление компилятора.
M>>3. нет четкого понятия модуля с импортом и экспортом. хидеры — чисто инклудные файлы для обработки препроцессором. R>Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки?
Постоянно.
Начиная с очень долгой компиляции заканчивая DLL hell'ом.
Тот же немерле не смотря на то что языковых возможностей там куда как больше и компилируется много быстрее и DLL-hell'а там нет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
чего пока (к сожалению) нет в С++ или возможности С# 3.0
SI>- Вывод типа (Type Inference)
Это будет в C++09.
SI>- Анонимные типы (Anonymous Type)
В C++09 можно будет сделать с помощью макросов и decltype, хоть и не так красиво (что-нибудь вроде ANON((a, 42)(b, 'b')(c, someExpr()))).
SI>- Расширяющие методы (Extension Methods)
Это только сахар. Меня сильно смущает, как же быть с конфликтами имен.
SI>- Лямбда-выражения (Lambda Expression)
Будут в C++09.
SI>- Вывод типов и лямбда-выражения
Будут в C++09.
SI>- Дерево выражений (Expression Tree)
Вот рефлексии не хватает...
SI>- Ленивые вычисления (Lazy Evaluation)
Это и в C++98 можно сделать, это не свойство языка.
SI>- Auto Properties
А свойства — это зло :-)
Здравствуйте, remark, Вы писали:
R>А ну да, понял. Проблема, если компилятор *не* инлайнит инлайн функцию. R>Особая засада для дебаг сборки, когда компилятор вообще ничего не инлайнит, просто тупо кладёт каждую функцию в каждый объектный файл.
Эта беда в первую очередь от хреновой модульности, когда слишком много всего приходится класть в хедеры. Те же шаблоны, например.
Опять-таки, это связано с единым форматом объектных файлов, в которых всё должно быть уже скомпилировано. Без этого не получится дешёвая интеграция с другими языками.
R>А какой промышленный язык справляется с этой задачей лучше? Т.е. какой язык способен быстро сгенерировать эквивалент 40Мб нативного кода?
Вот такую нетривиальную задачу поставили разработчики промышленного языка перед разработчиками промышленных компиляторов
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, s.ts, Вы писали:
ST>>Если бы была инициализация по умолчанию до вызова конструктора, то можно было бы просто звать деструктор в случае исключения. ST>>Почему нет ?
RO>Паттерн «Zombie Object»?
RO>
RO>Чем здесь инициализировать m_fd? Нулем? Тогда деструктор недоделанного объекта закроет нулевой дескриптор, т. е., stdin, а это совсем не то, что нужно. (В WinAPI была бы аналогичная ситуация, потому что HANDLE() != INVALID_HANDLE_VALUE.)
Ну да. Одно другое за собой и тянет.
Чем требовать конструктор по умолчанию, тогда уж заставить создавать объекты в куче.
Тогда членами классов будут только указатели/ссылки, которые нулем инициализируются на раз.
Еще ничего не напоминает ?
RO>Суть в том, что для многих классов нет приличного дефолтного конструктора. Когда конструктор создал один объект, второй не смог (исключение) и до третьего так и не добрался, то третий объект еще не существует, и вызывать какие бы то ни было его функции, в т. ч. деструктор, лишено смысла.
Если он был проинициализирован изначально, то можно и вызвать деструктор.
RO>Можно было бы попытаться реализовать это на уровне языка. Но это нарушило бы принцип «платишь только за то, что используешь», и нарушился бы баланс между конструкторами и деструкторами.
Ну а вот разработчики таких языков как Delphi, Java, С# пошли другим путем.
Нарушили, конечно, принцип.
Но не факт, что их путь не правильный.
RO>Мораль сей басни такова: или класс управляет ровно одним ресурсом и, соответственно, закрывает его в деструкторе (std::*stream, std::tr1::unique_ptr), или все члены класса сами заботятся об освобождении своих ресурсов.
Беда в том, что есть еще сырые указатели и т.п., которые сами о себе позаботиться не могут.
Речь об этом:
class raw_data
{
int *m1;
int *m2;
int *m3;
int *m4;
void clear()
{
delete[] m1;
delete[] m2;
delete[] m3;
delete[] m4;
}
public:
raw_data()
: m1(0) // если это делать автоматом, а при исключениях звать деструктор, то и ловить исключения не надо.
, m2(0)
, m3(0)
, m4(0)
{
try
{
m1 = new int[100];
m2 = new int[100];
m3 = new int[100];
m4 = new int[100];
}
catch(...)
{
clear();
}
}
~raw_data()
{
clear();
}
};
Одной из причин того, что при исключениях в конструкторе не вызывается деструктор является отсутствие начальной инициализации членов класса.
Потому пришлось придумывать списки инициализации и т.д., чтобы дать пользователям языка общий механизм освобождения ресурсов при ошибках конструирования.
Это мое утверждение вроде бы не противоречит ни одному из твоих.
Спор какой-то ни о чем. Или я чего-то не понимаю ?
Здравствуйте, remark, Вы писали:
R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>Что Вам мешает в С++?
Нет рефакторинга
Удвой число ошибок, если не получается добиться цели.
EyeOfHell пишет: > > 2. Отсутствие полиморфизма времени компиляции в макросах. В С99 конечно > вариадики ввели, но все равно не айс > 3. Невозможность вложенного препроцессора.
Здравствуйте, strcpy, Вы писали:
S>Здравствуйте, remark, Вы писали:
R>>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>>Что Вам мешает в С++?
S>Нет рефакторинга
Кодт пишет:
> R>А ну да, понял. Проблема, если компилятор *не* инлайнит инлайн функцию. > R>Особая засада для дебаг сборки, когда компилятор вообще ничего не > инлайнит, просто тупо кладёт каждую функцию в каждый объектный файл. > > Эта беда в первую очередь от хреновой модульности, когда слишком много > всего приходится класть в хедеры. Те же шаблоны, например. > Опять-таки, это связано с единым форматом объектных файлов, в которых > всё должно быть уже скомпилировано. Без этого не получится дешёвая > интеграция с другими языками.
Это надуманная причина — никто не запрещает ввести еще один формат
объектников, подразумевающий наличие центрального репозитария.
Поддерживает же в конце концов VC одновременно и COFF и OMF.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[4]: Что Вам мешает в С++?
От:
Аноним
Дата:
23.06.08 17:35
Оценка:
M>>>3. нет четкого понятия модуля с импортом и экспортом. хидеры — чисто инклудные файлы для обработки препроцессором. R>>Как часто у тебя это приводит к ошибкам или к существенному увеличению времени разработки? WH>Постоянно. WH>Начиная с очень долгой компиляции заканчивая DLL hell'ом.
Казалось бы причем тут С++ к dll hell'у, который является чисто виндовым явлением как и сама dll. C++ про нее не в курсе. И боротьяс с ним надо средствами предусмотренными на платформе — юзать SxS с ее манифестами, это, (сорприз?) не исключительно .нетная штука, а вообще для любых длл предусмотрено в венде.
Re[2]: Что Вам мешает в С++?
От:
Аноним
Дата:
23.06.08 18:40
Оценка:
TB>Первое, что приходит в голову -- работа с памятью. Указатели, преобразование указателей, выделение и освобождение памяти...
За delete и голвые в С++ коде воще по рукам бить надо.
TB>Еще, пожалуй, обилие диалектов. Когда при обновлении Visual Studio перестает компилироваться код, это очень огорчает. Думаю, ни в одном другом языке эта проблема не цветет таким махровым цветом.
Правда, неужели переход с .net 1.1 на 2.0 был совершенно безболезненным?)
Здравствуйте, <Аноним>, Вы писали:
А>Казалось бы причем тут С++ к dll hell'у, который является чисто виндовым явлением как и сама dll.
dll-hell явление повсемесное, а не только виндовое. Ибо аналоги dll есть практически везде.
А>C++ про нее не в курсе.
По тому dll-hell и есть что не в курсе.
А>И боротьяс с ним надо средствами предусмотренными на платформе — юзать SxS с ее манифестами, это, (сорприз?) не исключительно .нетная штука, а вообще для любых длл предусмотрено в венде.
Единственный надежный способ бороться с dll-hell это грамотная поддержка dll на уровне языка.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
А>>Казалось бы причем тут С++ к dll hell'у, который является чисто виндовым явлением как и сама dll. WH>dll-hell явление повсемесное, а не только виндовое. Ибо аналоги dll есть практически везде.
Везде==Windows&UNIX?
А знаете почему в С++ нету стандартных средств для работы со структурой каталогов? Потому что не везде есть каталоги.
Знаете почему в С++ существуют триграфы? Потому что не везде есть { и }
Знаете почему в RFC на сетевые протоколы байты называются странным словом октеты? А потому что не везде байт — это 8 бит.
А вы тут про какието dll....
А>>C++ про нее не в курсе. WH>По тому dll-hell и есть что не в курсе.
Потрудитесь настроить генерацию манифестов для своих проектов в студии.
А>>И боротьяс с ним надо средствами предусмотренными на платформе — юзать SxS с ее манифестами, это, (сорприз?) не исключительно .нетная штука, а вообще для любых длл предусмотрено в венде. WH>Единственный надежный способ бороться с dll-hell это грамотная поддержка dll на уровне языка.
.нет боретьяс в dll hell средством платформы. Но ибо это язык для одной платформы, то мона значит сказать что это сделано на уровне языка? А ведь используются все те же application&module манифесты, activation контексты и прочая лабуда которая кстати весьма и весьма коряво устроена.
Здравствуйте, <Аноним>, Вы писали:
А>Везде==Windows&UNIX? А>А знаете почему в С++ нету стандартных средств для работы со структурой каталогов? Потому что не везде есть каталоги. А>Знаете почему в С++ существуют триграфы? Потому что не везде есть { и } А>Знаете почему в RFC на сетевые протоколы байты называются странным словом октеты? А потому что не везде байт — это 8 бит. А>А вы тут про какието dll....
А ты знаешь куда идут доказательства по аналогии?
В любом случае никто не мешает линьковать статически.
WH>>По тому dll-hell и есть что не в курсе. А>Потрудитесь настроить генерацию манифестов для своих проектов в студии.
Как мне это поможет в 4х версиях линуха под которые я пишу?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Что Вам мешает в С++?
От:
Аноним
Дата:
23.06.08 19:21
Оценка:
А>>Везде==Windows&UNIX? А>>А знаете почему в С++ нету стандартных средств для работы со структурой каталогов? Потому что не везде есть каталоги. А>>Знаете почему в С++ существуют триграфы? Потому что не везде есть { и } А>>Знаете почему в RFC на сетевые протоколы байты называются странным словом октеты? А потому что не везде байт — это 8 бит. А>>А вы тут про какието dll.... WH>А ты знаешь куда идут доказательства по аналогии?
Это не аналогии, а тонкие намеки на толстые обстоятельства
WH>В любом случае никто не мешает линьковать статически. WH>>>По тому dll-hell и есть что не в курсе. А>>Потрудитесь настроить генерацию манифестов для своих проектов в студии. WH>Как мне это поможет в 4х версиях линуха под которые я пишу?
Никак Сделайте в makefile'е автоматическое дополнение имени либы ее версией и не парьтесь, если вам это критично Манифесты то по сути эо тоже самое, но нифига не UNIX-way
Здравствуйте, <Аноним>, Вы писали:
А>Это не аналогии, а тонкие намеки на толстые обстоятельства
Единственное толстое обстоятельство это раздолбайство авторов С.
А>Никак Сделайте в makefile'е автоматическое дополнение имени либы ее версией и не парьтесь, если вам это критично Манифесты то по сути эо тоже самое, но нифига не UNIX-way
Как избавлятся от so-hell я и сам знаю.
Тем не менее... еслиб изначально это все продумали таких слов в лексиконе программистов вобще бы небыло.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Я начинающий программист, большого опыта нету, но мнение на этот счёт есть. Язык мне нравится, но после того как попробовал на вкус Яву, разница заметна. Чтобы пофилософствовать супер, но есть пути гораздо короче.
"С++ мне друг, но Ява мне дороже".
Здравствуйте, <Аноним>, Вы писали:
А>юзать SxS с ее манифестами
Это блин бомба замедленного действия, предназначенная для ускоренного пожирания места на системном диске!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[10]: Что Вам мешает в С++?
От:
Аноним
Дата:
23.06.08 21:31
Оценка:
А>>Это не аналогии, а тонкие намеки на толстые обстоятельства WH>Единственное толстое обстоятельство это раздолбайство авторов С.
Язык С изначально вообще никак не привязан к какому либо формату получившихся исполняемых файлов. Это может быть и виндовая длл и образ flash ROM безо всякой файловой системы.
Забота о бинарных файлах и их форматах — это уж дело абстракций более высокого уровня — target платформы и компилятора под нее. То что существующие реализации компонентов под юниксы говенные — язык С совершенно не колышет, точно так же как проблемы индейцев шерифа.
Незачем пихать совершенно все сущности в один уровень абстракции. Есть синтаксис языка, потом — стандартные библиотеки, потом — компиляторы и платформы. Это три разных, совершенно независимых уровня абстракции. Первые две стандартизированы и называются стандарт С++. Другие две — совершенно никак не стандартизированы. Хотите — сделайте свою систему конторя совместимости версий бинарных файлов, — сделайте приблуду к GCC, может быть вам даже спасибо скажут, если повезет конечно. Микрософт сделал свою в пределах своей платформы, линуксоиды как-то этим не озаботились, и в принципе правы — проблема то решается гораздо проще (см мессаги выше).
Re[2]: Что Вам мешает в С++?
От:
Аноним
Дата:
23.06.08 21:40
Оценка:
интерфейсы — наше все
Re[11]: Что Вам мешает в С++?
От:
Аноним
Дата:
23.06.08 21:52
Оценка:
Объяснюсь немного проще — С++ предназначен для того чтобы компилировать исходный текст программы (определенного вида) в исполняемый код (любой). Стандарт С++ накладывает ряд ограничений именно на исходный текст программы — синтаксис и набор стандартных функций и классов. Но на "выхлоп" компилятора — объектники, библиотеки, исполняемые файлы, просто plain код, да хоть код на др ЯП — стандарт никаких правил не накладывает потому, что это означает что target платформа должна была бы быть совместима с С++, а не наоборот. Из этого прямо следует отсутствие каких либо средств борьбы с dll-hell, тк сам язык С++ не стандартизует формат библиотек (статических или динамических) и правил их использования, тк это бинарные файлы, которые могут быть ЛЮБЫМИ.
Здравствуйте, Аноним, Вы писали:
А>Объяснюсь немного проще — С++ предназначен для того чтобы компилировать исходный текст программы (определенного вида) в исполняемый код (любой). Стандарт С++ накладывает ряд ограничений именно на исходный текст программы — синтаксис и набор стандартных функций и классов. Но на "выхлоп" компилятора — объектники, библиотеки, исполняемые файлы, просто plain код, да хоть код на др ЯП — стандарт никаких правил не накладывает потому, что это означает что target платформа должна была бы быть совместима с С++, а не наоборот. Из этого прямо следует отсутствие каких либо средств борьбы с dll-hell, тк сам язык С++ не стандартизует формат библиотек (статических или динамических) и правил их использования, тк это бинарные файлы, которые могут быть ЛЮБЫМИ.
стандарт любого языка, в т.ч и любого асма, не связан с вариантами представления программы в памяти. с асмом вопрос немного спорен, но все таки.
разговор шел об одной из краеугольных стратегий разработки софта — о его модульной разработке с четкими интерфесами импорта и экспорта.
с и с++ этого не поддерживают.
хидер вообще не стандартизован, насколько я понимаю, и есть лишь общепринятое соглашение. можете не поддерживать! сколько раз я видел людей, что просто не умеют писать хидеры, причем спецы между прочим. например они в хидер впихивают инклуды, нужные только для имплементации. почему? а потому что хидер виден в имплементации и им так удобно! проверьте кстати свои
то, что написано в одном хидере можно реализовать в нескольких файлах и наоброт.
декларацию класса тоже можно реализовать в нескольких файлах.
саму декларацию класса можно расписать в нескольких файлах! за счет инклудов
даже декрацию функции(не говоря про реализацию) и декларацию переменной можно расписать в нескольких файлах!
отличный способ написать программу которую никто не разберет
int x
#include "file"
знаете что это?
нет.
варианты
int x;
int x[];
int x(int fx, in fy);
и вообще черт знает что.
при любом инклуде, строго говоря, в голове читателя должна возникать паника, и стремление изучить то ,что вообще вставили в это место. и главное зачем?
вы берете текст программы и читаете. видя инклуды у вас сносит крышу.
слишком много говорят правилах — что нельзя делать, мол побочные эффекты, ход программы труден для понимания, некоторые догвориваются до того, что программер, это существо, способное лишь порождать обьекты, но совершенно не способное их убивать. потому всем нужен GC. это мол круто и типа авангард.
при этом программеру дают такой синтаксис с семантикой, от которой крышу может снести просто при чтении текста. конечно со сдвинутой крышей, он не сумеет жить без сборки мусора.
Re[13]: Что Вам мешает в С++?
От:
Аноним
Дата:
23.06.08 23:04
Оценка:
M>с и с++ этого не поддерживают. M>хидер вообще не стандартизован, насколько я понимаю, и есть лишь общепринятое соглашение. можете не поддерживать! сколько раз я видел людей, что просто не умеют писать хидеры, причем спецы между прочим.
То что вы называете "хидер" это просто исходный файл, который вставляется в единицу трансляции. С++ выше понятий хидер и тп. Не думайте о тех файлах которые пишутся в include как о неких библиотеках. Думайте как просто о "вставленных" в текст программы кусках кода.
Да, это большой недостаток любых универсальных систем — к реальной жизни и реальных людей их надо местами притягивать за уши. С++ универсален, как набор шарниров и палочек из которых можно сделать что угодно. Но делать что угодно из шарниров и палочек накладно, потому появились некие дополнительные соглашения, которые никак не оговариваются стандартом:
— способ использования хедеров, который не нравится вам — их можно использовать как угодно, ваше дело лишь использовать как вам удобно.
— способ построение модульной архмитектуры, используя прекомпилированные бинарные библиотеки — объектники, статические или динамические библиотеки — вообще никак стандартом не покрывается. Опять же — стройте сами свою архитектуру и пользуйте 3rd party framework'и модульной архитектуры, к коим относится и венда с ее дллками и манифестами, и юниксовые so etc
— просто стиль написания кода — о чем я писал уже тут — http://www.rsdn.ru/forum/message/2995741.1.aspx
Просто стандарт языка описывает сам язык. Синтаксис и набор стандартных сущностей. Так же как правила русского языка — описывают грамматику и фонетику, а писать на нем бульварные романы, падонкавские посты или стихи — дело ваше. В универсальности С++ нет места ничему, что можно реализовать как доп библиотеку, доп набор правил для конкретной платформы/платформ, или просто как набор человеческих правил в файле, хранящемся в дереве CVS'а под названием coding_style.txt . В этом же и его беда
Здравствуйте, s.ts, Вы писали:
ST>Здравствуйте, Alexander G, Вы писали:
AG>>Я начинал с Delphi, поэтому что мешает:
AG>>1. Отуствие finally. Да, я в курсе про RAII, смарт-поинтеры в т.ч. с кастомными деаллокаторами и скоп гарды. Но меня не устраивает навязывание ООП здесь. Выходит, что С++ не поддершивает стиль старого дорбого С (хотя вроде как пытается поддерживать и С и ООП и даже ФП). Сюда же то, что деструктор не вызовется для недоделаных объектов (в Delphi — вызовется), что требует не только помещать ресурсы в классы, но и помещать кажды ресурс в свой класс. If I hear the phrase``everything is an object'' once more, I think I will scream.
ST>Одна из причин "невызова" деструктора в том, что в плюсах объект никак не инициализирован на момент вызова конструктора. ST>В Delphi производится инициализация по умолчанию нулями до вызова конструктора, потому в деструкторе вполне можно писать x.Free для всех динамически аллоцированных членов класса. ST>В плюсах же, если даже деструктор и вызывался бы, все равно было бы не понятно что там делать. ST>Ибо часть объектов инициализирована, а часть содержит мусор. Но кто есть кто — не понять. ST>Потому даются лишь гарантии для списка инициализации, а в теле конструктора контроль можно производить вручную.
AG>>2. Наследие С. Выражается в недостаточной типизации. Пример: '\0' NULL и 0 — совместимы, причём последние 2 вообще одно и то же. В паскале nil 0 и #0 компилятор не даст попутать if (p) p = 0 /* я пропустил * перед p но компилятор не проглотил, т.к. nil и 0 одно и то же */. Также в С путают указатель с массивом. И выражение с операцией. Возможностью написать короче пользоваться не приходится, т.к. требуется написать понятнее, но ошибки типа if (a = b) сделать всё равно можно.
ST>+
AG>>3. Я не могу клепать формы на WTL так быстро, как это получалось в Delphi
ST>+
чета вы гоните.
не явлется обьект с забитыми в него нулями никаким — "дефолтно-инициализированным".
поскольку на деструктор не накладывается никаких фунциональных ограничений, он может, например, по некоему нулю в поле обьекта делать нечто необычное. в реальности же конструктор должен инициализировать поля таким образом, чтобы даже если будет исключение, обьект был корректным для деструктора.
корректная реализация finally может быть сделана, если оно вообще нужно, но только не через нули.
инициализируйте короче свои мусорные поля ручками, потом вызывайте то, что может генерить исключение.
finnaly реализуется просто как первоначальный jump на кусок кода обьявленный как finally, а потом уж поиск по стеку подходящего по типу обработчика исключания. finally аналогичен тут дополнительно вставленному в цепочку обработчиков исключения, еще одному обработчику, что выполняется при ЛЮБОМ исключении, и потом ищется уже обработчик по типу выброшенного.
и неча тут дров наламывать.
finally можно в любом дельфи нарисовать некорректным.
Здравствуйте, Аноним, Вы писали:
M>>с и с++ этого не поддерживают. M>>хидер вообще не стандартизован, насколько я понимаю, и есть лишь общепринятое соглашение. можете не поддерживать! сколько раз я видел людей, что просто не умеют писать хидеры, причем спецы между прочим. А>То что вы называете "хидер" это просто исходный файл, который вставляется в единицу трансляции. С++ выше понятий хидер и тп. Не думайте о тех файлах которые пишутся в include как о неких библиотеках. Думайте как просто о "вставленных" в текст программы кусках кода.
не вставляют в модульных языках куски других модулей в код данного. ну не вставляют.
также всерьез вы не знаете, что у вас вставляется. не знаете. поскольку с одним маааахоньким, ничтожным инклудиком, вам могут вставить неограниченный обьем кода, и вы в принципе не догадаетесь, что вам подставили.
инклудим файл. в нем тоже есть инклуд, например под условной переменной..ищем значение условной переменной...она тоже где-то зависит от инклуда, причем тоже под условием из выражения на трех переменных,..ищем три переменные... легко пустить вас по кругу, из которого вы не вырветесь. будете ходить с тетрадкой, с картинками — кто там кого проинклудил, страниц на ..дцать.
более того, от таких рекурсивных инклудов вам насыпят в область видимости могучее множество внешних обьектов, пересекающихся с вашими по именам например и описка чревата необнаружением ошибки.
ваши аргументы критики не выдерживают.
это все равно что поснимать сфетофоры с улиц и отказаться от ПДД. обьявить это либерализмом..и уверяю вас — движение быстро встанет навсегда
не нужно путать либерализм с анархией.
Здравствуйте, Sergey, Вы писали:
>> Эта беда в первую очередь от хреновой модульности, когда слишком много >> всего приходится класть в хедеры. Те же шаблоны, например. >> Опять-таки, это связано с единым форматом объектных файлов, в которых >> всё должно быть уже скомпилировано. Без этого не получится дешёвая >> интеграция с другими языками.
S>Это надуманная причина — никто не запрещает ввести еще один формат S>объектников, подразумевающий наличие центрального репозитария. S>Поддерживает же в конце концов VC одновременно и COFF и OMF.
Ближе всего к решению проблемы прекомпилированные заголовки. Но, увы, они находятся не в том слое: между разбором и трансляцией отдельных файлов, а не между компилятором и линкером (который должен был бы осуществлять окончательную компиляцию, а не просто линковку).
А хреновая модульность, кстати, вылезает ещё и в том, что хедеры можно писать как попало и включать как попало, получая всю мощь и всю головную боль условной компиляции.
И это тоже сдерживает. Даже если компилятор каждому хедеру сопоставил pch в надежде, что линкер потом сам соберёт — то эта надежда может быть жестоко разбита: один и тот же хедер можно дважды включить с разным смыслом. А тащить в pch все варианты (со всеми возможными подстановками и ветвлениями) — это комбинаторный взрыв, как минимум.
чета кто-та по ночам не то-та чета пишет
M>не явлется обьект с забитыми в него нулями никаким — "дефолтно-инициализированным". M>поскольку на деструктор не накладывается никаких фунциональных ограничений, он может, например, по некоему нулю в поле обьекта делать нечто необычное. в реальности же конструктор должен инициализировать поля таким образом, чтобы даже если будет исключение, обьект был корректным для деструктора.
Тем не менее, именно так происходит, например, в дельфи, о которой собс-но и идет речь.
Там конструктор может рассчитывать на то, что переменные инициализированы неким правильным значением или нулем.
Что хорошо вписывается, например, в то, что функции освобождения памяти игнорируют нулевые параметры.
M>корректная реализация finally может быть сделана, если оно вообще нужно, но только не через нули. M>инициализируйте короче свои мусорные поля ручками, потом вызывайте то, что может генерить исключение. M>finnaly реализуется просто как первоначальный jump на кусок кода обьявленный как finally, а потом уж поиск по стеку подходящего по типу обработчика исключания. finally аналогичен тут дополнительно вставленному в цепочку обработчиков исключения, еще одному обработчику, что выполняется при ЛЮБОМ исключении, и потом ищется уже обработчик по типу выброшенного.
Блок finally выполняется в любом случае, даже если исключения не было.
Так что если не использовать scope guard-ы, отсутствие finally ведет к дублированию кода.
int *i = new int;
try
{
...
}
catch(...)
{
delete i;
throw;
}
delete i;
против
int *i = new int;
try
{
...
}
finally
{
delete i;
}
Вот и все, видимо, о чем хотел сказать автор.
M>и неча тут дров наламывать. M>finally можно в любом дельфи нарисовать некорректным.
Для производительности. Чтобы можно было всё инлайнить. Чтобы можно было реализовать статический полиморфизм. За это приходится платить увеличением времени компиляции. Неужели не понятно?
Конечно, здесь есть, что улучшить. Например, хорошо бы избежать полной перекомпиляции при добавлении какой-нибудь private-функции, она же не меняет ABI. Но полностью засунуть std::sort в модуль не удастся никогда.
Кодт пишет: >> > Эта беда в первую очередь от хреновой модульности, когда слишком много >> > всего приходится класть в хедеры. Те же шаблоны, например. >> > Опять-таки, это связано с единым форматом объектных файлов, в которых >> > всё должно быть уже скомпилировано. Без этого не получится дешёвая >> > интеграция с другими языками. > > S>Это надуманная причина — никто не запрещает ввести еще один формат > S>объектников, подразумевающий наличие центрального репозитария. > S>Поддерживает же в конце концов VC одновременно и COFF и OMF. > > Ближе всего к решению проблемы прекомпилированные заголовки. Но, увы, > они находятся не в том слое: между разбором и трансляцией отдельных > файлов, а не между компилятором и линкером (который должен был бы > осуществлять окончательную компиляцию, а не просто линковку).
Вот именно что pch — это вообще не о том.
> А хреновая модульность, кстати, вылезает ещё и в том, что хедеры можно > писать как попало и включать как попало, получая всю мощь и всю головную > боль условной компиляции. > И это тоже сдерживает. Даже если компилятор каждому хедеру сопоставил > pch в надежде, что линкер потом сам соберёт — то эта надежда может быть > жестоко разбита: один и тот же хедер можно дважды включить с разным > смыслом. А тащить в pch все варианты (со всеми возможными подстановками > и ветвлениями) — это комбинаторный взрыв, как минимум.
Поэтому надо работать не (или не только) с хедерами/pch, а с уже
откомпилированными функциями. Только пихать их, грубо говоря, в один на
программу большой объектник. Заодно получаем в качестве бонуса
диагностику нарушений ODR.
Неплохо бы также иметь какой-нибудь p-code для промежуточного
представления шаблонов — из этого дополнительный выигрыш во времени
трансляции бы получился, и почти автоматом — export templates.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
M>это все равно что поснимать сфетофоры с улиц и отказаться от ПДД. обьявить это либерализмом..и уверяю вас — движение быстро встанет навсегда M>не нужно путать либерализм с анархией.
Вот тут вы правы — С++ это как улицы без светофоров, правил и тп. Потому что во первых правила в разных странах таки отличаются, во вторых — это идеологический минимум того что называется дорожной сетью Светофоры, ПДД — это как доп библиотеки и соглашения о кодировании. В том числе о порядке инклудов и общая архитектура проекта. Стандарт С++ их никак не ограничивает.
Здравствуйте, <Аноним>, Вы писали:
А>Язык С изначально вообще никак не привязан к какому либо формату получившихся исполняемых файлов. Это может быть и виндовая длл и образ flash ROM безо всякой файловой системы. А>Забота о бинарных файлах и их форматах — это уж дело абстракций более высокого уровня — target платформы и компилятора под нее. То что существующие реализации компонентов под юниксы говенные — язык С совершенно не колышет, точно так же как проблемы индейцев шерифа.
Пойми одну простую вещь: Наличие или отсутствие модульности в языке никак не зависит от формата таргет платформы. Те вобще никак.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
P>Я не предлагаю клонировать реализацию поддержки исключений из Javы, мне просто в С++ не хватает инструмента который бы мог определить, что какое-то исключение оставлено без внимания.
Зачем вносить в стандарт С++, то что можно реализовать как внешний инструмент? http://edoc.sourceforge.net/
Здравствуйте, Roman Odaisky, Вы писали:
RO>Конечно, здесь есть, что улучшить. Например, хорошо бы избежать полной перекомпиляции при добавлении какой-нибудь private-функции, она же не меняет ABI. Но полностью засунуть std::sort в модуль не удастся никогда.
.NET'у удалось.
Кто мешает поступить также?
Те фронтенд генерит некий промежуточный код(возможно даже кроссплатформенный), а бекенд конкретные бинарники.
См например LLVM.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Что Вам мешает в С++?
От:
Аноним
Дата:
24.06.08 14:20
Оценка:
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Аноним, Вы писали:
R>>>Что Вам мешает в С++?
А>>Как ни парадоксално — свобода в выборе стиля. Можно писать в стиле старого доброго С, можно использовать шаблоны и прочие прелести ФП, можно ООП, можно даже автоматическое управление памятью, которое по мне так даже удобнее GC. Проблема в том что когда проект пишет сотня человек у каждого из который свое понятие "правильности" — вот это то и мешает в С++.
R>Ок. Принимается. Сам с таким сталкивался.
Это не проблема языка. Это проблема команды, и личной дисциплины каждого. Есть coding style проекта, за любое отступление от него должно биться по рукам и производиться обязательное "выправление". Если не согласны со стилем — все вопросы к лидеру проекта. Но пока он не одобрит изменения в coding style — все должны пищать, но соответствовать текущему варианту. Ибо нефиг.
Здравствуйте, WolfHound, Вы писали:
RO>>Конечно, здесь есть, что улучшить. Например, хорошо бы избежать полной перекомпиляции при добавлении какой-нибудь private-функции, она же не меняет ABI. Но полностью засунуть std::sort в модуль не удастся никогда.
WH>.NET'у удалось. WH>Кто мешает поступить также?
Это tradeoff. Решение .NET не строго лучше. Тем более, что то же самое можно сделать и в C++, см. pimpl. Например, <stdio.h>: пользователю неведомо, что внутри структуры FILE, и при изменении внутренностей fopen не нужна перекомпиляция. Чем за это нужно платить, понятно?
WH>Те фронтенд генерит некий промежуточный код(возможно даже кроссплатформенный), а бекенд конкретные бинарники. WH>См например LLVM.
Если я добавлю в класс еще один член, то пользователей класса всё равно придется перекомпилировать, верно?
Если изменится что-нибудь в недрах std::sort, то нужно будет перекомпилировать все воплощения, верно?
Промежуточный код мог бы помочь, различая существенные и несущественные изменения. Но ускорить компиляцию на порядки не выйдет.
Впрочем, было бы интересно попытаться реализовать два способа компиляции: тот, который есть сейчас, и дотнетоподобный, где весь статический полиморфизм был бы заменен динамическим. Для разработки использовался бы второй, а для конечного продукта — обычный, с полномасштабным инлайнингом и т. п. Во время разработки отдавалось бы предпочтение скорости компиляции, а по окончании ее — скорости работы самой программы.
Здравствуйте, Аноним, Вы писали:
А>интерфейсы — наше все
я за и делаю максимально где это возможно, но иногда чтото требует скорости, например matlib и вот тут интерфейсы ну уж совсем не к месту
Здравствуйте, Roman Odaisky, Вы писали:
RO>Это tradeoff. Решение .NET не строго лучше. Тем более, что то же самое можно сделать и в C++, см. pimpl. Например, <stdio.h>: пользователю неведомо, что внутри структуры FILE, и при изменении внутренностей fopen не нужна перекомпиляция. Чем за это нужно платить, понятно?
Ты не понимаешь.
Нет там ничего такого.
Генерики воплощаются каждый раз. (правда только для value типов но это чисто заморочки .NET)
RO>Если я добавлю в класс еще один член, то пользователей класса всё равно придется перекомпилировать, верно?
Не совсем.
Отработает только бекенд.
А он очень быстро работает ибо ему не нужно ничего проверять, искать и порождать сотни одинаковых воплощений в разных единицах трансляции.
RO>Промежуточный код мог бы помочь, различая существенные и несущественные изменения. Но ускорить компиляцию на порядки не выйдет.
Как нефиг делать. Даже прекомпилированные заголовки очень сильно помогают.
А на сколько порядков можно разогнать линькер...
RO>Впрочем, было бы интересно попытаться реализовать два способа компиляции:
Для этого придется очень сильно менять язык.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
RO>>Это tradeoff. Решение .NET не строго лучше. Тем более, что то же самое можно сделать и в C++, см. pimpl. Например, <stdio.h>: пользователю неведомо, что внутри структуры FILE, и при изменении внутренностей fopen не нужна перекомпиляция. Чем за это нужно платить, понятно? WH>Ты не понимаешь. WH>Нет там ничего такого. WH>Генерики воплощаются каждый раз. (правда только для value типов но это чисто заморочки .NET)
Таки не понимаю, объясни, пожалуйста.
Как можно оставить возможность создания объектов на стеке и избежать перекомпиляции при изменении внутренней структуры объектов?
Или, например, есть вызов std::sort с неким предикатом. Вызов предиката инлайнится. И сама std::sort (частично) инлайнится. Если кто-то меняет предикат, то как можно обойтись без перекомпиляции?
Здравствуйте, Roman Odaisky, Вы писали:
RO>Или, например, есть вызов std::sort с неким предикатом. Вызов предиката инлайнится. И сама std::sort (частично) инлайнится. Если кто-то меняет предикат, то как можно обойтись без перекомпиляции?
Без запуска фронтенда (для модуля с std::sort) легко.
Также учти что в этой схеме не будет сотен воплощений одного и тогоже метода.
Компилятору не придется их долго и нудно компилировать, а линькеру не придется их долго и нудно сливать.
Не будет гигабайт промежуточных файлов что позволит очень не хило сэкономить на IO.
...
А еще бекенд можно очень сильно распаралелить.
Вплоть до потока на функцию что в условиях наступающих многоядерников совсем не помешает.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
RO>>Или, например, есть вызов std::sort с неким предикатом. Вызов предиката инлайнится. И сама std::sort (частично) инлайнится. Если кто-то меняет предикат, то как можно обойтись без перекомпиляции? WH>Без запуска фронтенда (для модуля с std::sort) легко.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Вот как именно легко? Как это реализовать?
Псевдокод:
std.sort.cpp
module std.sort;
public import std.iterator;
public import std.predicate;
namespace std
{
template<class IterType, class Comparator, class ValueType>
public void sort(IterType begin, IterType end, Comparator cmp)
where IterType : std::random_access_iterator<ValueType>
where Comparator : std::order_predicate<ValueType>
where ValueType : std::swappable<ValueType>
{
...сортируем...
}
template<class IterType, class ValueType>
public void sort(IterType begin, IterType end)
where IterType : std::random_access_iterator<ValueType>
where ValueType : std::ordered<ValueType>, std::swappable<ValueType>
{
sort(begin, end, std::less<ValueType>());
}
}
Теперь просто компилим и получаем бинарник в котором недокомпилированный код.
В такой схеме приходится указывать констрейнты но ИМХО это даже плюс.
Ибо автокомплит будет работать без проблем.
Да и ошибки будут наааамного понятнее.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, s.ts, Вы писали:
ST>Здравствуйте, merk, Вы писали:
M>>чета вы гоните.
ST>чета кто-та по ночам не то-та чета пишет
M>>не явлется обьект с забитыми в него нулями никаким — "дефолтно-инициализированным". M>>поскольку на деструктор не накладывается никаких фунциональных ограничений, он может, например, по некоему нулю в поле обьекта делать нечто необычное. в реальности же конструктор должен инициализировать поля таким образом, чтобы даже если будет исключение, обьект был корректным для деструктора.
ST>Тем не менее, именно так происходит, например, в дельфи, о которой собс-но и идет речь. ST>Там конструктор может рассчитывать на то, что переменные инициализированы неким правильным значением или нулем. ST>Что хорошо вписывается, например, в то, что функции освобождения памяти игнорируют нулевые параметры.
давно с дельфи имел дело...а там можно экземпляры классов располагать на стеке? или делают их только на куче?
M>>корректная реализация finally может быть сделана, если оно вообще нужно, но только не через нули. M>>инициализируйте короче свои мусорные поля ручками, потом вызывайте то, что может генерить исключение. M>>finnaly реализуется просто как первоначальный jump на кусок кода обьявленный как finally, а потом уж поиск по стеку подходящего по типу обработчика исключания. finally аналогичен тут дополнительно вставленному в цепочку обработчиков исключения, еще одному обработчику, что выполняется при ЛЮБОМ исключении, и потом ищется уже обработчик по типу выброшенного.
ST>Блок finally выполняется в любом случае, даже если исключения не было. ST>Так что если не использовать scope guard-ы, отсутствие finally ведет к дублированию кода.
ST>
ST>против
не делайте throw, если вы обработали исключение.
раз вы его делаете, это значит, что вы не можете исключение реально обработать.
вообще это моветон, программировать "на исключениях", моду на такое пресекать нуна!
ST>
Здравствуйте, merk, Вы писали:
M>хидер вообще не стандартизован, насколько я понимаю, и есть лишь общепринятое соглашение. можете не поддерживать! сколько раз я видел людей, что просто не умеют писать хидеры, причем спецы между прочим. например они в хидер впихивают инклуды, нужные только для имплементации. почему?
Скорее всего проекты небольшие, и время компиляции не превысило некий критический порог.
WolfHound пишет:
> Единственное толстое обстоятельство это раздолбайство авторов С. >
Я думаю, авторы C были в шоке от последствий.
Мне вот на днях консерву надо было ночью открыть, а открывашка
потерялась, я ключом "открыл" (помыв его до и после, конечно).
А теперь представьте, что одним солнечным днём я обнаруживаю в продаже
швейцарский набор ключей. Теперь уже не только для открывания консерв.
Винты можно вкручивать вместо отвёртки, на гитаре играть вместо медиатора.
Здравствуйте, Аноним, Вы писали:
TB>>Первое, что приходит в голову -- работа с памятью. Указатели, преобразование указателей, выделение и освобождение памяти... А>За delete и голвые в С++ коде воще по рукам бить надо.
В этом и дело. Необходимо отвлекать ресурсы на обучение, контроль и битье по рукам, что здорово увеличивает стоимость разработки.
TB>>Еще, пожалуй, обилие диалектов. Когда при обновлении Visual Studio перестает компилироваться код, это очень огорчает. Думаю, ни в одном другом языке эта проблема не цветет таким махровым цветом. А>Правда, неужели переход с .net 1.1 на 2.0 был совершенно безболезненным?)
Единственный большой проект, который мне пришлось сделать на 1.1, коллеги перевели на 2.0 без меня, но на проблемы вроде не жаловались.
merk пишет:
> более того, от таких рекурсивных инклудов вам насыпят в область > видимости могучее множество внешних обьектов, пересекающихся с вашими по > именам
А>Это не проблема языка. Это проблема команды, и личной дисциплины каждого. Есть coding style проекта, за любое отступление от него должно биться по рукам и производиться обязательное "выправление". Если не согласны со стилем — все вопросы к лидеру проекта. Но пока он не одобрит изменения в coding style — все должны пищать, но соответствовать текущему варианту. Ибо нефиг.
Это все, конечно, хорошо звучит, однако работать приходится не с роботами, а с людьми. Думаю не стоит доказывать, что никакой тим-лид не в состоянии постоянно контролировать каждый участок кода, да и нездорово это. К тому же написать Стандарт Кодирования, в частности стиль кодирования, который бы удовлетворял всех и при этом был непротиворечив, практически невозможно (я как-то пробовал). При этом если только у вас не армейское предприятие, будет довольно трудно и посему дорого контролировать код...
Здравствуйте, anonim_44ax, Вы писали:
_>Это все, конечно, хорошо звучит, однако работать приходится не с роботами, а с людьми. Думаю не стоит доказывать, что никакой тим-лид не в состоянии постоянно контролировать каждый участок кода, да и нездорово это. К тому же написать Стандарт Кодирования, в частности стиль кодирования, который бы удовлетворял всех и при этом был непротиворечив, практически невозможно (я как-то пробовал). При этом если только у вас не армейское предприятие, будет довольно трудно и посему дорого контролировать код...
Ипатьевский метод творит чудеса, даже на гражданских предприятиях...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, merk, Вы писали:
M>не делайте throw, если вы обработали исключение. M>раз вы его делаете, это значит, что вы не можете исключение реально обработать.
Здравствуйте, Roman Odaisky, Вы писали:
RO>А как правильно?
CTransaction tr( context );
// ...
tr.commit();
а rollback, если он вообще нужен, делается в деструкторе незакоммиченой транзакции...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Roman Odaisky, Вы писали:
RO>Для производительности. Чтобы можно было всё инлайнить. Чтобы можно было реализовать статический полиморфизм. За это приходится платить увеличением времени компиляции. Неужели не понятно?
imho, tradeoff это не только увеличение времени компиляции, но и увеличение затрат на сопровождение, что выражается в таких проблемах, как лишние инклуды (представьте компоненту, код к которой пишут несколько команд из разных стран, под прессингом времени находится немного людей, которые удаляют такие лишние зависимости времени компиляции — сталкивался неоднократно на собственном опыте).
Плюс появление различных вариаций, как можно писать инклуды —
так
#include "myfolder/myfile.h",
#include "../myfolder/myfile.h",
#include "myfile.h",
#include <myfolder/myfile.h>,
#include <myfile.h>
???
И еще — необходимость писать инклуд гарды. Я считаю идиотизмом, что не стандартизировали хотя бы в 98 году #pragma once, которая была известна еще в 80-х. И по сей день для написания "ISO 100% compliant" кода приходится писать эти наборы #ifndef/#define...#endif
Я понимаю, что таково наследие С++ и иногда(хоть это категорически не рекомендуется) инклуд того же файла пишется дважды с целью иной трактовки его содержимого. Но, согласитесь, это в промышленном коде это встречается исчезающе редко.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, merk, Вы писали:
M>>не делайте throw, если вы обработали исключение. M>>раз вы его делаете, это значит, что вы не можете исключение реально обработать.
RO>Это он изображает finally.
RO>Кстати, как можно иначе сделать вот это: RO>
RO>?
M>>вообще это моветон, программировать "на исключениях", моду на такое пресекать нуна!
RO>А как правильно?
чтобы было правильно, сначала нужно строго сформулировать условия когда должны возникать исключения.
исключение сигнализирует о том, что сложно написать нормальное продолжение алгоритма, при такой вот ситуации.
еще строже — когда функция выполняет предусловия, но не может никаким образом выполнить постусловия. то есть нет выхода из функции регулярным образом.
теперь вопрос — если у вас что-то сломалось в базе и вы либо откатываетесь, либо завершаете транзакцию...действительно это настолько разрушительно для вашего алгоритма, что вы не можете выйти из функции?
нет.
ситуаций для эксепшенов, на самом деле — на пальцах перечесть. и народ кидает эксепшены в 90 проц. случаях совершенно излишне.
Здравствуйте, merk, Вы писали:
M>чтобы было правильно, сначала нужно строго сформулировать условия когда должны возникать исключения. M>исключение сигнализирует о том, что сложно написать нормальное продолжение алгоритма, при такой вот ситуации. M>еще строже — когда функция выполняет предусловия, но не может никаким образом выполнить постусловия. то есть нет выхода из функции регулярным образом. M>теперь вопрос — если у вас что-то сломалось в базе и вы либо откатываетесь, либо завершаете транзакцию...действительно это настолько разрушительно для вашего алгоритма, что вы не можете выйти из функции? M>нет. M>ситуаций для эксепшенов, на самом деле — на пальцах перечесть. и народ кидает эксепшены в 90 проц. случаях совершенно излишне.
Т. е., ты предлагаешь заменять исключения кодами возврата?
До последнего не верил в пирамиду Лебедева.
Re[4]: Что Вам мешает в С++?
От:
Аноним
Дата:
25.06.08 11:22
Оценка:
А>Это не проблема языка. Это проблема команды, и личной дисциплины каждого. Есть coding style проекта, за любое отступление от него должно биться по рукам и производиться обязательное "выправление". Если не согласны со стилем — все вопросы к лидеру проекта. Но пока он не одобрит изменения в coding style — все должны пищать, но соответствовать текущему варианту. Ибо нефиг.
Вы просто думаете с точки зрения программера. А с точки зрениия руководства фирмы дополнительная поддержка дисциплины в конечном итоге выливается в дополнительные материальные расходу — на оплату более квалифицированных манагеров, архитектов да и самих программеров, да и битье по рукам и переписывание кода — это затраты времени, которое тоже стоит денег.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, merk, Вы писали:
M>>чтобы было правильно, сначала нужно строго сформулировать условия когда должны возникать исключения. M>>исключение сигнализирует о том, что сложно написать нормальное продолжение алгоритма, при такой вот ситуации. M>>еще строже — когда функция выполняет предусловия, но не может никаким образом выполнить постусловия. то есть нет выхода из функции регулярным образом. M>>теперь вопрос — если у вас что-то сломалось в базе и вы либо откатываетесь, либо завершаете транзакцию...действительно это настолько разрушительно для вашего алгоритма, что вы не можете выйти из функции? M>>нет. M>>ситуаций для эксепшенов, на самом деле — на пальцах перечесть. и народ кидает эксепшены в 90 проц. случаях совершенно излишне.
RO>Т. е., ты предлагаешь заменять исключения кодами возврата?
я предлагаю любую замену исключениям, там где возможны варианты исполнения вашей задачи.
если вы открываете файл, коотрого нет...это не значит, что это нельзя обработать регулярным образом. о чем свидетельствует исключение.
код возврата, например.
Здравствуйте, merk, Вы писали:
RO>>Т. е., ты предлагаешь заменять исключения кодами возврата? M>я предлагаю любую замену исключениям, там где возможны варианты исполнения вашей задачи. M>если вы открываете файл, коотрого нет...это не значит, что это нельзя обработать регулярным образом. о чем свидетельствует исключение. M>код возврата, например.
Ну это древний флейм, исключения против кодов возврата. Вроде уже единогласно решили, что исключения лучше, кроме случаев, когда они значительно вредят производительности.
Исключения не позволяют проигнорировать проблему и отделяют основную работу от обработки ошибок.
Самый простой пример — try { document.save(); } catch(std::exception const& e) { alert(text="Failure saving document", details=e.what()); }. И всё. С кодами возврата задолбаешься проверять успешность каждой операции.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, merk, Вы писали:
RO>>>Т. е., ты предлагаешь заменять исключения кодами возврата? M>>я предлагаю любую замену исключениям, там где возможны варианты исполнения вашей задачи. M>>если вы открываете файл, коотрого нет...это не значит, что это нельзя обработать регулярным образом. о чем свидетельствует исключение. M>>код возврата, например.
RO>Ну это древний флейм, исключения против кодов возврата. Вроде уже единогласно решили, что исключения лучше, кроме случаев, когда они значительно вредят производительности.
RO>Исключения не позволяют проигнорировать проблему и отделяют основную работу от обработки ошибок.
RO>Самый простой пример — try { document.save(); } catch(std::exception const& e) { alert(text="Failure saving document", details=e.what()); }. И всё. С кодами возврата задолбаешься проверять успешность каждой операции.
этот мир так устроен, что любая идиотская мысль, всегда подтверждается изящным примером.
если вас задолбит код возврата,...то обработка исключений задолбит еще больше.
причем если вы всего-то передали исключение из вызываемой в вызывающую функцию... — вы просто сэмулировали код возврата.
исключения еще имеют смысл, для "выпрыгивания" из данного контекста далеко наружу, но уж по крайней мере не в предыдущий контекст.
опять же ошибки нужно обрабатывать как можно ближе к месту их возникновения. а — далеко выпрыгивать — противоречит данному принципу.
Здравствуйте, merk, Вы писали:
M>опять же ошибки нужно обрабатывать как можно ближе к месту их возникновения. а — далеко выпрыгивать — противоречит данному принципу.
бессмысленный принцип.
Ошибки нужно обрабатывать там, где ты можешь их адекватно обработать, в зависимости от тяжести ошибки.
А далеко это или близко окажется от места возникновения ошибки — дело десятое.
Здравствуйте, merk, Вы писали:
M>этот мир так устроен, что любая идиотская мысль, всегда подтверждается изящным примером. M>если вас задолбит код возврата,...то обработка исключений задолбит еще больше.
Видимо симметрия мира требует считать, что и твоя идиотская мысль подтверждается изящными примерами?
OK, примеры в топку.
M>причем если вы всего-то передали исключение из вызываемой в вызывающую функцию... — вы просто сэмулировали код возврата. M>исключения еще имеют смысл, для "выпрыгивания" из данного контекста далеко наружу, но уж по крайней мере не в предыдущий контекст. M>опять же ошибки нужно обрабатывать как можно ближе к месту их возникновения. а — далеко выпрыгивать — противоречит данному принципу.
IMHO, есть намного более прямой главный и обязательный принцип. Обработка ошибок и исключительных ситуаций должна иметь в программе цельный и продуманный характер.
Можно сделать и цельную и стройную обработку на кодах возврата и на исключениях, и на длинных джампах и много ещё на чём. Только сначала надо продумать и спроектировать логичную систему, а потом уж отвечать на вопросы про исключения там или коды возврата...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Про исключения и ошибки...проектирования... :)
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, merk, Вы писали:
M>>этот мир так устроен, что любая идиотская мысль, всегда подтверждается изящным примером. M>>если вас задолбит код возврата,...то обработка исключений задолбит еще больше. E>Видимо симметрия мира требует считать, что и твоя идиотская мысль подтверждается изящными примерами?
E>OK, примеры в топку.
M>>причем если вы всего-то передали исключение из вызываемой в вызывающую функцию... — вы просто сэмулировали код возврата. M>>исключения еще имеют смысл, для "выпрыгивания" из данного контекста далеко наружу, но уж по крайней мере не в предыдущий контекст. M>>опять же ошибки нужно обрабатывать как можно ближе к месту их возникновения. а — далеко выпрыгивать — противоречит данному принципу.
E>IMHO, есть намного более прямой главный и обязательный принцип. Обработка ошибок и исключительных ситуаций должна иметь в программе цельный и продуманный характер.
Это не принцип. Это бла-бла.
E>Можно сделать и цельную и стройную обработку на кодах возврата и на исключениях, и на длинных джампах и много ещё на чём. Только сначала надо продумать и спроектировать логичную систему, а потом уж отвечать на вопросы про исключения там или коды возврата...
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, merk, Вы писали:
M>>опять же ошибки нужно обрабатывать как можно ближе к месту их возникновения. а — далеко выпрыгивать — противоречит данному принципу.
J>бессмысленный принцип.
J>Ошибки нужно обрабатывать там, где ты можешь их адекватно обработать, в зависимости от тяжести ошибки. J>А далеко это или близко окажется от места возникновения ошибки — дело десятое.
раз пошла такая пьянка.
софт ващета не должен падать с правильной диагностикой, а система должна стараться ошибку локализовать, изолировать, исправить.
из принципа локализации уже видно, что ...читай мое выше — как можно ближе к месту возникновения...
принцип изоляции говорит о том же. что логически не относящиеся к ошибочной ситуации узлы, процедуры, компоненты и модули и все такое, вплоть до контекстов не должны быть вовлечены в изоляцию ошибки.
поотму проброс ошибки вверх по контексту и радостное сообщение юзеру — "привет, мы упали!" не является хорошим методом обработки ошибок, и также случаем функционирования правильной системы, ну в моем конешна понимании.
Здравствуйте, merk, Вы писали:
M>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, merk, Вы писали:
M>>>опять же ошибки нужно обрабатывать как можно ближе к месту их возникновения. а — далеко выпрыгивать — противоречит данному принципу.
J>>бессмысленный принцип.
J>>Ошибки нужно обрабатывать там, где ты можешь их адекватно обработать, в зависимости от тяжести ошибки. J>>А далеко это или близко окажется от места возникновения ошибки — дело десятое.
M>раз пошла такая пьянка. M>софт ващета не должен падать с правильной диагностикой, а система должна стараться ошибку локализовать, изолировать, исправить. M>из принципа локализации уже видно, что ...читай мое выше — как можно ближе к месту возникновения... M>принцип изоляции говорит о том же. что логически не относящиеся к ошибочной ситуации узлы, процедуры, компоненты и модули и все такое, вплоть до контекстов не должны быть вовлечены в изоляцию ошибки. M>поотму проброс ошибки вверх по контексту и радостное сообщение юзеру — "привет, мы упали!" не является хорошим методом обработки ошибок, и также случаем функционирования правильной системы, ну в моем конешна понимании.
Что-то я не понял, из каких моих слов следует, что единственный правильный способ реакции на ошибку, с которым ты споришь — это "падать с правильной диагностикой" либо показывать "радостное сообщение юзеру".
Цитата бы очень помогла.
Здравствуйте, merk, Вы писали:
E>>IMHO, есть намного более прямой главный и обязательный принцип. Обработка ошибок и исключительных ситуаций должна иметь в программе цельный и продуманный характер.
M>Это не принцип. Это бла-бла.
IMHO, Это не реплика, а очень аргументированная заявка на высокий профессиональный уровень тебя, как проектировщика и программиста...
Может перейдёшь от навешивания ярлыков к аргументам? От чего тебе кажется, что продумывать систему обработки исключительных ситуаций не нужно? Или ты что-то другое хотел сказать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, jazzer, Вы писали:
M>>раз пошла такая пьянка. M>>софт ващета не должен падать с правильной диагностикой, а система должна стараться ошибку локализовать, изолировать, исправить. M>>из принципа локализации уже видно, что ...читай мое выше — как можно ближе к месту возникновения... M>>принцип изоляции говорит о том же. что логически не относящиеся к ошибочной ситуации узлы, процедуры, компоненты и модули и все такое, вплоть до контекстов не должны быть вовлечены в изоляцию ошибки. M>>поотму проброс ошибки вверх по контексту и радостное сообщение юзеру — "привет, мы упали!" не является хорошим методом обработки ошибок, и также случаем функционирования правильной системы, ну в моем конешна понимании.
J>Что-то я не понял, из каких моих слов следует, что единственный правильный способ реакции на ошибку, с которым ты споришь — это "падать с правильной диагностикой" либо показывать "радостное сообщение юзеру". J>Цитата бы очень помогла.
по моему очевидно, что покидание контекста возникновения ошибки приводит к трудности ее исправления. теряются детали. вы же утверждаете общо — что мол там перехватим где удобно! но это слишком общо.
я же утверждаю, что локализовать ошибку можно только где-то вблизи ее возниконовения. и даже нужно.
вам это не нравится, вы с этим спорите, вы говорите, что как настоящий фокусник готовы изолировать ошибку где угодно.
и в этом вам помогут исключения.
но как раз исключения хороши для стремительного покидания контекста. что типа противоречит..читай выше.
Здравствуйте, merk, Вы писали:
M>по моему очевидно, что покидание контекста возникновения ошибки приводит к трудности ее исправления. теряются детали. вы же утверждаете общо — что мол там перехватим где удобно! но это слишком общо. M>я же утверждаю, что локализовать ошибку можно только где-то вблизи ее возниконовения. и даже нужно. M>вам это не нравится, вы с этим спорите, вы говорите, что как настоящий фокусник готовы изолировать ошибку где угодно. M>и в этом вам помогут исключения. M>но как раз исключения хороши для стремительного покидания контекста. что типа противоречит..читай выше.
Что такое контекст возникновения исключительной ситуации?
Это функция, которая кинула исключение, та которая ее непосредственно вызвала?
Насколько в стеке вызова распространяется допустимый дипазон для обработки исключения?
Imho, все зависит от разбиения на логические подсистемы, а размер стека вызовов значения не имеет.
Нехорошо выводить на уровень пользовательского интерфейса std::out_of_range, т.к. для пользователя
сообщение бессмысленное. А коды возврата — в топку. Их случайное игнорирование множит количество
неучтенных сценариев выполнения программы, не всегда приводящих к явной и быстрой смерти, а чаще к странным глюкам
и порче важных данных.
З.Ы. Пример с откатом транзакции в деструкторе scope guard'а — удачный. У меня в большом проекте, где активно
юзается MS SQL, повсеместно применяется. Это ОЧЕНЬ удобно, такое количество кода с использованием кодов возврата
поддерживать было бы просто НЕРЕАЛЬНО.
Здравствуйте, merk, Вы писали:
M>1. совместимость с С. в С просто видна история развития и затыкание синтаксических дыр. M>например значок -> как сокращение косорукой(из-за лексики С) необходимой записи (*p).name. M>авторы С явно сначала и не думали использовать структурные типы, и видимо клепали точное подобие какого-нить ассемблера PDP-11. по крайней мере чтобы при не особосложном компиляторе получить прямое отображение С в ассемблер.
После паскаля, думаю, сложно понять язык. Это ничто иное, как современный стандартизованный (кроссплатформенный) ассемблер. К сведению — традиционные ассемблеры сейчас могут переплюнуть в метапрограммировании любые шаблоны. Только писанины там будет... Да и не используют макросы настоящие джедаи (real men code in hex), вот Страуструп тоже устал писать на традиционном ассемблере...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Не мешает, но несколько напрягает сложность языка. В том смысле, что отражается это на сложности транслятора. Иной раз не понять, насколько кривые у тебя руки, когда минимальный пример работает нормально, а большой код ломается в зависимости от ключей компилятора. У производителей компиляторов то руки по определению правильные, багов в них не бывает
Или internal compiler error — очень вразумительное сообщение об ошибке
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Alexander G, Вы писали:
AG>std::function — не на уровне языка
Тем неменее оно будет в
Standard for Programming Language C++
new, dynamic_cast<>, исключения, ... тоже "не на уровне", требуют поддержку рантаймом...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
AG>>std::function — не на уровне языка
GN>Тем неменее оно будет в GN>
Standard for Programming Language C++
Ага. Будет как сейчас vector или string. Шаблонный класс, а не встроенная в язык конструкция. Недостатки: Легче использовать неправильно.
Труднее смотреть в отладчике.
Мешает, а не помогает оптимизации.
Больше свои тараканов у каждой реализации.
GN>new, dynamic_cast<>, исключения, ... тоже "не на уровне", требуют поддержку рантаймом...
Да, но это уже действительно элменты языка.
Вот кстати лямбда будет тоже элементом языка.
Причём как в lambda, так и в function ничего особого в рантайм добалять не надо.
Не то чтобы мне сильно хотелось чтобы std::function была частью языка, но всё же было бы лучше именно так.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, merk, Вы писали:
M>>по моему очевидно, что покидание контекста возникновения ошибки приводит к трудности ее исправления. теряются детали. вы же утверждаете общо — что мол там перехватим где удобно! но это слишком общо. M>>я же утверждаю, что локализовать ошибку можно только где-то вблизи ее возниконовения. и даже нужно. M>>вам это не нравится, вы с этим спорите, вы говорите, что как настоящий фокусник готовы изолировать ошибку где угодно. M>>и в этом вам помогут исключения. M>>но как раз исключения хороши для стремительного покидания контекста. что типа противоречит..читай выше.
А>Что такое контекст возникновения исключительной ситуации?
вы вообще сначала сформулируйте — что такое исключительная ситуация. вот как вам кажется? А>Это функция, которая кинула исключение, та которая ее непосредственно вызвала?
вполне возможно. А>Насколько в стеке вызова распространяется допустимый дипазон для обработки исключения?
ну вы барин и вопросы задаете... допустимый диапазон — разный. в зависимости от вашей методы обработки ошибок. и что вы считаете ошибками, а что — возможностями. например вы открываете файл..а его нет. это ошибка или возможность? тут нужно генерить исключение, или как-то иначе обрабатывать? и где обрабатывать?
А>З.Ы. Пример с откатом транзакции в деструкторе scope guard'а — удачный. У меня в большом проекте, где активно А>юзается MS SQL, повсеместно применяется. Это ОЧЕНЬ удобно, такое количество кода с использованием кодов возврата А>поддерживать было бы просто НЕРЕАЛЬНО.
пример потому и удачный, что вам дали внешний метод исправления ситуации — откат транзакций. вам осталось только его вызвать. кстати где пример-то?
действительно. когда есть много каких-то действий и известно как восстановиться после неустранимой ошибки внутри них, невзирая на глубину вызовов — оченно подходят эксепшены.
но это как раз и есть ситауция, когда их следует применять. я же не говорил что ексепшены вообще не нужны в принципе.
но просто кидать рядовые ошибки с их помощью — неразумно.
Здравствуйте, merk, Вы писали:
M>по моему очевидно, что покидание контекста возникновения ошибки приводит к трудности ее исправления. теряются детали. вы же утверждаете общо — что мол там перехватим где удобно! но это слишком общо. M>я же утверждаю, что локализовать ошибку можно только где-то вблизи ее возниконовения. и даже нужно.
В пользовательском коде известно, что нужно делать в случае возникновения проблемы, а в общем — нет.
До последнего не верил в пирамиду Лебедева.
Re[3]: Что Вам мешает в С++?
От:
Аноним
Дата:
25.06.08 20:57
Оценка:
GN>После паскаля, думаю, сложно понять язык. Это ничто иное, как современный стандартизованный (кроссплатформенный) ассемблер. К сведению — традиционные ассемблеры сейчас могут переплюнуть в
выделенное — оксюморон
Здравствуйте, minorlogic, Вы писали:
M>Сама идея что обработать ошибку по месту удобнее — ошибочна.
M>Типичный пример , ошибка выделения памяти , ну как прикажешь ее локально обработать ?
интересно как вы предлагаете ее обработать нелокально.
что вы будете делать если возникла такая ошибка?
Здравствуйте, merk, Вы писали:
M>Здравствуйте, minorlogic, Вы писали:
M>>Сама идея что обработать ошибку по месту удобнее — ошибочна.
M>>Типичный пример , ошибка выделения памяти , ну как прикажешь ее локально обработать ?
M>интересно как вы предлагаете ее обработать нелокально. M>что вы будете делать если возникла такая ошибка?
Так и бум отвечать вопросом на вопрос?
А все просто , наверху я могу изменить параметры и попытаться снова или отказаться от операции, все зависит от программы.
Есть отличное империческое правило
"кидайте исключение если вы не можете выполнять дальнейшии операции"
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, merk, Вы писали:
M>>Здравствуйте, minorlogic, Вы писали:
M>>>Сама идея что обработать ошибку по месту удобнее — ошибочна.
M>>>Типичный пример , ошибка выделения памяти , ну как прикажешь ее локально обработать ?
M>>интересно как вы предлагаете ее обработать нелокально. M>>что вы будете делать если возникла такая ошибка?
M>Так и бум отвечать вопросом на вопрос?
ответ на вопрос простой и вовсе не ваш. ошибка выделения памяти относится к критическим ошибкам, при которых очень трудно восстановиться и продолжить работу. лучше тут стараться корректно завершаться с максимальным сохранением данных. как это сделать — это оставляю вам.
M>А все просто , наверху я могу изменить параметры и попытаться снова или отказаться от операции, все зависит от программы.
если у вас недостаток памяти, все ваши трепыхания ни к чему не приведут. см. совет выше.
M>Есть отличное империческое правило M>"кидайте исключение если вы не можете выполнять дальнейшии операции"
рекомендация слишком обща. непонятно что имеется ввиду — вы в принципе не имеете возможности написать регулярным кодом продолжение работы, или вам просто это кажется?
M>напрмиер в псевдокоде.
M>void readHeaderFromFile(filename) M>{ M> file f(filename); M> if(f.error()) M> { M> throw ("open file error"); M> }
M> readHeader(f); M>}
и что? в 100 местах программы вы вызываете эту функцию.
и в ста местах программы вы будете ее писать в конструкции
try{
readHeaderFromFile(filename)
} catch ....
не утомительно?
вообще функция очевидно косорукая. любая функция может и часто должна иметь предусловия.
в вашем случае просто валидность имени файла. не пустое имя, не нуль(если указатель), правильно сформированное. это — ну например.
вы ж без проверки, тут же конструируете обьект, обламываетесь например в конструкторе, и всю кучу возможных ошибок, то есть —
невалидность имени, факт существования файла, существование файловой системы вообще, заблокированность файла кем-то другим, заблокированность файловой системы и прочие ошибки ввода вывода... завернули в исключение "ошибка открытия файла", и кинули наружу.
и уже готовы меня убедить, что сможете восстановиться от ошибки.
КАК? вы же в реальности не знаете что произошло.
если вы будете проверять предусловия(когда-нить в жизни), вы будете тоже генерить исключения??? тогда вызов каждой функции будете делать в блоке try{} что-ли??? не утомительный ли стиль?
короче. вот тут наткнулся на какое-то руководство... ну совершенно согласен с автором. особенно обратите внимание на конец страницы — 11.5. Исключения и вопросы проектирования http://valera.asf.ru/cpp/book/c11.shtml
[snip]
M>>Есть отличное империческое правило M>>"кидайте исключение если вы не можете выполнять дальнейшии операции" M>рекомендация слишком обща. непонятно что имеется ввиду — вы в принципе не имеете возможности написать регулярным кодом продолжение работы, или вам просто это кажется?
Так себе и представляю: сидит разработчик и думает "тут я в принципе не могу написать продолжение, а тут могу, но, мне кажется, что в принципе не могу". Кто эту разницу сможет обнаружить?
M>>напрмиер в псевдокоде.
M>>void readHeaderFromFile(filename) M>>{ M>> file f(filename); M>> if(f.error()) M>> { M>> throw ("open file error"); M>> }
M>> readHeader(f); M>>}
M>и что? в 100 местах программы вы вызываете эту функцию. M>и в ста местах программы вы будете ее писать в конструкции M>try{ M> readHeaderFromFile(filename) M>} catch ....
M>не утомительно?
Утомительно, конечно, а зачем так писать? Перехватывайте исключения на более высоком уровне. В нормальных проектах try catch не так уж и часто встречаются.
M>вообще функция очевидно косорукая. любая функция может и часто должна иметь предусловия. M>в вашем случае просто валидность имени файла. не пустое имя, не нуль(если указатель), правильно сформированное. это — ну например.
Т.е. пользователь ввел имя, мы его проверили, передаем в функцию обработки, там мы его тоже проверяем, передаем в readHeaderFromFile — проверяем и там, дальше оно идет в конструктор file, который, очевидно, снова должен его проверить... Это только мне кажется, что в этой схеме что-то не так?
M>вы ж без проверки, тут же конструируете обьект, обламываетесь например в конструкторе, и всю кучу возможных ошибок, то есть — M>невалидность имени, факт существования файла, существование файловой системы вообще, заблокированность файла кем-то другим, заблокированность файловой системы и прочие ошибки ввода вывода... завернули в исключение "ошибка открытия файла", и кинули наружу. M>и уже готовы меня убедить, что сможете восстановиться от ошибки. M>КАК? вы же в реальности не знаете что произошло.
Кажется я не совсем понял это Ваше высказывание. Вы хотели сказать, что по существу, Вам возразить нечего и потому придираетесь к примеру, в котором для краткости все эти очевидные детали опущены, правильно? Вы считаете, что с помощью исключений всю эту информацию, в принципе, нельзя передать наружу?
M>если вы будете проверять предусловия(когда-нить в жизни), вы будете тоже генерить исключения??? тогда вызов каждой функции будете делать в блоке try{} что-ли??? не утомительный ли стиль?
Да. Нет, а зачем? Очень утомительный, поэтому так никто не делает, исключения перехватываются на более высоком уровне. В частности, нарушение предусловий, как правило, означает ошибку в логике программы, восстановиться после нее нельзя (ну, разве, что послать письмо разработчикам, чтобы они ее пофиксили и прислали патч, произвести горячую замену кода и продолжить работу ), поэтому вполне может хватить одного обработчика, который нарисует окошко с сообщением о критическом сбое в программе и т.п.
[snip]
The last good thing written in C was Franz Schubert's Symphony No. 9.
Здравствуйте, gear nuke, Вы писали:
> К сведению — традиционные ассемблеры сейчас могут переплюнуть в метапрограммировании любые шаблоны. Только писанины там будет...
LOL я то глупый думал, что макросы да шаблоны как раз предназначены для уменьшения писанины
> вот Страуструп тоже устал писать на традиционном ассемблере...
Страуструп устал дожидаться когда Simula ему курсовик сосчитает
Здравствуйте, merk, Вы писали:
M>>void readHeaderFromFile(filename) M>>{ M>> file f(filename); M>> if(f.error()) M>> { M>> throw ("open file error"); M>> }
M>> readHeader(f); M>>}
M>и что? в 100 местах программы вы вызываете эту функцию. M>и в ста местах программы вы будете ее писать в конструкции M>try{ M> readHeaderFromFile(filename) M>} catch ....
С чего ты взял что если фугкция генерит исключение то она должна сразу оборачиватся в try catch ? это неверная пердпосылка и дальнейшие рассуждения неверны.
Здравствуйте, gear nuke, Вы писали:
GN>Или internal compiler error — очень вразумительное сообщение об ошибке
Подобное честно говоря последний раз встречал в VC6...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gear nuke, Вы писали:
GN>>Или internal compiler error — очень вразумительное сообщение об ошибке CC>Подобное честно говоря последний раз встречал в VC6...
Да, VS 2005 современно падаает
Здравствуйте, crable, Вы писали:
C>Утомительно, конечно, а зачем так писать? Перехватывайте исключения на более высоком уровне. В нормальных проектах try catch не так уж и часто встречаются.
я спорил с утверждением, что коды возврата позволяют их игнорировать. и потому — исключения!
теперь вы советуете игнорировать исключения. точки зрения взаимоисключающие.
C>Т.е. пользователь ввел имя, мы его проверили, передаем в функцию обработки, там мы его тоже проверяем, передаем в readHeaderFromFile — проверяем и там, дальше оно идет в конструктор file, который, очевидно, снова должен его проверить... Это только мне кажется, что в этой схеме что-то не так?
ввода имени пользователем в коде нет. если имя вводит пользователь, очевидно, что его сначала нужно проверить, поскольку невалидность имени будет очевидной ошибкой пользователя. и он должен ее исправить.
хотя бы приблизительную валидность имени, непустое, не nil, стоит проверить и предусловием в функции.
конструктор класса File тоже должен проверять, хотя бы очевидную невалидность. и что? если все они используются в разных контекстах, то по крайней мере хоть одна проверка должна быть. если проверки накладываются, как в данном случае, хуже не будет. Это спор не об именах файла, а о предусловиях вообще.
C>Кажется я не совсем понял это Ваше высказывание. Вы хотели сказать, что по существу, Вам возразить нечего и потому придираетесь к примеру, в котором для краткости все эти очевидные детали опущены, правильно? Вы считаете, что с помощью исключений всю эту информацию, в принципе, нельзя передать наружу?
можно, только толку мало. если пользователь(см выше) ошибся в имени, ошибка вида — не могу открыть файл, мало что ему говорит. непонятно куда бежать. то ли имя править, то ли звать программиста(нарушение предусловий), то ли сисадмина(типа сетевой диск отсутствует).
C>Да. Нет, а зачем? Очень утомительный, поэтому так никто не делает, исключения перехватываются на более высоком уровне. В частности, нарушение предусловий, как правило, означает ошибку в логике программы, восстановиться после нее нельзя (ну, разве, что послать письмо разработчикам, чтобы они ее пофиксили и прислали патч, произвести горячую замену кода и продолжить работу ), поэтому вполне может хватить одного обработчика, который нарисует окошко с сообщением о критическом сбое в программе и т.п.
согласен с оратором. если предусловия сформулированы правильно, их нарушение — это неустранимая ошибка. нужно звать программера.
C>[snip]
Здравствуйте, merk, Вы писали:
M>я спорил с утверждением, что коды возврата позволяют их игнорировать. и потому — исключения! M>теперь вы советуете игнорировать исключения. точки зрения взаимоисключающие.
Вы бы не путали. Игнорирование кода возврата приведёт к неопределённому поведению, а "игнорирование" (которые сейчас вы имели в виду) исключения — ко вполне определённым последствиям.
Не надо понятия подменять. С исключениями я не могу вызвать new и получить 0 с последующим AV.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, merk, Вы писали:
M>>я спорил с утверждением, что коды возврата позволяют их игнорировать. и потому — исключения! M>>теперь вы советуете игнорировать исключения. точки зрения взаимоисключающие.
VE>Вы бы не путали. Игнорирование кода возврата приведёт к неопределённому поведению, а "игнорирование" (которые сейчас вы имели в виду) исключения — ко вполне определённым последствиям. VE>Не надо понятия подменять. С исключениями я не могу вызвать new и получить 0 с последующим AV.
это вам не нужно подменять понятия.
я уж сто раз говорил о неустранимых ошибках. что и должно оформляться как исключения.
ошибки эти — нарушение инвариантов непротиворечивости системы. как то — деление на нуль, недостаток памяти, нарушение предусловий и проч.
способ реакции на эти ошибки — верная диагностика и завершение работы.
прыгающие через контексты исключения как раз для этого и приспособлены.
ноль в указателе вы можете получить просто присвоением туда нуля. и исключения не будет.
что ж касается исключения в new или getmem, то по результату функции прямо видно, удалась функция или нет. наличие исключения тут в принципе некритично.
аналогично с выбором элемента их списка, хотите взять элемент, а его там нет. тоже для невозможности игнора бросать исключение, или просто проверить на не null? а если не проверить — то можно упасть? по вашей схеме НУЖНО генерить исключение. так? если не так, то почему функция взятия нечта из списка свободной памяти менеджера кучи, должна бросить исключение, а взятие элемента из другого списка — нет?
..щас будет дискуссия о добре и зле, поскольку четкого ответа на этот вопрос нет.
Здравствуйте, crable, Вы писали:
C>Т.е. пользователь ввел имя, мы его проверили, передаем в функцию обработки, там мы его тоже проверяем, передаем в readHeaderFromFile — проверяем и там, дальше оно идет в конструктор file, который, очевидно, снова должен его проверить... Это только мне кажется, что в этой схеме что-то не так?
Кроме того, что операция производится много раз, тут есть более глубокая проблема. Она состоит в том, что какие-нибудь козлы могут стереть наш файл уже после всех проверок, но до того, как мы его откроем, запретив тем самым его удаление.
В принципе хотелось бы программировать как-то так, чтобы случай "пользователь ввёл имя несуществующего файла" и "пользователь ввёл имя файла, который удалили до того, как мы успели его открыть" не отличался по логике поведения программы, с точки зрения пользователя.
Так что в этом смысле предварительные проверки верности имени файла могут использоваться только дл яоптимизации
Мало файл, который мы в конце концов открыли, может оказаться, например, расположенным на флешке. И флешку могут вынуть из нашего компа в любой момент. Хотелось бы чтобы и на это событие наша программа реагировала адекватно. Соответсвенно, если мы спроектировали систему обработки ошибок как-то так, что ошибки возбуждаются по месут возникновения, обрабатываются где-то на высоком очень и абстрактном уровне (например на уровне запроса), а весь промежуточный код исключительно обеспечивает безопасность исключений, и больше никак не заморачивается на обработку всех мыслемых ошибок, которые могут произойти в вызываемом им коде...
Так обычно строят обработку исключительных ситуаций на исключениях. Есть стратегии делать то же на кодах возврата. IMHO они хуже, но тоже есть, и так тоже можно писать. Но тогда таки нужны примеры, и, хотя бы, изложения способа обработки имключительных ситуаций в программе в целом, а то не о чём разговор выходит
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, merk, Вы писали:
VE>>Здравствуйте, merk, Вы писали:
M>..щас будет дискуссия о добре и зле, поскольку четкого ответа на этот вопрос нет.
Как раз есть, просто вы этот ответ упорно не хотите принимать. У меня складывается впечатление, что у вас совершенно не правильное представление о том, для чего в C++ предназначены исключения. C++ exceptions — это лишь средство для сообщения об ошибках, а не о каких то исключительных ситуациях. Это замена кодам возврата. Произошла ошибка в программе — сгенерировали исключение и всё. Зачем усложнять? О том, что считать ошибкой, а что нет, можно почитать например у Саттера (да и Мейерс об этом вроде писАл тоже).
Внутри одно проекта (или хотябы модуля) необходимо определить какой подход к обработке ошибок использовать: основаный на исключениях либо на кодах возврата и строго его придерживаться. А что касается спора по поводу использования кодов возврата либо исключений — дык он уже давно завершился (не в пользу кодов возврата).
Re: Что Вам мешает в С++?
От:
Аноним
Дата:
26.06.08 10:34
Оценка:
Здравствуйте, remark, Вы писали:
R>Что Вам мешает в С++?
Все замечательно, когда мы пишем код сами, но самое веселое начинается, когда нужно использовать/интегрировать проекты соседнего отдела. Тут сказывается плохая поддержка компонентной модели, решено кажется везде где можно, Common Lisp, OCaml, Java, .NET.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, merk, Вы писали:
M>>это вам не нужно подменять понятия.
VE>Не надо только детский сад устраивать.
VE>С Вами скучно спорить, аргументов серьёзных нет, а доказывать что-то Вам лично я не хочу.
не парьтесь. спор давно окончен. я уже привел ссылку на учебник, с которым полностью согласен.
если мои высказывания ему противоречат, то они считаются несостоятельными.
для целостности подхода вам советую во всех функциях, где возможен возврат null просто генерить исключения.
это будет посильнее фауста гете, потом их обрабатывать.
главное, чтобы это кто-то купил.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, merk, Вы писали:
VE>>>Здравствуйте, merk, Вы писали:
M>>..щас будет дискуссия о добре и зле, поскольку четкого ответа на этот вопрос нет.
А>Как раз есть, просто вы этот ответ упорно не хотите принимать. У меня складывается впечатление, что у вас совершенно не правильное представление о том, для чего в C++ предназначены исключения. C++ exceptions — это лишь средство для сообщения об ошибках, а не о каких то исключительных ситуациях. Это замена кодам возврата. Произошла ошибка в программе — сгенерировали исключение и всё. Зачем усложнять? О том, что считать ошибкой, а что нет, можно почитать например у Саттера (да и Мейерс об этом вроде писАл тоже). А>Внутри одно проекта (или хотябы модуля) необходимо определить какой подход к обработке ошибок использовать: основаный на исключениях либо на кодах возврата и строго его придерживаться. А что касается спора по поводу использования кодов возврата либо исключений — дык он уже давно завершился (не в пользу кодов возврата).
то есть читаем это http://valera.asf.ru/cpp/book/c11.shtml
и категорически не соглашаемся?
там перечислены характерные признаки для исключительных ситуаций. они названы аномальными, и фактически неустранимыми.
несоглашаться — ваше право.
"дык давно завершившийся спор..." в какой-нить институтской курилке, вообще не аргумент.
Здравствуйте, merk, Вы писали:
M>не парьтесь. спор давно окончен. я уже привел ссылку на учебник, с которым полностью согласен. M>если мои высказывания ему противоречат, то они считаются несостоятельными.
Не, ну тогда да, с тобой действительно не о чем разговаривать. Лчше тот учебник почитать. Хотя он мне, например, не кажется идеалом...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, merk, Вы писали:
M>"дык давно завершившийся спор..." в какой-нить институтской курилке, вообще не аргумент.
Вне всяких сомнений гужевой транспорт рулит, а ДВС используется так часто совершенно неоправданно?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, merk, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, merk, Вы писали:
VE>>>>Здравствуйте, merk, Вы писали:
M>>>..щас будет дискуссия о добре и зле, поскольку четкого ответа на этот вопрос нет.
А>>Как раз есть, просто вы этот ответ упорно не хотите принимать. У меня складывается впечатление, что у вас совершенно не правильное представление о том, для чего в C++ предназначены исключения. C++ exceptions — это лишь средство для сообщения об ошибках, а не о каких то исключительных ситуациях. Это замена кодам возврата. Произошла ошибка в программе — сгенерировали исключение и всё. Зачем усложнять? О том, что считать ошибкой, а что нет, можно почитать например у Саттера (да и Мейерс об этом вроде писАл тоже). А>>Внутри одно проекта (или хотябы модуля) необходимо определить какой подход к обработке ошибок использовать: основаный на исключениях либо на кодах возврата и строго его придерживаться. А что касается спора по поводу использования кодов возврата либо исключений — дык он уже давно завершился (не в пользу кодов возврата).
А>"C++ для начинающих"? А>Читаем Саттера, Александреску, Мейерса и переходим на следующий уровень
??? не я давал название учебнику.
уровень его вполне достойный. на западе книжки типа...для чайников — традиционный коммерческий ход, для привлечения аудитории. и порой какая-нить ..."для профессионалов" куда бестолковей.
аргумент не принимается.
дайте заодно ссцылу не на маркса,энгельса,чаушеску, а на конкретную толковость, где ваша точка зрения не изложена столь сумбурно. я почитаю, почему нет?
А>P.S. Почему в этом вопросе с вами здесь никто не соглашается?
никто, это кто? даже если сам страуструп со мной не согласился, это не значит еще — никто.
Здравствуйте, merk, Вы писали:
А>>Читаем Саттера, Александреску, Мейерса и переходим на следующий уровень M>??? не я давал название учебнику. M>уровень его вполне достойный. на западе книжки типа...для чайников — традиционный коммерческий ход, для привлечения аудитории. и порой какая-нить ..."для профессионалов" куда бестолковей.
Не, ну то есть тебе он кажется авторитетнее Саттера, Александреску и Мейерса со Страуструпом?
УВАЖАЮ!!!
А>>P.S. Почему в этом вопросе с вами здесь никто не соглашается? M>никто, это кто? даже если сам страуструп со мной не согласился, это не значит еще — никто.
Ну а кто таки соглашается?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Alexander G, Вы писали:
AG>Не то чтобы мне сильно хотелось чтобы std::function была частью языка, но всё же было бы лучше именно так.
Вобще говоря это дело реализации.
Те весь STL вполне может быть реализованно компилятором.
Таким образом если разработчик компилятора решит что std::function лучше реализовать компилятором то именно так он и сделает.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, <Аноним>, Вы писали:
GN>>После паскаля, думаю, сложно понять язык. GN>>Это ничто иное, как современный стандартизованный (кроссплатформенный) ассемблер. А>выделенное — оксюморон
Нет желания дискутировать? zen it Суть вещей всегда "до смешного просто"
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Gluk_Kazan, Вы писали:
G_K>LOL я то глупый думал, что макросы да шаблоны как раз предназначены для уменьшения писанины
Верно, клиентский код сокращается, но из этого совсем не следует. что библиотечный будет автоматически сгенерирован компилятором
G_K>Страуструп устал дожидаться когда Simula ему курсовик сосчитает
Поэтому ему и нужен был язык уровня ассемблера.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, remark, Вы писали:
R>Что Вам мешает в С++?
Тему не читал, по сабжу:
1. Переусложненность. Не нравится решать проблемы на пустом месте, решения которых нужны только компилятору. POD-типы инициализируются, а пользовательские нет (это и к вопросу о нелогичности). Функциям нужен прототип, даже если они находятся в этом же самом .cpp файле на 15 строк ниже. Класс со static-переменной не вызывает ошибок линковки, но глобальная static-переменная вызывает; инициализация же static-члена в классе сейчас в вообще невозможна и вне классе в хидере вызывает ошибку линковки. Вы уважаете право компилятора быть ленивым и капризным? Я нет. Я наоборот стараюсь автоматизировать максимум своей работы.
2. Непоследовательность и нелогичность грамматики. Можно придумать сотни как вырожденных примеров (типа new A<B>(0) == false если A это не шаблон), так и обоснованных (почему if (int x = 1) компилируется, а if (Foo x(1)) нет?). Дай бог чтобы в следующем стандарте это все почистили, но лично я тут настроен пессимистично — мешает и обратная совместимость, и сам подход (который и привел к такой ситуации) у авторов языка остался прежним.
3. Несовместимость. C++ плохо совместим даже сам с собой, в буквальном смысле. Проблемы даже в пределах одного компилятора: при пересечении границ процессов, DLL, при поставке новых сборок двоичных файлов в систему мелких модулей, при интеграции сторонних библиотек. Про такую фантастику, как собрать один модуль системы одним компилятором, а вторую другим, я не буду сильно распространяться, чтобы не трепать вам нервы Есть почти 100-ная зависимость: чем больше вы считаете .Net высосанной из пальца штукой, тем больше вы не согласны с этим пунктом.
Да я понимаю, всё рано или поздно исправят (сурово наступив себе на яйца — в ущерб обратной совместимости), но смотря что вдохновители некоторых C++ библиотек вносят в D например, я боюсь они просто наделают новых проблем. Многим программистам нравится именно сложность, им нравится быть профи, нравится знать, почему то что выглядит как строка и называется строкой не является строкой вообще, но мне уже надоело. Я согласен иметь дело с ним, если он будет применяться в 5% специфического низкоуровневого софта, а остальное писать на чем-нибудь более вменяемом (но см. пункт про совместимость — есть ли вообще у него такой шанс?).
Здравствуйте, Roman Odaisky, Вы писали:
RO>Как можно оставить возможность создания объектов на стеке и избежать перекомпиляции при изменении внутренней структуры объектов?
Back-patching еще в Dragonbook описан, осталось немного пофантазировать. Еще, размер и оффсеты на мемберы можно сделать не непосредственными операндами опкодов, а хранить как данные. Тогда можно будет даже в рантайме менять... Заплитить лишней косвенностью, как сейчас с VTbl.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Roman Odaisky, Вы писали:
RO>Для производительности. Чтобы можно было всё инлайнить. Чтобы можно было реализовать статический полиморфизм. За это приходится платить увеличением времени компиляции. Неужели не понятно?
Непонятно, почему из-за этого страдает JIT. Это легко в тех же C, asm, Forth, не говоря про многие высокоуровневые языки. Хотя сказано, что можно без файлов (16.2/2)
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, merk, Вы писали:
M>ответ на вопрос простой и вовсе не ваш. ошибка выделения памяти относится к критическим ошибкам, при которых очень трудно восстановиться и продолжить работу. лучше тут стараться корректно завершаться с максимальным сохранением данных.
Написанный в соответствии с этим "правилом" софт не является надёжным, любое сторонее приложение может его завершить (хорошо еще, если это не приведёт к краху всей системы).
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Sergey, Вы писали:
S>CreatorCray пишет:
>> S>а вот с какой целью изготовили похожую на нее WTL и, особенно, почему >> S>люди ей пользуются — для меня загадка. >> WTL ИМХО больше на MFC похожа.
S>Ну не знаю. Внутри она устроена как оконная часть ATL, из которой S>собственно и сделана — с чего бы ей быть похожей на MFC? DDX разве что S>приделали MFC-образный.
>> Пользуются потому, что удобнее чем MFC. >> Не требует ничего тащить с программой — никаких dependencies.
S>Что тащить ничего не надо — это замечательно. Но вот что она S>обеспечивает такого, чего нет в винапи? Докинг там скажем или что-нибудь S>подобное wxSizer? Или GDI объекты умеет правильно уничтожать, как та же S>wxWidgets? Или куча стронних контролов под нее есть, как под MFC? S>IMHO, без разницы — на голом винапи писать или с WTL.
Давненько пользовался WTL, но помнится, что была эта штука просто незаменима при написании всяких dislog based утилит. Контролов под нее можно найти достаточно много, сайзер встроен, ну, а близость к API — иногда очень полезна, IMHO
Qt и wxWidgets не пользовался (wxWidgets смотрел доки, примеры...), но активно пользовался MFC. В принципе — никаких претензий, но было бы замечательно (IMHO), если бы ее разбили на несколько библиотек и вот "оконной" частью такой "побитой" MFC могла бы стать WTL
Ну и в догонку, что мешает. Бинарная несовместимость — библиотеку построенную одним компилятором не прикрутишь в другому. И про модульность и инклуды тут хорошо было сказано. Иногда занимался комбинаторикой, переставляя инклуды для того, чтобы оно скомпилировалось (не исключаю кривость рук)
А в целом — С++ отличнейшая штука
Re[8]: Что Вам мешает в С++?
От:
Аноним
Дата:
26.06.08 16:27
Оценка:
I>Ну и в догонку, что мешает. Бинарная несовместимость — библиотеку построенную одним компилятором не прикрутишь в другому
Как вы себе представляете прикручивание библиотеки скомпиленной под IA64 в проект для arm'а какого нить?
Здравствуйте, remark, Вы писали:
R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>Что Вам мешает в С++?
R>...
На днях один мой знакомый побывал на самом крупном столичном книжном рынке. Там очаровательная блондинка потрясла его известием: "С++ больше нет, теперь вместо него С#"
Здравствуйте, Аноним, Вы писали:
А>Как вы себе представляете прикручивание библиотеки скомпиленной под IA64 в проект для arm'а какого нить?
А собранную gcc к собранному VC предатсаляешь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Кё>3. Несовместимость. C++ плохо совместим даже сам с собой, в буквальном смысле. Проблемы даже в пределах одного компилятора: при пересечении границ процессов, DLL, при поставке новых сборок двоичных файлов в систему мелких модулей, при интеграции сторонних библиотек. Про такую фантастику, как собрать один модуль системы одним компилятором, а вторую другим, я не буду сильно распространяться, чтобы не трепать вам нервы Есть почти 100-ная зависимость: чем больше вы считаете .Net высосанной из пальца штукой, тем больше вы не согласны с этим пунктом.
Плохая идея сравнивать кроссплатформенный ЯП которым является С++, и платформу, которыми являются .нет и жаба.
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, merk, Вы писали:
M>>ответ на вопрос простой и вовсе не ваш. ошибка выделения памяти относится к критическим ошибкам, при которых очень трудно восстановиться и продолжить работу. лучше тут стараться корректно завершаться с максимальным сохранением данных.
GN>Написанный в соответствии с этим "правилом" софт не является надёжным, любое сторонее приложение может его завершить (хорошо еще, если это не приведёт к краху всей системы).
я бы вам посоветовал все таки спасаться. поскольку без памяти программы обычно не работают.
выташите все модули памяти из компа и перезагрузитесь.
каким образом по-вашему стороннее приложение может завершить другое, через нехватку памяти? через захват общей памяти системы? тогда его, стороннее, обязана завершить ос. чтобы не баловалось.
Здравствуйте, merk, Вы писали:
M>каким образом по-вашему стороннее приложение может завершить другое, через нехватку памяти? через захват общей памяти системы? тогда его, стороннее, обязана завершить ос. чтобы не баловалось.
OS вообще-то разные бывают...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, merk, Вы писали:
M>>каким образом по-вашему стороннее приложение может завершить другое, через нехватку памяти? через захват общей памяти системы? тогда его, стороннее, обязана завершить ос. чтобы не баловалось.
E>OS вообще-то разные бывают...
Егор, ваши знания поистине безграничны.
Re[26]: Тебя часом не Вольки ибно Алёша зовут? :)))
Здравствуйте, merk, Вы писали:
E>>OS вообще-то разные бывают... M>Егор, ваши знания поистине безграничны.
Это смотря с чьими сравнивать...
Но в целом ты меня поразил глубиной своих познаний...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[27]: Тебя часом не Вольки ибно Алёша зовут? :)))
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, merk, Вы писали:
E>>>OS вообще-то разные бывают... M>>Егор, ваши знания поистине безграничны. E>Это смотря с чьими сравнивать...
E>Но в целом ты меня поразил глубиной своих познаний...
Здравствуйте, merk, Вы писали:
M>егор, вы приблизительно помните название топика?
Что-то про анотомию плохих тонцоров?
Но в целом вроде как ты, конкретно, развивал тему про вредоносность программистов использующих исключения для чего-то кроме авоста...
Или я тебя как-то не так понял?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, IROV.., Вы писали:
IRO>Здравствуйте, remark, Вы писали:
R>>Что Вам мешает в С++? IRO>Отсутствие приватных методов и членнов которые бы не были видны в .hpp фаилах. Например.
IRO>Foo.hpp IRO>
тут проблема в том, что компайлер по декларации класса вычисляет его размер. а если будет браться экземпляр класса, например как поле нового класса, то физразмер поля нужен обязатно. но если только поинтер, то физразмер необязатно.
проблема может быть решена только разбиением представления класса на видимые поля и сцылу(указатель) на невидимые поля в обьекте класса.соответсвенно при доступе к невидимым нужна дополнительная косвенность. сами невидимые будут располагаться где-то вне обьекта данного класса, состоящего из видимых полей.
поскольку в С++ невидимость может быть нарушена например френдами, то для компиляции френдов скрытые поля все равно нужно как-то открыть, а их из хидеров не видно... или отказаться от френдов вообще.
короче даже если страструп и думал бы над этим, все это запутало и без того не особо распутанный его концепт.
Здравствуйте, merk, Вы писали:
M>короче даже если страструп и думал бы над этим, все это запутало и без того не особо распутанный его концепт.
Вообще-то можно было бы просто использовать недовычесленные выражения, вроде "размер того-то + рамер того-то +..."
А при линковке всё досчитывать и генерить код окончательно.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, merk, Вы писали:
M>>короче даже если страструп и думал бы над этим, все это запутало и без того не особо распутанный его концепт.
E>Вообще-то можно было бы просто использовать недовычесленные выражения, вроде "размер того-то + рамер того-то +..." E>А при линковке всё досчитывать и генерить код окончательно.
а если обьект получается из dll? компилятор вообще его размера не знает, что-ли? ну там в поля ему залезть?
рекомендация — положить видимые первыми, не проходит если у вас есть наследник от такого класса. в наследнике между видимыми предка и видимыми наследника будут невидимые предка.
еще. поскольку в С++ нет модулей, то к одному хидеру может идти несколько реализаций, или реализация может быть растащена на много файлов. скрытые поля по сути недекларированы в хидере и могут быть получаиццо обьявлены где-то. в неограниченном количестве, в неограниченном количестве файлов. скрытые поля являются суммой всех найденных обьявлений? или могут быть обьявлены только в одном файле? но в С++ такого выделенного файла нет. значит сумма.
Здравствуйте, merk, Вы писали:
M>а если обьект получается из dll? компилятор вообще его размера не знает, что-ли? ну там в поля ему залезть? M>рекомендация — положить видимые первыми, не проходит если у вас есть наследник от такого класса. в наследнике между видимыми предка и видимыми наследника будут невидимые предка.
Ну и что? Ну экспортировался бы из dll ещё и какой-то описатель приватной части объектов? Ты же просто символы из DLL экспортируешь? Почему лэйаут объектов нельзя?
M>еще. поскольку в С++ нет модулей, то к одному хидеру может идти несколько реализаций, или реализация может быть растащена на много файлов. скрытые поля по сути недекларированы в хидере и могут быть получаиццо обьявлены где-то. в неограниченном количестве, в неограниченном количестве файлов. скрытые поля являются суммой всех найденных обьявлений? или могут быть обьявлены только в одном файле? но в С++ такого выделенного файла нет. значит сумма.
Ну будет нарушение ODR. Как будто что-то новое в этом есть
В целом, при желании, можно прямо сейчас доработать С++ напильником до того, чтобы приватную часть класса не показывать. Типа пишешь какой-то хедер, в котором только публичный интерфейс + ещё один файл особого вида, где есть полное описание. Из этого файла это описание экспортируется в другие единицы трансляции и всё. Каких-то непреодолимых особо пролем нет. Просто это не особо кому-то надо
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, merk, Вы писали:
M>я бы вам посоветовал все таки спасаться. поскольку без памяти программы обычно не работают. выташите все модули памяти из компа и перезагрузитесь.
Отличный пример Я услышу звуковые сигналы "нет памяти". Если бы разработчики BIOS следовали "спасительному правилу", был бы бесконечный цикл попыток загрузки
M>каким образом по-вашему стороннее приложение может завершить другое, через нехватку памяти? через захват общей памяти системы?
Например, да. Главное, что если какие-то способы неизвестны, это не значит, что их нет. Не в тему, но для развития фантазии можно погуглить, как Joanna Rutkowska загружала код в ядро Vista.
M>тогда его, стороннее, обязана завершить ос. чтобы не баловалось.
На каком основании? Запрос памяти приложением — лагальное действие.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Erop, Вы писали:
E>Ну и что? Ну экспортировался бы из dll ещё и какой-то описатель приватной части объектов? Ты же просто символы из DLL экспортируешь? Почему лэйаут объектов нельзя?
то есть dll ный загрузчик будет еще и с размерами в программе разбираццо?
смело шагает маладешь к виртуальным машинам!
E>Ну будет нарушение ODR. Как будто что-то новое в этом есть
никакого нарушения одр. разные поля в разных файлах. реально декларацию класса придется собирать по кускам из произвольного множества файлов.
E>В целом, при желании, можно прямо сейчас доработать С++ напильником до того, чтобы приватную часть класса не показывать. Типа пишешь какой-то хедер, в котором только публичный интерфейс + ещё один файл особого вида, где есть полное описание. Из этого файла это описание экспортируется в другие единицы трансляции и всё. Каких-то непреодолимых особо пролем нет. Просто это не особо кому-то надо
это как раз особо и надо. в частности для простецкой реализации приблуды типа фасад. да и вообще удобного сокрытия. вот только делать это нужно ручками, рисуя поинтер либо на раелизующий класс, либо скрытые поля, например. попытка разместить эт она стеке будет ужасающей по производительности, за счет размещения части обьекта на куче.
клиент желает истинного сокрытия своих полей от потребителя класса. а если есть какой-то "файл специального вида", то он доступен потребителю. в данном случае — "другие единицы трансляции" это именно файлы потребителя.
также будет невозможно писать реализации отдельных методов класса прямо в хидере, поскольку в нем приватных полей нет.
напильник у меня есть, могу подарить. но чем больше рассуждений тута, тем ближе мы становимся к интеллектуальным загрузчикам и всяким там джитам.
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, merk, Вы писали:
M>>я бы вам посоветовал все таки спасаться. поскольку без памяти программы обычно не работают. выташите все модули памяти из компа и перезагрузитесь.
GN>Отличный пример Я услышу звуковые сигналы "нет памяти". Если бы разработчики BIOS следовали "спасительному правилу", был бы бесконечный цикл попыток загрузки
биосу тут вообще память не нужна. он из пзу работает. у него не нехватка памяти, а необнаружение нечта. и поскольку он совершенно функционален и без вашей памяти, он вам и пищит.
GN>Например, да. Главное, что если какие-то способы неизвестны, это не значит, что их нет. Не в тему, но для развития фантазии можно погуглить, как Joanna Rutkowska загружала код в ядро Vista.
опять ерунда. приложение от которого требуется особая устойчивость вообще не будет работать в одной среде с вашими левыми программами. это первое. второе то, что вы никакого более разумного общего способа не предложили. на самом деле есть способы сохранения некоей работоспособности, но они очень частные и в общем случае ничего не гарантируют. таким образом не могут рассматриваться как рекомендации.
тогда вы о чем вообще?
да какая разница как эта дама грузила код в ядро виста? причем тут приложение испытываюющее нехватку памяти?
приложение летит на марс на бортовом компьютере..причем тут и виста и рутковска?
M>>тогда его, стороннее, обязана завершить ос. чтобы не баловалось. GN>На каком основании? Запрос памяти приложением — лагальное действие.
запрос памяти — легальное, но с сохранением неких инвариантов, если вы требуете устойчивую среду. если приложение просит памяти выше некоего соглашения с ним и мешает другим, что не требуют памяти выше соглашения с ними, то виновато первое приложение и система его считает разрушителем инвариантов с вытекающими.
Здравствуйте, merk, Вы писали:
M>ответ на вопрос простой и вовсе не ваш. ошибка выделения памяти относится к критическим ошибкам, при которых очень трудно восстановиться и продолжить работу. лучше тут стараться корректно завершаться с максимальным сохранением данных. как это сделать — это оставляю вам.
M>>А все просто , наверху я могу изменить параметры и попытаться снова или отказаться от операции, все зависит от программы. M>если у вас недостаток памяти, все ваши трепыхания ни к чему не приведут. см. совет выше.
Как минимум в результате раскрутки стека при выбросе исключения будут уничтожены локальные объекты и это может привести к освобождения памяти(или других ресурсов). Поможет это или нет — другой вопрос.
... M>>напрмиер в псевдокоде.
M>и что? в 100 местах программы вы вызываете эту функцию. M>и в ста местах программы вы будете ее писать в конструкции M>try{ M> readHeaderFromFile(filename) M>} catch ....
M>не утомительно? M>... любая функция может и часто должна иметь предусловия.
Согласен
M>в вашем случае просто валидность имени файла. не пустое имя, не нуль(если указатель), правильно сформированное. это — ну например. M>вы ж без проверки, тут же конструируете обьект, обламываетесь например в конструкторе, и всю кучу возможных ошибок, то есть — M>невалидность имени, факт существования файла, существование файловой системы вообще, заблокированность файла кем-то другим, заблокированность файловой системы и прочие ошибки ввода вывода... завернули в исключение "ошибка открытия файла", и кинули наружу. M>и уже готовы меня убедить, что сможете восстановиться от ошибки. M>КАК? вы же в реальности не знаете что произошло.
Здесь все смешано в кучу. Не всегда все можно вынести в предусловия: даже если у нас будет функция ПолучитьОбъемДоступнойПамяти — толку от нее нет, поскольку между временем ее вызова и запросом на выделение памяти другой поток/процесс может съесть весь доступный объем. Так же и с открытием файла: нет смысла выносить в предусловие факт его существования. Успешность вызова таких функций определяется "по факту": вызов либо успешен, либо нет.
Предусловия, имхо, лучше делать "типизированными" например, если для имени файла существует валидный паттерн(и его правильность не зависит от окружения), то в первом приближении
(существование объекта filename должно гарантировать првавильность имени, которое он содержит)
Дальше: readHeaderFromFile исходя из названия должна читать header, а она еще и открывает файл, а это нарушает принцип разделения обязанностей, поэтому функциональность логичнее разделить на две части, приблизительно так:
void readHeaderFromStream(const InputStream& strm) // "типизированное" предусловие - открытый файл.
+
std::auto_ptr<InputStream> create_file_stream(const filename& name/* или const std::string&, или вообще без аргументов - имя спрашиваем у пользователя*/);
M>если вы будете проверять предусловия(когда-нить в жизни), вы будете тоже генерить исключения???
Поскольку не сказано чьи предусловия проверяются(и где это происходит), то возможны два случая:
1) проверка собственных предусловий внутри функций: — только assert и никаких исключений.
2) исключение — это нормальная ситуация, если(и только если)
* это происходит _перед_ вызовом функции чьи предусловия проверяются, и
* невозможность вызова функции(чьи предусловия проверяются) является исключительной ситуацией для вызывающего
M>тогда вызов каждой функции будете делать в блоке try{} что-ли??? не утомительный ли стиль?
Только там где исключение нужно обработать.
M>короче. вот тут наткнулся на какое-то руководство... ну совершенно согласен с автором. особенно обратите внимание на конец страницы — 11.5. Исключения и вопросы проектирования M>http://valera.asf.ru/cpp/book/c11.shtml
Видимо после таких статей и возникает желание оборачивать каждый вызов в try/catch.
Здравствуйте, gear nuke, Вы писали:
G_K>>LOL я то глупый думал, что макросы да шаблоны как раз предназначены для уменьшения писанины
GN>Верно, клиентский код сокращается, но из этого совсем не следует. что библиотечный будет автоматически сгенерирован компилятором
Не понял вашу мысль Я вам указал на то, что переплевывание в метапрограммировании при большем количестве писанины выглядит несколько ... смешно
Как впрочем и кроссплатформенные ассемблеры.
Последняя Ваша фраза просто не дошла до сознания. Видимо слишком глубока
Здравствуйте, remark, Вы писали:
R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>Что Вам мешает в С++?
Если говорить о чем то, что именно мешает, а не о фичах, которые хотелось бы.
1. Это RTTI (Run Time Type Information). В таком языке как C++ лучще бы смотрелся CTTI (Compile Time Type Information). Т.е. нужно больше информации о типе в compile time, что это за тип, какие у него функции/свойства, как называется, номер (UUID какой нибудь) и т.п. А какой то специфичный RTTI я и сам из этого сделаю.
Здравствуйте, Аноним, Вы писали:
I>>Ну и в догонку, что мешает. Бинарная несовместимость — библиотеку построенную одним компилятором не прикрутишь в другому А>Как вы себе представляете прикручивание библиотеки скомпиленной под IA64 в проект для arm'а какого нить?
merk пишет: > E>Ну будет нарушение ODR. Как будто что-то новое в этом есть > никакого нарушения одр. разные поля в разных файлах. реально декларацию > класса придется собирать по кускам из произвольного множества файлов.
Зачем произвольного? Ограничить одним — получится всем знакомое ODR.
> E>В целом, при желании, можно прямо сейчас доработать С++ напильником до > того, чтобы приватную часть класса не показывать. Типа пишешь какой-то > хедер, в котором только публичный интерфейс + ещё один файл особого > вида, где есть полное описание. Из этого файла это описание > экспортируется в другие единицы трансляции и всё. Каких-то непреодолимых > особо пролем нет. Просто это не особо кому-то надо > это как раз особо и надо. в частности для простецкой реализации приблуды > типа фасад. да и вообще удобного сокрытия. вот только делать это нужно > ручками, рисуя поинтер либо на раелизующий класс, либо скрытые поля, > например. попытка разместить эт она стеке будет ужасающей по > производительности, за счет размещения части обьекта на куче.
Не надо ничего в куче размещать, функцию alloca никто пока не отменял.
> клиент желает истинного сокрытия своих полей от потребителя класса. а > если есть какой-то "файл специального вида", то он доступен потребителю. > в данном случае — "другие единицы трансляции" это именно файлы потребителя.
С++ должен защищать от дурака, а не от террориста Так что с этим
вполне нормально.
> также будет невозможно писать реализации отдельных методов класса прямо > в хидере, поскольку в нем приватных полей нет.
Для приватных-скрытых можно ввести отдельную декларацию, типа
private extern:
> напильник у меня есть, могу подарить. но чем больше рассуждений тута, > тем ближе мы становимся к интеллектуальным загрузчикам и всяким там джитам.
Тут главное чтобы до сборки мусора дело не дошло
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, merk, Вы писали:
M>то есть dll ный загрузчик будет еще и с размерами в программе разбираццо?
Зачем? Это может быть просто частью интерфейса DLL. Если интерфейс устаревает, то надо пересобрать клиента. Это всего лишь вопрос того, насколько широко ты готов продвинуться по пути сокрытия подробностей реализации класса от его клиентов.
M>смело шагает маладешь к виртуальным машинам!
Это ты про Вирта что ли?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sergey, Вы писали:
S>Не надо ничего в куче размещать, функцию alloca никто пока не отменял.
не настолько знаю С++ чтобы автоматически распознать, где обьявляется переменная данного класса.
если она обьявляется глобально — скрытую часть нужно помещать в кучу.
если локально — можно на стеке
если делается по new — опять в куче.
>> клиент желает истинного сокрытия своих полей от потребителя класса. а >> если есть какой-то "файл специального вида", то он доступен потребителю. >> в данном случае — "другие единицы трансляции" это именно файлы потребителя.
S>С++ должен защищать от дурака, а не от террориста Так что с этим S>вполне нормально.
а от дурака он итак защищает. проблема только в том, что все приватные потроха класса торчат наружу. это конечно если не рисовать интерфейсные классы.
проблема в простоте доступа к приватным членам. например дали тебе из осторожности обьектные файлы и хидеры.
берешь хидер, снимаешь private и все. все приватные поля твои. языку пофигу, ничего перекомпилировать не нужно.
>> также будет невозможно писать реализации отдельных методов класса прямо >> в хидере, поскольку в нем приватных полей нет.
S>Для приватных-скрытых можно ввести отдельную декларацию, типа S>
private extern:
private extern — что? нужно сделать так чтобы там не было никаких имен.
опять же из соображений общности, аналогичный ход можно сделать и в отношении приватных виртуальных методов.
то есть убрать их из интерфейса. тогда компилятор извне не сможет понять индексы публичных виртметодов в виртуальной таблице.
в принципе, если б делать язык с нуля, нужно ввести модули и генерацию "хидера" из текста модуля. то есть интерфейс составляется автоматически компилятором и не пишется руками вообще.
тогда сокрытие, по простому выражалось бы так
в сгенерированном интерфейсе модуля стояло бы, ну например
class A
{
hidden[60]; //60 hidden bytes
int a; //public
int b; //public
virtual f(int fx)[20] //это обьявление публичной вирт функции и обьявление ее смещения в вирт таблице
virtual ff()[32] //еще публ.вирт функция со смещением
}
по такому описанию компилятор извне работал бы спокойно и размер типа известен и смещения виртметодов.
M>class A M>{ M> hidden[60]; //60 hidden bytes M> int a; //public M> int b; //public M> virtual f(int fx)[20] //это обьявление публичной вирт функции и обьявление ее смещения в вирт таблице M> virtual ff()[32] //еще публ.вирт функция со смещением M>}
M>по такому описанию компилятор извне работал бы спокойно и размер типа известен и смещения виртметодов.
нет. не смог бы компилятор. надо еще общий размер вирттаблицы этого класса нарисовать ему. M>class A M>{ M> hidden[60]; //60 hidden bytes M> int a; //public M> int b; //public M> virtabsize[80] ; //типа так!
virtual f(int fx)[20] //это обьявление публичной вирт функции и обьявление ее смещения в вирт таблице M> virtual ff()[32] //еще публ.вирт функция со смещением M>}
Здравствуйте, merk, Вы писали:
M>в принципе, если б делать язык с нуля, нужно ввести модули и генерацию "хидера" из текста модуля. то есть интерфейс составляется автоматически компилятором и не пишется руками вообще.
Если делать с нуля надо делать нормальные модули, ну и по желанию необязательные генерируемые хидеры, в том же D так и сделано.
Здравствуйте, merk, Вы писали:
M>в принципе, если б делать язык с нуля, нужно ввести модули и генерацию "хидера" из текста модуля. то есть интерфейс составляется автоматически компилятором и не пишется руками вообще.
Т.е. мало того что клиенты зависят от "хидера", так они еще от реализации будут зависеть(в плане необходимости перекомпиляции, ведь интерфес фактически будет изменяться при каждом изменении реализации) ??
Хотя некоторое рациональное зерно в этом есть, но имхо, "стандартные" интерфейсы в этом плане лучше...
merk пишет:
> S>Не надо ничего в куче размещать, функцию alloca никто пока не отменял. > не настолько знаю С++ чтобы автоматически распознать, где обьявляется > переменная данного класса.
Мы говорим о переделанном компиляторе или о чем?
> если она обьявляется глобально — скрытую часть нужно помещать в кучу. > если локально — можно на стеке > если делается по new — опять в куче.
Типа того.
>> > клиент желает истинного сокрытия своих полей от потребителя класса. а >> > если есть какой-то "файл специального вида", то он доступен потребителю. >> > в данном случае — "другие единицы трансляции" это именно файлы > потребителя. > > S>С++ должен защищать от дурака, а не от террориста Так что с этим > S>вполне нормально. > > а от дурака он итак защищает. проблема только в том, что все приватные > потроха класса торчат наружу. это конечно если не рисовать интерфейсные > классы.
А, ну я совсем другую проблему имел в виду — перекомпилировать
приходится каждый раз даже при изменении приватных членов.
> проблема в простоте доступа к приватным членам. например дали тебе из > осторожности обьектные файлы и хидеры. > берешь хидер, снимаешь private и все. все приватные поля твои. языку > пофигу, ничего перекомпилировать не нужно.
Допустим (хотя насколько я помню, в том же VC спецификаторы доступа
включаются в декорацию имени. Так что скорее всего будет ошибка
линковки.) Но все равно — считаем, что так сделать можно и мы придумали
механизм для запрета. Ну и что с того — делаешь пару reinterpret_cast,
правишь в памяти что надо. Защита от "террориста" в С++ невозможна в
принципе.
>> > также будет невозможно писать реализации отдельных методов класса прямо >> > в хидере, поскольку в нем приватных полей нет. > > S>Для приватных-скрытых можно ввести отдельную декларацию, типа > S> > > private extern: > > > > private extern — что? нужно сделать так чтобы там не было никаких имен.
да, лучше private extern:...; — шоб было понятно, что в данном классе
есть еще какие-то скрытые потроха. А обычные private, естественно,
остаются по старому.
> опять же из соображений общности, аналогичный ход можно сделать и в > отношении приватных виртуальных методов. > то есть убрать их из интерфейса. тогда компилятор извне не сможет понять > индексы публичных виртметодов в виртуальной таблице.
Зачем.
> > в принципе, если б делать язык с нуля, нужно ввести модули и генерацию > "хидера" из текста модуля. то есть интерфейс составляется автоматически > компилятором и не пишется руками вообще. > тогда сокрытие, по простому выражалось бы так > в сгенерированном интерфейсе модуля стояло бы, ну например > class A > { > hidden[60]; //60 hidden bytes > int a; //public > int b; //public > virtual f(int fx)[20] //это обьявление публичной вирт функции и > обьявление ее смещения в вирт таблице > virtual ff()[32] //еще публ.вирт функция со смещением > } > > по такому описанию компилятор извне работал бы спокойно и размер типа > известен и смещения виртметодов.
Язык "с нуля" меня не интересует, их и так полно, на любой вкус почти.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Да нет никакой проблемы.
Вот смотри, если каждый класс, кроме своих методов будет экспортировать несколько констант (например размер, выравнивание и объём виртуальной таблицы). А на каждую публикуемую виртуальную функцию будет экспортировтаься константа, которая обозначает позицию её дискриптора в таблице виртуальных функций, то дальше весь код можно дотачивать на этапе линковки/загрузки. Как пожелаешь.
Например, чтобы такой, не совсем доступный на этапе линковки класс (скажем класс из DLL) использовать, то при создании объекта класса, надо будет вычислить объём его хранилища. Это вычисление можно делать на момент загрузки DLL, например. То есть в загрузчике.
Ну будет в таких классах в некоторых редких случаях лишний уровень косвенности, ну и что?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>Здравствуйте, merk, Вы писали:
M>>в принципе, если б делать язык с нуля, нужно ввести модули и генерацию "хидера" из текста модуля. то есть интерфейс составляется автоматически компилятором и не пишется руками вообще.
ЮЖ>Т.е. мало того что клиенты зависят от "хидера", так они еще от реализации будут зависеть(в плане необходимости перекомпиляции, ведь интерфес фактически будет изменяться при каждом изменении реализации) ?? ЮЖ>Хотя некоторое рациональное зерно в этом есть, но имхо, "стандартные" интерфейсы в этом плане лучше...
не нужно перекомпиляции.
компилятор перегенерит хидер модуля M если
1. его еще нет
2. хеш существующего не равен хешу экспортов из модуля M.
а модуль M нужно перекомпилировать, если дата файла "хидера", что он импортирует, позднее даты обьектника модуля M. либо обьектника нет вообще.
то есть будет строго раздельная компиляция.
Здравствуйте, Gluk_Kazan, Вы писали:
G_K>Не понял вашу мысль Я вам указал на то, что переплевывание в метапрограммировании при большем количестве писанины выглядит несколько ... смешно
Препроцессоры некоторых ассемблеров могут очень много. Например, реализовать поддержку синтаксиса C, обеспечить строгую типизацию. Только придётся написать довольно много кода — это не смешно, а долго и чревато ошибками.
G_K>Как впрочем и кроссплатформенные ассемблеры.
Например, C?
G_K>Последняя Ваша фраза просто не дошла до сознания. Видимо слишком глубока
Возьмём сферическую программу на C++. Исходники можно разделить на 2 части: определение (шаблонных) классов и бизнес-логика. Второе использует "готовые" классы — это клиентский код, чем мощнее первая часть, тем он меньше (и проще). Но первую часть кто-то должен написать. Простейший helloworld в 2 строки требует несколько мегабайт библиотечного кода.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, <Аноним>, Вы писали: А>Наглядность + не нужно возни с шаблонными параметрами как сейчас
А>
А>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;
А>
Ужос! Несоответствие объявления объекта MyDelegate как указателя и работы с ним как с объектом (операторы += и -= для указателей делают совсем другое).
Неявная работа "делегата" с кучей.
Требование обязательного расположения объекта и делегатов в куче.
Неявная зависимость "делегата" от времени жизни объектов чьи функции дёргаются.
Неявное навязывание контейнера для реализации "делегата".
Короче, по мне, лучше явная либа или велосипед, где я хорошо представляю во что подобный код выльется.
А если уж и включать в язык, то именно замыкание метода на объект, как сделпно у багланда (__closure) и gcc (extern), а уж контейнер на это и руками весело прикручивается (были бы определены операторы =, == и <) да шаблоны с произвольным числом параметров.
Т.е. в С++0х вполне реализуемо.
Здравствуйте, Erop, Вы писали: А>>Как вы себе представляете прикручивание библиотеки скомпиленной под IA64 в проект для arm'а какого нить? E>А собранную gcc к собранному VC предатсаляешь?
Вполне. Pure C или аля-COM и с песней.
Здравствуйте, Sergey, Вы писали: S>Поэтому надо работать не (или не только) с хедерами/pch, а с уже S>откомпилированными функциями. Только пихать их, грубо говоря, в один на S>программу большой объектник. Заодно получаем в качестве бонуса S>диагностику нарушений ODR.
А это уже входит в противоречие с предкомпилированныим библиотеками.
Даже если отвлечся от того, что объектники могут получатся из исходников на других языках.
Здравствуйте, alzt, Вы писали: A>Немного отклонюсь от темы, и приведу то, что немного мешает: A>1. Отсутствие стандартного типа строки. Я знаю про stl, но практически каждая крупная библиотека имеет свой тип строки, который лучше использовать при её использовании (большинство функций используют либо строки своего формата, либо Си-шные строки). Т.е. std::string стандартная только на бумаге.
Лучше работать всегда с одним типом строки не зависимо то фрэймворка.
std::string — довольно хороший выбор, хотя могут быть и варианты.
A>2. Работа с памятью. Создание\Удаление небольших объектов в С++ неэффективно. При этом можно сделать настроить операторы new\delete для своих нужд. Но сделать это достаточно сложно, есть множество ограничений, в итоге — чтобы включить какую-то свою стратегию — нужно переписать множества кода.
Множество маленьких объектов лучше сразу держать в массиве. Например в std::vector. Тогда проблем с постоянным созданием/удалением не будет.
Здравствуйте, Roman Odaisky, Вы писали: RO>Как можно оставить возможность создания объектов на стеке и избежать перекомпиляции при изменении внутренней структуры объектов? RO>Или, например, есть вызов std::sort с неким предикатом. Вызов предиката инлайнится. И сама std::sort (частично) инлайнится. Если кто-то меняет предикат, то как можно обойтись без перекомпиляции?
Вполне представимо: при компиляции определения шаблона/инлайна нужно сохранять некоторое представление АСД + требования на внешние сущности, при соблюдении которых сгенерённое представление остаётся корректным.
А при компиляции использования сначало проверяется корректность, а потом подставляется само тело.
Мне кажется, вполне реально сделать такое с современными компиляторами. Причём, если эти отрывки индексировать, то компиляция может существенно ускорится.
А если собирать это в библиотеки получатся export template.
Здравствуйте, remark, Вы писали: R>Что Вам мешает в С++?
1) Отсутствие лямбд, замыканий, частичных применений — без этого не удобно использовать стандартные алгоритмы.
Есть в Haskell, Python, C# и многих других. Эмулируется функторами
2) Отсутствие автоматического вывода типов — приходится явно выписывать типы промежуточных и временных переменных — например тип итератора часто не интересен.
Есть в Haskell. Эмулируется шаблонами.
3) Ограничения на неклассовые типы шаблонных параметров — нельзя инстанцировать шаблон массивом, сторкой, float-ом, пользовательским типом.
Из за этого приходится выносить во время выполнение код, который вполне возможно выполнить во время компиляции (например построение конечного автомата по регулярному выражению).
4) Недостаток CTTI — хотелось бы уметь для произвольного типа получать список данных/функций/базовых классов и как-то с ним манипулировать.
На этой основе пишется любая кастомная RTTI, сериализация и т.п. Эмулируется макросами.
Здравствуйте, NikeByNike, Вы писали:
NBN>Чем не устраивает вижалка?
Дорогая... Express для win32-разработки как-то не особо приспособлен.
Не знаю как последние версии, а в 7.1 далеко не всегда stl контейнеры можно в дебаге посмотреть.
В последних версиях убрали поддержку win9x, т.е. писать программы, которые будут в win9x работать — нельзя. ИМХО рано еще.
Здравствуйте, Tonal-, Вы писали:
T>Вполне. Pure C или аля-COM и с песней.
А если я таки хочу С++ интерфейс + исключения, напрмиер?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, gear nuke, Вы писали:
GN>Препроцессоры некоторых ассемблеров могут очень много. Например, реализовать поддержку синтаксиса C, обеспечить строгую типизацию. Только придётся написать довольно много кода — это не смешно, а долго и чревато ошибками.
Единственный известный мне понт в метапрограммировании — уменьшение ручной работы (и тем самым уменьшение количества ошибок)
Если Вам исзвестен еще какой-то, не жадничайте, делитесь
G_K>>Как впрочем и кроссплатформенные ассемблеры. GN>Например, C?
Приведите пожалуйста (серьезный) источник, в котором C упоминается в качестве ассемблера
GN>Возьмём сферическую программу на C++. Исходники можно разделить на 2 части: определение (шаблонных) классов и бизнес-логика. Второе использует "готовые" классы — это клиентский код, чем мощнее первая часть, тем он меньше (и проще). Но первую часть кто-то должен написать. Простейший helloworld в 2 строки требует несколько мегабайт библиотечного кода.
Понятно
К сожалению я не занимаюсь сферическими хеллоуворлдами
Здравствуйте, remark, Вы писали:
R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>Что Вам мешает в С++?
1. Отсутствие стандартных кросс — платформенных библиотек.
2. Отсутствие относительно простых стандартных решений с простой семантикой, типа списков типов, например. Или деревьев.
3. Часто приходится слишком много усилий затрачивать на синтаксис (например в бусте семантика часто странно выглядит), вместо того, чтобы думать о дизайне/алгоритмах.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, remark, Вы писали:
R>>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>>Что Вам мешает в С++?
А>1. Отсутствие стандартных кросс — платформенных библиотек. А>2. Отсутствие относительно простых стандартных решений с простой семантикой, типа списков типов, например. Или деревьев. А>3. Часто приходится слишком много усилий затрачивать на синтаксис (например в бусте семантика часто странно выглядит), вместо того, чтобы думать о дизайне/алгоритмах.
В общем, если кратко, то это слишком уж разнообразная семантика и отсутствие должной стандартизации. (С) Или это уже где то было?
Немного помочь пытаются введением концептов. К сожалению для совместимости все равно оставят возможность писать шаблонные конструкции на типах без формальных требований к типам.
concept class comparable
{
bool operator < (...);
};
А>Delete == C# Dispose, можна удалить сразу или поставить в очередь на удаление в зависимости от состояния сборщика в текущий момент.
Мы, С++сники привыкли, что delete это всегда удаление, а иначе неудобно
Здравствуйте, Tonal-, Вы писали:
T>А это уже входит в противоречие с предкомпилированныим библиотеками. T>Даже если отвлечся от того, что объектники могут получатся из исходников на других языках.
Ну можно, например, писать в объектиники и в общую бащзу, какие-нибудь контрольные суммы. И как-то включать/выключать весь этот механизм на объектники из прагм.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали: T>>Вполне. Pure C или аля-COM и с песней. E>А если я таки хочу С++ интерфейс + исключения, напрмиер?
Тады надо обломаться.
Ну или пачить gcc благо исходники открыты. Только пачить много довольно придётся, особенно в обработке исключений (gcc единственный распостранённый компилер под винду который не поддерживает SEH).
Я делал dll-ки на мингве, которые дёргались из багландёвых приложений.
Интерфейс был — типа облегчённый COM (без подсчёта ссылок и обращения к COM-API) — вполне нормально работает.
Но исключения конечно гасятся на границе, да и в параметрах только ссылки, указатели да инты с чарами.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Roman Odaisky, Вы писали:
RO>>Здравствуйте, Аноним, Вы писали:
А>>>Не хватает: А>>>1. Делегатов на уровне языка; RO>>В C++09 будут. А>Отлично!
А>>>2. Полной информации о типах в runtime опционально; RO>>Рефлексия?
А>Да.
А>>>3. Что то типа C++Scripts для кодогенерации и выполнения его же на лету в runtime c возможностью cross objects, то есть объявил обьект в основной проге, а в скрипте мог обратиться к нему и наоборот; RO>>Это противоречило бы принципу «плати только за то, что используешь».
А>В смысле?
А>>>4. Сборщик мусора в принципе не нужен, от него больше проблем чем пользы; RO>>Я считаю, что сборка мусора правильно сделана в C++/CLI с помощью другого типа указателей и ссылок.
А>Нееет, без полной интеграции в язык неудобно. Нужно что бы из unmanaged кода было сделать managed без всякого переписывания старого кода.
По-моему вы очень много хотите. Я думаю, если бы была возможность это реализовать без значительных проблем и !!!Обратной совместимости, это бы было сделано.
Сборщик мусора сам не люблю, но очень удобно создавать объект в функции и не возвращать его по значению.
По поводу библиотек считаю самым весомым аргументом. Для Java стандартная библиотека будет мягко говоря пофункциональнее. А с boost я намучался присоединяя ее.
С++ требует горааааздо больше концентрации чем типобезопасные языки C++/CLI, C#, Java и другие.
Но программировать на C++ нравится, потому что это незабываемое чувство контроля...
M>Александр!
M>Вы не согласны что мне это мешает?
M>Или я допустил какие нить технические ляпы в своем псевдокоде?
Нет, Миша, технический ляп есть в посыле "К сожалению для совместимости все равно оставят возможность писать шаблонные конструкции на типах без формальных требований к типам."
Эту возможность оставляют далеко не только для совместимости.
Многие техники (особенно метопрограммирования) невозможно было бы применять, не будь возможности использовать unconstrained шаблоны.
Пара примеров:
* Is there anything useful that we can express with <class T> that we can’t express with <C T> where C is some concept? Yes, a completely unconstrained type, such as the type T pointed to by T*. Even a void* can’t point to a function.
* Can we eliminate <class T>? In the abstract, maybe. In reality, no. Many template meta-programming techniques seem to fundamentally depend on unconstrained types parameters (see appendix D). Also, there will always be pre-concept C++ code around.
Пример "практического" применения:
Modern C++ Design (Alexandrescu), chapter 1.8, Optional Functionality Through Incomplete Instantiation:
...
Creator prescribes a class template of one type T that exposes a member function Create. Create should
return a pointer to a new object of type T. Optionally, the implementation can define two additional
member functions — T* GetPrototype() and SetPrototype(T*) — having the semantics of getting
and setting a prototype object used for creation. In this case, WidgetManager exposes [to client — Alxndr] the
SwitchPrototype (T* pNewPrototype) member function, which deletes the current prototype and
sets it to the incoming argument.
...
Т.е. политика/стратегия может иметь в интерфейсе совершенно "левые" функции, которыми клиент может (или не может) пользоаться при определенных параметрах шаблона.
Вполне оргичнео было бы разрешить использование unconstrained типов не по дефолту , а наоборот. Это тоже самое что разрешить по дефолту interpret_cast любых типов (int)std::string.
Миша,
M>Вполне оргичнео было бы разрешить использование unconstrained типов не по дефолту , а наоборот.
Не совсем понятно, что ты понимаешь под "разрешить использовать не по дефолту".
Нужно — пишешь template <MySuperPuperConcept Model>, не нужно — пишешь template <class IDoNotNeedConceptHere>. И никакого дефолта
M>за ссылку спасибо.
Здравствуйте, Gluk_Kazan, Вы писали:
GN>>Препроцессоры некоторых ассемблеров могут очень много. Например, реализовать поддержку синтаксиса C, обеспечить строгую типизацию. Только придётся написать довольно много кода — это не смешно, а долго и чревато ошибками.
G_K>Единственный известный мне понт в метапрограммировании — уменьшение ручной работы (и тем самым уменьшение количества ошибок)
Уменьшение ручной работы — понт от любого прораммирования. А в чём понт этого высказывания? Я вообще про то, что можно написать мега-крутую библиотеку макросов на ассемблере, а потом её пользователи будут экономить время... Но на С++ такое делать проще, поскольку это следующая ступень в эволюции (машкод+монитор, ассемблер, макроассемблер, компилятор ассемблера, С) и часть этой мега-библиотеки захардкожено в компилятор, так что экономит время и разработчик.
G_K>Приведите пожалуйста (серьезный) источник, в котором C упоминается в качестве ассемблера
Про паскаль задело, да? Это было к тому, что можно смотреть на язык с противоположной стороны...
Можно бы привести определение "языка ассемблера", а потом выудить из ISO9899 что-нибуть про абстрактную машину, но слегка на демагогию будет похож вывод "ассемблер==транслятор"
а вот K&R отражает суть:
Си имеет дело с теми же объектами, что и большинство компьютеров, а именно с символами, числами и адресами. Они могут обрабатываться арифметическими и логическими операциями, реализованными на реальной машине
G_K>К сожалению я не занимаюсь сферическими хеллоуворлдами
helloworld самый обычный, из любой книжки. Остальной софт структурирован сложнее — может использоваться несколько библиотек, одна поверх другой и т.д, но деление на клиента и библиотеку можно произвести всегда.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
машкод+монитор, ассемблер, макроассемблер, компилятор ассемблера, С
А до компилятора ассемблера был интерпретатор ?
GN>Про паскаль задело, да? Это было к тому, что можно смотреть на язык с противоположной стороны...
Гмм. не уловил, что меня должно было задеть про Паскаль ???
И где у языка противоположная сторона ?
Я правда хочу разобраться Открой мне глаза, может я всегда смотрел на языки не с той стороны ???
GN>а вот K&R отражает суть: GN>
Си имеет дело с теми же объектами, что и большинство компьютеров, а именно с символами, числами и адресами. Они могут обрабатываться арифметическими и логическими операциями, реализованными на реальной машине
Дело конечно, но про ассемблеры то ничего не сказано (особенно кроссплатформенные)
Если есть проблемы с источниками, буду рад услышать ТВОЕ определение ассемблера
А то вдруг мы тут копья ломаем о разном, и ты под ассемблером понимаешь что-то свое, глубоко личное ?
Кстати, определение компилятора ассемблера тоже не помешает
GN>helloworld самый обычный, из любой книжки. Остальной софт структурирован сложнее — может использоваться несколько библиотек, одна поверх другой и т.д, но деление на клиента и библиотеку можно произвести всегда.
Думаю, что ты будешь удивлен сколько библиотек (одна поверх другой) может использовать самый обычный helloworld
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, remark, Вы писали:
R>>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>>Что Вам мешает в С++?
R>>...
R>На днях один мой знакомый побывал на самом крупном столичном книжном рынке. Там очаровательная блондинка потрясла его известием: "С++ больше нет, теперь вместо него С#"
А мужики-то не знают!!! Пора сворачивать форум, С++ кончился
Здравствуйте, remark, Вы писали:
R>Регулярно можно слышать критику в адрес С++, что дескать язык морально устаревший, что время разработки на С++ неприлично большое, что в С++ постоянно приходится сражаться с ветряными мельницами. Посему хочется провести следующий опрос среди коллег С++ программистов.
R>Что Вам мешает в С++?
В общем-то язык нужно принимать таким, какой он есть...
Но...
На мой взгляд, С++ мало подходит для коллективной разработки в силу слишком большой свободы...
То, что хорошо для гуру, очень плохо для обычного среднего работника-программиста.
С++ позволят писать в самых различных стилях и парадигмах... Нужно жесткое управление проектом с точки зрения стиля написания, и жестокое самоограничение и самодисциплина самих программистов, чтобы не потерять управление проектом и не утонуть в разнообразии...
Второе — это тянущийся хвост обратной совместимости с С. Это заставляет оставлять в С++ плохо подходящие в ООП конструкции... И опять же дает слишком много свободы программистам.
С уже давно не тот язык, с которым была провозглашена совместимость. С имеет собственный стандарт, который уже не совпадает с С++. Поэтому лучше не заморачяиваться на эту совместимость и провозгласить независимость.
Либо уж тогда следовать стандарту С и надстраивать с++ при каждом изменении стандарта С.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>С уже давно не тот язык, с которым была провозглашена совместимость. С имеет собственный стандарт, который уже не совпадает с С++. Поэтому лучше не заморачяиваться на эту совместимость и провозгласить независимость.
Тогда получится совсем другой язык, например тот же D.
Здравствуйте, Gluk_Kazan, Вы писали:
G_K>А до компилятора ассемблера был интерпретатор ?
Почти что был, я же выше перечислял monitor — строчный редактор, вводим по одной команде, пошаговое выполнение... Когда ассемблеры стали 2х проходными и научились вычислять метки, думаю, был серьёзный прорыв Assembly compiler понимает уже и высокоуровневые конструкции (см .IF в MASM, или HLA)
G_K>И где у языка противоположная сторона ? G_K>Я правда хочу разобраться Открой мне глаза, может я всегда смотрел на языки не с той стороны ???
Сторона зависит от предыдущих языков, или их количества. Если это высокоуровневые языки, то C++ будет выглядеть ассемблером (см. подфорум философия). Если низкоуровневые — мощным макроассемблером. А если паскаль — то будут раздражать всякие скобочки
. Совместимость с С — это собствено причина, по которой С++ — промышленный язык... Спор о синтаксисе == о блондинках и брюнетках.
G_K>Дело конечно, но про ассемблеры то ничего не сказано (особенно кроссплатформенные)
Зато сказано про модель памяти, которая соответствует реальному железу.
G_K>Если есть проблемы с источниками, буду рад услышать ТВОЕ определение ассемблера
Определение есть в Википедии:
Ассемблер (от англ. assembler — рабочий-сборщик) — компьютерная программа, компилятор исходного текста программы написанной на языке ассемблера, в программу на машинном коде.
Язык ассемблера — тип языка программирования низкого уровня, представляющий собой формат записи машинных команд, удобный для восприятия человеком.
Формально, язык определяется производителем процессора в даташитах. Но, например, для самой распространённой платформы — x86 — определения попросту нет, что позволило Randall Hyde назвать ассемблером HLA, а мне — С Традиционные мнемоники ничем не лучше того же '=', если не считаться с простотой парсера.
G_K>Думаю, что ты будешь удивлен сколько библиотек (одна поверх другой) может использовать самый обычный helloworld
Тот, что в книжках — одну — C++ Standard Library
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, sergey_shandar, Вы писали:
_>1. Это RTTI (Run Time Type Information). В таком языке как C++ лучще бы смотрелся CTTI (Compile Time Type Information). Т.е. нужно больше информации о типе в compile time, что это за тип, какие у него функции/свойства, как называется, номер (UUID какой нибудь) и т.п. А какой то специфичный RTTI я и сам из этого сделаю.
А как насчёт PTTI (Preprocessing Time Type Information)?
RTTI — скучно. CTTI — интереснее, надмножество RTTI + плюс можем генерировать специализированные алгоритмы и структуры данных. PTTI — ещё интереснее, надмножество CTTI + можем генерировать исходный код.
Здравствуйте, remark, Вы писали:
R>А как насчёт PTTI (Preprocessing Time Type Information)? R>RTTI — скучно. CTTI — интереснее, надмножество RTTI + плюс можем генерировать специализированные алгоритмы и структуры данных. PTTI — ещё интереснее, надмножество CTTI + можем генерировать исходный код.
См макры немерла.
Удобные анализ, трансформация и генерация кода на нескольких стадиях компиляции от почти потока токенов до полностью типизированного дерева.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Лет 8 назад я составил бы список из Х кривостей и недостатков.
Лет 5 назад я составил бы список из Х * Х кривостей и недостатков.
А сегодня согласен с вводом автора этого вопроса — горбатого могила исправит.
Нельзя улучшить С++ дот требуемого уровня не уничтожив при этом обратную совместимость.
Меж тем есть масса более совершенных языков: OCaml, LISP, Scala, C#, Nemerle, Haskell, D... Конечно не все они пригодны для решения задач стоящих перед программистом, но тем не менее из них всегда можно выбрать подходящий.
Так что дело не в том, что чего-то нет. Дело в том, что есть машина по оболваниванию людей и люди которые не хотя или не способны выучить второй язык.
* Язык сложный? Дык в нем море неопределенностей из-за того, что на плохотипизированый С попытались присабачить классы.
* Макросы кривые? Хотите такие же как в Лиспе или Немерле? Дык сами эти языки заточены под обработку списков и алгебраических типов средствами которых код представляется наиболее удобным борзом. Кроме того, без полноценной поддержки функций как значений обрабатывать код будет очень сложно. Так что чтобы были хорошие макросы нужно и язык иметь другой.
* Хотите лямбды? А их очень сложно сделать полноценными без GC.
* Хотите полноценный GC с дефрагментацией? А как же его сделаешь если основа языка это указатели, и даже массивов то полноценных нет? Опять наследие С...
* Хотите рефактринг? Смотрите первый пункт...
* Хотите СТТI? А что вы с ним будете делать если нет полноценных макросов? Опять головоломный и глючный мета-код на шаблонах?
В общем, это замкнутый круг — горбатого могила исправит.
Ну, а теперь самое крамольное. Писать программы (эффективные и даже сложные) можно практически на любом ЯП высокого уровня (не на ассемблере). Современный С++ мало чем отличается от С++ середины 90-ых прошлого века в этом контексте. Если уж вам нужны серьезные отличия, то список куда более отличных языков приведен выше. А если вам пофигу на чем писать, и пофигу ваша производительность, то вам хватит и VC 6 или Zortech. Да, что там Zortech — С хватит. Разница между ними и современным С++ с точки зрения продуктивности программиста все равно не сравнима с разницей между С++ и любым из перечисленных мною выше языков.
Почему же монстры индустрии до сих пор пишут код на С++?
Отличный пример МС. Там плевать на то, что производство ПО с помощью С++ неимоверно дорого. Плевать что код, в массе своей, созданный на С++ глюкав и крив. Важно, что есть огромная армия программистов из которой всегда можно найти тонну-другую талантов для своих проектов. И важно, что С++ порождает относительно шутсрый код совместимый с базовыми АПИ. Остальное по боку. Бабло всегда побеждает осло (с).
И наверно они (в МС) правы. С их баблом С++ + куча однобоких кодеров — лучший выбор.
Ведь С++ как гиря на ногах у их конкурентов, а с мегабаксами и при должной организации производства можно создавать софт и самыми экстенсивными методами.
Хорошие инструменты нужны отнюдь не мегамонстрам вроде МС. Они нужны мелким стартапам и маленьким но очень интеллектуальным командам. Инструмент сам по себе действительно является фетишем. Он всего лишь может увеличить производительность труда толковых людей. Но хороший инструмент в хороших руках — это убийственный аргумент. Ни как не могу забыть ощущение от BFG 10000 в моих руках когда я бежал по относительно просторному уровню...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
LVV>>С уже давно не тот язык, с которым была провозглашена совместимость. С имеет собственный стандарт, который уже не совпадает с С++. Поэтому лучше не заморачяиваться на эту совместимость и провозгласить независимость.
FR>Тогда получится совсем другой язык, например тот же D.
Но он тоже будет недотягивать потому что его будут уже сравнивать с другими языками.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, remark, Вы писали:
... VD>Почему же монстры индустрии до сих пор пишут код на С++?
не-не-не. А как же будущее "наше все" — C#? Вы ж, наверное, видели C# 3 с его гипермощным LINQ и прочими мегафичами
VD>Отличный пример МС. Там плевать на то, что производство ПО с помощью С++ неимоверно дорого. Плевать что код, в массе своей, созданный на С++ глюкав и крив. Важно, что есть огромная армия программистов из которой всегда можно найти тонну-другую талантов для своих проектов. И важно, что С++ порождает относительно шутсрый код совместимый с базовыми АПИ. Остальное по боку. Бабло всегда побеждает осло (с).
...зря что ль они на Андерса Хейлсберга раскошелились?
VD>И наверно они (в МС) правы. С их баблом С++ + куча однобоких кодеров — лучший выбор. VD>Ведь С++ как гиря на ногах у их конкурентов, а с мегабаксами и при должной организации производства можно создавать софт и самыми экстенсивными методами.
...и вообще в Висте — уже .NET предустановлен, и WPF для unmanaged кода недоступна.
Здравствуйте, StevenIvanov, Вы писали:
VD>>Почему же монстры индустрии до сих пор пишут код на С++?
SI>не-не-не. А как же будущее "наше все" — C#? Вы ж, наверное, видели C# 3 с его гипермощным LINQ и прочими мегафичами
А какя тут связь?
C# 3.0 используют те кто хочет быстро создавать довольно надежные приложения обработки данных.
А МС использует С++ просто от жиру.
VD>>Отличный пример МС. Там плевать на то, что производство ПО с помощью С++ неимоверно дорого. Плевать что код, в массе своей, созданный на С++ глюкав и крив. Важно, что есть огромная армия программистов из которой всегда можно найти тонну-другую талантов для своих проектов. И важно, что С++ порождает относительно шутсрый код совместимый с базовыми АПИ. Остальное по боку. Бабло всегда побеждает осло (с).
SI>...зря что ль они на Андерса Хейлсберга раскошелились?
Дык, а на чем его команда тот самый C#-компилятор пишет? В прочем, времена похоже меняются и даже МС вроде как собирается переписать компилятор Шарпа на менеджед-языке.
VD>>И наверно они (в МС) правы. С их баблом С++ + куча однобоких кодеров — лучший выбор. VD>>Ведь С++ как гиря на ногах у их конкурентов, а с мегабаксами и при должной организации производства можно создавать софт и самыми экстенсивными методами.
SI>...и вообще в Висте — уже .NET предустановлен, и WPF для unmanaged кода недоступна.
Ага. И сделано на этом дотнете аж одна закладка во вьюере событий.
Но даже МС потихоничку переползает. Вот уже большая часть студии написана на менеджед-языках. Вроде как компилятор все же перепишут. В разном прикладном ПО дотнет появляется. Так что даже мегамонстры понимают, что выбрасывать бабки на ветер глупо. Хотя для МС это все не критично. Бабла там столько, что они и на ассемблере Виндовс написали бы (писали же ДОС и большую часть Винды?).
Заметь при этом о каких-то радикальных изменениях в С++ они даже не заикаются. И это при том, что как раз они то для своего дотнета очень даже нехило С++ доработали. Там тебе и GC, и делегаты, и безопасный режим, и дженерики (не в ущерб шаблонам) и много чего. Вот только использовать его один хрен неудобно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, StevenIvanov, Вы писали:
VD>>>...
не, дело очевидно не только в деньгах. Сопровождение makes sense
Представь стоимость переписывания всего объема кода, который надо было бы еще и перетестировать (да еще и параллельно добавив-выкинув пару сотен фич).
Недавно вычитал в умной книжке по си шарпу, что что стоимость написания с нуля крупного современного программного продукта (а windows, msoffice, photoshop там какой нибудь — ну просто мегакрупные) сравнима со стоимостью постройки небоскреба.
Да и еще. Мне кажется, что в этой ветке многие не читали (или уже забыли) Брукса:
Я считаю, что сложность создания программного обеспечения заключается в задании технических требований, проектировании и проверке этой концептуальной конструкции, а не в затратах, связанных с ее представлением и проверкой точности представления. Конечно, мы делаем синтаксические ошибки, но в большинстве систем они несущественны в сравнении с концептуальными ошибками.
Здравствуйте, StevenIvanov, Вы писали:
SI>не, дело очевидно не только в деньгах. Сопровождение makes sense SI>Представь стоимость переписывания всего объема кода, который надо было бы еще и перетестировать (да еще и параллельно добавив-выкинув пару сотен фич). SI>Недавно вычитал в умной книжке по си шарпу, что что стоимость написания с нуля крупного современного программного продукта (а windows, msoffice, photoshop там какой нибудь — ну просто мегакрупные) сравнима со стоимостью постройки небоскреба.
На прибыли от Виндовс можно 100 скребонебов построить. Так что дело не в деньгах, а как всегда и их количестве .
Потом ненадо переписывать все. Но уж если что-то переписывается, то можно и сэкономить. При этом и качество выше будет. Я конечно понимаю, что тут каждый второй крут как вареное яйцо и не делает ошибок при программировании на С++, но все же продукты, то постоянно вылетают. Тот же Ворд уже много лет глючит по черному...
Так что тут дело в другом. Дело в том, что с их доходами даже небольшая разница в потребляемых ресурсах уже влияет на доходы, а стоимость разработки для них не играет роли. Глюки пользователь тоже переживает. Вот и получается, то что получается.
Казалось бы и правда, создать некий аналог С++ с точки зрения качества оптимизации кода и потребляемых ресурсов конечного приложения и можно избежать огромной части затрат на разработку и сопровождение, но зачем? Скажем, я уверен, что даже если бы для разработки драйверов использовался бы какой-нить ОКамл (а я не сомневаюсь, что для МС это не было бы проблемой реализовать), то надежность драйверо была бы куда вше. Но зачем? Можно же потратить море бабок на написание и вылизывание этих драйверов. Плюс еще море на создание разных драйвер-верифайров, которые один фиг всех ошибок не предотвращают. Ведь проблема в том, что если начать менять, то может измениться и расклад сил на рынке. А зачем это нужно тем, кто его уже успешно занимает?
SI>Да и еще. Мне кажется, что в этой ветке многие не читали (или уже забыли) Брукса:
SI>
SI>Я считаю, что сложность создания программного обеспечения заключается в задании технических требований, проектировании и проверке этой концептуальной конструкции, а не в затратах, связанных с ее представлением и проверкой точности представления. Конечно, мы делаем синтаксические ошибки, но в большинстве систем они несущественны в сравнении с концептуальными ошибками.
Мне кажется это чушь. Вернее это конечно все правильно, но от инструмента зависит и то как ты будешь проектировать код, и то какие ошибки в нем можно допустить (ну, не должен современный язык допускать ошибки связанные с типами), и то как программу потом можно будет проверить на соответствие некоторым условиям. Если код пишется на С++, то все плохо. Программу не то чтобы верифицировать, ее скомпилировать то не всегда удастся (не смотря на ее формальную правильность). И так по всем параметрам.
SI>Я так понимаю это и оказывается решающим фактором в выборе ЯП в микрософте.
Мне кажется, что как и везде решающим фактором оказывается то, что начальство знает, что такое С++ и что все пишут на нем. Плюс, то о чем я говорил. Наличие моря бабла снимает проблемы оптимальности выбора. Думаю, что они на ассемблере, то ОС не пишут, не потому, что это сложно, а потому, что код не переносимым получается, ну, и потому, что толку почти от этого нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LaptevVV, Вы писали:
LVV>В общем-то язык нужно принимать таким, какой он есть...
+1
LVV>Но... LVV>На мой взгляд, С++ мало подходит для коллективной разработки в силу слишком большой свободы... LVV>То, что хорошо для гуру, очень плохо для обычного среднего работника-программиста.
Это означает всего лишь, что разношерстные команды менее эффективны, чем "неразношерстные". Для некоторых других языков наоборот — разношерстные команды более эффективны, и что с того... просто нужно учитывать это при формировании команд.
LVV>С++ позволят писать в самых различных стилях и парадигмах...
И это есть хорошо
LVV>Нужно жесткое управление проектом с точки зрения стиля написания, и жестокое самоограничение и самодисциплина самих программистов, чтобы не потерять управление проектом и не утонуть в разнообразии...
Если выбранный путь решения не противоречит ни чему, то и проблемы нет, по большому счету. Если проблемы появляются — это, как правило, следствие разношерстных команд или неумение людей уважать чужой код.
LVV>Второе — это тянущийся хвост обратной совместимости с С. Это заставляет оставлять в С++ плохо подходящие в ООП конструкции...
Но не заставляет их использовать, так что проблемы нет.
LVV>И опять же дает слишком много свободы программистам.
При четком разграничении приоритетов для отдельных частей проектов — это только хорошо.
LVV>С уже давно не тот язык, с которым была провозглашена совместимость. С имеет собственный стандарт, который уже не совпадает с С++. Поэтому лучше не заморачяиваться на эту совместимость и провозгласить независимость.
Совместимость нужна не со стандартами, а с существующим кодом, что обеспечивается насколько это возможно. Если кто-то в C использует что-то в соответствии со стандартом, но что плохо согласуется с C++, пусть он идет в сад.
LVV>Либо уж тогда следовать стандарту С и надстраивать с++ при каждом изменении стандарта С.
Нет уж, пусть лучше сомнительные решения из стандарта в стандарт не перекочевывают (как сейчас стараются и делать).
Здравствуйте, VladD2, Вы писали:
VD>Нельзя улучшить С++ до требуемого уровня, не уничтожив при этом обратную совместимость.
Основной принцип C++ — нулевой оверхед. Он автоматически несовместим со многими фичами. Вот и всё.
А аргументы твои довольно странные. Макросы, лямбды, рефакторинг, CTTI в C++ вполне возможны, они не противоречат основному принципу. GC с дефрагментацией требуют еще один уровень косвенности, потому не годятся. Умные указатели имеют свои недостатки, но работают быстро — при должном внимании к проектированию (и отсутствии циклических ссылок).
VD> VD>Ну, а теперь самое крамольное. Писать программы (эффективные и даже сложные) можно практически на любом ЯП высокого уровня (не на ассемблере).
Ага.
VD>Отличный пример МС. Там плевать на то, что производство ПО с помощью С++ неимоверно дорого. Плевать что код, в массе своей, созданный на С++ глюкав и крив. Важно, что есть огромная армия программистов из которой всегда можно найти тонну-другую талантов для своих проектов. И важно, что С++ порождает относительно шутсрый код совместимый с базовыми АПИ. Остальное по боку. Бабло всегда побеждает осло (с).
Хочешь посмотреть на Top 10 языков пакетов Debian?
c
32.44%
perl
25.68% (из них 85% — библиотеки)
c++
10.32%
python
9.74%
lisp
4.76%
php
2.81%
ocaml
2.55%
ruby
2.40%
java
1.81%
shell
1.47%
Опрошено 11 тысяч пакетов (примерно половина), у которых есть теги implemented-in.
Ты еще писал об огромной стоимости разработки аналогов MS Office или Adobe Photoshop. GIMP вдвое моложе Photoshop, написан на суровом C, и — хотя это и из другого флейма — я Photoshop не осилил, GIMP мне нравится намного больше. И стоимость его примерно в 0 раз выше стоимости небоскреба :-)
Здравствуйте, VladD2, Вы писали:
VD>Что-то меняется в этом мире. Я то думал, что мне тут сразу минусов понаставят, а прошло уже несколько часов, а мне только один смайлик поставили .
Здравствуйте, Кодёнок, Вы писали:
VD>>Что-то меняется в этом мире. Я то думал, что мне тут сразу минусов понаставят, а прошло уже несколько часов, а мне только один смайлик поставили :wow: :xz:.
Кё>может просто до них дошло? :)
Здравствуйте, VladD2, Вы писали:
VD>* Хотите СТТI? А что вы с ним будете делать если нет полноценных макросов? Опять головоломный и глючный мета-код на шаблонах?
Тут уж ты точно неправ, ничего ни мешает сделать в C++ как в D http://www.digitalmars.com/d/2.0/traits.html
VD>В общем, это замкнутый круг — горбатого могила исправит. VD> VD>Ну, а теперь самое крамольное. Писать программы (эффективные и даже сложные) можно практически на любом ЯП высокого уровня (не на ассемблере). Современный С++ мало чем отличается от С++ середины 90-ых прошлого века в этом контексте. Если уж вам нужны серьезные отличия, то список куда более отличных языков приведен выше. А если вам пофигу на чем писать, и пофигу ваша производительность, то вам хватит и VC 6 или Zortech. Да, что там Zortech — С хватит. Разница между ними и современным С++ с точки зрения продуктивности программиста все равно не сравнима с разницей между С++ и любым из перечисленных мною выше языков.
Влад такое очущение что ты на _современном_ C++ просто никогда ни писал.
Хотя я конечно понимаю что вы городские с трудом отличает лошадь с сохой от трактора
VD>Почему же монстры индустрии до сих пор пишут код на С++?
VD>Отличный пример МС. Там плевать на то, что производство ПО с помощью С++ неимоверно дорого. Плевать что код, в массе своей, созданный на С++ глюкав и крив. Важно, что есть огромная армия программистов из которой всегда можно найти тонну-другую талантов для своих проектов. И важно, что С++ порождает относительно шутсрый код совместимый с базовыми АПИ. Остальное по боку. Бабло всегда побеждает осло (с).
Слишком гиперболизируешь.
VD>И наверно они (в МС) правы. С их баблом С++ + куча однобоких кодеров — лучший выбор.
Для "однобоких кодеров" есть специально созданные для них ява и шарп.
VD>Ведь С++ как гиря на ногах у их конкурентов, а с мегабаксами и при должной организации производства можно создавать софт и самыми экстенсивными методами.
У них ровно обратная тактика http://russian.joelonsoftware.com/Articles/FireAndMotion.html
VD>Хорошие инструменты нужны отнюдь не мегамонстрам вроде МС. Они нужны мелким стартапам и маленьким но очень интеллектуальным командам. Инструмент сам по себе действительно является фетишем. Он всего лишь может увеличить производительность труда толковых людей. Но хороший инструмент в хороших руках — это убийственный аргумент. Ни как не могу забыть ощущение от BFG 10000 в моих руках когда я бежал по относительно просторному уровню...
Есть небольшая проблема C++ в правильных руках тоже относится к хорошим инструментам.
Здравствуйте, VladD2, Вы писали:
VD>Мне кажется это чушь. Вернее это конечно все правильно, но от инструмента зависит и то как ты будешь проектировать код, и то какие ошибки в нем можно допустить (ну, не должен современный язык допускать ошибки связанные с типами), и то как программу потом можно будет проверить на соответствие некоторым условиям. Если код пишется на С++, то все плохо. Программу не то чтобы верифицировать, ее скомпилировать то не всегда удастся (не смотря на ее формальную правильность). И так по всем параметрам.
Все так, но ты не хочешь понять простую вещь, для программ-монстров, общие затраты на кодирование (и низкоуровневое проектирование) настолько малы что выбор языка почти ни окажет влияния на общую скорость разработки. Возьми хоть того же Макконнелла посмотри графики из 27 главы.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, StevenIvanov, Вы писали:
SI>>Да и еще. Мне кажется, что в этой ветке многие не читали (или уже забыли) Брукса:
SI>>
SI>>Я считаю, что сложность создания программного обеспечения заключается в задании технических требований, проектировании и проверке этой концептуальной конструкции, а не в затратах, связанных с ее представлением и проверкой точности представления. Конечно, мы делаем синтаксические ошибки, но в большинстве систем они несущественны в сравнении с концептуальными ошибками.
SI>>online версия здесь
VD>Мне кажется это чушь. Вернее это конечно все правильно, но от инструмента зависит и то как ты будешь проектировать код, и то какие ошибки в нем можно допустить (ну, не должен современный язык допускать ошибки связанные с типами), и то как программу потом можно будет проверить на соответствие некоторым условиям. Если код пишется на С++, то все плохо. Программу не то чтобы верифицировать, ее скомпилировать то не всегда удастся (не смотря на ее формальную правильность). И так по всем параметрам.
Вроде убедительно и тоже вроде правда, но не могу полностью согласиться. Ведь для того, чтобы обуздать непредсказуемость и закидоны этого зверя — С++а придуманы такие вещи, как:
— coding standards
— best practices
— code review
все они устоявшиеся и проверены годами. Сделано многое, чтобы не писать "велосипеды". От явных ошибок избавляют отладчики и инструменты динамического и статического анализа, а так же процедурные меры — напр. Fagan-like inspections. Специальные инструменты оценивают сложность кода — и с превышением показателя complexity код нельзя выставлять на review. Так написаны тысячи и тысячи вещей "от мала до велика". Результат ПРЕДСКАЗУЕМ. Бывалый проектный менеджер всегда сможет выдать estimation по реализации конкретной фичи — что ценно. Все это уже утряслось и более менее устоялось.
Я на мгновение представил себя бюрократом, не имеющим понятия о ЯП, но знающим, что конкретно в моей конторе (а так же в лавках многочисленных конкурентов) используют С++, "их" и "наши" программисты уже съели стаю собак и пуды соли... Зачем мне будет нужно что-то новое, не обкатанное? Явный риск. Неприемлемый для очередной мегафичи. Даже в роли техлида, даже за новым проектом, я бы вряд ли взялся сориентировать бывалых сиплюсплюсников из своей команды на что то новое, пусть и C#.
А по поводу "выбрасывания денег на ветер" — это вы зря. Уж там народ деньги считать умеет. Это точно. И работают они на конкретный результат, справедливо считая, что "the profits justify the means".
Здравствуйте, VladD2, Вы писали:
VD>Отличный пример МС. Там плевать на то, что производство ПО с помощью С++ неимоверно дорого. Плевать что код, в массе своей, созданный на С++ глюкав и крив. Важно, что есть огромная армия программистов из которой всегда можно найти тонну-другую талантов для своих проектов. И важно, что С++ порождает относительно шутсрый код совместимый с базовыми АПИ. Остальное по боку. Бабло всегда побеждает осло (с).
VD>И наверно они (в МС) правы. С их баблом С++ + куча однобоких кодеров — лучший выбор. VD>Ведь С++ как гиря на ногах у их конкурентов, а с мегабаксами и при должной организации производства можно создавать софт и самыми экстенсивными методами.
C++ вселяет больше уверенности, чем С#, Java. Вдруг microsoft решит прикрыть этот C# и сказать мол ребята звиняйте но C# obsolete потому как мы тут написали Z#, который лишен недостатков которые были в C#, F#, ...#. Переписывайте теперь весь свой софт на Z#. Здесь критикуют С++ зато что он до сих пор поддерживает обратную совместимость, но ведь это же мегакруто , чем когда переводил проект с .NET 1.0 -> .NET 2.0 была куча ошибок и постоянные мысли о том что где-то что-то перестанет работать, а заказчику не обьяснишь — как это раньше все работало, а теперь перестало работать
Да и сам MC не спешит переходить на C#, потому что это очень большой риск завести себя в тупик. Все эти C# ориентированы на тех кому надо срубить бабло быстро и сейчас, отлично подходит для проектов маленького/среднего уровня, которые если что случится со C# будет не проблема переписать на Z#.
Здравствуйте, remark, Вы писали:
R>1. Мешать это должно регулярно. Т.к. если это мешает эпизодически, например, раз в год, то это не интересно, т.к. раз в год можно и потерпеть, и на общей эффективности разработки это не сказывается. R>2. Это должно быть решено в других промышленных языках. Т.к. если это не решено хотя бы в одном другом промышленном языке, то это не интересно, т.к. это не проблема С++, а просто общая проблема. Если не очевидно, то желательно указывать языки, в которых это решено.
Самая главная и крупная неприятность в C++ для меня — практическая невозможность автоматического анализа кода. То, что так легко и непринужденно делается в Java, в Lisp, в языках .NET, для C++ недоступно. Виноваты тут две вещи — препроцессор и очень плохой синтаксис языка. Написание парсера C++ — задача практически самоубийственная.
То есть, даже такую простейшую (и архинужную) вещь, как построить граф вызовов методов, для C++ сделать крайне непросто. Мешает это регулярно, каждую минуту. Когда в проекте миллионы строк унаследованного кода, плохо документированного, то без умных средств анализа кода жизнь тяжела и уныла.
Вторая претензия к языку шаблонов в C++. Он плох. Он недостаточен. Но это, понятно, далеко не всем надо, так что про детали этих претензий промолчу.
Здравствуйте, De Veloper, Вы писали:
DV> Вторая претензия к языку шаблонов в C++. Он плох. Он недостаточен. Но это, понятно, далеко не всем надо, так что про детали этих претензий промолчу.
Было бы интересно послушать, и сравнить с тем что есть тут:
0) Мешает ПРЕЖДЕ ВСЕГО отсутствие хорошей продуманной стандартной библиотеки,
предоставляющей background для создания приложений и предоставляющая
-- строки
-- коллекции (забудьте про STL, — не отвечает критериям "продуманная" и
"стандартная")
-- точные целые произвольной длины
-- юникод
-- XML
-- многопоточность
-- взаимодействие с ОС
-- возможно что-то еще (забыл).
(отчасти boost и open source лечит эти проблемы, но пока это все нестандартное.
Надо чтобы это все было в любом компиляторе, и было бы ОБЯЗАТЕЛЬНО).
Roman Odaisky пишет: > Библиотек, собственно, много. Наверное, больше, чем для любого другого > языка. Не хватает грамотно спроектированных качественных библиотек.
Да как раз и проблема, что нужно не много библиотек. А одна, хорошая
и стандартная.
Здравствуйте, MasterZiv, Вы писали:
MZ>Да как раз и проблема, что нужно не много библиотек. А одна, хорошая MZ>и стандартная.
С одной функцией: "doSomething()"...
merk пишет:
> 1. совместимость с С. в С просто видна история развития и затыкание > синтаксических дыр.
> 2. аццки подозрительная форма записи типов. когда я переходил с модулы > на с, долго не мог понять — какая вообще в С схема записи сложного типа.
> 3. нет четкого понятия модуля с импортом и экспортом. хидеры — чисто
Это все — ерунда. К этому всему привыкаешь и все понятно. После этого
можно нормально писать на С++, это не мешает созданию на нём программ.
Здравствуйте, VladD2, Вы писали:
VD>Что-то меняется в этом мире. Я то думал, что мне тут сразу минусов понаставят, а прошло уже несколько часов, а мне только один смайлик поставили .
Может потому, что уже общеизвестно твое отношение к С++ и никто уже к подобным твоим заявлениям всерьёз не относится?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, FR, Вы писали:
FR>Все так, но ты не хочешь понять простую вещь, для программ-монстров, общие затраты на кодирование (и низкоуровневое проектирование) настолько малы что выбор языка почти ни окажет влияния на общую скорость разработки. Возьми хоть того же Макконнелла посмотри графики из 27 главы.
Код есть код. Его надо проектировать, писать, отлаживать и менять. На любой из этих аспектов разработки влияет инструмент и уровень владения им разработчиков/дизайнеров.
Конечно есть скажем игры где много времени уходит на дизайн левелов и т.п., но и там скорость и качество разработки много стоят. Ведь и в уровнях много скриптов, и движок развивать надо. В итоге получаем по 3 года разработки, а потм софт вылетает, течет, глючит...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CreatorCray, Вы писали:
CC>Может потому, что уже общеизвестно твое отношение к С++ и никто уже к подобным твоим заявлениям всерьёз не относится?
До сих пор это никого не останавливало. Похоже, все же что-то меняется. Это не может не радовать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Конечно есть скажем игры где много времени уходит на дизайн левелов и т.п., но и там скорость и качество разработки много стоят. Ведь и в уровнях много скриптов, и движок развивать надо. В итоге получаем по 3 года разработки, а потм софт вылетает, течет, глючит...
Год разработки, да и глюкавых игр достаточно мало.
Да и шарп с явой в них, что характерно, почти не применимы (во всяком случае в серьёзных проектах).
Здравствуйте, MasterZiv, Вы писали:
MZ>-- коллекции (забудьте про STL, — не отвечает критериям "продуманная" и "стандартная")
Стандартнее некуда, и очень продуманная. Есть люди, которые считают, что не в ту сторону продуманная, но это из другого флейма.
MZ>1) хорошая стандартная кроссплатформенная build-система.
Стандартной системы сборки ни у какого языка нет. Тем более, что часто приходится использовать сразу несколько языков в проекте. А хороших кросс-платформенных кросс-языковых систем сборки много. Хотя бы CMake и Boost.Build.
Здравствуйте, MasterZiv, Вы писали:
>> Библиотек, собственно, много. Наверное, больше, чем для любого другого >> языка. Не хватает грамотно спроектированных качественных библиотек.
MZ>Да как раз и проблема, что нужно не много библиотек. А одна, хорошая MZ>и стандартная.
Должен быть Единственный Правильный Путь написания библиотек. Как в Python, как в Java. Тогда они будут с легкостью интегрироваться.
Здравствуйте, VladD2, Вы писали: VD>Что-то меняется в этом мире. Я то думал, что мне тут сразу минусов понаставят, а прошло уже несколько часов, а мне только один смайлик поставили .
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, VladD2, Вы писали:
VD>Код есть код. Его надо проектировать, писать, отлаживать и менять. На любой из этих аспектов разработки влияет инструмент и уровень владения им разработчиков/дизайнеров.
Угу и поэтому еще и неизвестно будет ли вообще ускорение разработки для больших программ, может из-за всех накладных факторов, переобучения и т. п. и замедление получится.
VD>Конечно есть скажем игры где много времени уходит на дизайн левелов и т.п., но и там скорость и качество разработки много стоят. Ведь и в уровнях много скриптов, и движок развивать надо. В итоге получаем по 3 года разработки, а потм софт вылетает, течет, глючит...
Влад у меня последний год кроме студии стояла единственная NET программа OmeaReader от JetBrains, в общем вполне качественная программа, конечно притормаживала, и иногда вылетала или задумывалась навсегда со 100% загрузкой процессора, но в целом вполне меня устраивала. И вот с месяц назад запускаю ее и получаю ошибку разрушена база, жму восстановить backup, он тоже разрушен, поиск по гуглю показывает что проблема нередкая и у многих людей эта основная причина отказа от использования даной программы. Насколько я знаю программа написана вполне квалифицированными людьми, так что не сильно уж и надежнее NET.
R>Моменты можно приводить любые от ядра языка и до инструментальных средств, но при этом накладываются следующие ограничения: R>1. Мешать это должно регулярно. Т.к. если это мешает эпизодически, например, раз в год, то это не интересно, т.к. раз в год можно и потерпеть, и на общей эффективности разработки это не сказывается. R>2. Это должно быть решено в других промышленных языках. Т.к. если это не решено хотя бы в одном другом промышленном языке, то это не интересно, т.к. это не проблема С++, а просто общая проблема. Если не очевидно, то желательно указывать языки, в которых это решено.
Мешает нагромождение темплейтов, там где их может не быть в старом (legacy) коде, который приходится мейнтейнить.
Отладка на промышленый серверах типа AIX, стандартными слабенькими отладчиками этого "счастья" угнетает.
А что то мощное не тянет по деньгам/сетке, так как сервера далеко.
Ну и в стандарте недостаточно четка прописана организация класса на системном уровне (реализуй как хочешь, тоже для отладки не гуд).
Это как раз оно, так и должны выглядеть шаблоны в низкоуровневом высокопроизводительном языке. Примером, который меня убедил, был regexp. Собственно, основная претензия к C++ — нельзя сделать так же. Небольшой, довольно жалкий набор операций над целыми числами — и всё. Маловато будет! А вот если можно читать строки — значит, можно сделать все, причем дешево.
Здравствуйте, De Veloper, Вы писали:
FR>>http://www.digitalmars.com/d/2.0/templates-revisited.html
DV> Это как раз оно, так и должны выглядеть шаблоны в низкоуровневом высокопроизводительном языке. Примером, который меня убедил, был regexp. Собственно, основная претензия к C++ — нельзя сделать так же. Небольшой, довольно жалкий набор операций над целыми числами — и всё. Маловато будет! А вот если можно читать строки — значит, можно сделать все, причем дешево.
Так ведь, насколько я понял, в C++09 запись SomeTemplate<"SomeString"> будет срабатывать, если template <class... Chars> SomeTemplate<Chars...>, т. е., будет раскрываться в SomeTemplate<'S', 'o', 'm', 'e', 'S', 't', 'r', 'i', 'n', 'g'>.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Так ведь, насколько я понял, в C++09 запись SomeTemplate<"SomeString"> будет срабатывать, если template <class... Chars> SomeTemplate<Chars...>, т. е., будет раскрываться в SomeTemplate<'S', 'o', 'm', 'e', 'S', 't', 'r', 'i', 'n', 'g'>.
Да. Это хорошо. Одно только плохо — нет пока никакого C++0x.
А так там очень много полезных и вкусных штучек обещается, я давно уже устал слюни пускать в ожидании.
Roman Odaisky пишет:
> MZ>1) хорошая стандартная кроссплатформенная build-система. > Стандартной системы сборки ни у какого языка нет. Тем более, что часто
Здравствуйте, MasterZiv, Вы писали:
MZ>Ужас бухгалтера пишет:
>> C>С одной функцией: "doSomething()"...
MZ>Очень смешно. Тут язык такой замечательный помирает, а им всё — хиханьки да MZ>хаханьки ...
Здравствуйте, VladD2, Вы писали:
VD>Казалось бы и правда, создать некий аналог С++ с точки зрения качества оптимизации кода и потребляемых ресурсов конечного приложения и можно избежать огромной части затрат на разработку и сопровождение, но зачем? Скажем, я уверен, что даже если бы для разработки драйверов использовался бы какой-нить ОКамл (а я не сомневаюсь, что для МС это не было бы проблемой реализовать), то надежность драйверо была бы куда вше. Но зачем? Можно же потратить море бабок на написание и вылизывание этих драйверов. Плюс еще море на создание разных драйвер-верифайров, которые один фиг всех ошибок не предотвращают. Ведь проблема в том, что если начать менять, то может измениться и расклад сил на рынке. А зачем это нужно тем, кто его уже успешно занимает?
Таких "аналогов" понаписано уже два вагона. От модулы до ады. И что и где? Кто-то на них прогает?
Жизнь такова, что бывают разные программы и разные задачи и разные требования как к средствам реализации, так и к качеству разработки, стоимости поддержки, требованиям к ресурсам и т. п.
Для одних ниш C# годится, для других нет.
В целом это, IMHO, не удивительно. Всё-таки и ява и C# разрабатывались для того, чтобы занять нишу а ля VB + переносимость. Типа пофиг скорость, пофиг память, главное, чтобы можно было что-то задёшево написать почти не проектируя, а потом задёшево развивать. Ещё важно обеспечеть лёгкость вызова библиотек, других приложений, сторонних компонент и т. п.
И это правильно, так как есть очень большой класс задач, которые всегда надо реализовать "уже вчера", и "совем задёшево". При этом вопрос о переиспользовании кода вообще не стоит.
А есть задачи, которые надо решить таки хорошо, эффективно по ресурсам, обеспечить эффективное переиспользование кода в течении десятков лет и т. д.
Тогда уже основная стоимость разработки переходит в проектирование, тестирование, мероприятия по удешевлению поддержки (например в адекватное документирование), и там преимущества C# таки растворяются. Зато проявляются недостатки. Вот на С++ и пишут. Даже ада не подходит, как оказалось
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, MasterZiv, Вы писали:
>> MZ>1) хорошая стандартная кроссплатформенная build-система. >> Стандартной системы сборки ни у какого языка нет. Тем более, что часто
MZ>В Java — есть. LISP — есть.
Здравствуйте, MasterZiv, Вы писали:
>> MZ>1) хорошая стандартная кроссплатформенная build-система. >> Стандартной системы сборки ни у какого языка нет. Тем более, что часто MZ>В Java — есть. LISP -есть.
А что есть стандартное в Java?
Ant, Maven, Maven2, Rant, SCons, а может быть make?
Здравствуйте, Roman Odaisky, Вы писали:
O>Так ведь, насколько я понял, в C++09 запись SomeTemplate<"SomeString"> будет срабатывать, если template <class... Chars> SomeTemplate<Chars...>, т. е., будет раскрываться в SomeTemplate<'S', 'o', 'm', 'e', 'S', 't', 'r', 'i', 'n', 'g'>.
В D удобней и мощней, даже без миксинов, а с миксинами вообще уже близко к полноценному макро языку.
Roman Odaisky пишет: > Ant, что ли? Он ни разу не стандартный.
Ant, maven, да их там дофига. Я Java не знаю.
Они есть ? Есть. Везде ? Везде. В любом месте
с ними можно работать (в любом IDE)? Можно.
Кроссплатформенное ? Да.
Что ж ещё там нестандартного ?
Мне не надо, чтобы ISO стандарт выпустило, стандарт
вон POSIX вроде и есть, мне надо чтобы везде работало!
Здравствуйте, MasterZiv, Вы писали:
MZ>Они есть ? Есть. Везде ? Везде. В любом месте MZ>с ними можно работать (в любом IDE)? Можно. MZ>Кроссплатформенное ? Да. MZ>Что ж ещё там нестандартного ?
MZ>Мне не надо, чтобы ISO стандарт выпустило, стандарт MZ>вон POSIX вроде и есть, мне надо чтобы везде работало!
В С++ еще проще, там обычных мейкфайлов достаточно.
Только вот проблемы начинаются, когда у тебя одна бибилотека с одним мейкфайлом, а другая — с другим, а твой проект — с третьим, и все они, хоть и написаны для одной и той же версии make, никак работать вместе не хотят.
И эти проблемы с мейкфайлами совершенно не зависят от того, что ими собирается — С++, Ява или С#.
Я лично сталкивался несколько раз
)
Перекуём баги на фичи!
