[std-interval] Parameter passing

[Guillaume Melquiond]

To get out of digest mode, go to
  http://compgeom.poly.edu/mailman/listinfo/std-interval
and search "edit options" at the very bottom of the page.

Le mercredi 05 avril 2006 à 21:48 +0000, first.i.last at comcast.net a
écrit :
 
> > 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.

If an implementation follows the specification of our proposal, then the
resulting type is necessarily a POD. The interface has been specially
designed so that it happens. With respect to the scope of our proposal,
I don't see the point of adding a non-POD field to the interval class
(what would it contain?) or of saying that the copy constructor and the
destructor have side effects (what would they do?). Maybe we missed
something in writing the proposal, but at least our toy implementation
was clearly a POD.

> > As a
> > consequence, on some architectures and with non-broken compilers, they
> > will behave no differently than if the function arguments were simply
> > integers; except that the register will probably be bigger, or two
> > registers will be used. When this happens, passing by value will be
> > faster than passing by const-reference. Indeed there is no architecture
> > such that foo(int) is slower than bar(int const &).
> 
> Of course there is.  When addresses are narrow (fit in a register) and ints are 
> wide (don't fit in a register).  64-bit code on 32-bit hardware.  32-bit code on 
> 16-bit hardware.  16-bit code on 8-bit hardware.  I've even worked on a 
> bit-slice machine with 20-bit ints and 16-bit addresses.

It is not enough to consider only the part where the caller writes the
arguments. You are missing the part where the callee reads the
arguments. This requires an indirection when passing an argument by
reference. Let us consider a non-trivial example like the successor
function:

  int foo(int a)        { return a + 1; }
  int bar(int const &a) { return a + 1; }

So I state it again, slightly modified: there is no architecture such
that foo(int) is slower than bar(int const &) if the functions use the
integer argument.

> > 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;
> > 
> > This requires all the functions of the library to use the same calling
> > convention.
> 
> How do you derive this requirement?  I don't see it.

If you have two functions with different calling conventions:

  interval foo(interval, interval);
  interval bar(interval const &, interval const &);

then one of them is obviously not of the type

  interval binary_function(param_type, param_type);

Best regards,

Guillaume