After spending most of my waking time on Stack Overflow, for better or for worse, I've come to notice how 99% of the C++ questions are answered with "use boost::wealreadysolvedyourproblem", but there must definitely be a few areas Boost doesn't cover, but would be better if it did.
So what features is Boost missing?
I'll start by saying:
PS: The purpose is to compile a reasonable list, and hopefully Boost-like solutions out there that aren't yet a part of Boost, so no silly stuff like boost::turkey please.
A boost::log library is my vote. For logging messages, not logarithms, silly.
Well, I don't keep my expectations high, but boost::callstack would be nice (or maybe it should be boost::debug::callstack). I mean, on most platforms (compilers) the callstack info could be easily retrieved - it would be nice to have one api, that would work on all platforms.
a boost::archive to directly manipulate .zip, .tar, .rar, etc. files would be useful.
boost::stl, seriously, something along the lines of the EASTL [1]. A fast, efficient STL implementation which gets rid of the legacy problems. There has been some discussion at the Boost mailing list about new IOStreams, which would be byte oriented (and not character oriented!), things like that should really be done.
Besides that, it would be nice if a XML library like TinyXML [2] would get into Boost. And give me a good string library which works by default with UTF-8 strings.
Finally, concurrency stuff in spirit of the
TBB
[3]. We already see GCC implementing parallel_for
(
parallel mode
[4]), Microsoft is coming next -- obviously, this is something that should get standardized.
boost::gui would be a nice addition.
boost::concurency, like mentioned above, may contain lock free data structures, atomic operations, different usermode synchronization objects(spin locks) and so on.
Is there a boost::xml? If not then TinyXML should be adopted. :)
How about a good arbitrary precision float (or int) data type. Sometimes you want to carry around a number with super high precision (like calculating pi).
I would like much some boost::gpu to abstract call to layers like cuda or openCL with nice syntaxic sugar. I can't believe software vendors are actually providing their own compilers (nvcc for cuda) for that purpose.
Cross-Platform, high performance timing. The microsecond timer doesn't work on windows (it will not throw errors, but is highly discontinuous).
I'd like to see more high-level language interfaces like the existing boost::python.
boost::ruby maybe?
From what I can tell boost stays away from specific standards. Whereas you might expect that it could have a DOM library, it might not be specific to XML or JSON.
Anything touching hardware would be right out. Anything touching specific standards is out. Anything platform specific is out (unless it can clearly be made to be non-specific). Anything requiring other libraries is out.
You dont find boost gzip or boost png, because again too specific. Nor audio or GUI stuff because they touch hardware/platform/other libs.
Basically anything that could be a moving target is out.
Good candidates for boost libs would be very generic concepts that can be improved until there is no reason to modify it again except to fix bugs.
Boost RPC.
Something that connects the boost network/IPC-functionality with the serialization features to make it possible to call functions on processes remotely in some fancy type safe way.
It should preferably be cross platform (no endian problems), floating point compatible, and string encoding agnostic.
boost::atomic
A thread pool.
boost::encoding would be nice. A library to be able to convert between different character encodings.
A checksum/hashing library. The CRC-library is nice, but md5 or sha would be useful as well.
boost::os to query and interact with the machines enviroment, settings and performance info in a standardized C++ fashion. And it would probably provide other c-posix capabilities missing from C++.
Also boost::url would be nice (probably a cUrl wrapper)
boost::coroutines
Why not have a call tree or even a call graph instead of a dull call stack?
boost::extensions for adding scripting support to your application. You'd have boost::extensions::scheme, boost::extensions::python, boost::extensions::ruby and boost::extensions::lua etc.
Kind of like guile.
Fixed size strings.
How about Boost::MQ. A message queue to augment Boost::ASIO
Boost.Unicode. Unicode is such a core component in many technologies desired above/below*: XML, GUIs, etc. Its existence would provide a much needed stepping stone.
*delete as appropriate.
boost::cryptography
, including a wide set of security related algorithms, similar to Crypto++. As I often write networked applications that need different kinds of security on application level, I would love this feature to be present in boost. There are some libs around (I mostly use crpyto++) but having it clearly licensed in the boost library would be very helpful.
I would definitely be interested in a Boost.Sql
library.
However, I think to really be interesting, one should up the bar (in term of interface) from the SOCI interface you mentioned.
Here is the kind of thing I'd like to write:
DEFINE_TABLE(
myTable,
((id, Int, NotNull))
((name, VarChar2<56>, NotNull))
((firstName, VarChar2<64>, Null)),
(PrimaryKey)(id)(name)
);
And then:
auto aQuery = Select(myTable.id, myTable.name).From(myTable).Where(myTable.firstName != Null);
auto aCursor = Cursor(aQuery);
std::list< std::pair<int,std::string> > aList;
while(aCursor.fetch())
{
aList.insert(std::make_pair(aCursor.get(myTable.id), aCursor.get(myTable.name)));
}
I am definitely waiting for the auto
keyword of course, since this implies a high degree of template meta-programming, but I do love DSELs and compile-time checking of the validity of a sql request with "natural" syntax would be a huge boon!
auto
it's difficult because of the types generated :/ - Matthieu M.
@Vicente
, I just had a look at Boost.rdb and its interface is very promising. I have only read about sql query formatting, don't know if it does much more, and it doesn't look like it uses parameterized sql when the parameters are known at compile time (which is a shame I think), but it's a really good piece of work imho :) - Matthieu M.
I hope you will find this link Libraries Under Construction [1] useful.
Please let me know if you want I add some wish libraries to it by adding a comment to this answer, or posting on the Boost ML.
[1] http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstructionboost::gc is one thing missing from it.
It could have the following classes and functions:
gc_ptr<T>: garbage-collected pointer.
gc_base<T>: garbage-collected base class.
gc<T>: garbage-collected wrapper class.
gc_collect(): collect garbage manually.
Using it would be like this:
gc_ptr<int> data = new gc<int>[100];
class foo : public gc_base<foo> {};
gc_ptr<foo> foo1 = new foo;
The implementation would be free to choose between Boehm's gc or a map-based implementation.
I'd like to see something like the SafeInt [1] library in boost.
It can catch integer overflow and casting problems at runtime.
[1] http://channel9.msdn.com/shows/Going+Deep/David-LeBlanc-Inside-SafeInt/A logic programming library including unification and backtracking.
config files support with reading and writing
I used boost:program_options to read config files and there is some unkept promises. My point is that boost::po supports a kind of unification between command line option and config files parsers, but for config files what is available fall short : only one supported format similar to old windows ini files.
But my biggest regret is definitely that boost::po has not the slighlest hint of a write support for config files.
boost::artificial_intelligence
boost::persistent_collections
⇒ A Persistent Collections Library.
How about Boost::Network for items like SMTP, FTP, HTTP protocol handlers etc.
boost::unique_ptr. The one in Boost.Interprocess needs to put into Boost.SmartPtr so that anyone may use it (without having to depend on Interprocess).
Boost.Singleton
I would also like to see a boost::tree which may even be a subset of the Boost Graph Library. There has been at least one Stack Overflow [1] question about C++ tree implementations and apparently a proposal [2] for boost::tree existed a couple of years ago but I guess it died out. From the Stack Overflow question, the lack of a "good" one-size-fits-all approach disqualifies it from being incorporated into Boost; a good deal of free third party implementations exist too.
From reading other answers, about XML and JSON, I believe a similar approach could be adopted. Instead of boost::xml/boost::json you would have a boost::dom that could be configured to read XML or JSON. Instead of boost::quadtree or boost::octtree you would have a boost::tree that could be configured to manipulate one or the other. That's highly simplified so I wonder if it's practical.
[1] http://stackoverflow.com/questions/205945/why-does-the-c-stl-not-provide-any-tree-containersBoost::time
I hate the cstdlib time.h, simply because it makes me hack out how long my program is taking.
Regarding boost::sql proposal, there is some work in progress:
Arrays indexed by enums
Unique identifier : Use to create unique identifiers for example in database tables, network messages session identifiers, transactions identifiers.
regarding boost::sql there is Wt dbo [1] although it is more like hibernate
[1] http://webtoolkit.eu/wt#/blog/2009/11/26/wt__dbo__an_orm__c___styleboost::reflection, boost::eval, boost::emit, and boost::compile.
The scoped_guard as included on the detail directory of Boost.MultiIndex
Boost.Persistent able to manage with objects stored on a persistent storage
Boost.Tree: divers tree implementations and hierarchical iteration
well, i need the following:
boost::make, or boost::system something like that. which should provide facilities to call system commands, captures the shell output, gets the return values etc... using APIs to be used inside a C++ program. so that i can get rid of scripting language whenever i choose to. May be they can extend the boost::program_options to take care of this.
boost::graph needs some improvement on interface level. it takes a while
to learn BGL.
why? because the functions that it provides are not too easy to use in the first place.
ObjectRole a library that helps to implement the Object Role pattern.
EnumSet similar to bitset but with enum indexes.
Boost.Quartet Quartet are half an octet, i.e. 4 bits taking values from 0..15, and usually represented by chars '0'-'9' 'A'-'F'. There are some container specializations as std::string, std::vector and boost::array that could be of interest to some applications. They are also used when a decimal number is encoded using the BCD format (binary coded decimal) or to encode telephone numbers.
Monotonic allocators.
Formatted container output: Simple and uniform display mechanism for arbitrary ordered lists
boost::video : sort of like directshow/vmr
Why boost::json if Boost.Property_tree already can do it?
Property trees can be created from JSON, XML and INI.
Also boost::sql could be really useful if it worked with many different SQL engines(?) like MySql, PostgreSQL and even Sqlite. You could easily modify the database location with a simple line modification.
It's hard but I think possible, boost::location
boost::avl
a library for self-balancing binary search tree, modeled around boost::graph
Boost.TUI (Text User Interface)
A portable interface to construct text base user interfaces.
boost::graphics
I've seen a suggestion on GUI which is arguably adequate, but I think a really good addition to boost would be low level graphics, rasterization, primitives, paths, gradients, fonts as well as surface/canvas to use the graphics on, blending, blitting... all those can naturally be platform independent.
Recently boost included GIL - the generic image library, so I think low level, platform independent 2d graphics will contribute a lot to boost.
boost::magic_button
You simply add a magic button to your program, and it does everything.
boost::wealreadysolvedyourproblem
you mentioned sounds pretty good, actually. My vote goes to that. ;) - jalfboost
tries to be a general-purpose library; I don't think there is a place for stuff like SQL, JSON and audio. - Thomasboost::dwim
— that would render all other libraries redundant. :-) - celtschk