LINUX.ORG.RU

Zig 0.8

 , ,


2

5

После 7 месяцев работы и 2711 коммитов вышла новая версия Zig: 0.8

Zig это:

  • Современный компилятор С

  • Современный компилятор С++

  • Компилятор языка Zig

  • Сборочная система для C, C++, языка Zig

  • (Планируется) Пакетный менеджер для С, C++, языка Zig

Zig разрабатывается под лицензией MIT: https://github.com/ziglang/zig/blob/master/LICENSE

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

Небольшая заметка, которая пытается объяснить зачем нужен Zig, когда уже есть C++, D, и Rust: https://ziglang.org/learn/why_zig_rust_d_cpp/

Даже если вам не интересен язык Zig, возможно вам будет интересен Zig как кросскомпилятор С или С++.

#include <iostream>
int main() {
    std::cout << "Hello World!\n";
    return 0;
}
$ zig c++ -o hello hello.cpp -target riscv64-linux
$ qemu-riscv64 ./hello
Hello World!

Ещё про использование zig как кросскомпилятора: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html

В новой версии:

  1. Обновление LLVM до LLVM 12.

  2. Поддержка arm64 macOS (aka the Apple Silicon) и также поддержка кросскомпиляции C, C++, и Zig в arm64 и x86_64 macOS.

  3. Zig также разрушает миф, что вам нужен Mac и Xcode для компиляции кода для Mac OS. Заголовочные С файлы Apple выложены под Apple Public Source License которая разрешительная.

Так что вы можете собирать бинарники для Apple из-под Linux/Windows/FreeBSD без XCode:

#include <iostream>

int main() {
   std::cout << "Hello World!\n";
}
$ zig c++ main.cpp -o test -target x86_64-macos
$ file test
test: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>

Подробнее: https://ziglang.org/download/0.8.0/release-notes.html#macOS-Support

и

https://github.com/ziglang/fetch-them-macos-headers

  1. Добавлена поддержка WASI libc

  2. Начальная поддержка Haiku

  3. Изменения в языке: https://ziglang.org/download/0.8.0/release-notes.html#Language-Changes

  4. Изменения в стандартной библиотеке: https://ziglang.org/download/0.8.0/release-notes.html#Standard-Library

  5. Zig поддерживает Position Independent Executables, даже когда компилируются статические бинарники

  6. Изменения в сборочной системе: https://ziglang.org/download/0.8.0/release-notes.html#Zig-Build-System

  7. Обновление musl до 1.2.2, mingw-w64 до 9.0.0, возможность нацеливания glibc 2.33

Полный список изменений: https://ziglang.org/download/0.8.0/release-notes.html

>>> Официальный сайт

★★★★★

Проверено: Satori ()
Последнее исправление: xaizek (всего исправлений: 6)

Ответ на: комментарий от aist1

В Rust приходят плюсовики и начинают просить фичи, к которым они привыкли.

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

И, рано или поздно, они своего добьются.

Ставишь на то, что и «полноценное ООП» завезут? (:

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

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

Посмотрим помогут ли расту редакции поддерживать фичи согласованными.

Я в данном вопросе солидарен с мнением, что если, образно говоря, «гнаться за фичами С++», то в итоге: (а) получится «недо-С++», но такой же несогласованный, (б) будет убито время и (с) — отсутсвовать совместимость с кодовой базой С++. Поэтому я, например, предпочитаю использовать С++ как хост-язык и обвешивать его eDSL-ями, кодогенераторами и анализаторами, специфичными для приложения. Это, разумеется, не так удобно, как если бы это всё было «из коробки». Но мне ехать надо, а не шашечки.

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

Моё мнение, что лучше С++ обвешивать современным тулингом. Хотя в этом смыле проекты типа Rust и Zig очень полезны, потому что дают представление о том, как эти все продвинутые идеи работают.

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

Я в данном вопросе солидарен с мнением, что если, образно говоря, «гнаться за фичами С++», то в итоге: (а) получится «недо-С++», но такой же несогласованный, (б) будет убито время и (с) — отсутсвовать совместимость с кодовой базой С++.

Не обязательно гнаться за фичами С++, скажем вместо HKT (что, кстати, сложно назвать фичей С++), если я ничего не пропустил, будут GAT (generic associated type), которые дают похожие возможности. Я к тому, что язык вполне может идти своим путём, ну и пока редакции вполне помогали сгладить всякие мелочи. Сомнения есть относительно того помогут ли они при более значительных изменениях.

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

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

Моё мнение, что лучше С++ обвешивать современным тулингом.

Ну а я четыре года как парешёл на раст. Пока доволен.

DarkEld3r ★★★★★
()
Последнее исправление: DarkEld3r (всего исправлений: 1)
Ответ на: комментарий от aist1

Нужно больше и можно больше, но нужно полноценное мапрограммирование, а не вот это вот всё.

Полноценное макропрограммирование много раз переизобреталось, лисп, форт, немерле, но так и не взлетело в массовом программировании. Тот же немерле, если отбросить платформу не реализует ли большую часть твоих мечт?

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

Тот же немерле, если отбросить платформу не реализует ли большую часть твоих мечт?

Мои мЕчты — полноценное метапрограммирование в низкоуровневом продакшн-языке (площадке для использования), а не в виде академического эксперимента. Это все потому, что у меня есть конкретные задачи, которым это метапрограммирование нужно.

Всё дело в них, в задачах. И в пересечении прагматики использования языка с классом задач, которым продвинутое метапрограммирование надо. С++ сейчас «в пузыре». Так как там нет нормального метапрограммирования, он и не используется там, где оно надо. А так как он не используется там, где оно надо, что его и не спешат внедрять — спроса нет.

У меня как раз такая задача есть. Я всё это не голословно утверждаю.

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

Не обязательно гнаться за фичами С++, скажем вместо HKT (что, кстати, сложно назвать фичей С++), если я ничего не пропустил, будут GAT (generic associated type),

Да, я согласен. Можно идти разными путями. Я тут немного про другое...

Вот есть, скажем, Golang, и есть C++. И есть Rust как «что-то между» ними. Парадигмально очень разные языки, в целом, нацеливающиеся на одну и ту же нишу.

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

Вилка в том, что если сделать язык простым изначально, как golang, mere people будут довольны, а эксперты начнут фыркать. Сделаешь язык для экспертов — отпугнешь mere people, которые и двигают-то внедрение языка. Сделаешь язык сначала простым, а потом начнешь его усложнять — поломаешь философию. Сделаешь язык изначально мощным, а потом начнешь упрощать — ничего не получится :)

Rust пытается быть золотой серединой, и это было бы отлично при статичных альтернативах. А так как и Golang, и C++ развиваются, Rust-у тоже придется «дергаться», чтобы сохранить актуальность в условиях, когда для него еще пока не наработана достаточная кодовая база. Это — жестокий мир.

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

Rust пытается быть золотой серединой

Как-то не похоже что пытается, он с самого своего релиза гораздо на порядки ближе к C++ чем к Go.

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

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

Мне кажется, что «поломка философии» будет только если язык позиционируется именно как простой. Но из таких («современных») только Go, потому и интересно, что с ним будет дальше. А большинство языков не простые и не экспертные, а скорее «средние». Опять же, когда выходит новый стандарт/релиз, то средние разработчики уже освоили предыдущий и надо разобраться не с таким уж большим количеством новых идей. А уж если человек старается быть в курсе, то тем более: фичи не падают с неба, они долго обсуждаются, пишутся статьи и реализуются в библиотеках (если возможно). Новичкам сложнее - это да, хотя даже в С++, который небезосновательно принято считать сложным, многие новые возможности облегчают жизнь и заменяют старые.

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

Rust пытается быть золотой серединой

Мне кажется, что у раста акцент на другом. Язык не позиционируется как «упрощённый С++», а как «безопасный системный язык». Во многих моментах раст не быть неявным (и тут тоже можно поспорить насколько удачно), но явность - это совсем не простота.

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

С C++ трудность в том, что каждое мажорное поколение это уже парадигмально совсем другой язык. С++11 принес rvalue refs, variadic templates и closures, что существенно изменило дизайн API и библиотек. С++14 это дело закрепил с выводом типов, откинув С++03 куда-то, если не на уровень С, то близко к... С++17 погоды не делал, а вот С++20 всё опять меняет радикально с концептами, модулями и корутинами. Пойдет ползучая корутинизация всего, так как высокопроизводительный ввод-вывод без них сейчас не заведется.

Т.е. плюсовику сейчас не позавидуешь. Раз в 5 лет полностью менять прошивку в голове, когда тебе 40+ — это жестоко. С Java не так. Язык там не так сильно меняется, и парадигмально всё тот же Java 8, с еще большим количеством батареек в комплекте. Да, вывод типов завезли, т.е. можно теперь писать более сложный обобщенный код без избыточного синтаксического шума. Там больше радикальных изменений в области GraalVM и межъязыковой интеграции, что таки меняет парадигму в некоторых областях: eDSL-и можно, наконец, делать весьма эффективно.

А Rust, да. Не совсем правильно помещать его между Go и С++, потому что основные цели у него отличаются от С++. Там выше анонимус сказал, что по фичам он на много ближе к С++, чем к Go (что есть истинно так). Но вот по целям (безопасный системный язык) он на много ближе к Go, чем к С++.

И, да, всё верно. Он не пытается быть простым, он пытается остаться безопасным, вбирая в себя всё новые и новые фичи.

А вообще, как профессиональный Java-программист, я бы сказал, что Java будет посложнее С++. Так как надо учитывать еще и платформу, которая сейчас у Java очень сложна. Ну и, конечно же, «выскопроизводительная Java» — это что-то с чем-то. Нужно очень хорошо понимать, как работает JVM, чтобы знать, когда она какие оптимизации способна применять (например, Inline cache для девиртуализации, что у меня давало до +40% к производительности). Парадигмально, Java в этом плане стала на много ближе к С++, который то по сути система легковесных абстракций над оптимизирующим компилятором.

И я молчу, что ручное использование sun.misc.Unsafe — это один сплошной UB.

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

Мне кажется, что «поломка философии» будет только если язык позиционируется именно как простой. Но из таких («современных») только Go, потому и интересно, что с ним будет дальше.

Ещё 1С. От бейсика с объектами доступа к БД развилось в мегамонстра с многослойными абстракциями и многопоточным выполнением.

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

Только это и спасает. Хотя знаю достаточно много 1С-ников, которые из-за развития языка забросили программирование и ушли в консультирование/администрирование.

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

Т.е. плюсовику сейчас не позавидуешь.

Ну не знаю: я пока на плюсах писал (С++14 ещё застал), то нововведениям только радовался. А если человек устал от гонки технологий, то он зря в айти пошёл хватает и консервативных плюсовых проектов, где и шаблонов по минимуму - есть где досидеть до пенсии.

С Java не так. Язык там не так сильно меняется, и парадигмально всё тот же Java 8, с еще большим количеством батареек в комплекте.

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

Но вот по целям (безопасный системный язык) он на много ближе к Go, чем к С++.

Не уверен, что у Go именно такая цель. (:

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

Хотя знаю достаточно много 1С-ников, которые из-за развития языка забросили программирование и ушли в консультирование/администрирование.

Занятно. (:

Может ли дело быть в том, что 1С специфических разработчиков привлекает? Ну типа хорошо платят, пусть и в ущерб «интересным задачам». Хотя я вообще не в теме этой области и не понимаю, что там происходит. Может там как раз интересно?

Кстати, бейсик (который для дотнета) тоже, вроде как, стал не таким уж простым.

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

Может ли дело быть в том, что 1С специфических разработчиков привлекает? Ну типа хорошо платят, пусть и в ущерб «интересным задачам». Хотя я вообще не в теме этой области и не понимаю, что там происходит. Может там как раз интересно?

Тут два нюанса. Во-первых, приходится сильно изучать предметную область: в результате появляется лёгкая возможно смигрировать в консультанта без потери зарплаты (или, если хочется рисковать, то сходить на курсы и стать главбухом). Во-вторых, изначально 1С рекламировала свой язык как лёгкий для обучения (и он реально таким был).

Примерная аналогия: представь себе, что в очередной версии Linux решили улучшить bash: добавили async, поддержку XML и JSON, HTTP, … и переписали все скрипты запуска на этом новом диалекте и по канонам ООП через фабрики, менеджеры и прочее с ассоциативными массивами или чём-то вроде https://bolknote.ru/all/3848/ вместо классов и объектов. Много админов Linux согласятся такое программировать? Или уйдут в администрирование Cisco/почты/веба./…?

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 2)
Ответ на: комментарий от aist1

У меня как раз такая задача есть.

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

EDIT: а, нет, нашел подробный Overview

З.Ы. там в Overview пара опечаток в первой строке, `usilizing` => `utilizing`, `consistes from` => `consists of`

yetanother ★★
()
Последнее исправление: yetanother (всего исправлений: 1)
Ответ на: комментарий от monk

Гы, и получили Python :)

Нет, от этого они не уйдут из профессии. Python как инструментальный язык очень широко используется.

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

Нет, от этого они не уйдут из профессии. Python как инструментальный язык очень широко используется.

И на нём пишут те же люди, который раньше писали только на bash/awk/sed ? Я не говорю, что язык плох. Новый 1С тоже для крупных программ лучше старого (и количество строк в программах выросло в 20 раз по сравнению с временами 1С 7.7). Но его надо изучать и он сложнее.

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

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

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

Я сейчас там делаю кодогенератор (python + clang), который бы заменил тяжелое TMP. Если всё пойдет нормально, то где-то к концу лета можно будет посмотреть, как именно метапрограммирование помогает в разработке структур данных. А вот это будет практической задачей.

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

А вот это будет практической задачей.

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

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

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

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

  • Event-driven computations. Мы это уже широко используем под разным «соусом»: Flux/Redux.
  • Интеграция инструментов clang, таких как его чекеры/санитайзеры, а так же language server в потоковый API.
  • Поддержка метапрограммирования.

С последним нужно пояснить. С точки зрения компилятора и системы сборки, метапрограммирование — это серия трансформаций программы. И вот в случае того же C++ TMP, эти трансформации полностью непрозрачны. Нельзя просто взять, и дампануть состояние инстанцирования конкретных шаблонов в конкретном месте. Нельзя сделать точку остановки и пройтись дебаггером (хотя проекты такие есть). Но я лично считаю, что шаблоны — не для (мета)программирования, и тут нужно переходить к обычному императивному стилю программирования уровня типов. Разговоры (и не только) об этом в сообществе тоже есть.

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

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

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

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

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

Практическая разница с тем же make в том, что последнему, чтобы определить дельту изменений, нужно просканировать весь проект. У меня быстрый ninja на сборке Clang «думает» несколько секунд перед тем, как начать сборку. Прочитать и разрулить временные метки тысяч файлов — это не шутки. Короче, это O(N), тогда как change log — это O(1) на определение того, что изменилось.

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

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

опять эти удивительные истории о C++… Новые фичи изучаются по мере необходимости. А легаси код со времен до C++11/14/… как работал, так и работает, с минимаными модификациями.

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

Ну, вот, представь себе, ты — 40+ программист с красавицей-женой, двумя спиногрызами, ипотекой, и хорошая жизнь состоялась. И тут все молодые программисты вокруг начинают бодро оконцептовывать и модуляризировать код, вовсю использовать constexpr-метапрограммирование и функциональные техники (а-ля Boost Hana). А ты не без труда переполз на C++11, а из С++14 используешь только auto. Потому что во времена, когда ты формировался профессионально, TMP был вообще не рекомендованной технологией (вместе с исключениями и множественным наследованием). И ты такой говоришь всем, что ты специалист по высокопроизводительным вычислениям, потому что это последняя ниша, где все эти навороты языка не нужны, а нужно знать, как на UB не нарваться, выжимая из оптимизатора производительность по-максимуму.

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

Новые фичи изучаются по мере необходимости.

Даже не знаю …
Новый API?

Предпочитаю не ждать у моря погоды ...
anonymous
()
Ответ на: комментарий от aist1

Потому что во времена, когда ты формировался профессионально, TMP был вообще не рекомендованной технологией

Оно и сейчас не так, чтобы все пространство фич заполняет, и многие утилиты, которые на плюсах удобнее писать, TMP не требуют (м.б. как-то косвенно через std, но прикладник этого не видит).

вместе с исключениями и множественным наследованием

воу, полегче. Это когда все это было «не рекомендовано», в каком году и в какой отрасли?

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

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

seiken ★★★★★
()
Последнее исправление: seiken (всего исправлений: 1)
Ответ на: комментарий от aist1

представь себе, ты — 40+ программист с красавицей-женой, двумя спиногрызами, ипотекой, и хорошая жизнь состоялась

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

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

воу, полегче. Это когда все это было «не рекомендовано», в каком году и в какой отрасли?

Видимо, я уже стал стар. В мои молодые годы было нерекомендовано. Модным был вообще C/C++. Т.е. когда ты пишешь на С++, но используешь только необходимый минимум его абстракций. Ссылки искать лень.

нужны какие-то основания, чтобы так говорить.

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

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

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

aist1 ★★★
()

Почитал «Язык программирования Картарика.» /и не много попостил/.

Имеется много способ обеспечения написания кода в национальной кодировке.
Microsoft для C++ показала один из вариантов решения этого вопроса.

Но

кипит наш разум возмущенный  

многие хотят в коде использовать название управляющих операторов на языке «Картарика».

Имеется много методов решения этой «хотелки».
Приведу один из способов.

Для этого нужно доработать какой-нибудь редактор исходных текстов программ.
Что именно?

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

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

 - ...

 Все пункты расписывать не буду.  
 Суть сказал.

И все!

Ребята, вы споритесь по десять страниц, а лучше бы предлагали способы решения этой задачи

Привел всего лишь один из множества способов решения этого вопроса.

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

Ахаха, ржака.

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

Ладно, по началу это всё казалось запредельным в плане сложности, поэтому реализовали только самый-самый минимум функционала. Потом подумали, что переборщили, и в С++14 сняли часть наиболее идиотских ограничений. Потом поняли, что и TMP — это тупик, и метапрограммирование должно идти по пути function-style. И тут бы снимать ограничения с constexpr дальше, но кто-то очень влиятельный застращал всех ужасным UB, поэтому решили, что в constexpr не должно быть UB. И теперь думают, как позволить constexpr-функциям выделять динамическую память, но чтобы без UB.

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

Короче, мы имеем ситуацию, похожую на ту, которая в свое время сложилась с шаблонами. Шаблоны не дизайнились для метапрограммирования, но стали использоваться и постепенно обрастать фичами. Но так и остались трясиной Тьюринга. Constexpr тоже, по всей видимости, не дизайнился изначально для метапрограммирования, а просто для более гибкого пред-вычисления констант. И теперь эту, весьма ограниченную изначально подсистему языка, пытаются раздуть, накачивая фичами. Вместо того, чтобы просто сразу добавить полноценные метафункции. Мол, кому надо дорого и сердито — пользуйтесь метафункциями. А constexpr оставьте в покое.

В результате, мы сейчас имеет три очень разные подсистемы для метапрограммирования в С++: TMP, constexpr и метафункции. Последние — в сторонних форках компиляторов.

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

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

Язык программирования Картарика. (комментарий)
Основная проблема — ломаются все инструменты работы с текстом. От просмотра на гитхабе до текстовых редакторов.

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

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

НЕ ХОЧЕТ

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

@den73 вы сказали, что сатана есть

и вы ПРАВЫ
'''   
но   

БОГ тоже есть


Мир полон зла не от того, что в этом виноват БОГ ...





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