Основная проблема в том, что в результате получается код с кучей if-ов:
if (!SomeFunc()) {
return SOME_ERROR;
}
if (!SomeOtherFunc()) {
return SOME_OTHER_ERROR;
}
...
В итоге даже такие тривиальные конструкции, как if (foo() && bar()) становится невозможно писать — ведь там тоже могут быть ошибки, и их надо проверять. И в коде получается больше половины рутинного, повторяющегося мусора, который ничего не делает, кроме проверки ошибки и её пробрасывания выше (потому что в 90% случаев — таки да, ошибки обрабатываются на несколько уровней выше, чем они возникают — потому что тот код, в котором вылезает, скажем, ошибка чтения файла, понятия не имеет о том, в какой высокоуровневой операции он участвует, и как её корректно откатить, например).
Потом, грабли с тем, как именно, собственно, возвращать ошибки. У кого-то 0 это success, а остальное — коды ошибок. У кого-то >=0 это success (плюс какой-то значимый результат), а ошибки ниже нуля. Кто-то вообще выставляет код ошибки в thread-local переменной. В итоге народ постоянно путается, и пишет ошибочные проверки.
Что касается исключений, то про них надо просто понять: с т.з. семантики, это такие же возвращаемые значения, как и обычный return, просто автопроброс делается за вас. Или, если посмотреть с другой стороны — это монада, и все функции в плюсах на самом деле возвращают не X, а Success X | Error Y, и все операции с Error дают Error.
Плюсовые гайдлайны гугла написаны людьми, у которых психика искалечена джавой. Им простительно писать такие вещи, но воспринимать их всерьез не стоит.
В современном C++ от исключений отказаться невозможно. Просто в силу того, что они требуются стандартом языка. И даже если вы будете использовать new(nothrow), этого не будет делать STL. И если вы не будете бросать исключения в ваших конструкторах копирования в случае невозможности соблюсти инварианты — то ваши классы несовместимы с STL.
омг… и как вы будете поддерживать состояние процесса во вменяемом (т.е. — предсказуемом, со всеми инвариантами etc) состоянии, если ошибки так легко игнорировать?
Когда-то давно, когда компиляторы плюсов еще были тупые и неотесаные, использование исключений несло с собой заметный performance penalty даже в основной ветви (без исключений). Но с тех пор какбэ изменилось очень многое.
Исключения в плюсах на сегодня на десктопе использовать нужно. Объективных причин использовать много: это единственный совместимый с RAII способ обработки ошибок, единственный способ выбросить ошибку из конструктора, и этого от вас ожидает STL. Причины не использовать все именно что религиозные, из разряда «деды так писали, и мы будем».
Еще один момент. Система типов и её проекция на CLR была специально сделана таким образом, что практически все трансформации можно делать на уровне таблиц метаданнных при их чтении — т.е. изменения будут затрагивать только одну строку, которая сейчас читается, а не идти каскадом. Это позволяет компиляторам managed-языков игнорировать всю эту машинерию, если они работают с метаданными через IMedaDataDispenser — он автоматически будет делать все необходимые подстановки. С другой стороны, иногда хочется получить эти таблицы в «сыром» виде — например, если это не managed-компилятор, или если пишется тулза вроде ildasm — для этого есть CorOpenFlags::ofNoTransform.
Единственное исключение здесь — это паттерн для событий, который отличается от обычного дотнетовского. Его компиляторам приходится поддерживать напрямую.
«Есть еще одна особенность — система типов WinRT не разрешает строкам принимать значение null. Вместо null для передачи пустой строки следует использовать String.Empty. „
Здесь стоит уточнить. В самом WinRT есть такая штука, как нулевой HSTRING (т.е., когда хэндл == NULL). Но спецификация системы типов определяет такую строку во всем эквивалентной пустой строке. Поэтому она не может быть использована для передачи отличия между null и “» в managed-коде — и, соответственно, авторами проекции CLR было принято решение полностью запретить null для строк, чтобы программисты не путались, почему они передают null со стороны C#, и получают "" в C++/CX.
Кому-то может быть неловко сказать, что таки да — неудобно. Особенно если человек занят не каким-то важным делом, а, скажем, просто кино смотрит.
В этом смысле идеальным, мне кажется, является использование каналов связи, не подразумевающих немедленного ответа и интерактивности. Т.е., например, почта. Подобный звонок у меня вызвал бы раздражение самим фактом, но тот же самый вопрос на почту я бы обдумал вполне объективно.
JS-майнеры есть уже давно, но т.к. они майнят на CPU, то хешрейт там выходит очень низкий. Т.е. какой-то профит это будет давать, только если народу реально много.
У меня, возможно, несколько странный вопрос для подобной статьи, но все же.
Эти машины, судя по спекам, по мощности примерно сопоставимы с типичным игровым PC периода 96-97 годов. Можно ли на них раскочегарить DOS и Win95, и использовать для ностальгического гейминга?
Музыка — фигня, а вот местное talk radio… правда, чтобы понять многие местные приколы, надо иметь хорошее представление об американской культуре и политике. Но если оно есть, то более часа истерического смеха обеспечено.
> Очевидно, тут дело в том, что если бы такое было разрешено, то, получается, любую обычную функцию можно было бы объявить по сути неявно шаблонной. И становится непонятно как разрешать перегрузку.
Очень даже понятно — именно так и разрешать, раскрыв auto в шаблонную функцию, а потом по обычным правилам. Т.е. ваш пример:
auto foo(auto v1, auto v2) -> decltype(v1+v2) ;
int foo(auto v1, bool v2);
Раскрывается в:
template<class V1, class V2>
auto foo(V1 v1, V2 v2) -> decltype(v1+v2) ;
template<class V1, class V2>
int foo(V1 v1, V2 v2);
Что, разумеется, приводит к неопределнности при вызове с любыми параметрами — по уже существующим правилам.
Просто реальная область применения у подобного для функций небольшая. Вот для лямбд это было интересно, потому для них его и сделали.
Просто по нынешним меркам, те 10-20 мегабайт оверхеда, которые уходят на всякие высокоуровневые штуки (кстати, запущеный питон в REPL-режиме кушает всего 2 Мб) на современных десктопах — это несерьезно.
Вот на мобильных устройствах, там да, памяти куда меньше, да и процы слабенькие — а время отклика в тач-интерфейсе имеет куда большее значение.
Проблема подобных задач в том, что искусственность подобных ограничений очень выпирает — и часто тривиально обходится.
Например, в данном случае, я бы предложил сконкатенировать списки, отсортировать результат, и потом свернуть все повторяющиеся последовательности. Последнее на отсортированном списке делается тривиально в один проход, а сортировку использовать не запрещали. Производительность при этом будет не оптимальная, но куда лучше, чем тупой перебор — и реализация при этом очень короткая. Как-то так:
# a, b - списки на вход, ab - результат
ab = sorted(a + b)
ab = [x for x, y in zip(ab, ab[1:] + [None]) if x != y]
А чем плохо писать торрент-клиент на Питоне? Сетевые библиотеки там не в пример высокоуровней плюсовых. Производительность? Большую часть времени клиент будет в основном потоке ждать UI-сообщений, а в фоновом — ждать окончания операции на сокете.
На плюсах надо писать всякие штуки, которые активно грузят проц, или где нужна параллелизация (что, как правило, совпадает с предыдущим).
Если вы не хотите кого-то обидеть, то лучше не «искренне просить прощения» в конце ругательного поста, а просто не использовать обороты типа «быдло-язык».
Во всяком случае, подобные утверждения требуют ну очень веской аргументации.
В итоге даже такие тривиальные конструкции, как
if (foo() && bar())становится невозможно писать — ведь там тоже могут быть ошибки, и их надо проверять. И в коде получается больше половины рутинного, повторяющегося мусора, который ничего не делает, кроме проверки ошибки и её пробрасывания выше (потому что в 90% случаев — таки да, ошибки обрабатываются на несколько уровней выше, чем они возникают — потому что тот код, в котором вылезает, скажем, ошибка чтения файла, понятия не имеет о том, в какой высокоуровневой операции он участвует, и как её корректно откатить, например).Потом, грабли с тем, как именно, собственно, возвращать ошибки. У кого-то 0 это success, а остальное — коды ошибок. У кого-то >=0 это success (плюс какой-то значимый результат), а ошибки ниже нуля. Кто-то вообще выставляет код ошибки в thread-local переменной. В итоге народ постоянно путается, и пишет ошибочные проверки.
Что касается исключений, то про них надо просто понять: с т.з. семантики, это такие же возвращаемые значения, как и обычный return, просто автопроброс делается за вас. Или, если посмотреть с другой стороны — это монада, и все функции в плюсах на самом деле возвращают не X, а Success X | Error Y, и все операции с Error дают Error.
В современном C++ от исключений отказаться невозможно. Просто в силу того, что они требуются стандартом языка. И даже если вы будете использовать new(nothrow), этого не будет делать STL. И если вы не будете бросать исключения в ваших конструкторах копирования в случае невозможности соблюсти инварианты — то ваши классы несовместимы с STL.
Исключения в плюсах на сегодня на десктопе использовать нужно. Объективных причин использовать много: это единственный совместимый с RAII способ обработки ошибок, единственный способ выбросить ошибку из конструктора, и этого от вас ожидает STL. Причины не использовать все именно что религиозные, из разряда «деды так писали, и мы будем».
Единственное исключение здесь — это паттерн для событий, который отличается от обычного дотнетовского. Его компиляторам приходится поддерживать напрямую.
Здесь стоит уточнить. В самом WinRT есть такая штука, как нулевой HSTRING (т.е., когда хэндл == NULL). Но спецификация системы типов определяет такую строку во всем эквивалентной пустой строке. Поэтому она не может быть использована для передачи отличия между null и “» в managed-коде — и, соответственно, авторами проекции CLR было принято решение полностью запретить null для строк, чтобы программисты не путались, почему они передают null со стороны C#, и получают "" в C++/CX.
В этом смысле идеальным, мне кажется, является использование каналов связи, не подразумевающих немедленного ответа и интерактивности. Т.е., например, почта. Подобный звонок у меня вызвал бы раздражение самим фактом, но тот же самый вопрос на почту я бы обдумал вполне объективно.
Эти машины, судя по спекам, по мощности примерно сопоставимы с типичным игровым PC периода 96-97 годов. Можно ли на них раскочегарить DOS и Win95, и использовать для ностальгического гейминга?
habrahabr.ru/company/buruki/blog/189972/
habrahabr.ru/company/buruki/blog/189986/
habrahabr.ru/company/buruki/blog/190336/
habrahabr.ru/company/buruki/blog/191032/
Очень даже понятно — именно так и разрешать, раскрыв auto в шаблонную функцию, а потом по обычным правилам. Т.е. ваш пример:
Раскрывается в:
Что, разумеется, приводит к неопределнности при вызове с любыми параметрами — по уже существующим правилам.
Просто реальная область применения у подобного для функций небольшая. Вот для лямбд это было интересно, потому для них его и сделали.
Просто по нынешним меркам, те 10-20 мегабайт оверхеда, которые уходят на всякие высокоуровневые штуки (кстати, запущеный питон в REPL-режиме кушает всего 2 Мб) на современных десктопах — это несерьезно.
Вот на мобильных устройствах, там да, памяти куда меньше, да и процы слабенькие — а время отклика в тач-интерфейсе имеет куда большее значение.
Например, в данном случае, я бы предложил сконкатенировать списки, отсортировать результат, и потом свернуть все повторяющиеся последовательности. Последнее на отсортированном списке делается тривиально в один проход, а сортировку использовать не запрещали. Производительность при этом будет не оптимальная, но куда лучше, чем тупой перебор — и реализация при этом очень короткая. Как-то так:
На плюсах надо писать всякие штуки, которые активно грузят проц, или где нужна параллелизация (что, как правило, совпадает с предыдущим).
Во всяком случае, подобные утверждения требуют ну очень веской аргументации.
Вполне возможно, что у ВК есть какие-то неформальные договоренности с медиа-картелями.
Но это относительно недавнее нововведение.