• Рефлексия в C++14
    +1
    Сейчас на github лежит версия, которая может работать в C++14 с любыми пользовательскими типами данных и не использует их явное перечисление.

    Она является чем-то отдалённо похожим на смесь вашего предложения и того что описано в статье: github.com/apolukhin/magic_get/blob/develop/include/boost/pfr/detail/core14_loophole.hpp

    Буду рад любым предложениям по улучшению.
  • Рефлексия в C++14
    +3
    Есть рефлексия динамическая (run-time), есть статическая (compile-time).

    C++ движется в сторону статической рефлексии www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0194r3.html
  • Ещё один шажок к C++20. Встреча в Альбукерке
    +1
    Кто будет выбирать язык, в котором десятистраничные ошибки генерации типов во время компиляции — это норма?

    Должно быть починено Concepts TS, уже будет в C++20.

    За счёт чего будет расширяться комьюнити языка, у которого интеграция нового пакета — задача из категории стыковок космических станций?

    Это общая проблема всех языков программирования. И никакой пакетный менеджер это не решает, ошибки с pip/maven/gem/conan всё еще проще чинить копированием нужного пакета в репозитарий и выкидыванием пакетного менеджера.
  • Ещё один шажок к C++20. Встреча в Альбукерке
    0
    Не в C++20. Надеюсь что в C++23
  • Ещё один шажок к C++20. Встреча в Альбукерке
    0
    backtrace/stackrace на подходе, скоро закинем в комитет предложение.
  • Ещё один шажок к C++20. Встреча в Альбукерке
    0
    Что конкретно вы предлагаете исправить в стандарте? Вызывать std::terminate при throw на платформе без поддержки исключений?
  • Ещё один шажок к C++20. Встреча в Альбукерке
  • Ещё один шажок к C++20. Встреча в Альбукерке
    +1
    Всё, но это не совсем C++.

    Поищите замечательные доклады от SG14 (game dev, low latency). Они пытаются уйти от исключений в сторону более быстрых механизмов сообщений об ошибках… И не могут найти механизмы, которые работали бы быстрее, в случае отсутствия ошибки.

    Читайте современные исследования, не используйте исключения для «не ошибок» и всё будет хорошо.
  • Ещё один шажок к C++20. Встреча в Альбукерке
    0
    Это отдельная фишка. На неё была отдельная бумага www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2148.html
  • Ещё один шажок к C++20. Встреча в Альбукерке
    0
    Так пример же мотивирующий, так что «плохой» вариант должен быть по длиннее :)
  • Ещё один шажок к C++20. Встреча в Альбукерке
    0
    osyncstream работает без мьютексов под капотом. Так что он немного производительнее и намного лучше масштабируется.
  • Ещё один шажок к C++20. Встреча в Альбукерке
    +1
    Сомневаюсь, что фишки новой модели памяти люди применяют в повседневном программировании.
  • Ещё один шажок к C++20. Встреча в Альбукерке
    0
    Спасибо, пример немного подправил.

    А насчёт geobase — это не ко мне :)
  • Ещё один шажок к C++20. Встреча в Альбукерке
    0
    Помечены как deprecated, чтобы мотивировать людей использовать is_standard_layout и is_trivally_copyable.
  • Ещё один шажок к C++20. Встреча в Альбукерке
    +4
    Была создана подгруппа Tooling (SG Tooling) в Альбукерке. Возможно что через пол годика можно будет посылать предложения по унификации систем сборок, пакетным менеджерам и прочему.
  • Ещё один шажок к C++20. Встреча в Альбукерке
    0
    Пока только готовятся к выходу в виде TS. Непонятно как оно пойдёт дальше. Concepts прожили два года в виде TS, прежде чем их втянули в C++20.
  • Ещё один шажок к C++20. Встреча в Альбукерке
    0
    По хорошему C#, Java и PHP нужно учить столько же, прежде чем приступать к программированию :)
  • Ещё один шажок к C++20. Встреча в Альбукерке
    0
    Есть в виде TS, почитать можно вот тут.

    Как обкатают, станут частью стандарта.
  • Ещё один шажок к C++20. Встреча в Альбукерке
    +6
    В одну строчку просто не поместилось в табличке:
    auto operator<=>(const point3d&) const = default;
  • Пишем свою книгу заново
    0
    Нужны ещё корректоры, технические ревьюеры, платформа для распространения, тех персонал для поддержки платформы, реклама и туча менеджеров, чтобы всё это работало.

    Если не поставлено на поток, то найти всех необходимых людей — уже проблема. Дополнительная проблема в том, что заключать договор фриланса с каждым получится дороже, чем если они все сидят в офисе и получают зарплату.

    А вообще есть самиздат, но я не рискнул попробовать. Может кто издавал техническую литературу через самиздат? Поделитесь пожалуйста опытом.
  • Пишем свою книгу заново
    0
    Вы кстати пишете сразу на английском, или сначала делаете заготовки на русском а потом переводите?


    Обычно я делаю заготовки кода, через которые хочу донести мысль. Потом сразу на английском описываю что код делает. Потом докидываю фактов, которые лично мне было интересно узнать за последние несколько лет и домешиваю новостей и планов на будущее.

    Сложные моменты в голове обдумывается на русском. Простые вещи через неделю работы над книгой начинают обдумываться сразу на английском.
  • Пишем свою книгу заново
    +1
    Да, без проблем. Могу дать контакты :)
  • Пишем свою книгу заново
    0
    Спрос порождают читатели, издательство следует за спросом.

    Если издательство выпускает только техническую литературу и в данный момент на пике популярности находится Node.js/Rust/Erlang, то книги на эту тематику и будут переводить в первую очередь. Остальное переводится по мере наличия ресурсов.
  • Пишем свою книгу заново
    +1
    Это зависит от объёма продаж и от цены за переведённую книгу.

    Есть порог, после которого начинают капать проценты и с перевода, но издательство сразу предупредило что порог весьма высок, а проценты там весьма незначительны (что-то на подобие 16% от 16% от чистой прибыли издательства с перевода).

    Для того чтобы с переводов получать солидный процент надо быть Страуструпом (но не уверен что поможет!), или писать не техническую литературу.
  • Пишем свою книгу заново
    0
    Это зависит от российских издательств. Если их заинтересует покупка прав на перевод — я буду весьма рад.

    Больше никак на ситуацию я повлиять вроде бы не в состоянии :(
  • На шаг ближе к С++20. Итоги встречи в Торонто
    0
    Т.е. потенциально это будет медленнее, чем выделение памяти на стеке…

    Нет. Компилятору разрешено оптимизировать это место и удалять динамическую аллокацию в пользу аллокации на стеке, даже если подставлен пользовательский аллокатор.

    Другими словами — если компилятор вставит вызов аллокатора, то написать без динамической аллокации руками у вас не получится, без серьёзной переработки логики приложения. См изначальный пример с Boost.Asio. Там есть «new tcp_connection», так вот, этот new в примере с корутинами фактически «переехал» внутрь имплементации корутины.
  • На шаг ближе к С++20. Итоги встречи в Торонто
    0
    Поправочка:
    * люди из этой же подгруппы занимаются executors и новыми классами для синхронизации…
  • На шаг ближе к С++20. Итоги встречи в Торонто
    0
    У SG5 есть идея выпустить техническую спецификацию на TM к C++20, но не понятно успеют ли по срокам. Эта же подгруппа занимается executors и новыми классами для синхронизации, работы у них и очень много.
  • На шаг ближе к С++20. Итоги встречи в Торонто
    0
    Добавил ваши правки в статью. Спасибо!
  • На шаг ближе к С++20. Итоги встречи в Торонто
    0
  • На шаг ближе к С++20. Итоги встречи в Торонто
    +1
    Да, компилятор оставит тело в каждой единице трансляции где эта функция была объявлена. Линкер, при объединении единиц трансляций, будет выкидывать одинаковые weak функции.

    В случае с модулями, функция будет только в теле модуля и не просочится в другие единицы трансляции.
  • На шаг ближе к С++20. Итоги встречи в Торонто
    0
    С этим сейчас экспериментирют несколько людей из комитета. Так что обязательно добавят, но не в ближайшее время.
  • Как Яндекс создавал курс по C++, или Почему нам всё пришлось переписать
    0
    Приятно видеть рост популярности C++ в России. Сначала РГ21, теперь еще и курсы!
  • Как Яндекс создавал курс по C++, или Почему нам всё пришлось переписать
    +7
    Ребята очень большие молодцы!

    Бьярн Страуструп как-то рассказывал: «Открыл какой-то учебник по С++, а там на первой неделе указатели, printf, new, delete, void*… И я понял, что не хочу пользоваться таким С++».

    Так вот, в начальных курсах всего этого безобразия вы не найдёте. И это заслуга создателей курса
  • Как я писал предложение к стандарту С++
    0
    Над proposal на restrict сейчас работают люди занимающиеся разработкой компиляторов. Там есть много сложностей связанных с алиасингом this, алиасингами членов класса (не очень понятно как это указывать с точки зрения синтаксиса).

    Авось через лет 5 появится в стандарте.
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +2
    А шарп 2.0 от шарпа 7.0 для пользователя отличается только незначительным сахаром.


    Кортежы, именованные поля кортежей, structured bindings, шаблоны с is, шаблонные switch… Это только некоторые нововведения 7 C#. Когда я заглядывал в код контейнеров 5 лет назад — множество ключевых слов C# я просто не знал, т.к. большинство пользователей их не пишут в повседневном коде и в институте за год их не успели объяснить.

    Написать знакомому программу на C# было адом — абсолютно непонятны времена жизни объектов в лямбдах, примитивы синхронизации немного отличаются, и их приходится учить заново…

    Вывод — любой язык сложен, если его не знаешь или знаешь плохо. В любом языке есть свои сложности в огромных количествах.
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +3
    vec.push_back(a);

    Вы сможете сказать, будет тут выделена память или нет? Не сможете, потому что это а) зависит от внутреннего состояния vec б) зависит от конкретной стратегии std:vector на данной платформе.

    Если нужно чтобы элементы хранились непрерывно и:
    * если вы точно знаете, сколько элементов вам нужно — используйте array/stack_vector
    * если вы знаете, сколько в среднем хранится элементов — используйте small_vector/vector+reserve
    * если не знаете — используйте vector

    Все известные мне не интрузивные самописные решения сводятся к одному из этих пунктов.

    Если это не так — опишите пожалуйста поподробнее вашу идею и вашу реализацию контейнера.
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +12
    Ниже практически всё подметили:
    * нижние подчеркивания перед всем что только можно — чтобы защитить себя от пользователей, пишущих макросы в нижнем регистре
    * вместо throw/try/catch — макросы, так как многие пользователи используют стандартную библиотеку с выключенными исключениями
    * большие и длинные тела if — оптимизация под конкретный компилятор (разработчик знает где у него hot path и знает какую ветку компилятор делает hot path). Некоторые стандартные библиотеки имеют в телах goto по той же причине — знают косяки своего компилятора и написали goto чтобы сгенерировался более оптимальный код
    * Множество макросов так же делают библиотеку юзабельной для разных версий стандарта. Так libstdc++ работает на флагах -std=(gnu++98,gnu++03,gnu++11,gnu++14,gnu++1z,c++98,c++03,c++11,c++14,c++1z), без макросов напободие _GLIBCXX_NOEXCEPT просто не обойтись.
    * Есть макросы, которые позволяют работать без RTTI (так любят делать embedded разработчики)
    * Другие странности форматирования (например после открывающей фигурной скобки отступ в -4 пробела) связаны с очень древними кодовыми базами… когда мониторы были узкие и вся С++ строчка иначе на экран не помещалась
    * Куча плясок с бубном вокруг аллокаторов (поэтому много всякого метапрограммирования и специфичные typedef для указателей, вместо T*). Все для того, чтобы пользовательские аллокаторы с using pointer = fancy-pointers работали
    * Куча плясок с бубном вокруг точек кастомизации — поэтому часть методов помечены как ::std::, другие методы вызываются без указания namespace
    * Много плясок с бубном вокруг исключений — практически всё что пользователь передал в качестве шаблонного параметра может кинуть исключение в любой момент. После такого исключения надо оставаться в валидном состоянии (да, даже если функция хеширования кинула исключения — надо подчистить ресурсы и остаться в валидном состоянии).
    * Некоторые имплементации поддерживают дебажные версии стандартной библиотеки, из-за чего макросов становится еще больше, а странность кода возрастает в угоду производительности в дебажном режиме
    *… (я что-то наверняка забыл)
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    0
    Готов вам помочь в стандартизации юникодных строк для C++. Стоит начать с написания прототипа, который понравится большинству разработчиков.
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +2
    Вы даже не представляете, что порой люди пишут:
    #define count int // В фирме Одуванчик принято макросы писать с маленькой буквы
    
    struct vector {
        vector(size_t count); // Боль...
    };