• Пишем свою книгу заново
    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); // Боль...
    };
    
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +2
    В вашей строке ошибка: если вот тут выскочит исключение, то у вас произойдет double free и приложение рухнет.

  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +2
    В стандарте есть:
    An incomplete type T may be used when instantiating forward_list if the allocator satisfies the allocator completeness requirements 17.5.3.5.1

    An incomplete type T may be used when instantiating list if the allocator satisfies the allocator completeness requirements 17.5.3.5.1

    An incomplete type T may be used when instantiating vector if the allocator satisfies the allocator completeness requirements 17.5.3.5.1


    Для map и unordered_map гарантий никаких нет. Если хотите добавить — опишите идею на https://stdcpp.ru/proposals
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    0
    Вначале опишите свою идею на английском вот сюда и послушайте что люди говорят.
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +5
    А можно посмотреть на ваш string?
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +3
    код библиотеки std, мне всегда казалось, что его писали инопланетяне.… никогда не использую в своих проектах код, который выглядит ужасно

    А что вы используете вместо стандартной библиотеки (вместо std::vector, std::unordered_map и std::string например)?
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +1
    Например очень многим они не нравятся: https://stdcpp.ru/proposals/07a6ff30-4f0e-4683-bbaf-4a635eadfb34

    А еще они не сокращают написание кода, делают его чтение сложнее, являются синтаксическим сахаром (к которому у меня необоснованная ненависть после Perl)… А ещё некоторые разработчики языков, где уже есть свойства, называют их «одной из ошибок при дизайне языка» и жалеют что в своё время их добавили (можете поискать по интернету ссылки).
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    0
    А для (2) фулл тайм и не требуется, вы недооцениваете свои силы:

    * Один человек не напрягаясь в свободное время может разгрести тьму ошибок, до которых у разработчика просто не доходят руки (например ищите Mikhail Maksimov в changelog Boost. 1.64)

    * Некоторые в свободное время просто берут, и добавляют недостающий им функционал. Вот например вам changelog GCC, в котором есть фраза «Thanks to Daniel Krügler, Tim Shen, Edward Smith-Rowland, and Ville Voutilainen for work on the C++17 support.». Что-то мне подсказывает, что эти ребята на GCC не работают.

    Я могу тут приводить примеры до вечера. При том будут и матёрые дяди-пенсионеры, и студенты, и безработные, и люди вкалывающие на двух работах. Все они не работают фулл тайм, однако заменяют собой пару десятков фулл тайм разработчиков (за что им огромное спасибо).
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +3
    Лично мои планы относительно свойств очень масштабные: не допустить включения этой фигни в стандарт.
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    0
    Мне тут nataliamakarova773 подсказала, что «на youtube можно будет задавать вопросы, будем озвучивать докладчикам».
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    0
    * Для (1) нужен работающий прототип, который всех устраивает. Такого нет и в ближайшем будущем не появится
    * С (2) вы всегда можете помочь — допишите нехватающий функционал в GCC/Clang ;-)
    * Пункт (3) ожидайте в скором времени во всех компиляторах поддерживающих концепты — ranges выпускаются в этом году в виде отдельного TS, который можно попробовать ещё до С++20.
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    0
    Это похоже на развитие контрактов. В данный момент этим занимаются все самые именитые С++ники и несколько очень умных человек, повёрнутых на доказательстве корректности программы на этапе компиляции. Есть несколько предложений, например вот тут предлагается нечто близкое к тому что в вашей статье про проверку исключений: possibly_throw_exception();

    Все эти десятки бумаг по контрактам ещё будут устаканиваться долгое время, [[implies(std::nothrow)]] появится не скоро. Сокро появятся только нечто наподобие:
    void push(int x, queue & q)
      [[expects: !q.full()]]
      [[ensures: !q.empty()]]
    {
      //...
      [[assert: q.is_valid()]];
      //...
    }
    
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    0
    Работает и для пользовательских. При том из коробки, если шаблонные параметры класса участвуют в конструкторе. Иначе придётся писать explicit deduction guide.
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +2
    Хороший вопрос. Попробуем решить.
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    0
    Да. Но не уверен что будет способ задавать вопросы удалённо.
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    0
    Мы в РГ21 тоже надеялись и голосовали за их принятие на заседании. К несчастью, к консенсусу на заседании не пришли.
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +4
    Внимание, вопрос: как вы думаете, а почему код написан именно так? Какие на то причины?
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +1
    Когда я смотрел на код библиотеки std, мне всегда казалось, что его писали инопланетяне.… я никогда не использую в своих проектах код, который выглядит ужасно

    А что вы используете в своих проектах вместо стандартной библиотеки?
  • Что приняли в C++17, фотография Бьярне Страуструпа и опрос для C++20
    +2
    На этой встрече обсуждали контракты: одобрили их в EWG, отправили на рассмотрение в LEWG (где скорее всего просто помусолят тему «интеграция контрактов в стандартную библиотеку)», далее отправят в CWG.

    Все шансы что контракты будут в C++20.