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 ()

Очень круто, но пользоваться не буду.

shpinog ()

ошибкопорождающий

Интересный перевод для error-prone.

anonymous ()

Выпустили когда уже устарело? Спасибо!

А этот TensorFlow, привязанный к закрытому железу Nvidia пускай себе оставят!

svyatozar ()

Ещё одна ненужная зависимость будет грузом в системе

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

Это же плюсы, они целиком состоят из распухших бинарников и зависимостей. Подумаешь, сто метров больше, сто метров меньше.

devl547 ★★★★★ ()
Ответ на: комментарий от 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 ★★★★★ ()
Ответ на: комментарий от vzzo

Работа в чём угодно с таймзонами — это полнейшая боль.

Centaur ()
Ответ на: комментарий от 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 ★★★ ()

А как у них с поддержкой юникода?

Их функции для строк будут работать с utf8 и т.п.?

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

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

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

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

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

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

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

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

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

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

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

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

Если я знаю откуда она, то что мне мешает указать таймзону самому?

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

Если я знаю откуда она, то что мне мешает указать таймзону самому?

А ты попробуй. И посмотри что получится.

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

А потом я не понимаю почему килобайтная программа требует 2 гигабайта для сборки

mittorn ★★★★★ ()
Ответ на: комментарий от 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 ()
Ответ на: комментарий от RazrFalcon

Может стоит перестать говорить загадками?

Перестань.

И попробуй.

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

Про летнее время слышал?

Вызывайте ремонтную бригаду, у нас тут криокамера протекла. И, да, Qt прекрасно знает об DST.

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

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

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

Вызывайте ремонтную бригаду, у нас тут криокамера протекла. И, да, Qt прекрасно знает об DST.

В твоем решении нет учета разного типа времени.

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

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

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

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

В твоем решении нет учета разного типа времени.

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

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

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

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

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

Так покажи решение, если проблемы нет.

x86_64 ★★★ ()
Ответ на: комментарий от 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 ()
Ответ на: комментарий от anonymous

Толстый троль!

Я уже говорил. В пятницу, 22 сентября 2017 года в 0:00 перевели на час назад. Дай мне пример с двумя разными 21 сентября 2017 года 23:45.

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

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

Гугли DST и читай как считается этот час, задолбал уже.

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

угли DST и читай как считается этот час, задолбал уже.

Рабочег примера не будет. Я так понял?

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

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

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

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

Локальные 21 сентября 2017 года 23:45 в Иране были только одни

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

x86_64 ★★★ ()
Ответ на: комментарий от 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 ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.