fresh look on copying objects and passing args by value

15 views
Skip to first unread message

witoldk

unread,
Feb 9, 2003, 5:50:34 PM2/9/03
to
My surprisingly unpopular views on some fundamental language
concepts have gotten me into lots of trouble on this and
other Usenet newsgroups lately. Trying to start all fresh :)

I think I understand now that the criticism my (maybe unusual
for some) ideas about copy constructing objects have been
receiving has been caused by mistake on my side.
I've found that people have problems accepting my novel
designs because I've failed to provide means to reason about
equivalence of copies. Still can not understand why instead
of telling me that equivalence of copies is impossible to
assertain everybody was telling me my copies were not
equivalent.

So here is my fresh start (can hardly do anything right first
try these days :)

struct side_eff {
side_eff(): k(0) {}
side_eff(side_eff const&): k(1) {}
bool operator == (side_eff const& rhs)
{
return k == 1 || rhs.k == 1;
}
int k;
};

void foo(side_eff se = side_eff()) { cout << se.k << endl; }

int main() { foo(); return 0; }

Please critique the code.
Please reason what is going to be printed had this code
been compiled and run.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

Hyman Rosen

unread,
Feb 9, 2003, 9:46:15 PM2/9/03
to
witoldk wrote:
> My surprisingly unpopular views

As we keep saying, the language permits an object to be constructed
into its ultimate destination when the code would otherwise construct
a temporary and then copy it. This is true regardless of any side
effects the copy constructor may have, or the what any member functions
do, or the phase of the moon.

There is no "reasoning about equivalence of copies" involved.

Bruce G. Stewart

unread,
Feb 10, 2003, 5:18:48 AM2/10/03
to

Some headers and some namespace tags are missing.

side_eff v;
assert (v == v);

This assertion fails, an unconventional notion of equality.

Still, the program does not use values of this type with any library
functions that have constraints or requirements for operator ==(), so
that isn't technically incorrect. It's just contrary to what I think
is the normal expectation.

Whether this program is correct or incorrect depends on what
requirements it is expected to fulfill. You haven't said what it is
supposed to do. Any critique involves assumptions about your intent.

The program sends "1\n" or "0\n" to cout, depending on whether the the
copy constructor is used or not used to construct the parameter se. We
cannot determine from the language specification which it will be.


If the intent is that the program print one of these values, and never
the other, then the program is defective.

You could avoid the uncertainty by defining the function foo more
explicitly, for example:

void foo (side_eff const &r)
{
side_eff se (r);
cout << se.k << endl;
}
void foo ()
{
side_eff t;
foo (t);
}

The above implements what I understand you once expected your foo to
mean, (except for, possibly, the order of destruction of se, and t or
any temporary created to act as the parameter of a call with an
arguement.)

John Potter

unread,
Feb 10, 2003, 5:19:27 AM2/10/03
to
On 9 Feb 2003 17:50:34 -0500, witoldk <wit...@optonline.net> wrote:

> So here is my fresh start (can hardly do anything right first
> try these days :)

It is impossible to do anything wrong, right.

> struct side_eff {
> side_eff(): k(0) {}
> side_eff(side_eff const&): k(1) {}
> bool operator == (side_eff const& rhs)
> {
> return k == 1 || rhs.k == 1;
> }
> int k;
> };

int main() {
side_eff a, b, c(a);
cout << (a == a) << "\n";
cout << (a == c) << (c == b) << (a == b) << "\n";
}

It seems that equality is neither reflexive nor transitive.
Do you expect the language to go out of the way to support
this absurdity?

I can't decide whether your posts are trollish, foolish,
or really confused by basic (maybe C++) factsish. It would
help if you could tell us which or offer another choicish.

John

Joshua Lehrer

unread,
Feb 10, 2003, 5:21:25 AM2/10/03
to
witoldk <wit...@optonline.net> wrote in message news:<pan.2003.02.09....@optonline.net>...

>
> struct side_eff {
> side_eff(): k(0) {}
> side_eff(side_eff const&): k(1) {}
> bool operator == (side_eff const& rhs)
> {
> return k == 1 || rhs.k == 1;
> }
> int k;
> };
>
> void foo(side_eff se = side_eff()) { cout << se.k << endl; }
>
> int main() { foo(); return 0; }
>
>
> Please critique the code.

It is impossible to critique code without knowing what the programmer
intends for it to do. Usually, this can be conveyed with well named
variables and classes. In this case, you named a member "k", not very
descriptive. Unless I know what you are trying to do, I can't
critique your code and tell you if it will do what you expect.

On the other hand, operator== is self descriptive. It should return
true if the objects being compared are equivalent. First of all, it
should be a "const" method, yours is not. Second, your operator==
does not do what a standard operator== should do, it does not test
equivalence. Therefore, I would red flag this code during a code
review, and ask for justification in the form of comments in the code.

joshua lehrer
factset research systems
NYSE:FDS

witoldk

unread,
Feb 10, 2003, 8:14:04 PM2/10/03
to
Hyman Rosen <hyr...@mail.com> wrote in message news:<fyB1a.15338$F25....@nwrddc02.gnilink.net>...

> witoldk wrote:
> > My surprisingly unpopular views
>
> As we keep saying, the language permits an object to be constructed
> into its ultimate destination when the code would otherwise construct
> a temporary and then copy it. This is true regardless of any side
> effects the copy constructor may have, or the what any member functions
> do, or the phase of the moon.
>
> There is no "reasoning about equivalence of copies" involved.

Since it looks like we've run into the wall here, let my try "from
a different angle": what does it mean to pass function args by value
in C++?
I've posted that question on several ocasions and I've got only one
answer so far, and that was on c.s.c. Still, the poster has yet to answer
my follow-up :)

Shane Beasley

unread,
Feb 10, 2003, 8:22:58 PM2/10/03
to
Hyman Rosen <hyr...@mail.com> wrote in message news:<fyB1a.15338$F25....@nwrddc02.gnilink.net>...

> witoldk wrote:


> > My surprisingly unpopular views
>
> As we keep saying, the language permits an object to be constructed
> into its ultimate destination when the code would otherwise construct
> a temporary and then copy it. This is true regardless of any side
> effects the copy constructor may have, or the what any member functions
> do, or the phase of the moon.

The question at hand isn't whether this optimization is permitted by
the language (which it is), but whether it should be permitted. The OP
seems to argue against it, on the basis that it alters the behavior of
some programs. To disagree is to enter into an ethical debate, not a
legal one.

As to the merits of such a debate... :)

> There is no "reasoning about equivalence of copies" involved.

Actually, there is; in fact, it's at the heart of the matter.

By convention, copying an object means to copy its state, i.e., its
member data. Similarly, by convention, x and y are equivalent, and x
== y is true, when x and y have the same observable state. If a copy
is equivalent to the original, then they have the same state, so that
it shouldn't matter whose state you are inspecting -- one's as good as
the other. That's why C++ allows the compiler to elide copying in
certain well-defined cases.

Even the notorious exception to traditional copy semantics,
std::auto_ptr, is not affected by this optimization -- either the
unchanged original or the copy is inspected, and they are equivalent.
To be affected by this optimization requires the state of the copy to
be distinct from the state of the original, at which point it's not
much of a copy, is it?

Instead of defending the optimization, I expect the OP to defend why
his code ought to work. The copy constructor doesn't even look at its
argument, so it can't possibly copy its state; and that operator== is
a joke, in no way associated with the concept of equivalence (i.e., x
== y doesn't compare x to y). To call these semantics "surprising" is
to be exceedingly gracious.

If there's a more practical application of this, I'd love to see it.
Otherwise, this issue is purely philosophical (best case) or a troll
(worst case), neither interesting nor important.

- Shane

witoldk

unread,
Feb 10, 2003, 8:27:32 PM2/10/03
to
jpo...@falcon.lhup.edu (John Potter) wrote in message news:<3e472422...@news.earthlink.net>...

> On 9 Feb 2003 17:50:34 -0500, witoldk <wit...@optonline.net> wrote:
>
> > So here is my fresh start (can hardly do anything right first
> > try these days :)
>
> It is impossible to do anything wrong, right.
>
> > struct side_eff {
> > side_eff(): k(0) {}
> > side_eff(side_eff const&): k(1) {}
> > bool operator == (side_eff const& rhs)
> > {
> > return k == 1 || rhs.k == 1;
> > }
> > int k;
> > };
>
> int main() {
> side_eff a, b, c(a);
> cout << (a == a) << "\n";
> cout << (a == c) << (c == b) << (a == b) << "\n";
> }
>
> It seems that equality is neither reflexive nor transitive.
> Do you expect the language to go out of the way to support
> this absurdity?
>
> I can't decide whether your posts are trollish, foolish,
> or really confused by basic (maybe C++) factsish. It would
> help if you could tell us which or offer another choicish.


Looks like I've got what I've been asking for all along :)
My posts are likely all of the above, with the accent
on the second and third choices.

The problem is with my limited mental capacity. Stupid me,
the operator == is neither reflexive nor it is transitive.
What an absurd! Shoot, it is not a const method either.
But all I wanted to say is that the objects of my side_eff
class are equal when one of them has member variable k == 1.
Maybe some on this newsgroup could help me fix it?

Nobody writes code like that. Not even I (well, maybe not all
the time). I still think (but no, I could not be right) this
is legal C++. Whether anybody likes it or anybody finds it
reasonable does not change this supposition.
My posts are meant to find out whether the fact that the
foo() can print 1 and it can also print 0 and be right in both
cases bothers anybody but me.

So far, here is what I've got for the answer: it absolutely
bothers nobody, because copy constructors should copy, and I
don't know what I'm talking about.

If that is the answer I'll take it.

johnchx

unread,
Feb 11, 2003, 6:16:16 AM2/11/03
to
witoldk <wit...@optonline.net> wrote:

> My surprisingly unpopular views on some fundamental language
> concepts have gotten me into lots of trouble on this and
> other Usenet newsgroups lately. Trying to start all fresh :)

I'm not sure what you're driving at. Are you saying that you'd prefer
it if the Standard _didn't_ allow the compiler to elide the copy-ctor?
If so, I suspect that your view was considered by the committee, and
that the committee decided that the benefit of simplifying the
application of the RVO outweighed the drawbacks.

So.... To critique your design: (1) others have already pointed out
that operator== does something strange and unexpected, so it's
probably ill conceived. (2) The output of foo() is unpredictable in
standard c++. Is that the intent? Why?

Hyman Rosen

unread,
Feb 11, 2003, 4:01:13 PM2/11/03
to
witoldk wrote:
> Since it looks like we've run into the wall here, let my try "from
> a different angle": what does it mean to pass function args by value
> in C++?

The argument expressions are used to initialize the parameters of the
function to be called.

Daniel Frey

unread,
Feb 11, 2003, 6:08:19 PM2/11/03
to

Come on. It seems to me that you want to know how to achive a certain
goal but so far nobody understood your goal. Instead of getting
destructive, why not try to get the question right before complaining
about "wrong" answers? As far as I can see your question could be: Given
that the compiler is allowed to elide certain temporaries (and thus
eliding my user-defined cctor), how can I write my code/class in a way
which prevents this and leads to a predictable and reliable behaviour?
I'm sure people will happily try to help you once we understand the real
question :)

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: danie...@aixigo.de, web: http://www.aixigo.de

Maciej Sobczak

unread,
Feb 11, 2003, 6:12:08 PM2/11/03
to
Hi,

"witoldk" <wit...@optonline.net> wrote in message

news:9bed99bb.03021...@posting.google.com...

> So far, here is what I've got for the answer: it absolutely
> bothers nobody, because copy constructors should copy

The problem (not with the code, but with the fact whether it
bothers anybody) is that the semantics of copy constructor is not
locally defined in the standard and therefore it is easy to come
up with only partial definition (or understanding).

For some, copy constructor is their own business -- nobody should
influence what they like to put in the code.

For some others, copy constructor is defined in terms of
imaginary comparison (==) following the copy, as if this code is
executed:

MyClass a;
MyClass b;
assert(a == b);

This understanding is more common and can be shared among
programmers from other languages (note that one can do the other
way round: stretch the meaning of operator== to fit the meaning
of copy constructor).

My understanding is that the semantics of copy constructor in C++
is defined by *every* phrase in the standard that can possibly
influence it. One of such a phrase is the explicit permission to
omit temporaries in certain contexts (12.8/15), which means that
in addition to be in harmony with operator==, your copy
constructors should more or less be independent on how many times
the object is copied (I write "more or less", because for example
logging to a file is not independent, yet I do not bother, since
the logging is not likely to be the main effect of running a
program). In other words, the copy constructor should have a
meaning that fits both operator== and 12.8/15 and probably other
places where it is involved in any way. Writing code so that only
*some* of the issues are considered is like *selectively* reading
the Bible (or the Koran or whatever else you choose) or your
country's constritution. I think we agree that the hell is full
of people doing this. ;)

Yet I'm ready to admint that if your copy constructor meets:
1. the operator== semantics in terms of assert(a == b);
2. the 12.8/15 clause
3. whatever else the Standard contains that is relevant
*AND*
4. the design of your program,

then you are OK.

In your code, the copy constructor violates 2 and (most
importantly) 4, which means that it is only you who should bother
and only about this one piece of code.

In short: write your code to fit the language as it is instead of
blaming the language that it does not fit your code. ;) Most of
the time it works. In the *very special* cases where it doesn't,
I switch to another language.

--
Maciej Sobczak
http://www.maciejsobczak.com/

Distributed programming lib for C, C++, Python & Tcl:
http://www.maciejsobczak.com/prog/yami/

witoldk

unread,
Feb 11, 2003, 6:52:19 PM2/11/03
to
john...@yahoo.com (johnchx) wrote in message news:<4fb4137d.03021...@posting.google.com>...

> witoldk <wit...@optonline.net> wrote:
>
> > My surprisingly unpopular views on some fundamental language
> > concepts have gotten me into lots of trouble on this and
> > other Usenet newsgroups lately. Trying to start all fresh :)
>
> I'm not sure what you're driving at. Are you saying that you'd prefer
> it if the Standard _didn't_ allow the compiler to elide the copy-ctor?

Let me be first to correct you :) The compiler would not elide the
copy-ctor. It would elide the copy (according to some :)

> If so, I suspect that your view was considered by the committee, and
> that the committee decided that the benefit of simplifying the
> application of the RVO outweighed the drawbacks.

With all due respect I think it was a wrong decision. I would
expect the optimization to be something extra. In this case
I do not want the extras when making the basics "muddy" is the price.

>
> So.... To critique your design: (1) others have already pointed out
> that operator== does something strange and unexpected, so it's
> probably ill conceived.

Thank you for the "probably" :)


> (2) The output of foo() is unpredictable in
> standard c++. Is that the intent? Why?

The intent is actually to make it predictable.
Telling me this is bad C++ when the standard approves similar
designs (auto_ptr - do not mean it is bad; it did save the day
for me at least once :) is inconsistent to say the least.
Telling me that this code is an absurd does not change the fact
that it is legal C++.
Telling me that design like that could not ever be relevant or
have practical use (auto_ptr!!!) and demanding to justify why
should it work suggests that a person demanding it seems to be
thinking he/she is in a position to enumerate all the "right"
uses for the _general_purpose_ programming language like C++.
In an effort to make my posts a little less controversial I am
going to refrain from making my point more explicitly :)
Please note that the code was put together to illustrate the
price for the RVO (or rather this specific application of it).
The price to pay is departing from "coomon" (as in C) meaning of
pass by value.
I think the code serves its purpose well.

James Dennett

unread,
Feb 11, 2003, 6:54:32 PM2/11/03
to
witoldk wrote:
> Hyman Rosen <hyr...@mail.com> wrote in message news:<fyB1a.15338$F25....@nwrddc02.gnilink.net>...
>
>>witoldk wrote:
>>
>>>My surprisingly unpopular views
>>
>>As we keep saying, the language permits an object to be constructed
>>into its ultimate destination when the code would otherwise construct
>>a temporary and then copy it. This is true regardless of any side
>>effects the copy constructor may have, or the what any member functions
>>do, or the phase of the moon.
>>
>>There is no "reasoning about equivalence of copies" involved.
>
>
> Since it looks like we've run into the wall here, let my try "from
> a different angle": what does it mean to pass function args by value
> in C++?

That the called function will receive a value not in
use elsewhere on which to operate. As opposed to working
on a reference to an external object.

-- James.

Andrea Griffini

unread,
Feb 11, 2003, 7:06:52 PM2/11/03
to
On 10 Feb 2003 20:27:32 -0500, wit...@optonline.net (witoldk) wrote:


>So far, here is what I've got for the answer: it absolutely
>bothers nobody, because copy constructors should copy, and I
>don't know what I'm talking about.
>
>If that is the answer I'll take it.

May be I'm more mentally limited by you, but I can't really
understand what your point is... for example if I write

#include <iostream>

int x;

int foo(int i)
{
x=i;
return i;
}

int main()
{
int res=foo(1)+foo(2);
std::cout << "x=" << x << "\n";
return 0;
}

then the program is valid C++, but still you can't tell
what its output is going to be. In general it can be
"x=1" or "x=2", and this may depend on the compiler,
the version, the weather and the mood of who's looking
at the screen.

Back to your case the language says that if you pass
an object argument by value it will be a compiler
decision to either compute a temporary object for
the expression in the call, and the copy this object
to the parameter the function will receive, or just
build the parameter using the expression.
So the compiler has a special license in this case
to just skip the copy in the name of efficency, like
it has for example for the RVO.

If your program has side effect or strange meaning
of copy construction then you've been warned; in those
cases you can't predict if the copy constructor will
be called or not. You're not even guaranteed that the
behaviour will be consistent between one call and
the successive if you do them in a loop.

That is a reason among the others for which people
say that in C++ the copy construcor must copy.
Writing code that depends on one behaviour or the
other is like writing code that depends on the order
of evaluation as in my former example.... a recipe
for a disaster

In some case even the library gave some strange
meaning to the copy constructor, but getting that
right has been a big source of pain even for gurus.

Andrea

witoldk

unread,
Feb 11, 2003, 7:08:44 PM2/11/03
to
usene...@lehrerfamily.com (Joshua Lehrer) wrote in message news:<31c49f0d.03020...@posting.google.com>...

> witoldk <wit...@optonline.net> wrote in message news:<pan.2003.02.09....@optonline.net>...
> >
> > struct side_eff {
> > side_eff(): k(0) {}
> > side_eff(side_eff const&): k(1) {}
> > bool operator == (side_eff const& rhs)
> > {
> > return k == 1 || rhs.k == 1;
> > }
> > int k;
> > };
> >
> > void foo(side_eff se = side_eff()) { cout << se.k << endl; }
> >
> > int main() { foo(); return 0; }
> >
> >
> > Please critique the code.
>
> It is impossible to critique code without knowing what the programmer
> intends for it to do. Usually, this can be conveyed with well named
> variables and classes. In this case, you named a member "k", not very
> descriptive. Unless I know what you are trying to do, I can't
> critique your code and tell you if it will do what you expect.
>
> On the other hand, operator== is self descriptive. It should return
> true if the objects being compared are equivalent. First of all, it
> should be a "const" method, yours is not. Second, your operator==
> does not do what a standard operator== should do, it does not test
> equivalence. Therefore, I would red flag this code during a code
> review, and ask for justification in the form of comments in the code.

Thank you.
Could you please explain what makes you think my operator == does not
test equivalence ?

Early Ehlinger

unread,
Feb 11, 2003, 7:12:23 PM2/11/03
to
"witoldk" <wit...@optonline.net> wrote

> My posts are meant to find out whether the fact that the
> foo() can print 1 and it can also print 0 and be right in both
> cases bothers anybody but me.

There are so many (legal) uses of C++ that result in implementation-defined
behavior that we have (almost) all become numb to them. They do not bother
us at all, because we understand the benefits of allowing implementations to
define the behavior.

Without implementation-defined behavior, all int's would have to be the same
size, regardless of processor-specific considerations. So suppose the
Standards comittee had decided that all int's must be 128 bits long? That
would really make life difficult for compiler writers trying to support
32-bit only processors. They'd have to implement all kinds of support code
to emulate a 128 bit integer. Instead, sizeof(int) is implementation
defined, just like sizeof(long).

Should this particular scenario result in implementation defined behaviour?
In my opinion the answer is clearly YES.

Why?

Consider this. The temporary you expect to create in order to initialize se
must also be destructed. If, on the other hand, you elide away the copy
construction and use the default constructor for se, what you are really
doing is eliding away the entire temporary variable! Is that a good
optimization, dropping two (redundant) variables in favor of having only
one? I would say yes and welcome the kindness of the compiler in getting
rid of the temporary variable altogether.

void bar( unsigned int n )
{
for( unsigned int idx = 0 ; idx != n ; ++idx )
foo( );
}

If this takes O(n) time with the optimization, it takes O(2n) time without
(roughly). Sure, they're both linear w/ respect to n, but one takes twice
as long simply because it has to call the constructor for the temporary and
then call the copy constructor to initialize se instead of directly calling
the constructor for se.


--
-- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697 --
- RenderFarm - Lightwave , 3dSMax , Bryce , Maya , AfterEffects -
--- www.respower.com -- 400+ GHz Starting At USD$0.50/GHz*Hour --
----------------- SuperComputing For the Masses! ----------------
"I'm so busy programming my computer to let me be lazy, I never
get any rest!" - John Kaster

Maciej Sobczak

unread,
Feb 12, 2003, 9:35:38 AM2/12/03
to
Hi,

"Maciej Sobczak" <mac...@maciejsobczak.com> wrote in message
news:b2ac63$iga$1...@SunSITE.icm.edu.pl...

> For some others, copy constructor is defined in terms of
> imaginary comparison (==) following the copy, as if this code
is
> executed:
>
> MyClass a;
> MyClass b;
> assert(a == b);

Of course:

MyClass a;
MyClass b(a); // <-- copy constructor invoked
assert(a == b);

Maciej Sobczak

unread,
Feb 12, 2003, 11:31:20 AM2/12/03
to
Hi,

"Andrea Griffini" <agr...@tin.it> wrote in message
news:3e496ebd...@news.tin.it...

> #include <iostream>
>
> int x;
>
> int foo(int i)
> {
> x=i;
> return i;
> }
>
> int main()
> {
> int res=foo(1)+foo(2);
> std::cout << "x=" << x << "\n";
> return 0;
> }
>
> then the program is valid C++

Are you sure?
What about sequence points?

This code:

int res = ++x + ++x;

Is certainly *not* valid C++, since x is read and modified twice
before a sequence point. Undefined behavior.

Consider this:

int foo(int &x)
{
return ++x;
}

// ...
int res = foo(x) + foo(x);

Does it make any difference?
In other words -- how the existence of function call in the
middle of some expression influences its sequence points?

The follow-up question: what about *inlining* foo()?

My understanding is that a compiler targeting some imaginary
superscalar architecture could arrange for both foos to be
executed simultaneously (who've made this spelling?) or
interleaved, also resulting in undefined behavior.

This is something that is not quite clear to me.

witoldk

unread,
Feb 12, 2003, 2:54:09 PM2/12/03
to
Daniel Frey <danie...@aixigo.de> wrote in message
news:<3E48C109...@aixigo.de>...

Thank you. Your post had somewhat sobering effect :)
What was it that I was asking? I guess I got mildly annoyed by people
telling me my copy constructors don't copy. From there it became an
exercise in verbosity :) See no reason to be sorry, as this is an open
discussion forum, and those who don't care don't have to join :)
What I was trying to do is express my disbelief in the standard
introducing yet another way for perfectly legal programs to print
different
results and be right (true, it took me five years to notice :)
It seems to have been done in the name of efficiency.
Just like allowing evaluation order to be unspecified. There seems to be
difference though this time around. The difference seems to be that
nowadays iron is cheap. Few yaers ago I've seen a project aimed at
squeezing some time out of the nightly batch cycle. It took half a year
to squeeze some half hour. Soon after, some $$ were poured on the iron
and
that squeezed 1 and 1/2 hours from the cycle elsewhere. It was a
"routine"
upgrade. If I've learned that lesson, then everybody else likely learned
it ten times over. Enter RVO. If people write classes that are expensive
to copy they likely make sure the objects are not copied around too
much.
If they do need them copied around I think the fact that their compiler
might not implement RVO is not going to stop them. So the way I see it
the
RVO is best suited for speed comparisons between C# and C++ :) For that
application the price seems high.
That is all :)
Lesson: start a philosophical debate and all the questions you might
have
ever wanted to ask are going to be answered even without you asking :)

Andrea Griffini

unread,
Feb 12, 2003, 6:32:18 PM2/12/03
to
On 12 Feb 2003 11:31:20 -0500, "Maciej Sobczak"
<mac...@maciejsobczak.com> wrote:

>> then the program is valid C++
>
>Are you sure?
>What about sequence points?
>
>This code:
>
>int res = ++x + ++x;
>
>Is certainly *not* valid C++, since x is read and modified twice
>before a sequence point. Undefined behavior.

I wasn't doing this

>Consider this:
>
>int foo(int &x)
>{
> return ++x;
>}
>
>// ...
>int res = foo(x) + foo(x);
>
>Does it make any difference?

Sure it does. In this second example you're calling a function.
In my docs I read

1.8 Program execution [intro.execution]
...

8 Once the execution of a function begins, no expressions
from the calling function are evaluated until execution
of the called function has completed.8)

...

and numbered note 8 to which paragraph 8 is referring to
says

8) In other words, function executions do not interleave
with each other.


Also paragraph 7 says among other things..

Evaluation of an expression might produce side effects.
At certain specified points in the execution sequence
called sequence points, all side effects of previous
evaluations shall be complete and no side effects
of subsequent evaluations shall have taken place.7)

numered note 7 explains that

7) Note that some aspects of sequencing in the abstract
machine are unspecified; the preceding restriction
upon side effects applies to that particular
execution sequence in which the actual code is
generated. ...

This is what I understood them to say: there are sequence
points that are not decided by the programmer, and one of
them is the calling of a function; after a function starts
and before returns nothing is evaluated from the calling
context, and some of the side effects of the full expression
may have been applied, and some other not.
Which ones are applied and which ones not may be unspecified.

So when I write a full expression containing several
function calls and without forcing sequence points myself
the compiler can choose the order of evaluation of the
various terms, but every function call is a sequence point
and the compiler has the freedom to move those sequence
points a bit in the timeline, but can't remove them.
As example I think that with the code

x = y = 0; // globals
result = f() + (x++) + g() + (y++);

if f sees

x==1, y==0

then g cannot see

x==0, y==1

because g() must have been called either before or
after f(), and in neither of those cases that
combination is possible.
Of course g() can see any of

x==0, y==0 // g before f
x==1, y==0 // g before or after f
x==1, y==1 // g after f

>In other words -- how the existence of function call in the
>middle of some expression influences its sequence points?

Where you use "&&" or "||" there are sequence points,
but those are not the only ones. There is also sequence
point before every function call, and you just don't
happen to know where on the hypotetical timeline those
sequence points are placed.

Note also that assignment is not a sequence point for
native types, but it implies a sequence point for
classes, as it's considered a function call.

>The follow-up question: what about *inlining* foo()?

Paragraph 17 in my docs says

17 When calling a function (whether or not the
function is inline), there is a sequence point
after the evaluation of all function arguments
(if any) which takes place before execution
of any expressions or statements in the
function body.

>My understanding is that a compiler targeting some imaginary
>superscalar architecture could arrange for both foos to be
>executed simultaneously (who've made this spelling?) or
>interleaved, also resulting in undefined behavior.
>
>This is something that is not quite clear to me.

The compiler is free to do whatever it wants but the
observable result must be the same as if a sequential
execution has been performed in one of the admissible
orders of evaluation. An observable interleaved
execution is specifically forbidden.

Roughly I think one could simplify saying that if you
can tell the difference at the C++ level, then the
compiler can't do that. If it's not possible to tell
the difference ... well... what are we talking about ?
If there's no difference there's no difference (this
is a deep concept ;) ) and one may say the code has
been inlined and another may say it hasn't. Who is right ?
If you wanna discuss if something has been inlined or
not then you're required to dive in the assembly sea.


Andrea

PS:
Note that I don't have the official standard,
so the numberings and even the text can be
different in the current official C++
specification document. I *suppose* however
that the supporting reasoning didn't change.

Hyman Rosen

unread,
Feb 12, 2003, 6:35:05 PM2/12/03
to
Maciej Sobczak wrote:
> What about sequence points?

What about them? According to 1.9/17, there is a sequence
point after the return value of a function is copied but
before any further expressions outside the function are
executed.

> Consider this: ... Does it make any difference?

No. It's still OK.

> In other words -- how the existence of function call in the
> middle of some expression influences its sequence points?

Each function call results in two more sequence points,
one before the statements of the function begin executing
and one after, before any expression outside the function
is executed.

> The follow-up question: what about *inlining* foo()?

Completely irrelevant. Inlining does not change any semantics.

> interleaved

This is expressly forbidden by 1.9/8 and its footnote.
Any such optimization must act "as-if" the executions
were not interleaved.

Hyman Rosen

unread,
Feb 12, 2003, 6:37:37 PM2/12/03
to
witoldk wrote:
> Telling me...

Ignore all those other people who are bashing your code :-)
What *I'm* telling you is that C++ and its makers have chosen
the lack or predictability in favor of the optimization.

Unless you can make an absolutely compelling case for the
other point of view (perhaps by showing some code which
accomplishes something essential and difficult to do in
any other way) it's going to stay that way.

Francis Glassborow

unread,
Feb 12, 2003, 8:02:18 PM2/12/03
to
In message <b2dc5n$s79$1...@SunSITE.icm.edu.pl>, Maciej Sobczak
<mac...@maciejsobczak.com> writes

>My understanding is that a compiler targeting some imaginary
>superscalar architecture could arrange for both foos to be
>executed simultaneously (who've made this spelling?) or
>interleaved, also resulting in undefined behavior.

Such machines do not fit the model that C++ is written for. I asked WG14

to clarify this issue over a decade ago and their answer seems just as
valid today.

We can all suggest machines on which specific behaviour will fail. I
think that the way sequence points work (yes there are some corner cases

that WG14 are working on tying down) is that sequence points may nest
but must not interleave. Perhaps we need a formal specification.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU

Andrea Griffini

unread,
Feb 13, 2003, 8:51:57 PM2/13/03
to
On 12 Feb 2003 20:02:18 -0500, Francis Glassborow
<francis.g...@ntlworld.com> wrote:

>that WG14 are working on tying down) is that sequence points may nest
>but must not interleave. Perhaps we need a formal specification.

I think I don't understand neither of the cases. I always
considered sequence points being "points", in particular
without a dimension in the line of time.
If I understood the docs correctly there's only one virtual
thread in the C++ model (if there's more than one even the
idea of "order of evaluation" is nonsense), so what does
it mean that sequence point may "nest" ?

As I read the documens this is the picture I get: you can
imagine a single-processor single-thread architecture in
which the code is compiled, and for a give source code
there are however a few possible choices of order of
evaluation of subexpressions. There are sequence points
that can be placed somewhat freely in the time axis but
that can't fall in the middle of any side effect.
As I see them those points are gemetric points in the
time axis, and none can "contain" or "interleave" another.

A valid behaviour of a C++ program must then be one
resulting by a possible sequence of choices in such a
simple model, with no observable difference from it.
Another bit of freedom is that the choices made are not
required to be the same every time a specific part of
the code is executed.

Andrea

John Potter

unread,
Feb 13, 2003, 9:02:30 PM2/13/03
to
On 12 Feb 2003 11:31:20 -0500, "Maciej Sobczak" <mac...@maciejsobczak.com>
wrote:

> Consider this:

> int foo(int &x)
> {
> return ++x;
> }

> // ...
> int res = foo(x) + foo(x);

> Does it make any difference?

Yes, function call introduces two sequence points.

> In other words -- how the existence of function call in the
> middle of some expression influences its sequence points?

> The follow-up question: what about *inlining* foo()?

Inlining does not change semantics.

> My understanding is that a compiler targeting some imaginary
> superscalar architecture could arrange for both foos to be
> executed simultaneously (who've made this spelling?) or
> interleaved, also resulting in undefined behavior.

No. The function call is a sequence point and no statements in
the called function and the calling function may be interleaved.
It is thus not possible to call the other function until the
first returns. 1.9/8.

John

johnchx

unread,
Feb 13, 2003, 9:20:26 PM2/13/03
to
wit...@optonline.net (witoldk) wrote

> > I'm not sure what you're driving at. Are you saying that you'd prefer
> > it if the Standard _didn't_ allow the compiler to elide the copy-ctor?
>
> Let me be first to correct you :) The compiler would not elide the
> copy-ctor. It would elide the copy (according to some :)

Indeed :-) It hadn't crossed my mind that "elide the copy-ctor" might
be read as "memcpy the raw storage of an object instead of calling the
copy-ctor," but I suppose somebody could theoretically misunderstand
it in this way. Henceforth, let us say "elide the copy." Actually,
doing so may help clarify the discussion a bit:

As you mentioned earlier, the idea of the copy-ctor is to allow you to
define the precise semantics of copying your classes. And this is so:
any time one of your objects is copied, the compiler _must_ call your
copy-ctor. What is out of your hands in some cases (in particular
where the RVO may apply) is _whether_ a copy is made.


> > (2) The output of foo() is unpredictable in
> > standard c++. Is that the intent? Why?
>
> The intent is actually to make it predictable.

Well, then, the program is not guaranteed by the C++ standard to work.
But you already know that -- it's the standard you're arguing with.
:-)

> Telling me this is bad C++ when the standard approves similar
> designs (auto_ptr - do not mean it is bad; it did save the day
> for me at least once :) is inconsistent to say the least.

I didn't say it was "bad." If, for instance, this code is intended to
diagonse whether your compiler is or is not applying the RVO in this
particular situation, it's just fine. If it's intended to reliably,
portably print the same result anywhere it's compiled...well, it won't
work.

But...what about auto_ptr? An excellent question! (In the original
"interview question" thread, I suggested the follow-up question "Is it
always an error for a copy-ctor to have side effects? Why or why
not?") Copy-ctors have side effects all the time -- auto_ptr and the
various ref-counted pointers being handy examples. So: what's the
difference? How do you tell "good" side effects from "bad" ones?

My first cut at a general rule is something like: "The copy-ctor
should define behavior necessary to preserve the class invariants if
and only if an object of the class is actually copied."
Interestingly, you can only apply the rule if you know what the class
invariants _are_.

Take auto_ptr: it's meant to guarantee strict ownership of a chunk of
heap-allocated memory. If -- and ONLY if -- an auto_ptr is actually
copied, the original pointer loses ownership to the copy. And this is
what auto_ptr's copy-ctor does -- it handles the ownership change if
and only if a real copy is made.

Another poster suggested an interesting rule of thumb: if the
copy-ctor does something, it should be "undone" in the destructor.
I'm not sure that "undone" really captures what goes on in, e.g., the
destructor of an auto_ptr which has relinquished ownership via a copy
operation. But the rule makes a good point -- that one legitimate use
of copy-ctor side effects is to "set the stage" for the destructor (of
the source and/or the target object). In fact, the only uses I've
been able to come up with for copy-ctor side-effects which _don't_
follow this pattern are conditions in which you are intentionally
making your code behave differently in different implementation
environments (i.e. you want to count the copies actually made to
figure out what your compiler or library is really up to).

> The price to pay is departing from "coomon" (as in C) meaning of
> pass by value.

Well, no. The C meaning of pass-by-value is "memcpy the raw storage
of a POD object." There is no "C meaning" of passing an object with a
user defined copy-ctor. And if you pass a POD in C++, it'll behave
just like in C -- the compiler may elide the copy, but you won't be
able to tell because the copy-ctor won't have any side effects. :-)

In C++, the general rule seems to be...the programmer can't always
control the exact number of times an object will be copied, so your
classes should be designed to work correctly without regard to the
frequency of copying. (This isn't just about RVO...IIRC, the standard
containers and algorithms also get to make copies of contained objects
more or less at will.)

llewelly

unread,
Feb 13, 2003, 9:34:31 PM2/13/03
to
agr...@tin.it (Andrea Griffini) writes:

> On 12 Feb 2003 11:31:20 -0500, "Maciej Sobczak"
> <mac...@maciejsobczak.com> wrote:
>
> >> then the program is valid C++
> >
> >Are you sure?
> >What about sequence points?
> >
> >This code:
> >
> >int res = ++x + ++x;
> >
> >Is certainly *not* valid C++, since x is read and modified twice
> >before a sequence point. Undefined behavior.
>
> I wasn't doing this
>
> >Consider this:
> >
> >int foo(int &x)
> >{
> > return ++x;
> >}
> >
> >// ...
> >int res = foo(x) + foo(x);
> >
> >Does it make any difference?
>
> Sure it does. In this second example you're calling a function.
> In my docs I read
>
> 1.8 Program execution [intro.execution]
> ...
>
> 8 Once the execution of a function begins, no expressions
> from the calling function are evaluated until execution
> of the called function has completed.8)

In the final standard, this is 1.9/8. The text remains unchanged. The
same applies to the remainder of Andrea's citations; they occur in
1.9 instead of 1.8 . (To me it appears that the Program Execution
section of the General clause was renumbered. The paragraphs
themselves however were not renumbered.)

[snip]


> PS:
> Note that I don't have the official standard,
> so the numberings and even the text can be
> different in the current official C++
> specification document. I *suppose* however
> that the supporting reasoning didn't change.

[snip]

This time you are correct. Next time ... Who can say? :-)

Andrea Griffini

unread,
Feb 14, 2003, 6:37:58 PM2/14/03
to
On 13 Feb 2003 21:34:31 -0500, llewelly <llewe...@xmission.dot.com>
wrote:

>This time you are correct. Next time ... Who can say? :-)

I've been told more than once that the standard is only $18
but that's not the problem for me (I've invested more than
twenty times that much just on C++ books in a couple of years).
My problem is that I've been working with standardization
institutions in the past and my view is probably a bit biased
because of this. I really don't like the idea that my $18
would be used just to buy a new leather chair for some
useless director in a misused building somewhere: for that
they can use all the big money the big industries are happy
to pay in the form of yearly subscriptions.

And, just to be accurate, the $18 standard is just an
american-only meaningless piece of paper... the real thing
is around $250 and has an ISO imprimatur.

And don't tell me that $18 is for covering the expenses...
they don't pay a dime for anything (if we exclude leather
chairs for useless directors).

Andrea

Early Ehlinger

unread,
Feb 15, 2003, 11:55:55 AM2/15/03
to
"witoldk" <wit...@optonline.net> wrote

> What I was trying to do is express my disbelief in the standard
> introducing yet another way for perfectly legal programs to print
> different
> results and be right (true, it took me five years to notice :)
> It seems to have been done in the name of efficiency.
> Just like allowing evaluation order to be unspecified. There seems to be
> difference though this time around. The difference seems to be that
> nowadays iron is cheap. Few yaers ago I've seen a project aimed at
> squeezing some time out of the nightly batch cycle. It took half a year
> to squeeze some half hour. Soon after, some $$ were poured on the iron
> and
> that squeezed 1 and 1/2 hours from the cycle elsewhere. It was a
> "routine"
> upgrade.

Methinks you miss the point.

Yes, we're all constantly amazed at how fast and cheap computers are "now"
as opposed to "before." However, they still aren't "fast enough," and
because of the problem domain I work in (and I'm guessing this applies to
the domains that quite a few others work in), they never will be.

Why wait 18 months for Moore's Law to produce a computer that's twice as
fast, when I can implement code that's twice as fast today? Why wait 18
months for Moore's Law to make up for an optimization that I could have
today (as it's already implemented)? And besides, if I make my code twice
as fast today, in 18 months, it will be at least 4 times as fast, and
probably faster since I'm going to be trying to figure out how to get rid of
some more bottlenecks during that time.

How long was this task taking before the routine upgrade? Did the change in
processor speed result in an equal change in time?

--
-- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697 --
- RenderFarm - Lightwave , 3dSMax , Bryce , Maya , AfterEffects -
--- www.respower.com -- 400+ GHz Starting At USD$0.50/GHz*Hour --
----------------- SuperComputing For the Masses! ----------------
"I'm so busy programming my computer to let me be lazy, I never
get any rest!" - John Kaster

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Ryjek

unread,
Feb 15, 2003, 12:01:52 PM2/15/03
to
John Potter wrote:
> On 12 Feb 2003 11:31:20 -0500, "Maciej Sobczak" <mac...@maciejsobczak.com>
> wrote:
>
>>Consider this:
>
>>int foo(int &x)
>>{
>> return ++x;
>>}
>
>>// ...
>>int res = foo(x) + foo(x);
>
>>Does it make any difference?
>
> Yes, function call introduces two sequence points.

What about this:

int res = foo(x) - foo(x);

Is it possible to reason about the result of this computation ?

Francis Glassborow

unread,
Feb 15, 2003, 2:48:19 PM2/15/03
to
In message <3e4b4266...@news.tin.it>, Andrea Griffini
<agr...@tin.it> writes

>I think I don't understand neither of the cases. I always
>considered sequence points being "points", in particular
>without a dimension in the line of time.
>If I understood the docs correctly there's only one virtual
>thread in the C++ model (if there's more than one even the
>idea of "order of evaluation" is nonsense), so what does
>it mean that sequence point may "nest" ?

A sequence point marks the end of a process and the start of another. A
process often contains internal sequence points. For example a function
call has a sp on entry and another on exit. Those points define a
segment of computation in a virtual single computational thread. Inside
that segment there will be other sps (end of complete statements etc.)
Those also break up the thread of computation. The rules of the language
sometimes allow alternative orders of evaluation of sub-expressions.
Sometimes those subexpressions themselves contain sequence points. I
believe it is the intention of those specifying the semantics of sps
that subexpressions that are delimited by sequence points must not be
interleaved.

Yes the ideas are hard to tie down which is why WG14 is finding it hard
to ensure that all the corner cases work as expected (actually some of
us are coming to believe that this cannot be achieved and that we really
need to agree on the achievable semantics even though that may differ
from what we hitherto believed were the semantics.)


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU

John G Harris

unread,
Feb 16, 2003, 6:22:49 AM2/16/03
to
In article <3e4c920...@news.tin.it>, Andrea Griffini
<agr...@tin.it> writes
<snip>

>And, just to be accurate, the $18 standard is just an
>american-only meaningless piece of paper... the real thing
>is around $250 and has an ISO imprimatur.
<snip>

The first two lines of your 18 dollar standard says :

INTERNATIONAL ISO/IEC
STANDARD 14882

so you needn't worry about it not being the original ISO text.

John
--
John Harris
mailto:jo...@jgharris.demon.co.uk

LLeweLLyn

unread,
Feb 16, 2003, 6:23:35 AM2/16/03
to
Ryjek <ry...@cox.net> writes:

> John Potter wrote:
> > On 12 Feb 2003 11:31:20 -0500, "Maciej Sobczak" <mac...@maciejsobczak.com>
> > wrote:
> >
> >>Consider this:
> >
> >>int foo(int &x)
> >>{
> >> return ++x;
> >>}
> >
> >>// ...
> >>int res = foo(x) + foo(x);
> >
> >>Does it make any difference?
> >
> > Yes, function call introduces two sequence points.
>
> What about this:
>
> int res = foo(x) - foo(x);
>
> Is it possible to reason about the result of this computation ?

Certainly. Both calls to foo(x) must complete before execution of
operator - . They may not be interleaved, but the order is
otherwise unspecified. If the left side is evaluated first, we
have something akin to:

(original_x_value + 1) - (original_x_value + 2)

that is, -1. If the right side is evaluated first, we have:

(original_x_value + 2) - (original_x_value + 1)

which is 1. So we can reason that the standard allows either 1 or -1,
but not time-travel.

More importantly, we can reason that this construct is confusing, in
addition to being unspecified, and should therefor be rejected by
the semi-mythical person reviewing your code. :-)

John Potter

unread,
Feb 16, 2003, 6:25:40 AM2/16/03
to
On 15 Feb 2003 12:01:52 -0500, Ryjek <ry...@cox.net> wrote:

> John Potter wrote:
> > On 12 Feb 2003 11:31:20 -0500, "Maciej Sobczak" <mac...@maciejsobczak.com>
> > wrote:

> >>Consider this:

> >>int foo(int &x)
> >>{
> >> return ++x;
> >>}

> >>// ...
> >>int res = foo(x) + foo(x);

> >>Does it make any difference?

> > Yes, function call introduces two sequence points.

> What about this:

> int res = foo(x) - foo(x);

> Is it possible to reason about the result of this computation ?

Yes. Let's initialize the global x to 40. Because of the function
call sequence points we know that one of the calls to foo will be
performed with all side effects taking place before the other call
is performed. Foo returns by value and the two calls will return
41 and 42. The final value of x will be 42. The value of res will
be either -1 or 1. There are no other possibilities. It will not
format your hard drive. It is unspecified not undefined.

John

LLeweLLyn

unread,
Feb 16, 2003, 6:53:32 PM2/16/03
to
agr...@tin.it (Andrea Griffini) writes:

> On 13 Feb 2003 21:34:31 -0500, llewelly <llewe...@xmission.dot.com>
> wrote:
>
> >This time you are correct. Next time ... Who can say? :-)
>
> I've been told more than once that the standard is only $18
> but that's not the problem for me (I've invested more than
> twenty times that much just on C++ books in a couple of years).

[snip]

The cost of the standard or wether you should buy it wasn't my
point. I thought it might be useful to compare your text from the
draft with the final version. I was amused (though not surprised)
to find that the standard was in this case effectively identical
to the draft.

I'd say more, but his line of conversation always resurrects a thread
which, IMO, has never reached any useful resolution, and is better
off dead.

Joshua Lehrer

unread,
Feb 16, 2003, 6:54:59 PM2/16/03
to
wit...@optonline.net (witoldk) wrote in message
news:<9bed99bb.03021...@posting.google.com>...

> usene...@lehrerfamily.com (Joshua Lehrer) wrote in message
news:<31c49f0d.03020...@posting.google.com>...
> > witoldk <wit...@optonline.net> wrote in message
news:<pan.2003.02.09....@optonline.net>...
> > >
> > > struct side_eff {
> > > side_eff(): k(0) {}
> > > side_eff(side_eff const&): k(1) {}
> > > bool operator == (side_eff const& rhs)
> > > {
> > > return k == 1 || rhs.k == 1;
> > > }
> > > int k;
> > > };
> > >
> Thank you.
> Could you please explain what makes you think my operator == does not
> test equivalence ?

From m-w.com: equivalence - equal in force, amount, or value.
virtually identical.

By definition. Identical objects are also virtually identical, as
"virtually identical" is a weaker form of "identical". Therefore, it
must be true that "X==X", and therefore "side_eff()==side_eff()", a
test which your operator== fails.

joshua lehrer
factset research systems
NYSE:FDS

Randy Maddox

unread,
Feb 19, 2003, 7:04:39 PM2/19/03
to
agr...@tin.it (Andrea Griffini) wrote in message
news:<3e4c920...@news.tin.it>...

> On 13 Feb 2003 21:34:31 -0500, llewelly <llewe...@xmission.dot.com>
> wrote:
>
> >This time you are correct. Next time ... Who can say? :-)
>
> I've been told more than once that the standard is only $18
> but that's not the problem for me (I've invested more than
> twenty times that much just on C++ books in a couple of years).
> My problem is that I've been working with standardization
> institutions in the past and my view is probably a bit biased
> because of this. I really don't like the idea that my $18
> would be used just to buy a new leather chair for some
> useless director in a misused building somewhere: for that
> they can use all the big money the big industries are happy
> to pay in the form of yearly subscriptions.
>
> And, just to be accurate, the $18 standard is just an
> american-only meaningless piece of paper... the real thing
> is around $250 and has an ISO imprimatur.

Sorry, but this statement is not accurate at all. The US $18 version
of the standard is a downloadable .pdf file, while the US $250 version
of the standard is a printed document. The content of both versions
is identically the very same Holy Standard as blessed by ISO and IEC.

Randy.

Andrea Griffini

unread,
Feb 20, 2003, 5:38:34 AM2/20/03
to
On 19 Feb 2003 19:04:39 -0500, rma...@isicns.com (Randy Maddox)
wrote:

>Sorry, but this statement is not accurate at all. The US $18 version
>of the standard is a downloadable .pdf file, while the US $250 version
>of the standard is a printed document. The content of both versions
>is identically the very same Holy Standard as blessed by ISO and IEC.

I was talking about this:

http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=25845&ICS1=35&ICS2=60&ICS3=

that to me looks like $250 for a download (or a printed version,
no price difference). What are you talking about ?
The only real good thing about the official standard is IMO
that it is the official standard. And the ANSI document is
not the official standard. Don't tell me just the cover is
different, it either is THE standard or is not THE standard.
I don't expect the differences between THE standard and the
last public draft being that many either.

If you think that $250 for a download is horrible then I
agree completely: I find offensive even the "mere" $18
that ANSI wants for its version.

I get my food by writing C++ programs, and for writing C++
programs I think the standard document isn't really that
important. More important is to know what real compilers
do, and on what areas real compilers do no agree.
For that, for dreaming about having them to converge and
for whishes or rants about the language itself IMO the
cover page is not that essential, and the last public
draft is more than adequate.

I don't want save $18, I just don't wanna bend on this
robbery for such a little gain. My working life is not
around C++, I don't care that much.
Me being one making a living by talking about how to
program in C++ or writing C++ compilers or books could
be a difference... probably in that situation even a mere
fortune-cookie line like "not everything is free in life"
would be enough to swallow that offense.

Kresimir Fresl

unread,
Feb 20, 2003, 9:49:44 PM2/20/03
to

Andrea Griffini wrote:

[...]


> What are you talking about ?

http://www.jamesd.demon.co.uk/csc/faq.html#B1

> The only real good thing about the official standard is IMO
> that it is the official standard. And the ANSI document is
> not the official standard. Don't tell me just the cover is
> different, it either is THE standard or is not THE standard.

Cover is *not* different. It is THE standard.

[...]


> If you think that $250 for a download is horrible then I
> agree completely: I find offensive even the "mere" $18
> that ANSI wants for its version.

http://www.jamesd.demon.co.uk/csc/faq.html#B4


fres

James Kanze

unread,
Feb 21, 2003, 5:02:00 AM2/21/03
to
agr...@tin.it (Andrea Griffini) wrote in message
news:<3e547a95...@news.tin.it>...

> And the ANSI document is not the official standard. Don't tell me just
> the cover is different, it either is THE standard or is not THE
> standard.

I'm pretty sure that the ANSI document IS the official standard. That
is, the ANSI document defines the ANSI standard, and ANSI has legislated
that the ANSI standard is the ISO standard. (That's how it works in
France or Germany, at any rate.)

Are the paperback edition and the hardcover edition of a book different
works?

> I don't expect the differences between THE standard and the last
> public draft being that many either.

There will be difference, however. Both in technical content and in
wording. There are no such differences between the ANSI standard and
the ISO standard.

--
James Kanze mailto:jka...@caicheuvreux.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung

Randy Maddox

unread,
Feb 21, 2003, 5:06:36 AM2/21/03
to
agr...@tin.it (Andrea Griffini) wrote in message news:<3e547a95...@news.tin.it>...

> On 19 Feb 2003 19:04:39 -0500, rma...@isicns.com (Randy Maddox)
> wrote:
>
> >Sorry, but this statement is not accurate at all. The US $18 version
> >of the standard is a downloadable .pdf file, while the US $250 version
> >of the standard is a printed document. The content of both versions
> >is identically the very same Holy Standard as blessed by ISO and IEC.
>
> I was talking about this:
>
> http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=25845&ICS1=35&ICS2=60&ICS3=

Yes, and following that link takes me to a page that clearly describes
two different physical packages of the exact same ISO/IEC document,
i.e., THE C++ Standard. The first is clearly indicated to be "pdf
version" while the second is clearly indicated to be a "paper
version", but they are indeed exactly the same document.

>
> that to me looks like $250 for a download (or a printed version,
> no price difference). What are you talking about ?
> The only real good thing about the official standard is IMO
> that it is the official standard. And the ANSI document is
> not the official standard. Don't tell me just the cover is
> different, it either is THE standard or is not THE standard.
> I don't expect the differences between THE standard and the
> last public draft being that many either.

Sorry, but you are simply incorrect here. Either the pdf file or the
printed document are THE officially blessed ISO/IEC C++ standard. The
cover, and the content, is no different, only the distribution media.

>
> If you think that $250 for a download is horrible then I
> agree completely: I find offensive even the "mere" $18
> that ANSI wants for its version.

While US $250 does seem a bit high for a printed version I really have
no idea what ANSI's cost basis for printing this large document is.
If they simply print, bind and deliver to order, then that might
actually be reasonable. I don't know.

However, US $18 to download the pdf file does seem very reasonable to
me. After all, somebody has to pay to support standards
organizations, and the web site through which it is downloaded is not
developed, hosted and kept up to date for free. Either the government
could pay that cost with taxpayers money, thereby forcing even those
with no interest in a particular standard to pay its distribution
costs, or those individuals who are interested in a particular
standard can pay the costs directly, which is a heck of a lot more
efficient.

There is no such thing as a free lunch. The C++ Standard is a useful
document for many C++ developers and I personally have no difficulty
with paying a small fee to be able to access the results of a
tremendous amount of very difficult work that was done by the C++
Committee (and many others) to produce this standard. The
cost-benefit ratio here seems low enough to justify my purhcase of the
downloaded pdf file. Please do note too that you can also download
the Acrobat Reader to view the pdf file for free, nada, zip from
adobe.com so that the US $18 is your only cost.

I am sorry that you are for some unknown to me reason laboring under a
misconception about this, but I most sincerely hope that your
confusion does not cause others to miss out on getting a copy of the
standard. And I do hope that you will check around to confirm that
what I am telling you is in fact correct so that you too can get your
own copy. It's a handy document to have around.

BTW, you may also be able to obtain a copy of THE standard from your
own local national standards body if giving US $18 to ANSI is simply
too abhorrent for you. Shopping locally is a good thing. Remember:
If you leave the 'hood to shop, the shops may leave the 'hood. :-)

Randy.

Early Ehlinger

unread,
Feb 21, 2003, 12:14:59 PM2/21/03
to
"Andrea Griffini" <agr...@tin.it> wrote:
> I was talking about this:
>
>
http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=2
5845
&ICS1=35&ICS2=60&ICS3=
>
> And the ANSI document is
> not the official standard. Don't tell me just the cover is
> different, it either is THE standard or is not THE standard.
> I don't expect the differences between THE standard and the
> last public draft being that many either.

I hate to break it to you, but that is the sole difference. ANSI
prepends
their cover onto the ISO standard, in effect saying, "We, the American
National Standards Institute, hereby adopt the ISO standard,
word-for-word,
as our own." This is common practice in the standards industry.
Building
standards groups do this all the time, for example.

> If you think that $250 for a download is horrible then I
> agree completely: I find offensive even the "mere" $18
> that ANSI wants for its version.

Why would you find this offensive? The cheapest cover price I've seen
for a
C++ book is in the neighborhood of $25, and it was plagued with
innacuracies
with respect to the language. To be able to download the real thing for
$18
is a steal. It's searchable (unlike a paper version) and you can print
it
out to read on the sofa.

> More important is to know what real compilers
> do, and on what areas real compilers do no agree.
> For that, for dreaming about having them to converge and
> for whishes or rants about the language itself IMO the
> cover page is not that essential, and the last public
> draft is more than adequate.

What you're missing is that the compiler vendors are trying to make
their
compilers converge on the Standard - every one of them, even *gasp*
Microsoft. If you're working toward the last public draft, then you are
not
converging with everybody else. It may never make a difference, but
then
again, Mr Murphy is always lurking around the corner.

In the meantime, and indeed in all likelihood for all eternity (will the
compiler vendors ever get it totally right?), you will need to know how
the
compilers you use diverge from the Standard. But you cannot know that
unless you know what the standard is. And you cannot know what the
standard
is if you only have a facsimile thereof.

--
-- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697 --
- RenderFarm - Lightwave , 3dSMax , Bryce , Maya , AfterEffects -
--- www.respower.com -- 400+ GHz Starting At USD$0.50/GHz*Hour --
----------------- SuperComputing For the Masses! ----------------
"I'm so busy programming my computer to let me be lazy, I never
get any rest!" - John Kaster

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

witoldk

unread,
Feb 22, 2003, 8:33:29 AM2/22/03
to
"Early Ehlinger" <ea...@respower.com> wrote in message news:<v4qpd0g...@corp.supernews.com>...

> "witoldk" <wit...@optonline.net> wrote
> > What I was trying to do is express my disbelief in the standard
> > introducing yet another way for perfectly legal programs to print
> > different
> > results and be right (true, it took me five years to notice :)
> > It seems to have been done in the name of efficiency.
> > Just like allowing evaluation order to be unspecified. There seems to be
> > difference though this time around. The difference seems to be that
> > nowadays iron is cheap. Few yaers ago I've seen a project aimed at
> > squeezing some time out of the nightly batch cycle. It took half a year
> > to squeeze some half hour. Soon after, some $$ were poured on the iron
> > and
> > that squeezed 1 and 1/2 hours from the cycle elsewhere. It was a
> > "routine"
> > upgrade.
>
> Methinks you miss the point.
>
> Yes, we're all constantly amazed at how fast and cheap computers are "now"
> as opposed to "before." However, they still aren't "fast enough," and
> because of the problem domain I work in (and I'm guessing this applies to
> the domains that quite a few others work in), they never will be.
[snip]

For no less than two seconds methought thee were after Navier-Stokes.

> --
> -- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697 --
> - RenderFarm - Lightwave , 3dSMax , Bryce , Maya , AfterEffects -
> --- www.respower.com -- 400+ GHz Starting At USD$0.50/GHz*Hour --
> ----------------- SuperComputing For the Masses! ----------------

But that was only for so long :)

Andrea Griffini

unread,
Feb 22, 2003, 3:27:07 PM2/22/03
to
On 21 Feb 2003 05:06:36 -0500, rma...@isicns.com (Randy Maddox)
wrote:

>Yes, and following that link takes me to a page that clearly describes


>two different physical packages of the exact same ISO/IEC document,
>i.e., THE C++ Standard. The first is clearly indicated to be "pdf
>version" while the second is clearly indicated to be a "paper
>version", but they are indeed exactly the same document.

And they cost exactly the same amount... That's around $250

>Sorry, but you are simply incorrect here. Either the pdf file or the
>printed document are THE officially blessed ISO/IEC C++ standard. The
>cover, and the content, is no different, only the distribution media.

I've no idea if you're serious or just joking. I see no
smileys so I'll suppose you're serious and I'll accuse
once again my english for this misunderstanding.
Le me retry... the two different documents I was talking
about are not the two listed in the page that link sent
you, but the ISO *download* and the ANSI *download*.
One is $250, the other is $18 and I was told that the
only difference is a cover page.

>> If you think that $250 for a download is horrible then I
>> agree completely: I find offensive even the "mere" $18
>> that ANSI wants for its version.
>
>While US $250 does seem a bit high for a printed version
>I really have no idea what ANSI's cost basis for printing
>this large document is.
>If they simply print, bind and deliver to order, then that
>might actually be reasonable. I don't know.

I've read somewhere that ANSI sells a printed copy for
about $125. Run, don't walk, to get your copy... it's
a bargain :-) ... you can resell them to people that
is interested in ISO standard; for one they normally
pay twice the money ;)

>However, US $18 to download the pdf file does seem very
>reasonable to me. After all, somebody has to pay to
>support standards organizations

I've been working in a project where there were a couple
of standard organizations involved. I'm not sure if this
is the same all over the world... but did you know that
(as far as I know):

1) Standards are edited for free by volunteers;
the individuals can be paid by companies for
partecipating, but the standard organization
doesn't pay a dime to people directly involved.

2) There is no support for logistic or other need
of a group. Standard organizations do not pay
for meetings or other events. If there are
expenses then those are on sponsors.

3) Big companies normally do not buy standards one
document at a time... they normally just sign a
subscription to whole sets of standard documents
either they're going to use or read them or not.
That sort of thing costs *serious* money.
There are companies that pay standard organizations
in the six digits range per year just for that
(that is, excluding paying people involved in
committees and supporting meetings).

>and the web site through which it is downloaded is not
>developed, hosted and kept up to date for free.

You must be kidding. The cost of publishing a document
on the internet is zero if you accept ads.
I actually found this ludicrous, but the ISO page has
banners too :-) ... looks like they need more money.
Finding someone hosting the C++ standard document
shouldn't be such a problem, IMO.

Note that I'm not talking about other documents, like
specifications for processes way more intricate,
specialized and obscure. I don't think many care how
much does it cost a standard on how to use a
multimillion instrument.

>Either the government could pay that cost with
>taxpayers money, thereby forcing even those with
>no interest in a particular standard to pay its
>distribution costs, or those individuals who are
>interested in a particular standard can pay the
>costs directly, which is a heck of a lot more
>efficient.

Both ISO and ANSI are no profit, I suppose, But this
doesn't really mean anything. Get a billion and spend
that billion in big cars and leather chairs and
et-voila, you're no profit too.
After long I decided to pay something for my preferred
text editor (that's charityware) and I was quite happy
to see that the money not only goes to a no profit
organization, but that less than 1% is the part wasted
in the pipes. My impression is that this percentage
is really different for standard organizations... in
my eyes they're almost just a big mess of pipes.

I'm not contrary if big companies wanna throw fluid
in there (or if they actually NEED to, so that there
is a smaller risk that a new standard puts them out
of the game). I find offensive that they want money
from me too.

>There is no such thing as a free lunch.

Wow. That's a nice line. Ever thought about going
into the fortune cookie businness ? :-)

>The C++ Standard is a useful document for many C++
>developers and I personally have no difficulty
>with paying a small fee to be able to access the
>results of a tremendous amount of very difficult
>work that was done by the C++ Committee (and many
>others) to produce this standard.

None (nada, zip) of that money goes to who produced
the document. Looks like there's some spilling in
the plumbing.

>The cost-benefit ratio here seems low enough to
>justify my purhcase of the downloaded pdf file.

That's the same for a robbery. The cost/benefit ratio
is high even when someone handling a knife is swearing
at you in a dark alley. I can stay away from that,
I'll leave this true bargain to who likes it.

>Please do note too that you can also download
>the Acrobat Reader to view the pdf file for free,
>nada, zip from adobe.com so that the US $18 is
>your only cost.

I've read on a fortune cookie that there's no free
lunch... probably Adobe is an exception.

>BTW, you may also be able to obtain a copy of THE standard from your
>own local national standards body if giving US $18 to ANSI is simply
>too abhorrent for you. Shopping locally is a good thing. Remember:
>If you leave the 'hood to shop, the shops may leave the 'hood. :-)

Wow. Another one. You're a goldmine :-)

Andrea

Alexander Terekhov

unread,
Feb 22, 2003, 9:31:09 PM2/22/03
to

Francis Glassborow

unread,
Feb 22, 2003, 9:35:13 PM2/22/03
to
In message <3e571e9...@news.tin.it>, Andrea Griffini
<agr...@tin.it> writes

>I've read somewhere that ANSI sells a printed copy for
>about $125. Run, don't walk, to get your copy... it's
>a bargain :-) ... you can resell them to people that
>is interested in ISO standard; for one they normally
>pay twice the money ;)

But only if you need one in the near future. I hope to be in a position
to announce publication dates for both the C and C++ standards in book
form before the end of the ACCU Spring Conference. They will cost
substantially less than $125. (target prices are about $50)


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow ACCU

LLeweLLyn

unread,
Feb 23, 2003, 5:38:00 AM2/23/03
to
Francis Glassborow <francis.g...@ntlworld.com> writes:

> In message <3e571e9...@news.tin.it>, Andrea Griffini
> <agr...@tin.it> writes
> >I've read somewhere that ANSI sells a printed copy for
> >about $125. Run, don't walk, to get your copy... it's
> >a bargain :-) ... you can resell them to people that
> >is interested in ISO standard; for one they normally
> >pay twice the money ;)
>
> But only if you need one in the near future. I hope to be in a position
> to announce publication dates for both the C and C++ standards in book
> form before the end of the ACCU Spring Conference. They will cost
> substantially less than $125. (target prices are about $50)

Annotated? Where do I pre-order?

{No, and I will post details when I have publication dates etc.
-mod/fwg}

Randy Maddox

unread,
Feb 24, 2003, 3:34:16 PM2/24/03
to
agr...@tin.it (Andrea Griffini) wrote in message news:<3e571e9...@news.tin.it>...

[large snip]

Andrea, if you will follow the two links very kindly provided by
Kresimir Fresl in his post to this thread I believe that you will find
exactly the information you are looking for. Hope you find that
helpful since you apparently have not been aided by my attempts to
provide you the same. To make this as easy as possible I have copied
those links here for your convenience.

http://www.jamesd.demon.co.uk/csc/faq.html#B1

http://www.jamesd.demon.co.uk/csc/faq.html#B4


Randy.

Reply all
Reply to author
Forward
0 new messages