2

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.

Marcus
  • 1,675
  • 3
  • 18
  • 29
  • 1
    Do you have an idea about the target system(s) where your application will be deployed? If not, you need to get an idea asap. Then, check out the available compiler(s) on each such platform. Check out if Boost (or part thereof) is supported on such a platform. Take the lowest common denominator. Unfortunately, without specifics, the question is a bit vague to address with any degree of certainty. – dirkgently Jun 26 '12 at 14:57
  • `std::shared_ptr` has been part of C++ since the tr1 in 2005, so it should be fairly ubiquitous. Boost `intrusive_ptr` might be less heavy. – jxh Jun 26 '12 at 15:08
  • What is your embedded platform? – qehgt Jun 26 '12 at 15:45
  • I've already worked with ST SH4 platform (Linux), ARM (custom chip from client), MIPS (custom chip from client). It is not possible to know what new platforms it may be deployed. New clients may decide to work with us and the details about their platforms is not available publically (actually, it is very strategic for them). – Marcus Jun 26 '12 at 16:19
  • I heard a lot about TR1. But I'm not aware whether it is well adopted among embedded platforms. Should I consider that a common denominator? – Marcus Jun 26 '12 at 16:21
  • If you are working with custom chips, then the client should also be providing a toolchain. Are the toolchains generally based on GNU, or something else (e.g., Green Hills Software)? – jxh Jun 26 '12 at 19:48
  • Like I said a few messages above, the problem is not the current customers. The problems lies on possible new customers that I have no idea how their toolchain looks like. And there is no way to know about it ub advance. – Marcus Jul 02 '12 at 13:47

3 Answers3

1

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.

Rafał Rawicki
  • 22,324
  • 5
  • 59
  • 79
  • 1
    Also, did you see: http://stackoverflow.com/questions/7792011/alternative-to-boostshared-ptr-in-an-embedded-environment – Rafał Rawicki Jun 26 '12 at 15:33
  • Thanks for your answer. I've seen this post a while ago. It was one of my starting points for possible custom implementations. You mean I should use boost extracted smart pointers or not? Your first sentence encorages me of using it, but the rest of it sound like a "don't do it". Or you are saying that I should use TR1 available smart pointers? Thanks agian. – Marcus Jun 26 '12 at 16:24
  • I mean you should use an extracted boost smart_ptr. What I meant in the second sentence is - Boost is big, because it support more possible use cases, including working around compiler bugs. However, that doesn't guarantee, that it will work on your compiler and it is possible, that you will have to replace some parts of the code. – Rafał Rawicki Jun 27 '12 at 15:20
  • What compiler are you using? For ARM and MIPS, there is GCC available and this is good compiler, well tested with Boost. If you use some exotic compiler it's hard to guess about its own problems. – Rafał Rawicki Jun 27 '12 at 15:21
  • For now I'm using GCC for SH4, MIPS, ARM. The point is: It is possible that we get new customers. So we would have to port our solution to their platform. New customers may use other compilers and it is not possible to predict the future. I think I'm going to use TR1 smart pointers... I know it may cause trouble in the future, but it seems to be safer to me than using boost. What do you think? Thanks for your help, once again. – Marcus Jun 27 '12 at 16:56
  • I think, that both TR1 and Boost will be equally good - what matters is that both of them are used by many users and well tested. I don't know if the TR1 implementation doesn't have any compiler specific or C++11 features used. If so, you will be forced to patch this anyway. Otherwise, it is easier to use than Boost. – Rafał Rawicki Jun 27 '12 at 21:55
  • 2
    [This article](http://www.codesynthesis.com/~boris/blog/2010/05/24/smart-pointers-in-boost-tr1-cxx-x0/) comparing TR1, Boost and C++x11 smart pointer implementations may be useful. – Clifford Jun 28 '12 at 05:05
  • Thanks guys. Seems like TR1 is the solution for me. I'll stick with that. Thanks very much again. – Marcus Jun 28 '12 at 20:45
  • 1
    Clifford, great article. Thanks very much for that. – Marcus Jul 02 '12 at 16:46
1

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.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • The problem for me is expressions like "most common", "generally". The solution code is very big... If I need to remove boost for some reason, it would cause me a lot of trouble and testing. I'm going to stick with TR1 for now. Thanks very much for your answer. – Marcus Jul 02 '12 at 13:50
  • My point was that GCC is more broadly cross-platform that any other compiler. Many proprietary compilers even support GCC extensions for compatibility with it. However as a subset of both Boost and C++x11 (albeit in a different namespace), TR1 is probably the safest bet. – Clifford Jul 03 '12 at 19:46
1

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.

Puppy
  • 144,682
  • 38
  • 256
  • 465