Его не придётся читать как только добавят концепты в основные компиляторы.
Помню пытался выяснить почему в GCC STL unordered_map не желает принимать incomplete types при декларации. Так и не понял — адская смесь из разных наследующихся друг от друга и от соседского Шарика классов. И без единого комментария — что особо убивает.
Если бы только рефлексия. По которой пока нет единого мнения, есть ряд прототипов. Не вошла целая пачка практически готовых и очень нужных вещей. Зато вошла зета-функция Римана и её товарки, блин.
Проблема в том, что стандарт С++ не говорит о том, в какой кодировке однобайтовые строки. И не говорит, как нижележащее системное АПИ должно их интерпретировать. Современные линуксы используют UTF-8, там всё просто. А Windows использует однобайтовую системную локаль, с непредсказуемым результатом.
Окей, такие вещи, допустим, не везде есть. Но как в Ada с аналогами Iterable/Enumerable/Range для пользовательских типов? И что с передачей функций по ссылке в другие функции? Что с замыканиями и лямбдами?
std::expected<unit, SomeError> doComplexStuff()
{
auto result = doStuff();
if(result.isError())
return result.getError();
auto intResult = result.getResult();
... // use intResult
}
но не получится написать проверку на ошибку, распаковку результата и возврат значения-ошибки в одном выражении:
std::expected<unit, SomeError> doComplexStuff()
{
auto result = (auto result = doStuff()) ? result.getResult() : return result.getError();
... // result is int here, do smth with it
}
Увы, именно что "когда-нибудь". ranges-v3 зависят от concepts-lite. Которые не могут внести в стандарт уже лет 10. Между тем даже аналога boost.iterator_adaptors до сих пор нет в стандарте.
Немного не соглашусь.
Иметь базовые понятия чем vector отличается от hash_map или list — необходимо. Я встречал одного оригинала, хешировал 3-мерные точки методом превращения их координат в строку через to_string (который пишет 6 знаков после запятой). И так на каждый вызов хеш-функции. А потом ещё возмущался, когда ему говорили, что он не прав.
Но — требовать от человека знания алгоритма балансировки красно-чёрного дерева (если этого не предполагает вакансия) действительно глупо.
"Немного" это сколько?
Основные виды алгоритмов и структур?
Сложностные показатели?
Основные алгоритмы работы, в описательном виде?
Основные алгоритмы работы в деталях?
Доскональное знание всего вплоть до timsort, KD-tree и компании?
Увы, в С++ обработка ошибок через исключения меньше всего превращает код функции в бесконечные проверки, за которыми не видно логики. Коды возврата и коды состояния никуда не годятся, т.к. их очень легко проигнорировать. Either-style возвращаемые значения тоже не айс т.к. их во-первых нет в стандартной библиотеке, а во-вторых "раздувают" early return код — нет возможности сделать return из выражения.
Я бы предпочёл std::expected и немножко сахарку, чтобы это красиво чейнилось.
Такими темпами скоро будет arbitrary operator definition.
a #$^ b >>= c ^&* d.А можно ли оставлять вопросы на сайте?
Концепты с двусторонними последствиями (т.е. бьют по рукам и вызывающий код, и за непредусмотренный юз в теле ф-ции). Мечты, мечты...
А эта красота работает только для нескольких стандартных классов? Или пользовательские тоже смогут?
Его не придётся читать как только добавят концепты в основные компиляторы.
Помню пытался выяснить почему в GCC STL unordered_map не желает принимать incomplete types при декларации. Так и не понял — адская смесь из разных наследующихся друг от друга и от соседского Шарика классов. И без единого комментария — что особо убивает.
Для начала хотелось бы концепты. Причём не лайт, с ограничением только "наружу", но и с ограничением "внутрь".
Если бы только рефлексия. По которой пока нет единого мнения, есть ряд прототипов. Не вошла целая пачка практически готовых и очень нужных вещей. Зато вошла зета-функция Римана и её товарки, блин.
Проблема в том, что стандарт С++ не говорит о том, в какой кодировке однобайтовые строки. И не говорит, как нижележащее системное АПИ должно их интерпретировать. Современные линуксы используют UTF-8, там всё просто. А Windows использует однобайтовую системную локаль, с непредсказуемым результатом.
Это было нестандартное расширение в MS STL
MadSpace?
Ссылку нашёл сходу только здесь: http://www.ag.ru/games/madspace
Как раз она отличалась ЕМНИП шизоидной геометрией уровней.
EDIT: про наличие subprogram access уже нашёл. Вопрос по лямбдам пока остаётся.
Окей, такие вещи, допустим, не везде есть. Но как в Ada с аналогами Iterable/Enumerable/Range для пользовательских типов? И что с передачей функций по ссылке в другие функции? Что с замыканиями и лямбдами?
У меня к вам вопрос с подвохом. Позволяет ли Ada объявить пользовательский тип, который можно потом "ограничить"?
Пусть есть функция с сигнатурой
В С++ распаковку придётся писать так (псевдокод):
но не получится написать проверку на ошибку, распаковку результата и возврат значения-ошибки в одном выражении:
Это Swift и Rust умеют красоту вида
Спасибо, не знал.
Увы, именно что "когда-нибудь". ranges-v3 зависят от concepts-lite. Которые не могут внести в стандарт уже лет 10. Между тем даже аналога boost.iterator_adaptors до сих пор нет в стандарте.
Немного не соглашусь.
Иметь базовые понятия чем vector отличается от hash_map или list — необходимо. Я встречал одного оригинала, хешировал 3-мерные точки методом превращения их координат в строку через to_string (который пишет 6 знаков после запятой). И так на каждый вызов хеш-функции. А потом ещё возмущался, когда ему говорили, что он не прав.
Но — требовать от человека знания алгоритма балансировки красно-чёрного дерева (если этого не предполагает вакансия) действительно глупо.
"Немного" это сколько?
Основные виды алгоритмов и структур?
Сложностные показатели?
Основные алгоритмы работы, в описательном виде?
Основные алгоритмы работы в деталях?
Доскональное знание всего вплоть до timsort, KD-tree и компании?
Увы, в С++ обработка ошибок через исключения меньше всего превращает код функции в бесконечные проверки, за которыми не видно логики. Коды возврата и коды состояния никуда не годятся, т.к. их очень легко проигнорировать. Either-style возвращаемые значения тоже не айс т.к. их во-первых нет в стандартной библиотеке, а во-вторых "раздувают" early return код — нет возможности сделать return из выражения.
Я бы предпочёл std::expected и немножко сахарку, чтобы это красиво чейнилось.