contradiction in TC++PL?

[ES Kim]

Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial element
is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I think
contradict the statement in the excerpt. What do you think?

--
ES Kim

[BekTek]

Hi~
It's good to see you, you Korean right? me either..

Anyway,

"The result of taking the address of the element before the initial element is undefined and should be avoided." The author says, as I understand, it's ok with ++p after p--, which I think contradict the statement in the excerpt. What do you think?
Both clauses are right IMHO.
p-- actually returns the fist element's reference even though it decreaments
internal pointer..
It's because that's posfix..
So in this case, there in no way to access the element before the zeroth
element..

And then '++p' makes the pointer point to the zeroth element.. T v[200];
T* p = &v[0];
p--; // please note (my comment)
++p;
So then, the code above is not dangerous..

Is that your questions?
:)

"ES Kim" <[e-mail] > wrote in message
news:cl******** **@news1.kornet .net... Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial element is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I think contradict the statement in the excerpt. What do you think?

--
ES Kim

[ES Kim]

"BekTek" <be****@gmail.c om> wrote in message
news:h8_cd.2969 $7d7.1176@trndd c04...

Hi~
It's good to see you, you Korean right? me either..
Yes, I'm a Korean. Nice to see you.

Anyway,

"The result of taking the address of the element before the initial

element

is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I

think

contradict the statement in the excerpt. What do you think?

Both clauses are right IMHO.
p-- actually returns the fist element's reference even though it decreaments
internal pointer..
It's because that's posfix..
So in this case, there in no way to access the element before the zeroth
element..

And then '++p' makes the pointer point to the zeroth element..

I'm not sure what you mean by 'internal pointer'.
There's no difference between postfix and prefix form in this context.
The expression p-- is evaluated as a pointer to the initial element,
but it also has a side effect, which makes p point to the address before
the initial element.

--
ES Kim

[Alf P. Steinbach]

* ES Kim:

Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial element
is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I think
contradict the statement in the excerpt. What do you think?

According to Google it's not in the errata list.

Executing those statements in sequence is definitely Undefined Behavior,
and in particular the increment can not "fix" the earlier invoked UB.

Mail Bjarne and get the $30 prize money (or whatever the amount is... ;-)).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ioannis Vranos]

ES Kim wrote:

Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial element
is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I think
contradict the statement in the excerpt. What do you think?

p--; produces undefined behaviour since it points to an invalid element.
This is allowed only for one past the end element of a sequence.

++p; reincrements the pointer and points to the first element. In this
place, p is again pointing to a valid element and in this state it is
well defined.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Alf P. Steinbach wrote:

* ES Kim:

Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial element
is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I think
contradict the statement in the excerpt. What do you think?

According to Google it's not in the errata list.

Executing those statements in sequence is definitely Undefined Behavior,
and in particular the increment can not "fix" the earlier invoked UB.

Mail Bjarne and get the $30 prize money (or whatever the amount is... ;-)).

Actually there is not any book error, since it is stated that undefined
behaviour is invoked.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Alf P. Steinbach]

* Ioannis Vranos:

ES Kim wrote:

Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial element
is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I think
contradict the statement in the excerpt. What do you think?

p--; produces undefined behaviour since it points to an invalid element.
This is allowed only for one past the end element of a sequence.

++p; reincrements the pointer and points to the first element. In this
place, p is again pointing to a valid element and in this state it is
well defined.

That is incorrect.

The result of the decrement is UB.

The result of incrementing that result is UB, not a "reincremen t".

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alf P. Steinbach]

* Ioannis Vranos:

Alf P. Steinbach wrote:

* ES Kim:

Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial element
is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I think
contradict the statement in the excerpt. What do you think?

According to Google it's not in the errata list.

Executing those statements in sequence is definitely Undefined Behavior,
and in particular the increment can not "fix" the earlier invoked UB.

Mail Bjarne and get the $30 prize money (or whatever the amount is... ;-)).

Actually there is not any book error, since it is stated that undefined
behaviour is invoked.

I'm assuming the "ok" comment is from the book.

If so then this is an error.

See reply to your other response.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[ES Kim]

"Ioannis Vranos" <iv*@guesswh.at .grad.com> wrote in message
news:1098154188 .513463@athnrd0 2...

ES Kim wrote:

Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial element
is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--, which I think
contradict the statement in the excerpt. What do you think?

p--; produces undefined behaviour since it points to an invalid element.
This is allowed only for one past the end element of a sequence.

++p; reincrements the pointer and points to the first element. In this
place, p is again pointing to a valid element and in this state it is
well defined.

There's no guarantee that "p is again pointing to a valid element".
Even one UB will make every following well-defined statements undefined.

--
ES Kim

[E. Robert Tisdale]

ES Kim wrote:

Here's a code fragment from TC++PL Special Edition, p291:

void f1(T a)
{
T v[200];
T* p = &v[0];
p--; // please note (my comment)
*p = a; // oops: 'p' out of range, uncaught
++p;
*p = a; // ok
}

And here's an excerpt from p92:

"The result of taking the address of the element before the initial element
is undefined and should be avoided."

The author says, as I understand, it's ok with ++p after p--,
which I think contradict the statement in the excerpt. What do you think?

Correct. It's a bad example. A better example might be:

void f1(T a) {
T v[200];
T* p = &v[0];
*p = a; // ok
p--; // undefined but works everywhere
*p = a; // run-time error: 'p' out of range
++p; // still undefined but works everywhere
*p = a; // undefined but works everywhere
}