[std-interval] PODs and parameter passing

[Gabriel Dos Reis]

first.i.last at comcast.net writes:

[...]

| > | > 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.
| 
| Why?

because if the proposal is accepted, it is going to be part of a much
larger context.  They are some operations on can do on types depending
on whether they are PODs or not, like offsetof, initializations and
other fine details.  The standard needs to say whether such operations
are permitted or not.

[...]

| In this regard I consider things like specific requirements of
| PODness to be a kind of fine print that should be minimized. 

probably; but in the context we are talking about, you have to
specify.  You can't do without it -- and we learnt it the hard way. 

[...]

| > | > 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).
| 
| Is an abstract type for parameters vague?

In C++, there is the notion of "abstract class" but I doubt that is
what you were refering to.  One has to be more specific than general
terms; this is not a language independent specification.

| > [...]
| > 
| > | > 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
| > | > 
| 
| > | > 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?
| 
| ----- interval.h -----
|     template< T > struct Interval    { ... };
|     template< T > struct IntervalArg { ... };

That is half of it; the other half is how are they used concretely in
specifying function parameters?  That is the most interesting bits.
Please don't be afraid to be concrete, otherwise I fear we would not
communicate effectively: the issue at hand is too concrete.

| Such an abstraction would require each implementor to document the
| calling convention actually used so that interfacing with other
| languages was possible, but implementations already have to document
| all kinds of calling convention properties of which parameter
| passing is only one. 

How is IntervalArg<T> is different from IntervalArg<T>?  What do they
contain? 

| Does the interval standard need to be specific about who cleans
| arguments off of the stack?

Once we know what IntervalArg<T> and Interval<T> contain and do, we
can get to that question.

[...]

| > [ As I mentioned earlier, I'm not sure template aliases help in this
| > case. ]
| 
| I don't understand the term template alias.  Coud you describe one?

A "template alias" is an alias for a family of types

   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1489.pdf

-- Gaby