[std-interval] PODs and parameter passing

[Steve Clamage]

first.i.last at comcast.net wrote:
>  -------------- Original message ----------------------
> From: Gabriel Dos Reis <gdr at integrable-solutions.net>
> 
>>first.i.last at comcast.net writes:
>>
>>[...]
>>| OK, I did not ask a sufficiently precise question.  Why is
>>| "implementation defined" unacceptable?  I.e., why does PODness have
>>| to be a constant for all implementations? 
>>
>>Because whether the operations in question are permitted or not would
>>depend on the compiler; I don't see any compelling reason for that
>>sort of non-portability.
> 
> It is only non-portable if it is not detectable at compile time.

Scenario: A programmer develops on one platform, unaware that the code depends 
on a feature that varies among implementations. A colleague tries the code on a 
different platform, and it doesn't compile. The code requires a significant 
re-write to accomodate the differences.

Don't you agree this is a portability issue?

I'm a compiler developer. I find that the majority of customer questions and 
complaints are of the form, "My code works with compiler X, why doesn't it work 
with your compiler?"  Often the answer is that the code is not portable, in the 
sense of the scenario above.

Every time the standard says "undefined", "unspecified", or "implementation 
defined", it opens the door to problems like these. We need a compelling reason 
to leave issues like POD-ness and function signatures up to individual 
implementations.

[...]
>>
>>It all depends on the degree of non-PODness; there are ABIs out there
>>on popular platforms that make optimization decisions based on degree
>>of PODness.

Gaby, PODness is binary. If a type does not satisfy all the requirements of a 
POD, it is not a POD.

 > Let's see if we can mutate a classic into something useful:
 >
 >     Intervals should be as POD as possible and no PODer.
 >           -- apologies to Albert?
 >
 > -- Lee Winter

Let's paraphrase Tolstoy's "Anna Karenina" instead:
    All PODs are alike. Every non-POD is non-POD in its own way.

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.)

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