Компания Google представила (https://opensource.googleblog.com/2017/09/introducing-abseil...) проект Abseil (http://abseil.io/), в рамках которого открыта коллекция полезного кода для разработчиков на языке C++, расширяющего стандартную библиотеку функций. Исходные тексты распространяются (https://github.com/abseil/abseil-cpp) под лицензией Apache 2.0.В состав библиотеки включены функции общего назначения, используемые в продуктах Google и хорошо протестированные на реально работающих проектах. Одна часть предложенных в Abseil функций заполняет ниши, не определённые в стандарте C++, а другая предоставляет альтернативные реализации штатных возможностей стандартов C++14 и C++17, адаптированные для использования в коде на C++11 (например, типы optional, any и string_view). Google не пытается продвигать Abseil как альтернативу стандартной библиотеке, а лишь желает поделиться с сообществом кодом, который оказался полезен в собственных проектах.
Компоненты библиотеки:- base - базовая часть, включающая код для инициализации и первичные примитивы, которые используют только стандартную библиотеку C++, но при этом выступают в качестве зависимостей для других компонентов Abseil;
- algorithm - библиотека с коллекцией алгоритмов, дополняющая одноимённую стандартную библиотеку C++ и включающая варианты предложенных в ней алгоритмов, оформленных с использованием контейнеров (http://www.cplusplus.com/reference/stl/);
- container - библиотека с дополнительными контейнерами в стиле STL;
- debugging - отладочная библиотека, добавляющая проверки для выявления утечек;
- memory - включает совместимую с C++11 реализацию std::make_unique() и других функций, связанных с управлением памятью;- meta - включает совместимые с C++11 версии механизмов проверок типов, появившихся в библиотеке type_traits в C++14 и C++17;
- numeric - предоставляет совместимые с C++11 реализации 128-разрядных целых типов;
- strings - подборка функций для обработки строк, включая absl::StrCat(), absl::StrJoin() и absl::StrSplit(), а также совместимую с C++11 версию типа std::string_view, появившегося в стандарте C++17- synchronization - примитивы для организации параллельно выполняемых потоков, класс absl::Mutex (оптимизированная замена std::mutex) и набор абстракций для синхронизации потоков;
- time - функции для операций с абсолютными моментами времени (absl::Time), отрезками времени (absl::Duration), форматирования и разбора значений времени. Также предложен absl::Now() , оптимизированный вариант std::chrono::system_clock::now();
- types - подборка типов, например, совместимый с C++11 вариант absl::optional.
Дополнительно развивается (https://github.com/abseil/abseil-py) вариант библиотеки для языка Python, включающий систему обработки флагов командной строки и модуль для организации ведения логов.URL: https://opensource.googleblog.com/2017/09/introducing-abseil...
Новость: https://www.opennet.ru/opennews/art.shtml?num=47275
Какая-то совершенно бессмысленная штука. Зачем нужна (почему не взять сразу нормальный компилятор) - непонятно, зато фактически обещают всё постоянно ломать и исключают возможность нормального использования как shared lib, от которой зависит софт в дистрибутиве.Хотя, к моему удивлению, они в кои-то веки плюс-минус поддержали исключения. Надо же, окстились слегка.
Самое весёлое, что с std::variant<T, E> и std::expected на горизонте исключения больше не нужны для современной обработки ошибок.
Только во влажных мечтах растодетей.
Какая милая наивность. expected иногда хорошо подходит, но никоим образом не делает исключения ненужными (не говоря о том, Что оно само на исключениях основано). Во многих случаях оно излишне или прямо мешает, путая основной code path с разного рода реакциями на экзотику.Александреску это, разумеется, понимал и явно упоминал, что это просто удобное средство для многих случаев.
Ну, или вам в C/go, это там любят всё явно на каждый чих проверять.
> Ну, или вам в C/go, это там любят всё явно на каждый чих проверять.Вот лохи то, не то что реальные пацаны, программы которых просто падают с абсолютно одинаковым unhandled exception по совершенно разным причинам. Ведь пользователь ни в коем случае не должен узнать, что именно пошло не так. А то еще загуглит решение или сам решит проблему. Нет, пользователь программы должен страдать.
То ли дело error codes --- пусть пользователь даже не знает, что программа игнорит критическую ошибку, пока не станет слишком поздно
Это как раз с expected решается (не проверишь, а там ошибка - получишь старый добрый exception), но код уж больно замусоренный когда проверка на ошибки перемешана с основной логикой.
Во-первых, ты передёргиваешь, и сам это понимаешь. Отложить обработку исключений в конец функции - совсем не то же самое, что один try-catch на всё про всё. Ну а чтобы вообще unhandled exception получить - такое я в плюсах очень редко вижу в отличие от питона того же.Во-вторых, часто пользователю и правда абсолютно побоку, что именно пошло не так. Главное - этом должно быть вывалено достаточно инфы чтобы осмысленно репортить проблему.
А вот с проверкой на каждой строке код становится весьма неудобно читать - слишком отвлекается внимание от основной логики. Что уменьшению количества ошибок никак не способствует. Плюс это много медленнее, чем исключения (если исключения достаточно редки, конечно).
Код ошибки: Опаньки что-то пошло не так
ГуглХроме стайл
Когда же доктора научатся вместо истории болезни такие коды ошибок использовать?
> Во многих случаях оно излишне или прямо мешает, путая основной code path с разного рода реакциями на экзотику.Для такого сценария как раз почти подходит variant. Но я сомневаюсь, что в нём сделали bind.
std::variant - это довольно дeбильная штука, т.к. если T и E - это один тип, то получается карачун.
>> Какая-то совершенно бессмысленная штука.Но у тебя против неё есть волшебная сила — идти мимо.
А то! У гугла вообще много странного, которое, вероятно, не с пустого места родилось, но либо нормально себя чувствует именно в их экосистеме либо вообще дохнет со времененм по ненужности. Одно GWT вспомнить.
Зачем это нужно, когда есть буст?
от буста в последние годы разрабы бегут как от дуста ...
Едрить коптить. То его все задрачивали, а теперь оказывается все от него бегут. Что произошло?
вышли стильно молодежные стандарты? с более понятными доками и прочим?
> Что произошло?Джун сэкстраполировал свою неосиляторскую шаражку на весь мир.
А мужики-то не знали...
Зачем это нужно, когда есть раст?
Потому, что не каждый разработчик педе...ст.
пупоразрывающий хохот, сопровождаемый руколомными аплодисментами, Петросян вскочил со своего места в зале и пустился в пляс
А что, Rust как язык, уже стандартизировали?
Когда-то было скучно и я писал многопоточный процесс-сервер на boost. С тех пор я не то, чтобы boost не люблю, но неприязнь ко всем плюсам. Там была ошибка передачи данных в какой-то конструктор, у которого была нехилая перегрузка. Сообщение об ошибке настолько непонятным, что даже Гугл еле помог. Точнее, он помог найти описание ошибки на форумах, где говорилось, что её текст Вам ничем не поможет, а на самом деле в конструктор просто передавался неверный аргумент или что-то в этом духе.
Ты просто не умеешь в многопоточность. Ни в одном языке против неё не существует серебрянной пули.
сообщения об ошибках компиляции в плюсах известная слабость. Про это и деды писали, то ли меейрс то ли этот, как его, забыл какого-то пенсионера из собеса для всяких александреску. В советах про эффектив стл вроде пару советов было - как читать ошибки размером со страницу текста. При этом сишечка, что характерно, за все эти десятилетия до такого не дошла. В дом престарелых не собирается.
erlang
О да, там-то сообщения - вершина понятности. Причём, блин, в рантайме.
Зачем это нужно, когда есть dlib?
>предоставляет альтернативные реализации штатных возможностей стандартов C++14 и C++17, адаптированные для использования в коде на C++11ой, а можно тоже самое, только с c++11 и c++03?
>>предоставляет альтернативные реализации штатных возможностей стандартов C++14 и C++17, адаптированные для использования в коде на C++11
> ой, а можно тоже самое, только с c++11 и c++03?Boost.
Hooyust
В google coding standard использование своего метапрограммирования (да и шаблонов) было запрещено. Как они дошли до создания subj?
И исключений. Тем не менее дошли. А куда деваться - текущие плюсы без всего этого становятся совершенно бессмысленными - это стало слишком важной частью языка.
Скорее "выработалась методика правильного использования эксепшенов"
Она сто лет как выработалась - с момента ухода от checked exceptions. Но гугл зависел (и зависит), от старого кода, где эксепшны не живут. Но сейчас ежу ясно, что плюсовая библиотека общего пользования без эксепшнов и прочих удобных и полезных плюшек просто не взлетит. Тем более, если они претендуют на использование современного тсиля плюсов и реализацию фишек новых стандартов.
никаких изменений по поводу исключений нет.
https://google.github.io/styleguide/cppguide.html#ExceptionsСомнительная вкусность плюшек исключений всё так же недостаточно заманчива для гуглокодеров.
> container - библиотека с дополнительными контейнерами в стиле STL;
> в стиле STL;Ничем не учатся...
Очередная реализация strings для С++? Пора уже, а то давненько что-то не было...