Edit: What I'm really thinking of is a C++ equivalent to the Contrib libraries other languages enjoy, like CPAN/PyPI/Ruby Gems
Suppose I want a collection type that isn't really supported by anything in the STL or by BOOST, like a spacial index or a fibonacci tree (if i think that might be useful on my really big dataset). Is there a good place to find these kinds of less common tools?
Sometimes Vault has useful things. maybe you can find something there.
As it is said, google is your friend :-)
It appears that here (http://resnet.uoregon.edu/~gurney_j/jmpc/fib.html) is an implementation of Fibonacci heap in C. Check it out, and if you like it, may be you can translate/modify/improve to a C++.
Well, I don't know if there are any actual 'collections of libraries', but i'll start a list of useful libraries. (C++ libs only, please)
There's Boost, obviously, but also Boost Vault, which appears to contain libraries that aren't quite ready for inclusion in Boost proper. (thanks aaa carp for pointing this out)
GMP, an arbitrary precision number library, has C++ bindings
Qt, which is about as old as the moon, but also modern enough to still be useful. This of course is a heavy handed application library, but there's no real reason not to use whatever parts could be useful. I'm not too sure how esoteric that really is, though. Outside of the GUI portions, most functionality would already be duplicated by boost.
libCurl has c++ bindings, for http access (and other things)
Related
I have seen lots of people suggesting the Boost library on Stack Overflow, so I am also thinking of learning it. But today I came across this link: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Boost
I wanted to know about its acceptance in industry at a broader level. My current company also doesn't allow me to use this so I am confused whether to look into this or not.
Parts of Boost library is currently being accepted into the Standard library for C++0x and it is regarded as one of the top libs with a high industry acceptance. I'm actually unaware of any other library getting accepted into the C++ Standard Library on such a large scale.
"Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) and will be in the new C++0x Standard now being finalized. C++0x will also include several more Boost libraries in addition to those from TR1. More Boost libraries are proposed for TR2."
You should definately look into this. Don't go by Google or any other large institution. They generally have to work to a subset of any complex language like C++. Hence, they'll have restrictions on which parts they can use so that it's easier to hire and train engineers to use the code base.
Additionally, Boost leverages many aspects of the higher forms of functionality within C++, case in point template meta-programming. Boost provides for a safer, though bulkier, form of functions as first class objects. They add in a more powerful "bind" which works so well with the standard library that I'd be lost without it. Finally, they have in place tuples and hash tables, both fundamental datatypes in modern development libraries.
In short, I really can't name one reason why you wouldn't want to look at Boost, even just to learn something. It's peer reviewed and largely platform independent. The source code is a treasure trove of information and more advanced programming techniques.
I think the who is using boost web page speaks for itself. Notably: Adobe, McAfee, and Real Networks probably qualify as industry.
My current company also does not allow me
to use [boost]. So I am confused whether
to look into it or not.
You might want to dig a little further and find out why. As others have said, Boost is a fantastically useful set of open source and peer reviewed libraries of extremely high quality. Look at their development LOC chart for an idea how long and how much $$ it would cost your company to reinvent the wheel.
I need a portable C++ library for doing IPC. I used fork() and SysV shared memory until now but this limits me to Linux/Unix. I found out that there are 3 major C++ libraries that offer a portable solution (including Windows and Mac OS X). I really like Boost, and would like to use it but I need processes and it seems like that this is only an experimental branch until now!? I have never heard of ACE or POCO before and thus I am stuck I do not know which one to choose. I need fork(), sleep() (usleep() would be great) and shared memory of course. Performance and documentation are also important criteria.
Thanks, for your Help!
Boost Interprocess has been around since Boost 1.35 (which should be something like 3 years ago if memory serves).
ACE has been around longer, but from the sound of things, it's probably overkill -- ACE is a big library, and you only seem to want a tiny bit of what it includes. That's not necessarily a major problem, but it is something to keep in mind. In particular, a library that's really designed for big projects can tend to seem (or be) a bit clumsy for smaller ones. ACE is also intended primarily for network development, with IPC included because (for example) you might want to build what appears to be a single server out of a number of cooperating processes, and if so you obviously need a way to build those cooperating processes.
POCO is a lot more like ACE -- it's basically a network library that happens to include some IPC capability. Again, you're looking at using a pretty small part of a much larger, more ambitious library.
Based on what you want, I'd probably use Boost -- it seems to be the closest fit for what you've said you want. POCO would probably be my second choice. Although it's separate from Boost, it seems to largely follow similar design philosophy -- in particular it's meant to integrate with the standard library, where ACE tends to be more all-encompassing.
I like to add the Apache portable runtime. It`s not really c++ but of course you can use it. The headers even has the "extern "C"" included.
Included is:
Shared Memory
Network connections
Signals
Mutexes
many other things.
The problem with boost is that it has strong requirements for the c++ compiler. Especially cross compilers have a problem with e.g. the strong template usage, so that a plain C library is "more portable".
The Loki library implements some very widely used concepts (smart pointer, visitor, factory, etc.). The associated book "Modern C++ Design" is often mentioned, but the library itself is not widely used. Why is that?
Most developers seem to prefer Boost. In particular, why do people often decide to use Boost's smart pointers rather than Loki's?
Loki is a research/proof-of-concept sort of thing. Alexandrescu pushes new ideas, other people adopt those for real world. Also boost::shared_ptr is almost literally in TR1.
Loki's suffers from being a good library touching on several functional areas (template metaprogamming support with a few specific applications: smart pointers, singletons, function objects, scope guards etc.), whereas boost is a collection of many libraries typically exhaustively covering each functional area and much more highly tuned for portability (first).
When 9 birds out of 10 can be killed with the same stone, many people just start with boost and fill in the gaps with third party libraries. It's very hard to compete with boost if you overlap. Because you won't overlap with much of boost, people will download/install boost anyway to get the other functionality, so unless you nail an area that boost is weak at - and the difference is significant to the project, they'll "settle" for boost there too.
Further, Alexandrescu made repeated attempts to get Loki included in boost, and some of the key boost authors just weren't cooperative. My personal view is that they want the more complete but much less user-friendly MPL to have more "market share": as authors of the library and the hard-copy books that are the only decent documentation (in stark contrast with most other boost libraries which have excellent online documentation), they do quite well out of this.
If anyone is offended by and disagrees with this analysis, I'm all ears.
Another practical issue with extremely parameterised code is that in large projects where different developers/teams work independently, they'll often end up using subtly different instantiations of the same template pretty arbitrarily. This makes it harder to pass values between those subsystems: the receiver may need to:
be parameterised (i.e. templated, and hence inline, which introduces compilation dependencies and slower builds in enterprise-scale systems)
provide some minimal coverage for all possible instantiations (e.g. checking error codes and expecting/handling exceptions)
working through some compile-time to run-time hand-over based on an abstract base accessor with implementations for each instantiation) which compromises some of the performance benefits of parameterisation
This is all possible, but it takes a great programmer to navigate the terrain.
You want to use a library that the next programmer is going to know and that is going to be well supported in the future - so you pick a major lib.
Because it's a major lib lots of people use it, so it becomes the default choice.
I actually prefer Loki's way of doing things and I have contributed to Loki myself a Decorator pattern which now sits in the tracker because the project as far as I know is no longer maintained.
I use boost shared_pointer just because it will be the standard very soon, I may dislike the fact that I can't customize it to act exactly the way I want it to act but I have to live with it.
Usage of the standard library is important as it keeps the code maintainable by other programmers. If it's open source and you want to experiment go ahead and use Loki. No one is stopping you.
Actually Windows Vista uses some of Loki's features.
I am guessing they are not using the redundant implementations of smart pointers and visitors.
Speaking as someone who's used quite a bit of the Boost library, and also looked at Loki more than once, the biggest problem was the sparsity of documentation. Also, Loki uses some of the hairiest bits of C++ templates. Exciting stuff, but also rather daunting.
I used Loki once for a little tool (basically an interpreter) and actually liked it. My coworkers were less enthusiastic about the library, so its use remained constrained to this small sub-project.
I've used Boost graph library a fair amount but not much of the rest of it. I frequently see recommendations here to use parts of Boost (say, Boost's various smart pointers). Obviously Boost is good and good to use. It is also large or diverse. Does anyone know of a FAQ or decent best practices doc to help a knowledgeable C++ programmer make better use of Boost?
You might find https://stackoverflow.com/questions/379290/how-to-learn-boost useful.
But in general, keep in mind that Boost is not a library, but a collection of libraries. Which means that you can and should use parts of it, but probably not all of it.
Just read over the list of libraries within Boost, and check the documentation for the specific libraries that sound useful. The Boost website is really the authoritative source, both on what Boost has to offer, and on how it should be used.
Pick out individual libraries that seem useful, and see what the Boost website has to say about them.
I learned the libraries I use by other developers suggesting certain libraries and me reading all the documentation I could find/needed to use the library.
However recently I bought this book, Beyond the C++ Standard, that introduces the most common parts of Boost. Even with reasonable boost experience I found this book really useful. It explains what the the libraries do, why they do it, how to use it and some of the techniques they use to implement it.
When some problem looks like a wheel which was invented already, firstly I look at boost's list of libraries and I trying to use that which will be appropriate for certain task. That's is my way to learn boost.
In trying to get up to speed with C++ (coming from a long experience with C), I am obviously trying to do the right thing, and use as much as is standard as is possible.
However, in my readings on the matter I come accross a lot of criticism for standard things, and praise for non-standard things. For example, even the the (I assume) poorly-thought-of MFC library has features in, for example, its CString class that some folks think useful enough to cause them to continue using it despite the fact that it's (a) non-standard and (b) that it's (I assume, from the wealth of criticism) deficient in many important ways.
My question is twofold, then:
A. What libraries that are poorly-thought-of contain features that nonetheless make it worth continuing to use them, what are those features, and what's so good about them?
B. Are there "adaptor" libraries out there that simplify and/or tighten up the use of such libraries, e.g. providing nice interfaces that abstract resources leaks, adaptors that go from a non-STL library interface to a STL, and so on
As a relative newbie to StackOverflow, I'm not 100% sure that this question is sufficiently on-point, so I apologise up-front if it's too open-ended.
Thanks in advance
My personal grunge is with ACE. It was sort of the other way around - great idea, nothing else was available at the time for cross-platform threaded and network development in C++, wide deployment, books by the library authors, etc. But the implementation was terrible, usage patterns were complicated, almost all the useful features of C++ suppressed (or didn't exist at the time.) I think this library alone is responsible for good chunk of people thinking that C++ is hard and ugly. Very recently Boost collection started catching up with threads, ipc, and networking, so there is at least an alternative. BUT with all that said, I still think it's worth to be familiar with ACE if you are in that space since, again, way too many people use it, the ideas are good, and it can serve as great negative example for library design.
IMO the best thing about MFC is that, historically, it was available before the STL was available, and something was better than nothing.
MFC is still good, if you're writing code to be compatible with an existing MFC code base.
Apart from that there's little merit in MFC, except that it's perhaps still one of the (if not the most) obvious C++ class library for Windows.
On a more general note I think one of the reasons that people stick with old, awkward and perhaps even obsolete libraries is that they have grown used to it and anything new and shiny might do the job better but are harder to grasp/understand initially. And so you stay with what is familiar and keep your productivity.
I think it is a balance between getting the job done and getting the job done "right". Somewhere in between is probably where most of us end up.
CString is non-standard because MFC is not cross-platform, I think. std::string() is standard, but if we use everything standard, then why MS developed MFC?