Re: using C++ STL containers in GCC/gfortran source code

["N.M. Maclaren" <nmm1 at cam dot ac dot uk>]

On Dec 16 2016, Janus Weil wrote:
> What I'd like to know is: In the current state of things in GCC, is it
> possible/reasonable to use any of the STL containers (like
> std::vector, std::string, whatever) in GCC and its front ends (in
> particular gfortran)?
>
> That question has two parts:
> 1) Is it technically possible at all? Are there drawbacks/pitfalls?
> (In particular Jakub mentioned possible memory management issues, i.e.
> xmalloc vs malloc etc.)

I can say something about this, which is not gcc-specific.  The executive
summary is that there shouldn't be any problem if you KISS, but heaven
help you if you don't.

Not all containers etc. are equally problematic and, as expected, the
problem increase rapidly with complexity and how 'advanced' your code is.
For example, the interaction between sorting on a vector, allocation and
copying is, er, 'interesting' (and essentially unspecified).

There are a lot of restrictions and oddities to do with iterators and
any action that changes the container, which could cause trouble if
anyone working on the code isn't fully au fait with them.

The standard library is hopelessly ill-defined and ambiguous with regard
to parallel use of a single container so, if gcc wants to allow that, it
must be VERY conservative.  A strict reading of the standard says that
this applies to any two containers derived from the same base class, but
that is almost certainly safe.

The de facto library specification keeps changing, not always in fully
compatible ways.  For example, are containers allowed to count element
accesses?  They used to be, that's for sure, but it's now doubtful - see
the previous paragraph for why.

In my experience, it is often easier (and sometimes less code) to write
your own container if you are pushing the boundaries.  I doubt that gcc
will need n-D arrays, but that's an extreme example (and Boost is no
better).


Regards,
Nick Maclaren.