C++ Russia 2017: Сергей Зубков, C++ Core Guidelines

แชร์
ฝัง
  • เผยแพร่เมื่อ 9 พ.ค. 2017
  • Подробнее о конференции C++ Russia: jrg.su/W8skjE
    - -
    . . Core Guidelines: github.com/isocpp/CppCoreGuid...

ความคิดเห็น • 16

  • @EvgenyChannel
    @EvgenyChannel 7 ปีที่แล้ว +8

    пока нет в описании, вот ссылка на guidelines github.com/isocpp/CppCoreGuidelines

  • @calmsam2217
    @calmsam2217 3 ปีที่แล้ว

    Зрители, даю вам 100% инфу, автор , отвечая на вопросы переводит код в ассемблер, это уровень...

  • @dmitriydmitriev892
    @dmitriydmitriev892 6 ปีที่แล้ว +9

    Очень интересное выступление, но слушать трындец сложно...

  • @tertiumorganum5665
    @tertiumorganum5665 ปีที่แล้ว +1

    интересно, сейчас, спустя 5 лет, это все стало реальностью?

  • @ianzagorskikh3964
    @ianzagorskikh3964 6 ปีที่แล้ว +2

    Вопрос: Указатель vs ссылка в качестве аргумента ф-и.
    Я бы добавил ещё один момент (с моей точки зрения ключевой). Принимая ссылку мы тем самым задаем контракт, который обязует вызывающий код гарантированно (SIC!) передать валидный аргумент (адрес). Как следствие, ф-и нет необходимости проверять ситуацию "а не нулевой ли указатель на abc нам передали и если нулевой то как нам на это реагировать?". Передавая указатель мы автоматически порождаем ситуацию, в которой ф-я обязана проверить переданный указатель на валидность и если он не валиден - как-то на это отреагировать. А если у нас ф-я без возврата статуса ошибки? И мы к тому же не используем исключения по одной из миллионов причин? Можно конечно заасертиться (это считайте аналог жесткого исключения) но и это тоже не всегда возможно.
    Передача аргумента по указателю IMHO может быть применено только в случае, когда семантика вызова ф-и подразумевает "отсутствие значения аргумента" и это не является ошибочной ситуацией. Но и тут можно спокойно обойтись без указателей.

    • @user-jf3gi7gt8i
      @user-jf3gi7gt8i 6 ปีที่แล้ว

      Массив тоже по ссылке передавать?

  • @apivovarov2
    @apivovarov2 4 ปีที่แล้ว

    change_speed(23_m / 10s) - не пойму а что такое 23_m . Вроде как имена переменных не могут с цифры начинаться.

    • @tertiumorganum5665
      @tertiumorganum5665 ปีที่แล้ว +1

      кастомный оператор перегрузки для дабла, типа множителя

  • @suckmy
    @suckmy 5 ปีที่แล้ว

    43:30

  • @sdgsweg
    @sdgsweg 4 ปีที่แล้ว

    Использовать span вместо арифметики указателей. А как же двумерные массивы? А как же узкие места? Как раз для критичных ко времени местах используется адресная арифметика, а на вы предлагаете проверять диапазоны. В некоторых местах приходится даже целочисленные умножения оптимизировать, не говоря уже о делениях. Если завести эту шарманку, то в дебаге будет просто невозможно запускать проект. Не от хорошей жизни люди используют адресную арифметику.

    • @vlad071096
      @vlad071096 4 ปีที่แล้ว

      Проверка индексов же только в дебаге. А так, если вам надо передать массив, вы же все равно передаете начало и размер - тот же span по сути.

    • @sdgsweg
      @sdgsweg 4 ปีที่แล้ว

      @@vlad071096 я считаю, что разница в том, что когда указываешь размер сам, то можешь ошибиться. span же извлекает сам размеры из контейнера, чем уменьшает поле для возникновения ошибок.

    • @kovesik
      @kovesik 3 ปีที่แล้ว

      @@sdgsweg D это решил на уровне языка, что по мне логичнее, чем ждать 10 лет спан в поставке стандартной библиотеке

  • @xintreavideo
    @xintreavideo 2 ปีที่แล้ว +2

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

  • @user-pl2lx3ur3g
    @user-pl2lx3ur3g 7 ปีที่แล้ว +5

    Ой что, вот что только не делает комитет С++ чтобы не прогать на Ada, интересно сколько лет они еще с помощью вот таких правил будут тащить стандарт Ada в С++.

  • @nekosora6036
    @nekosora6036 5 ปีที่แล้ว +4

    P.999: Avoid C++. Code Rust