Ни в коем случае.
> Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции. Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь. > > Использование C-ных макросов для более серьезных вещей, по моему опыту, является следствием непродуманного дизайна. Когда на поиск более подходящей реализации не хватило времени, подходящих инструментов или хорошей идеи.
Вот именно — не хватает более подходящих инструментов. Поэтому приходится либо навешивать внешний кодогенератор, либо использовать макросы в стиле boost preprocessor. И то и другое — не очень удобно.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, eao197, Вы писали:
VD>>А если серьезнь, то есть менее кривые средства. Те же текстуаьные макросы можно заменить немерлоподобными.
E>Макросы в топку. E>Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции. Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь.
E>Использование C-ных макросов для более серьезных вещей, по моему опыту, является следствием непродуманного дизайна. Когда на поиск более подходящей реализации не хватило времени, подходящих инструментов или хорошей идеи.
Видишь ли, программа, как ни крути — это текстовый файл, и есть вещи, которые хочется делать именно на этом уровне (если, конечно, нет доступа к более продвинутым средствам, типа немер левых макросов, которые работают напрямую с синтаксическим деревом — тогда эти же вещи захочется делать на уровне преобразования дерева), и никакими другими способами ты для этих вещей такой же ясности и лаконичности не добьешься.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>>>Вот через 20 лет кто-нибудь поставит Nemerle в упрек то, что он создавался под .NET.
AF>Хрустального шара, чтобы в нем показать, у меня нет. Но сам факт таких высказываний (см выше) уже о многом говорит
А ни о чем не говорит, вон ML появился в 1973 году, в 97 был принят новый стандарт, и сейчас вполне жив и здоров, вот только доля на рынке (даже с диалектами типа Ocaml'а) близка к нулю. Это вполне вероятное будущее и для Немерле.
Здравствуйте, VladD2, Вы писали:
VD>А С++ так проектировался когда он еще даже С++-мо не был, а был СиСсКлассами.
И что? Или мне повторить мой ответ Курилке?
VD>>>С++ можно сделать удобным только если таки отказаться от совместимости. J>>Ну мне лично совместимость никак не мешает.
VD>Ну, ты лично этим маральным уродством и пользуешся. А я вот попробовал алтернативу.
Пожалуйста, не надо хамить и считать собеседника глупее себя, как бы это ни было тебе приятно.
Стыдно тебе, как модератору, нарушать правила, за соблюдением которых ты же и обязан следить.
VD>Теперь обратно не то что бы не тянет, а тошнить начинает просто от прсмотра кода на С++.
Ну я даже и не знаю, как это прокомментировать. Разве что как-то вроде: слишком сильные эмоции для человека, который утверждает, что язык для него — лишь инструмент.
VD>Это не опции компиляции, а скорее области видимости (скопы) в которых допустим/недопустим старый/новый синтаксис. Как с опасным кодом в Шарпе.
А, вот ты о чем. В целом согласен, было бы полезно, хоть совсем и не позарез критично. Ну и наверняка, если копать глубже, полезут грабли и так просто разделить фичи не удастся.
VD>Где-то такой подход прокатит. Где-то нужно большая гранулярность. И опять же важно, чтобы кроме указателей были другие средства сделать ту же работу. Иначе на что варнинги то кидать? На сам язык?
Да понял я уже, о чем ты, понял.
VD>Ну, мне вот не надо С++ даже в виде 0х. А ведь когда-то я даже подумать об этом не мог. Так что не надо про "не надо никому".
Не надо никому из пишущих на С++. Ты, очевидно, к ним не относишься.
J>>Двумя режимами точно никто не обойдется, потому что выбрасывать весь старый код ради того, чтоб заюзать одну новую фичу, абсолютно бессмысленно. И не юзать фичу ради сохранения старого кода столь же бессмысленно. А посему никто не будет делать подобных "или-или" режимов — ими просто никто не будет пользоваться.
VD>Я не предлагал выбрасывать.
Ну извини, я понял твою фразу "Я бы тупо ввел два режима" именно как "или-или". откуда ж мне было догадаться, точ на самом деле ты имеешь в виду гранулярность чуть ли не на уровне инструкций.
VD>Я предлагал четко разделить старый иновый, чтобы можно было порвать с совместимостью в новом языке.
Если это будет соответствующим образом гранулироваться — я только за. И, опять же, совсем не 2 режима (все или ничего), а отдельное управление каждой "опасной" фичей.
Здравствуйте, jazzer, Вы писали:
E>>Использование C-ных макросов для более серьезных вещей, по моему опыту, является следствием непродуманного дизайна. Когда на поиск более подходящей реализации не хватило времени, подходящих инструментов или хорошей идеи.
J>Видишь ли, программа, как ни крути — это текстовый файл, и есть вещи, которые хочется делать именно на этом уровне (если, конечно, нет доступа к более продвинутым средствам, типа немер левых макросов, которые работают напрямую с синтаксическим деревом — тогда эти же вещи захочется делать на уровне преобразования дерева), и никакими другими способами ты для этих вещей такой же ясности и лаконичности не добьешься.
Внешний DSL и pre-compile-time генерация кода. Чтобы можно было получить результат этой генерации в виде чистого C++ кода. Чтобы затем отладчиком по нему пройтись можно было. А если этот DSL генерирует какие-то классы/функции, чтобы инструменты типа doxygen могли их в отчет включить.
А то потом всякие эксперименты с созданием своего подъязычка на макросах боком вылазят. По разном причинам. Например, сложно обеспечивать совместимость при необходимости расширения подъязыка.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
E>>>Использование C-ных макросов для более серьезных вещей, по моему опыту, является следствием непродуманного дизайна. Когда на поиск более подходящей реализации не хватило времени, подходящих инструментов или хорошей идеи.
J>>Видишь ли, программа, как ни крути — это текстовый файл, и есть вещи, которые хочется делать именно на этом уровне (если, конечно, нет доступа к более продвинутым средствам, типа немер левых макросов, которые работают напрямую с синтаксическим деревом — тогда эти же вещи захочется делать на уровне преобразования дерева), и никакими другими способами ты для этих вещей такой же ясности и лаконичности не добьешься.
E>Внешний DSL и pre-compile-time генерация кода. Чтобы можно было получить результат этой генерации в виде чистого C++ кода. Чтобы затем отладчиком по нему пройтись можно было. А если этот DSL генерирует какие-то классы/функции, чтобы инструменты типа doxygen могли их в отчет включить.
E>А то потом всякие эксперименты с созданием своего подъязычка на макросах боком вылазят. По разном причинам. Например, сложно обеспечивать совместимость при необходимости расширения подъязыка.
Оно боком вылазит, если делаешь страшные вещи. А если нужно просто немножко пошаманить — то вполне нормально все работает.
Внешние тулы — они, во-первых, внешние, во-вторых, они работают на уровне всего файла, что обычно совсем не надо.
Ну и неудобно просто, у меня порядком опыта было с такой генерацией, и никогда это удобно не было.
Здравствуйте, jazzer, Вы писали:
E>>Внешний DSL и pre-compile-time генерация кода. Чтобы можно было получить результат этой генерации в виде чистого C++ кода. Чтобы затем отладчиком по нему пройтись можно было. А если этот DSL генерирует какие-то классы/функции, чтобы инструменты типа doxygen могли их в отчет включить.
E>>А то потом всякие эксперименты с созданием своего подъязычка на макросах боком вылазят. По разном причинам. Например, сложно обеспечивать совместимость при необходимости расширения подъязыка.
J>Оно боком вылазит, если делаешь страшные вещи. А если нужно просто немножко пошаманить — то вполне нормально все работает. J>Внешние тулы — они, во-первых, внешние, во-вторых, они работают на уровне всего файла, что обычно совсем не надо.
J>Ну и неудобно просто, у меня порядком опыта было с такой генерацией, и никогда это удобно не было.
А ты можешь привести примеры того, о чем говоришь?
А то может получится, что мы вообще о разных вещах разговариваем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
E>>>Внешний DSL и pre-compile-time генерация кода. Чтобы можно было получить результат этой генерации в виде чистого C++ кода. Чтобы затем отладчиком по нему пройтись можно было. А если этот DSL генерирует какие-то классы/функции, чтобы инструменты типа doxygen могли их в отчет включить.
E>>>А то потом всякие эксперименты с созданием своего подъязычка на макросах боком вылазят. По разном причинам. Например, сложно обеспечивать совместимость при необходимости расширения подъязыка.
J>>Оно боком вылазит, если делаешь страшные вещи. А если нужно просто немножко пошаманить — то вполне нормально все работает. J>>Внешние тулы — они, во-первых, внешние, во-вторых, они работают на уровне всего файла, что обычно совсем не надо.
J>>Ну и неудобно просто, у меня порядком опыта было с такой генерацией, и никогда это удобно не было.
E>А ты можешь привести примеры того, о чем говоришь?
E>А то может получится, что мы вообще о разных вещах разговариваем.
ну представь что у тебя есть код на три строчки и его надо размножить десятикратно прям тут же (case-ы в свитче, скажем), причем к функциям это легко не сводится? даже к шаблонным, потому что различия в типах, в строках (литералах) и т.п.
Вот такие три строчки упрятать под одну строчку макроса и потом эти 10 строчек написать — милое дело, все ясно и понятно.
И надежно, кстати, потому что ты полностью защищен от ошибок копи-пейста — у тебя вместо разноженного трехстрочного блока кода (где черт ногу сломит и не поймешь, правильно ли все употреблено или при копи-пейсте всё поменяли, а вот тут забыли) всего одна строчка вызова макроса и каждая сущность там упоминается ровно один раз.
И сразу после этих 10 строчек поставить #undef
Здравствуйте, jazzer, Вы писали:
J>ну представь что у тебя есть код на три строчки и его надо размножить десятикратно прям тут же (case-ы в свитче, скажем), причем к функциям это легко не сводится? даже к шаблонным, потому что различия в типах, в строках (литералах) и т.п. J>Вот такие три строчки упрятать под одну строчку макроса и потом эти 10 строчек написать — милое дело, все ясно и понятно. J>И надежно, кстати, потому что ты полностью защищен от ошибок копи-пейста — у тебя вместо разноженного трехстрочного блока кода (где черт ногу сломит и не поймешь, правильно ли все употреблено или при копи-пейсте всё поменяли, а вот тут забыли) всего одна строчка вызова макроса и каждая сущность там упоминается ровно один раз. J>И сразу после этих 10 строчек поставить #undef
Ну и зачем при этом навороченный механизм макросов?
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>ну представь что у тебя есть код на три строчки и его надо размножить десятикратно прям тут же (case-ы в свитче, скажем), причем к функциям это легко не сводится? даже к шаблонным, потому что различия в типах, в строках (литералах) и т.п. J>>Вот такие три строчки упрятать под одну строчку макроса и потом эти 10 строчек написать — милое дело, все ясно и понятно. J>>И надежно, кстати, потому что ты полностью защищен от ошибок копи-пейста — у тебя вместо разноженного трехстрочного блока кода (где черт ногу сломит и не поймешь, правильно ли все употреблено или при копи-пейсте всё поменяли, а вот тут забыли) всего одна строчка вызова макроса и каждая сущность там упоминается ровно один раз. J>>И сразу после этих 10 строчек поставить #undef
E>Ну и зачем при этом навороченный механизм макросов?
Погоди, ты ведь начал с общего "Макросы в топку" с расшифровкой "Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции. Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь."
То, что я описываю, под твои рамки не подходит, стало быть, в топку
E>Я на внешних DSL-ях делал более навороченную генерацию
Я тоже делал, и не могу сказать, что был счастлив.
Для такого, имхо, лучше встроенный DSL, с поддержкой автокомплитов и прочего.
И что толку мне с того, что doxygen сгенерит документацию для сгенеренных потрохов?
Скажем, зачем мне корячиться и юзать lex/bison/yacc для генерации парсера (и уж тем более зачем мне документация по сгенеренному ими коду), если я могу заюзать Boost.Spirit, который представляет собой вполне валидный С++ и еще с кучей разных вкусностей, которых у внешних тулов нету, и при этом выглядит очень близко к EBNF? Правильно, незачем (в большинстве случаев). И если б мне пришлось для этого юзать макросы — я бы совсем не обиделся.
Или вот scope.exit из твоего любимого D — Саша Насонов реализовал это дело для С++, но с помощью макросов — а попробуй объедь это дело без их помощи — поолезут страшные страшности...
А если бы в С++ были макросы типа немерлевых, позволяющие изменять синтаксис — можно было бы вообще добиться естественного синтаксиса объявления блока.
Здравствуйте, jazzer, Вы писали:
E>>Ну и зачем при этом навороченный механизм макросов?
J>Погоди, ты ведь начал с общего "Макросы в топку" с расшифровкой "Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции. Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь."
J>То, что я описываю, под твои рамки не подходит, стало быть, в топку
Ну, кстати, такие вещи так же достаточно неудобны, например, при отладке. Скажем отладочную печать в нужное место не вставишь. Так что как раз с таких примеров и начинается страсть к макросам.
E>>Я на внешних DSL-ях делал более навороченную генерацию
примера (с генерацией кода по выборке данных).
J>Я тоже делал, и не могу сказать, что был счастлив.
J>Для такого, имхо, лучше встроенный DSL, с поддержкой автокомплитов и прочего.
Которого для C++ никогда не будет. Мы ведь здесь все еще про C++ говорим
J>И что толку мне с того, что doxygen сгенерит документацию для сгенеренных потрохов?
Ну, кстати, Java IDE используют JavaDoc комментарии при выдаче подсказок. Почему бы какому-нибудь KDevelop не делать то же самое с помощью doxygen комментариев? Насколько я помню, даже Visual Studio 6 умела показывать части комментариев при автокомплите. И опять же мы остаемся в рамках старого доброго C++, который уже сейчас поддерживают сотни разных инструментов.
J>Скажем, зачем мне корячиться и юзать lex/bison/yacc для генерации парсера (и уж тем более зачем мне документация по сгенеренному ими коду), если я могу заюзать Boost.Spirit, который представляет собой вполне валидный С++ и еще с кучей разных вкусностей, которых у внешних тулов нету, и при этом выглядит очень близко к EBNF? Правильно, незачем (в большинстве случаев). И если б мне пришлось для этого юзать макросы — я бы совсем не обиделся.
Насколько я помню, lex/bison/yacc достаточно примитивны по сравнению с современными конкурентами типа ANTLR, Ragel и пр. Зачем мне брать монстрообразный Boost.Spirit, если можно взять специальный инструмент, очень хорошо заточенный под свои задачи. Для ANTLR есть достаточное количество примеров, документации и даже какой-то визуальный тул для отладки своих парсеров.
J>Или вот scope.exit из твоего любимого D — Саша Насонов реализовал это дело для С++, но с помощью макросов — а попробуй объедь это дело без их помощи — поолезут страшные страшности...
Вот в этом и проблема, лучше бы не Саша Насонов с помощью макросов, а Страуструп в компиляторе языка. А если это в языке не сделано, то может есть на это причины? Может в scope.exit есть потенциальные проблемы, которые разработчики языка видят, а вот обычные пользователи -- нет.
Тем более, что у scope в D есть три варианта, поддерживает ли их все реализация Насонова?
J>А если бы в С++ были макросы типа немерлевых, позволяющие изменять синтаксис — можно было бы вообще добиться естественного синтаксиса объявления блока.
Ну посмотри на то, что с Lisp-ами произошло. У каждого разработчика свой язык.
Как показывала практика, наиболее успешными и востребованными являлись языки, в которых изменение синтаксиса штатными средствами языка невозможно. Java и C# тому яркие примеры.
Я вообще негативно отношусь к предоставлению разработчикам возможности создавать свои подъязыки и изменять синтаксис основного языка -- слишком это сложно, сделать хороший язык. За всю историю программирования это удавалось очень не многим.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
E>>>Ну и зачем при этом навороченный механизм макросов?
J>>Погоди, ты ведь начал с общего "Макросы в топку" с расшифровкой "Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции. Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь."
J>>То, что я описываю, под твои рамки не подходит, стало быть, в топку
E>Ну, кстати, такие вещи так же достаточно неудобны, например, при отладке. Скажем отладочную печать в нужное место не вставишь. Так что как раз с таких примеров и начинается страсть к макросам.
Внешняя генерация столь же неудобна, по тем же самым причинам.
E>>>Я на внешних DSL-ях делал более навороченную генерацию
примера (с генерацией кода по выборке данных).
J>>Я тоже делал, и не могу сказать, что был счастлив.
J>>Для такого, имхо, лучше встроенный DSL, с поддержкой автокомплитов и прочего.
E>Которого для C++ никогда не будет. Мы ведь здесь все еще про C++ говорим
Вот тебе пример — Boost.Spirit. Или Boost.Python. Или Boost.Expressive.
J>>И что толку мне с того, что doxygen сгенерит документацию для сгенеренных потрохов?
E>Ну, кстати, Java IDE используют JavaDoc комментарии при выдаче подсказок. Почему бы какому-нибудь KDevelop не делать то же самое с помощью doxygen комментариев? Насколько я помню, даже Visual Studio 6 умела показывать части комментариев при автокомплите. И опять же мы остаемся в рамках старого доброго C++, который уже сейчас поддерживают сотни разных инструментов.
не, ты не понял, я имею в виду, что мне нужна документация на одну единственную строчку, где вызван макрос, а не документация по километрам сгенеренных потрохов.
J>>Скажем, зачем мне корячиться и юзать lex/bison/yacc для генерации парсера (и уж тем более зачем мне документация по сгенеренному ими коду), если я могу заюзать Boost.Spirit, который представляет собой вполне валидный С++ и еще с кучей разных вкусностей, которых у внешних тулов нету, и при этом выглядит очень близко к EBNF? Правильно, незачем (в большинстве случаев). И если б мне пришлось для этого юзать макросы — я бы совсем не обиделся.
E>Насколько я помню, lex/bison/yacc достаточно примитивны по сравнению с современными конкурентами типа ANTLR, Ragel и пр. Зачем мне брать монстрообразный Boost.Spirit, если можно взять специальный инструмент, очень хорошо заточенный под свои задачи. Для ANTLR есть достаточное количество примеров, документации и даже какой-то визуальный тул для отладки своих парсеров.
Сорри, а чем тебе спирит не заточен под эти же самые задачи? С дополнительным плюсом интегрированности в язык, т..е ты можешь использовать все остальные механизмы С++ для работы с ним.
J>>Или вот scope.exit из твоего любимого D — Саша Насонов реализовал это дело для С++, но с помощью макросов — а попробуй объедь это дело без их помощи — поолезут страшные страшности...
E>Вот в этом и проблема, лучше бы не Саша Насонов с помощью макросов, а Страуструп в компиляторе языка. А если это в языке не сделано, то может есть на это причины? Может в scope.exit есть потенциальные проблемы, которые разработчики языка видят, а вот обычные пользователи -- нет.
Не лучше. И проблема не в этом.
Одна из причин — на все фичи не напасешься времени. Мало ли какую фичу изобретут в следующем году в очередном языке, и она будет признана полезной и в С++? И что, на каждый чих менять язык?
Язык должен позволять подобные фичи, в которых возникла необходимость прямо сейчас, реализовывать прямо сейчас, и чтоб они выходили более-менее читабельными.
Для этой цели у нас есть макросы как средство генерации кода внутри самого языка, если нельзя сгенерировать этот код другими средствами (шаблонами, скажем).
E>Тем более, что у scope в D есть три варианта, поддерживает ли их все реализация Насонова?
Нет, ее невозможно в С++ сделать в принципе (в текущей редакции). Только scope_exit.
J>>А если бы в С++ были макросы типа немерлевых, позволяющие изменять синтаксис — можно было бы вообще добиться естественного синтаксиса объявления блока.
E>Ну посмотри на то, что с Lisp-ами произошло. У каждого разработчика свой язык.
E>Как показывала практика, наиболее успешными и востребованными являлись языки, в которых изменение синтаксиса штатными средствами языка невозможно. Java и C# тому яркие примеры.
Ты еще оберон вспомни, в нем еще и оверхеда нету
Ты всерьез считаешь, что успех жавы и шарпа в том, что нельзя изменить синтаксис, а не в том, что их версии пекутся со скоростью 3 новые версии на одну новую версию С++ и в прочих организационных преимуществах?
E>Я вообще негативно отношусь к предоставлению разработчикам возможности создавать свои подъязыки и изменять синтаксис основного языка -- слишком это сложно, сделать хороший язык. За всю историю программирования это удавалось очень не многим.
В широком смысле, ты эти языки создаешь ежечасно.
Написал два взаимодействующих класса — вот тебе и мини-язык, сразу.
Все многочисленные классы и функции, которые ты пишешь, служат тому, чтобы решение задачи в результате записывалось несколькими понятными с первого взгляда строчками, которые уже зовут внутри себя все свои потроха.
А это и означает, что ты для этой своей задачи только что создал свой мини-язык.
Здравствуйте, eao197, Вы писали:
E>Я вообще негативно отношусь к предоставлению разработчикам возможности создавать свои подъязыки и изменять синтаксис основного языка -- слишком это сложно, сделать хороший язык. За всю историю программирования это удавалось очень не многим.
В общем, согласен.
E>>Я вообще негативно отношусь к предоставлению разработчикам возможности создавать свои подъязыки и изменять синтаксис основного языка -- слишком это сложно, сделать хороший язык. За всю историю программирования это удавалось очень не многим.
J>В широком смысле, ты эти языки создаешь ежечасно. J>Написал два взаимодействующих класса — вот тебе и мини-язык, сразу. J>Все многочисленные классы и функции, которые ты пишешь, служат тому, чтобы решение задачи в результате записывалось несколькими понятными с первого взгляда строчками, которые уже зовут внутри себя все свои потроха. J>А это и означает, что ты для этой своей задачи только что создал свой мини-язык.
Не совсем. Семантика разная, а вот синтаксис одинаковый. eao197 говорит про различные синтаксисы, порожденные макросами.
Здравствуйте, jazzer, Вы писали:
E>>Ну, кстати, такие вещи так же достаточно неудобны, например, при отладке. Скажем отладочную печать в нужное место не вставишь. Так что как раз с таких примеров и начинается страсть к макросам.
J>Внешняя генерация столь же неудобна, по тем же самым причинам.
Не соглашусь, т.к. это противоречит тому, с чем мне приходилось сталкиваться. Например, у меня в SObjectizer много описаний делается C-ными макросами (кстати, один из корней нелюбви к макросам). И когда временами приходится посмотреть, что происходит во вспомогательном коде перед вызовом обработчика события, то приходится править исходник макроса. Соответственно, модифицируются все участки кода, порожденные этим макросом. И, если модификацию макроса сделать неаккуратно, то вместо одной отладочной печати получишь в буквальном смысле миллион.
С другой стороны, я использую систему сериализации, в которой по внешнему описанию в виде DDL-файла строится простыня вспомогательного кода для каждого сериализуемого класса. И результирующий C++ный код для конкретного класса или атрибута я могу подправить.
E>>>>Я на внешних DSL-ях делал более навороченную генерацию
примера (с генерацией кода по выборке данных).
J>>>Я тоже делал, и не могу сказать, что был счастлив.
J>>>Для такого, имхо, лучше встроенный DSL, с поддержкой автокомплитов и прочего.
E>>Которого для C++ никогда не будет. Мы ведь здесь все еще про C++ говорим
J>Вот тебе пример — Boost.Spirit. Или Boost.Python. Или Boost.Expressive.
А вот интересно, когда ты используешь Boost.Expressive тебе подсказка выдается по public-интерфейсам Boost.Expressive или по синтаксису регулярных выражений?
J>>>И что толку мне с того, что doxygen сгенерит документацию для сгенеренных потрохов?
E>>Ну, кстати, Java IDE используют JavaDoc комментарии при выдаче подсказок. Почему бы какому-нибудь KDevelop не делать то же самое с помощью doxygen комментариев? Насколько я помню, даже Visual Studio 6 умела показывать части комментариев при автокомплите. И опять же мы остаемся в рамках старого доброго C++, который уже сейчас поддерживают сотни разных инструментов.
J>не, ты не понял, я имею в виду, что мне нужна документация на одну единственную строчку, где вызван макрос, а не документация по километрам сгенеренных потрохов.
Так это от use case зависит. Если я использую инструмент, который мне по XSD/DTD или ASN.1 описанию строит набор C++ классов, то естественно, что я хотел бы видеть документацию по сгенерированным классам.
А если макросы используются, например, для компактной записи однотипных case в switch-е, тогда другое дело.
J>>>Скажем, зачем мне корячиться и юзать lex/bison/yacc для генерации парсера (и уж тем более зачем мне документация по сгенеренному ими коду), если я могу заюзать Boost.Spirit, который представляет собой вполне валидный С++ и еще с кучей разных вкусностей, которых у внешних тулов нету, и при этом выглядит очень близко к EBNF? Правильно, незачем (в большинстве случаев). И если б мне пришлось для этого юзать макросы — я бы совсем не обиделся.
E>>Насколько я помню, lex/bison/yacc достаточно примитивны по сравнению с современными конкурентами типа ANTLR, Ragel и пр. Зачем мне брать монстрообразный Boost.Spirit, если можно взять специальный инструмент, очень хорошо заточенный под свои задачи. Для ANTLR есть достаточное количество примеров, документации и даже какой-то визуальный тул для отладки своих парсеров.
J>Сорри, а чем тебе спирит не заточен под эти же самые задачи? С дополнительным плюсом интегрированности в язык, т..е ты можешь использовать все остальные механизмы С++ для работы с ним.
А Spirit -- он LR(1), LALR(1) или LR(*) парсер?
Все может упереться в выразительные возможности языка описания граматики, наличия готовых средств для получения AST, удобства поддержки стека токенов во время парсинга, внятности и точности сообщений о синтаксических ошибках, да и элементарной скорости выполнения парсинга, наконец. Так что интегрированность инструмента в язык -- это может быть еще и недостаток, так как он влияет на остальные критерии оценки.
J>>>Или вот scope.exit из твоего любимого D — Саша Насонов реализовал это дело для С++, но с помощью макросов — а попробуй объедь это дело без их помощи — поолезут страшные страшности...
E>>Вот в этом и проблема, лучше бы не Саша Насонов с помощью макросов, а Страуструп в компиляторе языка. А если это в языке не сделано, то может есть на это причины? Может в scope.exit есть потенциальные проблемы, которые разработчики языка видят, а вот обычные пользователи -- нет. J>Не лучше. И проблема не в этом. J>Одна из причин — на все фичи не напасешься времени. Мало ли какую фичу изобретут в следующем году в очередном языке, и она будет признана полезной и в С++? И что, на каждый чих менять язык?
Нет. В язык нужно включать только то, что действительно необходимо, что зарекомендовало себя во множестве проектов.
А обратный пример -- любимый мной когда-то язык D. Куда автор пихает все, что ему в голову взбредает. В итоге -- отсутствие стабильного языка в течении 7-ми лет.
J>Язык должен позволять подобные фичи, в которых возникла необходимость прямо сейчас, реализовывать прямо сейчас, и чтоб они выходили более-менее читабельными.
Вот это как раз прямой путь к помойке. Не может любая кухарка управлять государством. Так же язык должен разрабатывать кто-то один или одна команда. А когда каждый будет добавлять собственные варианты foreach-ей, ничего хорошего из этого не выйдет.
J>>>А если бы в С++ были макросы типа немерлевых, позволяющие изменять синтаксис — можно было бы вообще добиться естественного синтаксиса объявления блока.
E>>Ну посмотри на то, что с Lisp-ами произошло. У каждого разработчика свой язык.
E>>Как показывала практика, наиболее успешными и востребованными являлись языки, в которых изменение синтаксиса штатными средствами языка невозможно. Java и C# тому яркие примеры.
J>Ты еще оберон вспомни, в нем еще и оверхеда нету
Оберон обязан дурной славе незабвенному Сергею Губанову. Который с благими намерениями обосрал весьма приличный язык. Он минималистичен и прост, обучить ему нового человека можно без проблем. И за счет своей простоты в нем мало граблей. Конечно же, примитивность Оберона вряд ли позволит использовать его для решения сложных задач, однако для некоторых областей, где предсказуемость и прозрачность кода очень важна, Оберон не самый плохой выбор. Особенно если сравнивать с C. Не зря же Оберон до сих пор во встраиваемых системах для авиации используется. Так что Оберон как раз является примером удачно спроектированного минималистичного языка.
Другой хороший пример -- Eiffel. В отличии от C++, в Eiffel можно заглянуть в любую библиотеку и понять, как она работает. Поскольку все делается простыми приемами. В отличии от трехэтажных шаблонов в некоторых C++ных библиотеках.
J>Ты всерьез считаешь, что успех жавы и шарпа в том, что нельзя изменить синтаксис, а не в том, что их версии пекутся со скоростью 3 новые версии на одну новую версию С++ и в прочих организационных преимуществах?
Я считаю, что эти организационные преимущества не в последнюю очередь обязаны тому, что язык не позволяет любому программисту создавать собственные поддиалекты. Или страшилки, вроде Boost.Spirit-а (не обижайся, но вот не могу понять, какая польза от реализации персера на C++ных шаблонах).
E>>Я вообще негативно отношусь к предоставлению разработчикам возможности создавать свои подъязыки и изменять синтаксис основного языка -- слишком это сложно, сделать хороший язык. За всю историю программирования это удавалось очень не многим.
J>В широком смысле, ты эти языки создаешь ежечасно. J>Написал два взаимодействующих класса — вот тебе и мини-язык, сразу. J>Все многочисленные классы и функции, которые ты пишешь, служат тому, чтобы решение задачи в результате записывалось несколькими понятными с первого взгляда строчками, которые уже зовут внутри себя все свои потроха. J>А это и означает, что ты для этой своей задачи только что создал свой мини-язык.
Так вот мне и нравится, что существует всего один слой сущностей в программе -- классы/объекты и методы. Все программа на любом уровне абракции записывается только в этих терминах.
При расширении языка (при изменении синтаксиса) эта стройность теряется. За несколькими строчками уже стоят не только объекты и методы, там уже появляются модификации AST, какие-то действия, которые скрыты от разработчика, и только где-то в конце все это преобразуется в тот же самый набор объектов и методов.
А если к C++ с его мультипарадигменностью метапрограммированием на шаблонах еще и Nemerle-вую макросистему добавить -- все, кранты. Будет MegaMacroBoost, в деталях реализации которого вообще мало кто сможет разобраться
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>С другой стороны, я использую систему сериализации, в которой по внешнему описанию в виде DDL-файла строится простыня вспомогательного кода для каждого сериализуемого класса. И результирующий C++ный код для конкретного класса или атрибута я могу подправить.
А, так ты потом правишь сгенеренный код... Я тебя не понял сначала.
Ну так я в таких случаях делаю то же самое — прогоняю через препроцессор (g++ -E), беру соответствующий кусок кода и вставляю на место вызова макроса (ну и комментирую сам вызов, понятное дело), а дальше — по твоему сценарию.
Заодно я защищен от перекомпиляций/перегенераций, в отличие от тебя, когда при перегенерации все твои изменения улетят.
J>>Вот тебе пример — Boost.Spirit. Или Boost.Python. Или Boost.Expressive.
E>А вот интересно, когда ты используешь Boost.Expressive тебе подсказка выдается по public-интерфейсам Boost.Expressive или по синтаксису регулярных выражений?
Причем тут подсказка? Все эти библиотеки предоставляют встроенный DSL, причем в строгом соответствии с синтаксисом С++, за который ты так ратуешь, хотя он и не очень тут удобен оказывается.
E>Так это от use case зависит. Если я использую инструмент, который мне по XSD/DTD или ASN.1 описанию строит набор C++ классов, то естественно, что я хотел бы видеть документацию по сгенерированным классам.
Тут согласен.
J>>Сорри, а чем тебе спирит не заточен под эти же самые задачи? С дополнительным плюсом интегрированности в язык, т..е ты можешь использовать все остальные механизмы С++ для работы с ним.
E>А Spirit -- он LR(1), LALR(1) или LR(*) парсер? E>Все может упереться в выразительные возможности языка описания граматики, наличия готовых средств для получения AST, удобства поддержки стека токенов во время парсинга, внятности и точности сообщений о синтаксических ошибках, да и элементарной скорости выполнения парсинга, наконец.
Всегда и везде можно упереться в одно или в другое. У Спирита есть режим отладки, когда он все распечатывает, что спарсилось, можно ходить по распарсенным деревьям и т.д.
А самое главное — это скорость и легкость, с которой пишется парсер и сопутствующие парсингу действия (грубо говоря: "если распарсили число — положи его вот в эту переменную, а потом позови вот эту функцию").
Я очень сомневаюсь, что можно легко разобраться в коде, который генерит внешний тул типа ANTLR, особенно когда задачи разобраться с его потрохами не стоит, а стоит задача распарсить и сделать что-нть в соответствии с распарсенным.
E>Так что интегрированность инструмента в язык -- это может быть еще и недостаток, так как он влияет на остальные критерии оценки.
Это просто еще один критерий оценки, причем немаловажный, потому что с внешними генераторами некоторых вещей в принципе не добиться, потому что они понятия не имеют об особенностях С++ (об областях видимости, в частности).
Опять же, тот факт, что синтаксис спирита близок к EBNF настолько, насколько это возможно, оставаясь в рамках грамматики С++, то миграция на внешний тул не составит труда.
E>Нет. В язык нужно включать только то, что действительно необходимо, что зарекомендовало себя во множестве проектов.
Не могу согласиться. Язык — это не набор готовых и всем необходимых решений, а средство для создания этого набора.
И чем больше язык позволят, не усложняя при этом простые вещи — тем лучше.
E>А обратный пример -- любимый мной когда-то язык D. Куда автор пихает все, что ему в голову взбредает. В итоге -- отсутствие стабильного языка в течении 7-ми лет.
Вот именно. А если бы в языке были достаточно гибкие концепции — все эти вещи, котоыре он пихает, уехали бы в стандартную библиотеку.
J>>Язык должен позволять подобные фичи, в которых возникла необходимость прямо сейчас, реализовывать прямо сейчас, и чтоб они выходили более-менее читабельными.
E>Вот это как раз прямой путь к помойке. Не может любая кухарка управлять государством.
Естественно, только это абсолютно не зависит от средства — макросы это, шаблоны или просто классы.
Если ты дашь "любой кухарке" спроектировать с десяток классов — получишь ту же самую помойку.
Я думаю, глупо спорить о том, что можные инструменты должны быть только в умелых руках, и вопрос это — чисто организационный.
E>Так же язык должен разрабатывать кто-то один или одна команда. А когда каждый будет добавлять собственные варианты foreach-ей, ничего хорошего из этого не выйдет.
См. выше и еще выше (про язык и про обезьян с гранатами).
Кстати, вот foreach — вещь, безусловно, всем нужная, а в языке ее нету, есть супермощная, но не особо удобная и безопасная std::for_each.
J>>>>А если бы в С++ были макросы типа немерлевых, позволяющие изменять синтаксис — можно было бы вообще добиться естественного синтаксиса объявления блока.
E>>>Ну посмотри на то, что с Lisp-ами произошло. У каждого разработчика свой язык.
Лисп — это 1) академический язык и 2) очень неудобный при использовании только базового синтаксиса. Естественно, что его диалектов расплодилось страшное количество.
Если смотреть шире, то в любом языке на определенном множестве задач всегда образуются более-менее центральные вещи, которые определяют, что будет вокруг, как кому себя вести, и т.д. Возьми вот MFC, к примеру.
E>>>Как показывала практика, наиболее успешными и востребованными являлись языки, в которых изменение синтаксиса штатными средствами языка невозможно. Java и C# тому яркие примеры.
J>>Ты еще оберон вспомни, в нем еще и оверхеда нету
E>Так что Оберон как раз является примером удачно спроектированного минималистичного языка.
На котором удобно решать только минималистичные задачи.
Ты за такой язык и ратуешь?
E>Другой хороший пример -- Eiffel. В отличии от C++, в Eiffel можно заглянуть в любую библиотеку и понять, как она работает. Поскольку все делается простыми приемами. В отличии от трехэтажных шаблонов в некоторых C++ных библиотеках.
В смысле — заглянуть? А как же "интеллектуальная собственность"?
J>>Ты всерьез считаешь, что успех жавы и шарпа в том, что нельзя изменить синтаксис, а не в том, что их версии пекутся со скоростью 3 новые версии на одну новую версию С++ и в прочих организационных преимуществах?
E>Я считаю, что эти организационные преимущества не в последнюю очередь обязаны тому, что язык не позволяет любому программисту создавать собственные поддиалекты. Или страшилки, вроде Boost.Spirit-а (не обижайся, но вот не могу понять, какая польза от реализации персера на C++ных шаблонах).
А я считаю, что ну никакой связи нет. Есть компании, которые вбухивают огромные средства в свои детища, поэтому крайне быстро появляются огромные стандартные библиотеки, до того, как возникнет зоопарк альтернативных решений одного и того же.
А во-вторых, страшилки вроде буста являются страшилками не их любви к искусству, а именно потому, что язык не позволяет реализовать нужную функциональность просто. Если бы позволял — никто бы ни в жисть не парился с трехэтажными шаблонами.
Про Спирит — смотри совсем выше. Мне-то чего обижаться — я его использую на каждом шагу и счастлив
E>Так вот мне и нравится, что существует всего один слой сущностей в программе -- классы/объекты и методы. Все программа на любом уровне абракции записывается только в этих терминах.
Это она только на уровне текста так записывается.
А реально при программировании ты, помимо объектов/методов, должен держать в голове кучу разной информации о том, как они все совокупляются, в каком порядке что можно звать, как оно аукнется и где откликнется, и т.д. и т.п.
И вот когда подобные вещи удается упрятать в (мини-)язык — это реальная победа.
За примером далеко ходить не надо — подумай на тему const и необходимости его в языке.
E>При расширении языка (при изменении синтаксиса) эта стройность теряется. За несколькими строчками уже стоят не только объекты и методы, там уже появляются модификации AST, какие-то действия, которые скрыты от разработчика, и только где-то в конце все это преобразуется в тот же самый набор объектов и методов.
и это правильно, потому что позволяет кратко и понятно выражать более высокоуровневые концепции, которые иначе потерялись бы за лесом объектов и методов.
E>А если к C++ с его мультипарадигменностью метапрограммированием на шаблонах еще и Nemerle-вую макросистему добавить -- все, кранты. Будет MegaMacroBoost, в деталях реализации которого вообще мало кто сможет разобраться
Ты за деревьями теряешь лес. Все навороты и фичи языков нужны исключительно для того, чтобы сделать прикладной код проще, понятнее и безопаснее, не более того, а не для того, чтобы написать "MegaMacroBoost, в деталях реализации которого вообще мало кто сможет разобраться".
З.Ы. Если будешь отвечать на это сообщение еще более длинным — отвечай в несколько приемов, хорошо? А то я думал, не закончу это сегодня
Здравствуйте, jazzer, Вы писали:
E>>С другой стороны, я использую систему сериализации, в которой по внешнему описанию в виде DDL-файла строится простыня вспомогательного кода для каждого сериализуемого класса. И результирующий C++ный код для конкретного класса или атрибута я могу подправить.
J>А, так ты потом правишь сгенеренный код... Я тебя не понял сначала. J>Ну так я в таких случаях делаю то же самое — прогоняю через препроцессор (g++ -E), беру соответствующий кусок кода и вставляю на место вызова макроса (ну и комментирую сам вызов, понятное дело), а дальше — по твоему сценарию.
Вспоминаю эти трюки как страшный сон -- когда-то давно я пытался таким образом разобраться в каких-то деталях windows.h
J>Заодно я защищен от перекомпиляций/перегенераций, в отличие от тебя, когда при перегенерации все твои изменения улетят.
Ничего подобного -- я могу запретить перегенерацию или заинклюдить копию вспомогательного кода, которая не перегенерируется
J>>>Вот тебе пример — Boost.Spirit. Или Boost.Python. Или Boost.Expressive.
E>>А вот интересно, когда ты используешь Boost.Expressive тебе подсказка выдается по public-интерфейсам Boost.Expressive или по синтаксису регулярных выражений?
J>Причем тут подсказка? Все эти библиотеки предоставляют встроенный DSL, причем в строгом соответствии с синтаксисом С++, за который ты так ратуешь, хотя он и не очень тут удобен оказывается.
Ну просто если уж заводить речь о подсказках, то хорошо бы было их получать по предметной области. Пишешь регулярное выражение -- получаешь подсказки по регулярному выражению. Ну или хотя бы подсветку синтаксиса. Вот, например, что я вижу в ViM-е при редактировании Ruby кода:
ViM знает, что внутри строк с двойными кавычками (которые другим цветом выделяются) можно вставлять фрагменты Ruby кода в специальных скобках: #{}. Поэтому ViM умеет выделять этот фрагмент из строки. Более того, глобальные переменные, начинающиеся с $ в ViM помечаются другим цветом и это так же отображается внутри строки.
Так вот когда мы говорим о встраивании DSL-ей внутрь языка, то хотелось бы, чтобы любой инструмент, который расчитан на этот язык, мог правильно и осмысленно понимать наши DSL-и. И если DSL представляет средства для работы с регулярными выражениями, то хотя бы подсвечивать эти выражения соответствующим образом.
E>>А Spirit -- он LR(1), LALR(1) или LR(*) парсер? E>>Все может упереться в выразительные возможности языка описания граматики, наличия готовых средств для получения AST, удобства поддержки стека токенов во время парсинга, внятности и точности сообщений о синтаксических ошибках, да и элементарной скорости выполнения парсинга, наконец. J>Всегда и везде можно упереться в одно или в другое. У Спирита есть режим отладки, когда он все распечатывает, что спарсилось, можно ходить по распарсенным деревьям и т.д. J>А самое главное — это скорость и легкость, с которой пишется парсер и сопутствующие парсингу действия (грубо говоря: "если распарсили число — положи его вот в эту переменную, а потом позови вот эту функцию").
А ты можешь сравнить легкость и скорость разработки парсеров, например, при помощи Coco/R, ANTLR или Ragel и Boost.Spirit? Ведь дело в том, что они уже давно далеко ушли вперед по сравнению с lex/yacc. И вызов методов/сохранение результатов там так же делается тривиально.
J>Я очень сомневаюсь, что можно легко разобраться в коде, который генерит внешний тул типа ANTLR, особенно когда задачи разобраться с его потрохами не стоит, а стоит задача распарсить и сделать что-нть в соответствии с распарсенным.
Я больше чем уверен, что разобраться в коде, сгенерированном Ragel или ANTLR вообще удасться, т.к. там используются специальные алгоритмы для генерации оптимального кода для парсинга конкретной граматики. Т.е. генерируется специфический конечный автомат. Посмотри, например, на стартовой страничке Ragel-я пример того, что он строит.
J>Опять же, тот факт, что синтаксис спирита близок к EBNF настолько, насколько это возможно, оставаясь в рамках грамматики С++, то миграция на внешний тул не составит труда.
Это, вообще-то не факт. Поскольку подобные инструменты используют свой специализированный язык описания, перемежающий декларации граматики и синтаксические действия.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
E>>Нет. В язык нужно включать только то, что действительно необходимо, что зарекомендовало себя во множестве проектов. J>Не могу согласиться. Язык — это не набор готовых и всем необходимых решений, а средство для создания этого набора.
Тут не понял. Язык -- это набор неких концепций, неких кирпичиков. Чем логичнее и целостнее этот набор, тем лучше. На основе этих кирпичиков нужно создавать прикладные решения. А если язык предлагает достраивать сам себя, то вот это мне и не нравится. Язык должны достраивать разработчики языка, а не пользователи.
J>И чем больше язык позволят, не усложняя при этом простые вещи — тем лучше.
Тут не однозначно. Должна выдерживаться какая-то разумная мера сложности.
E>>А обратный пример -- любимый мной когда-то язык D. Куда автор пихает все, что ему в голову взбредает. В итоге -- отсутствие стабильного языка в течении 7-ми лет. J>Вот именно. А если бы в языке были достаточно гибкие концепции — все эти вещи, котоыре он пихает, уехали бы в стандартную библиотеку.
Вот сильно сомневаюсь, что такие вещи, как константность, замыкания, lazy-аргументы, scope-классы и scope.exit, design by contract могли бы уехать в стандартную библиотеку.
E>>Так что Оберон как раз является примером удачно спроектированного минималистичного языка. J>На котором удобно решать только минималистичные задачи. J>Ты за такой язык и ратуешь?
Минималистичность и сложность, и ответственность проекта -- это скорее ортогональные понятия. Если я делаю встроенный софт для радиолокационной станции, то там всего-то может быть 30K строк кода. Но зато уровень требований к качеству и надежности этих 30K строк может быть гораздо выше, чем у, например, SMPP-шлюза в 150K строк кода.
А ратую я за язык, который сочетал бы в себе разумную минималистичность и достаточную мощность. У Оберона-то как раз минималистичность неразумная
Наиболее близкий к моему пониманию хорошего языка -- Eiffel. Но там свои тараканы.
J>А во-вторых, страшилки вроде буста являются страшилками не их любви к искусству, а именно потому, что язык не позволяет реализовать нужную функциональность просто. Если бы позволял — никто бы ни в жисть не парился с трехэтажными шаблонами.
Позволю себе не согласиться. Boost.Lambda, имхо, как раз пример такой любви к искусству. Вроде как смогли вроде как настоящую лямбду сделать. Ну или метапрограммирование на шаблонах, которое использует побочный эффект.
По мне так: либо какая-то штука работает хорошо, она проста и понятна, либо не нужно делать суррогаты. В этом плане автор D поступает разумно -- нужны лямбды -- пожалуйста, вот вам делегаты и lazy аргументы, а сейчас еще и замыкания сделали. Нужно метапрограммирование -- вот вам static if, is и std.traits. Как раз хороший пример того, как нужные и восстребованные вещи в язык добавляются.
И, в моем понимании, нормальный язык и должен так развиваться. Все нововедения только через основную команду разработчиков.
E>>Так вот мне и нравится, что существует всего один слой сущностей в программе -- классы/объекты и методы. Все программа на любом уровне абракции записывается только в этих терминах.
J>Это она только на уровне текста так записывается. J>А реально при программировании ты, помимо объектов/методов, должен держать в голове кучу разной информации о том, как они все совокупляются, в каком порядке что можно звать, как оно аукнется и где откликнется, и т.д. и т.п. J>И вот когда подобные вещи удается упрятать в (мини-)язык — это реальная победа. J>За примером далеко ходить не надо — подумай на тему const и необходимости его в языке.
Вот здесь не понял. Вот, допустим, в языке нет const. Кто-то захотел его сделать с помощью макросистемы. Как это возможно?
E>>При расширении языка (при изменении синтаксиса) эта стройность теряется. За несколькими строчками уже стоят не только объекты и методы, там уже появляются модификации AST, какие-то действия, которые скрыты от разработчика, и только где-то в конце все это преобразуется в тот же самый набор объектов и методов.
J>и это правильно, потому что позволяет кратко и понятно выражать более высокоуровневые концепции, которые иначе потерялись бы за лесом объектов и методов.
Так вот мне и кажется, что если разработчик не смог придумать такие высокоуровневые классы и методы, которые бы позволили лаконично решить задачу, то где гарантия, что он сможет сделать это с помощью языка?
E>>А если к C++ с его мультипарадигменностью метапрограммированием на шаблонах еще и Nemerle-вую макросистему добавить -- все, кранты. Будет MegaMacroBoost, в деталях реализации которого вообще мало кто сможет разобраться
J>Ты за деревьями теряешь лес. Все навороты и фичи языков нужны исключительно для того, чтобы сделать прикладной код проще, понятнее и безопаснее, не более того, а не для того, чтобы написать "MegaMacroBoost, в деталях реализации которого вообще мало кто сможет разобраться".
Иногда для получения нужных характеристик прикладного кода нужно понимать, как устроены и работают задействованные библиотеки. Если понять это сложно, то и на качестве прикладного код это отразиться обязательно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, jazzer, Вы писали:
VD>>или даже: VD>>
Зачем C++?
J>или даже: J>
Зачем?
Это уже теряет смысл. Тогда лучше так:
С++?
VD>>Те же текстуаьные макросы можно заменить немерлоподобными. J>Вот тут я согласен. Немерлевые макросы в С++ я очень хотел бы видеть — то, что сейчас делается текстовым препроцессором, стало бы гораздо читабельнее, проще и надежнее. Ну и еще кое-что хотел бы видеть, но это нереально, по крайней мере, в текущей редакции языка (слишком глубоко придется лезть в его объектную модель).
О том и речь. Потому я уже лет 5 как забил на то чтобы что-то ждать от С++.
J>Насчет остального — ну вот я уже столько времени не напарывался на проблемы с адресной арифметикой...
Ладно я эту тему даже развивать не хочу. Все круты до тех пор пока жареный петух в зад не клюнет, а потом нчинается "Какой козел тут напортачил?...". Потом ты не один. Ну, и даже гении тратят времы и силы на соврешенно бессмысленный контроль. Вн тот же Паша на што уж знаток и фанат С++, но когда попробовал на Питоне пописать, так сразу стал говорить о том насколько это проще.
J> Но это, конечно, при условии, что у тебя в проекте не работают студенты.
Да пофигу. С++ — это по любому якорь тормозящий процесс разработки. Понятно, что человек зверюга приспосабливающаяся к чему угодно, но при прочих равных С++ хреновый выбор. С++ оправданно использовать только если основной приоритет при разработке — это экономия ресурсов компьютера, а качество и скорость разработки не так важны.
J>Но при этом другого способа пройтись по встроенному массиву или встроенной строке, кроме адресной арифметики, нету, если не хочется терять скорость, конечно.
Дык о том и речь. В современно, полноценном языке массивы должны быть примитивами языка. Как и многое дургое. Потому я и говорю, что язык нужно очень серьезно пересматривать. То на что закрывали глаза в С, как в высокоуровневом ассемблере не катит для современного языка.
J>Хотя в моем коде подобные вещи обычно упрятаны в классы либо просто используются алгоритмы STL.
Тебе не кажется маразмом тот яакт, что ты не можешь напрямую пользоваться такими базовыми фичами как массиы? И не кажется, что раз уж даже массивы не являются небезопасными, то крайне важно встроить в язык понятие безопасного и небезопасного контекста, так чтобы глядя на прикладной код ты четко понимал, что в нем не может оказаться адресной арифметики и т.п.? Вот в коде STL пусть убдет четко выделенный участок кода реализующий базовые вещи. Но не в прикладном же коде?!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А я раньше думал, что платят за работу.
VD>>А если серьезнь, то есть менее кривые средства. Те же текстуаьные макросы можно заменить немерлоподобными.
E>Макросы в топку.
С++ без макросов? Гы-гы.
E>Мне препроцессор в C++ нужен для устранения различий между платформами и поддержкой разных режимов компиляции.
А кто о препроцессоре то говорит?
Похоже ты просто не очень представляешь себе что значит "полноценные макросы".
E> Ну еще за макросами удобно прятать вещи типа assert или trace, которые из release версии вырезаются напрочь.
Ну, вот в Немерел их тоже прячут за макросами. Только не текстуальными, а полноценными, АСТ-шными. И результат получается намного более качественным.
E>Использование C-ных макросов для более серьезных вещей, по моему опыту, является следствием непродуманного дизайна. Когда на поиск более подходящей реализации не хватило времени, подходящих инструментов или хорошей идеи.
Дык каково средство, таков и результат. Но, как говорится, за неимением молодой горничной имеем старого дворника.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
