Comments 64
Боже, это эпик! Про дату выхода что-нибудь известно?
Обещают в октябре, насколько я знаю. Также в составе Update 1 должен быть прототип инструмента для проверки «С++ Core Guidelines», который показывал Саттер.
Дело не в дате выхода VS, а в дате выхода официального стандарта языка. И даже не в этой дате, а в дате официального перехода вашего проекта на нужную версию VS. Что для больших компаний может быть лет через 5, увы.
Боже мой! Это как? Это что же теперь, любой java программист, который чем статистическая библиотека от динамической отличается не знает, на С++ безболезненно писать сможет? Это получается теперь, пока код собирается, даже на мечах толком не порубишься?
OMG, модули будут стандартизированы? Лучше поздно, чем никогда! С++ укрепляется в качестве лучшего кросс-платформенного компилируемого ЯП!
Боже мой, это же просто боже мой! OMG!
Да, это будет сильный удар по Go\Rust, понизится входной порог в плюсы. Милота!
Это лучше что может произойти с C++․
Ура!
Ура!
Какой ужас! Эти люди делают из C++ очередной Rust или D… Но зачем?
Сама идея того что в один файл на 10К инклюдится еще 150Мб сорцов для компиляции это не нормально.
Каждый инструмент создается под свою задачу. Если для вас данное поведение не нормально — есть множество альтернатив. А прикручивать скотчем к молотку лазерный прицел после того как прошло 30 лет и называть его все тем же молотком — глупость.
Что любопытно — так устроена компиляция программ на go. Даже стандартная библиотека каждый раз собирается заново.
Не прошло и 35 лет:)
Но лучше поздно чем никогда. Наконец-то этот ад под названием include станет постепенно исчезать.
Конечно еще придется подождать пока основные библиотеки (boost, qt и т.п.) перейдут на модули. Но думаю как только msvc, gcc и clang поддержат — так сразу и перейдут.
Еще бы рефлексию нормальную и метапрограммирование человеческое, а не на шаблонах.
Но лучше поздно чем никогда. Наконец-то этот ад под названием include станет постепенно исчезать.
Конечно еще придется подождать пока основные библиотеки (boost, qt и т.п.) перейдут на модули. Но думаю как только msvc, gcc и clang поддержат — так сразу и перейдут.
Еще бы рефлексию нормальную и метапрограммирование человеческое, а не на шаблонах.
Еще бы рефлексию нормальную и метапрограммирование человеческое, а не на шаблонах
Как по мне, это дело решается доступом к AST через специальный исполняемый в compile-time язык. Вот тут Эрик Ниблер такую тему задвигал (можно найти по фразе «Я бы предпочёл на его месте основанный на AST чистый макропроцессор»; кстати, там же была дискуссия по поводу разбора плюсвого кода сторонними средствами — например, clang-ом).
Кстати, от знакмого узнал (тут посмотрел) что есть такой язык nim. В нём можно писать своим оптимизаторы компиляции (по ссылке — раздел «Добавляем свои оптимизации в компилятор»). Вот что-то вроде такой концепции, только, естественно, намного более навороченной нужно для плюсов, как по мне. Чтобы именно доступ к AST был.
Ну да, именно это я и имею в виду. Синтаксические (а не лексические как в плюсах) макросы, доступ к AST. В качестве языка метапрограммирования можно использовать любой достаточно распространенный скриптовый язык, например javascript.
Большего бреда, чем использования JavaScript'а для метапрограммирования и представить себе сложно. Метапрограммирование должно происходить на том же языке, что и «нормальное» программирование! Что шаблоны, что JavaScript — всё будет неудобно кому-то.
С указателями и прочими «небезопасными» вещами? Ну-ну:) Если падает программа, ее можно хотя-бы в отладчике загрузить и посмотреть что и где падает. А если упадет компилятор, как искать ошибку будете? А он упадет, не сомневайтесь; компиляторы и на существующих шаблонах иногда падают.
Метапрограммирование совершенно не должно быть на том же языке, что и нормальное программирование, т.к. у этих видов программирования совершенно разные задачи и совершенно разное окружение: у программ — системные вызовы ОС и внешние библиотеки, а нередко и доступ к оборудованию; у метапрограмм — API компилятора и AST компилируемой программы. Хотя конечно это возможно и на одном языке, но с очень серьезными ограничениями.
Метапрограммирование совершенно не должно быть на том же языке, что и нормальное программирование, т.к. у этих видов программирования совершенно разные задачи и совершенно разное окружение: у программ — системные вызовы ОС и внешние библиотеки, а нередко и доступ к оборудованию; у метапрограмм — API компилятора и AST компилируемой программы. Хотя конечно это возможно и на одном языке, но с очень серьезными ограничениями.
Добавлю: к программам и метапрограммам предъявляются совершенно разные требования. В отличие от программы, метапрограмма может не быть супер-быстрой, но она обязана быть максимально безопасной. Вы же не хотите, чтобы скачанные с гитхаба исходники при компиляции (всего лишь при компиляции!) отформатировали ваш жесткий диск или отправили ваши пароли куда-нибудь в интернет? Метапрограмма должна быть заточена для работы в специальном окружении — внутри компилятора (т.к. по сути это плагин к компилятору). Там должны быть удобные средства работы со специальными типами данных (такими как узлы AST, идентификаторы и т.д.). Скриптовые языки на самом деле предназначены именно для этого — для работы в специальных изолированных окружениях (будь то движок игры, CAD-система, браузер или в нашем случае компилятор). А синтаксическое дерево имеет некоторое сходство с иерархической структурой HTML DOM, так что в случае с js есть на что ориентироваться. Хотя конечно можно взять и другой язык — Lua, Python и т.д.
Вы же не хотите, чтобы скачанные с гитхаба исходники при компиляции (всего лишь при компиляции!) отформатировали ваш жесткий диск или отправили ваши пароли куда-нибудь в интернет?Не хочу. Но компиляцию я запускаю из под nobody где-то там на кластере, а готовую программу потом — у себя на машине и зачастую под root'ом. Причём метапрограмме я скармливаю данные о которых мне всё известно, а программе — фиг знает что из интернета. Так что требования безопасности к метапрограммам, как правило, ниже, чем к самой программе.
Да что там говорить: из-за отсутствия нормального метапрограммирования люди пользуются генераторами кода, которые, вы не поверите, запускаются именно что таки во время сборки. Так что все ультрасупермегабеды мы уже и так имеем — а удобства как не было, так и нет.
Только что осознал до какой степени я идиот.
Зачем делать что-то через ошибки в реализации метапрограммы если вы можете сделать всё ровно то же самое прямо и непосредственно?
P.S. Кстати как раз грамотно сделанная поддержка модулей может, по крайней мере в простых случаях, проблему «расшить». Помнится что программки на Turbo Pascal'е вполне себе собирались с помошью «tpc /m» и никаких систем сборки не требовали — примерно как и программы на какой-нибудь Аде. Ровно-таки из-за наличия грамотно сделанных модулей.
Вы же не хотите, чтобы скачанные с гитхаба исходники при компиляции (всего лишь при компиляции!) отформатировали ваш жесткий диск или отправили ваши пароли куда-нибудь в интернет?Тот факт что 99% систем сборки (сказал бы 100% но, возможно, в природе не только существуют системы сборки без подобных возможностей, но ими кто-то из C++ программистов может ещё и реально пользоваться) это позволяют сделать без всякого метопрограммирования вас не смущает, нет?
Зачем делать что-то через ошибки в реализации метапрограммы если вы можете сделать всё ровно то же самое прямо и непосредственно?
P.S. Кстати как раз грамотно сделанная поддержка модулей может, по крайней мере в простых случаях, проблему «расшить». Помнится что программки на Turbo Pascal'е вполне себе собирались с помошью «tpc /m» и никаких систем сборки не требовали — примерно как и программы на какой-нибудь Аде. Ровно-таки из-за наличия грамотно сделанных модулей.
А если упадет компилятор, как искать ошибку будете?А как я ищу ошибку сейчас, когда он падает? С помощью gdb. Ну или printf'ов если случай очень сложный.
А он упадет, не сомневайтесь; компиляторы и на существующих шаблонах иногда падают.А вот как раз для отладки метапрограмм на шаблонах приличных средст нет. Хотя уже второй десяток лет пошёл этому направлению.
Метапрограммирование совершенно не должно быть на том же языке, что и нормальное программирование, т.к. у этих видов программирования совершенно разные задачи и совершенно разное окружениеВы сейчас рассказываете что node.js — это от лукавого и никому не нужно. Нужно. Причём выгода та же самая: вы можете с лёгкостью неимоверной перенести код из времени исполнения во время компиляции. Или назад.
Типичный пример задачи метапрограммирования, которая должна, посто обязана приличным языком решаться, но не решается на C++: статический std::map. Зачем у меня при старте какого-нибудь Chrome'а (или любой другой мало-мальски сложной программы) заново создаются и размещаются в памяти десятки разнообразных std::map'ов? Зачем придумывается синглтноны и куча прочей фигни, чтобы это не тормозило запуск программ (но бестолковая работа всё равно исполняется — просто в другой момент времени)? Ответ: потому что кто-то когда решил, что «у этих видов программирования — разные задачи и совершенно разное окружение».
Да, окружение разное, да не все функции могут использоваться. Но вы уж предоставьте с этим самому программисту разбираться, а не решайте заранее за меня — что мне нужно.
P.S. Думаю что в каком-нибудь C++21 для статического std::map'а что-нибудь придумают. Но это будет очередной костыль, так как останутся проблемы статически заданного XML'я, JSON'и и прочего.
Важное дополнение: в настоящий момент есть 2 конкурирующих пропозала по модулям:
1. Пропозал Google, ориентированный на обратную совместимость с заголовками и препроцессором, уже довольно давно реализованный в Clang
2. Пропозал Microsoft, о котором идет речь тут, он более «идеологически чистый» с меньшей обратной совместимотью.
В стандарт войдёт то, что получится когда удастся договориться и придти к общему решению. Возможно, это произойдет скоро (следующее заседание комитета будет вроде в октябре), возможно — несколько позже. Скорее всего то, что войдёт в стандарт, будет несколько отличаться.
1. Пропозал Google, ориентированный на обратную совместимость с заголовками и препроцессором, уже довольно давно реализованный в Clang
2. Пропозал Microsoft, о котором идет речь тут, он более «идеологически чистый» с меньшей обратной совместимотью.
В стандарт войдёт то, что получится когда удастся договориться и придти к общему решению. Возможно, это произойдет скоро (следующее заседание комитета будет вроде в октябре), возможно — несколько позже. Скорее всего то, что войдёт в стандарт, будет несколько отличаться.
Ура! С одной стороны я рад — любимый язык воспрянет ото сна. С другой — я писал свой менеджер пакетов для плюсов. Теперь будет не нужен… Решение, включённое в стандарт всегда будет круче.
П.С.: Весьма интересно как решат вопрос с compile-time штуками: макросами и шаблонами. Я у себя как раз из-за этого забуксовал. Скорее всего в либы будут впаивать какие-нибудь хитрособранные куски обобщённого AST.
П.С.: Весьма интересно как решат вопрос с compile-time штуками: макросами и шаблонами. Я у себя как раз из-за этого забуксовал. Скорее всего в либы будут впаивать какие-нибудь хитрособранные куски обобщённого AST.
Там в доке про это написано. По макросам — полная изоляция. Макросы модуля не видимы и не влияют на код того, кто его импортирует. И наоборот. По шаблонам — модуль описывает шаблон и конкретные реализации, которые мы желаем экспортировать. Остальные реализации шаблона не могут быть инстанциированы (да, серьёзное ограничение).
Хм. Выходит, почти ничего нового. Для библиотек были, фактически, такие же ограничения (с точностью до того, что тут у нас не совсем хедеры). Только там в аналогичном случаи с шаблонами была бы ошибка линковки.
А не подскажете, есть ли какой-нибудь простой пример использования модулей? В доке не нашёл.
А не подскажете, есть ли какой-нибудь простой пример использования модулей? В доке не нашёл.
Остальные реализации шаблона не могут быть инстанциированы
Да это бред какой-то. Куча библиотек на шаблонах станет неюзабельными. Те же контейнеры и смарт-пойнтеры из STL, к примеру.
свой менеджер пакетов?
а можно ссылочку?
Я его пока не выкладывал в открытый доступ. Живёт в закрытом репо на bitbucket. Не хотел выкладывать пока проект не доведён до приемлемого состояния. Если интересно — могу добавить в ридеры проекта, рассказать о нём в личке, по скайпу либо при встрече в реале. Я там безумную философию ещё свою придумал для него…
Ещё, кстати, вот тут было обсуждение по поводу, там я узнал про bii, попробовал его и немного переосмыслил концепцию. Понял, что нужно отказаться от чисто объектного подхода как от такого, что сильно ограничивает свободу (у меня модуль был, фактически, объектом — и только через объект модуля можно было получать доступ к функционалу; свободные функции и констнаты отрицались) и перейти к метапрограммным тулзам для хедер-генерации.
Ещё, кстати, вот тут было обсуждение по поводу, там я узнал про bii, попробовал его и немного переосмыслил концепцию. Понял, что нужно отказаться от чисто объектного подхода как от такого, что сильно ограничивает свободу (у меня модуль был, фактически, объектом — и только через объект модуля можно было получать доступ к функционалу; свободные функции и констнаты отрицались) и перейти к метапрограммным тулзам для хедер-генерации.
Если интересно — могу добавить в ридеры проекта, рассказать о нём в личке, по скайпу либо при встрече в реале. Я там безумную философию ещё свою придумал для него…
c удовольствием посмотрю, я сам в последнее время брежу нормальным пакетным менеджером для плюсов для разрешения транзитивных зависимостей. Так что шлите доступ к репозиторию в ЛС, возможно, присоединюсь)
Видео про модули пока не выложено (пока есть несколько ключевых видео Бъярна, Герба Саттера и Шона Парента)
Но презентация по модулям уже выложена на 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 программ.
Но презентация по модулям уже выложена на 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 программ.
Теперь выложено!
О боже, теперь в С++ будут и заголовочные файлы и модули! Замечательный язык! В следующей версии предлагаю еще возможность вместо скобок табуляцией все отбивать, чтобы программисты вместо того, чтобы думать над тем как решить задачу думали над тем как всем этим мусором истории пользоваться.
UFO just landed and posted this here
«механизм использовани компонентов в программах на С++ придумывался где-то лет 35 назад»
Занудства ради, он не придумывался для С++, он достался от Си, который аж 42 года назад придумали.
Занудства ради, он не придумывался для С++, он достался от Си, который аж 42 года назад придумали.
Судя по количеству восторженных комментариев потенциальная аудитория проникшаяся данным новшеством чуть ниже аудитории приверженцев Perl 6.
Теперь С++ стал еще сложнее и запутаннее. Кроме тонн Legacy кода будет еще и куча проблем с этими модулями, восторгаться которыми может только человек не писавший ни на одном другом языке. У меня все кто мог сползли на другие языки от C# до D и Go, просто потому что там можно писать код, а решать проблемы языка.
Если Rust сможет заменить чистый Си это будет огромным ударом по С++ и будет способствовать его дальнейшему протуханию. Сам по себе С++ нужен только из-за тонн Legacy кода.
Теперь С++ стал еще сложнее и запутаннее. Кроме тонн Legacy кода будет еще и куча проблем с этими модулями, восторгаться которыми может только человек не писавший ни на одном другом языке. У меня все кто мог сползли на другие языки от C# до D и Go, просто потому что там можно писать код, а решать проблемы языка.
Если Rust сможет заменить чистый Си это будет огромным ударом по С++ и будет способствовать его дальнейшему протуханию. Сам по себе С++ нужен только из-за тонн Legacy кода.
Сам по себе С++ нужен только из-за тонн Legacy кода.
А еще он нужен для того, чтобы писать сложный софт, который требует ООП, около нулевого оверхеда от самого языка и развитых средств разработки. Тот же Go, с которым все носятся, сразу отпадает из-за своего сборщика мусора и средств разработки, и вообще слишком жирный он пока что. В данный момент C++ единственный выбор. Взять теже игры — альтернативы С++ там нет и в ближайшее время не предвидится.
восторгаться которыми может только человек не писавший ни на одном другом языке
Я вот пишу, но чего-то модули меня несказанно радуют. Еще бы репозиторий прикрутить и заживем (тот же NuGet от МС было бы очень неплохо. Тем более что они как раз участвуют во всем этом).
Теперь С++ стал еще сложнее и запутаннее.
У меня вот вам вопрос. Вы на С++ то писали? Вообще-то на этой конференции речь о том, чтобы сделать наконец С++ менее сложным и запутанным. И, вроде бы, все у них в руках. Модули должны решить проблему подключения внешних зависимостей. GSL и статические анализаторы двинут язык в сторону того же Rust, когда во время компиляции будет происходить проверка некоторого набора правил. С++ слишком большой, поэтому люди хотят взять срез его современных возможностей и популяризировать именно его. Нужно отучить людей от копания в стандартах и спецификациях языка, когда это делать не нужно.
>В данный момент C++ единственный выбор
Не единственный, на том же D можно писать высокопроизводительные решения ни чем не уступающие С++, к примеру у sociomantic.com почти вся логика на D написана. Единственное что мешает D вместо С++ использовать это отсутствие нативной графической библиотеки типа Qt. В остальном язык гораздо проще плюсов, и что в плюсах кое-как возможно появится только завтра в том же D есть by design с самого начала.
Поэтому мне вообще не понятен восторг. Быть может для людей не видевших лучшей жизни все эти нововведения и звучат привлекательно, но для большинства остальных это не так.
Если не нет заморочек с GC, то часто вообще на C# проще писать.
> С++ слишком большой, поэтому люди хотят взять срез его современных возможностей и популяризировать именно его
Да не получится его популяризовать. Придется и дальше тащить огромное неуклюжее Legacy наследие. В итоге С++ будет вечно отставать лет на 15-20 от других более новых языков.
Не единственный, на том же D можно писать высокопроизводительные решения ни чем не уступающие С++, к примеру у sociomantic.com почти вся логика на D написана. Единственное что мешает D вместо С++ использовать это отсутствие нативной графической библиотеки типа Qt. В остальном язык гораздо проще плюсов, и что в плюсах кое-как возможно появится только завтра в том же D есть by design с самого начала.
Поэтому мне вообще не понятен восторг. Быть может для людей не видевших лучшей жизни все эти нововведения и звучат привлекательно, но для большинства остальных это не так.
Если не нет заморочек с GC, то часто вообще на C# проще писать.
> С++ слишком большой, поэтому люди хотят взять срез его современных возможностей и популяризировать именно его
Да не получится его популяризовать. Придется и дальше тащить огромное неуклюжее Legacy наследие. В итоге С++ будет вечно отставать лет на 15-20 от других более новых языков.
Не единственный, на том же D можно писать высокопроизводительные решения
Можно, но экосистема С++ просто несравнима, поэтому выбирают именно последний. Это проблема всех новых языков и D даже с учетом своего возраста так и не выбрался из этой стадии, а от того все такой же мертвый.
Если не нет заморочек с GC, то часто вообще на C# проще писать.
Когда не нужен zero-overhead, то открывается огромный просто для выбора и тот же D/Rust там уже никому не нужен будет.
Да не получится его популяризовать. Придется и дальше тащить огромное неуклюжее Legacy наследие. В итоге С++ будет вечно отставать лет на 15-20 от других более новых языков.
Так вроде бы все это понимают. Речь о том, чтобы новый код начали писать с использованием этих правил. Легаси код всегда останется и будет работать, а новый код можно начать писать на современном С++. Этому и будут способствовать GSL и статический анализ. C++ идет в ногу со временем.
Я бы не стал Rust списывать со счетов. Еще меньше оверхеда, еще больше возможностей, фантастический язык. Да, пока что экосистема языка бедная, но что вы хотите, стабильный билд только-только вышел. Я уверен, что Rust приживется во всяких микроконтроллерных байдах, где даже плюсы считаются оверхедом, и все время чинят мелкие утечки памяти из-за забытых указателей и прочей адресной арифметики. Постепенно наработается библиотечка и плюсы потеснят, не беспокойтесь. Через 100 лет С++ существовать не будет, сейчас он есть. Следовательно, по теореме Больцано-Коши где-то на этом интервале он исчезнет. Почему бы этому не произойти в ближайшие 10 лет? Не завтра, не после-завтра, но постепенно и по чуть-чуть. 20 лет назад помню тоже КОБОЛЬщики утверждали, что на коболе написано 100500 программ, весь бизнес и банки работают на нем и никуда это не денется. И вот прошли эти самые 20 лет, теперь балом правит Джава. Учитывая экспоненциальный характер развития технологий 20 лет превращается в 10 или даже 5. Так что оглянуться не успеем, как и плюсы, и джава с моими любимыми си-решетками окажется на свалке истории.
20 лет назад помню тоже КОБОЛЬщики утверждали, что на коболе написано 100500 программ, весь бизнес и банки работают на нем и никуда это не денется.А ведь никуда и не делось. Статистика утверждает, что Кобол всё ещё популярнее, чем D, Lua или какой-нибудь Erlang!
Да даже уже убитый насмерть FoxPro сейчас популярнее, чем Go или Rust!
Языки умирают ну ооочень долго. Они могут становиться менее или более популярными, но так вот, чтобы совсем-совсем вымереть… для этого язык изначально должен быть не слишком популярным и не слишком критичным.
Про Go ничего не скажу. Но вот странно сравнивать весьма популярную в своё время технологию с языком для системного программирования, только вышедшим из беты, с ежеденевным изменением синтаксиса и стандартной либы, и весьма высоким порогом вхождения, плюс абсолютно беспрецедентной схемой own/borrow(да, знаю, что похоже на всякие uniqueptr и т.п., но всё же это не одно и то же), непривычная для большинства, плюс очень строгий компилятор. Одним словом, порог вхождения в язык очень и очень высок — выше, чем у плюсов, на уровне Хаскелля/J имхо. Странно от него ожидать сходу 100500% рынка и распространенность.
«Ежедневное изменение синтаксиса» было до беты, сейчас такого больше не будет. Схему они заимствовали из какого‐то другого языка (популярностью тот, впрочем, совсем не отличался). Часть строгости является ошибками компилятора и это починят, но порог вхождения сильно не снизится.
>> Схему они заимствовали из какого‐то другого языка (популярностью тот, впрочем, совсем не отличался).
Из какого? Насколько я знаю, именно такой работы с памятью, завязанной на владении/одалживании и изменяемости/неизменяемости не было.
>> Часть строгости является ошибками компилятора и это починят…
А можно подробней про «ошибки, которые починят»? Там же просто мелочи хотят подкрутить, и то не факт что сделают.
Из какого? Насколько я знаю, именно такой работы с памятью, завязанной на владении/одалживании и изменяемости/неизменяемости не было.
>> Часть строгости является ошибками компилятора и это починят…
А можно подробней про «ошибки, которые починят»? Там же просто мелочи хотят подкрутить, и то не факт что сделают.
Я вот не уверен что это было раньше, но концепция владения была в objective-C (и позже легла в основу ARC). Там же мутабельность структур данных занимала важную роль (хоть и не в контексте ссылок на объекты).
А вообще, интересно было бы узнать где подобные механизмы применили раньше всего.
А вообще, интересно было бы узнать где подобные механизмы применили раньше всего.
Да, вроде как набор «владение-одалживание-время жизни» (ownership-borrowing-lifetimes) для Rust уникально:
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 появилось впервые. Радует, что разработчики других языков увидели в этом перспективы.
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 появилось впервые. Радует, что разработчики других языков увидели в этом перспективы.
Не единственный, на том же D можно писать высокопроизводительные решения ни чем не уступающие С++, к примеру у sociomantic.com почти вся логика на D написана. Единственное что мешает D вместо С++ использовать это отсутствие нативной графической библиотеки типа Qt. В остальном язык гораздо проще плюсов, и что в плюсах кое-как возможно появится только завтра в том же D есть by design с самого начала.
За исключением нескольких «но», которые сводят на нет практическое применение D (увы):
- нельзя по-нормальному использовать уже написанный плючовый код (интерфес к плююсам поддерживается лишь формально, на деле его никто не использует, по крайней мере я не видел)
- нельзя использовать D из плюсов (у Rust-а в этом вопросе большое преимущество)
- GC как понятие, который убивает всю предсказуемость выполнения, а вводить семантику владения либо ARC-и Александреску с Уолтером некогда, по крайней мере их просили об этом еще три года назад, они говорили что думают в этом направлении… а воз и ныне там
а вообще жаль, что D не взлетел, у него до выхода 11-го стандарта еще были шансы заменить плюсы. С выходом 11-го единственным преимуществом D остались модули и система сборки, с выходом С++17, видимо, ничего, а жаль…
>С выходом 11-го единственным преимуществом D остались модули и система сборки, с выходом С++17, видимо, ничего, а жаль…
Так D тоже не стоит на месте, новые фишки в него добавляются куда проще чем в С++, так что даже когда выйдет С++17 он все равно будет на те же 10-15 лет отставать от D.
Касательно сборщика мусора в последних версиях с ним очень плотно поработали. Я темой GC не интересуюсь т.к. мне и так хорошо, но все же.
По поводу уже на писанного кода С++ есть замечательный проект https://github.com/Syniurge/Calypso который позволяет собирать практически все существующие библиотеки на С++, даже такие большие как Qt.
Так D тоже не стоит на месте, новые фишки в него добавляются куда проще чем в С++, так что даже когда выйдет С++17 он все равно будет на те же 10-15 лет отставать от D.
Касательно сборщика мусора в последних версиях с ним очень плотно поработали. Я темой GC не интересуюсь т.к. мне и так хорошо, но все же.
По поводу уже на писанного кода С++ есть замечательный проект https://github.com/Syniurge/Calypso который позволяет собирать практически все существующие библиотеки на С++, даже такие большие как Qt.
про Calypso слышал, вещь интригующая. но если честно, есть сомнения, как это будет работать на практике.
со сборщиком мусора я намучился вдоволь, так что весь код пришлось переписывать на плюсах: дело было даже не в предсказуемости, а в том, что он собирал куски памяти, на которые были активные ссылки: проблема была точно диагностирована (пришлось применять некоторые отладочные средства и дебажить D-ный runtime), пытались решить проблему с одним из активных контрибьюторов D — не получилось, так как я, увы, не мог дать код. В результате в какой-то момент я сдался и отказался от D.
Увы, мой эксперимент по использованию D в продакшене провалился =(
Основная проблема с D в том, что он в отличие от C/C++ не может стать общим знаменателем из-за активного рантайма. У rust в этом отношении больше перспектив.
P.S. Сам я сплю и вижу как С++, кобол 21 века, умрет, но боюсь он мягко эволюционирует во что-то не идеальное, но хорошее.
со сборщиком мусора я намучился вдоволь, так что весь код пришлось переписывать на плюсах: дело было даже не в предсказуемости, а в том, что он собирал куски памяти, на которые были активные ссылки: проблема была точно диагностирована (пришлось применять некоторые отладочные средства и дебажить D-ный runtime), пытались решить проблему с одним из активных контрибьюторов D — не получилось, так как я, увы, не мог дать код. В результате в какой-то момент я сдался и отказался от D.
Увы, мой эксперимент по использованию D в продакшене провалился =(
Основная проблема с D в том, что он в отличие от C/C++ не может стать общим знаменателем из-за активного рантайма. У rust в этом отношении больше перспектив.
P.S. Сам я сплю и вижу как С++, кобол 21 века, умрет, но боюсь он мягко эволюционирует во что-то не идеальное, но хорошее.
А Александреску уволился из Фейсбука, для того, чтобы посвятить всё своё время развитию D.
Нельзя говорить о модулях и не упомянуть это видео: Hitler on C++17.
А какие репозитории с модулями будут? NuGet?
Апдейт вышел, поддержка на уровне experimental. Кто-то пробовал уже?
Sign up to leave a comment.
Поддержка C++ модулей в Visual Studio 2015 Update 1