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.
