Re: C++ API backwards compatibility

[Andrew Johnson <anj@aps.anl.gov>]

Chris Larrieu wrote:
> 
>   I've encountered code which purported to be compatible with
> ISO/IEC 14882, but which in fact depended upon intentionally
> undefined behavior.  Both g++ and MS VC++ quietly allow some
> questionable constructs; how do you intend to verify that the
> code adheres to the standard?

Are you asking how I will verify that I'm implementing the standard API,
or whether I'm going to ensure that user code written for my class will
build against some other implementation of the standard?

I don't claim to have implemented the complete standard list template but
I have provided what I judge to be the most useful subset for EPICS,
starting from the list template as published in the ISO standards
document.  Other member functions could be added if needed, but some can't
be implemented with all our current compilers and others won't be able to
meet the complexity requirements of the standard without internal changes
that will slow down the insert/delete operations.

My implementation also only supports epicsList<sometype*>, i.e. putting
pointers on a list (it may work with ints too, but I've not tried it).  I
would use the same approach for the other container classes as well -
making lists of non-pointer types is not conducive to fast operations, and
is only possible if the class is copy-assignable.

>   Don't get me wrong: I'm all for it.  I just want to make
> sure that everybody understands what "compatible with the
> ISO/ANSI C++ standard" means.

My aim is that code written to use epicsList<x*> can be run through the
substitution s/epicsList/std::list/g and the result should compile and run
exactly as before (maybe not 100% literally, you also need to change the
include file for instance).  The reverse substitution is not guaranteed
though.  If/when all our compiler vendors implementations become fast
enough, epicsList should be retired.

There's no way that I can ensure that user code doesn't depend upon some
undefined behaviour that I implement differently to any other version
though.  For example the standard doesn't have any defined behaviour for
calling emptyList.pop_first() or emptyList.front() - mine throws an
exception, but it is at liberty to run system("format c:") and still be
compliant!

- Andrew
-- 
Every great idea appears crazy to start with.