В проде крупных компаний и банков

В проде твоих фантазий.

Более продвинутые системы типов помогают выражать ожидаемое поведние еще более явно и точно.

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

да ладно, видно же, что чувак хоть что-то читает, хоть бы и хабр. бывают и такие которые вообще ничего не читают. хороший с++ будет когда перестанет читать хабр и начнёт думать собственной головой.

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

1. Прости эт ты в плюсах систему типов назвал адекватной? Ну у меня для тебя плохие новости...

Меня мало волнует то, что там тебе сообщаю голоса в твоей голове.

2. «Мощная» семантика плюсов является его самым большим недостатком, особенно с приходом 1y. Она настолько «мощная» что позволяет писать самые простые вещи вычурно в хлам забаговано и абсолютно не дебагабельно....

И примеры ты не приведёшь?

3. Жабка на голову выше в своих воможностях чем кресты.

У тебя методичка потекла.

И папик плюсов на голову выше в ООПешности. Я уж не говорю про ЖС или там свифт, которые на полторы головы выше за смесь змеи и холодильника (ака С++)...

Опять голоса без каких-либо пруфвов.

4. Тулинг в крестах говно, это если откровенно.

Ога. Покажешь что-то уровня libclang?

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

Никаких «создателей крестов» в природе нет. Опять ты перепутал реальность и голоса.

По факту весь тулинг для крестов состоит из осколков тулинга от папки(которые не матчатся с рельными плюсами), хипстерски недоделок(прювет шланг и атом) и проприетарных сингл-пурпоуз китов (привет icc, qcc)

Опять какая-то шиза. С каких пор птушное говно типа icc стало китом? Ты явно жертва пропаганды.

Иди помоги пацанам тут: https://habr.com/ru/post/450512/#comment_20149214 Раст обделался. Нужно спасать.

Нет, это просто обычный эникей, который насмотрелся всякой пропаганды в интернете. Что, где и зачем - он не знает. Он даже не знает что это. Но он слышался, что это круто. Поэтому и видно риторику уровня «serious business» и «где-то там».

Ага, брызгай жиром дальше (:

Ога, попытался спорить. Сел в лужу. Убежал. Типичное поведение раст-адепта.

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

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

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

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

По поводу гц. ГЦ в неком общем виде - это некое неуправляемая работа с памятью в противовес управляемой. В раст-пхп никакого управления памятью нет. Там есть некие костыли, которые позволяют манипулятивно классифицировать себя за «негц». Но это попросту обман обывателя.

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

Зачем ты пытаешься о чём-то говорить, если это не твоё?

Зачем ты снова завел шарманку про самодостаточность, когда в реальности плюсовые проги не запускается без установки плюсового рантайма? По твоей логике и Java-програма самодостаточна, ведь никто не запрещает jar-файлам «использовать либы и прочие зависимости»

чувак, твои коментарии, да и код по ссылке - это один сплошной фейспалм. погугли что-нибудь про с++. и вообще когда читаешь что-то про с++ на хабре или в википедии, то во-первых надо читать всё до конца, а во-вторых надо потом читать документашку по языку, cppreference.com будет хорошим началом.

Спасибо за наставление, конечно. Насмешил.

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

По себе людей не судят.

откуда вообще берутся указатели на char

???

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

Видимо, на Хабре или Википедии об этом ни слова. Почитай Страуструпа.

с++ до вчерашнего дня вообще на глаза попадался

Смешно.

По поводу гц. ГЦ в неком общем виде - это некое неуправляемая работа с памятью в противовес управляемой

Если тебе нравится такое определение, пусть так. Вот только твоя C++-скриптота с умными указателями и прочим RAII, не чекается должным образом компилятором (*листает методичку*). И допустить ошибки при использовании такого «C++ c ГЦ» не сложнее чем malloc/free. Выходит, что старейшины упорно вкорячивают ГЦ в плюсы, просто потому, что оно есть в современных языках?

Хозяйке на заметку: если б эпл не вкидывал бабла в LLVM, он бы так и остался неизвестной поделкой на кафедре университета иллинойса. Эпл юзает clang/LLVM преимущественно для C/ObjC/Swift и избегает плюсов (кстати, почему?). Выходит, тот факт, что LLVM написан на плюсах, есть историческое недоразумение, не более

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

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

Оффтопик:

Нда сколько слов Rust находятся тут. Был бы модером банил бы или снижал скор раст-адептам, которые триггерятся в любом треде про Си++.

Т.е. редкий тред бывает без этого. А это говорит о чём. О том что те кто больше всего говорит, тот меньше всего делает..

В спорах о ЯП так-же. На Си++ пишут, пишут много, пишут код в больших проектах, и будут писать много еще десятилетия вперёд.

А Rust-аманы все это время будут писать про то что какой Си++ плохой и какой хороший Раст, уже даже Мозилла загнётся (как самый крупный проект на Раст) окончательно проиграв небезызвестному движку, но они всеравно будут говорить что это самый лучший язык.

Таков мой прогноз :)

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

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

А что не осталось бы неизвестной поделкой без вливания бабла?

Выходит, тот факт, что LLVM написан на плюсах, есть историческое недоразумение, не более

Не выходит. На ObjC что ли надо было писать?

А java-машину кто написал? Тоже те, кто в «хоть день в жизни работали в мире РЕАЛЬНОГО программирования?». Ведь все живые реализации java-машины тоже на языке С++, либо вообще чистом С написаны.

типы высшего порядка

это шаблоны с параметрами-типами

Кон- и контр- вариативность типов?

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

Линейные и зависимые типы

это шаблоны с параметрами-переменными

Гомотопические типы?

строго говоря, нет, но всё, что вы от них хотите реализуется за счёт перегрузки операторов приведения типа

не хочу тебя огорчать, но JVM написан на с++98 с невидимым налетом 1х. Та самая причина почему оно работает до сих пор.

Ога. Покажешь что-то уровня libclang?

Тебе точно мозг не муляет в голове? libc && libgcc :D Повторяю - шланг унылая поделка школоты.

А называть icc ПТУшным говном - ну мощно, что тут скажешь, сразу видно експерта.

А огорчать-то чем? Я тоже самое и написал. Только без деталей.

Тебе точно мозг не муляет в голове? libc && libgcc :D Повторяю - шланг унылая поделка школоты.

libclang не имеет никакого отношения к libc/libgcc. У них совершенно разное назначение.

А называть icc ПТУшным говном - ну мощно, что тут скажешь, сразу видно експерта.

Типичная картина, когда у птушника методичка потекла.

Я тебе уже объяснял, что а) маздайка не имеет никакого отношения к С/С++. Ты с нею идёшь сходу и надолго. б) это не является рантаймом языка.

По твоей логике и Java-програма самодостаточна, ведь никто не запрещает jar-файлам «использовать либы и прочие зависимости»

Ты слишком туп, что-бы говорить о какой-то логике. Проблема скриптухи не в том, что в ней существуют либы. Проблема в том, что она не существует без либ. С/С++ же без либ существует. С/С++ существует сам по себе. java не существует без С/С++-рантайма. Как и раст, как и любая другая скриптуха.

Если тебе нравится такое определение, пусть так

Это базовое определение.

Вот только твоя C++-скриптота с умными указателями и прочим RAII

Я тебе уже сказал. Ты слишком тупой, что-бы рассуждать о чём-то кроме «как поменять штанишки». Ты не пытаешься даже думать. Пытайся.

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

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

И допустить ошибки при использовании такого «C++ c ГЦ» не сложнее чем malloc/free.

Опять лозунги убогие. Они ничего не стоят. Как напишешь на своём говне хоть что-то, кроме хелвордов и лаб - приходи.

Выходит, что старейшины упорно вкорячивают ГЦ в плюсы, просто потому, что оно есть в современных языках?

Никакого ГЦ нет. Ты опять обосрался. То, что ты там где-то слышал - это ничего не значит. Управление памятью в С++ как было так и осталось полностью управляемым. Всякое raii никоим образом на это не влияет.

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

Он был известен до эпла, к тому же причём тут вообще эпл? Что значит эта ахинея, что из неё следует? На что она отвечает?

Эпл юзает clang/LLVM преимущественно для C/ObjC/Swift

Опять шиза. Свифт там родился недавно и основа llvm - это шланг, который прежде всего С/С++-компилятор.

и избегает плюсов (кстати, почему?).

Да ты явно тупой. Куда избегает, чего избегает. Ты чини методичку — C++ база для llvm. Шланг на 70% состоит логики именно С++-фронта.

Единственное что там в последнее время случилось со шлангом - он плохо развивается. Но то типично для подобного периода.

Выходит, тот факт, что LLVM написан на плюсах, есть историческое недоразумение, не более

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

Как же ты брешешь! Отличная комедия, продолжай! :D

Всё, трепло окончательно сломалось. Пошел попросту рандомныйн абор слов, вместо ответа.

Всё, сишкохолоп вне себя от горящего пердака, уже буквы пропускает.

libclang не имеет никакого отношения к libc/libgcc. У них совершенно разное назначение.

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

У него это изначально не получилось.

FastCGI - legacy, не более.

Весь C++ - legacy, не более...

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

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

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

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

Ой вэй. А чего тогда каждая вторая програмулина на венде не запускается пока я не установлю какой-то Visual C++ Redistributable, а то и не один?

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

вот смотри, есть венда, которая собиралась MSVC. под другие компиляторы она в принципе не предназначена — см. OpenNT, там везде nmake и cl.exe.

если взять например ReactOS, там сама система может собираться не только cl. exe но и gcc.

если взять firefox систему сборки под винду, там реализовали cl.py обёртку, которая выглядит как nmake и cl.exe, но запускает gcc.

(также, как и линакс исторически был gcc-only с gcc-измами в коде. то есть, это не просто Си, это gcc-шный си — а например plan9 это K&R си, более стандартный. в итоге в plan9 есть kencc и 8c/8l компилятор, нативный: зависящий только от lib9 и crt. есть gcc, и ape/posix подсистема (необязательна), и в итоге зависимости от lib9, crt gcc-шный и glibc gcc-шный. можно собрать plan9 ядро gcc-шным компилятором, либо clang-ом а не только kencc — см. например Jehanne OS, где именно это и происходит: средства сборки plan9 отвязали от kencc-only и можно на выбор собирать gcc-шным компилятором (дефолтно) либо clang-ом либо kencc (как в plan9 классическом))

если в юниксах есть интерфейс сисколлов ядра который не зависит от ABI и libc + crt (C runtime, например crt0.o в gcc) + конкретный интерфейс ядро/драйвер в /usr/src/linux , на основе которого генерируется тот же glibc, например при сборке — то есть, интерфейс который зависит от ABI, и gcc-измов в исходниках ядра и glibc; и например в gcc и в clang он (ABI) может быть разный.

то есть, фактически нет единого «linux ABI». вместо этого есть стабильный С ABI между libc и сисколлами (внутри libc). и нестабильный kernel, glibc, gcc/clang/whatevercc ABI между этими тремя.

и при смене мажорной версии glibc, например он может разрушаться. в итоге нужно перекомпилировать мир заново, с новым glibc.

то в венде ему соответствуют несколько вещей:

1. аналог glibc ~это примерно~ msvcrt.dll в юзерленде + crt зависимости вижуал си в ядре.

2. интерфейс сисколлы ~ glibc это интерфейс между msvcrt.dll и ntdll.dll, user32.dll, win32.dll. ntdll.dll это shim, обёртка к NT native kernel API. как правило явно не используется, неявно реализовано в msvcrt.dll

3. интерфейс API: WinAPI или POSIX. библиотеки, например pthreads, winpthreads, win32 threads, и т.п.

4. C рантайм это crt0.o в gcc, msvcrt разных версий в cl.exe.

здесь, WinAPI основной для венды. если не WinAPI вы должны стрядать. если вы хотите POSIX с форками с дешевым COW и сигналы, семафоры — вы должны страдать.

посредством суровой уличной магии (image, process, threads, fibers, ...) авторам WinAPI удалось сделать так, чтобы CreateProcess с 5 аргументами работал быстро. а форк с 0 и exec поверх него  — медленно. сюда же добавить отличия в реализации DLL/Shared objects, mmap и прочее.

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

идеальный 100% вендор лок ин: на обезфорченный и обезсигналенный API в винде, наоборот, на позиксивизмы и gcc-измы — в gcc/glib/linux kernel.

сдаётся, это не по недомыслию. это не баг, это фича. by design такой.

далее, допустим мы хотим gcc в венде. мы можем пойти несколькими путями:

crossgcc, gcc/mingw. работает из-под линакса, компилирует в target toolchain особый: например, crossgcc-w64-x86_64{-gcc,-as,-ld} берём libbfd + binutils, обучаем его генерить PE exe а не ELF. далее собираем кросстулчейн. он работает из-под линакса, умеет собирать в целевой crossgcc-w64-x86_64 тулчейн, который уже PE gcc.exe и сможет запускаться под виндой.

это не так уж просто потому что gcc. в отличие от того же OpenWatcom, kencc, sxc, tcc или например clang. где нормальная кросскомпиляция. тут сам компилятор gcc сильно завязан на POSIX-сивизмы, fork/signal, юниксизмы (configure.sh и пайпы, а не dll и временые или response файлы), gcc-змы (gcc написан под gcc, и если clang одинаково хорошо собирается gcc/cl.exe/clang то gcc хорошо собирается только gcc)

плюс, с libc надо что-то делать. например, заменить glibc на musl или ещё какой.

native windows gcc, cygwin. берём gcc и реализуем POSIX подсистему в рантайме. в итоге у нас запускалка иньектором поверх cygwin1.dll, fork через CreateProcess, signal через WaitForSingleObject/WaitForMultipleObject и т.п.

медленно и печально, потому что нужно как-то отобразить процессы POSIX с fork с дешёвым COW, signal, mmap, pthreads на виндовз аналоги. в рантайме, потому и медленно. зато академически правильно.

native gcc, SUA/Interix: реализуем POSIX подсистему в ядре. процесс psxss.exe запускает PE бинарники специального вида, которые шарят ресурсы с другими подсистемами (Win32 API, OS/2 1.0 console API).

внутри есть особый форк gcc старой версии, хедеры, библиотеки.

удалено из винды свежих версий. хотя раньше был даже дистрибутив Gentoo/Interix.

с точки зрения psxss.exe подсистемы винда выглядит как BSD.

ELF, foreign linux gcc, ... whatever linux ELF binary ..., WSL, Win10. реализован загрузчик ELF файлов немодифицированных линукс бинарников. запускается паравиртуализованное ядро линакса. в последних версиях почти нормальное, обычное ядро линакса, два в одном.

native windows gcc, mingw. берём gcc и жестоко патчим, удаляя юниксизмы и позиксимы, gcc-измы.

получаем Minimal Gcc for Windows, с зависимостями только от WinAPI.

всё ещё зависит от msvcrt.dll, и вот почему.

аффтарам mingw было лень делать полноценный POSIX форк, glibc форк и прочее. сделали минимальный, лишь бы хелловорд с MessageBox запускался.

всякие форки и сигналы там просто не реализованы. хотите — используйте WinAPI аналоги. хотите нитки — используйте виндовые, а не pthreads.

поэтому нужен специальный патченный юзерленд, под mingw, библиотеки. тот же winpthreads, pdcurses или форк, прочее.

в итоге накостылять такой форк gcc проще: можно взять среду сборки gcc, и изначально cl.exe или cl.py из Firefox-а , собирать вижуал студией. потом получить gcc.exe которым уже собирать всё остальное. в итоге получить неявные зависимости от msvcrt.dll и С рантайма вижуал студии.

потом новые версии собирать старыми. с этой унаследованной зависимостью от вижуал с++ и msvcrt.dll.

поэтому если например clang собрать хоть mingw, хоть cl.exe всё равно получим зависимость от msvcrt.dll и MS VC C runtime.

native windows gcc, midipix.org: обсуждение на HN

100% WIN, ящитаю. современный аналог SUA/Interix POSIX подсистемы NT ядра. реализован поверх NT native kernel API, частично не документированном.

действуем по инструкции (либо этой)

0. берём gcc, и muscl вместо glibc. отвязываемся от gcc-змов, POSIX-исмов, юниксизмов в musl. реализуем такой libc на WinAPI.

1. делаем кросстулчейн, запускаемый как ELF бинарники из-под линакса. то есть, если нативный линукс гцц это target вида configure --host=XXX --target=YYY который видно через gcc -dumpmachine например x86_64-w64-mingw32 или x86_64-pc-linux-gnu, то здесь целевой target будет x86_64-nt64-midipix, а исходный host=x86_64-pc-linux-gnu.

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

3. неявная зависимость msvcrt.dll теперь не нужна. интерфейс между ntdll.dll (и далее «сисколлами» виндовз) и libc — это musl, форк под midipix. интерфейс между libc и gcc это C runtime, это crt0.S обычный из gcc/mingw.

4. этот форк musl + реализация в подсистеме POSIX (сам midipix) содержит полноценную реализацию уровня NT ядра (функции Zw*, типа ZwCreateProcess) таких вещей API как форк, exec, сигналы, семафоры, mmap, нитки. pthreads тоже есть полноценная реализация.

5. этот кросстулчейн вполне себе хорошо интегрируется в пакетные менеджеры вроде арча под линакс либо msys2 под выньдовз.

6. если написать на этом gcc ассемблерный хелловорд под винду, и посмотреть его зависимости через ldd, или dependency walker, то можно увидеть минимализм: не зависет ни от чего лишнего (типа неявной зависимости от msvcrt.dll)

7. далее можно портировать под такой musl из midipix например llvm (llvm под musl llvm2)

алсо, заметь. например, компиляторы оберона-2 или модулы под виндовз. там пишется линк-файл для простого хелловорда который явно включает зависимости от user32.dll, win32.dll, ntdll.dll. зависимостей от msvcrt.dll в вариантах там тоже нет и не нужно, ибо линкер оберона-2 или модулы написан на обероне-2 или модуле. он умеет напрямую работать с PE бинарниками нужного вида.

вообще же, каждый может взять себе например keystone. взяли MC framework из LLVM, отвязали от лишних зависимостей

Keystone is much more lightweight than LLVM because we stripped all the subsystems that do not involve in assembler. As a result, Keystone is more than 10 times smaller in size and in memory consumption. Initial verson of Keystone takes only 30 seconds to compile on a laptop, while LLVM needs 15 minutes to build.

работает под все основные ОС. ассемблер в разделяемой библиотеке, хелловорд который ассемблирует INC reg/DEC reg очень простой, прозрачный и понятный, без всякого ненужно.

и ассемблировать себе в бинарник без всякого msvcrtненужно.dll

если же хочется чего-то LLVM-подобного с SSA, то можно взять LLVM с 10500 оптимизациями и проходами, а можно — легковесный QBE, который С, а не ++.

C компилятор, например, проще писать на Myrrdin чем на си пруфлинк. или лисп-компилятор. вполне себе haskell или ocaml-подобный код.

алсо, есть такой «как бы rust» : zig. исходники на zig выглядят сильно похоже на ржавого. тетрис кроссплатформный под все основные платформы, например. или примеры

язык zig

вообще забавная вещь этот zig : хабр интро дока unsafer than unsafe rust

можно брать код на С/C++, и поэтапно переписывать. при этом компилятор zig хавает и код на С тоже, умеет его компилировать. при этом FFI и прочее делаются автомагически через @cImport(@cInclude(«csrc/header.h»)). при этом есть модули, CTFE, дженерики, опциональные типы. при этом есть typeinfo и CTFE рефлексия и интроспекция (макросов правда нет, ну и не особо-то и надо), асинхронность и корутины, прочее. при этом работает кросскомпиляция из коробки в полпинка под все основные платформы одним ключём -t компилятора. при этом есть из коробки тесты, система сборки — рецепты пишутся на build.zig на самом zig вместо makefile с костылями. при этом есть кеширование собранных бинарников. можно взять какой-нибудь код на c/c++ и поэтапно переписывать, при этом язык знает больше чем С

получится нечто раст-подобное, на первый взгляд. но как язык zig проще чем раст — нет лайфтаймов, иммутабельности и прочего, макросов, зависимых типов и прочего. есть дженерики, модульность, прозрачный C FFI, опциональные типы, defer.

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

C компилятор, например, проще писать на Myrrdin чем на си пруфлинк. или лисп-компилятор. вполне себе haskell или ocaml-подобный код.

впрочем, если взять все эти лиспы, транслируемые в си(на си) либо ml, транслирумый в си (тоже на си), или этот myrdin(ЕМНИП, тоже на Си, с QBE вместо LLVM в качестве бекенда, одного из). и поэтапно переписывать этот си на zig.

получим всё то же самое, но более технологично: кроссплатформенность везде одним ключом, прозрачный C FFI, прозрачные модули, готовую std библиотеку и прочее.

DOS, лучший чем DOS!

C, лучший чем С.

раст, лучший чем раст. если лайфтаймы не нужны!1111

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

Без ADT ненужно.

Выходит, тот факт, что LLVM написан на плюсах, есть историческое недоразумение, не более

ну да. вот например XDS, компилятор модулы и оберона-2. был тоже SSA, при этом на низкоуровневой модуле был написан GC и прочий рантайм для оберона. внутри SSA представление, си-подобный (модула-подобный) интерфейс к нему, кодогенератор из SSA.

или например QBE по ссылке выше. тоже SSA представление, при этом реализовано на С, а не на плюсах. в чём-то проще чем LLVM.

или например AmigaAnywhere/AmigaDE/ElateOS/TaoOS: AmigaDE Tao OS FAQ appsset Elate/TaoOS

предлагался кроссплатформный вариант AmigaOS, работающий как виртуальная ОС, поверх любой нативной ос (Win/Lin), в её среде (аналогично Inferno из Plan9).

в основе — идея виртуального процессора VP, у которого бесконечное число регистров, и на который относительно просто отображается любой реальный ассемблер (привет, SSA-представление биткода в LLVM).

это ещё не полноценный SSA. собственно, суть Elate/intent, Tao OS, AmigaDE/AmigaAnywhere была не в SSA представлении, удобном для оптимизации и написания компилятора вообще. суть в том, что придумывается виртуальный процессор и его виртуальный ассемблер (на который легко и просто отображается любой реальный распространённый, ну разве что кроме лисп-машин и стековых форт-ява-процессоров

суть в том, что на таком кроссплатформном ассемблере далее пишутся библиотеки, рантайм среда, GUI, мультимедиа. и получаем очень быструю ОС по принципам микроядра. аналогичную по целям Dis из Inferno, или, прости-господи, стековой JVM встраиваемой.

только гораздо быстрее и компактнее.

это было в районе 1998-2000 годов. интервью с ними было на OSnews, ещё, что-то находится поиском.

потом всё просрали, конечно же.

частично наработки TaoOS/Elate/intent/AmigaDE/AmigaAnywhere вошли в AmigaOS 4.0.

частично всё тупо просрали и похерили. ну и мелкомягкие подосрали опять, примерно как с BeOS.

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

zig: rust для птушников

ну если кто ниасилил ADT, монады, зависимые типы, лайфтаймы и AST макросы — для них есть свой упрощённый недораст, СБИШ.

c zero-cost abstraction в духе няшной сишечки (уж её-то ПТУшники осиливают).

Я тебе уже объяснял, что а) маздайка не имеет никакого отношения к С/С++.

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

почему именно цепепе и вижуал студию любят адепты COM/ATL/WTL/MFC и «таблицы сообщений» нежною любовью? да потому что это шаблоны шаблонов шаблонов шаблонов. трейты по сути реализованы миксинами С++, которые реализованы шаблонами. которые прозрачно, 1:1 отображаются на объектную модель C++ с VTABLE. по сути COM это костыль, в котором из MIDL методы прозрачно отображаются на виртуальные методы в С++ VTABLE (иногда тупо макроснёй как в MFC с таблицами сообщений или ATL).

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

в итоге, 95% выньдовз программистов искренне считает, что программировать под COM и прямойХ, например вообще нивазможна кроме как в вижуал студии.

а не взять в руки mingw и писать COM объекты на С. или вообще на фасме.

дотнет конечно сделал это всё ненужным, но не настолько же. как раз на С++ VTABLE прозрачно отображается объектная модель СOM, на COM — маздайка и прочее.

....вот и выросло поколение, не знакомое с цепепешными масдай-костылями

Кусок мусора, тебя еще не забанили?

[поток оскорблений] ...это не является рантаймом языка

Говоришь как моя бывшая: «Лишь бы ляпнуть, а обоснование потом придумаю. А если не придумаю, то начну истерить и обзываться» А чем это по-твоему является?

[поток оскорблений] ...Проблема в том, что она не существует без либ. С/С++ же без либ существует. С/С++ существует сам по себе

И после этого я по методичке говорю? Ты балаболишь как типичный сектант из тяньши, которого уличили в непорядочности. Оскорбить, выставить оппонента идиотом. А затем сказануть общую, бессмысленную фразу. «C++ существует сам по себе». Ну ****ец ты умный. Всё объяснил. Всё по полочкам разложил. Я у тебя уже вторую страницу добиваюсь, что значит «С++ самодостаточный». А в ответ только оскорбления и общие фразы

[поток оскорблений]

[поток оскорблений]

Я уже тысячи раз на эту тему говорил. Твоя раст-дристня ничего не чекает. Вообще

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

Как напишешь на своём говне хоть что-то, кроме хелвордов и лаб - приходи

Как напишешь на своём говне хоть что-то, кроме хелвордов и лаб - приходи

Управление памятью в С++ как было так и осталось полностью управляемым. Всякое raii никоим образом на это не влияет

Вот тут верю. Пытались вкорячить ГС в плюсы, а вышла невнятная какаха с безопасностью уровня malloc

Он был известен до эпла, к тому же причём тут вообще эпл?

Ну точно. Причем тут эпл. Эпл и LLVM вообще не связаны. Сектант

Свифт там родился недавно и основа llvm - это шланг, который прежде всего С/С++-компилятор

llvm — это C++! Эпл вообще не при чем! Вы всё врёти!

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

Это вершина твоего ораторского искусства. Огромная простыня оскорблений, в которую завернут вопросик «Какая альтернатива плюсам для LLVM?». Отвечаю. Это смотря кто бы его писал. Если бы GNU-тые, то на Сях. Если бы в эпл с нуля писали, то на ObjC. У них вон вся экосистема на ObjC до недавних пор была, и ничего, выжили как-то

Говоришь как моя бывшая: «Лишь бы ляпнуть, а обоснование потом придумаю. А если не придумаю, то начну истерить и обзываться» А чем это по-твоему является?

Рука бывшая? Хотя почему бывшая - настоящая. В любом случае, ты опять обделался и начал нести ахинею.

И после этого я по методичке говорю? Ты балаболишь как типичный сектант из тяньши, которого уличили в непорядочности. Оскорбить, выставить оппонента идиотом. А затем сказануть общую, бессмысленную фразу. «C++ существует сам по себе». Ну ****ец ты умный. Всё объяснил. Всё по полочкам разложил. Я у тебя уже вторую страницу добиваюсь, что значит «С++ самодостаточный». А в ответ только оскорбления и общие фразы

Клоун, побежал показывать где ты там что спрашивал? Ты нёс ахинею, потом обосрался. Если ты не знаешь что такое «самодостаточный», то с чем ты спорил, убоги?

Сообщаю тебе новость, С/С++ является самодостаточным, т.е. он может и существует без каких-либо ихных недоязычков.

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

Маня, ты обязана мне показывать и доказывать, что она чекает. Запомни, клоун, ничего не чекает до тех пор, пока ты не доказал обратное.

Как напишешь на своём говне хоть что-то, кроме хелвордов и лаб - приходи

Маня, ты опять обосрался. Твоя жопа на лоре сидит с того, что написано на С/С++. Этого достаточно.

Вот тут верю. Пытались вкорячить ГС в плюсы, а вышла невнятная какаха с безопасностью уровня malloc

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

Ну точно. Причем тут эпл. Эпл и LLVM вообще не связаны. Сектант

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

llvm — это C++! Эпл вообще не при чем! Вы всё врёти!

А что же это, убогий? Расскажи мне.

Это вершина твоего ораторского искусства. Огромная простыня оскорблений, в которую завернут вопросик «Какая альтернатива плюсам для LLVM?».

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

Внимание вопрос, с чего вдруг птушный мусор решил, что он может что-то там оценивать и о чём-то кукарекать, кроме как о мытье полов? А, убогий?

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

Отвечаю. Это смотря кто бы его писал. Если бы GNU-тые, то на Сях.

Опять обосрался.

Если бы в эпл с нуля писали, то на ObjC. У них вон вся экосистема на ObjC до недавних пор была, и ничего, выжили как-то

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

С/С++ является самодостаточным, т.е. он может и существует без каких-либо ихных недоязычков

То, что это греет тебе душу я уже понял. А кроме этого какие преимущества?

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

ты обязана мне показывать и доказывать, что она чекает

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

Твоя жопа на лоре сидит с того, что написано на С/С++

Моя жопа сидит с того, в чем 6.7% руста, 14% Сей и 28% плюсов.

Этого достаточно

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

Никто никуда никакое гц вставить не пытался. Ты опять обосрался

Напоминаю. ты сам, чтобы в очередной раз отбрехаться, привел свое определение ГЦ «ГЦ в неком общем виде - это некое неуправляемая работа с памятью в противовес управляемой». И мы беседуем принимая во внимание твое определение. смарт-поинтеры, raii — неуправляемая работа с памятью или управляемая?

А шаблоны... А что шаблоны? Отличный дробовик которым регулярно сносят пол-тела, это в реальности.

И вам, конечно же, не составит труда привести примеры оного?

А то на вопросе про парадигмы, поддерживаемые Java, вы как-то тихо слились.

А то на вопросе про парадигмы, поддерживаемые Java, вы как-то тихо слились.

Главная парадигма Джавы - «фабрика фабрики для фабрики фабрики для фабрики фабрики объектов».

Да, надо было на Rust писать, чтобы стильно-модно-молодёжно. C++ уже пора откатываться в сторону и помирать.

Это еще почему?

поржал, спасибо

Ой а что современное? Жабка?

PHPкапец

+1