Вопрос: Указатель vs ссылка в качестве аргумента ф-и. Я бы добавил ещё один момент (с моей точки зрения ключевой). Принимая ссылку мы тем самым задаем контракт, который обязует вызывающий код гарантированно (SIC!) передать валидный аргумент (адрес). Как следствие, ф-и нет необходимости проверять ситуацию "а не нулевой ли указатель на abc нам передали и если нулевой то как нам на это реагировать?". Передавая указатель мы автоматически порождаем ситуацию, в которой ф-я обязана проверить переданный указатель на валидность и если он не валиден - как-то на это отреагировать. А если у нас ф-я без возврата статуса ошибки? И мы к тому же не используем исключения по одной из миллионов причин? Можно конечно заасертиться (это считайте аналог жесткого исключения) но и это тоже не всегда возможно. Передача аргумента по указателю IMHO может быть применено только в случае, когда семантика вызова ф-и подразумевает "отсутствие значения аргумента" и это не является ошибочной ситуацией. Но и тут можно спокойно обойтись без указателей.
Докладчик один из немногих, кто работая в англоязычной стране, сделал презентацию на русском языке. За что ему отдельный респект. Обычно имеют заготовки англоязычных презентаций, дописывают несколько страниц тоже англоязычных и вперед, наплевать на зрителей, они же программисты, знают английский как родной, и так съедят.
Использовать span вместо арифметики указателей. А как же двумерные массивы? А как же узкие места? Как раз для критичных ко времени местах используется адресная арифметика, а на вы предлагаете проверять диапазоны. В некоторых местах приходится даже целочисленные умножения оптимизировать, не говоря уже о делениях. Если завести эту шарманку, то в дебаге будет просто невозможно запускать проект. Не от хорошей жизни люди используют адресную арифметику.
@@vlad071096 я считаю, что разница в том, что когда указываешь размер сам, то можешь ошибиться. span же извлекает сам размеры из контейнера, чем уменьшает поле для возникновения ошибок.
Ой что, вот что только не делает комитет С++ чтобы не прогать на Ada, интересно сколько лет они еще с помощью вот таких правил будут тащить стандарт Ada в С++.
Зрители, даю вам 100% инфу, автор , отвечая на вопросы переводит код в ассемблер, это уровень...
пока нет в описании, вот ссылка на guidelines github.com/isocpp/CppCoreGuidelines
интересно, сейчас, спустя 5 лет, это все стало реальностью?
Вопрос: Указатель vs ссылка в качестве аргумента ф-и.
Я бы добавил ещё один момент (с моей точки зрения ключевой). Принимая ссылку мы тем самым задаем контракт, который обязует вызывающий код гарантированно (SIC!) передать валидный аргумент (адрес). Как следствие, ф-и нет необходимости проверять ситуацию "а не нулевой ли указатель на abc нам передали и если нулевой то как нам на это реагировать?". Передавая указатель мы автоматически порождаем ситуацию, в которой ф-я обязана проверить переданный указатель на валидность и если он не валиден - как-то на это отреагировать. А если у нас ф-я без возврата статуса ошибки? И мы к тому же не используем исключения по одной из миллионов причин? Можно конечно заасертиться (это считайте аналог жесткого исключения) но и это тоже не всегда возможно.
Передача аргумента по указателю IMHO может быть применено только в случае, когда семантика вызова ф-и подразумевает "отсутствие значения аргумента" и это не является ошибочной ситуацией. Но и тут можно спокойно обойтись без указателей.
Массив тоже по ссылке передавать?
Это та книга с красной полосой?
Очень интересное выступление, но слушать трындец сложно...
Докладчик один из немногих, кто работая в англоязычной стране, сделал презентацию на русском языке. За что ему отдельный респект. Обычно имеют заготовки англоязычных презентаций, дописывают несколько страниц тоже англоязычных и вперед, наплевать на зрителей, они же программисты, знают английский как родной, и так съедят.
change_speed(23_m / 10s) - не пойму а что такое 23_m . Вроде как имена переменных не могут с цифры начинаться.
кастомный оператор перегрузки для дабла, типа множителя
Использовать span вместо арифметики указателей. А как же двумерные массивы? А как же узкие места? Как раз для критичных ко времени местах используется адресная арифметика, а на вы предлагаете проверять диапазоны. В некоторых местах приходится даже целочисленные умножения оптимизировать, не говоря уже о делениях. Если завести эту шарманку, то в дебаге будет просто невозможно запускать проект. Не от хорошей жизни люди используют адресную арифметику.
Проверка индексов же только в дебаге. А так, если вам надо передать массив, вы же все равно передаете начало и размер - тот же span по сути.
@@vlad071096 я считаю, что разница в том, что когда указываешь размер сам, то можешь ошибиться. span же извлекает сам размеры из контейнера, чем уменьшает поле для возникновения ошибок.
@@sdgsweg D это решил на уровне языка, что по мне логичнее, чем ждать 10 лет спан в поставке стандартной библиотеке
P.999: Avoid C++. Code Rust
Ой что, вот что только не делает комитет С++ чтобы не прогать на Ada, интересно сколько лет они еще с помощью вот таких правил будут тащить стандарт Ada в С++.