Comments on adding Boost dependency

[Michael J Iatauro]

Users and devs! I'm thinking of starting to include Boost libraries in Europa, but I
wanted to get the community's opinion on it first, since there's a deep love/hate among
C++ programmers.

The motivating factor here is the myriad names and locations that hash tables have been
given across compilers and versions*. It would be nice to be able to use Boost's
unordered_map to make the code simple without losing support for older compilers. Of
course, once there's one Boost dependency, it'd be nice to add others. I would try to
avoid any of the really big transitive dependencies, like Boost.MPL.

So, what are your thoughts?

~MJI

*At least three names/locations for various versions of GCC (not including tr1), at least
two for MSVC++, at least one for clang++, and no guarantee that any particular tr1
implementation includes them.


--
------------------
Michael J. Iatauro
Software Engineer
QTS, Inc.

NASA Ames Research Center
Office: 650-604-0662
Mail stop: 269-2
P.O. Box 1
Moffett Field, CA 94035-0001

[Simon Spero]

Specific issue of unordered_map: 

----

The C++11 standard include for unordered_map is:

#include<unordered_map> 

The template name is

std::unordered_map  

This works for the LLVM libc++  ( http://libcxx.llvm.org/ )

This works for GNU libstdc++ from at least version 4.4 forwards, but was not supported in 4.2.1.  I do not have 4.3 installed on my machine.  

Microsoft Visual C++ 2010 and later support this name.  

-----

The legacy TR1 namespace: 

For at least gcc 4.2 through gcc 4.8, if you use the include statement

#include<tr1/unordered_map>

The template name is 

std::tr1::unordered_map

The LLVM  libc++ implementation does not include the TR1 namespace (since it is post- C++11).  

Microsoft Visual C++ 2008 supports this namespace.

----

You use autoconf or the like  to check to see if the tr1 namespace is required, 

and select the include name and "using std::unordered_map" or "using std::tr1::unordered_map" as required. 

If the compiler libraries are too old to include either version, then the configure script  system can check for boost availability.  

You can use the configuration process  to check for which flags are required to enable c++-11 features (e.g. g++-4.[45] requires -std=c++0x ; later versions allow -std=c++11

----

As for the general question of whether to introduce boost dependencies,  I would suggest using them if they make sense (e.g. if BGL/ parallel BGL would be useful, it's silly to avoid them).  

As for MPL - you might want to consider whether porting Europa to Common Lisp might be a viable solution :-) 

Simon

--
You received this message because you are subscribed to the Google Groups "europa-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to europa-users+unsubscribe@googlegroups.com.
To post to this group, send email to europa...@googlegroups.com.
Visit this group at http://groups.google.com/group/europa-users.
For more options, visit https://groups.google.com/d/optout.

[Michael J Iatauro]

Thanks for your input on this, Simon! Unfortunately, the problem isn't only where
unordered_map is, it's also what it's called. Some older and weirder versions of GCC have
it as hash_map, and those compilers definitely won't have support for templated type
aliases like a good C++11 compiler will. I'd like to still maintain the fantasy that
Europa could run in a flight-like environment, so I'd like to keep as broad a base of
compiler support as possible.

My other goal here is to shift the blame... er... responsibility for platform-specific
issues outside the Europa codebase. I don't have a lot of resources at my disposal to
support it, so every point of configuration is one I'd like to avoid or eliminate. This
is why I'm starting to move the build to CMake. If I can get our two- or three-system
build system down to one, it'll be fabulous. If I can completely get rid of map-related
configuration and conditional compilation by depending on Boost unordered_map, almost as
good. While positive, neither of those things is worth the cost of users, which is why
I'm asking around.

> As for the general question of whether to introduce boost dependencies, I would suggest
> using them if they make sense (e.g. if BGL/ parallel BGL would be useful, it's silly to
> avoid them).

I'm definitely interested in using BGL. The STN and max-flow resource computations in
particular both have their own graph implementations that it would be nice to move to
something standard (and possibly faster) like that, especially if it can reduce our SLOC.
That's a fair-sized chunk of work.

> As for MPL - you might want to consider whether porting Europa to Common Lisp might be a
> viable solution :-)

Funny you should mention that. Back when Europa was called RAX, it was in Common Lisp!
(Due to a problem with C++ compiler support. The circle of software life.) I would like
to avoid MPL mostly due to the compilation overhead, but a lot of Boost libraries depend
on it, so I won't promise not to end up depending on it unless it's going to cause much
user consternation. I rather enjoy type-level programming, but it's very slow to compile
when you do it in C++.

~MJI

[Frédéric Py]

Indeed unordered_map is part of c++11 but the integration of c++11 is just getting started and older compiler do not have it obviously. That being said hash_map is not unordered_map but the remnant of SGI STL which was the implementation of C++ STL that gcc picked and they did a bad job on putting aside the non standard stuff and things started to get very messy staring around gcc 3.2 where they finally decided to be standard compliant.

For boost integration anybody that gave a look at trex code will know my answer: yes of course.

boost is a library with an excellent support and perenity : they tend to support most of their component for a very long time as their goal is to integrate them in the next c++ standard and even the deprecated ones are clearly stated and kept long enough for the developper o adapt to the alternate choice they have.

It also is a good compromise between moving to c++11 and support of older compiler s many of the boost libraries made their way through c++11 and they also provide boost.tr1 to abstract out where your unordered_map (or thread, or chrono) implementation is from boost or already supported by your compiler. 

Finally for the overhead of compilation related to some stuff (as boost is very template heavy). I personally do not mind having this overhead during compilation and cross-compilation is the solution for slow compiler. Additionally for things such as the use of BGL for STNs or resource. This overhead is easily reduced by the private implementation design pattern where the use of BGL (or MPL,…) is isolated in the cpp source code while the head just present the interface to the class. This isolate the overhead to the dole compilation of the libraries while extension will compile as fast as ever.

One main critique of boost though would be its documentation which make a lot of assumption on users initial knowledge of the concept approached, There’s also some libraries in boost which are not supported anymore (such as interval which, if it was supported would be ideal to implement constraint in interval domains in europa). These are few but checking regularly the changelings of boost new version is a good habit to identify and avoid these outliers.

As a matter a fact my habits and recommendation on using boost are as follow:

  - if the boost library made it through c+11 refer to the documentation of c++11 instead o avoid non-standard boost extension (for example the doc of unordered_map can be found here http://www.cplusplus.com/reference/unordered_map/unordered_map/  you just need to replace std:: by boost:: and it should work the same way.

 - always make sure that the boost library is updated regularly by looking at the changeling on 2 to 3  last releases

 - stick to the doc of one boost version (for trex for example I use 1.47 as my doc reference but you may want to take a more recent one to have the benefits fo new additions) while compiling against more recent versions ( I do dcompile my code against 1.55)

 

regards

—

Frederic Py

-- 
You received this message because you are subscribed to the Google Groups "europa-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to europa-users...@googlegroups.com.

[Simon Spero]

On Tue, Jul 15, 2014 at 6:41 PM, Frédéric Py <fre...@gmail.com> wrote:

Indeed unordered_map is part of c++11 but the integration of c++11 is just getting started and older compiler do not have it obviously. That being said hash_map is not unordered_map but the remnant of SGI STL which was the implementation of C++ STL that gcc picked and they did a bad job on putting aside the non standard stuff and things started to get very messy staring around gcc 3.2 where they finally decided to be standard compliant.

Right - I was writing something to that effect (also noting that hash_map has a few differences to unordered_map).   <unordered_map> (=> std::unordered_map appears  in gcc 4.3.  VxWorks gcc is at 4.8 (though diab remains at c++03).  

There's  CMake code for finding std::tr1::unordered_map or std::unordered_map if they're present:

https://ceres-solver.googlesource.com/ceres-solver/+/master/CMakeLists.txt  (around line 431). 

If  a cmake  boost package finder is run before the  then it ought to pick up tr1 from boost (which would fall through to the system tr1 if present).  

Simon