
Abseil: C++ Common Libraries - ingve
https://github.com/abseil/abseil-cpp#abseil---c-common-libraries
======
yegle
A hidden perk of this project is the open source of "C++ Tips of the Week"
(TotW internally). The plan, according to the page, is to post the revised and
vetted TotW docs to the public.

[https://abseil.io/tips/](https://abseil.io/tips/)

------
RcouF1uZ4gsC
I think one of the biggest issues for adoption will be the Bazel build system.
The C++ world seems to be slowly standardizing on CMake. Having to use another
build system to incorporate this library will give people second thoughts
about incorporating this library.

~~~
haberman
Hi there, I work at Google on the Protocol Buffers team. The Abseil team will
soon be adding CMake support (and automake, I hope). We need this for Protocol
Buffers, which currently supports CMake and automake.

~~~
shahms
Why would you wish maintenance of either of those things on your coworkers?

~~~
haberman
As grandparent illustrates, this matters to users. So it matters to me too.

~~~
shahms
As one of your users, I'd really like to stop maintaining our own BUILD files
for proto :-)

~~~
packetslave
As another of your users, I really wish the proto_library BUILD rules were
open-source :-)

~~~
DannyBee
If you feel like you are missing implicit dependencies on building haskell in
your project, you could always just add it.

~~~
mintplant
I wasn't aware Protocol Buffers had any relation to Haskell; would you mind
explaining what you're referring to here?

~~~
7197ghr918hf
Googler-on-googler trolling. The internal version of the build rule they're
discussing has some busted dependencies. Because of historical cruft, it
brings in a lot of unrelated crap. For example, building a C++ binary might
build bring in Haskell dependencies because of a protocol buffer. This is
being fixed, but it's been a thorn in our sides for years.

~~~
DannyBee
To expand a bit, the proto_library rules were "famously" broken in that it
never knew which outputs were actually used (Or so i believe that was the
cause, it's been a while)

Thus, it assumed the output was needed for any language specified in the proto
library rule. So if your proto library rule offered a haskell version,
anything using that proto library rule would do what was necessary (usually,
building haskell stuff) to make that output.

The more people offered more languages in their rules, the worse it got.

I believe this was eventually fixed (i stopped coding in the main repo years
ago, these days, i only hack on open source projects).

I expect one reason the rule was not open sourced was to not expose this cruft
to the rest of the world :)

------
ingve
Some more information is available:

[https://abseil.io/](https://abseil.io/)

[https://opensource.googleblog.com/2017/09/introducing-
abseil...](https://opensource.googleblog.com/2017/09/introducing-abseil-new-
common-libraries.html)

Almost live coverage of Titus Winters's CppCon keynote where this was
unveiled:

[https://twitter.com/CppCon/status/912742896905863168](https://twitter.com/CppCon/status/912742896905863168)

~~~
werelord
His plenary talk at CppCon is well worth it; when its posted online I highly
suggest viewing, regardless on whether one uses Abseil or not..

------
geofft
For distro packagers, is the idea that this should have SONAME libabseil.so.0
and remain at libabseil.so.0 forever?

(I know Google's preferred option is that we all realize that concepts like
"distros" and "shared libraries" and "SONAMEs" are so last century, and tbh
they are, but we'll have them for a long time yet, and it's helpful for
upstream libraries to declare what their preferred SONAME is so that you can
use the same dynamically-linked compiled binary on multiple distros.)

~~~
jlebar
Since abseil doesn't promise ABI compatibility over time, I think the notion
is you don't ship libabseil.so.0 as part of a distro.

(I'm a Googler, but this is not my project.)

~~~
geofft
Ugh, I missed that they promise indefinite API compatibility but not ABI
compatibility.

Distros aren't going to like "statically link it, and recompile all the
reverse-dependencies when there's a CVE" at all, but I totally understand why
that's a sensible approach for something that Google releases.

------
polskibus
Can anyone say what's the significance/unique value prop of this library when
compared to things like boost, bde, etc.?

~~~
7197ghr918hf
A couple of my favorite types and functions in absl:

\- Span

For when you want to take an array or a vector.

\- string_view

Avoids string copies. Makes your program faster. Its creation was a reaction
to situations like
[https://news.ycombinator.com/item?id=8704318](https://news.ycombinator.com/item?id=8704318).
(It predates that revelation, but internally the plague of string copies has
been known for some time.)

\- Mutex

A better mutex with deadlock detection.

\- Substitute

A string formatting function between 5 and 1000s of times faster than
snprintf. Profile your code some time. If it's anything like mine, you might
be surprised at how much this matters.

\- base::Time and base::Duration

Excellent wall time utilities, similar to Go's wall clock time libraries.

~~~
roel_v
"\- Span For when you want to take an array or a vector."

How's this different from taking a pair of iterators?

"string_view"

After having read all those articles about c++17's string_view, I still don't
really get the real differences. OK, when parsing (i.e. using many substrings)
it makes sense (but then you'd usually work with char* anyway); and maybe some
people interact with C libraries that only take char* a lot (and in cases
where they have to 'cross the boundary' often). So maybe in text-heavy
applications (like I imagine C++ application for the web would be) it makes
some sense, but I fail to understand why it's causing this much excitement.

"Substitute"

There are so many fast formatting libraries already - what does this one offer
over those? Because it's generally a trade off between completeness/type
safety on the one hand, and speed on the other. I use boost::format which is
quite slow in benchmarks, but again I don't do much string processing.

"base::Time and base::Duration"

In what way are these different from boost::date_time and std::chrono? Here
again the documentation (for Abseil) seem to be missing.

I mean, I'm all for batteries-included libraries - but this just seems to be a
few loosely-related classes slapped together and the only reason it's even on
here is because it's from Google. There are dozens of similar libraries
languishing on sourceforge and github. Compare it to e.g. POCO - this is not
even in the same league.

~~~
int_19h
> I fail to understand why it's causing this much excitement.

C++ guys just like zero-overhead abstractions. The more we can get, the
better. Passing std::string around has always been a sore point, and
occasionally prompted misguided optimizations (like refcounting copy-on-write
in g++).

~~~
roel_v
Well yes, I'm what one would call a 'C++ guy' myself. Don't pass around, pass
around const std::string&. What I see left and right is people saying 'you'll
never pass a const std::string& any more!'. The way I see it: you'd pass a
string_view in the cases where, in the past, you would have had to copy a part
out of a string (which is rare, except in parsers), or when dealing with char*
API's; what's better about passing a string_view than passing const string& ?

~~~
int_19h
Nothing. But I would disagree that having to copy a part of a string, or
having to pass part of a char buffer that is not a string, is all that rare,
even outside of parsers.

------
erik_seaberg
Also:
[https://news.ycombinator.com/item?id=15339564](https://news.ycombinator.com/item?id=15339564)

------
ggchappell
Is there any documentation?

This looks like it might be good, but I don't know how to tell whether it is.
The "Codemap" is just links to repo directories. The "Abseil Introduction"
link leads to basically to another version of the README. It does have an
"Abseil C++ Quickstart" link, which tells you how to get the package, but
doesn't tell you what's in it.

I see things about design philosophy, compatibility, etc. But what about: what
functions can I call, what do they do, and how do I call them?

Is there any way to find out what's in this thing, other than reading source
files?

\------------------

EDIT. Style guidelines, exceptions policy, leaking checking, platforms guide,
linking your code, feature check macros, yadda yadda yadda ....

WHAT FUNCTIONS CAN I CALL, WHAT DO THEY DO, AND HOW DO I CALL THEM?

(Sorry. I'll go calm down now.)

~~~
katzdm
[https://abseil.io/docs/cpp/guides/](https://abseil.io/docs/cpp/guides/)

This provides partial coverage, for some of the most useful bits. I believe
additional docs are in the works.

~~~
ggchappell
Very partial, yes. But thanks.

------
ezoe
It looks like most of the libraries are C++11 implementation of some of the
C++14/17 standard libraries.

~~~
katzdm
I wouldn't say "most", though this is definitely a slice of what is offered.

Some of this is also laying the groundwork for the release of further APIs, as
well as making it easier for Google to release/support higher-level libraries
(eg. Protobuf, TF, etc).

------
jonstewart
Whatever happened to the B-Tree library? Will it be included in Abseil's
container lib some day?

~~~
trimbo
It's still available in the Google Code archive:
[https://code.google.com/archive/p/cpp-
btree/](https://code.google.com/archive/p/cpp-btree/)

