[20:20:44] <ada_ru> (geniepro) https://www.reddit.com/r/cpp/comments/f47x4o/202002_prague_iso_c_committee_trip_report_c20_is/ https://www.ada-ru.org/files/bot/2020-02-16-x32.jpg
[20:22:05] <ada_ru> (geniepro) https://en.cppreference.com/w/cpp/language/modules
https://en.cppreference.com/w/cpp/concepts
[20:32:42] <ada_ru> (vasil_sd) Интересно, смогут за счет модулей сделать нормальную раздельную компиляцию? И уйти наконец-то от заголовков с этой дебильной семантикой include'ов
[21:00:03] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <Интересно, смогут за…>
Будет компилироваться медленнее, а так да :-)
[21:06:13] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <Будет компилироватьс…>
Посмотрел я семантику модулей - сомнительно мне, что сделают нормальную раздельную компиляцию в обозримом будущем. Модули позволяют просто аккуратнее нарезать приложение на логические куски, но шаблоны и пр никуда не делось.
[21:06:48] <ada_ru> (I_vlxy_I) дык а куда шаблоны то могли деться? инклюды шаблонам ортогональны
[21:07:30] <ada_ru> (I_vlxy_I) инклюды на самом деле абсолютно прекрасны - благодаря им можно абсолютно независимо и в любом порядке собирать единицы компиляции на любых машинах
[21:08:49] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <инклюды на самом дел…>
Ага, поменял в одном инклюдике пару чиселок в теле шаблонной функции и вуаля - пересобирай проект целиком на сто мильёнов строк кода :)
[21:09:33] <ada_ru> (vasil_sd) Шаблоны - это очень большая проблема плюсов. В таком виде обобщённое программирование - это зло
[21:09:53] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <Ага, поменял в одном…>
дык выноси эти чиселки в другие места, в чем проблема то?

будто если в спеке адской константу поменять, то не придется пересобирать всех зависимых от этой спеки
[21:10:54] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <дык выноси эти чисел…>
В Аде это на порядки более грамотно сделано - там реализация не в спеке. И менять чиселки в реализации можно сколько угодно
[21:11:40] <ada_ru> (I_vlxy_I) константы то в спеку запихать можно. и их запихивают таки.
[21:12:02] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <дык выноси эти чисел…>
Во-первых, не всё можно вынести, а во-вторых чтобы шаблоны не портили сборку нужно прилагать существенные усилия и не всегда это возможно.
[21:12:12] <ada_ru> (I_vlxy_I) равно как и определения типов например. поменял тип в спеке - пересобираю 100500 миллионов строк кода
[21:12:45] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <Во-первых, не всё мо…>
в случае константы просто засунь её в модуль другой и всё. пусть будет external символ.
[21:12:56] <ada_ru> (I_vlxy_I) ну не проблема же вообще ни разу
[21:14:10] <ada_ru> (I_vlxy_I) конкретно в gnat спеки сделаны подозрительно похожими на хедеры. я, помню, немного разочаровался в этом деле. а сейчас нет времени снова эксперименты ставить 🙁
[21:15:14] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <ну не проблема же во…>
Это в некоторых частных случаях не проблема. А в целом проблема и ещё какая. В Яндексе более 60 человек сидит в команде, которая практически целиком только и занимается системой сборки, чтобы хоть как-то оно побыстрее было. И небольшие изменения в TString например, которые ни разу не затрагивают её интерфейс, кладут dist-build кластер всерьёз и надолго
[21:16:24] <ada_ru> (I_vlxy_I) zapcc не пробовали? там по умолчанию кеширование инстанцирования шаблонов например
[21:16:59] <ada_ru> (I_vlxy_I) но еще раз - тема интересная, я бы посмотрел что там у Ады с дженериками и пересборкой.
[21:17:15] <ada_ru> (I_vlxy_I) конкретно в GNAT
[21:17:23] <ada_ru> (I_vlxy_I) на практике.
[21:18:01] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <конкретно в gnat спе…>
Да, гнат в этом плане немного мухлюет, но там всё-равно интерфейсная часть дженериков компилится отдельно и вроде как можно не рекомпилить всё, если меняется тело дженерика. Нужно посмотреть детальнее. Но факт в том, что в плюсах этого нет на уровне языка и это приходится как-то обходить в тулах
[21:18:23] <ada_ru> (I_vlxy_I) надо поставить эксперимент там и сям 🙂
[21:18:58] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <zapcc не пробовали? …>
Не пробовал. Но по моему опыту гнат компилит код намного быстрее плюсов.
[21:19:56] <ada_ru> (I_vlxy_I) ну, если у тебя про плюсы опыт из яндекса, а про аду - про личные проекты, то у тебя просто никогда не было возможности увидеть Аду в действии на подобном яндексу проекте.

проблема в сравнении в том, что на Аде просто НЕТ больших проектов.
[21:20:04] <ada_ru> (I_vlxy_I) то есть доступных для изучения
[21:20:29] <ada_ru> (I_vlxy_I) тем более современных крупных проектов
[21:20:38] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <ну, если у тебя про …>
У меня и на плюсах полно pet-projects для сравнения. Но да, выборка не репрезентативная
[21:22:16] <ada_ru> (I_vlxy_I) а так да, скорость сборки - это бывает проблема в больших проектах. когда после минимального изменения в общей компоненте тебе, чтобы увидеть результат, нужно ждать десятки-сотни минут - это такое.
[21:23:41] <ada_ru> (I_vlxy_I) но это не только проблемы плюсов, так то.
[21:26:28] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <но это не только про…>
Ада специально дизайнилась, как язык, чтобы такого не было. Именно за счёт чёткого разделения единиц компиляции на интерфейсную часть и на реализацию.
OCaml тоже по дизайну похож, поэтому многопоточная компиляция фантастически быстра.

А плюсы в этом плане - совсем никакие
[21:30:59] <ada_ru> (vasil_sd) BTW: по поводу generic и гната: "If a file being compiled instantiates a library level generic unit, the object file depends on both the spec and body files for this generic unit.
If a file being compiled instantiates a generic unit defined within a package, the object file depends on the body file for the package as well as the spec file."
То есть, да, тут печаль :(
Но это конкретная реализация такая, сам язык как раз разрабатывался, чтобы такого избегать
[21:31:36] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <Ада специально дизай…>
Камло просто сильно проще и по грамматике и по семантике. Он же вообще repl-ориентирован.

А на тему Ады - я не верю общим рассуждениям и тому, какие там были цели и намерения были при дизайне языка. Важно что имеем сейчас по факту. Что там в gnat
[21:32:03] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <BTW: по поводу gener…>
Гыгы :-)
[21:32:56] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <Гыгы :-)>
В плюсах таких гы-гы и в стандарте полно и в реализациях по сравнению с  :)
[21:33:46] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <Камло просто сильно …>
Насчёт проще - это дискуссионно. Но он намного регулярнее в плане свойств - это да.
[21:33:53] <ada_ru> (I_vlxy_I) По поводу модулей же в плюсах - я опасаюсь, что с введением их в плюсах исчезнет разделение на спецификацию и реализацию модуля. Не для компилятора, а для программиста.

Будет как в расте, go, джаве и так далее.
[21:34:39] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <По поводу модулей же…>
Я пока не совсем понимаю какую задачу они решают, кроме логического разбиения.
[21:34:44] <ada_ru> (I_vlxy_I) И пофигу, по большей части, мне на сложности компилятора
[21:35:12] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <Я пока не совсем пон…>
Проблему дефайнов в первую очередь. Ограничить их зону работы
[21:35:40] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <И пофигу, по большей…>
Ну тут как-бы есть такое, что сложности компилятора в конечном итоге склонны прорастать так или иначе в сложности разработчиков :)
[21:37:09] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <Проблему дефайнов в …>
сишные дейфаны? Это вообще зло, которое не нужно было в плюсы тащить. Сама идея препроцессора и реализация в сишнике и плюсах - очень сомнительная вещь.
[21:39:31] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <Ну тут как-бы есть т…>
Как разработчик я прежде всего код не пишу, и не компилирую, а читаю. Без разделения на хедеры и цпп, мне читать это сложно будет. Когда все всегда будет свалено в одном файле, как в расте, го и так далее
[21:40:15] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <сишные дейфаны? Это …>
Вот с ними и борются, но не тащить - не вариант по очевидным причинам
[21:42:03] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <Как разработчик я пр…>
Ну, когда в проекте много обобщенного кода, то так и получается - почти весь код в заголовках ;) В Яндексе такое сплошь и рядом было, ибо там много народа любит свои обобщённые велосипеды изобретать, вместо того, чтобы нормально архитектуру продумывать (что в итоге выливается в обобщённые костыли в будущем:) )
[21:43:33] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <Вот с ними и борются…>
До сих пор не могу понять, зачем при наличии механизма совместимости по ABI "extern "C"" нужно сишные атавизмы тащить в плюсы.
Ну оставьте вы легаси код как сишный, а новый пишите нормально в рамках нормальных плюсов.
[21:44:48] <ada_ru> (vasil_sd) Всё-равно же в плюсах ломают периодически обратную совместимость. Значит это не настолько приоритетно.
[21:46:35] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <Ну, когда в проекте …>
Да, шаблоны тут - особая боль. В 98 плюсах у них было разделение на реализацию и спецификацию, но реализовать на практике это осилил только один компилятор, поэтому в 11 плюсах это выпилили
[21:48:49] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <До сих пор не могу п…>
В публичный API сишечка часто выставляет не функцию, а макрос. Например см POSIX. Поэтому без Си-макросов в С++ никак
[21:49:40] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <Да, шаблоны тут - ос…>
Да, плюсы в этом плане странно развивались. На момент их выхода уже был накоплен приличный опыт обобщённого программирования и поддержки его в компиляторах. Но почему-то в плюсах сделали это особенно извращённо и так, что теперь непонятно куда от этого спрятаться
[21:50:30] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <Да, плюсы в этом пла…>
Это и сила и боль :-) свой, особый путь :-) по сути шаблоны - это макросы. Только Аля лисп
[21:50:33] <ada_ru> (I_vlxy_I) А не Си
[21:50:37] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <В публичный API сише…>
А зачем в плюсы тащить позиксовские макросы? Делать нормальные обёртки и тащить в плюсы как extern символы
[21:51:02] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <Это и сила и боль :-…>
Э нет. Не нужно пятнать лисп таким сравнением :)
[21:53:32] <ada_ru> (vasil_sd) Вот кстати, если бы сделали как в лисп - возможно и лучше было бы. Но скорее всего с синтаксисом тут не удалось бы совладать.
Да и идеология лиспа совсем другая.
[21:57:08] <ada_ru> (I_vlxy_I) Тут же не в синтаксисе дело, а в том, что такое шаблон есть - шаблон это не код. Кодом ему только предстоит стать. Соответственно его не скомпилировать заранее в бинарь
[21:57:38] <ada_ru> (I_vlxy_I) При инстанцировании он может превратиться вообще во что угодно
[21:58:00] <ada_ru> (I_vlxy_I) И пофигу на хедеры, инклюды и синтаксис.
[21:58:29] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <Тут же не в синтакси…>
Так в плюсах это далеко не шаблон. Это больше мне напоминает унифицируемую структуру, частично вычисляемую, из которой потом в итоге что-то может развернуться в код.
[21:59:22] <ada_ru> (vasil_sd)  отвечает (vasil_sd) на <Так в плюсах это дал…>
И инстанциация шаблонов очень похожа на унификацию в движках вывода.
[22:00:07] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <При инстанцировании …>
Ага, sfinae и пр.

И потом эту магию нормально отлаживать - это ещё то развлечение :)
[22:04:41] <ada_ru> (vasil_sd) В общем, по моему личному мнению, плюсы для больших проектов плохо применимы, ибо нужно очень много ограничений на использование языковых средств и много дисциплины в разработке, чтобы потом проект был более-менее поддерживаемым. А это дорого.
Ада в этом плане намного дешевле.
Странно, что бизнес до сих пор активно с плюсов не слезает. Видимо замкнутый круг в плане плюсовых разработчиков. И получается как с мышами и кактусом.
[22:07:25] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <В общем, по моему ли…>
как мы видели выше - у Адских дженериков НА ПРАКТИКЕ, те же проблемы с перекомпиляцией.
[22:11:00] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <как мы видели выше -…>
Да, но это не самая большая проблема. У плюсов проблема с тем, что шаблоны часто используются программистами для мета-магии и сложных вычислений в compile-time, и это потом поддерживать - большая головная боль.

Нужно постоянно следить, чтобы вот такого https://github.com/vasil-sd/cpp_rpc/blob/master/meta/conv.h#L18 не просачивалось в продакшн :)
[22:11:48] <ada_ru> (I_vlxy_I) а в других языках фигачат внешний кодогенератор на кодогенераторе который использует еще один кодогенератор на перле
[22:11:52] <ada_ru> (I_vlxy_I) ну нафиг
[22:12:49] <ada_ru> (I_vlxy_I) ну и да, возможность проверить всякое на этапе компиляции таки дорогого стоит
[22:12:58] <ada_ru> (I_vlxy_I) но надо знать меру, это правда.
[22:14:33] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <а в других языках фи…>
Ну в окамле это решили весьма неплохо. А так да, внешний кодогенератор. Но его-то как раз можно делать специализированным под задачу, чтобы DSL синтаксис легко было читать и поддерживать. В Яндексе, кстати, этих кодогенераторов тоже навелосипедили всяких будь здоров. Так что тьюринг-полные шаблоны задачу получается не смогли решить нормально :)
[22:15:16] <ada_ru> (I_vlxy_I) ты представляешь какое лютое говнище будет этот кодогенератор? хорошо если его на PHP напишут
[22:15:23] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <ну и да, возможность…>
Ага, нмпример так: https://github.com/vasil-sd/cpp_restart_case/blob/master/restart_case.h#L74 :)))

это у меня иногда бывает настроение поизвращаться над плюсами и компиляторами... :)
[22:16:11] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <Ага, нмпример так: h…>
неплохо! надо будет в проде применить
[22:16:15] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <ты представляешь как…>
Так я выше написал, что пишут для плюсов и много их пишут. И да, часто лютое говнище, ибо не задумываются над тем, что и как пишут
[22:16:28] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <неплохо! надо будет …>
Кхм... Ну-ну :)
[22:16:30] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <Так я выше написал, …>
так писали бы еще больше
[23:14:51] <ada_ru> (Максим) Wasm! http://hds.ada-ru.org/nails/index.html
[23:16:28] <ada_ru> (vasil_sd)  отвечает (Максим) на <Wasm! http://hds.ada…>
Обязательно нужны картинки гвоздей :)
[23:23:59] <ada_ru> (I_vlxy_I)  отвечает (vasil_sd) на <Обязательно нужны ка…>
3д! с анимацией того, как он будет с годами трансформироваться
[23:25:06] <ada_ru> (vasil_sd)  отвечает (I_vlxy_I) на <3д! с анимацией того…>
Ада в WebGL уже умеет, так что тут не так много усилий нужно :)