[std-interval] Parameter passing

[Gabriel Dos Reis]

first.i.last at comcast.net writes:

[...]

| > Message: 6
| > Date: Wed, 05 Apr 2006 04:51:32 -0700
| > From: Steve Clamage <Stephen.Clamage at Sun.COM>
| > Subject: Re: [std-interval] C++ interval std
| > To: For discussions concerning the C++ standardization of intervals
| > 	<std-interval at compgeom.poly.edu>
| > Message-ID: <4433AF44.8020308 at sun.com>
| > Content-Type: text/plain; charset=us-ascii; format=flowed
| > 
| > Alan Eliasen wrote:
| > > Bill Clarke wrote:
| > > 
| > >>This experiment is extremely platform specific, as you probably are
| > >>aware.  Most platforms in use today other than x86 will be the other way
| > >>around (add-by-value will be faster than add-by-const-ref).
| > > 
| > > 
| > >    How can that assertion possibly be made?  As you know, if a parameter
| > > is passed by value, then the copy constructor is automatically called
| > > for each object (e.g. twice for an add operator) on function entry, and
| > > then the destructor is called (twice) on function exit.
| > 
| > A simple object like complex or interval should have no user-defined copy 
| > constructor or destructor.
| 
| A desirable property, but unnecessarily restrictive.  In particular interval 
| objects with explicit properties might not be PODs.  

There are many PODs that do not have, nor need, a user-written copy
constructor and destructor.  If the mental model of interval is that
it is just a couple of floating point numbers, then Steve is
exactly right.  Are you operating under the assumption that an
interval is NOT essentially a couple of numbers?  If yes, please be
more specific.

[...]

| > Please note that our proposed interval type is meant to be a POD (plain
| > old data) type and as such has no copy constructor nor destructor.
| 
| Is it your plan that the proposal include the POD-only requirement?  I would 
| suggest that it is an obvious possibility that yeilds good performence 
| improvements, but how important is it to get fat intervals quickly?
| 
| I would must prefer not to see such a requirement in the standard.

The proposal would need to be precise about whether internal<T> is a
POD or not; that is unavoidable.

[...]

| > Message: 3
| > Date: Wed, 05 Apr 2006 05:49:41 -0700
| > From: Lawrence.Crowl at Sun.com
| > Subject: Re: [std-interval] Re: C++ interval std
| > To: For discussions concerning the C++ standardization of intervals
| > 	<std-interval at compgeom.poly.edu>
| > Message-ID: <200604051249.k35Cnfbd008613 at philmont.sfbay.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.
| 
| The issue is the atomicity of the type.  Atomicity often implies effective 
| opacity.  Opacity always implies atomicity.

Yet, at the end of the day the proposal needs to spell out the
mechanism for passing the representation.  At the moment, I don't see
how the committee would buy a proposal that is very vague about such
issue.  Past experience with vagueness in that area has been a fertile
source of programmer confusion, and defect reports (that the committee
had to deal with).

[...]

| > Message: 7
| > Date: 05 Apr 2006 15:37:20 +0200
| > From: Gabriel Dos Reis <gdr at integrable-solutions.net>
| > Subject: Re: [std-interval] passing by value vs reference
| > To: For discussions concerning the C++ standardization of intervals
| > 	<std-interval at compgeom.poly.edu>
| > Message-ID: <m3d5fwcfe7.fsf at uniton.integrable-solutions.net>
| > Content-Type: text/plain; charset=iso-8859-1
| > 
| > Guillaume Melquiond <guillaume.melquiond at ens-lyon.fr> writes:
| > 
| > | Le mercredi 05 avril 2006 à 11:32 +0200, Sylvain Pion a écrit :
| > | 
| > | > 3- leave freedom for the implementation to choose
| > | > 4- leave freedom for the implementation and have it provide
| > | >     a standard specified way to obtain this information.
| > | 
| > | > I would prefer 3 to 4.  I think
| > | > the complexity of implementing 4 is not worth it.
| > | 
| > | I don't see any additional complexity in 4 with respect to 3. As already
| > | mentioned by Bill Clarke, you could simply have a typedef member in
| > | interval<T> to express the calling convention of the functions of the
| > | interval library: typedef interval<T> const &param_type;
| > 
| > If done that way, in the typical cases, the "T" would then appear in
| > non-deducible context. 
| 
| It need not be a dependent type.  It could easily by a parallel set of 
| templates.

More specifically?


[ As I mentioned earlier, I'm not sure template aliases help in this
case. ]

-- Gaby