Для тех, кто не в курсе в чём эпохальность данного события: так уж сложилось, что механизм использовани компонентов в программах на С++ придумывался где-то лет 35 назад. Его нельзя назвать удобным: если вы хотите создать библиотеку — вам нужно сделать заголовочный файл и распространять с ним либо код, либо скомпилированную версию библиотеки. При этом возникает куча проблем:
- Заголовочный файл и библиотека — отдельные файлы, один из них может потеряться, либо они случайно могут рассинхронизироваться.
- Заголовочный файл включается в код директивой препроцессора #include, что во-первых, замедляет компиляцию, а во-вторых добавляет влияние всего, что написано в заголовочных файлах друг на друга и на конечный код. Нередки случаи, когда заголовочные файлы нужно включать в определенном порядке или определять некоторые макросы чтобы код нормально собрался.
В итоге в инфраструктуре С++ отсутствуют понятия «сборок» или «пакетов» и, в отличии от С# или Python, где установка компонентов тривиальна, в С++ подключение каждой новой библиотеки может нести свои неожиданности. Предлагаемый механизм модулей в С++ призван убрать данную проблему, отказаться от директивы препроцессора #include и ссылаться на компоненты, как на некоторую сущность, состоящую из кода и метаданных, целостную и легко подключаемую. В итоге мы вскоре можем получить существенное ускорение внедрения новых компонентов в проект, появления полноценных менеджеров пакетов, установка новой библиотеки сведется к выполнению одной строки или нескольким кликам мышью. Это ли не счастье!
Под катом будут примеры использования и ссылки на документацию.
Видео презентации пока что не доступно на канале конференции, так что всё, что у нас есть — несколько фотографий из твиттера, да ссылки на предлагаемый драфт стандарта модулей и его реализации в Visual C++ и Clang.
Комментарии (59)
poxu
26.09.2015 18:25+36Боже мой! Это как? Это что же теперь, любой java программист, который чем статистическая библиотека от динамической отличается не знает, на С++ безболезненно писать сможет? Это получается теперь, пока код собирается, даже на мечах толком не порубишься?
AndersonDunai
28.09.2015 00:17+2As requested:
Скрытый текст
VioletGiraffe
26.09.2015 18:26+11OMG, модули будут стандартизированы? Лучше поздно, чем никогда! С++ укрепляется в качестве лучшего кросс-платформенного компилируемого ЯП!
Scratch
26.09.2015 19:14+2Да, это будет сильный удар по Go\Rust, понизится входной порог в плюсы. Милота!
clogic
26.09.2015 19:53-14Какой ужас! Эти люди делают из C++ очередной Rust или D… Но зачем?
mezastel
28.09.2015 06:32+5Сама идея того что в один файл на 10К инклюдится еще 150Мб сорцов для компиляции это не нормально.
clogic
28.09.2015 07:31-4Каждый инструмент создается под свою задачу. Если для вас данное поведение не нормально — есть множество альтернатив. А прикручивать скотчем к молотку лазерный прицел после того как прошло 30 лет и называть его все тем же молотком — глупость.
poxu
28.09.2015 10:42-1Что любопытно — так устроена компиляция программ на go. Даже стандартная библиотека каждый раз собирается заново.
NeoCode
26.09.2015 19:56+3Не прошло и 35 лет:)
Но лучше поздно чем никогда. Наконец-то этот ад под названием include станет постепенно исчезать.
Конечно еще придется подождать пока основные библиотеки (boost, qt и т.п.) перейдут на модули. Но думаю как только msvc, gcc и clang поддержат — так сразу и перейдут.
Еще бы рефлексию нормальную и метапрограммирование человеческое, а не на шаблонах.
semenyakinVS
27.09.2015 01:09Еще бы рефлексию нормальную и метапрограммирование человеческое, а не на шаблонах
Как по мне, это дело решается доступом к AST через специальный исполняемый в compile-time язык. Вот тут Эрик Ниблер такую тему задвигал (можно найти по фразе «Я бы предпочёл на его месте основанный на AST чистый макропроцессор»; кстати, там же была дискуссия по поводу разбора плюсвого кода сторонними средствами — например, clang-ом).
Кстати, от знакмого узнал (тут посмотрел) что есть такой язык nim. В нём можно писать своим оптимизаторы компиляции (по ссылке — раздел «Добавляем свои оптимизации в компилятор»). Вот что-то вроде такой концепции, только, естественно, намного более навороченной нужно для плюсов, как по мне. Чтобы именно доступ к AST был.NeoCode
27.09.2015 14:58-6Ну да, именно это я и имею в виду. Синтаксические (а не лексические как в плюсах) макросы, доступ к AST. В качестве языка метапрограммирования можно использовать любой достаточно распространенный скриптовый язык, например javascript.
khim
27.09.2015 23:40+3Большего бреда, чем использования JavaScript'а для метапрограммирования и представить себе сложно. Метапрограммирование должно происходить на том же языке, что и «нормальное» программирование! Что шаблоны, что JavaScript — всё будет неудобно кому-то.
NeoCode
28.09.2015 09:40-1С указателями и прочими «небезопасными» вещами? Ну-ну:) Если падает программа, ее можно хотя-бы в отладчике загрузить и посмотреть что и где падает. А если упадет компилятор, как искать ошибку будете? А он упадет, не сомневайтесь; компиляторы и на существующих шаблонах иногда падают.
Метапрограммирование совершенно не должно быть на том же языке, что и нормальное программирование, т.к. у этих видов программирования совершенно разные задачи и совершенно разное окружение: у программ — системные вызовы ОС и внешние библиотеки, а нередко и доступ к оборудованию; у метапрограмм — API компилятора и AST компилируемой программы. Хотя конечно это возможно и на одном языке, но с очень серьезными ограничениями.NeoCode
28.09.2015 09:58-2Добавлю: к программам и метапрограммам предъявляются совершенно разные требования. В отличие от программы, метапрограмма может не быть супер-быстрой, но она обязана быть максимально безопасной. Вы же не хотите, чтобы скачанные с гитхаба исходники при компиляции (всего лишь при компиляции!) отформатировали ваш жесткий диск или отправили ваши пароли куда-нибудь в интернет? Метапрограмма должна быть заточена для работы в специальном окружении — внутри компилятора (т.к. по сути это плагин к компилятору). Там должны быть удобные средства работы со специальными типами данных (такими как узлы AST, идентификаторы и т.д.). Скриптовые языки на самом деле предназначены именно для этого — для работы в специальных изолированных окружениях (будь то движок игры, CAD-система, браузер или в нашем случае компилятор). А синтаксическое дерево имеет некоторое сходство с иерархической структурой HTML DOM, так что в случае с js есть на что ориентироваться. Хотя конечно можно взять и другой язык — Lua, Python и т.д.
khim
28.09.2015 11:53Вы же не хотите, чтобы скачанные с гитхаба исходники при компиляции (всего лишь при компиляции!) отформатировали ваш жесткий диск или отправили ваши пароли куда-нибудь в интернет?
Не хочу. Но компиляцию я запускаю из под nobody где-то там на кластере, а готовую программу потом — у себя на машине и зачастую под root'ом. Причём метапрограмме я скармливаю данные о которых мне всё известно, а программе — фиг знает что из интернета. Так что требования безопасности к метапрограммам, как правило, ниже, чем к самой программе.
Да что там говорить: из-за отсутствия нормального метапрограммирования люди пользуются генераторами кода, которые, вы не поверите, запускаются именно что таки во время сборки. Так что все ультрасупермегабеды мы уже и так имеем — а удобства как не было, так и нет.
khim
28.09.2015 15:20Только что осознал до какой степени я идиот.
Вы же не хотите, чтобы скачанные с гитхаба исходники при компиляции (всего лишь при компиляции!) отформатировали ваш жесткий диск или отправили ваши пароли куда-нибудь в интернет?
Тот факт что 99% систем сборки (сказал бы 100% но, возможно, в природе не только существуют системы сборки без подобных возможностей, но ими кто-то из C++ программистов может ещё и реально пользоваться) это позволяют сделать без всякого метопрограммирования вас не смущает, нет?
Зачем делать что-то через ошибки в реализации метапрограммы если вы можете сделать всё ровно то же самое прямо и непосредственно?
P.S. Кстати как раз грамотно сделанная поддержка модулей может, по крайней мере в простых случаях, проблему «расшить». Помнится что программки на Turbo Pascal'е вполне себе собирались с помошью «tpc /m» и никаких систем сборки не требовали — примерно как и программы на какой-нибудь Аде. Ровно-таки из-за наличия грамотно сделанных модулей.
khim
28.09.2015 11:48+2А если упадет компилятор, как искать ошибку будете?
А как я ищу ошибку сейчас, когда он падает? С помощью gdb. Ну или printf'ов если случай очень сложный.
А он упадет, не сомневайтесь; компиляторы и на существующих шаблонах иногда падают.
А вот как раз для отладки метапрограмм на шаблонах приличных средст нет. Хотя уже второй десяток лет пошёл этому направлению.
Метапрограммирование совершенно не должно быть на том же языке, что и нормальное программирование, т.к. у этих видов программирования совершенно разные задачи и совершенно разное окружение
Вы сейчас рассказываете что node.js — это от лукавого и никому не нужно. Нужно. Причём выгода та же самая: вы можете с лёгкостью неимоверной перенести код из времени исполнения во время компиляции. Или назад.
Типичный пример задачи метапрограммирования, которая должна, посто обязана приличным языком решаться, но не решается на C++: статический std::map. Зачем у меня при старте какого-нибудь Chrome'а (или любой другой мало-мальски сложной программы) заново создаются и размещаются в памяти десятки разнообразных std::map'ов? Зачем придумывается синглтноны и куча прочей фигни, чтобы это не тормозило запуск программ (но бестолковая работа всё равно исполняется — просто в другой момент времени)? Ответ: потому что кто-то когда решил, что «у этих видов программирования — разные задачи и совершенно разное окружение».
Да, окружение разное, да не все функции могут использоваться. Но вы уж предоставьте с этим самому программисту разбираться, а не решайте заранее за меня — что мне нужно.
P.S. Думаю что в каком-нибудь C++21 для статического std::map'а что-нибудь придумают. Но это будет очередной костыль, так как останутся проблемы статически заданного XML'я, JSON'и и прочего.FoxCanFly
28.09.2015 19:35А в каком языке есть статический map/xml/json?
stepik777
28.09.2015 20:39В Rust есть библиотека phf, но она, наверное, пока не работает на стабильном Расте, а только на nightly. В ней только map и set, она в Servo используется. Для других языков есть генераторы, которые могут генерировать исходники, искать по запросу «perfect hash generator».
encyclopedist
26.09.2015 20:42+12Важное дополнение: в настоящий момент есть 2 конкурирующих пропозала по модулям:
1. Пропозал Google, ориентированный на обратную совместимость с заголовками и препроцессором, уже довольно давно реализованный в Clang
2. Пропозал Microsoft, о котором идет речь тут, он более «идеологически чистый» с меньшей обратной совместимотью.
В стандарт войдёт то, что получится когда удастся договориться и придти к общему решению. Возможно, это произойдет скоро (следующее заседание комитета будет вроде в октябре), возможно — несколько позже. Скорее всего то, что войдёт в стандарт, будет несколько отличаться.
semenyakinVS
26.09.2015 21:03Ура! С одной стороны я рад — любимый язык воспрянет ото сна. С другой — я писал свой менеджер пакетов для плюсов. Теперь будет не нужен… Решение, включённое в стандарт всегда будет круче.
П.С.: Весьма интересно как решат вопрос с compile-time штуками: макросами и шаблонами. Я у себя как раз из-за этого забуксовал. Скорее всего в либы будут впаивать какие-нибудь хитрособранные куски обобщённого AST.tangro
26.09.2015 21:46+3Там в доке про это написано. По макросам — полная изоляция. Макросы модуля не видимы и не влияют на код того, кто его импортирует. И наоборот. По шаблонам — модуль описывает шаблон и конкретные реализации, которые мы желаем экспортировать. Остальные реализации шаблона не могут быть инстанциированы (да, серьёзное ограничение).
semenyakinVS
26.09.2015 22:09+1Хм. Выходит, почти ничего нового. Для библиотек были, фактически, такие же ограничения (с точностью до того, что тут у нас не совсем хедеры). Только там в аналогичном случаи с шаблонами была бы ошибка линковки.
А не подскажете, есть ли какой-нибудь простой пример использования модулей? В доке не нашёл.tangro
26.09.2015 23:39Ну, описание синтаксиса и флаги компиляции вон на фотках в статье. Только вот пробовать пока нет на чём — не вышел ещё апдейт компилятора.
alexeibs
27.09.2015 11:34+5Остальные реализации шаблона не могут быть инстанциированы
Да это бред какой-то. Куча библиотек на шаблонах станет неюзабельными. Те же контейнеры и смарт-пойнтеры из STL, к примеру.semenyakinVS
27.09.2015 14:34+1Так шаблоны в таких случаях будут по-прежнему в хедерах жить, как я понимаю… Я вот другого никак не пойму — в чём принципиальная разница между библиотекой и модулем?
bak
27.09.2015 14:51В хедерах — не вариант. Как минимум потому что многие библиотеки состоят не только из шаблонов но ещё и из компилируемой части. А микс include-ов и import-ов — это ад. Надеюсь что всё же разрешат шаблоны.
theambient
27.09.2015 23:52свой менеджер пакетов?
а можно ссылочку?semenyakinVS
28.09.2015 00:28Я его пока не выкладывал в открытый доступ. Живёт в закрытом репо на bitbucket. Не хотел выкладывать пока проект не доведён до приемлемого состояния. Если интересно — могу добавить в ридеры проекта, рассказать о нём в личке, по скайпу либо при встрече в реале. Я там безумную философию ещё свою придумал для него…
Ещё, кстати, вот тут было обсуждение по поводу, там я узнал про bii, попробовал его и немного переосмыслил концепцию. Понял, что нужно отказаться от чисто объектного подхода как от такого, что сильно ограничивает свободу (у меня модуль был, фактически, объектом — и только через объект модуля можно было получать доступ к функционалу; свободные функции и констнаты отрицались) и перейти к метапрограммным тулзам для хедер-генерации.theambient
28.09.2015 00:38Если интересно — могу добавить в ридеры проекта, рассказать о нём в личке, по скайпу либо при встрече в реале. Я там безумную философию ещё свою придумал для него…
c удовольствием посмотрю, я сам в последнее время брежу нормальным пакетным менеджером для плюсов для разрешения транзитивных зависимостей. Так что шлите доступ к репозиторию в ЛС, возможно, присоединюсь)
tsafin
26.09.2015 23:07+4Видео про модули пока не выложено (пока есть несколько ключевых видео Бъярна, Герба Саттера и Шона Парента)
Но презентация по модулям уже выложена на GitHub arge Scale C++ With Modules: What You Should Know (Gabriel Dos Reis)
P.S.
Моё персональное IMHO, но более эпохальны собственно предлагаемые guidelines, и соответствующие артефакты в виде GSL [guideliens support library] и статического анализатора по (смотри презентации Бъярна и Герба). Они кардинальным образом отразятся на качестве C++11/14/17 программ.
beduin01
27.09.2015 01:31-15О боже, теперь в С++ будут и заголовочные файлы и модули! Замечательный язык! В следующей версии предлагаю еще возможность вместо скобок табуляцией все отбивать, чтобы программисты вместо того, чтобы думать над тем как решить задачу думали над тем как всем этим мусором истории пользоваться.
mapron
27.09.2015 07:08+7«механизм использовани компонентов в программах на С++ придумывался где-то лет 35 назад»
Занудства ради, он не придумывался для С++, он достался от Си, который аж 42 года назад придумали.
beduin01
27.09.2015 11:04-7Судя по количеству восторженных комментариев потенциальная аудитория проникшаяся данным новшеством чуть ниже аудитории приверженцев Perl 6.
Теперь С++ стал еще сложнее и запутаннее. Кроме тонн Legacy кода будет еще и куча проблем с этими модулями, восторгаться которыми может только человек не писавший ни на одном другом языке. У меня все кто мог сползли на другие языки от C# до D и Go, просто потому что там можно писать код, а решать проблемы языка.
Если Rust сможет заменить чистый Си это будет огромным ударом по С++ и будет способствовать его дальнейшему протуханию. Сам по себе С++ нужен только из-за тонн Legacy кода.
creker
27.09.2015 16:02+9Сам по себе С++ нужен только из-за тонн Legacy кода.
А еще он нужен для того, чтобы писать сложный софт, который требует ООП, около нулевого оверхеда от самого языка и развитых средств разработки. Тот же Go, с которым все носятся, сразу отпадает из-за своего сборщика мусора и средств разработки, и вообще слишком жирный он пока что. В данный момент C++ единственный выбор. Взять теже игры — альтернативы С++ там нет и в ближайшее время не предвидится.
восторгаться которыми может только человек не писавший ни на одном другом языке
Я вот пишу, но чего-то модули меня несказанно радуют. Еще бы репозиторий прикрутить и заживем (тот же NuGet от МС было бы очень неплохо. Тем более что они как раз участвуют во всем этом).
Теперь С++ стал еще сложнее и запутаннее.
У меня вот вам вопрос. Вы на С++ то писали? Вообще-то на этой конференции речь о том, чтобы сделать наконец С++ менее сложным и запутанным. И, вроде бы, все у них в руках. Модули должны решить проблему подключения внешних зависимостей. GSL и статические анализаторы двинут язык в сторону того же Rust, когда во время компиляции будет происходить проверка некоторого набора правил. С++ слишком большой, поэтому люди хотят взять срез его современных возможностей и популяризировать именно его. Нужно отучить людей от копания в стандартах и спецификациях языка, когда это делать не нужно.
beduin01
27.09.2015 16:31-6>В данный момент C++ единственный выбор
Не единственный, на том же D можно писать высокопроизводительные решения ни чем не уступающие С++, к примеру у sociomantic.com почти вся логика на D написана. Единственное что мешает D вместо С++ использовать это отсутствие нативной графической библиотеки типа Qt. В остальном язык гораздо проще плюсов, и что в плюсах кое-как возможно появится только завтра в том же D есть by design с самого начала.
Поэтому мне вообще не понятен восторг. Быть может для людей не видевших лучшей жизни все эти нововведения и звучат привлекательно, но для большинства остальных это не так.
Если не нет заморочек с GC, то часто вообще на C# проще писать.
> С++ слишком большой, поэтому люди хотят взять срез его современных возможностей и популяризировать именно его
Да не получится его популяризовать. Придется и дальше тащить огромное неуклюжее Legacy наследие. В итоге С++ будет вечно отставать лет на 15-20 от других более новых языков.creker
27.09.2015 16:42+7Не единственный, на том же D можно писать высокопроизводительные решения
Можно, но экосистема С++ просто несравнима, поэтому выбирают именно последний. Это проблема всех новых языков и D даже с учетом своего возраста так и не выбрался из этой стадии, а от того все такой же мертвый.
Если не нет заморочек с GC, то часто вообще на C# проще писать.
Когда не нужен zero-overhead, то открывается огромный просто для выбора и тот же D/Rust там уже никому не нужен будет.
Да не получится его популяризовать. Придется и дальше тащить огромное неуклюжее Legacy наследие. В итоге С++ будет вечно отставать лет на 15-20 от других более новых языков.
Так вроде бы все это понимают. Речь о том, чтобы новый код начали писать с использованием этих правил. Легаси код всегда останется и будет работать, а новый код можно начать писать на современном С++. Этому и будут способствовать GSL и статический анализ. C++ идет в ногу со временем.
PsyHaSTe
28.09.2015 12:53+1Я бы не стал Rust списывать со счетов. Еще меньше оверхеда, еще больше возможностей, фантастический язык. Да, пока что экосистема языка бедная, но что вы хотите, стабильный билд только-только вышел. Я уверен, что Rust приживется во всяких микроконтроллерных байдах, где даже плюсы считаются оверхедом, и все время чинят мелкие утечки памяти из-за забытых указателей и прочей адресной арифметики. Постепенно наработается библиотечка и плюсы потеснят, не беспокойтесь. Через 100 лет С++ существовать не будет, сейчас он есть. Следовательно, по теореме Больцано-Коши где-то на этом интервале он исчезнет. Почему бы этому не произойти в ближайшие 10 лет? Не завтра, не после-завтра, но постепенно и по чуть-чуть. 20 лет назад помню тоже КОБОЛЬщики утверждали, что на коболе написано 100500 программ, весь бизнес и банки работают на нем и никуда это не денется. И вот прошли эти самые 20 лет, теперь балом правит Джава. Учитывая экспоненциальный характер развития технологий 20 лет превращается в 10 или даже 5. Так что оглянуться не успеем, как и плюсы, и джава с моими любимыми си-решетками окажется на свалке истории.
khim
28.09.2015 14:49+120 лет назад помню тоже КОБОЛЬщики утверждали, что на коболе написано 100500 программ, весь бизнес и банки работают на нем и никуда это не денется.
А ведь никуда и не делось. Статистика утверждает, что Кобол всё ещё популярнее, чем D, Lua или какой-нибудь Erlang!
Да даже уже убитый насмерть FoxPro сейчас популярнее, чем Go или Rust!
Языки умирают ну ооочень долго. Они могут становиться менее или более популярными, но так вот, чтобы совсем-совсем вымереть… для этого язык изначально должен быть не слишком популярным и не слишком критичным.PsyHaSTe
28.09.2015 20:53-2Про Go ничего не скажу. Но вот странно сравнивать весьма популярную в своё время технологию с языком для системного программирования, только вышедшим из беты, с ежеденевным изменением синтаксиса и стандартной либы, и весьма высоким порогом вхождения, плюс абсолютно беспрецедентной схемой own/borrow(да, знаю, что похоже на всякие uniqueptr и т.п., но всё же это не одно и то же), непривычная для большинства, плюс очень строгий компилятор. Одним словом, порог вхождения в язык очень и очень высок — выше, чем у плюсов, на уровне Хаскелля/J имхо. Странно от него ожидать сходу 100500% рынка и распространенность.
ZyXI
28.09.2015 21:28«Ежедневное изменение синтаксиса» было до беты, сейчас такого больше не будет. Схему они заимствовали из какого?то другого языка (популярностью тот, впрочем, совсем не отличался). Часть строгости является ошибками компилятора и это починят, но порог вхождения сильно не снизится.
ozkriff
29.09.2015 10:11>> Схему они заимствовали из какого?то другого языка (популярностью тот, впрочем, совсем не отличался).
Из какого? Насколько я знаю, именно такой работы с памятью, завязанной на владении/одалживании и изменяемости/неизменяемости не было.
>> Часть строгости является ошибками компилятора и это починят…
А можно подробней про «ошибки, которые починят»? Там же просто мелочи хотят подкрутить, и то не факт что сделают.semenyakinVS
29.09.2015 13:34Я вот не уверен что это было раньше, но концепция владения была в objective-C (и позже легла в основу ARC). Там же мутабельность структур данных занимала важную роль (хоть и не в контексте ссылок на объекты).
А вообще, интересно было бы узнать где подобные механизмы применили раньше всего.
JIghtuse
29.09.2015 16:29Да, вроде как набор «владение-одалживание-время жизни» (ownership-borrowing-lifetimes) для Rust уникально:
This [Rust's ownership system] is one of Rust’s most unique and compelling features, with which Rust developers should become quite acquainted. Ownership is how Rust achieves its largest goal, memory safety.
doc.rust-lang.org/book/ownership.html
Какие-то идеи явно растут из C++, какие-то — из других языков (их полный список из Wikipedia: Alef, C#, C++, Cyclone, Erlang, Haskell, Hermes, Limbo, Newsqueak, NIL, OCaml, Ruby, Scheme, Standard ML, Swift), но гармоничное их объединение в Rust появилось впервые. Радует, что разработчики других языков увидели в этом перспективы.ozkriff
29.09.2015 16:34+1>> Радует, что разработчики других языков увидели в этом перспективы.
Саттер говорит, что он сначала сделал то что сделал, а потом уже пошел смотреть другие решения этой же проблемы:
https://www.reddit.com/r/cpp/comments/3m0d41/writing_good_c14_by_default_herb_sutter/cvcnmn5
theambient
27.09.2015 23:47Не единственный, на том же D можно писать высокопроизводительные решения ни чем не уступающие С++, к примеру у sociomantic.com почти вся логика на D написана. Единственное что мешает D вместо С++ использовать это отсутствие нативной графической библиотеки типа Qt. В остальном язык гораздо проще плюсов, и что в плюсах кое-как возможно появится только завтра в том же D есть by design с самого начала.
За исключением нескольких «но», которые сводят на нет практическое применение D (увы):
- нельзя по-нормальному использовать уже написанный плючовый код (интерфес к плююсам поддерживается лишь формально, на деле его никто не использует, по крайней мере я не видел)
- нельзя использовать D из плюсов (у Rust-а в этом вопросе большое преимущество)
- GC как понятие, который убивает всю предсказуемость выполнения, а вводить семантику владения либо ARC-и Александреску с Уолтером некогда, по крайней мере их просили об этом еще три года назад, они говорили что думают в этом направлении… а воз и ныне там
а вообще жаль, что D не взлетел, у него до выхода 11-го стандарта еще были шансы заменить плюсы. С выходом 11-го единственным преимуществом D остались модули и система сборки, с выходом С++17, видимо, ничего, а жаль…beduin01
28.09.2015 10:28-2>С выходом 11-го единственным преимуществом D остались модули и система сборки, с выходом С++17, видимо, ничего, а жаль…
Так D тоже не стоит на месте, новые фишки в него добавляются куда проще чем в С++, так что даже когда выйдет С++17 он все равно будет на те же 10-15 лет отставать от D.
Касательно сборщика мусора в последних версиях с ним очень плотно поработали. Я темой GC не интересуюсь т.к. мне и так хорошо, но все же.
По поводу уже на писанного кода С++ есть замечательный проект https://github.com/Syniurge/Calypso который позволяет собирать практически все существующие библиотеки на С++, даже такие большие как Qt.theambient
28.09.2015 11:40про Calypso слышал, вещь интригующая. но если честно, есть сомнения, как это будет работать на практике.
со сборщиком мусора я намучился вдоволь, так что весь код пришлось переписывать на плюсах: дело было даже не в предсказуемости, а в том, что он собирал куски памяти, на которые были активные ссылки: проблема была точно диагностирована (пришлось применять некоторые отладочные средства и дебажить D-ный runtime), пытались решить проблему с одним из активных контрибьюторов D — не получилось, так как я, увы, не мог дать код. В результате в какой-то момент я сдался и отказался от D.
Увы, мой эксперимент по использованию D в продакшене провалился =(
Основная проблема с D в том, что он в отличие от C/C++ не может стать общим знаменателем из-за активного рантайма. У rust в этом отношении больше перспектив.
P.S. Сам я сплю и вижу как С++, кобол 21 века, умрет, но боюсь он мягко эволюционирует во что-то не идеальное, но хорошее.
poxu
28.09.2015 11:49А Александреску уволился из Фейсбука, для того, чтобы посвятить всё своё время развитию D.
dordzhiev
Боже, это эпик! Про дату выхода что-нибудь известно?
encyclopedist
Обещают в октябре, насколько я знаю. Также в составе Update 1 должен быть прототип инструмента для проверки «С++ Core Guidelines», который показывал Саттер.