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?
Related
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.
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.
I have a library written in C++/CLI and I want to open it up. I want it to be as cross-platform as possible and be able to write bindings to it for other languages to use (Java, Python, etc, etc). To do this, the library needs to be in plain C++ for maximum flexibility. I figure that the logical structures are already there, I just need to replace the .NET libraries it uses with the standard C++ ones. Is this a misguided notion? What should I watch out for when making this transition?
It might be more trouble than it's worth. Here is what you might come across:
There is no garbage collection in C++. This is the big one. This may require a significant redesign of your library just to convert. If you are using at least C++ tr1, or the boost library, you can sort of get there by using shared_ptr, but there are important fundamental differences. For example, you must be wary of circular dependencies. Also, they make debugging difficult without specific support for them in the debugger.
Functions in .Net classes which have no equivalent in C++ stl or the standard library. Probably the biggest hurtle will be any string manipulation code you have written since there are lot of differences there.
Class libraries/assemblies are not built-in to C++ - every platform has its own method of creating dynamic or shared libraries, and there isn't much support for C++ shared libraries - only C libraries in many cases. Be prepared to make everything a static library.
You must manage all your resources yourself.
Never done a port of C++/Cli to C++, but this comes to my mind:
Make sure that you dont have memory leaks. Use smart-pointers instead of gcnew, if possible (if not, make sure your code is exception safe nontheless).
Make sure your libraries interface only consists of builtin types (builtin does not include types of the STL! however this is not coercively necessary if you go open source)
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.
I want to use a library that makes heavy use of singletons, but I actually need some of the manager classes to have multiple instances. The code is open source, but changing the code myself would make updating the lib to a newer version hard.
What tricks are there, if any, to force creation of a new instance of a singleton or even the whole library?
Find out who wrote the library in the first place, visit their home address and beat them to a bloody pulp, preferrably with a book about software design. :)
Apart from that: maintain your changes to the original library as a patch set so you can (more or less) easily apply it to each new version. Also, try to get your changes into the library so you don’t have to maintain the patches yourself. ;)
Under windows you can encapsulate each instance in different DLLs.
The answer is "it depends". A good example is the C++ heap used by Microsofts C runtime. This is implemented as a singleton, of course. Now, when you statically link the CRT into multiple DLLs, you end up with multiple copies. The newer implementations have a single heap, whereas the older CRTs created one heap per library linked in.
Remember that the library also depends on the singleton nature of the singleton. If you want to update the library you need to verify that your changes don't violate library functioning. That can only be done manually each time.