Статья про потоки, потенциалы, схемы, графы — без единого рисунка графа. Хм. Автор явно высокого мнения о способностях аудитории к абстрактному мышлению :)
Там как раз рассматривается подходящий пример, о котором здесь не упомянули — итерация по терминированной нулём С-строке. С итератором начала всё ясно — это, собственно, указатель на строку. А вот как быть с концом? Проще всего было бы в качестве конца использовать указатель на последний (нулевой) символ. Но пока мы не пройдём по строке целиком, мы не знаем, где она кончается!
Значит, нам нужна дополнительная сущность. Это может быть специальное состояние в том же итераторе. Тогда это уже не может быть простой указатель. Этот случай с istream_iterator разобрал borisko выше. Проблема — плата в рантайме за хранение состояние и его проверку.
Другой подход — использовать другой тип для конца. Не итератор, а страж (sentinel). Тогда итератор начала остаётся просто указателем, а "итератор" конца становится стражем. В страже нет вообще никакого состояния, но операция сравнения итератора со стражем определена таким образом, что итератор просто сравнивается с нулём. И это операция выбирается на этапе компиляции! Никаких накладных расходов в рантайме. Так же эффективно, как голый цикл.
Файловая система. "Отличная штука! Была бы, если бы вошла в стандарт лет 15 назад."
Сейчас она менее полезна?
string_view. "будет хорошо смотреться в интерфейсах, какого-то принципиального быстродействия по сравнению с двумя предыдущими способами не даст" Почему вы здесь оцениваете что-то только с позиции быстродействия?
Параллельные алгоритмы. "Классическая ситуация «к 14-ти стандартам прибавился 15-ый»" Стандарта не было, теперь он есть, он один.
Специальные математические функции. "Ну боже мой, почему этому всему не нашлось места в какой-нибудь лежащей далеко в углу математической библиотеке" А они чему-то мешают? Да, можно было бы легко прожить без них, но ведь мы лишились модулей не из-за сферических гармоник, зачем паниковать?
С помощью ranged-for теперь можно бегать по диапазонам, в которых начало и конец имеют разные типы.
Это полезный шаг в сторону ranges, о чём вы не упомянули.
Концепты. "Я не знаю как всё там в комитете варится внутри" Тогда зачем пишете? Они регулярно об этом рассказывают на конференциях, на интервью, публикуют результаты встреч и отчёты. Подобное замечание смотрится крайне непрофессионально.
Унифицированный синтаксис вызова. "И ведь предлагают его Bjarne Stroustrup и Herb Sutter." Авторитет не должен давлеть над здравыми доводами.
Итог: слишком много эмоций, слишком мало полезной информации и анализа принятых решений.
stack unwinding, раскрутка стэка — вполне корректный перевод, другого никогда не слышал
throw, особенно в случае throwing function — выбрасывать/бросать/генерировать (ещё иногда говорят «поднимать») исключение; функция, которая может сгенерировать/..., или функция, генерирующая/…
А можете ответить чуть более подробно на вопрос "Почему квадрат?". Всегда меня мучал. То есть вот, например, у нас расстояния от точек до прямой в метрах. Тогда мы минимизируем… квадратные метры! Казалось бы, при чём тут они?.. И ещё. Вот мерили мы положения точек в метрах. Расстояние, допустим, 1, норма тоже 1. Теперь меряем в миллиметрах. Расстояние стало 10^3, а норма уже 10^6! Это немного смущает. Или не стоит пытаться сравнивать расстояние и норму?
Ну, в общем случае — никак. Ибо виртуальные функции — это динамический полиморфизм, а шаблоны — это статический полиморфизм. Однако, применительно к данной задаче нам динамический полиморфизм вроде как и не нужен. Есть один большой алгоритм и его нужно посчитать для заданной параметризации, которая не будет меняться в процессе работы.
Можно привести такой пример. В динамическом полиморфизме есть интерфейс, а в статическом — концепт. Любой класс, реализующий заданный набор методов удовлетворяет этому концепту. Класс, удовлетворяющий концепту, передаётся на этапе компиляции, в то время как объект, удовлетворяющий интерфейсу, передавался бы на этапе выполнения.
В динамическом полиморфизме можно сделать условие на конкретный тип предоставленного объекта через RTTI и построить логику в зависимости от этого. В статическом можно сделать характеристический (traits) класс, у которого будут свои специализации под разные классы, которые он будет характеризовать.
Входной параметр функции — тоже динамический полиморфизм, по сути. Ведь функция работает по-разному в зависимости от значения параметра, пусть это и не имеет отношения к ООП. Вместо параметра можно использовать скалярный аргумент шаблона. В целом, любое поведение, доступное динамически, можно смоделировать статически, только при условии, что вся необходимая информация есть на этапе компиляции. И хотя выглядеть в С++ это может тяжеловато, компилятору с этим будет работать намного проще, нежели чем с виртуальными функциями, ибо ему сразу доступна вся возможная информация.
Ещё было бы неплохо добавить английские имена на бэджик. Можно либо просто убрать русские, либо на одной стороне писать по-русски, а на другой — по-английски. А то у нас одна стороная бэджика было просто пустой — не круто.
Ещё часто делают бэджики разных цветов. Одного цвета — участники, другого — организаторы, третьего — спикеры. Может быть цвет для прессы или чуваков на стэндах. Удобно, и, опять же, сразу автопонт, что ты спикер, а не просто так :)
Вот чего я всегда не понимал в яндекс метро, так это странные маршруты, которые он периодически предлагает. Казалось, ну что может быть проще, оттестировать маршруты? Да их можно вообще полностью покрыть тестами! Вот например, предлагается от Тульской до Александровского Сада добираться через кольцо:
А в обратную сторону уже предлагает ехать по-человечески, напрямую.
Вот у меня точно такая же мысль возникла :) Как какая-то история была про конвейер, который переставал работать после некоторого количества выпущенных деталей. Причём число было совершенно непримечательным — 32768.
Захотел отправить ошибку, указать правильное местоположение остановки. Он мне предложил выбрать на карте — удобно. Только вот положение по умолчанию на карте находилось где-то в Казахстане О_О
Там как раз рассматривается подходящий пример, о котором здесь не упомянули — итерация по терминированной нулём С-строке. С итератором начала всё ясно — это, собственно, указатель на строку. А вот как быть с концом? Проще всего было бы в качестве конца использовать указатель на последний (нулевой) символ. Но пока мы не пройдём по строке целиком, мы не знаем, где она кончается!
Значит, нам нужна дополнительная сущность. Это может быть специальное состояние в том же итераторе. Тогда это уже не может быть простой указатель. Этот случай с istream_iterator разобрал borisko выше. Проблема — плата в рантайме за хранение состояние и его проверку.
Другой подход — использовать другой тип для конца. Не итератор, а страж (sentinel). Тогда итератор начала остаётся просто указателем, а "итератор" конца становится стражем. В страже нет вообще никакого состояния, но операция сравнения итератора со стражем определена таким образом, что итератор просто сравнивается с нулём. И это операция выбирается на этапе компиляции! Никаких накладных расходов в рантайме. Так же эффективно, как голый цикл.
Файловая система. "Отличная штука! Была бы, если бы вошла в стандарт лет 15 назад."
Сейчас она менее полезна?
string_view. "будет хорошо смотреться в интерфейсах, какого-то принципиального быстродействия по сравнению с двумя предыдущими способами не даст"
Почему вы здесь оцениваете что-то только с позиции быстродействия?
Параллельные алгоритмы. "Классическая ситуация «к 14-ти стандартам прибавился 15-ый»"
Стандарта не было, теперь он есть, он один.
Специальные математические функции. "Ну боже мой, почему этому всему не нашлось места в какой-нибудь лежащей далеко в углу математической библиотеке"
А они чему-то мешают? Да, можно было бы легко прожить без них, но ведь мы лишились модулей не из-за сферических гармоник, зачем паниковать?
С помощью ranged-for теперь можно бегать по диапазонам, в которых начало и конец имеют разные типы.
Это полезный шаг в сторону ranges, о чём вы не упомянули.
Концепты. "Я не знаю как всё там в комитете варится внутри"
Тогда зачем пишете? Они регулярно об этом рассказывают на конференциях, на интервью, публикуют результаты встреч и отчёты. Подобное замечание смотрится крайне непрофессионально.
Унифицированный синтаксис вызова. "И ведь предлагают его Bjarne Stroustrup и Herb Sutter."
Авторитет не должен давлеть над здравыми доводами.
Итог: слишком много эмоций, слишком мало полезной информации и анализа принятых решений.
Можно привести такой пример. В динамическом полиморфизме есть интерфейс, а в статическом — концепт. Любой класс, реализующий заданный набор методов удовлетворяет этому концепту. Класс, удовлетворяющий концепту, передаётся на этапе компиляции, в то время как объект, удовлетворяющий интерфейсу, передавался бы на этапе выполнения.
В динамическом полиморфизме можно сделать условие на конкретный тип предоставленного объекта через RTTI и построить логику в зависимости от этого. В статическом можно сделать характеристический (traits) класс, у которого будут свои специализации под разные классы, которые он будет характеризовать.
Входной параметр функции — тоже динамический полиморфизм, по сути. Ведь функция работает по-разному в зависимости от значения параметра, пусть это и не имеет отношения к ООП. Вместо параметра можно использовать скалярный аргумент шаблона. В целом, любое поведение, доступное динамически, можно смоделировать статически, только при условии, что вся необходимая информация есть на этапе компиляции. И хотя выглядеть в С++ это может тяжеловато, компилятору с этим будет работать намного проще, нежели чем с виртуальными функциями, ибо ему сразу доступна вся возможная информация.
Ещё часто делают бэджики разных цветов. Одного цвета — участники, другого — организаторы, третьего — спикеры. Может быть цвет для прессы или чуваков на стэндах. Удобно, и, опять же, сразу автопонт, что ты спикер, а не просто так :)
А в обратную сторону уже предлагает ехать по-человечески, напрямую.