Здравствуйте, VladD2, Вы писали:
VD>он генерирует разный код для разных типов полей. Где хотя бы это в твоем решении? VD>[...] VD>Я наверно очень отстал от прогресса в С++. Покажи мне как это приводит к генерации разного кода для int-а, и других объектов.
Разный код разгуливается перегрузкой hash_value.
VD>Если что-то реализовано еще где-то, то надо было это привести. А то я тебе тоже могу библиотечный макрос привести и сказать, что у меня тут все очень кратко.
Да какая разница если библиотека даёт всё необходимое для решения задачи. Причём библиотека не сферическая, а реальная, уже готовая. И код примера — также реальный, с демо в online компиляторе — в отличии от D и Nemerle вариантов.
VD>Интересные же возможности языка, а не библиотека которую уже кто-то написал.
Почему? Это демо того, какую библиотеку можно написать на языке.
У тебя в задачи не было условия не-использования библиотек — так что не надо дописывать новые условия. А то без библиотек пришлось бы и класс строки писать
EP>>>>И внезапно, полный код выглядит на порядок чище чем в D и Nemerle
VD>>>Это потому что ты знаешь ровно один язык. EP>>Твоя телепатия не работает. VD>Тут не нужно телепатии. Танцы с бубном ты называешь "порядок чище", а прямое создание нужного кода — чем-то грязным, очевидно.
Да ты сам посмотри на код — это готовое решение, с онлайн-demo-run, причём более чистое.
И ты при этом называешь его "говнокодом", приводя только какие-то уродливые обрезки с мясокомбината
VD>Думаю, что если тебе дать пару пояснений, то и ты поймешь, что он очень прост.
Я и так понимаю что он делает. Но генерировать код — не проще и не элегантней чем просто взять готовый fold, который пробежится по всем полям
EP>>Практически все преимущества range-only решения, доступны для решения итераторы+обвёртки. VD>Ну, да. С помощью адаптеров из неудобных, но гибких итераторов можно сделать удобные ренжи или их аналоги. Бесспорно. VD>Возможно для Ди так и нужно было бы сделать. Ну, так это никогда не поздно сделать. Если конечно, обертка не будет давать оверхэд.
В некоторых редких случаях, такая обвёртка даст небольшой оверхед. Но преимущества range-only исчезающе малы.
VD>Функция тоже не плохая абстракция, в конце концов.
Не плохая, согласен
VD>Все что я тебе пытался сказать, что ты прицепился к мелочи, которая, к тому же, легко исправляется.
Это не мелочь.
VD>А вот обсуждать реальные преимущества и недостатки ты уже не хочешь. Все у тебя "незначительно" и "не важно".
Я знаю какие у него есть преимущества, и обсуждать мне их не интересно. Что тут обсуждать? Ну есть и есть
Здравствуйте, VladD2, Вы писали:
EP>>Не хватает встроенной в стандарт compile-time reflection — тогда от макроса можно было бы уйти. VD>Еще не хватает: VD>1. Прямых средств генерации кода, а не с помощью финтов ушами, множественного наследования на ровном месте и прочей фигни.
Это не критично.
VD>2. Возможности бинарной компиляции метакода, чтобы мета-решения не отличались по скорости от тех что встроены в компилятор. Этого, кстати, и в Ди нет, вроде бы.
Что ты имеешь ввиду? В D можно генерировать строку кода, которая будет компилироваться в нужном месте.
VD>3. Возможности внятного и удобного расширения и/или реинтерпретации синтаксиса, чтобы мета-решениям можно было придать логичный и удобный вид.
Согласен, не хватает. Но требуется редко.
VD>Добавление метода может быть нужно просто для того, чтобы переопределить виртуальный метод. Не все проблемы, знаете ли, решаются в компайлтайме. Есть еще динамический полиморфизм.
Читай исходную задачу, которую сам и поставил. Где там переопределение виртуального метода?
Здравствуйте, VladD2, Вы писали:
EP>>Если кто-то постоянно тем и занимается что итетрирует структуры данных, и ему не хватает текущих возможностей — то пусть отсылает proposal в reflection study group #7, его обязательно рассмотрят. VD>Лет 10 как отправили. Нам сказали, что RTTI должно быть достаточно для любых задач .
Какой Proposal?
Почему RTTI — вы предлагали runtime reflection?
Здравствуйте, VladD2, Вы писали:
EP>>Более того — у меня в одном из проектов есть большая схема, так она вообще в xml хранится, и код из неё нормально генерируется, и не программисты могут с ней работать + всякие xml утилиты, и как-то не комплексуем по поводу "ай-ай-ай, нет reflection, надо менять язык!". VD>Вот это характерно! Ты программируешь на ХМЛ-е, а не на С++.
Сейчас вообще обхохочешься: код из схемы генерируется Python'ом
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Смотри внимательней, там под cut'ом.
Дык, под катом тоже не все. Там два инклюда. Я же не могу сказать, сколько мегатонн кода нужно загрузить из них, чтобы получить все что нужно. Когда-то давно я пытался разобраться с бустовской реализацией и малость прифигел.
VD>>В хороший язык тащат только базовые вещи вроде полноценной поддержки метапрограммирования и средств расширения синтаксиса.
EP>Хороший для чего?
Для программирования. Особенно для решения сложных задач малым числом людей.
EP>Да я вижу — и тихо ненавидишь всех кто его не расширяет/не использует. Нет уж, спасибо.
Да пойми ты, нет тут никакой ненависти. Мне скорее вас жалко. Убедить я вас все равно не могу. Но хоть пожалеть тех кто с костылями то ходит можно?
VD>>А библиотеки — без проблем. Тот же STL написал рядовой пользователь С++ работавший в HP.
EP>Тут как раз уж и не рядовой. Он эти идеи вынашивал много лет, и до этого делал реализации на разных языках (Scheme, Ada, etc)
Ту главное, что он не был автором языка и не работал в фирме где велась его разработка. Он просто написал библиотеку для чужого языка. До него STL не было. И писать на С++ было еще неудобнее.
Сейчас же эти концепции известны любому школьнику. Так что в чем проблема их реализовать в библиотеке? Можно даже тупо списать.
EP>Да уж — вот это взлёт.
А что не так? Живет 10 лет. Помирать не собирается. Главная претензия того же FR — слишком бурно развивается.
EP>Там где не хватит скорости Spirit'а или подобного — я спокойно могу взять внешний генератор кода
Spirit — это детство полное. А генераторов динамически расширяемых парсеров пока в природе очень мало. Можно сказать — нет. Мы же не просто очердной Як лепим. У нас задача фикс — сделать фреймворк который позволит создавать языки (любые, от ДСЛ-я, до языка общего назначения) настолько просто, что люди будут тупо решать задачи в терминах предметной области делая на нашем средстве все тулы (от компилятора, до IDE).
EP>Если приспичит, внешний генератор даже может подключатся к expression tree из кода — прям брать неопределённый символ с закодированной грамматикой из obj, и генерировать нужный код — но это только если делать нечего.
У нас AST автоматом создается. А для пользователя его вообще не видно. В грамматике можно просто методы объявлять которые видят правила как объекты с полями в виде подправил. Даже имена полей автоматом выводятся.
Но парсинг — это только пол дела (да даже не пол, а четверть). Еще нужен связывание символов, описание областей видимости, импорты разные, внешние метаданные, вывод типов, кодогенерация... Короче то чего как раз не хватало в С++.
Но речь то не о том. Речь о том, что метакод он и есть главная абстракция. Ты и сам ХМЛ используешь, так как проще сгенерировать код по нему, чем пытаться выписать его на шаблонах.
EP>Что значит живущие любое время? А если там ресурс?
В плюсах они рейдонли. И это не с проста. Ведь чтобы ничего не долбануло замыкание (созданное лямбдой) должна жить столько сколько ее используют. А в С++ у нас ручное управление памятью. Просто создать замыкание и забыть про него нельзя. Хорошо если это просто алгоритм и его можно заинлайнить. А если замыкание нужно где-то хранить, то это пипец как сложно в условиях отсутствия автоматического управления памятью.
EP>http://files.rsdn.ru/64603/nemerle2.jpg[/img]
Жалкая подделка. Правильный слон должен быть розовым!
VD>>Ты просто не умеешь их готовить. Точнее ты настолько уткнулся в детали реализации, что не можешь оторваться от них и посмотреть на то что они дают. Вот к примеру, что можно сделать на прототипе ренджей (энумераблах шарпа).
EP>Да не надо сравнивать "энумераблы шарпа" с D-Range — они им и в подмётки не годятся EP>"энумерабл" это single pass — а в D далеко не одна категория Range, также как в STL
Ты пример то посмотрел? Знаток подметок, блин. Я тебе говорю, что энумерабла достаточно. Так что уж рэнджи точно прокатят. Главную фичу они повторяют — предоставляют абстракцию линивого списка. Остальное дают правильный набор функций и переупорядочение и откладывание вычислений которое с ними происходит.
EP>Ну вроде бы всё ясно. "D хорош, но у него серьёзные проблемы — нужен Nemerle"
Ди хорошо как замена С++, на что он и был рассчитан. А в области МП он с немерлом тягаться не может. Хотя в последнее время он явно подтянулся. Они ведь на Немерл тоже смотрели.
EP>А вообще — если ты пытался разрекламировать Nemerle — то получилось всё как раз наоборот.
Я с такими как ты уже 10 лет общаюсь. Я знаю какие вы упертые. Так что я не надеюсь, что кто-то из вас меня послушает. Это религия. Ее аргументами не пробьешь.
Да и немерл не мой. Я, просто не мирюсь с неудобствами и проблемами, а устраняю их чтобы самому было чем пользоваться. Ну, и это чертовски интересно! Куда интереснее чем мечтать о светлом будущем в котором у С++ появятся средства интроспекции и т.п.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Причём в C++14 добавилось несколько способов — transparent operator functors и само-собой п.лямбды.
Вот тоже самое, помню, говорили в 2002-ом про концепты. Хорошая идея была, эти концепты...
В прочем, шутка про то что цифра (в номере стандарта) является шестнадцатеричной не отменяется! Так что можно надеяться, что в 0x14 (т.е. в 2020-ом) году чудо случится и долгожданное чудо придет!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
EP>>Там где не хватит скорости Spirit'а или подобного — я спокойно могу взять внешний генератор кода
VD>Spirit — это детство полное. А генераторов динамически расширяемых парсеров пока в природе очень мало. Можно сказать — нет. Мы же не просто очердной Як лепим. У нас задача фикс — сделать фреймворк который позволит создавать языки (любые, от ДСЛ-я, до языка общего назначения) настолько просто, что люди будут тупо решать задачи в терминах предметной области делая на нашем средстве все тулы (от компилятора, до IDE).
Spirit решает совершенно конкретную задачу — рантайм-парсинг. И решает ее на 5. У него нет задачи "сделать фреймворк который позволит создавать языки".
Здравствуйте, DarkEld3r, Вы писали:
DE>И тебя не смущает, что LLVM на С++ написана? Как же можно на "говнокод на говноязыке" полагаться? Нее, надо срочно переписывать на D, а до этого ни за какие проекты браться ни в коем случае нельзя.
Меня смущает. Это главный его недостаток. Нужны обертки для использования не из С++. Если бы у него был сишный АПИ было бы в сто раз лучше. Но это не совсем о "написан на". Это о том, что имеет интерфейс С++.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
EP>>Смотри внимательней, там под cut'ом. VD>Дык, под катом тоже не все. Там два инклюда. Я же не могу сказать, сколько мегатонн кода нужно загрузить из них, чтобы получить все что нужно. Когда-то давно я пытался разобраться с бустовской реализацией и малость прифигел.
В том то и фишка, что std::bind сам строит expression tree.
VD>>>В хороший язык тащат только базовые вещи вроде полноценной поддержки метапрограммирования и средств расширения синтаксиса. EP>>Хороший для чего? VD>Для программирования. Особенно для решения сложных задач малым числом людей.
За всё хорошее и против всего плохого! Ты конкретней говори.
EP>>Да я вижу — и тихо ненавидишь всех кто его не расширяет/не использует. Нет уж, спасибо. VD>Да пойми ты, нет тут никакой ненависти. Мне скорее вас жалко. Убедить я вас все равно не могу. Но хоть пожалеть тех кто с костылями то ходит можно?
В чём убедить? В том что в не-мейнстримовых языках есть какие-то особенные и полезные, а порой экспериментальные фичи? Да тут вроде никто и не спорит
EP>>Там где не хватит скорости Spirit'а или подобного — я спокойно могу взять внешний генератор кода VD>Spirit — это детство полное. А генераторов динамически расширяемых парсеров пока в природе очень мало. Можно сказать — нет. Мы же не просто очердной Як лепим. У нас задача фикс — сделать фреймворк который позволит создавать языки (любые, от ДСЛ-я, до языка общего назначения) настолько просто, что люди будут тупо решать задачи в терминах предметной области делая на нашем средстве все тулы (от компилятора, до IDE).
Ну, удачи
EP>>Что значит живущие любое время? А если там ресурс? VD>В плюсах они рейдонли. И это не с проста.
Это дефолт — там при необходимости легко добавить "mutable".
VD>Ведь чтобы ничего не долбануло замыкание (созданное лямбдой) должна жить столько сколько ее используют. А в С++ у нас ручное управление памятью. Просто создать замыкание и забыть про него нельзя. Хорошо если это просто алгоритм и его можно заинлайнить. А если замыкание нужно где-то хранить, то это пипец как сложно в условиях отсутствия автоматического управления памятью.
Да нет ничего сложного. Ты лучше на выделенный вопрос ответь. А то вот Ikemefula мне тоже лапшу на уши вешал что лямбду в C# можно передавать как угодно, и куда угодно
EP>>http://files.rsdn.ru/64603/nemerle2.jpg
VD>Жалкая подделка. Правильный слон должен быть розовым!
Правильный слон должен быть незаметным:
VD>Ты пример то посмотрел? Знаток подметок, блин. Я тебе говорю, что энумерабла достаточно. Так что уж рэнджи точно прокатят. Главную фичу они повторяют — предоставляют абстракцию линивого списка. Остальное дают правильный набор функций и переупорядочение и откладывание вычислений которое с ними происходит.
И что из этого тебе недоступно в C++?
EP>>А вообще — если ты пытался разрекламировать Nemerle — то получилось всё как раз наоборот. VD>Я с такими как ты уже 10 лет общаюсь. Я знаю какие вы упертые. Так что я не надеюсь, что кто-то из вас меня послушает. Это религия. Ее аргументами не пробьешь.
Здравствуйте, VladD2, Вы писали:
VD>Вот тоже самое, помню, говорили в 2002-ом про концепты. Хорошая идея была, эти концепты...
Те концепции были тяжёлыми (одна спецификация страниц сто), эти намного легче.
Практически всё необходимое уже есть в самом языке, нужен только небольшой сахар, для удобства.
VD>В прочем, шутка про то что цифра (в номере стандарта) является шестнадцатеричной не отменяется! Так что можно надеяться, что в 0x14 (т.е. в 2020-ом) году чудо случится и долгожданное чудо придет!
По идее уже в следующем году. Текущий proposal вроде всех устраивает (ну кроме тех кто мечтал об concept map).
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>По идее уже в следующем году. Текущий proposal вроде всех устраивает (ну кроме тех кто мечтал об concept map).
Здравствуйте, VladD2, Вы писали:
VD>В С++ с его моделью памяти нельзя сделать поддержку точного GC, так что спека тут не поможет. А зачем нужно медленное и кривое решение?
Справедливости ради, в D с точным GC тоже пока не густо. По умолчанию используется частично консервативный. Есть реализация "почти точного" (используется в VisualD, например), но и там осталась пара мест (вроде замыканий), где осталась консервативность. Т.е. теоретически точный GC сделать можно, но пока его нет. И те, кто в 64 бита компилит, говорят что и не нужно, нынешнего хватает. Другая проблема — скорость нынешнего GC, она печальная.
Здравствуйте, VladD2, Вы писали:
VD>Меня смущает. Это главный его недостаток. Нужны обертки для использования не из С++. Если бы у него был сишный АПИ было бы в сто раз лучше. Но это не совсем о "написан на". Это о том, что имеет интерфейс С++.
Вроде, есть? http://llvm.org/docs/doxygen/html/group__LLVMC.html
Или сишный апи неполный/недостаточно быстро обновляется?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, VladD2, Вы писали:
EP>>>Более того — у меня в одном из проектов есть большая схема, так она вообще в xml хранится, и код из неё нормально генерируется, и не программисты могут с ней работать + всякие xml утилиты, и как-то не комплексуем по поводу "ай-ай-ай, нет reflection, надо менять язык!". VD>>Вот это характерно! Ты программируешь на ХМЛ-е, а не на С++.
EP>Сейчас вообще обхохочешься: код из схемы генерируется Python'ом
А у меня перлом и седом и xslt из нескольких xml-ей, которыми управляет вообще другая команда
И процесс генерации записан в мейкфайле
Сейчас нам опять расскажут, что мы знаем только один язык
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Всё то — в C++ вот такой массив int x[11] — тоже range.
Хы, ну да, забавно. ))) Но всё же массивы D это скорее аналог std.vector, а не массивов C++. Хотя последнее в D тоже по сути есть, как свойство ptr массива. )))
_>>Вот если бы у range можно было вызывать функции массива (хотя в данном конкретном примере это и не пригодилось)... EP>Какие?
Ну например размер узнать или поменять. Или получить прямой указатель на данные...
EP>Только массивы вообще не интересны. std::partition_point работает даже с Forward итераторами. Попробуй сделать интерфейс, и хотя бы набросай реализацию (мелкие баги не имеют значения).
Для не массивов уже диапазоны надо использовать... А я как раз старался без них обойтись. ))) Да, но вообще для partition_point по идее и обычного InputRange будет достаточно. Собственно тут уже приводили подобный код с диапазоном. Просто возвращаем кортеж из двух диапазонов...
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Не хватает, но это не так критично как тут пытаются представить "omg нет reflection! все на D, Nemerle и т.п."
Нуу естественно, что одной интроспекции недостаточно для перехода с C++ на D, но по сумме удобных фич D всё же настолько лучше, что это того стоит. И кстати со скоростью там говорят всё отлично, если взять gdc (я то только их родной тестировал. т.к. gdc кривоват под виндой).
Но это если мы говорим именно про сам язык и может компилятор/стандартную библиотеку. Если же брать остальную инфраструктуру, т.е. сторонние библиотеки, инструменты (IDE и т.п.), то как бы
получается что в итоге разработка на D может даже дороже обойтись.
В общем никакого однозначного решения "переходит или нет" на мой взгляд сейчас не существует. И там и там свои плюсы и минусы, причём очень разные. Мы тут пока просто пробуем на одном можно сказать стажёрском проекте. Правда при этом похоже больше обучается не стажёр, а как раз главный разработчик.
EP>А какие накладные расходы он по-твоему добавляет?
Ну как минимум ненужные строки в исполняемый файл. Правда я смотрю в последнее время компиляторы (во всяком случае gcc) умнее стали и запихивают это дело только по надобности. Но раньше помнится всё подряд валили. Что кстати весьма неприятно, если в коде имеются какие-то сильно секретные нюансы. Вообще на мой взгляд с rtti единственная проблема в том, что оно по умолчанию включено, а выключается опцией. Если бы наоборот было, то никаких проблем.
EP>Это всё понятно, и действительно круто. Но сейчас — отчасти решается макросами, либо с небольшим дублированием в виде описания схемы в одном из форматов(Boost.Fusion, или например Boost.Serialization). EP>Более того — у меня в одном из проектов есть большая схема, так она вообще в xml хранится, и код из неё нормально генерируется, и не программисты могут с ней работать + всякие xml утилиты, и как-то не комплексуем по поводу "ай-ай-ай, нет reflection, надо менять язык!".
Вообще если бы C++11 не вышел, то мне кажется что D очень резко пошёл бы вперёд. Т.к. C++03 был уж очень отсталым и набор фич в D просто потрясал. C++11 можно сказать серьёзно подпортил жизнь D, т.к. смысл переходить заметно уменьшился. Хотя всё равно ещё есть на мой взгляд. Если в C++14 взяли бы ещё несколько модных вещей из D, то может уже вообще вопрос не стоял бы. Но насколько я знаю в C++14 ничего принципиального не ожидается, скорее так, косметика...
EP>В C++11 можно (гугли "Using strings in C++ template metaprograms", + должно уже быть в библиотеках)
Это ты про жуть типа задания отдельными буквами или про что? )
, а потом и Nitra. В Nitra так и происходит. Берем строку... из файла на диске... читаем из нее грамматику и генерируем на выхде динамически расширяемый эффективный парсер.
Интересно. )
А мы тут на D используем что-то из подобной же области, правда написанное не нами. Там значит при сборке исполняемого файла читаются текстовые файлы с диска, написанные на спец. языке шаблонизатора с определённой грамматикой. Кстати туда входят в том числе и вставки кусков кода на D. Это всё собирается в бинарник, который запускается и с безумной скоростью выдаёт по запросам генерируемые странички.
Здравствуйте, DarkEld3r, Вы писали:
DE>Здравствуйте, VladD2, Вы писали:
VD>>Меня смущает. Это главный его недостаток. Нужны обертки для использования не из С++. Если бы у него был сишный АПИ было бы в сто раз лучше. Но это не совсем о "написан на". Это о том, что имеет интерфейс С++. DE>Вроде, есть?
Есть. Но обертки есть обертки. Нет никакой гарантии, что через них доступны все функции и что нет никаких проблем.
По факту зачастую совместимость обеспечивается за счет генерации кода на их языке. То есть язык становится средством совместимости.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, D. Mon, Вы писали:
DM>Справедливости ради, в D с точным GC тоже пока не густо. По умолчанию используется частично консервативный. Есть реализация "почти точного" (используется в VisualD, например), но и там осталась пара мест (вроде замыканий), где осталась консервативность. Т.е. теоретически точный GC сделать можно, но пока его нет. И те, кто в 64 бита компилит, говорят что и не нужно, нынешнего хватает.
Дык это плохо. В С++ же даже возможности такой нет. Память на классы не делится. 30 лет назад об этом не думали.
DM>Другая проблема — скорость нынешнего GC, она печальная.
Естественно. Хорошую скорость может обеспечить только точный ЖЦ с нехилой поддержкой компилятора. Задача не из легкий.
Но это опять же следствие малости комьюнити и не заинтересованности мега-корпораций. Иначе давно написали бы. Для Явы ЖЦ выше крыши. У дотнета с ним тоже все ОК.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alex_public, Вы писали:
EP>>Всё то — в C++ вот такой массив int x[11] — тоже range. _>Хы, ну да, забавно. ))) Но всё же массивы D это скорее аналог std.vector, а не массивов C++. Хотя последнее в D тоже по сути есть, как свойство ptr массива. )))
std::vector — тоже range.
_>>>Вот если бы у range можно было вызывать функции массива (хотя в данном конкретном примере это и не пригодилось)... EP>>Какие? _>Ну например размер узнать или поменять. Или получить прямой указатель на данные...
А что произойдёт, если допустим slice'у от массива попытаться увеличить размер?
EP>>Только массивы вообще не интересны. std::partition_point работает даже с Forward итераторами. Попробуй сделать интерфейс, и хотя бы набросай реализацию (мелкие баги не имеют значения). _>Для не массивов уже диапазоны надо использовать... А я как раз старался без них обойтись. ))) Да, но вообще для partition_point по идее и обычного InputRange будет достаточно.
partition_point делает бинарный поиск — поэтому ему нужен ForwardRange как минимум.
_>Собственно тут уже приводили подобный код с диапазоном. Просто возвращаем кортеж из двух диапазонов...
Даже в том коде были разнообразные проблемы, как с гибкостью, так и с производительностью.
А в случае partition_point ещё и реализация будет неудобная. AFAIK в D есть бинарный поиск только для RandomAccess, в то время как в STL он спокойно работает и для ForwardIterator.
.
