[std-interval] Re: C++ interval std

[Lawrence.Crowl at Sun.com]

first.i.last at comcast.net writes:
 >> Lawrence feels strongly that the standard should be to pass by
 >> value.  Intervals are small data structures;
 >
 >That perspective causes problems, just as it did for complex.
 >Intervals should be considered atomic types whose internal structure
 >is opaque.  We don't consider fp types as structures even though they
 >consist of three distinct fields (and in fact are t reated as separate
 >fields in software implementations of the run-time library).

The issue was the mechanism for passing the representation, not the
logical opacity of the type.

 >> by value allows them
 >> to be passed in registers for speed.  That is how the current Sun
 >> C++ compiler works.  There is no reason to follow the C++ complex
 >> standard.  The library is often taken as an example by coders, and
 >> there is no good reason to follow the tradition of C from 20 years
 >> ago that structures should be passed by reference.
 >
 >There may or may not be a good reason for it.  On FPUs with weak
 >connections to the CPU, such as x87, passing by value is strongly
 >preferred.  Yet on FPUs with strong connections to the main CPU
 >passing by reference might be much more efficient.

I don't follow the reasoning here.

 >If the standard syntax is pass by value then a compiler that prefered
 >pass by reference would be free to do so internally (assuming
 >appropriate referential safe guards).

SPARC V7 (32-bit) does in fact do this.  SPARC V9 (64-bit) does so
for large structs, but passes in registers for small structs.

 >> Uninitialized.  The convention in C/C++ is to initialize to zero,
 >
 >Not quite.  The default initialization convention in C depends on the
 >lifetime of the object.  Dynamic objects (typically stack and heap)
 >are not initialized at all by default.  Static objects are initialized
 >to zero, but that is not a special property of numerics.  All static
 >objects lacking an initialization expression get a default expression
 >of zero.

Correct.

 >> The current C++ standard does not discuss or acknowledge threads.
 >> They are working on the next revision of the standard, which will
 >> have something to say about threads in the language proper and in
 >> the standard library.  Probably the interval standard should say,
 >> "Intervals will be implemented in a thread-safe manner."
 >
 >That is a tall order.  Intervals should be thread safe when the
 >underlying language is thread-safe.  Consider errno and matherr() for
 >intervals.

More specifically, two threads should be able to operate on their
disjoint data without worry of interference.  Shared variables may need
synchronization.

 >Some compilers give the programmer little control over parameter
 >passing.  Others give a great deal of control, including offering both
 >stack and register passing for atomic types, putting small structs in
 >registers, and even hybrids with part in registers and part on the
 >stack.

Yes, though the controls are of dubious value.

 >This matters because the implementor _must_ have the freedom to
 >optimize parameter passing.  So the standard should be as quiet as
 >possible on the issue.  The _syntax_ should be by-value because that
 >imposes the least (i.e., no actual) constraints.  But the code
 >generated could be either at the discretion of the implementor.

Agreed.

 >The best approach is probably a second set of types that are
 >specifically used for argument passing.  Portable code often uses this
 >approach.  It allows an implementor to alter the parameter passing
 >convention on a platform-by-platform basis.  So non-inline interval
 >functions would take arguments of type IntervalArg<double> from which
 >the function could obtain the actual argument.

As Steve Clamage pointed out, you have interference when function
pointers are involved if you delay the parameter types.

 >> Pass-by-value is also a correctness issue.
 >
 >How so?

Because users will copy the style of interval function declarations.
If that style includes reference paramters, the programmers will litter
their programs with unintended aliases.  These aliases are the source
of bugs.

 >> Note that on modern systems, initialization to [0,0] is more efficient.
 >
 >Please state the reasoning behind the above statement.

Variables of static extent (globals, function-local static, static member)
can be allocated in a "fill with zeros" section if and only if their
initial representation consists of all zero.  This implies a [0,0] interval
with modern floating-point representations.  The same issue arises with
dynamically allocated code, though only on systems that first ensure
that they clear the memory.

 >> The meaning of long double is implementation-dependent.  On Solaris
 >> SPARC, it is 128 bits.  On Solaris x86, it is 80 bits.
 >
 >And some compilers accept the syntax of long double but don't
 >implement it (long double becomes a synonym for double).

This behavior falls under "quality of implementation". :-)

  Lawrence Crowl             650-786-6146   Sun Microsystems, Inc.
                   Lawrence.Crowl at Sun.com   16 Network Circle, UMPK16-303
           http://www.Crowl.org/Lawrence/   Menlo Park, California, 94025