LINUX.ORG.RU

Google представил открытую библиотеку Abseil для разработчиков на C++

 , , , ,


0

4

В понедельник Google выпустил исходные коды библиотеки Abseil, созданной для того, чтобы значительно дополнить стандартную библиотеку языка C++. Данный код на протяжении многих лет использовался как базовая библиотека при разработке закрытого ПО, но был вынесен в отдельный открытый проект для упрощения открытия исходных кодов и разработки других библиотек, например, protobuf, grpc и tensorflow. Код распространяется под лицензией Apache 2.0.

Библиотека собирается с помощью bazel — системы сборки с открытым кодом, которая используется в Google. Данная система сборки позволяет точно контроллировать зависимости и получать воспроизводимые артефакты, но достаточно неудобна для повседневного использования. Но библиотека предполагает статическую линковку, так что её интеграция в любую систему сборки будет тривиальной.

Интересные части библиотеки:

  • absl::Mutex — примитив синхронизации, который одновременно может служить мьютексом, condition variable и read-write-блокировкой. Данный класс был разработан до появления C++11, но не был заменён std::mutex и его аналогами, так как предоставляет менее ошибкопорождающий интерфейс.
  • Бекпорты некоторых возможностей C++14/C++17 для компиляторов, поддерживающих только C++11: absl::make_unique, absl::optional, absl::any, absl::span, absl::string_view. При этом при сборке новым компилятором большинство absl:: типов будут обычным typedef для библиотечных.
  • «Стандартный» набор функций работы со строками: split, join, replace, объединение строк, перевод чисел в строки и обратно.
  • Функции и классы для работы с временем и промежутками времени (по сути дублирующие аналоги из std::chrono); 128-битный целочисленный тип данных; InlinedVector, позволяющий хранить маленькие массивы без выделения памяти; и прочее.

В данный момент список не очень большой, но библиотека постоянно будет дополняться.

>>> Подробности на opennet

★★

Проверено: shell-script ()

забавно как почти все фичи уже есть в новой ревизии с++, но у новой ревизии с++ ноги растут не из гугла, а скорее из буста. при этом промежуточные ревизии (14, 17) они использовать не торопятся, а бекпортируют некоторые фичи в 11, что имеет смысл. если стандартную библиотеку дополнят функциями работы со строками, все вот эти join, split etc, то гугл в принципе сможет работать на ванильном с++21 каком-нибудь.

хотя и без split с join они местами нос воротят и не хотят что-то переписывать на новой стандартной библиотеке, что тоже имеет смысл.

с++ окончательно зохватывает мир, пацаны, даже гугл по большому счёту не смог придумать чего-то такого, чего нет в новом с++. с++14 или 17 - это так, доводка того, что забыли сделать в с++11, до с++21 ещё дополируют и всё, сливайте воду, новый властелин прибыл.

anonymous ()
Ответ на: комментарий от anonymous

хотя и без split с join они местами нос воротят и не хотят что-то переписывать на новой стандартной библиотеке, что тоже имеет смысл.

Мне кажется, split/join, работающих с vector, в стандартной библиотеке не будет никогда, так как им нужна всякая обобщенность, независимость от контейнеров, итераторность и возможность не платить в рантайме за то, что не используешь. В результате обычный split из

for (const auto &i : std::split(s, " ")) ...
превращается в
{
  std::vector<std::string> tmp;
  std::split(s, " ", std::back_inserter(tmp));
  for (const auto &i : tmp) ...
}
Что мы примерно и видим в бустовой реализации.

vzzo ★★ ()
Ответ на: комментарий от te111011010

Зачем, если есть Qt?
Зачем, если есть boost?

Ответ написан в первом параграфе: «для упрощения открытия исходных кодов и разработки других библиотек, например, protobuf, grpc и tensorflow».

Например, работа в Qt с таймзонами — это полнейшая боль (что уже немного мотивирует пользоваться absl::Time). int128 и InlinedVector в Qt нет.

Работа с половиной буста — тоже боль, по причинам, описанным в сообщении выше.

vzzo ★★ ()
Ответ на: комментарий от vzzo

работа в Qt с таймзонами — это полнейшая боль

Пруф?

int128 и InlinedVector в Qt нет.

Зато в Qt есть сотни классов, которых нет в absl. И? Ну и в Qt есть QVarLengthArray который лежит на стеке.

RazrFalcon ★★★ ()
Ответ на: комментарий от te111011010

Зачем, если есть Qt?

примитив синхронизации, который одновременно может служить мьютексом, condition variable и read-write-блокировкой

Бекпорты некоторых возможностей C++14/C++17 для компиляторов, поддерживающих только C++11

128-битный целочисленный тип данных

Что из этого есть в Qt?

annulen ★★★★★ ()
Ответ на: комментарий от vzzo

они утверждают, что

vector<string_view> = split(s, " ")

не будет копировать строки т.к. их не копирует string_view. плюс гугловский split умеет трансформировать результат сплита в любой совместимый контейнер, хоть в set<string>. т.е. педположительно

for (const auto &i : split(s, " "))

а) будет работать б) будет работать с минимальными накладными расходами.

это очень серьёзная предъява.

anonymous ()
Ответ на: комментарий от RazrFalcon

работа в Qt с таймзонами — это полнейшая боль

Пруф?

Раньше нельзя было простым способом узнать время если ты получил строку со временем другой таймзоны.

Вот сижу я, скажем, в Москве, получил строку с локальным временем из Ирана как узнать какое время обозначает эта строка?

Сделали ли такую возможность сейчас - не знаю. Быстро посмотрел - не нашел.

x86_64 ★★★ ()
Ответ на: комментарий от RazrFalcon

Какую строку? Вы о чём? Есть QTimeZone и есть поддержка зон в QTime и QDate.

Я сформулировал предельно просто. Есть вариант решения - огласи. Нет - ну сам понимаешь...

x86_64 ★★★ ()
Ответ на: комментарий от RazrFalcon

Для меня - нет. Если строка не содержит в себе таймзону - откуда мне знать откуда она? Если содержит - то Qt это понимает.

Если строка не содержит в себе таймзону - откуда мне знать откуда она?

Этот вопрос не касается поставленной задачи. Из ее условий следует, что ты знаешь - откуда она. Не коси под дурачка.

x86_64 ★★★ ()
Ответ на: комментарий от x86_64

Вот сижу я, скажем, в Москве, получил строку с локальным временем из Ирана как узнать какое время обозначает эта строка?

auto dt = QDateTime::fromString( "2017-09-28T19:30:00", Qt::ISODate );
dt.setTimeZone( QTimeZone( "Iran" ) );
dt = dt.toTimeZone( QTimeZone( "Europe/Moscow" ) );

qDebug() << dt;

QDateTime(2017-09-28 19:00:00.000 MSK Qt::TimeSpec(TimeZone) Europe/Moscow )

Руки надо просто из жопы доставать.

anonymous ()
Ответ на: комментарий от x86_64

Напиши мне 21 сентября 2017 года в 23:45 летнего, а затем такое же зимнего. :)

Во-первых ты уже с Ираном обосрался, и писать тебе уже никто ничего не будет, т.к. ты рукожоп, во-вторых учи матчасть.

anonymous ()
Ответ на: комментарий от x86_64

Забавный... Я зря что ли про Иран вспомнил. Они 22 сентября 00:00 на зимнее время переходят. Как раз на час назад.

У тебя есть инет - иди смотреть разницу во времени, смотри ее в моем примере, думай.

anonymous ()
Ответ на: комментарий от anonymous

У тебя есть инет - иди смотреть разницу во времени, смотри ее в моем примере, думай.

Еще раз. Твой пример не дает возможности задать время для целого часа, который был неделю назад.

Думай :)

x86_64 ★★★ ()
Ответ на: комментарий от x86_64

Еще раз. Твой пример не дает возможности задать время для целого часа, который был неделю назад.

Убейся уже.

auto dt = QDateTime::fromString( "2017-09-19T19:30:00", Qt::ISODate );
dt.setTimeZone( QTimeZone( "Iran" ) );
dt = dt.toTimeZone( QTimeZone( "Europe/Moscow" ) );

qDebug() << dt;

QDateTime(2017-09-19 18:00:00.000 MSK Qt::TimeSpec(TimeZone) Europe/Moscow )

anonymous ()
Ответ на: комментарий от x86_64

Дай мне пример с двумя разными 21 сентября 2017 года 23:45
Рабочег примера не будет. Я так понял?

Наркоманией не занимаюсь. Локальные 21 сентября 2017 года 23:45 в Иране были только одни, конвертироваться они должны тоже только в одно время, а не в два. Если тебе не нравится поведение Qt, и тебе хочется два времени, то обратись в лигу сексуальных реформ, там тебе помогут.

anonymous ()
Ответ на: комментарий от anonymous

Он прав, читай про tzdata https://habrahabr.ru/post/130401/ . Может чел тебе не достаточно правильно пояснил, в один момент времени локальное время всегда одно, но расчет его из разных точек времени дает разный результат. ПО, которое привязывает определенное действие к определенному времени, обязанно корректно его обработать в соответствии с как можно более свежей базой tzdata.

anonymous ()
Ответ на: комментарий от x86_64

Какие на твой взгляд, когда первый раз это время на часах было или второй?

Неправильно выразился, локальное время записано одно, и ему соответсвует одно же время в другом поясе, и если не указано смешение, то используется заранее описанный способ преобразования, а не на мой взгляд.

anonymous ()
Ответ на: комментарий от anonymous

Он прав, читай про tzdata https://habrahabr.ru/post/130401/ .

Ты вообще не в тему, если что. Ему не временные зоны не нравятся, и даже не DST, а конкретно поведение при расчете одного конкретного часа при переходе на зимнее/летнее время. При этом вряд ли он сможет предложить «правильный» вариант.

anonymous ()
Ответ на: комментарий от anonymous

Неправильно выразился, локальное время записано одно, и ему соответсвует одно же время в другом поясе, и если не указано смешение, то используется заранее описанный способ преобразования, а не на мой взгляд.

А вот как раз указано что одно время летнее, а другое зимнее. И имея tzdata это разрулить без можно. Муторно, но можно. Одним Qt никак не отделаться.

Из сылка ононимуса:

В базе tzdata содержится детальная информация обо всех часовых поясах во всех регионах мира: — указано, в каких регионах применяется летнее время (DST), насколько оно смещается относительно стандартного, указаны точные даты и время переключения на летнее время и обратно в различных регионах в различные периоды;

Так что он все по делу сказал.

x86_64 ★★★ ()