1. Как «if (init; condition)» будет взаимодействовать с объявлением переменных внутри круглых скобок if, т.е. «if(int x = foo())»?
Если нет `;` в `if`, то считается что в круглых скобках condition. Другими словами — работать будет так же, как сейчас.
2. Structured bindings… получается очень забавно — в С++ со всех сторон подошли к прямой реализации кортежей средствами языка, но видимо из-за «legacy» синтаксических особенностей так и не сделают. А так почти все есть — и списки инициализации, и pair/tuple, и вот теперь structured bindings…
Одно из предложений, которые обсуждали на собрании, как раз было что-то похожее на «кортежы средствами языка». Но это был скорее исследовательский доклад, и решено было пока продолжить исследования и посмотреть что получится.
Модули уже почти готовы (по крайней мере дело дошло до wording — «патча» к существующему стандарту). Если не будет найдено фатальных недостатков, то есть все шансы увидеть модули в C++Next.
Звучит хорошо. Осталось продумать:
* многопоточность — всё должно рабоатать в многопоточных приложениях и при том быстро
* embedded устройства — на них держать тысячи thunkov — непозволительная роскошь
* производительность — не стоит грузить библиотеки с dlopen(RTLD_LOCAL) за спиной пользователя; идеальный вариант — без динамических аллокаций и загрузки библиотек
* как понять когда bound_function освобождается?
> Вы уже перешли массово хотя бы на C++11?
Конечно перешли.
> Как поживают ya::strochka и ya::shtrochka?
Наши внутренние библиотеки живы и активно развиваются, если вы об этом. Даже те, которые появилась до STL, во времена когда ещё свет не был отделён от тьмы, а мухи от котлет.
Если очень вкратце:
* template <size_t> struct ubiq { template operator T(); };
* пробуем aggregate initialization для структуры: T { ubiq{}… }
* уменьшаем количество ubiq, первое собравшееся выражение подсказывает нам сколько полей в структуре
* правдами и неправдами вытаскиваем информацию о типе к которому преобразоввывался ubiq из оператора неявного приведения
* PROFIT: имеем количество полей внутри структуры и их типы
Обязательно постараюсь выступить на конференции и написать статью на эту тему: в коде намешано много интересных трюков и фишечек без которых работает всё плохо или не работает вообще.
В общем, стандарт — это как красивая теория, а на практике мы сталкиваемся с жестокой реальностью того, что используется в основном 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 недавно отказался поддерживать некоторые античные компиляторы.
Просто мы не изобретаем ненужных велосипедов общего пользования, наш язык заточен под очень специфичные нужды и будет интересен разве что конкурентам. Он даже на язык программирования не особо похож, очень много позаимствовано из визуального программирования.
Как-то вы видите всё в мрачном свете. Давайте я распишу процесс поподробнее:
1) Вы хотите добавить в стандарт std:: что-то
2) Пишете proposal, мы вам помогаем (если хотите). Автором proposal являетесь Вы, ваше имя в нём стоит, Яндекс никак не упоминается.
3) Не можете поехать на заседание комитета сами — мы готовы представлять ваши интересы. Мы задаём вам кучу вопросов по предложению, слушаем ваши идеи и пожелания. Защищаем ваши интересы на заседании, отстаиваем ваши идеи. Если остальные члены комитета против — будем ловить их в свободное время и спрашивать что именно им не понравилось в предложении. Все их хотелки и пожелания — передаем вам, говорим как можно подправить proposal.
4) Повторяем процесс до тех пор пока proposal не примут или вам не надоест :)
И на этом всё. Если мы хотим добавить что-то своё, то процесс для нас такой же, как и для обычного программиста и нам надо goto 1).
> Может стоит все-таки за модули побороться, а stack trace подождет?
Есть отдельная подгруппа, занимающаяся модулями в комитете по стандартизации C++. Занимаются они модулями уже очень давно, они сильно «в теме» и с модулями множество проблем о которых мало кто задумывается:
* циклические зависимости
* линковка (в стандарт в данный момент вводится понятие module level linkage в дополнение к internal и external linkage. Вводить новое определение — очень сложно, необходимо проверить как оно взаимодействует со старыми определениями, нет ли конфликтов и прочего)
* макросы и как их экспортировать
* шаблоны и как их экспортировать из модулей. А если шаблон не проинстанцированный, как его экспортировать?
* typedef|using|constexpr и прочее
и т.д.
В стандарт модули скорее всего не примут до тех пор, пока в одном из компиляторов ну будет реализована их экспериментальная поддержка. Необходимо это для того, чтобы найти и решить проблемы о которых не подумали на этапе проектирования. Поторопить тут никого не получится.
>доступ к полям структур по индексу и базовая рефлексия.
Вот за это плюс один, использовать парсер C++ или дублировать код для рефлексии
по-моему через чур.
Вам может приглянуться эта библиотечка.
Это прототип, показывающий, что уже в C++14 можно определять содержимое структуры. Как правило подобные прототипы очень хорошо влияют на голосование по предложению, так что надеемся что особых проблем с доступом к полям структур по индексу не возникнет.
Основная проблема с таким подходом для С++/С — необходимость отдавать пользователю большое количество библиотек и заголовочных файлов. Для библиотеки Boost придется отдавать более 100MB данных (точнее 100MB — это если в бинарном виде; в emscripten размер наверняка увеличится раза в два-три).
К тому же некоторые вещи очень сложно перенести в браузер (многопоточность, работа с файлами и директориями, coroutines, true random numbers).
Высокие требования к производительности тоже проблема: примеры на Boost.Spirit или Boost.GIL на среднем железе могут собираться более 20 секунд, а на сайт могут заходить и с мобильных устройств. Уж лучше собирать эти примеры на мощном удаленном сервере и быстрее показывать пользователю результат.
Обучение:
Допустим что пользователь хочет понять, нужна ли ему библиотека Boost для проекта и научиться делать простые вещи на её основе. Для обучения и экспериментов ему понадобится скачать+скомпилировать+установить библиотеку, подобрать компилятор, скачать примеры, научиться их собирать. С непривычки это может занять пару часов.
С онлайн компилятором же, пользователь получает уже всё готовое и настроенное, он готов пробовать программировать как только страница загрузится.
Эксперименты:
«О! У меня есть гениальная идея как сделать очень крутую штуку под Windows. Надо только убедиться, что подобное можно сделать и под Linux».
Перезагружаться из одной ОС в другую — занятие долгое и скучное, особенно если приходится это делать по несколько раз на дню (виртуалка конечно спасает, но на слабых ноутбуках она сильно тормозит и есть много ресурсов хост системы). Онлайн компилятор тут сильно спасает.
С русским языком в технических статьях всегда сложно. С одной стороны надо стараться писать статью на русском, с другой стороны необходимо минимально коверкать термины.
Придерживаюсь следующего (неидеального) правила:
* переводить на русский созвучные часто употребимые термины (static -> статический, class -> класс, repository -> репозитарий)
* оставлять неизменными редкие или звучащие на русском абсолютно по другому термины (inline -> встраиваемые, alignment -> выравнивание)
Насколько я помню по документации, там адреса хранятся в хэш-таблице, а соответсвенно это не перебрать миллион записей, а за константное время получить ответ.
Если нет `;` в `if`, то считается что в круглых скобках condition. Другими словами — работать будет так же, как сейчас.
Одно из предложений, которые обсуждали на собрании, как раз было что-то похожее на «кортежы средствами языка». Но это был скорее исследовательский доклад, и решено было пока продолжить исследования и посмотреть что получится.
От себя могу добавить, что не нашёл его контактов в ISO Global Directory, так что активной деятельности он не ведёт.
* многопоточность — всё должно рабоатать в многопоточных приложениях и при том быстро
* embedded устройства — на них держать тысячи thunkov — непозволительная роскошь
* производительность — не стоит грузить библиотеки с dlopen(RTLD_LOCAL) за спиной пользователя; идеальный вариант — без динамических аллокаций и загрузки библиотек
* как понять когда bound_function освобождается?
От такой фичи не отказались бы многие. Осталось придумать как её реализовать. У вас есть рабочий прототип или идея, как подобное воплотить в жизнь?
Конечно перешли.
> Как поживают ya::strochka и ya::shtrochka?
Наши внутренние библиотеки живы и активно развиваются, если вы об этом. Даже те, которые появилась до STL, во времена когда ещё свет не был отделён от тьмы, а мухи от котлет.
* template <size_t> struct ubiq { template operator T(); };
* пробуем aggregate initialization для структуры: T { ubiq{}… }
* уменьшаем количество ubiq, первое собравшееся выражение подсказывает нам сколько полей в структуре
* правдами и неправдами вытаскиваем информацию о типе к которому преобразоввывался ubiq из оператора неявного приведения
* PROFIT: имеем количество полей внутри структуры и их типы
Обязательно постараюсь выступить на конференции и написать статью на эту тему: в коде намешано много интересных трюков и фишечек без которых работает всё плохо или не работает вообще.
Прошло всего 4 года, а стандарт уже подхватили некоторые основные игроки, новые проекты и open-source. Это молниеносная скорость для enterprise, это очень хорошая скорость для open-source.
Насколько я помню, у них и C99 пока не поддерживается полностью. У этой компании свои цели развития, мне не известные.
Был сделан выбор в пользу современных тенденций и требований рынка. C#, Java, Python умеют очень многое из коробки и людям это нравится по мнигим причинам, например:
* В некоторых компаниях запрещены библиотеки кроме стандартной (нужен variant/flat_set/shared_library? Пиши сам с нуля, в компании <имя практически любой ООО работающей с деньгами> спец требования к безопасности.)
* Когда пишешь что-то с чем раньше не встречался, хочется использовать что-то идущее вместе с языком, а не выбирать пару дней из N библиотек.
* Документации на стандартную библиотеку всегда больше чем на сторонние.
Одна реализация — это адище для разработчика библиотеки и медленное внесение исправлений под ошибки компиляторов. Посмотрите на количество #ifdef/#elif в коде Boost для каких-либо старых компонент… а ведь это при том, что Boost недавно отказался поддерживать некоторые античные компиляторы.
P.S.: мы тоже хотим модули :) Очень хотим!
Просто мы не изобретаем ненужных велосипедов общего пользования, наш язык заточен под очень специфичные нужды и будет интересен разве что конкурентам. Он даже на язык программирования не особо похож, очень много позаимствовано из визуального программирования.
1) Вы хотите добавить в стандарт std:: что-то
2) Пишете proposal, мы вам помогаем (если хотите). Автором proposal являетесь Вы, ваше имя в нём стоит, Яндекс никак не упоминается.
3) Не можете поехать на заседание комитета сами — мы готовы представлять ваши интересы. Мы задаём вам кучу вопросов по предложению, слушаем ваши идеи и пожелания. Защищаем ваши интересы на заседании, отстаиваем ваши идеи. Если остальные члены комитета против — будем ловить их в свободное время и спрашивать что именно им не понравилось в предложении. Все их хотелки и пожелания — передаем вам, говорим как можно подправить proposal.
4) Повторяем процесс до тех пор пока proposal не примут или вам не надоест :)
И на этом всё. Если мы хотим добавить что-то своё, то процесс для нас такой же, как и для обычного программиста и нам надо goto 1).
Есть отдельная подгруппа, занимающаяся модулями в комитете по стандартизации C++. Занимаются они модулями уже очень давно, они сильно «в теме» и с модулями множество проблем о которых мало кто задумывается:
* циклические зависимости
* линковка (в стандарт в данный момент вводится понятие module level linkage в дополнение к internal и external linkage. Вводить новое определение — очень сложно, необходимо проверить как оно взаимодействует со старыми определениями, нет ли конфликтов и прочего)
* макросы и как их экспортировать
* шаблоны и как их экспортировать из модулей. А если шаблон не проинстанцированный, как его экспортировать?
* typedef|using|constexpr и прочее
и т.д.
В стандарт модули скорее всего не примут до тех пор, пока в одном из компиляторов ну будет реализована их экспериментальная поддержка. Необходимо это для того, чтобы найти и решить проблемы о которых не подумали на этапе проектирования. Поторопить тут никого не получится.
Вам может приглянуться эта библиотечка.
Это прототип, показывающий, что уже в C++14 можно определять содержимое структуры. Как правило подобные прототипы очень хорошо влияют на голосование по предложению, так что надеемся что особых проблем с доступом к полям структур по индексу не возникнет.
К тому же некоторые вещи очень сложно перенести в браузер (многопоточность, работа с файлами и директориями, coroutines, true random numbers).
Высокие требования к производительности тоже проблема: примеры на Boost.Spirit или Boost.GIL на среднем железе могут собираться более 20 секунд, а на сайт могут заходить и с мобильных устройств. Уж лучше собирать эти примеры на мощном удаленном сервере и быстрее показывать пользователю результат.
Обучение:
Допустим что пользователь хочет понять, нужна ли ему библиотека Boost для проекта и научиться делать простые вещи на её основе. Для обучения и экспериментов ему понадобится скачать+скомпилировать+установить библиотеку, подобрать компилятор, скачать примеры, научиться их собирать. С непривычки это может занять пару часов.
С онлайн компилятором же, пользователь получает уже всё готовое и настроенное, он готов пробовать программировать как только страница загрузится.
Эксперименты:
«О! У меня есть гениальная идея как сделать очень крутую штуку под Windows. Надо только убедиться, что подобное можно сделать и под Linux».
Перезагружаться из одной ОС в другую — занятие долгое и скучное, особенно если приходится это делать по несколько раз на дню (виртуалка конечно спасает, но на слабых ноутбуках она сильно тормозит и есть много ресурсов хост системы). Онлайн компилятор тут сильно спасает.
Придерживаюсь следующего (неидеального) правила:
* переводить на русский созвучные часто употребимые термины (static -> статический, class -> класс, repository -> репозитарий)
* оставлять неизменными редкие или звучащие на русском абсолютно по другому термины (inline
-> встраиваемые, alignment-> выравнивание)