bad_alloc

Thanks laserlight!


Great reply. :-)

Two more comments,

1.

Quote:

---

Originally Posted by laserlight

Generally, "amortize" means to reduce to some lower value in the long run. In this context, robatino was trying to emphasize that in the long run, the overhead of a single vector is spread out over the many logical partitions that make up the small arrays needed. If multiple vectors was used instead, each vector would have its own container overhead.

---

I can understand the overhead of maintaining multiple container compared with one container. But I am not sure what do you mean "some lower value"? Confused. What are the so called lower value do you mean? :-)

2.

Quote:

---

Originally Posted by laserlight

As CornedBee pointed out, v[0] accesses an element that does not exist (since at that point the vector is empty). This results in undefined behaviour.

---

I can understand that accessing v[0] is undefined behavior since v[0] does not exist for an empty vector.

What do you understand is why as you guys mentioned before "triggers undefined behavior even if p is not dereferenced" in the following code segment. I think it should be ok (not undefined behavior) if p is not dereferenced. :-)

Please feel free to correct me if I am wrong. :-)

Code:

---

std::vector<T> v;
T *p = &v[0];

---

have a good weekend,
George

Quote:

---

I can understand the overhead of maintaining multiple container compared with one container. But I am not sure what do you mean "some lower value"? Confused. What are the so called lower value do you mean? :-)

---

In this case, zero, or perhaps "nothing".

Quote:

---

What do you understand is why as you guys mentioned before "triggers undefined behavior even if p is not dereferenced" in the following code segment. I think it should be ok (not undefined behavior) if p is not dereferenced. :-)

---

p does not matter at all, since the undefined behaviour lies with v[0].

Thanks laserlight,


You mean in the following code, using p is ok but using *p is not ok? :-)

Code:

---

std::vector<T> v;
T *p = &v[0];

---

Quote:

---

Originally Posted by laserlight

p does not matter at all, since the undefined behaviour lies with v[0].

---

regards,
George

Quote:

---

You mean in the following code, using p is ok but using *p is not ok? :-)

---

You have been told multiple times: that piece of code is simply wrong.

Sorry laserlight,


What makes me confused before is your point and robatino's point are different.

1.

This is what robatino mentioend, seems using p and *p (dereferencing) are both incorrect.

Quote:

---

Originally Posted by robatino

Code:

---

std::vector<T> v;
T *p = &v[0];

---

triggers undefined behavior even if p is not dereferenced.

---

2.

This is what you mentioned before, seems you mean using p is ok, but using *p is not ok.

Quote:

---

Originally Posted by laserlight

p does not matter at all

---

Hope I clarifies what makes me confused before. :-)

Quote:

---

Originally Posted by laserlight

You have been told multiple times: that piece of code is simply wrong.

---

regards,
George

Quote:

---

This is what you mentioned before, seems you mean using p is ok, but using *p is not ok.

---

Basically, this is a question of emphasis. Let's change the code to:

Code:

---

T *p = 0;

---

So now, using p is indeed okay, but using *p is not okay.

But what are we to make of:

Code:

---

std::vector<T> v;
T *p = &v[0];

---

We could say that using p and *p is both not okay, or we could relate it to my example above and say that using p is okay but *p is not okay, but that's besides the point. The point is that &v[0] is not okay, so whether using p is okay or using *p is okay does not matter any more.

Thanks laserlight,


I think my question is answered. Thanks again for your patience. :-)

Let me do a brief summarize. I think the code,

Code:

---

T *p = 0;

---

is ok because of p points to valid address (even NULL address), so using p is ok.

But for the code,

Code:

---

std::vector<T> v;
T *p = &v[0];

---

it is not ok since &v[0] is not valid (no elements, including 1st element exists in vector v), and p is pointing to an invalid address &v[0], using p is not valid, and using *P is even not valid. :-)

My summary correct?

Quote:

---

Originally Posted by laserlight

Basically, this is a question of emphasis. Let's change the code to:

Code:

---

T *p = 0;

---

So now, using p is indeed okay, but using *p is not okay.

But what are we to make of:

Code:

---

std::vector<T> v;
T *p = &v[0];

---

We could say that using p and *p is both not okay, or we could relate it to my example above and say that using p is okay but *p is not okay, but that's besides the point. The point is that &v[0] is not okay, so whether using p is okay or using *p is okay does not matter any more.

---

regards,
George

Since the expression v[0] itself triggers undefined behavior (which I should have realized originally), anything the program does after that is irrelevant - the program could crash before it even gets a chance to try evaluating &v[0], much less assigning it to p.

Thanks for your clarification, robatino!

Quote:

---

Originally Posted by robatino

Since the expression v[0] itself triggers undefined behavior (which I should have realized originally), anything the program does after that is irrelevant - the program could crash before it even gets a chance to try evaluating &v[0], much less assigning it to p.

---

regards,
George

Quote:

---

Originally Posted by robatino

Since the expression v[0] itself triggers undefined behavior (which I should have realized originally), anything the program does after that is irrelevant - the program could crash before it even gets a chance to try evaluating &v[0], much less assigning it to p.

---

The evaluation of &v[0] does not involve evaluating v[0].

Yes, it does. Especially for an overloaded [].

In practice, it does not for built-in pointer []. However, in standard theory it does, and thus the program behaviour is undefined, because whatever optimizations the compiler makes, the program must still adhere to the standard.

Why brewbuck?


Any more description of the internal process of evaluation of &v[0] and evaluation of v[0], so that we can see your points of the different process. :-)

Quote:

---

Originally Posted by brewbuck

The evaluation of &v[0] does not involve evaluating v[0].

---

regards,
George

Quote:

---

Originally Posted by CornedBee

Yes, it does. Especially for an overloaded [].

---

Even in that case, operator[] returns a reference, not a value, which still doesn't involve actually evaluating anything. I understand the standard says it's undefined.

It is not the case that all sub-expressions of an expression must have defined values. If that were the case, the following program would be undefined:

Code:

---

void clear_integer(int *x)
{
    *x = 0;
}

int main()
{
    int x;

    clear_integer(&x);
    return 0;
}

---

I don't think anybody will dispute the validity of this code. But 'x' does appear as a subexpression in the call to clear_integer(). At the time of the call, it is uninitialized. The "evaluation" of this uninitialized value should trigger undefined behavior according to the above, but I think we all agree that it doesn't. What gets passed is the address of x, not the contents of x.

Quote:

---

The "evaluation" of this uninitialized value should trigger undefined behavior according to the above, but I think we all agree that it doesn't. What gets passed is the address of x, not the contents of x.

---

Only one operator is at work here: the address of operator&. But two operators are at work for &v[0].

Quote:

---

Originally Posted by laserlight

Only one operator is at work here: the address of operator&. But two operators are at work for &v[0].

---

Yes, but the argument was that because v[0] is an undefined subexpression of &v[0] that therefore the entire expression &v[0] is undefined.

In my example, x is an uninitialized subexpression of &x and therefore... The entire expression &x is undefined? So this means we can't take the address of uninitialized variables?

Honestly I'm not sure exactly what the standard claims here.