Re: [boost] Re: Copy Constructible Concept

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-11-16 14:56:41

>From: "Gennaro Prota" <gennaro_prota_at_[hidden]>

> On Sat, 16 Nov 2002 00:07:11 +0100, "Terje Slettebø"
> <tslettebo_at_[hidden]> wrote:
>
> >>From: "Gennaro Prota" <gennaro_prota_at_[hidden]>
> >> Who knows? When I encounter these sorts of situations I dream a
> >> standard where propositions can be demonstrated like in mathematics or
> >> counter-examples provided. Don't you?
> >
> >You're not the only one. Bjarne Stroustrup says the same in "The Design
and
> >Evolution of C++" (p. 103):
>
> Ouch, it's too much time that my bookshelf claims that book.

<g> I've just started reading it, myself. I felt for a break from other
things, and have read most of part I. It has been sitting in my bookshelf
for quite some time, as well. It's quite interesting to learn about the
evolution of the language.

> >Much
> >later, the ANSI/ISO C++ committee had a stream of formal definition
experts
> >explain their techniques and tools and give their opinions of the extent
to
> >which a genuine formal approach to the definition of C++ would help us in
> >the standards effort.
>
> Thank you very much for typing all that stuff! In fact, I'm quite
> curious about those opinions.

I'm glad you appreciate it. I thought this could be of general interest,
which is why I posted it.

> I really miss formality in the standard. Even answering a simple
> question like: "is static_cast<unsigned int>(-1) guaranteed to give
> UINT_MAX on all conforming implementations?" is quite a project. If
> you think to the mathematical analogy those issues should be the kind
> of elementary propositions that you find just after a definition
> (uniqueness of inverse, and the like).

The thing is that different computers differ in their representation of
data. So implementation-dependent things may enable more efficient
implementations, than if one particular way is decided.

> Just imagine what it can be demonstrating anything which deals with
> that mystery of the logic that are references (they are not objects,
> but are not expressions either 'cause they are something whose
> "existence" must be considered in run-time, they are not... what they
> are???)

Hm, I find references quite straightforward. They are aliases of objects.
Unless it can be optimised away, they are typically implemented as pointers.

> To complicate things even further, there's the bad habit that
> "general" incorrect assertions are made though the standard, except
> that they are corrected for the "special cases" elsewhere.
>
> So that you
> can never know if a given paragraph contains everything you need to
> know. For instance, 6.6.3/2 says that
>
>     int main() {}
>
> invokes undefined behavior. The assertion is "corrected" in 3.6.1 but
> you see that this policy is quite dangerous when you have a doubt and
> you are looking for a quote. A similar situation concerns pure virtual
> destructors: 10.4/2 says it need be defined only if explicitly called
> with the qualified-id syntax (5.1); of course that's manifestly wrong.
> The "correction" is in 12.4/7 and 12.4/6.
>
> Now I think you begin to see why I'm so suspicious when
> "demonstrating" on the basis of what the standard says.

I find it understandable that the standard is as it is. You have general
rules, and you have any exceptions. You have the example of the section that
says a value-returning function that doesn't explicitely return something,
results in undefined behaviour, and the special case for main(). What one
could have done in this case is to add a reference to main() in that
section. For example (6.6.3/2):

"Flowing off the end of a function is equivalent to a return with no value;
this results in undefined behavior in a value-returning function. An
exception is main() (3.6.1.5), where the return is optional."

This would put all the relevant information in one place. This is what DRs
are about. :) (This is hardly a defect, but it shows that it's possible to
improve things, rather than just complaining about them)

Regards,

Terje