Компилятор языка D будет переписан с С++ на D

Не догадался ты.

как вам будет угодно, пускай это я не догадался

А теперь еще и солгал.

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

Я описал твое поведение. Если оно кажется тебе женским - это повод задуматься.

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

Замен С++ полно. Начиная от D, С#, Java, заканчивая скриптовыми языками.

да ты же наркоман

She wants D? О, да.

я ни разу не писал include ни на один бустовский хедер, документацию по нему читал

И опять же, я не об этом спрашивал.

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

Кросскомпиляцией. Я кэп!

Тольков Брайт таки к 5% относится. Учитывая, что умудрился в одно рыло сделать полноценный компилятор плюсов.

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

А http://dlang.ru/About падает с полным стектрейсом.

А все потому что Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.272

Неважно какой язык, главное чтобы человек был хороший.

Фишка не в самих фичах, а в том, как они друг на друга накладываются. Например, в D шаблоны, удобная перегрузка операторов и аж три способа сделать сущность итерируемой вкупе с GC и auto очень провоцируют клепать кучу ranges на все случаи жизни - от ленивых алгоритмов до того, что в перле называется tied массивами.

реквестирую ссылки на эти три способа

Тут всё хитрее. D по вызовам с сями совместим (и частично с плюсами). А вот чтобы понимать сишные .h он должен был бы нести в себе фактически полный препроцессор и компилдятор сей. Что сочли ненужным. Это «техническое» обоснование.

не обязательно «в себе», это вполне может быть отдельная тулза, сделанная, вдобавок, допустим на основе clang

вопрос стоит, скорее, в понимании и совместимости с объектной моделью с++ (и при этом совсем не нужно понимать синтаксис с++)

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

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

осталось совсем немного усилий — и соколиный глаз увидит, что четвертой стены нет они поймут, что это надо и другим тоже для _*постепенного*_ переписывания собственных проектов с с++ на д

Андрей Александреску (Andrei Alexandrescu), в ближайшее время будет начат проект по переписыванию компилятора языка D с С++ на D

велосипедисты отакуэ. Вообще есть же SDC, компилятор D на D. Оно правда, недопилено очень сильно.

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

ура-ура. тулчейн dmd-шный под винду, с линкером Optlink — тот ещё велосипед. Нуачо, нельзя было просто переписать линкер? Остальной сишный код вполне пристойный. Я вот довольно просто его на Haiku портировал, вполне очевидным способом.

На первом будет написано приложение, позволяющее генерировать корректные заголовки для С++ из модулей D.

что, неужто и интеграцию с С++ до ума доведут?

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

ура-ура. на самом деле, Волтер статьями на журнале доктора Доббса радует — вот хотя бы, про компонентную архитектуру на основе ranges. на этом вполне можно сделать компилятор. заодно и интерпретатор в CTFE можно более до ума довести.

не обязательно «в себе», это вполне может быть отдельная тулза, сделанная, вдобавок, допустим на основе clang

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

вопрос стоит, скорее, в понимании и совместимости с объектной моделью с++ (и при этом совсем не нужно понимать синтаксис с++)

там про это тоже частично есть. вообще тут сам С++ виноват с его нестабильным ABI. вот в C и в D ABI стабильное.

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

Java? C#? C++.NET? не, не слышал.

вообще эту проблему совместимости с С++ можно другими способами решать. Например, объектным брокером типа SOM (вполне классная компонентная архитектура, правда там в основе старьё типа CORBA, но задачи бинарной совместимости она вполне себе решает). Есть правда проблемы с производительностью (SOM примерно на 20% была медленнее объектной модели VTable в C++, по тестам) — но если за это по уму взяться, можно и оптимизации запилить.

потом, можно взять LLVM компиляторы: clang, ldc и придумать какой-то общий ABI и calling convention на основе LLVM биткода.

они поймут, что это надо и другим тоже для _*постепенного*_ переписывания собственных проектов с с++ на д

да, требуются киллер аппы. типа pegged, sdc, poseidon, что-то компонентное на основе ranges, VisualD и проч.

P.S. хидер sqlite (350к) переводится в D руками минут за 15. А толку - в родном виде в дишном коде вызовы sqlite смотрятся как дикарь в городе. Там даже если не делать ормы и прочие удобства надо как минимум прятать работу с памятью и добавление \0 в конец строковых данных.

даже ещё веселее. zlib переписали с C на D — исходник сократился на 2/3: за счёт scope, и прочего. Но кто блин будет занудно и кропотливо так всё переписывать?

кстати, UFCS фича для С биндингов помогает. это когда gtk_container_add (GTK_CONTAINER (window), button)) <=> window.gtk_container_add(button), например.

получаем сразу псевдоооп интерфейс.

Тупая трансляция сишных хидеров в D дает совершенно чужеродный код, вокруг которого всё равно нужна обёртка.

нафейхоа обёртки? вот для GTK например кроме GtkD есть более вменяемая обёртка, через UFCS. на гитхабе (в ньюсах анонс был).

даже ещё веселее. zlib переписали с C на D — исходник сократился на 2/3: за счёт scope, и прочего.

чушь, в коде zlib полно препроцессорной каши и кода для поддержки всяких досов, амиг и пр., ну и даже если закрыть глаза на это - где код на D? тот же gdc использует оригинальный zlib

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

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

С с легкостью могли бы заменить Модула, Оберон, например

ну оберон слишком чужеродный для человека, испорченного нарзаном braces language.

«технологическая изоляция», например. вот есть BlackBox Component Pascal, изящная штучка. с встроенным REPL в виде коммандеров, с парой компонент превращается в REPL через сокеты (оберон-система: сервер, команднострочная тулза — клиент, команднострочная тулза запихивается в make). ещё есть расширение к коммандерам, чтобы многострочные скрипты на обероне писать.

например, инструкцию по сборке или линковке в standalone exe.

но например, нафига они там свой линкер (DevLinker) навелосипедили? из обероновских модулей + сборщика модуля + стаба генерируется 32-битнй PE EXE. А умельцы и ELF32 прикрутили.

вместо этого всего, лучше бы LLVM прикрутили. чтобы компилятор генерил модули не только в .ocf формате для загрузки своим лоадером, а в LLVM-подобном биткоде (+ лоадер теоретически умел бы грузить модули обероновские, написанные не на обероне, например — нужен какой-то универсальный ABI для LLVM модулей, которые бы генерировались и другими LLVM компиляторами).

а вместо DevLinker или DevLinkerElf нужно переписать линковщик в бинарник через LLVM средства. тогда сразу из коробки получим и PE/ELF 64 bit, и MachO 32/64, и что угодно.

идеология оберон-систем по сравнению с сишечкой немного другая — нормальные компонентые системы с поддержкой ЖЦ против командной строки, отдельных процессов, отдельного тулчейна.

потом, что они с исключениями наворотили — только в модуле-3 есть нормальные исключения, ни в обероне ни в модуле-2 нет by design.

пример был в PDF-ке. взяли и переписали, бок о бок, слева сишный zlib, справа реализация на D на 2/3 короче.

пример был в PDF-ке

замечательно, допустим кроме этой PDF-ки этот код нигде не пригодился, но где же она?

слева сишный zlib, справа реализация на D на 2/3 короче.

прямо весь zlib? большая PDF-ка была видимо

прямо весь zlib?

Нет, конечно. Одна из функций.

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

ну в C++.NET например общий рантайм есть. два рантайма, один С++, другой .NET в одном бинарнике. Хотя теоретически им и не нужно так извращаться, достаточно одного CLR компилятора. в итоге имеем общую объектную модель, но отуплённую до уровня CLR.

вообще в чём проблема иметь два рантайма в одном бинарнике? просто чтобы эти 2 объектные модели были по настоящему интегрированы, надо повозиться.

а дальше намёк: «ну и вот в том же духе всю либу пилите».

вообще в чём проблема иметь два рантайма в одном бинарнике?

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

просто чтобы эти 2 объектные модели были по настоящему интегрированы, надо повозиться.

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

Нет, конечно. Одна из функций.

начинали с «zlib переписали с C на D — исходник сократился на 2/3», закончили тем, что переписали одну функцию и ее можно найти в каком-то PDF - окай

Кросскомпиляцией. Я кэп!

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

http://ecn.channel9.msdn.com/events/LangNEXT2012/AndreiLangNext.pdf

26 страница (23/53 справа внизу)

пример взят из zlib : функцию read из zlib переписали с С «буквально» на D, потом оказалось, что можно оптимизировать в 2-5 раз многобуквие.

ещё где-то на др. доббе ссылка на статью была, там более подробно разобрано.

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

C++ тут такой ССЗБ, да. теоретически, если бы взять какой-то SOM для обеспечения бинарно совместимого, стабильного ABI, и как-то здорово его облегчить (например, как в языке ooc), мог бы быть профит. правда, настоящих буйных мало.

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

Java? C#? C++.NET? не, не слышал.

чувак, ты ващще читать умеешь? слово «гигабаксы» видел, нет?

сан аж бедняжка (гы-гы) надорвался, вытягивая свою яву; майкрософт еще не надорвалась, но понятно, что делает язык не для общего блага, а для поддержания vendor lock-а на своей винде

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

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

26 страница (23/53 справа внизу)
потом оказалось, что можно оптимизировать в 2-5 раз многобуквие.

ОМГ, простое чтение файла в буфер (после «оптимизации») - 30 строк, да еще и с использованием всяких std.c.linux.linux.*, пусть перепишет сразу на С++:

try {
    ifstream f(path);
    vector<char> buf((istreambuf_iterator<char>(f)), istreambuf_iterator<char>());
}
catch(...) {
}

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

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

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

особенно понравилась оптимизация в виде удаления комментария про нулевой размер файла

вообще эту проблему совместимости с С++ можно другими способами решать. Например, объектным брокером типа SOM (вполне классная компонентная архитектура, правда там в основе старьё типа CORBA, но задачи бинарной совместимости она вполне себе решает). Есть правда проблемы с производительностью (SOM примерно на 20% была медленнее объектной модели VTable в C++, по тестам) — но если за это по уму взяться, можно и оптимизации запилить.

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

потом, можно взять LLVM компиляторы: clang, ldc и придумать какой-то общий ABI и calling convention на основе LLVM биткода.

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

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

и вот это тоже полезно было бы раскрыть подробнее

или написанием на местном языке, в несколько этапов доводят до ума на родной платформе.

Мне кажется, или вы описали людей у которых проблемы с головой.

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

теоретически, если бы взять какой-то SOM для обеспечения бинарно совместимого, стабильного ABI, и как-то здорово его облегчить (например, как в языке ooc), мог бы быть профит.

ooc = ?

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

Мне кажется, или вы описали людей у которых проблемы с головой.

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

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

Ди нуждается в сильной кастрации. И как минимум, в ускорении работы на типичных задачах раскрутки циклов-зависимостей, примерно в два раза.

Погорячился - два способа. Ranges и opApply - см. здесь: http://dlang.org/statement.html#ForeachStatement

Это я foreach over tuples чего-то сюда же засунул

Они с самого начала поддерживали ограниченную совместимость с объектной моделью плюсов. Вот детальное разъяснение: http://dlang.org/cpp_interface.html

Обёртка нужна потому что хотелось бы использовать либу в более-менее нативных для D терминах - ну там, ranges, автоматическая привязка SQL-типов к дишным для БД, RAII/scope для защиты от склероза и тому подобное.

Если его кастрировать - какой в нём толк? Он и хорош богатством фич. Наоборот - туда бы кастомную обработку AST, чтобы можно было добавлять пользовательские синтаксические конструкции - хотя бы в пределах rewriting'а

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

и вот это тоже полезно было бы раскрыть подробнее

Для начала, реализовать Си++-ABI - это отдельная сложная задача. Насчет несовместимости: следование Си++ ABI накладывает на реализатора нового языка нехилые ограничения (нельзя сделать reference-типы как в Яве; придется делать VTBL, RTTI и исключения как в Си++; для использования шаблонов придется написать небольшой компилятор Си++) и заставляет решать кучу вопросов разной степени тонкости (как передать «родной» объект аргументом в Си++-код? как использовать Си++-объект в ADT? как будут взаимодействовать системы управления памятью?). В общем, неизбежно появление в языке двух видов объектов - Си++ и «родных», причем их смешивание будет зверски ограничено. И встает вопрос - а оно того стоит? На Unix-платформе ответ вполне определенный - «нет». На Венде - ХЗ, но, думаю, и там прще будет поддеривать какой-нибудь COM.

ты просто не с того конца смотришь и оттого видишь сплошные проблемы

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

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

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

так что с++ все равно где-то рядом

заботы вроде «как собирать мусор» «как сделать, чтобы после перемещения объекта указателей на него не было либо они все были валидны» возникают и в плюсах — достаточно вспомнить, что std::vector при расширении реаллоцируется

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

__________________________________

хотя, возможно, у тебя есть на примете некая объектная система, где все внезапно совсем не такое — так расскажи

Богатство фич я наблюдаю в пакете Математика от дедушки Вольфрама, а это непонятно как назвать - ну была определенная поддержка от чисельников на первых этапах - чтобы квад был по умолчанию. Но не тянет оптимизация, не тянет. Даже до ЛЛВМ чтобы дотянуть - надо отключать все проверки границ, которые непонятно зачем нужны. В Си их вроде никогда и не было. То есть, называть язык тогда надо было AnotherScriptLang, а никак не понтоваться сравнением с Си.

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

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

ну оберон слишком чужеродный для человека, испорченного нарзаном braces language.

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

«технологическая изоляция», например. вот есть BlackBox Component Pascal, изящная штучка. с встроенным REPL в виде коммандеров, с парой компонент превращается в REPL через сокеты (оберон-система: сервер, команднострочная тулза — клиент, команднострочная тулза запихивается в make). ещё есть расширение к коммандерам, чтобы многострочные скрипты на обероне писать.

Я имел в виду только язык Оберон. BlackBox, Component Pascal это несколько из другой оперы.

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

Проверка границ нужна.