Comments 128
>Dynamic Library Load
>стандартизация плоских контейнеров
>класс для вывода stack trace
И почему среди кучи разных сугубо специфических вещей не упоминается
то, что вызывает раздражение у каждого C++ программиста каждый божий день?
А именно — скорость компиляции. Бедный компилятор снова и снова парсит мегабайты
исходников. При этом существующие полуавтоматические решения для использования precompiled headers
вызывают еще большее раздражение, особенно в кросплатформенных проектах.
И главное и proposal есть для модулей, но конечно не в c++17, ведь сферические функции важнее.
Может стоит все-таки за модули побороться, а stack trace подождет?
>доступ к полям структур по индексу и базовая рефлексия.
Вот за это плюс один, использовать парсер C++ или дублировать код для рефлексии
по-моему через чур.
>стандартизация плоских контейнеров
>класс для вывода stack trace
И почему среди кучи разных сугубо специфических вещей не упоминается
то, что вызывает раздражение у каждого C++ программиста каждый божий день?
А именно — скорость компиляции. Бедный компилятор снова и снова парсит мегабайты
исходников. При этом существующие полуавтоматические решения для использования precompiled headers
вызывают еще большее раздражение, особенно в кросплатформенных проектах.
И главное и proposal есть для модулей, но конечно не в c++17, ведь сферические функции важнее.
Может стоит все-таки за модули побороться, а stack trace подождет?
>доступ к полям структур по индексу и базовая рефлексия.
Вот за это плюс один, использовать парсер C++ или дублировать код для рефлексии
по-моему через чур.
> Может стоит все-таки за модули побороться, а stack trace подождет?
Есть отдельная подгруппа, занимающаяся модулями в комитете по стандартизации C++. Занимаются они модулями уже очень давно, они сильно «в теме» и с модулями множество проблем о которых мало кто задумывается:
* циклические зависимости
* линковка (в стандарт в данный момент вводится понятие module level linkage в дополнение к internal и external linkage. Вводить новое определение — очень сложно, необходимо проверить как оно взаимодействует со старыми определениями, нет ли конфликтов и прочего)
* макросы и как их экспортировать
* шаблоны и как их экспортировать из модулей. А если шаблон не проинстанцированный, как его экспортировать?
* typedef|using|constexpr и прочее
и т.д.
В стандарт модули скорее всего не примут до тех пор, пока в одном из компиляторов ну будет реализована их экспериментальная поддержка. Необходимо это для того, чтобы найти и решить проблемы о которых не подумали на этапе проектирования. Поторопить тут никого не получится.
Вам может приглянуться эта библиотечка.
Это прототип, показывающий, что уже в C++14 можно определять содержимое структуры. Как правило подобные прототипы очень хорошо влияют на голосование по предложению, так что надеемся что особых проблем с доступом к полям структур по индексу не возникнет.
Есть отдельная подгруппа, занимающаяся модулями в комитете по стандартизации C++. Занимаются они модулями уже очень давно, они сильно «в теме» и с модулями множество проблем о которых мало кто задумывается:
* циклические зависимости
* линковка (в стандарт в данный момент вводится понятие module level linkage в дополнение к internal и external linkage. Вводить новое определение — очень сложно, необходимо проверить как оно взаимодействует со старыми определениями, нет ли конфликтов и прочего)
* макросы и как их экспортировать
* шаблоны и как их экспортировать из модулей. А если шаблон не проинстанцированный, как его экспортировать?
* typedef|using|constexpr и прочее
и т.д.
В стандарт модули скорее всего не примут до тех пор, пока в одном из компиляторов ну будет реализована их экспериментальная поддержка. Необходимо это для того, чтобы найти и решить проблемы о которых не подумали на этапе проектирования. Поторопить тут никого не получится.
>доступ к полям структур по индексу и базовая рефлексия.
Вот за это плюс один, использовать парсер C++ или дублировать код для рефлексии
по-моему через чур.
Вам может приглянуться эта библиотечка.
Это прототип, показывающий, что уже в C++14 можно определять содержимое структуры. Как правило подобные прототипы очень хорошо влияют на голосование по предложению, так что надеемся что особых проблем с доступом к полям структур по индексу не возникнет.
>В стандарт модули скорее всего не примут до тех пор, пока в одном из компиляторов ну будет реализована их
> экспериментальная поддержка
Если их == модули, то есть и даже не в одном:
http://clang.llvm.org/docs/Modules.html
https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules-in-vs-2015-update-1/
>Поторопить тут никого не получится.
ИМХО, у людей работающих долго над чем-то, что не взлетает обычно
хорошо прокачено искуство объяснять как все сложно, но при этом
свежий вгляд от тех кто не испугался бывает им очень полезен.
>Вам может приглянуться эта библиотечка.
У меня уже есть решение основанное на парсинге с помощью libclang определения структур и
генерации метаинформации для работы с полями стуктуры в runtime.
ИМХО конечно, но в вашей библиотеке ведь даже название поля нельзя получить? Для сериализации
в json/xml это важно.
> экспериментальная поддержка
Если их == модули, то есть и даже не в одном:
http://clang.llvm.org/docs/Modules.html
https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules-in-vs-2015-update-1/
>Поторопить тут никого не получится.
ИМХО, у людей работающих долго над чем-то, что не взлетает обычно
хорошо прокачено искуство объяснять как все сложно, но при этом
свежий вгляд от тех кто не испугался бывает им очень полезен.
>Вам может приглянуться эта библиотечка.
У меня уже есть решение основанное на парсинге с помощью libclang определения структур и
генерации метаинформации для работы с полями стуктуры в runtime.
ИМХО конечно, но в вашей библиотеке ведь даже название поля нельзя получить? Для сериализации
в json/xml это важно.
Вы привели 2 реализации. В этом и была проблема — это 2 несовместимых подхода (главная разница — в вопросе, экспортировать ли макросы.) И потребовалось очень много времени, чтобы сторонники двух подходов договорились и пришли к единому мнению. Собственно, реализации итогового варианта вроде пока нет (хотя я не уверен, может быть Microsoft уже обновил реализацию)
Вам может приглянуться эта библиотечка.
o_O вот это магия! Но как?!
Если очень вкратце:
* template <size_t> struct ubiq { template operator T(); };
* пробуем aggregate initialization для структуры: T { ubiq{}… }
* уменьшаем количество ubiq, первое собравшееся выражение подсказывает нам сколько полей в структуре
* правдами и неправдами вытаскиваем информацию о типе к которому преобразоввывался ubiq из оператора неявного приведения
* PROFIT: имеем количество полей внутри структуры и их типы
Обязательно постараюсь выступить на конференции и написать статью на эту тему: в коде намешано много интересных трюков и фишечек без которых работает всё плохо или не работает вообще.
* template <size_t> struct ubiq { template operator T(); };
* пробуем aggregate initialization для структуры: T { ubiq{}… }
* уменьшаем количество ubiq, первое собравшееся выражение подсказывает нам сколько полей в структуре
* правдами и неправдами вытаскиваем информацию о типе к которому преобразоввывался ubiq из оператора неявного приведения
* PROFIT: имеем количество полей внутри структуры и их типы
Обязательно постараюсь выступить на конференции и написать статью на эту тему: в коде намешано много интересных трюков и фишечек без которых работает всё плохо или не работает вообще.
>>циклические зависимости
Звучит как «мы не будем добавлять наследование из-за проблем с возможных циклическим наследованием».
Стыдоба. Само предположение о необходимости циклической ссылки будет свидетельствовать о том, что ты что-то делаешь не так.
p.s. в C# с такой задачкой справляются. Справятся и тут.
Звучит как «мы не будем добавлять наследование из-за проблем с возможных циклическим наследованием».
Стыдоба. Само предположение о необходимости циклической ссылки будет свидетельствовать о том, что ты что-то делаешь не так.
p.s. в C# с такой задачкой справляются. Справятся и тут.
Циклические зависимости вполне возможны. Модуль A может зависеть от B::bar, а модуль B — от A::foo. Ничего плохого в этом нет. Проблема разрулить такие зависимости в рамках отдельных строительных блоков, чтобы там циклов не было.
Хотя мне это конечно напоминает аргументацию за введение синтаксиса 'auto foo(...) -> ret_type' тем, что компилятор якобы должен сначала увидеть определение аргументов, чтобы вычислять на их основе тип результата.
Хотя мне это конечно напоминает аргументацию за введение синтаксиса 'auto foo(...) -> ret_type' тем, что компилятор якобы должен сначала увидеть определение аргументов, чтобы вычислять на их основе тип результата.Если бы речь шла только о «типе аргументов», то и беды особой бы не было. К сожалению C++ — это язык в котором для того, чтобы просто построить AST нужно знать является ли что-то типом, функцией или чем-то ещё (ибо
a<b>(c) может обозначать как «вычисли a < b и сравни результат с», так и «создай объект шаблонного типа a, параметрированного b и передай ему в качестве параметра c» или «вызови функцию a, параметрированную b и передай ей в качестве параметра c»).И если компилятор ещё породит ошибку — это полбеды. А если он проинтерпретирует выражение не так, как того хотел программис?
В общем это — реальная проблема. Не столько для стандарта, сколько для разработчиков, впрочем. И да — с модулями то же самое.
Подключил ccache и сборка сильно не беспокоит, а вот stack trace для ARM, x86, x86-64 мне куда полезнее.
>Подключил ccache и сборка сильно не беспокоит, а вот stack trace для ARM, x86, x86-64 мне куда полезнее.
И как помогает ccache разработчику? Человеку, который отвечает за дистрибутив да, но современные
системы сборки и так собирают только измененные файлы, или имеется ввиду распределенный для нескольких разработчиков ccache или случай сборки сильно различающихся веток одного проекта?
При этом также следует учесть, что даже перекомпиляция одного файла используещего буст (без precompiled header) вполне может 10 секунд занимать на не слабом железе (i7/16 GB RAM/SSD),
конечно кэширование объектный файлов (ccache)
и распределение сборки по кластеру (distcc) в какой-то мере спасают положение, но не до конца.
У каждого из них есть свои недостатки, кэширование слабо поможет если изменение вызывает перекомпиляцию
нескольких файлов, а dictcc не вариант если расходы на передачу input/output компилятора по сети сравнимы
с временем компиляции.
>stack trace для ARM, x86, x86-64 мне куда полезнее
ИМХО, stacktrace вполне можно реализовать в виде общего интерфейса плюс реализация
для каждого компилятора/runtime, конечно удобно было иметь это в std::, но проблема решается,
а вот для времени компиляции одни костыли, проблему даже на 50% не решающие.
И как помогает ccache разработчику? Человеку, который отвечает за дистрибутив да, но современные
системы сборки и так собирают только измененные файлы, или имеется ввиду распределенный для нескольких разработчиков ccache или случай сборки сильно различающихся веток одного проекта?
При этом также следует учесть, что даже перекомпиляция одного файла используещего буст (без precompiled header) вполне может 10 секунд занимать на не слабом железе (i7/16 GB RAM/SSD),
конечно кэширование объектный файлов (ccache)
и распределение сборки по кластеру (distcc) в какой-то мере спасают положение, но не до конца.
У каждого из них есть свои недостатки, кэширование слабо поможет если изменение вызывает перекомпиляцию
нескольких файлов, а dictcc не вариант если расходы на передачу input/output компилятора по сети сравнимы
с временем компиляции.
>stack trace для ARM, x86, x86-64 мне куда полезнее
ИМХО, stacktrace вполне можно реализовать в виде общего интерфейса плюс реализация
для каждого компилятора/runtime, конечно удобно было иметь это в std::, но проблема решается,
а вот для времени компиляции одни костыли, проблему даже на 50% не решающие.
Мне кажется, что аналог cargo бы дал возможность обкатывать любые хотелки на кошках, иметь набор кроссплатформенных библиотек и не тащить всё вообще в std.
При этом также следует учесть, что даже перекомпиляция одного файла используещего буст (без precompiled header) вполне может 10 секунд занимать на не слабом железе (i7/16 GB RAM/SSD),Я надеюсь, вы это не под Windows меряете? То, что у Windows томозная файловая система — не повод вставлять костыли кругом.
Я наблюдал долгую компиляцию при использовании
boostа, но там было дело далеко не в заголовках и вовсе не факт, что модули сделали бы компиляцию заметно быстрее: распутывать всё это метопрограммирование — тяжёлая задача для компилятора, единственное решение — это нормальное метапрограммирование, а не то, что у C++.Тут, я боюсь, малой кровью не отделаться — нужно менять всю систему. Rust пока кажется неплохим вариантом — надо будет посмотреть как он развиваться будет.
>Я надеюсь, вы это не под Windows меряете?
Linux, правда конечно от boost spirit другого сложно ожидать в плане времени компиляции.
>но там было дело далеко не в заголовках и вовсе не факт, что модули сделали бы компиляцию заметно >быстрее
>всё это метопрограммирование — тяжёлая задача для компилятора
Не согласен, да время компиляции одного объектного файла модули не изменят,
но мы же говорим о сборке проекта целиком и вот тут как раз модули помогут,
т.к.
>всё это метопрограммирование — тяжёлая задача для компилятора
и поэтому решать ее несколько раз это полный бред.
Решил один раз загрузив CPU на 100% и отъев несколько гигабайт RAM, так закэшируй результат.
Те же 10 секунд превращаются в 2 секунды, когда засунешь boost includes в отдельный header
файл и превратишь его в precompiled.
Linux, правда конечно от boost spirit другого сложно ожидать в плане времени компиляции.
>но там было дело далеко не в заголовках и вовсе не факт, что модули сделали бы компиляцию заметно >быстрее
>всё это метопрограммирование — тяжёлая задача для компилятора
Не согласен, да время компиляции одного объектного файла модули не изменят,
но мы же говорим о сборке проекта целиком и вот тут как раз модули помогут,
т.к.
>всё это метопрограммирование — тяжёлая задача для компилятора
и поэтому решать ее несколько раз это полный бред.
Решил один раз загрузив CPU на 100% и отъев несколько гигабайт RAM, так закэшируй результат.
Те же 10 секунд превращаются в 2 секунды, когда засунешь boost includes в отдельный header
файл и превратишь его в precompiled.
А что не так с метапрограммированием в C++?
Преимущественно ccache использую на билд под CI.
ИМХО, stacktrace вполне можно реализовать в виде общего интерфейса
Да же у Google в Breakpad этого не получилось
ccache, к сожалению, не панацея. Причём дело не в заголовоных файлах и не в модулях. У нас в проекте есть такой простенький файл golden_output.cc с одной функцией:const std::map<std::string, std::string>& ArmInsnTestReferenceResults(void) {
static const std::map<std::string, std::string> reference_results = {
{ "A", "B" },
... тут ещё 100500 строк (но меньше мегабайта) ...
{ "X", "Y" }
};
}
Я поддерживаю этот крик души (тот редкий случай, когда я был полностью согласен с Гитлером)), но направлен он явно не по адресу. Модули были представлены на рассмотрение комитету, и тот решил их не включать в C++17 (как, собственно, и остальное самое интересное, что было представлено). Национальные представители не могут «заставить» CoreWG принять другое решение. Лучшее, на что мы можем надеяться в ближайшей перспективе — это принятие модулей как TS.
Если рассмотреть вопрос модулей с более практической точки зрения, то
а) ничто не мешает их использовать уже сейчас, хоть они и не в стандарте — VS2015U1 уже умеет, clang вроде бы тоже что-то выкатывал.
б) если бы они даже вошли в стандарт, то это не значит, что их вдруг стало бы можно использовать — нужна поддержка компиляторами, и нужна поддержка библиотеками.
В общем, стандарт — это как красивая теория, а на практике мы сталкиваемся с жестокой реальностью того, что используется в основном C++11, и то не везде. C++14 еще не стало популярным (даже нет полной поддержки в MSVS), не говоря уж о C++17.
Что касается тех фич, про которые говорится в статье:
— Dynamic Library Load — не вижу большого смысла вносить это в стандарт. Фича, имхо, достаточно редкая, и она полностью закрывается замечательными библиотеками, скрывающими кишки от пользователя, типа того же Boost.DLL. Атрибут [[visible]] в стандарте при том полностью поддерживаю (я не очень понял, как там модули решат проблему с dllimport, но это отдельный разговор).
— стандартизация плоских контейнеров — это тоже решено библиотеками, но эта фича очень востребована, так что оно в стандарте вполне уместно
— класс для вывода stack trace — очень специфическая фича, и есть библиотеки в помощь. Если идти в сторону стандартизации, то было бы лучше стандартизировать ABI для описаний функций; это, к сожалению, утопично, а заставить разработчиков компиляторов поддерживать единого API над своими ABI — тоже выход.
— интерфейсы — интересно, но пока не очень ясно, чем это принципиально отличается от ABC. Меня бы больше порадовала возможность описывать в публичных заголовках классы частично (только публичные функции), если внешним потребителям не требуется знать структуру класса в памяти. Сейчас либо приходится вываливать на всеобщее обозрение кишки класса, либо делать ABC, либо колбасить Pimpl или что-то похожее.
— доступ к полям структур по индексу и базовая рефлексия — архинужно, хотя бы на уровне проитерироваться по полям структуры и узнать их имена. Но на это уже есть как минимум 2 документа, которые давно в работе. Какой-то из двух должен в конце концов дойти до стандарта.
У меня за последний год сложилось ощущение, что в стандартную библиотеку C++ хотят/пытаются внести слишком много функционала. Лучше, на мой взгляд, было бы доделать модули и сделать наконец какой-нибудь нормальный dependency manager, и выносить функционал в отдельные самодостаточные библиотечки. При этом можно сделать какой-нибудь особый namespace для «официальных» библиотек типа «isocpp/» и не менять процедуру стандартизации «официальных» модулей; пусть также они сначала пишутся и обсуждаются в рабочей группе, потом идут в LibraryWG и там монстры и корифеи их доводят до идеала. А вот потом, вместо того, чтобы увеличивать и без того огромный документ под названием C++ standard, каждый модуль может оставаться независимым мини-стандартом по типу TS, и у него будет одна реализация в одном месте вместо кучи независимых под каждый компилятор. 3 из 5 фич, упомянутых в статье, можно было бы вынести в такие вот библиотеки.
Если рассмотреть вопрос модулей с более практической точки зрения, то
а) ничто не мешает их использовать уже сейчас, хоть они и не в стандарте — VS2015U1 уже умеет, clang вроде бы тоже что-то выкатывал.
б) если бы они даже вошли в стандарт, то это не значит, что их вдруг стало бы можно использовать — нужна поддержка компиляторами, и нужна поддержка библиотеками.
В общем, стандарт — это как красивая теория, а на практике мы сталкиваемся с жестокой реальностью того, что используется в основном C++11, и то не везде. C++14 еще не стало популярным (даже нет полной поддержки в MSVS), не говоря уж о C++17.
Что касается тех фич, про которые говорится в статье:
— Dynamic Library Load — не вижу большого смысла вносить это в стандарт. Фича, имхо, достаточно редкая, и она полностью закрывается замечательными библиотеками, скрывающими кишки от пользователя, типа того же Boost.DLL. Атрибут [[visible]] в стандарте при том полностью поддерживаю (я не очень понял, как там модули решат проблему с dllimport, но это отдельный разговор).
— стандартизация плоских контейнеров — это тоже решено библиотеками, но эта фича очень востребована, так что оно в стандарте вполне уместно
— класс для вывода stack trace — очень специфическая фича, и есть библиотеки в помощь. Если идти в сторону стандартизации, то было бы лучше стандартизировать ABI для описаний функций; это, к сожалению, утопично, а заставить разработчиков компиляторов поддерживать единого API над своими ABI — тоже выход.
— интерфейсы — интересно, но пока не очень ясно, чем это принципиально отличается от ABC. Меня бы больше порадовала возможность описывать в публичных заголовках классы частично (только публичные функции), если внешним потребителям не требуется знать структуру класса в памяти. Сейчас либо приходится вываливать на всеобщее обозрение кишки класса, либо делать ABC, либо колбасить Pimpl или что-то похожее.
— доступ к полям структур по индексу и базовая рефлексия — архинужно, хотя бы на уровне проитерироваться по полям структуры и узнать их имена. Но на это уже есть как минимум 2 документа, которые давно в работе. Какой-то из двух должен в конце концов дойти до стандарта.
У меня за последний год сложилось ощущение, что в стандартную библиотеку C++ хотят/пытаются внести слишком много функционала. Лучше, на мой взгляд, было бы доделать модули и сделать наконец какой-нибудь нормальный dependency manager, и выносить функционал в отдельные самодостаточные библиотечки. При этом можно сделать какой-нибудь особый namespace для «официальных» библиотек типа «isocpp/» и не менять процедуру стандартизации «официальных» модулей; пусть также они сначала пишутся и обсуждаются в рабочей группе, потом идут в LibraryWG и там монстры и корифеи их доводят до идеала. А вот потом, вместо того, чтобы увеличивать и без того огромный документ под названием C++ standard, каждый модуль может оставаться независимым мини-стандартом по типу TS, и у него будет одна реализация в одном месте вместо кучи независимых под каждый компилятор. 3 из 5 фич, упомянутых в статье, можно было бы вынести в такие вот библиотеки.
В общем, стандарт — это как красивая теория, а на практике мы сталкиваемся с жестокой реальностью того, что используется в основном C++11, и то не везде.
Прошло всего 4 года, а стандарт уже подхватили некоторые основные игроки, новые проекты и open-source. Это молниеносная скорость для enterprise, это очень хорошая скорость для open-source.
C++14 еще не стало популярным (даже нет полной поддержки в MSVS), не говоря уж о C++17.
Насколько я помню, у них и C99 пока не поддерживается полностью. У этой компании свои цели развития, мне не известные.
У меня за последний год сложилось ощущение, что в стандартную библиотеку C++ хотят/пытаются внести слишком много функционала.
Был сделан выбор в пользу современных тенденций и требований рынка. C#, Java, Python умеют очень многое из коробки и людям это нравится по мнигим причинам, например:
* В некоторых компаниях запрещены библиотеки кроме стандартной (нужен variant/flat_set/shared_library? Пиши сам с нуля, в компании <имя практически любой ООО работающей с деньгами> спец требования к безопасности.)
* Когда пишешь что-то с чем раньше не встречался, хочется использовать что-то идущее вместе с языком, а не выбирать пару дней из N библиотек.
* Документации на стандартную библиотеку всегда больше чем на сторонние.
одна реализация в одном месте вместо кучи независимых под каждый компилятор
Одна реализация — это адище для разработчика библиотеки и медленное внесение исправлений под ошибки компиляторов. Посмотрите на количество #ifdef/#elif в коде Boost для каких-либо старых компонент… а ведь это при том, что Boost недавно отказался поддерживать некоторые античные компиляторы.
P.S.: мы тоже хотим модули :) Очень хотим!
У меня за последний год сложилось ощущение, что в стандартную библиотеку C++ хотят/пытаются внести слишком много функционала.
Был сделан выбор в пользу современных тенденций и требований рынка. C#, Java, Python умеют очень многое из коробки и людям это нравится по мнигим причинам, например:
- В некоторых компаниях запрещены библиотеки кроме стандартной (нужен variant/flat_set/shared_library? Пиши сам с нуля, в компании <имя практически любой ООО работающей с деньгами> спец требования к безопасности.)
- Когда пишешь что-то с чем раньше не встречался, хочется использовать что-то идущее вместе с языком, а не выбирать пару дней из N библиотек.
- Документации на стандартную библиотеку всегда больше чем на сторонние.
Java, project Jigsaw. С точностью до наоборот — распиливание стандартного рантайма на несколько кусков поменьше, для тех кому не надо всё.
Также, никто не тянет Spring, Hibernate, Entity Framework в стандартные библиотеки.
По поводу документации — гораздо легче воспринимать маленькие самодостаточные компоненты.
одна реализация в одном месте вместо кучи независимых под каждый компилятор
Одна реализация — это адище для разработчика библиотеки и медленное внесение исправлений под ошибки компиляторов. Посмотрите на количество #ifdef/#elif в коде Boost для каких-либо старых компонент… а ведь это при том, что Boost недавно отказался поддерживать некоторые античные компиляторы.
Зато для пользователей библиотеки адищем является целая пачка её разновидностей. А большое кол-во директив условной компиляции — следствие зоопарка компиляторов в прошлом.
> Прошло всего 4 года, а стандарт уже подхватили некоторые основные игроки, новые проекты и open-source.
А хочется еще быстрее и еще больше ) Хочется async await, а приходится использовать gcc 4.7, в котором и C++11 не до конца допилен. Грустные реалии промышленного программирования.
> Насколько я помню, у них и C99 пока не поддерживается полностью.
В 2013 версии с C99 все стало гораздо лучше (хотя может быть все еще не полностью, утверждать не буду).
> Был сделан выбор в пользу современных тенденций и требований рынка…
Я имел в виду сделать некий набор официальных библиотек, которые бы стандартизировались по тем же принципам, что сейчас идет стандартизация в общий стандарт, и поддерживались производителями компиляторов. Соответственно — проблемы с безопасностью не больше, чем при использовании стандартной библиотеки компилятора (пишут те же люди); нет проблемы с выбором среди N библиотек — есть 1 официальная; документация на такие библиотеки тоже будет хорошей.
Из плюсов — меньше времени будет тратиться на добавление фич и их модификацию (я имею в виду спецификацию фичи — нет привязки к 3-годичному циклу общего стандарта); качество реализации каждой фичи будет выше (ибо не N реализаций от N команд, а 1 реализация от N команд; и пользователей кода соответственно X, а не X/N); баги в реализации будут фикситься быстрее (нет привязки к релизу следующей версии компилятора).
Из минусов — да, больше #ifdef/костылей под разные компиляторы (хотя буст в этом смысле не показатель — он пытается поддерживать старые компиляторы, а здесь производитель компилятора может просто не заявлять поддержку старых версий — как это и делается сейчас в стандартной библиотеке); меньше давление на производителя компилятора по поддержке новых стандартных библиотек (хотя и сейчас это их не останавливает — case in point MSVC и C99/expression SFINAE). На примере Boost.DLL — вроде бы самодостаточный модуль без каких-либо зависимостей (и он вполне может пройти все круги стандартизации за пару лет), но в лучшем случае это попадет в C++20; и даже после этого мы будем ждать, пока msvs/gcc/clang/icc реализуют эту часть стандарта у себя и выпустят очередные релизы, или использовать полифиллы из того же Boost. А можно было бы выпустить TS где-нибудь к 18 году и подождать, пока кто-то один/два из производителей накропает одну реализацию, которая скорее всего заработает со всеми остальными.
А хочется еще быстрее и еще больше ) Хочется async await, а приходится использовать gcc 4.7, в котором и C++11 не до конца допилен. Грустные реалии промышленного программирования.
> Насколько я помню, у них и C99 пока не поддерживается полностью.
В 2013 версии с C99 все стало гораздо лучше (хотя может быть все еще не полностью, утверждать не буду).
> Был сделан выбор в пользу современных тенденций и требований рынка…
Я имел в виду сделать некий набор официальных библиотек, которые бы стандартизировались по тем же принципам, что сейчас идет стандартизация в общий стандарт, и поддерживались производителями компиляторов. Соответственно — проблемы с безопасностью не больше, чем при использовании стандартной библиотеки компилятора (пишут те же люди); нет проблемы с выбором среди N библиотек — есть 1 официальная; документация на такие библиотеки тоже будет хорошей.
Из плюсов — меньше времени будет тратиться на добавление фич и их модификацию (я имею в виду спецификацию фичи — нет привязки к 3-годичному циклу общего стандарта); качество реализации каждой фичи будет выше (ибо не N реализаций от N команд, а 1 реализация от N команд; и пользователей кода соответственно X, а не X/N); баги в реализации будут фикситься быстрее (нет привязки к релизу следующей версии компилятора).
Из минусов — да, больше #ifdef/костылей под разные компиляторы (хотя буст в этом смысле не показатель — он пытается поддерживать старые компиляторы, а здесь производитель компилятора может просто не заявлять поддержку старых версий — как это и делается сейчас в стандартной библиотеке); меньше давление на производителя компилятора по поддержке новых стандартных библиотек (хотя и сейчас это их не останавливает — case in point MSVC и C99/expression SFINAE). На примере Boost.DLL — вроде бы самодостаточный модуль без каких-либо зависимостей (и он вполне может пройти все круги стандартизации за пару лет), но в лучшем случае это попадет в C++20; и даже после этого мы будем ждать, пока msvs/gcc/clang/icc реализуют эту часть стандарта у себя и выпустят очередные релизы, или использовать полифиллы из того же Boost. А можно было бы выпустить TS где-нибудь к 18 году и подождать, пока кто-то один/два из производителей накропает одну реализацию, которая скорее всего заработает со всеми остальными.
Немного офф.топ: а как вы в компании и другие читатели, пишущие на C++, относитесь к rust? Есть вероятность применения, в ближайшем будущем, в продакшене вместо C++?
Я не могу говорить за всю компанию, моё мнение такое: Rust можно будет использовать в продакшне сразу после того, как в Rust сделают IDE и доделают инкрементальную компиляцию. Это случится, я думаю, приблизительно в течение года-двух. До того, как эти фичи будут реализованы, Rust проблематично использовать в больших долгоживущих проектах. После того, как эти фичи будут реализованы, C++ можно будет постепенно закапывать.
Впрочем, есть небольшой шанс, что в C++ добавят основные фичи Rust (в первую очередь borrowed pointers; сделают модули вместо препроцессора и доделают «концепты»), и Rust станет не нужен.
Впрочем, есть небольшой шанс, что в C++ добавят основные фичи Rust (в первую очередь borrowed pointers; сделают модули вместо препроцессора и доделают «концепты»), и Rust станет не нужен.
Не добавят. Lifetimes начисто противоречат как минимум copy by default в C++, к тому же придётся мучительно аннотировать весь код чтобы это работало. Концепты в Rust есть уже сейчас в виде Traits & Trait impls. Модули добавят хорошо если к 20-му году. Препроцессор останется с нами навсегда во имя совместимости. Аналога же Cargo вообще не предвидится в обозримом будущем.
Короче, единственное КМК что держит С++ на плаву — огромное сообщество и гигатонны уже написанного кода. Плюс несоместимость С++ ни с кем кроме С++. Такой себе Language lock-in.
> Lifetimes начисто противоречат как минимум copy by default в C++
Не вижу противоречий. Поясни?
> к тому же придётся мучительно аннотировать весь код чтобы это работало
Не мучительнее, чем в Rust.
> Препроцессор останется с нами навсегда во имя совместимости.
Пусть остаётся. Но пользоваться им будет не обязательно.
> Аналога же Cargo вообще не предвидится в обозримом будущем.
Вот уж совсем не проблема языка C++. Cargo не требует стандартизации даже.
> несоместимость С++ ни с кем кроме С++. Такой себе Language lock-in.
Это утверждение справедливо для любого другого языка программирования.
> единственное КМК что держит С++ на плаву — огромное сообщество и гигатонны уже написанного кода
C++ на данный момент — единственный инструмент, который позволяет эффективно писать производительный код, и причина вовсе не в legacy.
Не вижу противоречий. Поясни?
> к тому же придётся мучительно аннотировать весь код чтобы это работало
Не мучительнее, чем в Rust.
> Препроцессор останется с нами навсегда во имя совместимости.
Пусть остаётся. Но пользоваться им будет не обязательно.
> Аналога же Cargo вообще не предвидится в обозримом будущем.
Вот уж совсем не проблема языка C++. Cargo не требует стандартизации даже.
> несоместимость С++ ни с кем кроме С++. Такой себе Language lock-in.
Это утверждение справедливо для любого другого языка программирования.
> единственное КМК что держит С++ на плаву — огромное сообщество и гигатонны уже написанного кода
C++ на данный момент — единственный инструмент, который позволяет эффективно писать производительный код, и причина вовсе не в legacy.
>> Lifetimes начисто противоречат как минимум copy by default в C++
> Не вижу противоречий. Поясни?
Может, не совсем правильно выразил свою мысль. Попробую написать более развёрнуто.
Во-первых, тот самый copy by default. В С++ «первичны» именно байтики, составляющие значение, а не само значение, с его семантикой и смысловой нагрузкой. Выражается это в том, что без дополнительных телодвижений значение любого типа будет банально копироваться. Делая «умный указатель», надо не забыть в обязательном порядке или запретить копирование, или правильно его обработать. Как следствие — можно схлопотать implicit copy, после чего дважды уничтожение одного и того же значения. Напротив, в Rust происходит move by default. Т.е. хочешь сделать копию — явно опиши как, а если не нужно — не будет лишних ошибок.
Во-вторых, значения «после перемещения» — т.е. значения, из которых полезную информацию переместили. Но какой-то мусор остался. И этот мусор должен быть корректно обработан деструктором.
В-третьих, тот самый borrowing. А конкретно его сложные случаи, когда заимствованная ссылка попадает внутрь структуры. В Rust в таком случае лайфтайм должен быть явно указан в типе структуры. В С++ как разрешать подобный случай — непонятно.
В-четвёртых, тонны старого кода, который про такие штуки ничего не знает. Считать отсутствие аннотаций ошибкой? Пропускать? Сделать аннотацию «не проверять аннотации»?
В общем, чисто теоретически можно написать для С++ стороннюю утилиту, которая будет выполнять проверки на время жизни. Но геморроя будет слишком много. Просто потому, что система типов С++ проектировалась на максимальную совместимость с С, а значит значения (как я писал выше) там рассматриваются скорее как пачки байт. Как результат — низкоуровневые уши торчат наружу. В то же время в Rust семантика значения первична на уровне с его представлением.
>> к тому же придётся мучительно аннотировать весь код чтобы это работало
> Не мучительнее, чем в Rust.
Компилятор обругает за каждое пропущенное место. Как поступать с пропусками аннотаций в С++ — неясно.
>> Препроцессор останется с нами навсегда во имя совместимости.
> Пусть остаётся. Но пользоваться им будет не обязательно.
Макро-константы. Их валом до сих пор.
>> Аналога же Cargo вообще не предвидится в обозримом будущем.
> Вот уж совсем не проблема языка C++. Cargo не требует стандартизации даже.
Верно. Однако IDE вы, например, хотите. Как инструмент, конечно. Стандартизировать IDE нет никакого смысла. Но почему тогда C++ — фактически единственный язык без вменяемого тулчейна для сборки и доставки зависимостей? Хотя бы как стандарта де-факто?
>> несоместимость С++ ни с кем кроме С++. Такой себе Language lock-in.
> Это утверждение справедливо для любого другого языка программирования.
В принципе да. Конкретно этот мой аргумент наверное несостоятелен. Генератора биндингов из Python в Ruby я не видел :)
>> единственное КМК что держит С++ на плаву — огромное сообщество и гигатонны уже написанного кода
> C++ на данный момент — единственный инструмент, который позволяет эффективно писать производительный код, и причина вовсе не в legacy.
Не совсем. Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.
Короче, в С++ накопилось слишком много проблем, часть из них не имеют адекватного решения без поломки обратной совместимости.
> Не вижу противоречий. Поясни?
Может, не совсем правильно выразил свою мысль. Попробую написать более развёрнуто.
Во-первых, тот самый copy by default. В С++ «первичны» именно байтики, составляющие значение, а не само значение, с его семантикой и смысловой нагрузкой. Выражается это в том, что без дополнительных телодвижений значение любого типа будет банально копироваться. Делая «умный указатель», надо не забыть в обязательном порядке или запретить копирование, или правильно его обработать. Как следствие — можно схлопотать implicit copy, после чего дважды уничтожение одного и того же значения. Напротив, в Rust происходит move by default. Т.е. хочешь сделать копию — явно опиши как, а если не нужно — не будет лишних ошибок.
Во-вторых, значения «после перемещения» — т.е. значения, из которых полезную информацию переместили. Но какой-то мусор остался. И этот мусор должен быть корректно обработан деструктором.
В-третьих, тот самый borrowing. А конкретно его сложные случаи, когда заимствованная ссылка попадает внутрь структуры. В Rust в таком случае лайфтайм должен быть явно указан в типе структуры. В С++ как разрешать подобный случай — непонятно.
В-четвёртых, тонны старого кода, который про такие штуки ничего не знает. Считать отсутствие аннотаций ошибкой? Пропускать? Сделать аннотацию «не проверять аннотации»?
В общем, чисто теоретически можно написать для С++ стороннюю утилиту, которая будет выполнять проверки на время жизни. Но геморроя будет слишком много. Просто потому, что система типов С++ проектировалась на максимальную совместимость с С, а значит значения (как я писал выше) там рассматриваются скорее как пачки байт. Как результат — низкоуровневые уши торчат наружу. В то же время в Rust семантика значения первична на уровне с его представлением.
>> к тому же придётся мучительно аннотировать весь код чтобы это работало
> Не мучительнее, чем в Rust.
Компилятор обругает за каждое пропущенное место. Как поступать с пропусками аннотаций в С++ — неясно.
>> Препроцессор останется с нами навсегда во имя совместимости.
> Пусть остаётся. Но пользоваться им будет не обязательно.
Макро-константы. Их валом до сих пор.
>> Аналога же Cargo вообще не предвидится в обозримом будущем.
> Вот уж совсем не проблема языка C++. Cargo не требует стандартизации даже.
Верно. Однако IDE вы, например, хотите. Как инструмент, конечно. Стандартизировать IDE нет никакого смысла. Но почему тогда C++ — фактически единственный язык без вменяемого тулчейна для сборки и доставки зависимостей? Хотя бы как стандарта де-факто?
>> несоместимость С++ ни с кем кроме С++. Такой себе Language lock-in.
> Это утверждение справедливо для любого другого языка программирования.
В принципе да. Конкретно этот мой аргумент наверное несостоятелен. Генератора биндингов из Python в Ruby я не видел :)
>> единственное КМК что держит С++ на плаву — огромное сообщество и гигатонны уже написанного кода
> C++ на данный момент — единственный инструмент, который позволяет эффективно писать производительный код, и причина вовсе не в legacy.
Не совсем. Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.
Короче, в С++ накопилось слишком много проблем, часть из них не имеют адекватного решения без поломки обратной совместимости.
> Во-первых, тот самый copy by default.
Не вижу, как это противоречит lifetimes. В Rust, кстати, для POD-типов copy by default тоже бывает, и lifetimes в нём работают.
> Во-вторых, значения «после перемещения» — т.е. значения, из которых полезную информацию переместили. Но какой-то мусор остался. И этот мусор должен быть корректно обработан деструктором.
Не вижу, как это противоречит lifetimes.
> В-третьих, тот самый borrowing. А конкретно его сложные случаи, когда заимствованная ссылка попадает внутрь структуры. В Rust в таком случае лайфтайм должен быть явно указан в типе структуры. В С++ как разрешать подобный случай — непонятно.
Очевидно, ввести новый синтаксис. Можно прямо синтаксис из rust заимствовать.
> В-четвёртых, тонны старого кода, который про такие штуки ничего не знает. Считать отсутствие аннотаций ошибкой? Пропускать? Сделать аннотацию «не проверять аннотации»?
Всё, что написано в текущем синтаксисе, не проверять. Если lifetimes присутствуют, то проверять. Сделать warning в компиляторе — указатели без lifetime. Сделать опцию сделать такой warning ошибкой.
> Просто потому, что система типов С++ проектировалась на максимальную совместимость с С, а значит значения (как я писал выше) там рассматриваются скорее как пачки байт… Как результат — низкоуровневые уши торчат наружу
Что следует из того, что «низкоуровневые уши торчат наружу»? Всё, что вы пишете, это то, что вам кажется, что lifetimes в C++ добавить нельзя. Здесь отсутствуют аргументы по существу, простите.
> Макро-константы. Их валом до сих пор.
Ну придумают что-нибудь. Если уж даже из Python можно эти константы использовать, то и из C++ можно будет.
> Но почему тогда C++ — фактически единственный язык без вменяемого тулчейна для сборки и доставки зависимостей? Хотя бы как стандарта де-факто?
Я думаю, отсутствие Cargo — это следствие того, что на C++ неудобно писать. Не хотят хипстеры писать на C++, вот и нет единой популярной системы сборки и доставки зависимостей.
> Не совсем. Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.
Это common misconception. В Go есть GC, что делает его непригодным для большого числа задач.
Не вижу, как это противоречит lifetimes. В Rust, кстати, для POD-типов copy by default тоже бывает, и lifetimes в нём работают.
> Во-вторых, значения «после перемещения» — т.е. значения, из которых полезную информацию переместили. Но какой-то мусор остался. И этот мусор должен быть корректно обработан деструктором.
Не вижу, как это противоречит lifetimes.
> В-третьих, тот самый borrowing. А конкретно его сложные случаи, когда заимствованная ссылка попадает внутрь структуры. В Rust в таком случае лайфтайм должен быть явно указан в типе структуры. В С++ как разрешать подобный случай — непонятно.
Очевидно, ввести новый синтаксис. Можно прямо синтаксис из rust заимствовать.
> В-четвёртых, тонны старого кода, который про такие штуки ничего не знает. Считать отсутствие аннотаций ошибкой? Пропускать? Сделать аннотацию «не проверять аннотации»?
Всё, что написано в текущем синтаксисе, не проверять. Если lifetimes присутствуют, то проверять. Сделать warning в компиляторе — указатели без lifetime. Сделать опцию сделать такой warning ошибкой.
> Просто потому, что система типов С++ проектировалась на максимальную совместимость с С, а значит значения (как я писал выше) там рассматриваются скорее как пачки байт… Как результат — низкоуровневые уши торчат наружу
Что следует из того, что «низкоуровневые уши торчат наружу»? Всё, что вы пишете, это то, что вам кажется, что lifetimes в C++ добавить нельзя. Здесь отсутствуют аргументы по существу, простите.
> Макро-константы. Их валом до сих пор.
Ну придумают что-нибудь. Если уж даже из Python можно эти константы использовать, то и из C++ можно будет.
> Но почему тогда C++ — фактически единственный язык без вменяемого тулчейна для сборки и доставки зависимостей? Хотя бы как стандарта де-факто?
Я думаю, отсутствие Cargo — это следствие того, что на C++ неудобно писать. Не хотят хипстеры писать на C++, вот и нет единой популярной системы сборки и доставки зависимостей.
> Не совсем. Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.
Это common misconception. В Go есть GC, что делает его непригодным для большого числа задач.
lifetimes
Я не могу, конечно, строго доказать, что в С++ в принципе нельзя добавить borrow checker. Но количество проблем и нестыковок будет просто зашкаливать. Не вижу смысла получать в стандарт ещё +200 страниц. Он и так толстый.
Ну придумают что-нибудь. Если уж даже из Python можно эти константы использовать, то и из C++ можно будет.
Поживём-увидим.
Я думаю, отсутствие Cargo — это следствие того, что на C++ неудобно писать. Не хотят хипстеры писать на C++, вот и нет единой популярной системы сборки и доставки зависимостей.
А вот мне хотелось бы писать на С++ удобно. А не танцевать с бубном, выбирая из нескольких вариантов подключить тот же Google Test. Java как бы тоже не хипстерная вещь, однако же есть Maven и его репозитории.
Это common misconception. В Go есть GC, что делает его непригодным для большого числа задач.
ответил здесь: https://habrahabr.ru/company/yandex/blog/301514/#comment_9623684
Что следует из того, что «низкоуровневые уши торчат наружу»? Всё, что вы пишете, это то, что вам кажется, что lifetimes в C++ добавить нельзя. Здесь отсутствуют аргументы по существу, простите.
Как обеспечить обратную совместимости при введении в язык lifetimes? Ведь это фича, которая сильно сужает множество принимаемых компилятором программ, а не наоборот. А нужно чтобы старый код продолжал работать.
Получается поддержка lifetimes — вирусная фича, которая не позволит внутри себя использовать старый код. Такое мы проходили — называется constexpr. Его ввели в C++11, но продолжают активно допиливать в C++14, C++17. А STL так и не допилили, поэтому придумали Sprout. При этом из нового синтаксиса там лишь одно ключевое слово, что явно будет мало для lifetimes.
Так что если оно и будет в C++, то не раньше C++30. И это оптимистичная оценка :) Вот концепты старый код не ломают, а их уже лет 10 принять не могут.
Если не нужно жёсткое «байтоложество», то тот же Golang вполне подходит, несмотря на свой минимализм.Не подходит. Есть куча мест, где GC нельзя использовать. По разным причинам. Так что Golang на замену C/C++ не претендует и никогда не претендовал. D отпадает по той же причине (практически он без GC работать может, практически — стандартная библиотека идёт лесом). Rust — теоретически может. Посмотрим как оно выйдет на практике.
Сейчас уже пара полу IDEшек на расте есть, тем же vs code можно очень активно пользоваться. Главная проблема тут в отсутствии дебага. Насчет компиляции, то можно и нужно разделять большие проекты на маленькие модули, тогда и компилируется быстро и архитектура лучше.
Можно вообще мысленно сделать соответствие класс на с++ == модуль на расте. Благо пишутся они элементарно.
Насчет плюсов не уверен, что это поможет. Слишком большую телегу из старых костылей с собой таскать приходится.
> Сейчас уже пара полу IDEшек на расте есть, тем же vs code можно очень активно пользоваться
Эти «IDEшки» пока больше похожи на редакторы с подсветкой синтаксиса, чем на полноценные инструменты для работы с большой кодовой базой.
> Главная проблема тут в отсутствии дебага
Нет, главная проблема в том, что в этих «IDEшках» отсутствуют примерно 99% фич, которые присутствуют в современных IDE типа JetBrains IDEA.
А дебаг редко нужен, только в очень специфичных случаях. Тесты надо писать.
> Насчет компиляции, то можно и нужно разделять большие проекты на маленькие модули, тогда и компилируется быстро и архитектура лучше
Сомнительный совет — переписать код, чтобы исправить тормоза компилятора.
В любом случае, этот совет в общем случае не работает. Далеко не все проекты распиливаются на осмысленные маленькие модули.
Эти «IDEшки» пока больше похожи на редакторы с подсветкой синтаксиса, чем на полноценные инструменты для работы с большой кодовой базой.
> Главная проблема тут в отсутствии дебага
Нет, главная проблема в том, что в этих «IDEшках» отсутствуют примерно 99% фич, которые присутствуют в современных IDE типа JetBrains IDEA.
А дебаг редко нужен, только в очень специфичных случаях. Тесты надо писать.
> Насчет компиляции, то можно и нужно разделять большие проекты на маленькие модули, тогда и компилируется быстро и архитектура лучше
Сомнительный совет — переписать код, чтобы исправить тормоза компилятора.
В любом случае, этот совет в общем случае не работает. Далеко не все проекты распиливаются на осмысленные маленькие модули.
Вы думаете, полноценная IDE для Rust появится за год-два? Я думаю, что не появится. Без коммерческой поддержки компаний, заинтересованных в языке, не появится. JetBrains, на сколько я знаю, ничего такого пока не планируют.
> Вы думаете, полноценная IDE для Rust появится за год-два?
Если сделают IDE server, который делает 80% работы, то достаточно хорошая IDE появится быстро.
> Без коммерческой поддержки компаний, заинтересованных в языке, не появится. JetBrains, на сколько я знаю, ничего такого пока не планируют.
Сегодня не планируют, завтра запланируют. Для typescript сделали, для groovy сделали, и для rust сделают.
Если сделают IDE server, который делает 80% работы, то достаточно хорошая IDE появится быстро.
> Без коммерческой поддержки компаний, заинтересованных в языке, не появится. JetBrains, на сколько я знаю, ничего такого пока не планируют.
Сегодня не планируют, завтра запланируют. Для typescript сделали, для groovy сделали, и для rust сделают.
Непонятно ещё, почему у яндекса нет своего ЯИСТ, не хватает амбиций чтоли? Не плодят велосипедов? А чё Мозилла плодит, дураки чтоли?
Mozilla — некоммерческая компания, она не ставить целью зарабатывание денег, поэтому может позволить себе такие проекты.
Кто сказал что нет…
Просто мы не изобретаем ненужных велосипедов общего пользования, наш язык заточен под очень специфичные нужды и будет интересен разве что конкурентам. Он даже на язык программирования не особо похож, очень много позаимствовано из визуального программирования.
Просто мы не изобретаем ненужных велосипедов общего пользования, наш язык заточен под очень специфичные нужды и будет интересен разве что конкурентам. Он даже на язык программирования не особо похож, очень много позаимствовано из визуального программирования.
Понятно, спасибо.
Но всё же языки и платформы появляются чаще, чем можно обосновать догмой про велосипеды, значит, это выгодно, тому же гуглу с его golang.
Но всё же языки и платформы появляются чаще, чем можно обосновать догмой про велосипеды, значит, это выгодно, тому же гуглу с его golang.
Гугл создал Go не потому, что он Гугл, а потому что там работает Роб Пайк. И то язык получился достаточно специфическим и назвать его «языком общего назначения», скорее нельзя.
Создавать языки — это легко и весело, а вот создавать языки, которые могли бы встать в один ряд с «большими» языками типа C++ — это тяжело.
Создавать языки — это легко и весело, а вот создавать языки, которые могли бы встать в один ряд с «большими» языками типа C++ — это тяжело.
UFO just landed and posted this here
Я бы очень даже за. Даже всерьёз начал переделывать один микросервис, просто посмотреть как пойдёт. Остановили генерация биндингов (непонятно что делать с кучей констант, заданных макросами; автора макро-констант убить мало) и zeroing drops — т.е. объект с деструктором распухает, а мне это сильно мешало делать обёртки над хендлами.
Новость действительно хорошая. Примите мои поздравления.
UFO just landed and posted this here
Как-то вы видите всё в мрачном свете. Давайте я распишу процесс поподробнее:
1) Вы хотите добавить в стандарт std:: что-то
2) Пишете proposal, мы вам помогаем (если хотите). Автором proposal являетесь Вы, ваше имя в нём стоит, Яндекс никак не упоминается.
3) Не можете поехать на заседание комитета сами — мы готовы представлять ваши интересы. Мы задаём вам кучу вопросов по предложению, слушаем ваши идеи и пожелания. Защищаем ваши интересы на заседании, отстаиваем ваши идеи. Если остальные члены комитета против — будем ловить их в свободное время и спрашивать что именно им не понравилось в предложении. Все их хотелки и пожелания — передаем вам, говорим как можно подправить proposal.
4) Повторяем процесс до тех пор пока proposal не примут или вам не надоест :)
И на этом всё. Если мы хотим добавить что-то своё, то процесс для нас такой же, как и для обычного программиста и нам надо goto 1).
1) Вы хотите добавить в стандарт std:: что-то
2) Пишете proposal, мы вам помогаем (если хотите). Автором proposal являетесь Вы, ваше имя в нём стоит, Яндекс никак не упоминается.
3) Не можете поехать на заседание комитета сами — мы готовы представлять ваши интересы. Мы задаём вам кучу вопросов по предложению, слушаем ваши идеи и пожелания. Защищаем ваши интересы на заседании, отстаиваем ваши идеи. Если остальные члены комитета против — будем ловить их в свободное время и спрашивать что именно им не понравилось в предложении. Все их хотелки и пожелания — передаем вам, говорим как можно подправить proposal.
4) Повторяем процесс до тех пор пока proposal не примут или вам не надоест :)
И на этом всё. Если мы хотим добавить что-то своё, то процесс для нас такой же, как и для обычного программиста и нам надо goto 1).
UFO just landed and posted this here
Не вижу поводов для мрачных мыслей.
Миновать Яндекс — можно. И да, никто не просил Яндекса стать представителем. Но Яндекс предлагает тем, у кого есть мысли по развитию C++ быть посредником по обсуждению в комитете этих самых мыслей — бесплатно и без смс.
Не так уж мало они при этом будут делать. Помогут с proposal, могут поехать на заседание и т.д. из комментария выше. Не так уж и мало, и ничего не прося взамен, кроме возможности попиариться.
Так что фиг с ними, пусть пиарятся.
Миновать Яндекс — можно. И да, никто не просил Яндекса стать представителем. Но Яндекс предлагает тем, у кого есть мысли по развитию C++ быть посредником по обсуждению в комитете этих самых мыслей — бесплатно и без смс.
Не так уж мало они при этом будут делать. Помогут с proposal, могут поехать на заседание и т.д. из комментария выше. Не так уж и мало, и ничего не прося взамен, кроме возможности попиариться.
Так что фиг с ними, пусть пиарятся.
Можно ли на эту рассылку подписаться?
UFO just landed and posted this here
Или добавить в стандарт линковку через наши духовные скрепы, например. Но как я понял что это просто помощь в продвижении предложений в стандарт с нашими региональными особенностями: не всякий наш разработчик способный предложить улучшение языка сможет пройти все формальности включая присутствие на комитетах. Кроме того будет кто-то русскоязычный с кем можно проконсультироваться как правильно оформить само предложение.
Упор только внутри вашей головы. А в заголовке обычный факт.
UFO just landed and posted this here
Вы не путайте поляны, если американцы не указывают на всех табличках, что это американская корпорация, это не значит, что корпорация перестала быть американской. Это значит, что для американцев Америка это дефолт-стейт. Полноценная страна в которой может быть создано вообще всё. Поэтому и указывать не надо. Как Москва для москвичей.
Если люди указали, что в российском Яндексе российские программисты представляют Россию — это просто факт. Эта ситуация даже не требует вашего околофашистского термина «ватник». Страны пока не отменили, следовательно, и заслуги стран как совокупность заслуг граждан — это констатация.
Вы не с Украины часом?
Если люди указали, что в российском Яндексе российские программисты представляют Россию — это просто факт. Эта ситуация даже не требует вашего околофашистского термина «ватник». Страны пока не отменили, следовательно, и заслуги стран как совокупность заслуг граждан — это констатация.
Вы не с Украины часом?
Сейчас модно каждой компании свой язык создавать…
Не путайте айти-метрополию и какую-то там Россию…
Ну, Россия не такая уж маленькая в смысле и финансов и рынка для Яндекса. Могли бы и свое что-то запилить. Не все же капусту рубить…
Создали бы новую открытую ветку С++ и управляли бы ею на благо себе и человечеству.
Создали бы новую открытую ветку С++ и управляли бы ею на благо себе и человечеству.
Где вы тут увидели благо?
Спасибо, но… спасибо не надо.
Я в своё время общался с преподавателями информатики, использующими ЛогоМиры, у которых диалект Лого — локализован. И у преподавателей по их поводу — одни матерные слова: так как английские ЛогоМиры понимают только английские слова, русские — только русские, а немецкие — только немецкие, то дети, участвующие во всякого рада программах «международного обмена» не могут обмениваться своими творениями!
Долгое время люди просто использовали старый добрый LogoWriter (и не рассказывали детям про локализованные ключевые слова, благо нелокализованные он тоже понимал), но после повсеместного перехода на XP пришлось от этого отказаться (совместимость XP с DOS уж очень паршивая).
И это — дети! Профессиональные программисты, уверяю вас, общаются между собой несколько чаще…
Я в своё время общался с преподавателями информатики, использующими ЛогоМиры, у которых диалект Лого — локализован. И у преподавателей по их поводу — одни матерные слова: так как английские ЛогоМиры понимают только английские слова, русские — только русские, а немецкие — только немецкие, то дети, участвующие во всякого рада программах «международного обмена» не могут обмениваться своими творениями!
Долгое время люди просто использовали старый добрый LogoWriter (и не рассказывали детям про локализованные ключевые слова, благо нелокализованные он тоже понимал), но после повсеместного перехода на XP пришлось от этого отказаться (совместимость XP с DOS уж очень паршивая).
И это — дети! Профессиональные программисты, уверяю вас, общаются между собой несколько чаще…
Кстати, да: может, попробовать Dlang использовать (ну, и улучшить попутно)? Сейчас D чуть медленней Явы бегает, а синтаксически и семантически хорош.
Насколько мне известно, в комитете по стандартизации C++ Россию представляли Евгений Александрович Зуев и компания «Интерстрон». Как-то упустил момент передачи эстафетной палочки. «Яндекс» как-то сотрудничает в этом плане с «Интерстроном»?
Первое, что приходит на ум, это класс для вывода stack trace
Это плохое предложение. Даже игнорируя вопрос "а чем выбор нестандартных библиотек плох?", не всегда по скомпилированному бинарнику можно этот самый stack trace получить, в релизной сборке читай никогда. Получается этот класс пригоден только для отладки, а значит относится не к языку, а к инструментам разработки.
Правильный путь — использовать out-of-process breakpad (или альтернативу, которую я не знаю) и генерировать minidump-ы. Парсить стек можно уже спокойно на crashdump сервере в режиме оффлайн (с использованием debug symbols). Так мы минимизируем вероятность ошибки при диагностике ошибки и не загружаем основной процесс не его работой.
Что касается стектрейса в catch блоке — его получить нельзя, т.к. к моменту захода в catch стека уже нет. Генерировать стек в throw — огромный оверхед. Кроме того — что считать стеком dependent (rethrow) исключения? Но если почитать вуду c++ — то можно придумать решение. Для себя я как наиболее оптимальное придумал такой вариант — делать прослойку в стеке вызовов со специальной personality routine, которая отлавливает исключения в search phase и делает снапшот (minidump). Такую прослойку ставить в начало стека, где стоит catch-all обработчик. Получается, что в случае необработанного исключения мы и не падаем (с std::terminate), и стек трейс имеем. Могу подробнее написать об это статью :)
Напишите статью по использованию breakpad, а то тут человек говорил про breakpad, не имея опыта применения его в продакшене.
> не всегда по скомпилированному бинарнику можно этот самый stack trace получить, в релизной сборке читай никогда
При наличии в бинарнике async unwind tables вроде бы должно быть можно, не?
Статью — просим нижайше, очень интересная тема. И про breakpad, и про сбор стека в полете исключения.
У нас есть костыль, пишущий минидампы, на базе SEH-обработчика, но хотелось бы чего-то более C++ного и универсального. Если оно еще и под *nix сумеет асинхронные сигналы перехватывать и дампить (и давить потом, чтобы можно было как-то попытаться восстановиться) — вдвойне интересно
При наличии в бинарнике async unwind tables вроде бы должно быть можно, не?
Статью — просим нижайше, очень интересная тема. И про breakpad, и про сбор стека в полете исключения.
У нас есть костыль, пишущий минидампы, на базе SEH-обработчика, но хотелось бы чего-то более C++ного и универсального. Если оно еще и под *nix сумеет асинхронные сигналы перехватывать и дампить (и давить потом, чтобы можно было как-то попытаться восстановиться) — вдвойне интересно
Новость хорошая, сам бы с удовольствием посотрудничал.
Но… Смущает то, что раньше в Яндексе было всё печально с языком C++. Вы уже перешли массово хотя бы на C++11? Как поживают ya::strochka и ya::shtrochka?
> Вы уже перешли массово хотя бы на C++11?
Конечно перешли.
> Как поживают ya::strochka и ya::shtrochka?
Наши внутренние библиотеки живы и активно развиваются, если вы об этом. Даже те, которые появилась до STL, во времена когда ещё свет не был отделён от тьмы, а мухи от котлет.
Конечно перешли.
> Как поживают ya::strochka и ya::shtrochka?
Наши внутренние библиотеки живы и активно развиваются, если вы об этом. Даже те, которые появилась до STL, во времена когда ещё свет не был отделён от тьмы, а мухи от котлет.
> Как поживают ya::strochka и ya::shtrochka?
Как вы думаете, зачем эта рабочая группа была создана?
Конечно же, пропозал на std::Stroka уже отправлен!
</joke>
Как вы думаете, зачем эта рабочая группа была создана?
Конечно же, пропозал на std::Stroka уже отправлен!
</joke>
Интересно, зачем вообще развивать этот язык, может быть стоит оставить его в покое… и обратить своё внимание на Rust хотя бы.
По прагматичным причинам в первую очередь. Например потому что браузер, в котором вы читаете это сообщение, написан на с++, и переписать его на Rust стоит миллионов человеко-дней, что довольно долго и ну очень дорого.
С вами согласен, но пример получился не очень. Rust как раз и создавался, чтобы переписать кое-какой браузер :)
Для этого не надо развивать язык, достаточно заморозить стабильную версию и с ней жить, пока она ещё нужна. Поразительный консерватизм иногда наблюдается среди прогрессивного айти-сообщества.
Зря вы человеку минусов накидали. Сам Беорн Стровструп признался, что цпп мог быть и получше, но взлетело то, что сделали на коленке. А новый код было бы здорово на D или на Rust писать (авторы обоих языков говорят, что языки уже более-менее устаканились.
D — это что-то мертворождённое, похоже. Вот, почитайте: Phobos (standard library) is deprecating features too quickly. Это месяц назад написано.
С++ уже где-то к 1990му году (то есть лет через 7-8 после создания) пришёл в состояние, когда устаревшие фичи поддерживались годами (а после выхода стандарта через 15 лет после создания языка — уже вообще почти ничего не удалялось).
Тут же… На дворе, на минуточку, 2016й год. Язык появился 15 лет назад. И он всё ещё позволяет себе менять стандартную библиотеку несовместимым образом? Это — клиника, извините.
На Rust же можно аккуратно так поглядывать. Посмотрим. Первые признаки обнадёживают, но пока с момента выхода версии 1.0 слишком мало времени прошло — год всего.
С++ уже где-то к 1990му году (то есть лет через 7-8 после создания) пришёл в состояние, когда устаревшие фичи поддерживались годами (а после выхода стандарта через 15 лет после создания языка — уже вообще почти ничего не удалялось).
Тут же… На дворе, на минуточку, 2016й год. Язык появился 15 лет назад. И он всё ещё позволяет себе менять стандартную библиотеку несовместимым образом? Это — клиника, извините.
На Rust же можно аккуратно так поглядывать. Посмотрим. Первые признаки обнадёживают, но пока с момента выхода версии 1.0 слишком мало времени прошло — год всего.
Спасибо, интересно человек пишет.
И правда, до стабильности и обратной совместимости Java D не дотягивает, совсем.
И правда, до стабильности и обратной совместимости Java D не дотягивает, совсем.
Добавлю ещё, что вот у Lisp ов (и даже CommonLisp'ов) стандартных библиотек почти нету (языку больше 50 лет). А тот библиотечный код, который есть, совместим не со всеми реализациями CommonLisp. И ничего, живут люди.
У паскалистов (к коим и себя отношу) есть всего 2 реализации ObjectPascal: от Embarcadero и от сообщества FreePascal. Обе реализации несколько несовместимы, библиотеки перетряхиваются (порой очень основательно) у обеих реализаций, но люди пользуются, главное — прибить компилятор гвоздями к проекту.
У паскалистов (к коим и себя отношу) есть всего 2 реализации ObjectPascal: от Embarcadero и от сообщества FreePascal. Обе реализации несколько несовместимы, библиотеки перетряхиваются (порой очень основательно) у обеих реализаций, но люди пользуются, главное — прибить компилятор гвоздями к проекту.
Добавлю ещё, что вот у Lisp ов (и даже CommonLisp'ов) стандартных библиотек почти нету (языку больше 50 лет). А тот библиотечный код, который есть, совместим не со всеми реализациями CommonLisp. И ничего, живут люди.Плохо живут. Энтузазисты — да, могут что-то такое на этом сваять. Но для больших проектов оно не подходит — никак.
Одно время проект GNU продвигал диалект лиспа под названием «GNU Ubiquitous Intelligent Language for Extensions». Ubiquitous, Карл! Результат? Его никто не использует. Когда в GDB засунули поддержку расширений на питоне Столлман (большой любитель Lisp'а, кстати) заставил сделать и поддержку Guile тоже — но кто про это, вообще, знает?
У паскалистов (к коим и себя отношу) есть всего 2 реализации ObjectPascal: от Embarcadero и от сообщества FreePascal. Обе реализации несколько несовместимы, библиотеки перетряхиваются (порой очень основательно) у обеих реализаций, но люди пользуются, главное — прибить компилятор гвоздями к проекту.Это — из той же серии, что и PHP: кто-то когда-то начал использовать «славный» Turbo Pascal 7.0 на уроках в школе — и предпочитает «плакать, но есть кактус» уже многие годы. У D такой форы нету: для обучения программирования его не используют, на бесплатных хостингает его не ставят… нафиг с ним связываться?
Модули пробивайте в первую очередь. Любой ценой и любым способом в С++17. Без этого развитие языка зайдет в тупик очень скоро (уже заходит). Остальное подождет, а вот без модулей совсем печально.
Это очень хорошо и для Яндекса как компании, что они вкладываются в поддержку C++ таким образом. В этом плане Яндекс довольно сильно проигрывает Google. Ведь у Google есть даже свои инструменты для C++, а у Яндекса (пока?) ничего такого нету. Будем надеяться, что появится со временем.
Кстати, на встрече в Казани будут представители Яндекса, с которыми можно будет поговорить о процессе стандартизации :)
Было бы неплохо сделать объявление прототипов функций необязательным (хотя бы в случаях, когда прототипы и функции всё равно располагаются в одном и том же файле), а также сделать возможным без танцев с бубном использовать методы объектов в качестве функций обратного вызова, например, в WinAPI.
UFO just landed and posted this here
> сделать возможным без танцев с бубном использовать методы объектов в качестве функций обратного вызова, например, в WinAPI
От такой фичи не отказались бы многие. Осталось придумать как её реализовать. У вас есть рабочий прототип или идея, как подобное воплотить в жизнь?
От такой фичи не отказались бы многие. Осталось придумать как её реализовать. У вас есть рабочий прототип или идея, как подобное воплотить в жизнь?
Реализация — дело разработчиков компиляторов/компоновщиков. Как пользователь языка я не вижу причин, почему нельзя прозрачно использовать метод как функцию обратного вызова (разные соглашения вызовов — это внутренняя кухня, которая не обязательно должна касаться пользователя).
Как пользователь языка C++ вы должны знать про функции, указатели на функции, указатели на методы — это не указатели. Подробно написано в «C++. Священные знания: второе издание, исправленное» Стивена Дьюхерста.
разные соглашения вызовов — это внутренняя кухня, которая не обязательно должна касаться пользователяСовершенно верно. Но она должна касаться составителя proposal'а. А то у вас пока предложение в стиле древнего анекдота.
А что случилось с существующим proposal'ом?
Там основная проблема в том, что нужно где-то хранить дополнительные данные, в proposal'е идёт речь об «allocator that can provide executable memory».
Почему-то все считают, что этот proposal требует нарушения W^X и вообще ужас-ужас-ужас, но в реальности переносимая версия (работающая на POSIX — то есть реально более-менее везде, кроме Windows, LOL) делается тривиально.
Делаете служебную библиотечку, скажем с тысячей thunk'ов. У каждого из них — пара инструкций, загружающих данные и вызывающих std::function. Когда bound_function создаётся — один из них захватывается и в соответствующий std::function загружаются данные для вызова. Когда bound_function освобождаются — thunk поступает обратно «в распоряжение» соответствующией подсистемы. Если нужно больше, чем тысяча таких объектов — грузите ту же самую библиотеку ещё раз (про dlopen(RTLD_LOCAL) не забываем) и получаете ещё тысячу thunk'ов.
Делов-то.
Видимо просто никому особо не нужно или выигрыш не кажется особо ощутимым…
Там основная проблема в том, что нужно где-то хранить дополнительные данные, в proposal'е идёт речь об «allocator that can provide executable memory».
Почему-то все считают, что этот proposal требует нарушения W^X и вообще ужас-ужас-ужас, но в реальности переносимая версия (работающая на POSIX — то есть реально более-менее везде, кроме Windows, LOL) делается тривиально.
Делаете служебную библиотечку, скажем с тысячей thunk'ов. У каждого из них — пара инструкций, загружающих данные и вызывающих std::function. Когда bound_function создаётся — один из них захватывается и в соответствующий std::function загружаются данные для вызова. Когда bound_function освобождаются — thunk поступает обратно «в распоряжение» соответствующией подсистемы. Если нужно больше, чем тысяча таких объектов — грузите ту же самую библиотеку ещё раз (про dlopen(RTLD_LOCAL) не забываем) и получаете ещё тысячу thunk'ов.
Делов-то.
Видимо просто никому особо не нужно или выигрыш не кажется особо ощутимым…
Звучит хорошо. Осталось продумать:
* многопоточность — всё должно рабоатать в многопоточных приложениях и при том быстро
* embedded устройства — на них держать тысячи thunkov — непозволительная роскошь
* производительность — не стоит грузить библиотеки с dlopen(RTLD_LOCAL) за спиной пользователя; идеальный вариант — без динамических аллокаций и загрузки библиотек
* как понять когда bound_function освобождается?
* многопоточность — всё должно рабоатать в многопоточных приложениях и при том быстро
* embedded устройства — на них держать тысячи thunkov — непозволительная роскошь
* производительность — не стоит грузить библиотеки с dlopen(RTLD_LOCAL) за спиной пользователя; идеальный вариант — без динамических аллокаций и загрузки библиотек
* как понять когда bound_function освобождается?
* Насчёт работы в многопоточных приложениях и при том быстро — это как-нибудь потом: всегда можно развести локальные кеши и прочее — если возникнет потребность. Чем это отличается от
* embedded устройства, которые были бы достаточно велики, чтобы позволить себе полную библиотеку C++ (влючая локализации и прочее), жёстко энфорсят W^X, но при это не могут позволить себе потратить 10-20KiB под загружаемую библиотеку? Это хде? Можно прописать в стандарте, что гарантируется обновременная работа не более «N» живых bound_function объектов и тем самым покрыть и embedded и системы без динамической аллокации памяти.
* Без динамических аллокаций и загрузки библиотек — это круто: придумаете как засунуть два байта в один (точнее восемь в четыре) — расскажите. Разработчики GNU C (где очень-очень похожая фича есть — но только в C) этого сделать не смогли, но, понятно, это не значит, что это в принципе невозможно.
Вообще код и данные во многих системах могут «жить» в разных местах, так что вариантов не так и много. Насчёт загрузки библиотек… почему когда банальный
* Не понял вопроса? Компилятор как-нибудь разберётся. Когда деструктор вызывается — это, вроде как, в других частях C++ описывается… довольно подробно.
operator new, я извиняюсь?* embedded устройства, которые были бы достаточно велики, чтобы позволить себе полную библиотеку C++ (влючая локализации и прочее), жёстко энфорсят W^X, но при это не могут позволить себе потратить 10-20KiB под загружаемую библиотеку? Это хде? Можно прописать в стандарте, что гарантируется обновременная работа не более «N» живых bound_function объектов и тем самым покрыть и embedded и системы без динамической аллокации памяти.
* Без динамических аллокаций и загрузки библиотек — это круто: придумаете как засунуть два байта в один (точнее восемь в четыре) — расскажите. Разработчики GNU C (где очень-очень похожая фича есть — но только в C) этого сделать не смогли, но, понятно, это не значит, что это в принципе невозможно.
Вообще код и данные во многих системах могут «жить» в разных местах, так что вариантов не так и много. Насчёт загрузки библиотек… почему когда банальный
printf или ostream это делают это нормально, но когда это же будет делать bound_function, то это пробелема? * Не понял вопроса? Компилятор как-нибудь разберётся. Когда деструктор вызывается — это, вроде как, в других частях C++ описывается… довольно подробно.
Вообще вы правы, конечно: сделать подобную штуку — это большая работа. Концептуально всё просто и не требуется никаких изменений, собственно, в компиляторе, однако под каждый компилятор (вернее каждый ABI) всё нужно делать отдельно (thunk'и ведь имеют «нестандартный» ABI: это не variadic функции, но какие они при этом получают аргументы на входе — одному богу ведомо… и вот эти аргументы, «не поцарапав» нужно передать дальше).
На ассемблере всё отлично делается, понятно (под все известные мне архитектуры), но — это реально куча работы. Плюс с не-POSIX платформами где «на отвяжись» (берите 128 «одновременно живущих» указателей — и ни в чём себе не отказывайте) не хочется делать, нужно разобраться. Хотя собственно скорее не «с платформами», а «с платформой»: Windows… У меня сейчас доступа к Windows нет и, честно говоря, связываться ней совершенно неохота — но понятно, что без Windows практического смысла в этой фиче не будет.
Или может вы знаете какие-нибудь другие «живые» не-POSIX платформы где энфорсится W^X? Если W^X не энфорсится (а это — почти весь «малый» эмбеддед), то проблем, в общем, гораздо меньше (хотя всякие Atmel'ы с их модифицированной гарвардской архитектурой, конечно, могут кровушки подвыпить).
Потому, собственно, я и не собираюсь это продвигать в качестве proposal'а: я реально оцениваю свои возможности. Как я уже говорил: концептуально — проблема яйца выеденного не стоят, но вот чтобы довести это до чего-то, что можно реально использовать — нужно несколько человеко-месяцев работы, я боюсь.
На ассемблере всё отлично делается, понятно (под все известные мне архитектуры), но — это реально куча работы. Плюс с не-POSIX платформами где «на отвяжись» (берите 128 «одновременно живущих» указателей — и ни в чём себе не отказывайте) не хочется делать, нужно разобраться. Хотя собственно скорее не «с платформами», а «с платформой»: Windows… У меня сейчас доступа к Windows нет и, честно говоря, связываться ней совершенно неохота — но понятно, что без Windows практического смысла в этой фиче не будет.
Или может вы знаете какие-нибудь другие «живые» не-POSIX платформы где энфорсится W^X? Если W^X не энфорсится (а это — почти весь «малый» эмбеддед), то проблем, в общем, гораздо меньше (хотя всякие Atmel'ы с их модифицированной гарвардской архитектурой, конечно, могут кровушки подвыпить).
Потому, собственно, я и не собираюсь это продвигать в качестве proposal'а: я реально оцениваю свои возможности. Как я уже говорил: концептуально — проблема яйца выеденного не стоят, но вот чтобы довести это до чего-то, что можно реально использовать — нужно несколько человеко-месяцев работы, я боюсь.
Если человек-программист может создать функцию-обёртку, вызывающую нужный метод объекта, и передать указатель на эту функцию в качестве callback-функции, то, вероятно, компилятор (или, на худой конец, препроцессор) мог бы неявным образом делать что-то аналогичное автоматически.
> Мы создали рабочую группу (РГ21) на основе сотрудников Яндекса, группа является национальной зеркальной рабочей группойISO/IEC JTC1/SC22/WG21 C++.
Не могли бы вы уточнить, что конкретно это значит?
Не могли бы вы уточнить, что конкретно это значит?
Помимо центрального (международного) комитета, в каждой стране может быть свой, национальный, комитет. (Его формальная роль такова: при принятии стандарта, сначала черновик рассылается в национальные комитеты, которые могут выдвинуть свои замечания и поправки, а также голосуют за черновик). (Эти все правила устанавливает организация ISO).
Так вот, Яндекс, судя по топику, создал российский национальный комитет, в который сейчас входят сотрудники Яндекса. Теоретически, в него может также войти любая другая компания.
Также, судя по топику, сотрудники Яндекса планирую участвовать в заседаниях международного комитета (где рассматриваются пропозалы по изменению стандарта, проходят 2-3 раза в год). Получат ли она там право голоса, я не знаю.
Мы создали рассылку cpp-proposals@yandex-team.ru — свои предложения, идеи и пожелания присылайте на нее.А почему выбрано такое архаичное и неудобное средство коммуникации, как список рассылки, а не форум? Использование издавна существующих списков рассылки ещё можно более-менее оправдать традициями (хотя вот даже CSSWG недавно решилась переместить новые обсуждения на баг-трекер на GitHub), но создавать в 2016 году новый список рассылки? %)
Будет ли подсайт яндекса со списком присланных предложений, где можно будет проголосовать и обсудить предложения? Рассылка есть, но это сомнительной удобности решение, имхо.
Да, мы думаем об этом. Есть еще несколько организационных идей которые так же находятся в рассмотрении.
Когда будет продолжение курса по С++ на stepic? Желательно сменить преподавателя и усложнить задачи.
Есть новости по теме:
Мы организовываем 5 октября 2016г открытую встречу российской рабочей группы по стандартизации С++: поговорим о перспективах С++, расскажем об успехах, новинках,толкнём мозгодробильную речьрасскажем о новых техниках в мета-программировании, выслушаем ваши предложения и замечания к C++17… + многое другое.
Подробности: Открытая встреча рабочей группы по стандартизации С++
Мы организовываем 5 октября 2016г открытую встречу российской рабочей группы по стандартизации С++: поговорим о перспективах С++, расскажем об успехах, новинках,
Подробности: Открытая встреча рабочей группы по стандартизации С++
Sign up to leave a comment.
Сотрудники Яндекса будут представлять Россию в комитете по стандартизации C++