While the absl:: namespace is aliased to std:: in a
standard win32 build, it also needlessly adds the
library to the build process, only to discard most
of it at link time. This also makes the distinction
between Abseil STL and G++ STL more explicit, to avoid
some forms of confusion.
From the product page:
"...We think not: if you look at the preprocessor conditional
structure in our string_view.h you'll see that we are trying
to identify whether your C++ installation has std::string_view.
If you do, absl::string_view is defined only as an alias to the
standard type. If you don't, you get a C++11/C++14 compatible
implementation of the type. This means you can adopt Abseil,
and for types we are b you can use the type from the absl
namespace. As soon as your project is built with the appropriate
compiler/standard library version, we'll fall away and leave you
with the standard type, albeit spelled funny. Better: as soon as
you know that your project will only build with the appropriate
language version you can run tools that we will provide to change
the places that refer to absl::string_view to spell it std::string_view
-- since those are the same type, this is safe to do, even across
API boundaries.
So, one reason you might want to adopt Abseil: early access to facilities
from upcoming C++ standard library releases, with a clear migration path."
enable lokinet shared library on win32
TODO: define an API to expose from this library
currently, it resorts to exporting *everything*
including system implementation details that otherwise
should remain hidden out of sight
(i.e. the winsock2 load stubs for new socket API, or entire libstdc++ classes!)
