«современное проектирование на C++»

Как можно проектировать на C++??

1) Мне чисельники до лампочки. Мне интересны богатые структуры управления - от scope до alias this, миксины, строковые миксины, шаблоны приличные и тому подобное. И здесь результаты очень даже хороши.

2) Позиция была и есть «сначала реализуем язык, оптимизации - если попадаются по дороге».

3) Проверки в релизной версии отключать - по-моему нормально. Тем более, что проверок в D получается много, если нормально писать (assert, контракты).

А уж что до скриптланга - постыдились бы. На шутауте D нет, но можете сами посравнивать - уж в первой пятёрке он будет на основной массе тестов. Скриптовые «несколько» подальше и несколько мнее надёжны, с их динамическими типизациями.

http://gleb-kulikov.livejournal.com/14112.html#comments

я же спрашивал: че это за таинственные «высокоуровневые объектные модели»?!

«Высокоуровневые»? Не знаю, я об этом не говорил. Пример другой объектной модели я привет - ссылочные типы а-ля Ява.

тебе все равно где-то придется хранить (или хотя бы передавать в функцию) тайптег, или vtbl ptr, или аналог для различения этих не важно классических объектов или объектов АлгТД

Как-то придется, конечно. Но если не придется морочиться о совместимости с Си++, это само по себе большое облегчение.

афайк в хаскеле разница с с++ только в том, что vtbl ptr лежит не в объекте, а передается функции вместе с указателем на объект

Ну то есть в объекте она просто не лежит %)

мой прошлый ответ не отменяет точного ответа на твои вопросы

Вопросы были риторические - для примера, какой can of worms придется распечатать. Но если возьмешься отвечать - заодно скажи, что делать с виртуальным и обычным множественным наследованием.

лисп-подобные макросы в D

а вообще, вот есть такой пример из книжки TDPL (Александреску, «Язык программирования D»): (глава 5.9.2, реализация reduce):

V  reduce(alias  fun,  V,  R)(V  x,  R  range)
if  (is(typeof(x  =  fun(x,  range.front)))
&&  is(typeof(range.empty)  ==  bool)
&&  is(typeof(range.popFront())))
{
for  (;  !range.empty;  range.popFront())  { 
x  =  fun(x,  range.front);
}
return  x;
}

построчно:

шаблон с 3 параметрами, первый: функциональный литерал (лямбда) параметр-псевдоним (alias fun), второй: тип начального значения, третий: тип range; 3 параметра шаблона, 2 параметра функции (нач. значение, диапазон).

сигнатура функции — с ограничением концепта, концепт из трёх строк, в каждой — проверка на то, что компилируется код x = fun(x, range.front); range.empty; range.popFront()

то есть, что у range есть три метода (хотя они могут быть реализованы и сахаром, как свойство или через UFCS), и что код x = fun (x,y), где y = range.front — компилируется.

от такого кода остаётся стойкое ощущение, что он написан не человеком, а каким-то макросом.

например, таким:

mixin(macros("macro_range", "reduce",
      q"/ fun : (x:V,y:V) -> V , V : x, R : range /",
  
      q"__macro_range__


      q"`  

      for  (;   q", !range.empty ,";  q", range.popFront() ,")  { 
 q", x  =  fun(x,  range.front) ,";
}
return  x;

      `"

      __macro_range__"
)); 

код должен быть сгенерирован автоматически в CTFE функции macros, которая раскрывает строку на «языке описания макросов» и возвращает строку на D, которая затем компилируется через string mixin.

эта macros раскрывает макросы:

1. парсит строку на «языке описания макросов» в AST; см. четвёртый параметр в macros

2. раскрывает макросы в AST (quasiquote q"` , unquote q", )

3. распечатывает раскрытое AST дерево

4. генерирует сигнатуру с ограничением концепта (например, выводит типы — «язык описания макросов» с типизированными макросами, см. третий параметр macros

в ограничения концепта добавляются строки вида «скомпилируется ли раскрытие unqoute»:

is(typeof(FOO)==bool)

quasiquote( ....
     unquote(FOO)
  ....)

может, придумать что-то вроде интерполяции строк в синтаксисе макросов.

поинт в том, что если через CTFE будет доступен весь компилятор, например парсер исходника в AST — то такое несложно будет сделать. сейчас в принципе можно взять pegged, составить D грамматику на PEG (там где-то даже есть готовая), разобрать строку в AST в CTFE функции-парсере.

если D будет переписан на самом D, и будет какой-то интерфейс типа std.compiler, такую штуку можно будет довольно просто сделать.

т.е., сделать лисп-подобные, но даже лучше макросы: типизированные, с выводом типов по необходимости + компилятор таких макросов в обычный D.

дискасс.

всё, что вы хотели спросить про биндинги к Си статья, всего 5 частей

я, вообще-то, хотел спросить про биндинги к с++

extern(C++) недопилен , и вот почему

хотя мне кажется, ещё можно повозиться, если вручную херачить манглинг и нужные calling convention.

примерно так:

1. собрать C++ код, посмотреть асмовый исходник, пример как вызывается метод в этом коде

2. в D писать асм функцию-обёртку через naked : реализация обёртки на асме должна вызывать через нужные calling convention, подсмотренные в 1 пункте с нужными параметрами

3. naked обёртки на асме генерировать функцией в CTFE, и подставлять через string mixin.

4. с учётом C++ манглинга, конечно же.

5. вот время жизни С++ кода — тут сложнее.

думается, что если взять LLVM компиляторы, например, clang и ldc, то можно значительно облегчить первый пункт.

вплоть до автоматической какой-то тулзы: грубо говоря, clang похаканный имеет плагин с ещё одним проходом, где по вызываемым методам и определению класса генерирует какой-то IDL для класса, и какую-то базу по тому, как вызывается такой метод.

потом ldc конпеляет тоже в LLVM биткод, как и clang.

потом тулза собирает это всё вместе, с учётом IDL и этой базы.

есть ощущение, что этот «сборщик» можно написать на самом D, CTFE макросами.

а в zlib много такого кода по простой причине - поддержка различных убогих платформ

это не отменяет того, что убогий код убог (там в нём даже багу нашли), и череват тараканами из-за всяких частных случаев.

нафига исходный код постоянно дёргает realloc?

понятнее можно написать, чтобы тараканы не возникали, а читалось легче.

да, и твой код на С++ тоже убог по сравнению с ranges.

смотри презентацию Волтера про компонентное программирование через ranges

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

в этом топике, в заголовке топика есть ссылка на сравнение различных объектных моделей: SOM, COM, GObject, ObjC, и т.п.

я щитаю, что тема довольно таки раскрыта.

я там немного поотжигал, на 4 странице.

вкратце, считаю что подобную SOM среду можно воспринимать как метаобъектный протокол, как объектную метамодель.

а уже её «специфицировать» в какую-то конкретную объектную модель, будь то C++ VTable, GObject, или там CLOS.

для этого нужно метапрограммирование во все поля и жестокая CTFE магия, конечно же.

и если они не пошли, почему ты предлагаешь новообращенному-писателю-на-д пойти этим путем? поперек батьки в пекло полезть?

потому что никто не думал с этой стороны, объектной модели (метамодели). все думали с точки зрения языка.

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

как именно её составить не суть важно: то ли это SOM «как реализация», то ли это SOM «как метаобъектный протокол», то ли это «общий универсальный ABI и calling convention» на основе LLVM биткода (между clang и ldc).

важно понять, что именно такая метамодель должна делать, её API грубо говоря.

направление мысли вроде бы и верное, но скажем как реализовывать указатель на метод класса? тут емнип могут быть бинарно разные варианты

грубо говоря, мы можем написать код на С++, откомпилять его в ассемблер, посмотреть реализацию и наполнить по ней базу с шаблоном для такого «универсального ABI»

а в раскрытии шаблона — поиск шаблона в базе + подстановка параметров.

ooc=?

язык ooc же. тут в соседнем топике некто geekless распинался про «гомоиконный Си», а это вот оно самое и есть.

HN примеры

компилятор ooc на ooc : раскрутился через Java: первая версия была Java => C, потом переписан с Java на ooc и пересобран сам собой

грамматика ooc на PEG фронтенд

из плюшек: кроме классов (бинарно совместимых с Си с т.з. ABI) ещё есть cover , которыми легко пишутся всякие биндинги и обёртки.

компилятор компилирует через Си, рантайм простой и понятный.

но пример в PDF мягко говоря притянут, от удаления комментариев и до изменения алгоритма, что можно сделать и на С

ну-ка, расскажи, как ты легко сделаешь scope(failure) и вложенные scope в сишечке?

Наоборот - туда бы кастомную обработку AST, чтобы можно было добавлять пользовательские синтаксические конструкции - хотя бы в пределах rewriting'а

теоретически, уже сейчас можно брать в руки «компилятор D на D» (по ссылке в топике приведено аж 4 штуки), и его фронтенд, или pegged + D PEG грамматику, херачить в string mixin'ы, делать всё это в CTFE, раскрывать какие-то свои макросы.

упорных достаточно писателей не хватает, однако.

хотя да, если бы был интерфейс к AST с точки зрения компилятора, чтобы эти string mixins легче дёргать, а в идеале, и не string mixin-ы, а типизированные AST макросы, было бы гораздо проще и нужнее.

как будут взаимодействовать системы управления памятью?)

тут засада, потому что время жизни C++ кода и D кода будет сильно разная.

На Венде - ХЗ, но, думаю, и там прще будет поддеривать какой-нибудь COM.

там COM и есть «из коробки».

вообще, надо прикрутить к D «какой-нибудь SOM» :)))

я же спрашивал: че это за таинственные «высокоуровневые объектные модели»?!

моя версия: это та самая объектная «метамодель», с неявными спеками, разными для каждого языка (а нестабильный ABI например — вплоть до реализации этого языка).

и если бы её составить явно для языка С++, например, для языка D, для языка СLOS, для модели SOM, например, и наложить их друг на друга, чтобы определить общие места и отличия в реализации — то можно и более чётко обозначить.

а потом из этой мета генерировать конкретную объектную модель конкретного языка: VTable + Fragile Base Class Problem в случае C++, что-то другое в случае Oberon, что-то другое в случае D, SOM и т.п.

короче, эти МЕЛОЧИ вовсе не делают из Новых Объектов нечто инопланетное — это обычные житейские дрязги вроде управления временем жизни; их надо просто упорядочить (да, тут нужны кое-какие системы эффектов)

+666

ну-ка, расскажи, как ты легко сделаешь scope(failure) и вложенные scope в сишечке?

сначала ты мне расскажи - где это в коде zlib можно найти функцию, которая полностью вычитывает файл в память

Но согласитесь, что синтаксис Модулы или Оберона гораздо приятнее для чтения, чем синтаксис С или Паскаля.

да. но соглашусь и с Керниганом, «почему паскаль не самый мой любимый». на примере Go и Oberon-a (на oberoncore почему-то люди кипятком писают от Go, дескать «оберон с сишным синтаксисом», а это не так — есть же goroutines, каналы,ad hoc интерфейсы то есть Go это совсем другой язык, а не просто синтаксис) — тут мне Go немного синтаксически приятнее.

код того же линкера в DevLinker выглядит убого. работа с BigNums в BlackBox CP убога. нет scope, нет исключений.

И опять же, не следует понимать буквально «взять модулу или оберон», можно взять их за основу при разработке нового языка, а лучше двух или трех ибо идея охватить одним языком программирования все сферы применения, ИМХО, неудачна.

на эту тему у Р. Богатырёва есть проект «Роса», языки M,R,S,T. Интересный проект, погуглите. правда, когда у них будет какой-нибудь релиз, чтобы пощупать --- непонятно.

концепт интересный.

ибо идея охватить одним языком программирования все сферы применения, ИМХО, неудачна.

тоже так думаю, но ИМХО, такую систему можно построить на основе LLVM, а из Оберон-системы (или блекбокса) оставить только загрузчик модулей, подключаемый сборщик мусора, подключаемый рантайм + много разных «языковых модулей» на разных языках, но в однотипном ABI (бинарном формате этих самых модулей)

кстати, на гитхабе есть компилятор какого-то языка krawl по типу Go на LLVM. вот первый кандидат на скрещение с обероном.

я же спрашивал: че это за таинственные «высокоуровневые объектные модели»?!

моя версия: это та самая объектная «метамодель»

Нет. Я считаю, что «надъязыковые „метамодели“ полностью зафейлились и интересны только с точки зрения легаси.

так зафейлилась реализация вроде маршаллинга, а с реализацией через метапрограммирование ИМХО вполне можно ещё побороться.

«Реализация объектной метамодели через метапрограммирование», okay.

А как по твоему создаётся первый компилятор на новой платформе?

То есть ты тоже не понимаешь принципиального различия ситуаций, когда компилятор для языка есть хотя бы для одной платформы, и когда его нет вообще?

Вопросы были риторические - для примера, какой can of worms придется распечатать.

ни разу не распечатать — эти черви *уже* разбежались

в той же жабке одни чуваки, когда реализовывали кэш в оперативе, написали его на с/с++ (т.к. жц на ~16ГБ кошмарно тормозит) и дергали его через jni — на хабре была статья, причем они побенчили и получили, что у них быстрее, чем альтернативные реализации

это я к тому, что у чуваков объекты, собираемы gc, и не собираемые, сосуществуют вместе — и чуваки че-то не жалуются

Но если возьмешься отвечать - заодно скажи, что делать с виртуальным и обычным множественным наследованием.

на большую часть я отвечать не буду, отмазавшись тем, что топик про Д

насчет виртуального и обычным множественного наследования:

1. оно очень полезно и не требует особых сложностей, когда используется в стиле mix-in (т.е. когда не требуется кастить к *множеству* баз)

2. где-то может быть лучше «множественное» делегирование (страуструп в d&e писал, что вначале вместо наследования было делегирование, но там обнаружились некие проблемы — надо их изучить, тем более alias this это случайно не делегирование ли? примеров на dlang мало и один явно плохой, и я забил на выяснение этого)

3. но в любом случае бинарные данные вида «класс с++ с множественным наследованием» надо хотя бы потенциально уметь понимать — пусть даже использование такой плюсовой библиотеки приведет к тому, что где-то придется делать копирование вместо передачи по ссылке, или не делать сборку мусора, или х.з. что подобное

Но если не придется морочиться о совместимости с Си++, это само по себе большое облегчение.

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

Ты ни черта не понимаешь. Читай про бутстрап и метаязыки. Нулевая реализация языка может быть тупым интерпретатором поверх какого либо притимивного метаязыка.

Нулевая реализация языка может быть тупым интерпретатором поверх какого либо притимивного метаязыка.

поверх динамически типизированного языка?

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

btw, я бы бутстраппил д совсем иным образом — писал бы на неком подмножестве д, которое простыми регулярными выражениями трансформировалось бы в с++

а где (ради любопытства) пишут про бутстрап?

да, и про метаязыки?

эти черви *уже* разбежались

Wut? Еще раз: проектируется новый язык, черви за его пределами никого не интересуют.

у чуваков объекты, собираемы gc, и не собираемые, сосуществуют вместе — и чуваки че-то не жалуются

Во-первых, зависит от интерфейса; во-вторых, вручную можно написать что угодно.

насчет виртуального и обычным множественного наследования:

1. оно очень полезно и не требует особых сложностей

Где еще есть виртуальное наследование, кроме как в Си++? Нигде? Вот именно.

в любом случае бинарные данные вида «класс с++ с множественным наследованием» надо хотя бы потенциально уметь понимать

Это было бы полезно, да. И правильно это делать какими-то внешними инструментами.

это устранение тупой, неинтересной и не-всем-необходимой работы по точному воспроизведению abi плюсового компилятора, но принципиальной сложности это не добавляет нисколько

Устранение не добавляет сложности? Кажется, ты не прочитал мессагу перед тем, как запостить ее.

Это было бы полезно, да. И правильно это делать какими-то внешними инструментами.

можно и внешними (и даже я об этом писал, применительно к д), но пойнт был в том, что поддержка языка для этого все равно требуется

это устранение тупой, неинтересной и не-всем-необходимой работы по точному воспроизведению abi плюсового компилятора, но принципиальной сложности это не добавляет нисколько

Устранение не добавляет сложности?

очевидно, «не добавляет сложности» не устранение, а необходимость

Во-первых, зависит от интерфейса;

не ясна мысль

во-вторых, вручную можно написать что угодно.

ну а нафейхоа вообще нужны языки программирования? в основном, чтобы чекать то, что написано ручками, и автоматически генерить то, что можно ручками написать, но лень

Где еще есть виртуальное наследование, кроме как в Си++? Нигде? Вот именно.

и?

Wut? Еще раз: проектируется новый язык, черви за его пределами никого не интересуют.

что значит «за пределами»? они как-бы везде

что ты предлагаешь? сделать объектную модель а-ля ява-где-все-собирается-жц? все равно потребуются weak references, fantom references и возможно вообще ручное уничтожение объектов

а еще я слышал про объекты, которые достижимы с точки зрения жц, но на самом деле мертвы (в контексте того, что их хотели собирать)

пойнт в том, что потребуются чуток разные объекты для неигрушечных изделий

D на ортогональность не претендует. Чисто практический язык, в котором куча не абсолютно необходимого сахара, TIMTOWDI тоже был явно декларирован.

кстати, как там в D с weak, soft, phantom references?

очевидно, «не добавляет сложности» не устранение, а необходимость

А, ну-ну. На этом можно и закончить.

D на ортогональность не претендует. Чисто практический язык, в котором куча не абсолютно необходимого сахара, TIMTOWDI тоже был явно декларирован.

ортогональность не противоречит сахару (тут мне было бы полезно подробнее написать)

TIMTOWDI не шибко конечно хорошо, но вполне терпимо, и вообще — тут д надо сравнивать не с абстрактным идеалом, а скажем с с++ по уровню TIMTOWDI

из мелочей мне, кстати, совсем не нравится, когда одно и то же ключевое слово употребляют для обозначения разных вещей; вот, случаем, alias this и alias в том примере, что чуть выше привел анонмус, обозначают ведь существенно разные вещи?

ну ты вообще кто — AI или человек? человеки (правда не все конечно) умеют по слегка испорченному хэшу соообщения восстанавливать само сообщение

Я восстановил сообщение, оно сводится к фразе «черное - это белое». Последи за разработкой реальных языков - может, отучишься говорить фразы «принципиальной сложности это не добавляет».

ну вот тебе например один классический хэш а-ля «черное - это белое» — «начало зимы это середина лета»

при наличии мозгов его можно восстановить до вполне непротиворечивой фразы, которая даже дает немного информации

То есть ты тоже не понимаешь принципиального различия ситуаций, когда компилятор для языка есть хотя бы для одной платформы, и когда его нет вообще?

Почитай в википузии статью «Раскрутка компилятора». У Ди есть компилятор для «платформы» С++. Не он первый, у визуалбейсика и 1С тоже компиляторы на плюсах.

кстати, как там в D с weak, soft, phantom references?

Например вот так: http://forum.dlang.org/thread/jjote0$1cql$1@digitalmars.com

В D это (как и многое другое) реализуемо в бибилиотеке.

Да, существенно разные. Но альтернатива - куча ключевых слов, которые и разработчику для идентификаторов пригодятся, либо мутный синтаксис.

В данном случае как раз всё прозрачно - alias this применяется только в классе, а в приведенном примерчике - в параметрах функции. Вон, вы с первого взгляда увидели, что это разные вещи, а кто один раз докментацию почитал - и подавно не спутает.

А TIMTOWDI где не надо легко ограничивается локальным style guide, зато позволяет выбрать то или иное средство в зависимости от ситуации. Вот, скажем, есть RAII как в плюсах, есть scope(exit) и есть finally - штуки функционально идентичные, но в конкретном случае одна может смотреться как родная, а другая - весьма странно. И если не индус пишет, то выбрать нужный вариант особого труда не составит.

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

Внезапно, SICP

А при чём тут это?

Что-то гнутое сообщество так и не смогло нормально перенести gcc на винду. По твоим словам получается что у них проблемы с головой?

Вообще-то уже давно перенесено. Причем используется во всю. Qt, например, с ним используется.

Вообще-то уже давно перенесено. Причем используется во всю.

Где скачать это нетормозящее чудо? Хочу пересобрать под винду самый новый mplayer и чтобы без секса с некомпилируемостью новых либ.

Где скачать это нетормозящее чудо? Хочу пересобрать под винду самый новый mplayer и чтобы без секса с некомпилируемостью новых либ.

В своих фантазиях. Слово «тормозит» к компиляторам не имеет никакого отношения и говорит о вашей ангожированности.

Некомпилируемость либ, опять же - дело либ.

А ошибки есть в любом компиляторе. Весь вопрос в скорости их выявления и устранения.

Так что смотрите в свой мозг. Проблема там.

Гражданин спрашивал, где читать про бутстрап. Вот в SICP и читать.

Почитай в википузии

Читаем:

используя какой-либо существующий для платформы M язык (например, C) программируется компилятор L0—С—M.

Чудес-то не бывает. Первоначальный сабсет все равно должен быть реализован на другом языке, для которого компилятор уже есть. А уж целиком реализован язык или нет это мелкие детали. А преимущества от self-hosting, прямо скажем, не гигантские. Особенно в случае D, который вообще неясно, полетит ли в том качестве, в котором его изначально проектировали. То есть предъява к языку за то, что компилер до сих не написан на нем самом, я воспринимаю как треп диванных экспертов. Тем паче, что многие эксперты тут тяжело больны религией «C++».

набирающего популярность языка D

И где эта «популярность»?

Откуда столько негативных комментов в треде? Они ведь не крадут, не убивают, просто пишут всякую лажу just for fun.

Мдээээээ… 8) Как всё-таки народ обожает подрать глотку во имя хз чего…

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

Если, конечно, не будет отыскана новая…