LINUX.ORG.RU

Вышла первая версия компилятора D, написанная на D

 


3

6

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

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

DMD теперь поддерживает формат mscoff, используемый в библиотеках VS2015.

Активно ведутся работы над поддержкой мобильных платформ. В настоящий момент сообщается, что рантайм языка и библиотека Phobos проходят практически все тесты на устройствах Android. О полноценной поддержке разработки под iOS пока говорить нельзя, однако благодаря усилиям проекта LDC-iphone несложные приложения на D под iOS писать можно уже сегодня.

Для пользователей Linux выложена первая пробная версия компилятора Calypso, позволяющая в D использовать практически все существующие С++-библиотеки, даже такие большие и сложные, как Qt5 и Ogre3D.

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

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

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

Новая версия сервера DCD, реализующая автодополнения исходного кода, также готова к использованию с новой версией DMD.

>>> Подробности

★★

Проверено: Shaman007 ()
Последнее исправление: Wizard_ (всего исправлений: 5)
Ответ на: комментарий от wolph

и в qml/javascript пробрасывается QVariantList или QVariantMap автоматом и становится там родным массивом/словарем.

«А вот если бы не было у меня машины, то не успел бы за день и колеса новые купить и стекло лобовое заменить» (с) народный анекдот.

andreyu ★★★★★
()

Обьясните в 2-ух словах так такое (компилятор написан на языке, который сам компилирует) работает в принципе? Если вы скачиваете исходники всего.. Если и сам компилятор на D.. то кто скомпилирует сам компилятор для начала? Бинарники всегда в комплекте идут чтоли?

Alexoy
()
Ответ на: комментарий от DarkEld3r

Нет, если нам не нужно остальное Qt-шное барахло.

Да, если нам не нужно остальное stl-ное барахло.

И что это за стиль такой?

Да хотя-бы те же arg, to/from. Да даже тот факт, что всё это было в кути за долго до того, как это впихнули в стл - уже говорит о многом.

Это «щас» появились всякие to_string() и прочее. Крестовые стримы просто убожество, сравнивать стрингстрим и arg - просто не имеет смысла.

А уж qfile и крестовые стримы даже сравнивать противно.

Ну а у меня не вызывает и что дальше?

Аргументируй.

PotentialCppTsar
()
Ответ на: комментарий от matumba

Зачем? Ставь, если тебе нравится!

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

anonymous
()
Ответ на: комментарий от wolph

Хорошо не жили - неча и начинать?

Кьют хорош если уже куча говна написана на нем. Если говно еще не начали плодить, то не стоит и браться за кьют.

andreyu ★★★★★
()
Ответ на: комментарий от asaw

Пока ты мне не приведешь пример полезной программы на альтернативном язычке

Ожидаемо, да. Последний вопрос - полезность будешь определять ты лично?

tailgunner ★★★★★
()
Ответ на: комментарий от andreyu

Кьют хорош если уже куча говна написана на нем. Если говно еще не начали плодить, то не стоит и браться за кьют.

Я бы сказал, что он хорошо как гуй, но не больше. А когда встречаешь консольные приложения реализованные на QApplication - меня оторопь берет. Зачем? Просто люди пихают Qt куда не попадя.

anonymous
()
Ответ на: комментарий от tailgunner

Ожидаемо, да. Последний вопрос - полезность будешь определять ты лично?

Всем лором будем определять. Возьмем за критерий результат опроса.

asaw ★★★★★
()
Ответ на: комментарий от matumba

В реале ты не исправил ни одной, ибо если б ты писал на Ди, то знал бы, что языковые элементы стабильны уж лет 5 как.

И не только я. Может «ложки уже и нашлись», но осадок остался. Теперь авторам D нужно доказать, что они могут в стабильность. Причем не только языка, но и компилятора. Changelog которого как обычно удручает глупыми багами (с которыми ты конечно не сталкивался).

У меня есть три программы, ОДНУ из которых пришлось править из-за регэкспов. В трёх местах. И я согласен на этот «геморой» в пользу будущего.

Без проблем, я тоже подожду это будущее.

anonymous
()
Ответ на: комментарий от anonymous

Changelog которого как обычно удручает глупыми багами (с которыми ты конечно не сталкивался).

Список глупых багов из ченджлога? Что-то не припомню таких. Года 4 уже пишу на D.

anonymous
()
Ответ на: комментарий от Alexoy

Обьясните в 2-ух словах так такое (компилятор написан на языке, который сам компилирует) работает в принципе?

Обычный режим - используется доступный бинарник компилятора предыдущего релиза (например из репозитория дистрибутива). Для проверки того, что это именно тот бинарник, производится поэтапаная сборка всех версий начиная с последней на «неродном» языке.

Dicebot
()
Ответ на: комментарий от anonymous

Список глупых багов из ченджлога? Что-то не припомню таких. Года 4 уже пишу на D.

Открываем changelog последней версии, пропускаем первый баг как неинтересный, смотрим второй:

https://issues.dlang.org/show_bug.cgi?id=14430

public class HttpResponse{
	public void setCookie(
		string name,
		long maxAgeInSeconds = long.min,
		string expiresOnGMTDate=null,
		string path=null,
		string domain=null,
		bool secure=false
	){
		assert(expiresOnGMTDate is null);
		assert(path is null);
		assert(domain is null);
	}
}

void main(){
	auto responseObject = new HttpResponse();

	responseObject.setCookie( "A1" );
	responseObject.setCookie( "A2" );
	responseObject.setCookie( "A3" );
	responseObject.setCookie( "A4" );
}

In the first call, it works correctly. In the second and later calls, assert doesn't pass, and it says those parameters are not null.

Ну и т.д.

anonymous
()
Ответ на: комментарий от bbk123

Хорошая новость. Интересно, появится ли вменяемый D IDE, написанный на D, и сможет ли D потеснить Java?

- Может, если какая-то корпорация/фонд начнет его продвигать и писать на нам свои продукты. Как это произошло с Go, Scala, Rust.

D ждет своего инвестора, лет 20 уже правда ждет...

anonymous
()
Ответ на: комментарий от anonymous

Я бы сказал, что он хорошо как гуй, но не больше. А когда встречаешь консольные приложения реализованные на QApplication - меня оторопь берет. Зачем? Просто люди пихают Qt куда не попадя.

- Да, для консоли лучше boost, для GUI - Qt.

anonymous
()
Ответ на: комментарий от PotentialCppTsar

ллвм - это 95% любого конпелятора и 100% самого сложного и затратного.

---------------------------------------------------------------------------------------
Language                             files          blank        comment           code
---------------------------------------------------------------------------------------
C++                                   2462         136045         172024         767517
Rust                                  6232          70607         140225         355002
C/C++ Header                          1445          46810          84461         259523
C                                      720          11581          13763         150341
Assembly                              1514          38414         129342          85622
...

Причём доля llvm там:

---------------------------------------------------------------------------------------
Language                             files          blank        comment           code
---------------------------------------------------------------------------------------
C++                                   1564         125353         159014         705300
C/C++ Header                          1208          42422          77705         178097
Assembly                              1407          37778         127179          83432
....

Т.е. 58% с хедерами и 48% без. Где обещанные 95%/100%?

Хотя даже будь он кодогинератор - это основная часть конпелятора.

Основная часть компилятора это семантический анализатор, ибо именно семантикой современные ЯПы и отличаются.

Парсер/лексер даже на русте не осилили написать. Гинерит его левая сишная тулза.

А по какой, позвольте узнать, причине clang/gcc/tcc/etc имеют свой лексер+парсер? А я Вам отвечу: сгенерированные LL- и LR- парсера — говно имеют плохие сообщения об ошибках (особенно LR-), поэтому RDP (реже RAP) — единственный вминяемый метод получить келлбек... в контексте убогого С++ с его неоднозначностями (да-да, я про всякие X*Y проблемы и прочее). Если Вы писали на ржавчине, то с его сообщения об ошибках наверняка знакомы (придраться там особо не к чему). Вопрос: на кой чёрт тратить кучу человекочасов для написания парсера. Возможно это сделают для повышения производительности, ибо синтаксис языка уже стабилизировался.

При этом парсер-лексер эта задача уровня лабы старшего курса.

Даже младшего. Не вижу абсолютно никаких проблем с написанием его на rust'е.

Раст к колнпелятору раста не имеет никакого отношения. Зачем балаболить, если нихрена не понимаешь?

Срочно перечитывать Ахо и Ульмана. Срочно.

loyd
()
Ответ на: комментарий от andreyu

не стоит и браться за кьют

тулкитофобы не нужны

А когда встречаешь консольные приложения реализованные на QApplication - меня оторопь берет.

man QCoreApplication. В любом случае всяко лучше питона.

PS: stl убог по определению.

anonymous
()
Ответ на: комментарий от DarkEld3r

Давай с другой стороны зайдём: языки, которые транслируются в С на чём написаны?

давай (подсказка в конце). языки, которые транслируются в Rust, на чём написаны? неважно. а если транслируется в макросы раста, плагином компилятору?

то можно компилятор D например написать на таком DSL макросов раста. например, можно написать «транспилятор» transpiler, который будет читать например PEG парсером синтаксис D, и переводить его в аналогичные конструкции на расте. при этом написать его как макрос, плагином раст-компилятора.

важная фича в том, что из-за CTFE компилятор D можно реализовать как библиотеку, на нём самом (см. например реализацию регекспов через CTFE, или pegged парсер через CTFE).

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

важная фича такой реализации — возможность отключить GC (если реализовать его отдельным модулем на расте, а непонятными кишками в рантайме Druntime, и проконтролировать работоспособность после gc.disable. была экспериментальная поделка Druntime в духе TObject из Delphi, которая не требовала GC, да сдохла).

и реализовать ключик -gc:disable в компиляторе — как в Nimrod.

опять же, менее завязано на тулчейн LDC (более на тулчейн раста, ага).

можно было бы наконец-то shared libraries по-нормальному запилить, без костылей! на всех платформах сразу.

кроссплатформно собрать LDC — то ещё приключение. под MinGW там как-то с бубном и камланиями собирали, особой сборкой. а так кроссплатформностью занимался бы раст, а не «ещё один компилятор с бекпортованными из DMD не полностью всеми фичами».

Давай с другой стороны зайдём: языки, которые транслируются в С на чём написаны?

подсказка: на метаязыке.

anonymous
()
Ответ на: комментарий от DarkEld3r

Давай с другой стороны зайдём: языки, которые транслируются в С на чём написаны?

например, InteLib А. Столярова. лисп, который транслируется в С++ через «операцию запятую» или «операцию пробел».

он написан на метаязыке поверх С++. только поскольку С++ сосёт, приходится реализовывать «операцию запятую» частично в рантайме. а в D через CTFE было бы менее частично, более в компайлтайме.

или в Rust через CTFE макросами как плагин к компилятору. опять же, макросы — это метаязык.

anonymous
()
Ответ на: комментарий от anonymous

Не удивительно, что на этом до сих пор ничего дельного не написали facepalm.jpg

asaw ★★★★★
()
Ответ на: комментарий от PotentialCppTsar

Правда я случайно включил стандартную библиотеку в подсчёт. Непосредственно к компилятору относится:

➜  rust git:(master) cloc src/librustc*
     367 text files.
     367 unique files.                                          
       8 files ignored.

http://cloc.sourceforge.net v 1.64  T=2.01 s (178.9 files/s, 91611.2 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Rust                           359          19720          25921         138237
-------------------------------------------------------------------------------
SUM:                           359          19720          25921         138237
-------------------------------------------------------------------------------
140к строк включает в себя семантику и работу со своим IR. Т.е. в этом случае доля llvm будет 83%. Вполне ок для бэкенда компилятора.

loyd
()
Ответ на: комментарий от loyd

Т.е. 58% с хедерами и 48% без. Где обещанные 95%/100%?

Чё ты мне тут напастил? Что это?

И да, никому не интересно где и сколько написано лапши.

Основная часть компилятора это семантический анализатор, ибо именно семантикой современные ЯПы и отличаются.

Датычё. Ну и зачем тогда нужен ллвм?

Меня не интересует то, что нужно адепту и его жалкие оправдания. Кодоген+трансформации кода - основная и наиболее сложная часть конпелятора.

А по какой, позвольте узнать, причине clang/gcc/tcc/etc имеют свой лексер+парсер?

А раст имеет?

А я Вам отвечу: сгенерированные LL- и LR- парсера — говно имеют плохие сообщения об ошибках (особенно LR-), поэтому RDP (реже RAP) — единственный вминяемый метод получить келлбек...

КО во все поля. Ты по-существу что-то ответь.

в контексте убогого С++ с его неоднозначностями (да-да, я про всякие X*Y проблемы и прочее)

Подробнее, в чём и где тут «неоднозначность» и прочее? Так же мне интересно каким это таким образом ты обосновал кресты, как «убогие».

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

Я не пишу на «куллязыках» и мне не интересны не синтаксические ошибки в конпеляторе, ибо они в целом бесполезны на том уровне, на котором пишу код я.

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

Вопрос: на кой чёрт тратить кучу человекочасов для написания парсера. Возможно это сделают для повышения производительности, ибо синтаксис языка уже стабилизировался.

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

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

Почему у всех адептов всегда так - писать рантайм-лапшу всегда пожалуйста, вливая в неё человекогода, а когда дело доходит до реально сложного и ответственного когда, так все в кусты?

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

Нет, тут дело не человекочасах, а в чём-то ином.

Даже младшего. Не вижу абсолютно никаких проблем с написанием его на rust'е.

Это никого не интересует.

Ахо и Ульмана

Подробнее, что я из неё узнаю? Протухшую теорию уровня лабы, которую я вывожу с нуля намного сильнее балаболов? Для этого не нужны никакие талмуды, а достаточно способностей уровня хотя-бы <1%.

В целом твоя проблема в том, что ты вместо конкретного ответа и вменяемого восприятия информации - пытаешься писать мне какие-то оправдания и свои выводы. Мне они не интересны.

Я конкретно написал - раст не имеет никакого отношения к конпелятору раста и пояснил почему.

Ты же по-существу ничего не сказал, кроме непонятно откуда взявшихся табличек.

Если есть что сказать - говори.

PotentialCppTsar
()
Ответ на: комментарий от DarkEld3r

С++ сосёт например потому, что нету в нём нормальной рефлексии и тайпинфо.

и те штуки, которые элементарно реализуются в D в CTFE на тайптуплах и трейтах (да и концепты в виде ограничений, функция (...) if предикатНаПараметры!вовремяCTFE { телоФункции } — с нормальным синтаксисом, а не как в С++ — используется всю дорогу в std.algorithm. сравни с бустом и прослезись) , template mixin — делаются просто, а в С++ через боль, унижение и вообще ненужно.

хотя есть вот например Константин Книжник, ООСУБД Goods и его диссер на эту тему. там на С++98 (или чуть раньше) вручную реализована рефлексия, затем метаобъектный протокол, сериализация, транзакции, стратегии СУБД.

только напоминает реализация закат солнца вручную. нормального CTFE опять же в С++ нет.

на D всё это гораздо проще было бы. опять же, аннотации почти как в C# сильно упрощают такую рефлексию. то есть, она практически полезна — у модулей есть метаинформация, и частично во время компиляции (CTFE).

anonymous
()

Для пользователей Linux выложена первая пробная версия компилятора Calypso, позволяющая в D использовать практически все существующие С++-библиотеки, даже такие большие и сложные, как Qt5 и Orge3D.

и это через полгода после того, как кое-кто дёргал Qt4 из D вручную.

anonymous
()
Ответ на: комментарий от loyd

Вполне ок для бэкенда компилятора.
бэкенда

Это именно «ок» для «бэкенда» конпелятора, но пацаны заявляли, что там где-то есть конпелятор на расте. Ищем.

Из которых 50%+ - мусора(левый код, гинерируемая лапша/таблицы и прочее).

Аля https://github.com/rust-lang/rust/blob/master/src/librustc_unicode/tables.rs https://github.com/rust-lang/rust/blob/master/src/librustc_platform_intrinsic...

2 файла - 10к строк - уже -~10% от твоего выхлоп, а там таких много.

А остальные <50% примитивная лапша, которая по сложности реализации даже рядом не валялась с ллвм.

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

И того - ты сам пруфцанул, что rustc представляет на 99% ллвм и на 1% руст, даже своим убогим подсчётом строк. И ведь ничего иного - я не ожидал.

PotentialCppTsar
()
Ответ на: комментарий от PotentialCppTsar

И да, никому не интересно где и сколько написано лапши.

Я так понял, конструктивного разговора у нас не получится?

Датычё. Ну и зачем тогда нужен ллвм?

Затем и нужен, чтобы можно было сделать хипстерский ЯП с новыми идеями и не писать тонны кода генерации IR->asm под каждую платформу.

Кодоген+трансформации кода - основная и наиболее сложная часть конпелятора.

Это самая нудная часть, любой студент, изучавший структурное программирование представляет как получить из примитивов структурной парадигмы низкоуровневые примитивы (т. Бёма-Якопини и т.д.), а дальше идут низкоуровневые оптимизации и сплошная специфичная asm нудятина, которой заниматься никто не хочет, ибо к ЯПу это напрямую не относится и нехрен писать велосипеды.

Вот интересно, а swift и clang тоже не компиляторы?

В данном случае аргумент один - не осилят, ибо некомпетентны.

Марш изучать и тогда можно будет о чём-то говорить.

Для этого не нужны никакие талмуды, а достаточно способностей уровня хотя-бы <1%.

Ну, что для Вас верх уровня сложности написание парсера по однозначной грамматики, это я уже понял.

В целом твоя проблема в том, что ты вместо конкретного ответа и вменяемого восприятия информации - пытаешься писать мне какие-то оправдания и свои выводы. Мне они не интересны.

Т.к. ни одного аргумента (кроме нытья и соплей) с Вашей стороны я не услышал, не думаю, что имеет смысл продолжать. /тред

loyd
()
Ответ на: комментарий от loyd

Датычё. Ну и зачем тогда нужен ллвм?

Затем и нужен, чтобы можно было сделать хипстерский ЯП с новыми идеями и не писать тонны кода генерации IR->asm под каждую платформу.

так и запишем — Kaleidoscope это есть хипстерский недоязычок с новыми питонами, на маргинальном окамле, ога. лолъ.

anonymous
()
Ответ на: комментарий от PotentialCppTsar

А остальные <50% примитивная лапша, которая по сложности реализации даже рядом не валялась с ллвм.

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

Аргументации ведь, кроме убогих выхлопов недотулз нет.

Ну да, а у Вас, я посмотрю, аргументации хоть отбавляй. То, что для Вас парсер для однозначной грамматики — задача за гранью способностей, это мы уже поняли, есть чем ещё удивить?

И того - ты сам пруфцанул, что rustc представляет на 99% ллвм и на 1% руст, даже своим убогим подсчётом строк.

Даже с арифметикой проблемы. Удивили.

2 файла - 10к строк - уже -~10% от твоего выхлоп, а там таких много.

5719. Ах да, это же опять арифметика...

И ведь ничего иного - я не ожидал.

Толсто, очень толсто. Нельзя же так, сударь.

loyd
()
Ответ на: комментарий от anonymous

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

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

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

хотя есть вот например Константин Книжник, ООСУБД Goods и его диссер на эту тему. там на С++98 (или чуть раньше) вручную реализована рефлексия, затем метаобъектный протокол, сериализация, транзакции, стратегии СУБД.

Этим и отличается С++ от «куллязыков». На нём «закатить солнце» вручную можно, а вот на «куллязыке» нет. Это и делает кресты крестами.

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

PotentialCppTsar
()
Ответ на: комментарий от anonymous

В любом случае всяко лучше питона.

Чем?

anonymous
()
Ответ на: комментарий от asaw

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

Есть в этом «если - то» что-то наркоманское. Масса людей (по крайней мере трое в этом топике, считая меня) пишет/писала полезный код на плюсах и живо интересуется их альтернативами.

anonymous
()
Ответ на: комментарий от loyd

Я так понял, конструктивного разговора у нас не получится?

Попытайся. Пока о «конструктивном разговоре» ты только рассуждаешь.

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

Как же я хочу с тобою нормально пообщаться, но так уж и быть - позволю тебе побалаболить.

и не писать тонны кода генерации IR->asm под каждую платформу

Никакого отношения к ллвм не имеет. Это бэкенд. В лужу.

Это самая нудная часть, любой студент, изучавший структурное программирование представляет как получить из примитивов структурной парадигмы низкоуровневые примитивы (т. Бёма-Якопини и т.д.)

Гинератор уровня блочного реплейса по шаблонам - нахрен никому не нужен, а твои «студенты» им могут только подтереться.

а дальше идут низкоуровневые оптимизации и сплошная специфичная asm нудятина

Т.е. трансформации кода на уровне ир - ты благополучно проигнорил, ибо понял, что обосрался.

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

Типичный представитель горестудента выстроганного по убогим талмудам 60-х годов. Те конпеляторы, о которых написана твоя убогая макулатура и о которых ты хоть что-то знаешь - умерли году эдак в 95.

Именно фронтенд написан по этой логике из 60-х. На уровне примитивного реплейса. Получаем из СА бревно - реплейсим синтаксические конструкции и выражения в ir-представление при помощи llvm-api. При этом реплейся тупо на блоки/инструкции - без малейшего анализа.

А вот дальше уже идёт то, в чём и основная сложность ллвм и заключается. Превратить это ir-убожество на входе во вменяемое представление.

которой заниматься никто не хочет

Ты хотел сказать «не может».

ибо к ЯПу это напрямую не относится

И опять обделался. Тебе про ЯП никто не говорил. Это относится к конпелятору, а тут ты обосрался.

и нехрен писать велосипеды.

До того, как не было ллвм и велосипеды надо было писать - этого никто не делал.

Вернее как - делал, но получалось что-то на уровне пхп, либо пистона.

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

Вот интересно, а swift и clang тоже не компиляторы?

Опять жалкая попытка съехать с темы подменой понятий.

Свифт и шланг точно так же не конпеляторы - об этом ты можешь прочитать в википедии:

Clang /ˈklæŋ/[3] is a compiler front end for the C, C++, Objective-C and Objective-C++ programming languages.

Очередной обсёр, но это к делу не относится. Шланг написан на крестах, как и ллвм - он на крестах. На каком «тулките» он основан - никого не интересует.

Поэтому крестовики могут говорить, что их компилятор написан на крестах и насрать фронтенд-ли шланг, либо нет.

Точно так же никого не интересует на каком «тулките» запилен rustc, пока его адепты не начинают кукарекать о том, что написан он на расте и является конпелятором, а не фронтендом к ллвм.

Ну, что для Вас верх уровня сложности написание парсера по однозначной грамматики, это я уже понял.

Опять же - по-существу ничего - одно балабольство.

К чему ты написал и что из этого следует?

Т.к. ни одного аргумента (кроме нытья и соплей) с Вашей стороны я не услышал, не думаю, что имеет смысл продолжать. /тред

И опять же, очередной адепт обделался.

Аргументы были написаны в первом посте - здесь же разбирался твой убогий высер.

Я могу только констатировать твой обсёр в связи с:

Отсутствием предоставление оснований на высеры: «Т.е. 58% с хедерами и 48% без. Где обещанные 95%/100%?» - тут ты уже признался, что обосрался(в другом комменте), «Основная часть компилятора это семантический анализатор», «А по какой, позвольте узнать, причине clang/gcc/tcc/etc имеют свой лексер+парсер?»(имеет ли раст свой парсер+лексер и причём тут шланг/гцц).

И полным игнорированием моих изначальных доводов.

PotentialCppTsar
()
Ответ на: комментарий от anonymous

Масса людей (по крайней мере трое в этом топике, считая меня) пишет/писала полезный код на плюсах и живо интересуется их альтернативами.

Да я не спорю, что множество болтунов любят порассуждать о преимуществах одних инструментов над другими чисто теоретически. Пока что никаких практических примеров на этот счет никто не продемонстрировал. Я доступно излагаю?

asaw ★★★★★
()
Ответ на: комментарий от loyd

Так. Балабол окончательно сломался.

Так, тыканье в лужу с тем, что 50%+ его «строк» - мусор было проигнорировано и 95% «по строкам кода» так же. А это просто анигилирует его изначальный высер в ноль. Т.е. полностью обосанно.

Ну да, тайпчеккер и борроучеккер любой школьник напишет

И ведь пишут.

не то что примитивную генерацию из условия в джамп, угу.

Опять же - какую-такую примитивную «генерацию» из условия в джамп и откуда такая задача вообще взялась, когда эта задача УРОВНЯ ФРОНДЕНДА(У МЕНЯ УЖЕ ЖОПА ОТ ЕГО УБОГОСТИ БОЛИТ - УБЕРИТЕ ЕГО ОТ МЕНЯ - Я ЩАС НЕ СДЕРЖУСЬ). ir - это байткод и условие в джамп генерирует rustc, как и любой другой фонтедн.

Ну да, а у Вас, я посмотрю, аргументации хоть отбавляй.

Пока что ты против моей «аргументации» ничего не смог противопоставить, кроме убого сравнение строк. Но даже в нём ты обосрался.

То, что для Вас парсер для однозначной грамматики — задача за гранью способностей, это мы уже поняли, есть чем ещё удивить?

Опять же - где я такое говорил и на чём основан этот «вывод»/«предьява»?

Типичное враньё сломанного балабола, который начинает врать и юлить по-чёрному.

5719. Ах да, это же опять арифметика...

К чему это и что из этого следует - опять же никому не ведомо. Но пытайся.

Толсто, очень толсто. Нельзя же так, сударь.

А потом меня спрашивают - почему я такой злой и не культурный. Проблема в том, среди кого я живу.

И после этого вы будите меня в чем-то упрекать.

PotentialCppTsar
()
Ответ на: комментарий от PotentialCppTsar

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

Хде? Я указал ~80%, где Вы тут 95-100 заявленных увидели я не знаю, это к докторам.

имеет ли раст свой парсер+лексер и причём тут шланг/гцц

Имеет, сгенерированный. Почему — объяснил. Если для Вас языки отличаются только синтаксисом, то говорить дальше не вижу смысла.

P.S. для звания царя надо в теме шарить, а то всё в лужу пердите, а толку 0, увы.

loyd
()
Ответ на: комментарий от asaw

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

Расскажи его болтунам из WG21. А то мучаются люди, что-то новое придумывают (и заимствуют из бесполезных языков!), а оказывается преимуществ там никаких нет.

anonymous
()
Ответ на: комментарий от PotentialCppTsar

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

откуда такая задача вообще взялась, когда эта задача УРОВНЯ ФРОНДЕНДА(У МЕНЯ УЖЕ ЖОПА ОТ ЕГО УБОГОСТИ БОЛИТ - УБЕРИТЕ ЕГО ОТ МЕНЯ - Я ЩАС НЕ СДЕРЖУСЬ). ir - это байткод и условие в джамп генерирует rustc, как и любой другой фонтедн.

http://llvm.org/docs/LangRef.html#br-instruction

Осильте уже туториал по rust-у, напишите простенькое условие (даже Вы справитесь) и посмотрите llvm ir выхлоп.

Ладно, в очередной раз не понимаю, зачем я продолжаю — Вы уже дискредитировали себя с десяток раз.

loyd
()
Ответ на: комментарий от loyd

Я указал ~80%,

Врёшь убогий, ты указал 48%, а потом обосрался. А теперь уже 83%, а 83% равносильно обсёру, ибо ты уже подтвердил, что основная, даже подавляющая кодовая база в рустц - это не раст.

138237

Из которых я доказал, что 50%+ - говно.

100 / ((767517 + 259523 + 150341 + 85622) / (138237 / 2)) = 5,472552322, точно 94.53%, чутка ошибся.

где Вы тут 95-100 заявленных увидели я не знаю, это к докторам.

Я даже не буду тебя мокать в дермище и говорит, что про строки кода я ничего не говорил. Ну да ладно.

Имеет, сгенерированный.

Т.е. надо добавить к этому ещё и кол-во строк в тулзе генераторов.

Почему — объяснил.

Только обделался. «ко-ко-ко ошибки норм - всё норм» - это не объяснение и не аргумент.

Если для Вас языки отличаются только синтаксисом, то говорить дальше не вижу смысла.

К чему и зачем ты это написал? Что из этого следует?

P.S. для звания царя надо в теме шарить, а то всё в лужу пердите, а толку 0, увы.

Ламерюга пытается мне что-то кукарекнуть. Как это мило.

Ну давай, в чём конкретно я «в лужу пердите».

PotentialCppTsar
()
Ответ на: комментарий от loyd

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

И поэтому ты проигнорил 90% из них.

http://llvm.org/docs/LangRef.html#br-instruction

Просто в нулину обосано.

if
br

Куллстори.

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

Осильте уже туториал по rust-у, напишите простенькое условие (даже Вы справитесь) и посмотрите llvm ir выхлоп.

К чему ты это высрал? Что из этого следует?

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

Ладно, в очередной раз не понимаю, зачем я продолжаю — Вы уже дискредитировали себя с десяток раз.

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

А раз ты решил рискнуть - я дам тебе шанс. С десяток раз - 9 пунктов(с моими цитатами), в которых я себя дискредитировал, а так же разбор их(т.е. ты должен написать в чём конкретно и почему этим я себя дискредитировал, типичное для ламерка «„ко-ко-ко“ - тут ты обделался потомучтоятаксказал» не работает).

Ладно, с 9-ю ты явно обделаешься, поэтому я дам возможность тебе хотя бы чутка не обосраться - высри три.

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

PotentialCppTsar
()

Там бекэнд несвободный вроде как. А нафиг он нужен с несвободным бекендом?

Или в сабжевом релизе это уже исправили?

Xenius ★★★★★
()
Ответ на: комментарий от DELIRIUM

D прекрасен, но, увы, уже есть C++14.

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

anonymous
()
Ответ на: комментарий от anonymous

Да и Уолтер Брайт разработчик первого родного компилятора C++ как бы знает все плюсы и минусы C++.

Плюса там всего два. Минусы стремятся к бесконечности.

umren ★★★★★
()
Ответ на: комментарий от anonymous

для консоли лучше boost

Boost лучше как тестовая площадка.

anonymous
()
Ответ на: комментарий от Alexoy

Обьясните в 2-ух словах так такое (компилятор написан на языке, который сам компилирует) работает в принципе? Если вы скачиваете исходники всего.. Если и сам компилятор на D.. то кто скомпилирует сам компилятор для начала? Бинарники всегда в комплекте идут чтоли?

Потому что такого не бывает. На самом деле есть минимальное ядро, написанное на ассемблере. Поверх него раскручиванием дописываются новые элементы. Именно так написаны компиляторы старейших языков типа C или Pascal. Вместо ассемблера может использоваться C (или тот же Pascal), либо целая библиотека, как в случае llvm. Это снижает самодостаточность, но часто делается в угоду скорости и удобству разработки.

Vudod ★★★★★
()
Ответ на: комментарий от KUser

Пожелаем удачи проекту! Потому что кресты давно закапывать пора

D еще монструозней крестов, причем кресты хотя бы могут быть в нише языков без GC, а зачем мутант D - большой вопрос.

anonymous
()
Ответ на: комментарий от PotentialCppTsar

100 / ((767517 + 259523 + 150341 + 85622) / (138237 / 2)) = 5,472552322, точно 94.53%, чутка ошибся.

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

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

А про что Вы говорили? Про сложность? Вы некомпетентны, чтобы оценивать сложность. Но если сильно хочеться — вводите формальную систему для оценки, проверим. А Ваш субъективный бред можете оставить при себе, он никого не интересует.

loyd
()
Ответ на: комментарий от anonymous

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

Расскажи его болтунам из WG21. А то мучаются люди, что-то новое придумывают (и заимствуют из бесполезных языков!), а оказывается преимуществ там никаких нет.

Не надо передергивать. Из исследовательских языков заимствуют. И никакие мои утверждения пока никто тут не опроверг.

asaw ★★★★★
()
Ответ на: комментарий от loyd

потому этот дублирующий быдлокод нужно выкинуть из подсчёта

А кто тебе сказал, что он дублирующий? Мальчик ни разу не видел хедеров? Кроме того хедер c классом, например, это по сути удобная документация. А ты в своем D без IDE будешь как мартышка бегать по всему файлу, чтоб увидеть цельную картину.

Вы некомпетентны

Он конечно шут, но про компетентность ты бы молчал.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.