Boost logo

Boost :

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-11-17 07:47:04


Terje, this is my last reply here because we are widely off-topic. Ah,
is your mail server up? I repeatedly get delivery status notifications
(Status: 5.1.1: bad destination mailbox address).

You wrote:
>> >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 meant I was curious to know whether the experts said the formal
approach could have helped in the standards effort.

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

Hopefully. But I see a man with a moderator hat who is getting nearer
and nearer.

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

http://groups.google.com/groups?threadm=aec3f4%24t8m%241%40glue.ucr.edu

[...]
>I find it understandable that the standard is as it is. You have general
>rules, and you have any exceptions.

General? With 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."

Even only "an exception is main", with a reference to the relevant
paragraph would be ok for me. The general assertion would be "flowing
off the end of a function other than main etc. etc.", not the one
written above. Your point of view is like saying that "no integer
number is equal to its opposite" is a true statement. After all, zero
"is an exception"! Just one further step and you say that continuity
implies derivability. The rest are "exceptions" (Well, nobody said
that so far, or we would hear Weierstrass turning in his grave :-()

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

Hmmm... I didn't expect such a jab from you. However, considering how
widespread is this policy through the standard, I'm not so conceited
to think that I can do anything, having the whole committee met to do
a major review of the standard text because a "just anybody" like me
didn't like their choice :-)

Genny.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk