43 lines
1.6 KiB
Markdown
43 lines
1.6 KiB
Markdown
|
# libbase
|
||
|
|
||
|
## Who is this library for?
|
||
|
|
||
|
This library is a collection of convenience functions to make common tasks
|
||
|
easier and less error-prone.
|
||
|
|
||
|
In this context, "error-prone" covers both "hard to do correctly" and
|
||
|
"hard to do with good performance", but as a general purpose library,
|
||
|
libbase's primary focus is on making it easier to do things easily and
|
||
|
correctly when a compromise has to be made between "simplest API" on the
|
||
|
one hand and "fastest implementation" on the other. Though obviously
|
||
|
the ideal is to have both.
|
||
|
|
||
|
## Should my routine be added?
|
||
|
|
||
|
The intention is to cover the 80% use cases, not be all things to all users.
|
||
|
|
||
|
If you have a routine that's really useful in your project,
|
||
|
congratulations. But that doesn't mean it should be here rather than
|
||
|
just in your project.
|
||
|
|
||
|
The question for libbase is "should everyone be doing this?"/"does this
|
||
|
make everyone's code cleaner/safer?". Historically we've considered the
|
||
|
bar for inclusion to be "are there at least three *unrelated* projects
|
||
|
that would be cleaned up by doing so".
|
||
|
|
||
|
If your routine is actually something from a future C++ standard (that
|
||
|
isn't yet in libc++), or it's widely used in another library, that helps
|
||
|
show that there's precedent. Being able to say "so-and-so has used this
|
||
|
API for n years" is a good way to reduce concerns about API choices.
|
||
|
|
||
|
## Any other restrictions?
|
||
|
|
||
|
Unlike most Android code, code in libbase has to build for Mac and
|
||
|
Windows too.
|
||
|
|
||
|
Code here is also expected to have good test coverage.
|
||
|
|
||
|
By its nature, it's difficult to change libbase API. It's often best
|
||
|
to start using your routine just in your project, and let it "graduate"
|
||
|
after you're certain that the API is solid.
|