Посмотри код 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 :-)

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

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

Вопрос к D-кам, его можно использовать совсем без своей стандартной библиотеки, как С++? Так, чтоб и классы были, и шаблоны, и миксины и пр., но на выходе получался самодостаточный и минимальный .so, который потом можно использовать с С. Сходу нагуглились костыли в виде minimal-d и пр,, но хотелось бы работы из коробки.

D без стандартной библиотеки

Без Phobos собирать можно, но D Runtime библиотека нужна - а она использует С runtime библиотеку.

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

Вот тут проект ядра OS (x86_64, простой helloworld):

http://forum.dlang.org/post/hniuujnhupttpfywcmfl@forum.dlang.org

Информация по сборке для микроконтроллеров:

http://wiki.dlang.org/Microcontroller_startup_files

Дело в том, что суровая бизнес логика требует хорошего ООП. В Rust он слаб.

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

У нас в проекте есть фаны его и к примеру куски поисковой машины готовы на него тащить, но в свой движок рекламного демона я даже не представляю как его пристроить. Да и зачем ? Основной аргумент - ОН БЕЗОПАСТНЫЙ. На что я резонно отвечаю, что в умелых руках и ... - балалайка. за 4-го в работающем проекте, не было ни одного падения. Были ошибки с самой логикой, но сегфолту не падали.

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

Для драйверов то Rust самое то.

Дело в том, что суровая бизнес логика требует хорошего ООП.

Это так внушили :-) На самом деле - вовсе не обязательно. И, к тому же, «хороший» ООП в Smalltalk, но не в цепепе :-)

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

Верно :-)

Во многом мозг развращают скриптовые языки. ))

И такой однобокий ООП, как в цепепе :-)

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

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

Common Lisp FTW!

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

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

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

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

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

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

Очень сомневаюсь. Всё-таки раст несёт и дополнительную сложность. И уж точно переход со скриптовых языков простым не будет.

На что я резонно отвечаю, что в умелых руках и ... - балалайка.

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

Впрочем, для меня, на этом плюсы раста не заканчиваются.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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