Does anyone know of any libraries that can be used in place of Boost::Function and Boost::Bind? We are trying to remove our dependency on Boost since it's a pretty large library. We're looking for something more focused.
I found this:
http://www.codeproject.com/KB/cpp/fastdelegate2.aspx
I've never used it though and it looks like it was last updated in 2007. Has anyone used it?
We use callbacks are fair amount throughout our code and boost::function and boost::bind allow us to do so. But we've run into problems turning RTTI and exceptions off using Boost. So any replacements would need to be usable with RTTI and exceptions turned off.
Thanks!
The implementation that you pointed to is built upon undefined behavior according to the standards. Disabling exceptions should be no problem with Boost.Function, as long as you define your own throw_exception function. And I'm sure disabling RTTI won't be a problem either, since Boost.Function goes through great trouble to avoid virtual functions at all (its all explained in its rationale). There are problems with disabling exceptions and RTTI for some Boost libraries, but Function and Bind are not the case, I have been using them in Android NDK with disabled exceptions and RTTI for a long while.
As for alternatives, you could always use the now standard C++11 ones (based on Boost) which are already available in several compilers; or you could always roll your own. There is also an alternative implementation of Boost.Function by Domagoj Saric, but I cannot seem to find pointers to it right now.
Check out Boost bcp tool, to extract only the files related to Function and Bind, and roll on your own version of them. You shouldn't need to change anything for them to work.
I've had good results using the sigslot library. This is an extremely lightweight library, it consists of just a single header file. It plays nice with STL and has optional multithreading support for Windows threads and pthreads.
There is a bcp tool which allows you to copy the part of boost library that you need.
There is no need to find alternatives for boost. This is a great library. If any library exists there it is the best in the world. Probably there are some exceptions like boost.test, but in generally it's true. Particularly it's true for boost.function and for boost.bind.
Related
I am new user of the boost library. I find my self thinking more about adopting boost for a number of reasons. From what I can tell, it seems that the boost library is a sort of skunkworks sandbox where various C++ TR features for upcoming standardization are tried out before being adopted by the C++ committee - think boost::filesystem and boost::regex,
As an example, I was trying out some of the C++11 regex features in visual studio via the #include header - this worked great until I ported to a target power pc platform, which, at the time used CodeSourcery's GCC 4.7.3. Unfortunately, I realized that at run-time, that much of the regex implementation was incomplete or empty (even thought it compiled) - With a bit of homework, I should have realized this beforehand, however now that GCC 4.8.x is out, the implementation is part of the v3 standard C++ library so it is a different story now.
In an ideal world, the standard library should be like developing for Java - write once, deploy everywhere - but that is not a reality. I would eventually like to move to the standard library implementation rather than Boost's regex and filesystem implementations.
My question given the above regex history, is how should developers use boost, is it possible to do a simple search and replace of the boost headers and namespaces when the features are adopted by the standard library or are there more many things to consider. I would like to use pure C++11 code without dependency on 3rd party libraries.
The amount of work required to move from a Boost library to its C++11 conterpart depends on the degree of C++11 conformance of a particular Boost library. In the simplest case it can be a matter of including another set of headers and using another namespace.
In a more complicated case, Boost library may have some subtle incompliancy with C++11 (eg. in Boost.Thread V1 ~thread used to call detach()) - such things might "silently" break the code correctness, but they are easy to fix.
Finally, Boost library may implement funcionality that doesn't exist in C++11 (eg. boost::bind can be extended using get_pointer function). Apparantly, porting such a code to C++11 would be quite not trivial.
Let's begin with your statement
I would like to use pure C++11 code without dependency on 3rd party
libraries.
It is clear that this is not possible now. You will have to use 3rd party libraries for any non-trivial program.
Unfortunately, C++ with Boost is not a platform also. You need 3rd party libraries to do things available out of the box in languages like Java, C#, Python etc.
So, you have to select libraries according to your requirements: performance, supported platforms, multithreading etc.
Again, Boost shouldn't be your default choice. It is not that useful now as it was 10 years ago. Most of must have stuff went into C++ standard library already.
If you support existing C++ codebase, find the best C++ library for your needs (e.g. re2 for regex). If you start a new project, I would suggest using Qt as a platform.
A "simple" way to migrate usage may be to use preprocessor defines to define a "Using Boost" directive. By putting all boost code in an #if-#else and carefully writing the code to not break (or at least have expected results) for sections that do not have a C++11 equivalent. You can simply not provide a definition for "Using Boost" before at the beginning of your code and C++11 features would be used instead.
See this and this
One link points to an old stackoverflow question, the other to an interesting talk performed by Stephan Lavavej
I have being using stlport to develop wince based custom OS, but from now on I am thinking about using stl provided by windows. I read that functionally they are not different from each other so currently what matters is my image's size. Unfortunately I cannot give both of them a try like first use stl and make a run time image and then use stlport, then compare both images' sizes, because I have a lot of other problems that I need to solve in order to succesfully build the OS. Hence I wanted to get an expert idea:
Which one do you think would be more lightweight? I know how stlport is attached, loaded etc but I am not quite sure about STL. I looked into STL headers and all I saw were thousands of inline functions. But is that all? I need to be sure about it. Does STL link any other libraries inside or does it simply include the headers and use those inline functions?
Best
Ps: I am using VS2012 and working on wec2013
Ps2: I know what STL and stlport stands for and how to build an application by using them. My actual question is which one would consume less memory, use smaller size on HDD? (Considering things like stlport is a lib but stl is not etc.)
I assume that by STL you mean your compiler's standard library. This is a common misunderstanding, as STL was the original name of a library that was proposed and accepted into the language, but it has evolved from that. Taking this into account, the question becomes:
Should I use the standard library provided with my compiler or use stlport [or other alternatives]?
The answer is that it will depend on your use case, but the good thing is that as long as you use the library as defined in the standard (i.e. without extensions) then you should be able to easily switch from building with one or the other, and that means that you can test this yourself. You can also test building with different compiler flags. This is specially important in VS, as by default the library uses checked iterators, that are good for debugging but at the cost of extra memory and processing.
STLPort is designed to be used on platforms that does not provide STL for some reasons (for example, embedded platforms without C++ exceptions support), or native STL support is outdated.
So, usually you do not need to replace native STL. There should be strong reasons to use STLPort in your project. In my experience, I used it for some embedded DSP platforms (no native STL), and for a UEFI platform (not really embedded, but no native STL as well, also runtime does not support C++ exceptions).
STLPort is highly customizable (you can disable exceptions, streams, etc), and can be used on almost any platform with basic C++ support.
I'm working on a big project for embedded systems.
The project is a library and some binaries that must be integrated into customer's code/solution.
So, it must be as much OS/Platform independent as possible.
We've been working on embedded linux so far without problems. However it is possible that non linux based platforms join the fun in the near future.
To ilustrate the kind of platform we are working with, they must be capable of running demanding modules such as a Java Virtual Machine.
I'm not sure which kind of platform may show up and what kind of compilers they may offer.
So I'm a little worried about using advanced C++ futures or libraries that may cause a lot of trouble. Mainly I want to avoid the possibility of incompatibility due to that.
We are refactoring a few C++ modules of our solution. They are really tricky and smart pointers support would help a lot.
At first, I thought about making a custom smart pointer package, but it seems a little risk to me (bugs here would cause a huge headache).
So I thought about using boost's smart pointers.
Do you guys think I'm going to have trouble in the future if I use the boost's smart pointers?
I tried to extract the boost's smart pointer package using bcp, however a lot of other things come along with that. something like 4Mb of code.
The extracted directories are:
config/compiler
config/stdlib
config/platform
config/abi
config/no_tr1
detail
smart_ptr
mpl (and subdirs)
preprocessor (and subdirs)
exception (and subdirs)
type_traits (and dubdirs)
That doesn't seem very portable to me (but I may be wrong about it).
What do you guys think about it?
Thanks very much for your help.
Newer compilers include shared_ptr as C++11/TR1. If you have a reasonably modern compiler- which you really want to have, because of C++11- then it should not be problematic.
If you do not right now have a customer who cannot use TR1, then rock on with it. You can deal with future customers when they arrive- YAGNI applies here, and smart pointers are very important. As are C++11 features like move semantics.
However, if you were desperate, you could roll your own shared_ptr- the concept is not particularly complex.
Don't hesitate with using smart pointers. The smart pointer package you extracted should be portable to all decent compilers.
If it won't work with your compiler, you can replace conflicting parts of code manually. Boost code is more complicated, because it contains workarounds for various compiler bugs or missing functionalities. That's one of the reasons, why Boost.Preprocessor or Boost.Typetraits were added.
Boost is very portable; the source code size of the library is no indication of target image size; much of the library code will remain unused and will not be included in the target image.
Moreover, most common (and not so common and obsolete) 32bit platforms are supported by a "bare-metal" ports of GCC. However while GCC is portable without an OS, GNU libc targets POSIX compliant OS, so bare-metal and non-POSIX dependent ports usually use alternative libraries such as uClib or Newlib. On top of these GNU stdlibc++ will run happily and also many Boost libraries. Parts of Boost such as threads will need porting for unsupported targets, purely data structure related features such as smart pointers will have no target environment dependencies.
My company are currently not won over by the Boost libraries and while I've used them and have been getting them pushed through for some work, some projects due to their nature will not be allowed to use Boost. Basically libraries, like Boost, cannot be brought in for work so I am limited to the libraries available by default (Currently using Visual Studio 2005).
So... My question is, if I am unable to use Boost::shared_ptr and its little brothers, what is the alternative when using STL containers with pointers?
One option I see is writing a container class like a shared_ptr that looks after a given pointer, but I'd like to know if there are other alternatives first.
If they're not going to accept boost, I presume other "not developed here" libraries are out of the question.
It seems to me you're left with two options:
Roll your own shared_ptr.
Use raw pointers, and manage the memory yourself.
Neither is ideal, and each comes with it's own pain. Your saving grace might be that you have all of the source to boost available to you. You can use it as a model for writing your own shared_ptr.
In Visual Studio 2008 there is available std::tr1::shared_ptr. I'm not sure it is available in VS2005, you should check.
That definetly depends on what you want to do. It's not as if shared_ptr are absolutely necessary for a project that uses pointers.
If you really need them, import those classes/templates/functions you really need to your own project if possible without importing the whole boost lib.
Without knowing the background, it's hard to say why boost's libraries aren't permitted. If the reason is to avoid complex dependencies, you can easily work around the issue: Almost all boost libraries work with only a simply #include header: in short, they don't need linking and thus avoid dll-hell or any variant thereof.
So, if external libraries aren't appreciated because of the complexities involved in linking (whether statically or dynamically) them, you can simply copy the boost headers you need into the project by hand and use them directly.
For clarity and to make future upgrades and maintenance easier I'd avoid renaming the boost libraries (so future coders know where the code came from). If "they" don't want such simple code inclusions, well, you could make the argument that quite a few boost headers are headed for inclusion in the spec, and that they'll save everyone a bunch of headaches and time. Legally, the boost license is specifically designed to be as easy and safe to integrate as possible: all files have an explicit license which permits all relevant things, and almost all libs have exactly the same license.
I'm curious though: why exactly aren't boost headers permitted?
The spate of questions regarding BOOST_FOREACH prompts me to ask users of the Boost library what (if anything) they are doing to prepare their code for portability to the proposed new C++ standard (aka C++0x). For example, do you write code like this if you use shared_ptr:
#ifdef CPPOX
#include <memory>
#else
#include "boost/shared_ptr.hpp"
#endif
There is also the namespace issue - in the future, shared_ptr will be part of the std, namespace - how do you deal with that?
I'm interested in these questions because I've decided to bite the bullet and start learning boost seriously, and I'd like to use best practices in my code.
Not exactly a flood of answers - does this mean it's a non-issue? Anyway, thanks to those that replied; I'm accepting jalfs answer because I like being advised to do nothing!
The simple answer is "do nothing". Boost is not going to remove the libraries that got adopted into 0x. So boost::shared_ptr will still exist. So you don't need to do anything to maintain portability.
Of course, once 0x is here, a lot of code can be simplified, cleaned up and optimized, but since it's not yet here, that work can't really begin. All you can do is make sure your code will still compile when 0x hits... and it should, just like that. Boost isn't going to delete half their libraries. (I'm not guessing. They've stated this on their mailing list before)
(and if you want to switch to the standard shared_ptr, I'd say it's probably easier to just do a simple search/replace when the time comes. Replace #include <boost/shared_ptr.hpp> with #include <memory>, and boost::shared_ptr with std::shared_ptr)
Or of course, you can just decide on the project that you're going to keep using Boost's shared_ptr. Just because it's been added to the standard library doesn't mean you have to use it, after all.
Nothing will need to be done because of namespaces. If you want to use the boost implementation you will still use the boost namesapce.
I don't think they would venture into breaking compatibility in such a big way with a previous version.
See my previous similar question here: what will happen with the overlapping portion of boost once C++0x becomes mainstream?
But of course if you do using namespace a lot in your code you may have some overlapping definitions. You'll have to go back to specifying the namespace explicitly on each use.
The best way to use shared parts between C++0x and Boost is to use the Boost.TR1, i.e; the implementation if the Technical Report already accepted. Boost.TR1 will use the implementation provided by the compiler when it is available, and the provided by Boost otherwise. This was the main goal of Boost.TR1
"The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. "
No we don't, as of yet, given the facts that:
support for C++0x is not yet upto the mark across the various platforms (we need) and
that it is yet to be declared a standard officially
But yes, we do use Boost as and when required (but of course, only after a release has gone through a sanitation phase do we use it) just like any other third party library that we use. Also, we use the source form on a as-needed basis.
There is however an effort towards more stringent adoption of the driving principles in product design phase (e.g. move-ctor etc).
There is definitely going to be some work when C++0x gets standardised; but that will also require us to move on to some of newer compilers (vc10?) and moving on to a new compiler is always a task in it's own.
You may actually always prefer using the Boost version for a long time. Especially if you need to compile on multiple platforms.
The Boost libraries are ported and tested on multiple platforms and behave the same there (most of the time.)
The first vendor implementations of the new C++ libraries may still contain minor bugs and performance differences just like it was such a mess when STL and the std namespace were added.