[std-interval] PODs and parameter passing

[Steve Clamage]

first.i.last at comcast.net wrote:

>  -------------- Original message ----------------------
> From: Steve Clamage <Stephen.Clamage at Sun.COM>
> 
...
>>In particular, a POD does not have a user-defined constructor. If the only 
>>departure from PODness is the presence of user-defined initialization or 
>>converting constructors (but still no copy constructor), a compiler can generate 
>>efficient code for copying and passing values in and out of functions. (I think 
>>we could also allow private or protected members.)
> 
> 
> Are you implying that the existence or non-existence of copy ctors is a key determinant in efficiency?  If so, what portability would be lost if the standard stated that intervals are non-PODs and implementations varied in their support for copy ctors?
> 
> You didn't mention destructors, I assume because they has less impact on the callinc convention topic.  How much efficiency is lost due to the simpl presence of a desctructor?  I'm particularly concerned with temporaries generated during expression evaluation rather than copies generated during parameter passing.

A POD has no user-defined constructors or destructor. If an object has a 
user-defined copy constructor or destructor, it affects what the compiler must 
do when passing and returning values. It's so much a question of how smart the 
compiler is, but what the language definition requires.

My point was that we can add an initialization constructor (but not a copy 
constructor) to what is otherwise a POD without affecting the efficiency of 
passing around values.

I expect an Interval type to be composed only of simple types (floating-point, 
pointer, enum, integer), and thus not need a user-defined copy constructor or 
destructor.

> Classic implementations of C's math.h always had to wrestle with speed versus correctness.  Some vendors appeased their customers by delegating the decision to them -- they provided a fast RTL and a good RTL that could be selected at link time.  As intervals become pervasive we should expect the kind of adaptive radiation that would drive vedors to offer alternative implementations.  The standard should not forbid that tradeoff without some compelling jusitification.

There is no problem with multiple library implementations co-existing and 
selectable at compile time or link time. For them to be most useful, the 
interfaces should be the same. The language standard would define only the 
interfaces, not the internals.

Example 1: Sun provides multiple versions of the basic C allocators 
malloc/calloc/realloc/free, each with different performance characteristics. 
Each of them conforms to the C (and C++) standards in that function signatures 
are identical in all versions. A programmer can select any one of the versions 
at link time, no source file editing or recompilation needed. If a programmer 
uses an extended interface offered by an allocator library, the code would not 
work with other libraries. The Standard allows extended interfaces, as long as a 
program using only the standard intefaces works correctly.  (The "as-if" rule 
again.)

Example 2:  Sun C++ comes with two different implementations of the C++ Standard 
Library: the default libCstd and the optional libstlport. The various Standard 
Library components are implemented very differently in the two libraries. Yet 
the public interfaces are identical, conforming to the C++ standard (except for 
some deficiencies in libCstd). To switch between libraries, one must recompile 
and re-link, but no source code editing is needed.

Getting back to Intervals, we should decide whether the Interval type supports a 
way (like a tag) to provide more information than just two floating-point 
values. I don't envision support for two kinds of Intervals, one with a 
tag-equivalent and one without.

As a quality of implementation (QOI) issue, the standard could allow the inquiry 
functions to return constant values, with no need to store and update the tag 
information. Different implementions with identical interfaces could offer 
tradeoffs among speed, accuracy, precision, and sharpness.

Example: The Standard requires types float, double, and long double, but says 
nothing about their representation or accuracy of computation. The only 
requirements are that arithmetic operations and sets of math functions be 
provided, and that minimum ranges are supported. All else is QOI. (Let the 
marketplace discard silly implementations instead of us trying to legislate 
against them.)

---
Steve Clamage, stephen.clamage at sun.com