#### Archived

This topic is now archived and is closed to further replies.

# How to pronounce C++

This topic is 5340 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

By expression I meant the entire expression, not just the increment part.

Pete

##### Share on other sites
quote:
Original post by Peter Vidler
By expression I meant the entire expression, not just the increment part.

The same problems apply.

##### Share on other sites
quote:
Original post by SabreMan
The same problems apply.

For me, the key argument here is whether the increment takes place before or after the rest of the expression (err.. I mean in the normal place -- the same place as preincrement would occur, or after everything else).

You have said that this order is unspecified (presumably you mean it's implementation dependent).. I would argue that this is not the case. From the standard:

quote:
C++ standard 5.2.6/1
The value obtained by applying a postfix ++ is the value that the operand had before applying the operator. (Note: the value obtained is a copy of the original value) The operand shall be a modifiable lvalue.

If the value must be a copy of the original value then surely the operation takes place before (in the same place a preincrement operation would take place)?

When I mentioned exceptions I didn't mean from within the increment operator, just within expressions that ++ was used (a single expression can contain many function calls, both explicit and implicit).

Pete, thinking he's gone just a little too far

[edited by - Peter Vidler on July 9, 2003 7:20:55 AM]

##### Share on other sites
Syntax error...

C wasnt defined above...
So one cannot write C++ unless C was defined..
Also, C++ is missing a end ;

##### Share on other sites
quote:

If the value must be a copy of the original value then surely the operation takes place before (in the same place a preincrement operation would take place)?

But surely, you do agree that ++variable and variable++ are not the same thing?

result = ++variable || result = variable++

'variable' is the same in both cases after the instruction is complete, 'result' is not.

It shouldn't matter how exactly the compiler does this internaly, as long as you know what you're doing, and what 'variable's value will be when you use it.

result = variable+++ ++variable;

[edited by - Wildfire on July 9, 2003 8:00:33 AM]

##### Share on other sites
quote:
Original post by Wildfire
But surely, you do agree that ++variable and variable++ are not the same thing?

Of course they aren't. All I'm saying is that the increment in variable++ happens at the same time as in ++variable. The only difference is that a temporary is returned instead of using variable itself (most programmers implement postfix operator++ in terms of the prefix one, by simply copying to a temp variable before calling the prefix operator).

Two side-effects of this:

1) Temporary variable means copying which is inefficient for this operation, especially in situations where prefix increment could work as well. This is compounded by the fact that postfix increment can often be found in loops.

2) If the current expression is interrupted the increment will already have taken place (err.. depending on where it is interrupted of course). The following two are NOT the same:

some_func(i++);andsome_func(i);i++;

All this is just as true for built in types like int as it is for user defined types.

Pete

[edited by - Peter Vidler on July 9, 2003 8:46:20 AM]

INC C

##### Share on other sites
Somehow, I think we''re looking into this a little much. Well not me, you people.

##### Share on other sites
it must be
see equals see plus one (C=C+1)
:D
or
incremented C
or
decremented C+++ (or decremented C#)
even , decremented VC++
))))

##### Share on other sites
quote:
Original post by Peter Vidler
For me, the key argument here is whether the increment takes place before or after the rest of the expression (err.. I mean in the normal place -- the same place as preincrement would occur, or after everything else).

You have said that this order is unspecified (presumably you mean it''s implementation dependent).. I would argue that this is not the case. From the standard:

quote:
C++ standard 5.2.6/1
The value obtained by applying a postfix ++ is the value that the operand had before applying the operator. (Note: the value obtained is a copy of the original value) The operand shall be a modifiable lvalue.

If the value must be a copy of the original value then surely the operation takes place before (in the same place a preincrement operation would take place)?

Nope. The above passage does not specify an order of evaluation. Surely you can think of more than one way to generate code for a postfix increment which satisfies the specified constraints?

##### Share on other sites
i think they call it postcrementing

C++ <-- PostCrement
++C <-- PreCrement

derived from increment incase you cant figure it out

A GOOD friend will come bail you out of jail...
but, a TRUE friend will be sitting next to you saying, "Damn, we fucked up."
Ingite 3D Game Engine Home -- Just click it

##### Share on other sites
quote:
Original post by SabreMan
Nope. The above passage does not specify an order of evaluation. Surely you can think of more than one way to generate code for a postfix increment which satisfies the specified constraints?

Of course I can -- but if the addition comes after the rest of the expression why would a copy be needed? Surely if this was the case the original variable could just be used, then added to.

The standard states that if the expression assigns to the variable in the same statement as the increment the outcome is undefined. To me this means that while an implementation could use the copy and still do the increment after the expression there would be no point. The only point in making a copy is so you can increment at that time (instead of later).

Besides lets not forget that the increment is an operator, equivalent to a function call even for built-in types (i.e. they behave the same), so the entire operation should be carried out in one step (not separately like copying and then incrementing later).

Pete

##### Share on other sites
quote:
Original post by Peter Vidler
Of course I can -- but if the addition comes after the rest of the expression why would a copy be needed?

Because it will have the wrong value otherwise! I suspect you are confused about the word copy'. Take this example...
int x = y++;  

Can be equivalent to...
int x = y;++y;  

In the above, the value of x is a copy of the value that was held in y prior to the increment. Now do you understand the meaning of the Standard passage you quoted?
quote:

The standard states that if the expression assigns to the variable in the same statement as the increment the outcome is undefined. To me this means that while an implementation could use the copy and still do the increment after the expression there would be no point. The only point in making a copy is so you can increment at that time (instead of later).

You are scrabbling around for evidence to support your misunderstanding. Specifying the above as undefined behaviour does not in any way support your reasoning, it is a result of undefined order of evaluation of side-effects.

[edited by - SabreMan on July 10, 2003 8:28:07 AM]

##### Share on other sites
quote:
Original post by SabreMan
Because it will have the wrong value otherwise! I suspect you are confused about the word copy'. Take this example...
int x = y++;

Can be equivalent to...
int x = y;++y;

That's a different case. The part of the standard I quoted specified that a copy of the original value is returned from the post-increment operation. Consider:
a[i++] = 5;

Which would be equivalent to this by my understanding of the standard:
int temp = y;++y; // <-- could be later, as I mentioned earliera[temp] = 5;// As I said before, if no copy is needed:a[y] = 5;++y; // <-- if add takes place after then there is no need of a copy (temporary)

..and it will not have the wrong value. Since a copy is required (mentioned in the standard passage that I quoted) I assumed it is because the first method is intended. The copy in your examples is explicit -- I am talking about a temporary being created.

If the standard is followed (as I read it) your first example ("int x = y++") would contain two copies, like so:
int temp = y;++y; // <-- could be later, but if so why have temp?int x = temp;

I realise this does not happen in practice.. most good compilers will recognise there is no need for the temporary and not use it (I have tried it with msvc), but to me this is what the standard indicates.

The use of the word "copy" in the standard is referring to post-increment only -- not any assignment (obviously assignment requires a copy).
quote:

In the above, the value of x is a copy of the value that was held in y prior to the increment. Now do you understand the meaning of the Standard passage you quoted?

I understood it from the beginning.. and have I said something to offend you? If so I apologise.

quote:
You are scrabbling around for evidence to support your misunderstanding. Specifying the above as undefined behaviour does not in any way support your reasoning, it is a result of undefined order of evaluation of side-effects.

It is the only case I could think of where a temporary (copy) of the variable would be required even if the increment was performed after everything else. If this behaviour had been defined.. since it's not I can see no reason for the copy (unless as I stated the increment is intended to take place at the same time as the copy). That is why specified the behaviour as undefined.

Pete, hoping that clears up my opinion

[edited by - Peter Vidler on July 10, 2003 4:46:08 PM]

##### Share on other sites
quote:
Original post by Peter Vidler
int temp = y;++y; // <-- could be later, as I mentioned earliera[temp] = 5;// As I said before, if no copy is needed:a[y] = 5;++y; // <-- if add takes place after then there is no need of a copy (temporary)

This is where your misunderstanding lies. In the passage we are discussing the mention of the word copy'' is non-normative. You are taking it to mean that a C++ copy must be performed.
quote:

Since a copy is required [...]

A (C++) copy isn''t required. What is required is that the final value of the expression be equal to the value of the variable before post-increment was applied (the return value is a copy'' of the original value). There is sufficient room for interpretation that a temporary can be omitted, as long as the observable behaviour is kept intact.
quote:

quote:

Now do you understand the meaning of the Standard passage you quoted?

I understood it from the beginning..

I''m convinced that you are confused about the word copy''.
quote:

and have I said something to offend you?

No, what part of my post makes you think that?

##### Share on other sites
quote:

This is where your misunderstanding lies. In the passage we are discussing the mention of the word copy' is non-normative. You are taking it to mean that a C++ copy must be performed.

Ah... now I see what you are saying. Yeah I have to concede the point (for built-in types), but for user-defined types you must admit that copy refers to a literal copy (if only because it all happens in one function which returns by value). I just took the use of the copying to mean that it would be the same for the builtins.

quote:

No, what part of my post makes you think that?

The scrabbling around for evidence came across a little harsh.

Pete, now understanding things more clearly

[edited by - Peter Vidler on July 11, 2003 8:14:16 AM]

##### Share on other sites
I think it''s to do with what processor you''re running the compiler on:

If C++ is run on a 6502 for example it would be called:

ORG C = $FF ORG$C000
LDA (\$FF)
INC A