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

Анонимный лиспер, который в сраче D vs C++ агитирует за переход на чистый C настолько упорот, что позор ему вряд ли страшен.

настолько упорот

Это всё цепепе виноват :-)

Пофиг с чего вы упоролись до полной неадекватности. Раз вы настаиваете на использовании чистого C вместо D и C++, то извольте показать, как это будет выглядеть. А то ведь код писать — это не на форумах звиздеть.

А то ведь код писать — это не на форумах звиздеть.

Зачем же так однобоко? :-) Код не только можно писать, но и читать. :-) И очень часто, что второе намного сложнее первого. Особенно, если это цепепе или какой-нибудь пёрл :-)

Вы тут неделю убеждаете всех, что вместо D и C++ нужно писать на чистом C. При этом сами написать на C даже простую программу не можете. Не удивительно, что C++ный код прочесть вам не дано.

Это ты о ком сейчас? :-) А то вот такой код я бы не показывал даже за бабки :-)

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

Код не только можно писать, но и читать. :-)

С кодом много чего можно делать, но писать ты его не способен.

Вы тут неделю убеждаете всех, что вместо D и C++ нужно писать на чистом C. При этом сами написать на C даже простую программу не можете. Не удивительно, что C++ный код прочесть вам не дано.

Ну хорошо, убедил :-)

PS. Не люблю стиль, когда внутренности скобок отделяются от самих скобок пробелами :-) Сразу наводит на подозрение, что автор испытывает проблемы с чтением кода :-)

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

Это не флуд, это просто просто отчаянная попытка обратить внимание на классику :-)

С кодом много чего можно делать,

Лучше по-чаще его выбрасывать :-)

но писать ты его не способен.

Способен!!1

А твой код действительно паршив.

Он просто великолепен. Показывает весь идиотизм пихания функционального подхода туда, где он не нужен.

Анонимный лиспер, который в сраче D vs C++ агитирует за переход на чистый C

Вообще-то, тема про новый компилятор D. И что ты тут со своим C++ устраиваешь «срач» вызывает недоумение.

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

Вообще-то, тема про новый компилятор D. И что ты тут со своим C++ устраиваешь «срач» вызывает недоумение.

Заходим на http://dlang.org/overview.html, и видим, что кол-во упоминаний C++ просто зашкаливает. Ну и если авторам такое можно, то почему нельзя остальным.

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

И с какую-такую задачу, которую можно решить на C++, нельзя решить на C? Лол.

И с какую-такую задачу, которую можно решить на C++, нельзя решить на C? Лол.

Тут уже одному С-шнику предложили переписать на С десять строчек на D. Результата до сих пор нет.

Написать то все можно, но нужно ли? Можно и на чистом ассемблере написать все, что угодно, но какой от этого профит?

Написать то все можно, но нужно ли?

Какого хрена тогда на твоём компе большинство софта написано на C? Нужно ли?

Можно и на чистом ассемблере написать все, что угодно, но какой от этого профит?

Можно и на чистом ассемблере, если для конкретной железяки. А профит от C как раз такой, что код на нём самый портабельный, чем все эти бусты вместе взятые.

Какого хрена тогда на твоём компе большинство софта написано на C?

Если говорить конкретно про мой, то еще не мешало бы убедиться, что большинство софта написано на C. Может под Linux-ами без KDE это и так, а вот под оффтопиком ситуация не так однозначно, т.к. в самой винде C++ используется активно, в том числе и для драйверов.

Из того, чем приходится пользоваться постоянно: три браузера (Firefox, Chrome, Opera) — С++, компиляторы (MinGW-w64 и VC++) — C++, Adobe Lightroom и Acrobat Reader — C++, Vim — С, виртуальная машина Ruby — С. Не знаю на чем написаны IrfanView и AIMP2.

Как бы доминирования C не наблюдается.

А профит от C как раз такой, что код на нём самый портабельный

Да, есть такое дело. Только не нужно умалчивать цену такой портабельности. Линусу хорошо, у него нет бюджета на разработку Linux-а, а вот если у программного проекта есть и бюджет, и сроки, то низкий уровень C и большее количество телодвижений для достижения сравнимого результата, скорее всего, будут перевешивать плюсы от высокой портабельности.

А профит от C как раз такой, что код на нём самый портабельный

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

Посмотри код zlib - это не портабельность, это ее противоположность.

Смотрел. Да, не сахар. Но это работает, и ничего лучше, чем препроцессор, не придумали. И C++ - тоже насмотрелся. Не сахар. И те же потуги с препроцессором, что и в C, дабы всё-таки попытаться сделать код портабельным, только ещё ++ все эти мангли-демангли, ABI, vtable и прочие «красоты». C++ же, надо же добавить проблем.

Смотрел. Да, не сахар. Но это работает, и ничего лучше, чем препроцессор, не придумали.

А ты уверен, что он тут вообще нужен? Вот M$, например, у себя на сишарпах всяких реализовала:

http://referencesource.microsoft.com/#System/sys/System/IO/compression/Huffma...

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

И C++ - тоже насмотрелся

С С++ так же история, что и с С.

А ты уверен, что он тут вообще нужен? Вот M$, например, у себя на сишарпах всяких реализовала:
Достаточно просто внятного стандарта языка с нормальной стандартной библиотекой.

Сравнил хрен с пальцем. Это всё равно, что сказать: «вот на SBCL реализация DEFLATE. Без всяких препроцессоров в принципе. Достаточно ANSI Common Lisp». Сравнил платформу - «Mono» с ОС. Лол.

Сравнил хрен с пальцем.

Сравнил два языка.

Сравнил платформу - «Mono» с ОС. Лол.

А ты не отмазывайся. Препроцессор тут нужен не потому, что Mono аж целая платформа, а потому-что:

а) в С ты не можешь создать динамическую библиотеку без препроцессора, т.к. надо выписать отдельно макросы для win/lin/etc.;
б) в С до сих пор «выводят» платформонезависимые типы, т.к. C99 не везде поддерживается и используется;
в) в С до недавних пор в стандарте не было даже тредов, и до сих пор их нет в той же glibc, что вынуждает все так же писать разный код под разные платформы;
г) в С масса платформоспецифичных UB;
д) в С масса платформоспецифичных костылей - strlcat, alloca, itoa и пр., которые родились из убогости языка и стандартной библиотеки.
е) в С несмотря на убогость языка, компиляторы и libc к ним понимают и умеют стандарт по своему;

И т.д. Все это не имеет отношения к «платформе», С сам по себе такой, что ты, написав, «int i = 0;» уже имеешь платформозависимый код.

Сравнил два языка.

Совершенно разного уровня абстракции, и, как следствие, совершенно разного назначения. На C# ОС не пишут, драйвера не пишут, и нативный код не генерят.

А ты не отмазывайся.

А я и не отмазываюсь. Я утверждаю то, что знаю.

а) в С ты не можешь создать динамическую библиотеку без препроцессора, т.к. надо выписать отдельно макросы для win/lin/etc.;

Ты забыл уточнить, что _кроссплатформенную_ библиотеку. Да, без препроцессора в C это невозможно.

б) в С до сих пор «выводят» платформонезависимые типы, т.к. C99 не везде поддерживается и используется;

А уж C11 - так тем паче. А C++14 под Windows - так вообще всё плохо.

в)
г)
д)
е)

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

И т.д. Все это не имеет отношения к «платформе», С сам по себе такой,

C как раз такой потому, что не имеет отношения ни к какой платформе. И никаким другими способами, кроме как макроподстановками, кроссплатформенный код не написать. К чему ты этот разговор завёл, мне не понятно. Пиаришь Mono, что-ли? Так она никому не упала. Почти. :)

что ты, написав, «int i = 0;» уже имеешь платформозависимый код.

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

На C# ОС не пишут, драйвера не пишут, и нативный код не генерят.

https://github.com/mosa/MOSA-Project/wiki

Ты забыл уточнить, что _кроссплатформенную_ библиотеку. Да, без препроцессора в C это невозможно.

А в других языках возможно. Шах и мат.

А уж C11 - так тем паче. А C++14 под Windows - так вообще всё плохо.

В VS2015 вполне себе хорошо. Но, повторюсь, я отношу С++ к той же категории, что и С.

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

Да, были давно времена, когда надо было руками много писать на ассемблерах, и С был удобной заменой. Но сейчас компиляторы генерируют код куда лучше чем человек. И какой-нибудь Rust по производительности практически не отличается от С. При том не имея недостатков «ассемблера».

C как раз такой потому, что не имеет отношения ни к какой платформе. И никаким другими способами, кроме как макроподстановками, кроссплатформенный код не написать.

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

Пиаришь Mono, что-ли? Так она никому не упала. Почти. :)

Mono был взят как пример, не больше.

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

Т.е. ты сам считаешь, что теоретический выигрыш важнее переносимости. Окай.

А в других языках возможно. Шах и мат.

:-) Где это ты видел библиотеку на C#, которую можно вызывать, скажем, из JavaScript, или Ruby? А вот биндинги для библиотек на C пишутся тривиально. Так что отдыхай себе :-)

В VS2015 вполне себе хорошо.

Да пох, если честно :-)

Наша песня хороша... В этой задаче вообще нет ничего платформозависимого. Вообще.

неРаспарсил(-:

Разработчики на С трахаются исключительно из-за особенностей своего языка, который застрял в прошлом.

А какой-такой язык является языком настоящего? Они все из прошлого, что C, что C++, что Lisp, что Ruby, что твой C#. :-)

И какой-нибудь Rust по производительности практически не отличается от С. При том не имея недостатков «ассемблера».

Игра в шахматы на твоём поле состоится тогда, когда на Rust напишут хотя бы 10% того, что написано на C :-)

Т.е. ты сам считаешь, что теоретический выигрыш важнее переносимости. Окай.

Да нет, это как раз практический выигрыш. Но тебе то до этого дела нет. Так что давай, до свидания. :-)

А в других языках возможно. Шах и мат.

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

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

В «других языках» есть jni/ffi/etc. Оно же обычно и используется для стандартной библиотеки.

Именно. Java новый тред не волшебством делает, а обычным сисколом, и для этого кто-то писал сишный код с макросами. Тоже самое и с c# и прочими бейсиками.

Именно. Java новый тред не волшебством делает, а обычным сисколом, и для этого кто-то писал сишный код с макросами.

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

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

Пользователи С или С++ тоже могут использовать библиотеку в которой уже все макросы написаны

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

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

Им приходится это делать. Как и писать бессмысленные include guards.

Не могут они этого делать.

Ложь. При чем здесь экспорт/импорт? У меня лежит бинарь либы на винде свой, на линуксе свой, и т.д.. Я линкую его как хочу на любой оси. При чем здесь препроцессор?

Им приходится это делать.

Ложь. Вот к примеру pthread, на какой распространенной платформе я не могу ее заюзать? Отвечай или балабол.

Ложь. При чем здесь экспорт/импорт? У меня лежит бинарь либы на винде свой, на линуксе свой, и т.д.. Я линкую его как хочу на любой оси. При чем здесь препроцессор?

У тебя память короткая? Разговор шел про _создание_ библиотек. То, что ты ноль, который ни разу их не писал и только пользуешься, и так понятно. Потому, если не в теме, то просто молчи.

Ложь. Вот к примеру pthread, на какой распространенной платформе я не могу ее заюзать? Отвечай или балабол.

Хоть тебя и понесло не туда, но ответ очевидный - на винде. Понятно, что есть всякие cygwin, wine, wsu и пр. сторонние прослойки для портирования туда и обратно, но поддержки POSIX в дефолтной винде нет. И Visual C++ скажет тебе, что ты идиот и никакой pthread ему не известен.

Разговор шел про _создание_ библиотек.

Так создавай. Если при создании понадобятся потоки, возьми pthread, прилинкуй ее к своей либе и не придется писать макросы. Если понадобится что-то еще, заюзай другую либу. Или не осилил pthread на винде? Тогда так и пиши, только тогда это не проблемы С/С++