Re: Using vectors as arrays

From: Leor Zolman (leor_at_bdsoft.com)
Date: 01/17/04 

Date: Sat, 17 Jan 2004 03:12:45 GMT

On Sat, 17 Jan 2004 02:52:59 -0000, "Erik Jälevik"
<erik.jalevikDELETE@ntlworldTHIS.com> wrote:

>>
>> Not sure who said what, but what you want to do is take the address of
>> the first element, _not_ the address of the vector itself:
>
>Yes, of course. Sorry, I didn't express myself clearly, that's what I meant.
>
I was being lazy; it was easier to just say it rather than look up the
other thread ;-)

>> >Is it also OK to use the individual
>> >addresses for assigning to like in the following example:
>> >
>> >vector<double> energy;
>> >energy.reserve(100);
>> >for (int j = 0; j < 100; j++) {
>> > *(&energy[j]) = res[j].GetEnergy();
>>
>> Looks "OK", but why would you choose to write this instead of plain
>> old:
>> energy[j] = res[j].GetEnergy();
>
>That works? I just assumed I couldn't do that for some silly reason. Oh
>well, thanks for pointing it out.

I'll tell ya, I had to stop for a second and make sure I wasn't saying
something stupid when I wrote that... but yes, sometimes the syntax
really is intuitive, even with the STL...

>
>> push_back will handle the case where the vector has to "grow", while
>> directly assigning will not, and will in fact yield undefined behavior
>> if you go out of bounds.
>
>Yes OK. But I will always make sure to allocate enough space with reserve
>beforehand since efficiency is quite important in my application and I never
>want the vector to grow.
>
>> Nothing can really "unpreserve" ordering in a vector; you
>> set the order and it would never second-guess you on it!
>
>OK, good. I assumed this would be the case but wasn't sure it was prescribed
>by the standard. In fact, I think the Josuttis book mentioned it wasn't
>strictly prescribed but that most compilers did it that way.

I can't imagine he'd ever have bothered to say anything about
"ordering" not being guaranteed, although he does talk about the issue
of contiguous memory (and there's a thread with that subject right
around here someplace...). Basically, go ahead and assume it is
contiguous. The Standard will bless that assumption soon enough
anyway.

Umm, the other thing I found that he says the Standard doesn't
explicitly guarantee is right at the start of the vector section: that
the vector's implementation necessarily uses a dynamic array. Well,
what the heck _else_ would it use? Perhaps they were thinking of when
Quantum Computing comes of age, some new-fangled multiverse-based
container that would not qualify as being labeled "dynamic"? Sheesh.
;-)
        -leor

>
>Erik
>

Leor Zolman
BD Software
leor@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
           Decryptor at www.bdsoft.com/tools/stlfilt.html

Relevant Pages

  • Re: cin.get() does not work if there is a previous cin?
    ... |>any wording to agree with that, ... ...but there are many things in the standard that are just ... the C++ Standard does not explicitly guarantee ... that the function try block will work on all implementations. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Does the C++ vector template class use pointer-based link lists?
    ... use contiguous memory. ... int n = some_size; ... What you really want is a comparison of the various containers, ... Dinkumware's documentation is superb (and they supply the standard ...
    (comp.lang.cpp)
  • Re: is it possible to pass C++ vectors to fortran subroutines
    ... I can't remember if this is currently a requirement, AFAIR it may go into the next standard. ... I believe it's either in the technical supplement or the next standard, and I also believe that every extant implementation of the standard library does keep the contents of a std::vector in contiguous memory. ...
    (comp.lang.fortran)