Addressing a &vector<>[i] as a C-array & the C++ standard.

[Numeromancer]

From the C++-FAQ Lite:

http://www.parashift.com/c++-faq-lit....html#faq-34.3

----------------------------
34.3] Is the storage for a std::vector<Tguaranteed to be contiguous? Yes.

This means you the following technique is safe:

#include <vector>
#include "Foo.h" /* get class Foo */

// old-style code that wants an array
void f(Foo* array, unsigned numFoos);

void g()
{
std::vector<Foov;
...
f(v.empty() ? NULL : &v[0], v.size()); � safe
}

The funny expression v.empty() ? NULL : &v[0] simply passes the NULL
pointer if v is empty, otherwise passes a pointer to the first (zeroth)
element of v. If you know a priori that v is not empty, you can change
that to simply &v[0].
----------------------------

I can find nothing in the standard to justify this statement. Does
anyone know the section in the standard (if any) which justifies this
statement?

Thanks,

Tim S.

[Gianni Mariani]

Numeromancer wrote:
....

I can find nothing in the standard to justify this statement. Does
anyone know the section in the standard (if any) which justifies this
statement?

It is somthing ratified as errata I believe. I heard the next standard
will go as far as saying that basic_string is also contiguous.

I have no concrete reference other than postings by others.

[Alan Woodland]

Numeromancer wrote:
....

// old-style code that wants an array
void f(Foo* array, unsigned numFoos);

void g()
{
std::vector<Foov;
...
f(v.empty() ? NULL : &v[0], v.size()); � safe
}

The funny expression v.empty() ? NULL : &v[0] simply passes the NULL
pointer if v is empty, otherwise passes a pointer to the first (zeroth)
element of v. If you know a priori that v is not empty, you can change
that to simply &v[0].
----------------------------

I can find nothing in the standard to justify this statement. Does
anyone know the section in the standard (if any) which justifies this
statement?

As I understand it if the vector is empty then any attempt to access any
element (in this case the first, at position 0) is passed the end of the
vector. Therefore this is undefined behaviour. This ternary operation
ensures that we never hit that situation.

Alan

[red floyd]

Gianni Mariani wrote:

Numeromancer wrote:
...

>I can find nothing in the standard to justify this statement. Does
anyone know the section in the standard (if any) which justifies this
statement?

It is somthing ratified as errata I believe. I heard the next standard
will go as far as saying that basic_string is also contiguous.

I have no concrete reference other than postings by others.

Vector is contiguous as of TC1 aka the 2003 revision.

[Numeromancer]

Numeromancer wrote:

From the C++-FAQ Lite:

http://www.parashift.com/c++-faq-lit....html#faq-34.3

----------------------------
34.3] Is the storage for a std::vector<Tguaranteed to be contiguous?
Yes.

This means you the following technique is safe:

#include <vector>
#include "Foo.h" /* get class Foo */

// old-style code that wants an array
void f(Foo* array, unsigned numFoos);

void g()
{
std::vector<Foov;
...
f(v.empty() ? NULL : &v[0], v.size()); � safe
}

The funny expression v.empty() ? NULL : &v[0] simply passes the NULL
pointer if v is empty, otherwise passes a pointer to the first (zeroth)
element of v. If you know a priori that v is not empty, you can change
that to simply &v[0].
----------------------------

I can find nothing in the standard to justify this statement. Does
anyone know the section in the standard (if any) which justifies this
statement?

Thanks,

Tim S.

Thanks to those whose pointed to the TRs, I found it. I confess: I
thought that the author of the FAQ list was being chummy, (:humble but I
was wrong). I'm glad I asked. I'll be reading over TR1 carefully
henceforth.
Tim S.

[red floyd]

Numeromancer wrote:

>The funny expression v.empty() ? NULL : &v[0] simply passes the NULL
pointer if v is empty, otherwise passes a pointer to the first
(zeroth) element of v. If you know a priori that v is not empty, you
can change that to simply &v[0].
----------------------------

I can find nothing in the standard to justify this statement. Does
anyone know the section in the standard (if any) which justifies this
statement?

Thanks,

Tim S.

Thanks to those whose pointed to the TRs, I found it. I confess: I
thought that the author of the FAQ list was being chummy, (:humble but I
was wrong). I'm glad I asked. I'll be reading over TR1 carefully
henceforth.

That's TC1 (Technical Corrigendum 1), not TR1.