std::vector and array

Discussion in 'C++' started by mathieu, Feb 1, 2011.

  1. mathieu

    mathieu Guest

    Dear all,

    Could someone please let me know what is wrong with the following:

    #include <vector>

    int main()
    {
    typedef double (OriginType)[3];
    std::vector< OriginType > OriginArray;
    // OriginArray.reserve( 1 );
    OriginArray.resize( 1 ); // does not compile

    return 0;
    }


    this code does not compile using g++-4.4

    Thanks !
    mathieu, Feb 1, 2011
    #1
    1. Advertising

  2. mathieu

    Ian Collins Guest

    On 02/ 2/11 07:40 AM, mathieu wrote:
    > Dear all,
    >
    > Could someone please let me know what is wrong with the following:
    >
    > #include<vector>
    >
    > int main()
    > {
    > typedef double (OriginType)[3];
    > std::vector< OriginType> OriginArray;
    > // OriginArray.reserve( 1 );
    > OriginArray.resize( 1 ); // does not compile
    >
    > return 0;
    > }


    As Leigh said, you can't sore an array in a container because you can't
    assign one to another (try it!).

    But you can put an array in a struct:

    struct OriginType
    {
    double data[3];
    };

    --
    Ian Collins
    Ian Collins, Feb 1, 2011
    #2
    1. Advertising

  3. mathieu

    mathieu Guest

    On Feb 1, 8:39 pm, Ian Collins <> wrote:
    > On 02/ 2/11 07:40 AM, mathieu wrote:
    >
    > > Dear all,

    >
    > >    Could someone please let me know what is wrong with the following:

    >
    > > #include<vector>

    >
    > > int main()
    > > {
    > >    typedef double (OriginType)[3];
    > >    std::vector<  OriginType>  OriginArray;
    > >    // OriginArray.reserve( 1 );
    > >    OriginArray.resize( 1 ); // does not compile

    >
    > >    return 0;
    > > }

    >
    > As Leigh said, you can't sore an array in a container because you can't
    > assign one to another (try it!).


    Sorry I forgot the copy-constructible requirement.

    Thanks
    mathieu, Feb 1, 2011
    #3
  4. mathieu

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 01/02/2011 19:39, Ian Collins wrote:
    >> On 02/ 2/11 07:40 AM, mathieu wrote:
    >>> Dear all,
    >>>
    >>> Could someone please let me know what is wrong with the following:
    >>>
    >>> #include<vector>
    >>>
    >>> int main()
    >>> {
    >>> typedef double (OriginType)[3];
    >>> std::vector< OriginType> OriginArray;
    >>> // OriginArray.reserve( 1 );
    >>> OriginArray.resize( 1 ); // does not compile
    >>>
    >>> return 0;
    >>> }

    >>
    >> As Leigh said, you can't sore an array in a container because you can't
    >> assign one to another (try it!).
    >>
    >> But you can put an array in a struct:
    >>
    >> struct OriginType
    >> {
    >> double data[3];
    >> };
    >>

    >
    > Or alternatively use:
    >
    > typedef std::tr1::array<double, 3> OriginType;
    >
    > or possibly
    >
    > typedef std::array<double, 3> OriginType;
    >
    > depending on your compiler and if it is fairly up-to-date and includes
    > TR1.
    >
    > /Leigh
    >

    Or store a pointer to a dynamically allocated array.
    Paul, Feb 1, 2011
    #4
  5. mathieu

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 01/02/2011 22:25, Paul wrote:
    >>
    >> "Leigh Johnston" <> wrote in message
    >> news:...
    >>> On 01/02/2011 19:39, Ian Collins wrote:
    >>>> On 02/ 2/11 07:40 AM, mathieu wrote:
    >>>>> Dear all,
    >>>>>
    >>>>> Could someone please let me know what is wrong with the following:
    >>>>>
    >>>>> #include<vector>
    >>>>>
    >>>>> int main()
    >>>>> {
    >>>>> typedef double (OriginType)[3];
    >>>>> std::vector< OriginType> OriginArray;
    >>>>> // OriginArray.reserve( 1 );
    >>>>> OriginArray.resize( 1 ); // does not compile
    >>>>>
    >>>>> return 0;
    >>>>> }
    >>>>
    >>>> As Leigh said, you can't sore an array in a container because you can't
    >>>> assign one to another (try it!).
    >>>>
    >>>> But you can put an array in a struct:
    >>>>
    >>>> struct OriginType
    >>>> {
    >>>> double data[3];
    >>>> };
    >>>>
    >>>
    >>> Or alternatively use:
    >>>
    >>> typedef std::tr1::array<double, 3> OriginType;
    >>>
    >>> or possibly
    >>>
    >>> typedef std::array<double, 3> OriginType;
    >>>
    >>> depending on your compiler and if it is fairly up-to-date and includes
    >>> TR1.
    >>>
    >>> /Leigh
    >>>

    >> Or store a pointer to a dynamically allocated array.

    >
    > That would be a sub-optimal solution as it defeats the purpose of using a
    > vector in the first place but I wouldn't expect *you* to know this given
    > your past record.
    >

    I don't know what you are talking about but a pointer is probably more
    optimal than your suggested techniques.
    vector<double*> OriginArray;

    As for past records well LOL @ you.
    Paul, Feb 1, 2011
    #5
  6. mathieu

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 01/02/2011 23:23, Paul wrote:
    >>
    >> "Leigh Johnston" <> wrote in message
    >> news:...
    >>> On 01/02/2011 22:25, Paul wrote:
    >>>>
    >>>> "Leigh Johnston" <> wrote in message
    >>>> news:...
    >>>>> On 01/02/2011 19:39, Ian Collins wrote:
    >>>>>> On 02/ 2/11 07:40 AM, mathieu wrote:
    >>>>>>> Dear all,
    >>>>>>>
    >>>>>>> Could someone please let me know what is wrong with the following:
    >>>>>>>
    >>>>>>> #include<vector>
    >>>>>>>
    >>>>>>> int main()
    >>>>>>> {
    >>>>>>> typedef double (OriginType)[3];
    >>>>>>> std::vector< OriginType> OriginArray;
    >>>>>>> // OriginArray.reserve( 1 );
    >>>>>>> OriginArray.resize( 1 ); // does not compile
    >>>>>>>
    >>>>>>> return 0;
    >>>>>>> }
    >>>>>>
    >>>>>> As Leigh said, you can't sore an array in a container because you
    >>>>>> can't
    >>>>>> assign one to another (try it!).
    >>>>>>
    >>>>>> But you can put an array in a struct:
    >>>>>>
    >>>>>> struct OriginType
    >>>>>> {
    >>>>>> double data[3];
    >>>>>> };
    >>>>>>
    >>>>>
    >>>>> Or alternatively use:
    >>>>>
    >>>>> typedef std::tr1::array<double, 3> OriginType;
    >>>>>
    >>>>> or possibly
    >>>>>
    >>>>> typedef std::array<double, 3> OriginType;
    >>>>>
    >>>>> depending on your compiler and if it is fairly up-to-date and includes
    >>>>> TR1.
    >>>>>
    >>>>> /Leigh
    >>>>>
    >>>> Or store a pointer to a dynamically allocated array.
    >>>
    >>> That would be a sub-optimal solution as it defeats the purpose of
    >>> using a vector in the first place but I wouldn't expect *you* to know
    >>> this given your past record.
    >>>

    >> I don't know what you are talking about but a pointer is probably more
    >> optimal than your suggested techniques.
    >> vector<double*> OriginArray;
    >>

    >
    > As I said sub-optimal; instead of a single allocation for all elements in
    > the vector you now have one allocation for every element in the vector
    > which does not scale well; you lose the property of contiguousness which
    > is sometimes an important requirement; you now have to write extra code to
    > delete the arrays the vector elements point to to avoid memory leaks.
    >

    The memory allocation is optional , the same can be done on the stack. If he
    already has the arrays its very simple to assign the address of an array to
    a pointer stored in a vector. This is more optimal than copying each array
    into a new object.
    If he was creating it all from scratch the pointer method would also use
    less memory, thus being a more optimal solution.

    As for memory leaks, well the fact that you worry about that really just
    shows your noobness lol.
    Paul, Feb 2, 2011
    #6
  7. mathieu

    Ian Collins Guest

    On 02/ 2/11 12:29 PM, Leigh Johnston wrote:
    > On 01/02/2011 23:23, Paul wrote:
    >>>

    >> I don't know what you are talking about but a pointer is probably more
    >> optimal than your suggested techniques.
    >> vector<double*> OriginArray;
    >>

    >
    > As I said sub-optimal; instead of a single allocation for all elements
    > in the vector you now have one allocation for every element in the
    > vector which does not scale well; you lose the property of
    > contiguousness which is sometimes an important requirement; you now have
    > to write extra code to delete the arrays the vector elements point to to
    > avoid memory leaks.


    A pointer based solution may be OK if the data pointed to is static.
    But it would be useless if the requirement was for an value based container.

    --
    Ian Collins
    Ian Collins, Feb 2, 2011
    #7
  8. mathieu

    Ian Collins Guest

    On 02/ 2/11 01:20 PM, Leigh Johnston wrote:
    > On 02/02/2011 00:16, Ian Collins wrote:
    >> On 02/ 2/11 12:29 PM, Leigh Johnston wrote:
    >>>
    >>> As I said sub-optimal; instead of a single allocation for all elements
    >>> in the vector you now have one allocation for every element in the
    >>> vector which does not scale well; you lose the property of
    >>> contiguousness which is sometimes an important requirement; you now have
    >>> to write extra code to delete the arrays the vector elements point to to
    >>> avoid memory leaks.

    >>
    >> A pointer based solution may be OK if the data pointed to is static. But
    >> it would be useless if the requirement was for an value based container.
    >>

    >
    > I agree but Paul The Troll suggested "store a pointer to a dynamically
    > allocated array" which is what I was reacting to.


    Why do you persist in responding to it?

    --
    Ian Collins
    Ian Collins, Feb 2, 2011
    #8
  9. mathieu

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 02/02/2011 00:03, Paul wrote:
    >>
    >> "Leigh Johnston" <> wrote in message
    >> news:...
    >>> On 01/02/2011 23:23, Paul wrote:
    >>>>
    >>>> "Leigh Johnston" <> wrote in message
    >>>> news:...
    >>>>> On 01/02/2011 22:25, Paul wrote:
    >>>>>>
    >>>>>> "Leigh Johnston" <> wrote in message
    >>>>>> news:...
    >>>>>>> On 01/02/2011 19:39, Ian Collins wrote:
    >>>>>>>> On 02/ 2/11 07:40 AM, mathieu wrote:
    >>>>>>>>> Dear all,
    >>>>>>>>>
    >>>>>>>>> Could someone please let me know what is wrong with the following:
    >>>>>>>>>
    >>>>>>>>> #include<vector>
    >>>>>>>>>
    >>>>>>>>> int main()
    >>>>>>>>> {
    >>>>>>>>> typedef double (OriginType)[3];
    >>>>>>>>> std::vector< OriginType> OriginArray;
    >>>>>>>>> // OriginArray.reserve( 1 );
    >>>>>>>>> OriginArray.resize( 1 ); // does not compile
    >>>>>>>>>
    >>>>>>>>> return 0;
    >>>>>>>>> }
    >>>>>>>>
    >>>>>>>> As Leigh said, you can't sore an array in a container because you
    >>>>>>>> can't
    >>>>>>>> assign one to another (try it!).
    >>>>>>>>
    >>>>>>>> But you can put an array in a struct:
    >>>>>>>>
    >>>>>>>> struct OriginType
    >>>>>>>> {
    >>>>>>>> double data[3];
    >>>>>>>> };
    >>>>>>>>
    >>>>>>>
    >>>>>>> Or alternatively use:
    >>>>>>>
    >>>>>>> typedef std::tr1::array<double, 3> OriginType;
    >>>>>>>
    >>>>>>> or possibly
    >>>>>>>
    >>>>>>> typedef std::array<double, 3> OriginType;
    >>>>>>>
    >>>>>>> depending on your compiler and if it is fairly up-to-date and
    >>>>>>> includes
    >>>>>>> TR1.
    >>>>>>>
    >>>>>>> /Leigh
    >>>>>>>
    >>>>>> Or store a pointer to a dynamically allocated array.
    >>>>>
    >>>>> That would be a sub-optimal solution as it defeats the purpose of
    >>>>> using a vector in the first place but I wouldn't expect *you* to know
    >>>>> this given your past record.
    >>>>>
    >>>> I don't know what you are talking about but a pointer is probably more
    >>>> optimal than your suggested techniques.
    >>>> vector<double*> OriginArray;
    >>>>
    >>>
    >>> As I said sub-optimal; instead of a single allocation for all elements
    >>> in the vector you now have one allocation for every element in the
    >>> vector which does not scale well; you lose the property of
    >>> contiguousness which is sometimes an important requirement; you now
    >>> have to write extra code to delete the arrays the vector elements
    >>> point to to avoid memory leaks.
    >>>

    >> The memory allocation is optional , the same can be done on the stack.

    >
    > You said:
    >
    > "store a pointer to a dynamically allocated array"
    >
    > You are now moving the goal posts which is the typical behaviour of a
    > troll. There is no indication that the OP wants a stack based solution.
    >

    You said my method was sub optimal because it required allocation.
    So I simply pointed out that my pointer method can be used on the stack
    also.

    If your method was on the heap you'd still need to allocate/delete each
    array so your comparsison of the two methods was completely incomparable.
    Any goalpost shifting has been done by your attempt to make dynamic
    allocation appear sub-optimal.

    >
    >> If he already has the arrays its very simple to assign the address of an
    >> array to a pointer stored in a vector. This is more optimal than copying
    >> each array into a new object.
    >> If he was creating it all from scratch the pointer method would also use
    >> less memory, thus being a more optimal solution.

    >
    > If he is creating it from scratch "storing a pointer to a dynamically
    > allocated array" then more memory will be used not less than with the
    > solutions I suggested.
    >

    You didn't suggest a way to use dynamic allocation.

    >>
    >> As for memory leaks, well the fact that you worry about that really just
    >> shows your noobness lol.
    >>

    >
    > You have a lot to learn. Troll off.
    >

    So you say but I seem to be the one who's always teaching you new stuff.
    :)
    Paul, Feb 2, 2011
    #9
  10. mathieu

    Paul Guest

    "Ian Collins" <> wrote in message
    news:...
    > On 02/ 2/11 01:20 PM, Leigh Johnston wrote:
    >> On 02/02/2011 00:16, Ian Collins wrote:
    >>> On 02/ 2/11 12:29 PM, Leigh Johnston wrote:
    >>>>
    >>>> As I said sub-optimal; instead of a single allocation for all elements
    >>>> in the vector you now have one allocation for every element in the
    >>>> vector which does not scale well; you lose the property of
    >>>> contiguousness which is sometimes an important requirement; you now
    >>>> have
    >>>> to write extra code to delete the arrays the vector elements point to
    >>>> to
    >>>> avoid memory leaks.
    >>>
    >>> A pointer based solution may be OK if the data pointed to is static. But
    >>> it would be useless if the requirement was for an value based container.
    >>>

    >>
    >> I agree but Paul The Troll suggested "store a pointer to a dynamically
    >> allocated array" which is what I was reacting to.

    >
    > Why do you persist in responding to it?
    >

    Yes because you don't normally create arrays of arrays on the stack.
    I can't help it if I don't think in noobish like you two.
    LOL
    Paul, Feb 2, 2011
    #10
  11. mathieu

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 02/02/2011 00:58, Paul wrote:
    >>
    >> "Leigh Johnston" <> wrote in message
    >> news:...
    >>> On 02/02/2011 00:03, Paul wrote:
    >>>>
    >>>> "Leigh Johnston" <> wrote in message
    >>>> news:...
    >>>>> On 01/02/2011 23:23, Paul wrote:
    >>>>>>
    >>>>>> "Leigh Johnston" <> wrote in message
    >>>>>> news:...
    >>>>>>> On 01/02/2011 22:25, Paul wrote:
    >>>>>>>>
    >>>>>>>> "Leigh Johnston" <> wrote in message
    >>>>>>>> news:...
    >>>>>>>>> On 01/02/2011 19:39, Ian Collins wrote:
    >>>>>>>>>> On 02/ 2/11 07:40 AM, mathieu wrote:
    >>>>>>>>>>> Dear all,
    >>>>>>>>>>>
    >>>>>>>>>>> Could someone please let me know what is wrong with the
    >>>>>>>>>>> following:
    >>>>>>>>>>>
    >>>>>>>>>>> #include<vector>
    >>>>>>>>>>>
    >>>>>>>>>>> int main()
    >>>>>>>>>>> {
    >>>>>>>>>>> typedef double (OriginType)[3];
    >>>>>>>>>>> std::vector< OriginType> OriginArray;
    >>>>>>>>>>> // OriginArray.reserve( 1 );
    >>>>>>>>>>> OriginArray.resize( 1 ); // does not compile
    >>>>>>>>>>>
    >>>>>>>>>>> return 0;
    >>>>>>>>>>> }
    >>>>>>>>>>
    >>>>>>>>>> As Leigh said, you can't sore an array in a container because you
    >>>>>>>>>> can't
    >>>>>>>>>> assign one to another (try it!).
    >>>>>>>>>>
    >>>>>>>>>> But you can put an array in a struct:
    >>>>>>>>>>
    >>>>>>>>>> struct OriginType
    >>>>>>>>>> {
    >>>>>>>>>> double data[3];
    >>>>>>>>>> };
    >>>>>>>>>>
    >>>>>>>>>
    >>>>>>>>> Or alternatively use:
    >>>>>>>>>
    >>>>>>>>> typedef std::tr1::array<double, 3> OriginType;
    >>>>>>>>>
    >>>>>>>>> or possibly
    >>>>>>>>>
    >>>>>>>>> typedef std::array<double, 3> OriginType;
    >>>>>>>>>
    >>>>>>>>> depending on your compiler and if it is fairly up-to-date and
    >>>>>>>>> includes
    >>>>>>>>> TR1.
    >>>>>>>>>
    >>>>>>>>> /Leigh
    >>>>>>>>>
    >>>>>>>> Or store a pointer to a dynamically allocated array.
    >>>>>>>
    >>>>>>> That would be a sub-optimal solution as it defeats the purpose of
    >>>>>>> using a vector in the first place but I wouldn't expect *you* to
    >>>>>>> know
    >>>>>>> this given your past record.
    >>>>>>>
    >>>>>> I don't know what you are talking about but a pointer is probably
    >>>>>> more
    >>>>>> optimal than your suggested techniques.
    >>>>>> vector<double*> OriginArray;
    >>>>>>
    >>>>>
    >>>>> As I said sub-optimal; instead of a single allocation for all elements
    >>>>> in the vector you now have one allocation for every element in the
    >>>>> vector which does not scale well; you lose the property of
    >>>>> contiguousness which is sometimes an important requirement; you now
    >>>>> have to write extra code to delete the arrays the vector elements
    >>>>> point to to avoid memory leaks.
    >>>>>
    >>>> The memory allocation is optional , the same can be done on the stack.
    >>>
    >>> You said:
    >>>
    >>> "store a pointer to a dynamically allocated array"
    >>>
    >>> You are now moving the goal posts which is the typical behaviour of a
    >>> troll. There is no indication that the OP wants a stack based solution.
    >>>

    >> You said my method was sub optimal because it required allocation.
    >> So I simply pointed out that my pointer method can be used on the stack
    >> also.
    >>
    >> If your method was on the heap you'd still need to allocate/delete each
    >> array so your comparsison of the two methods was completely incomparable.
    >> Any goalpost shifting has been done by your attempt to make dynamic
    >> allocation appear sub-optimal.

    >
    > Wrong; my solution involves std::vector performing all the allocations
    > resulting in one allocated block of memory for *all* the vector elements
    > rather than your solution of one allocated block of memory for *each*
    > array *each* vector element points to.
    >

    My solution?
    I suggested an option to use pointers and dynamic allocation. I didn't say
    anything about how to allocate memory as I don't know the full design of the
    program.

    Only one wrong here is you to make assumptions about the requirement for
    memory allocation.

    >>>
    >>>> If he already has the arrays its very simple to assign the address of
    >>>> an
    >>>> array to a pointer stored in a vector. This is more optimal than
    >>>> copying
    >>>> each array into a new object.
    >>>> If he was creating it all from scratch the pointer method would also
    >>>> use
    >>>> less memory, thus being a more optimal solution.
    >>>
    >>> If he is creating it from scratch "storing a pointer to a dynamically
    >>> allocated array" then more memory will be used not less than with the
    >>> solutions I suggested.
    >>>

    >> You didn't suggest a way to use dynamic allocation.

    >
    > What? Are you thick? std::vector by default uses std::allocator which by
    > default performs dynamic allocations and can allocate memory for more than
    > one element at a time rather than an individual allocation for each
    > element.
    >

    You would create an unneccessarry additional array in the vector and then
    need to copy all the original arrays to the vector. Then you would finish up
    with two of each array. Your method its very inneficient.
    >>
    >>>>
    >>>> As for memory leaks, well the fact that you worry about that really
    >>>> just
    >>>> shows your noobness lol.
    >>>>
    >>>
    >>> You have a lot to learn. Troll off.
    >>>

    >> So you say but I seem to be the one who's always teaching you new stuff.
    >> :)

    >
    > You really are deluded aren't you? What have you taught me exactly? I
    > don't recall you teaching me (or anyone else in this forum) anything.
    >
    > I have been a C++ programmer for 18 years; how long have you been a C++
    > programmer?
    >

    18 years and your still clueless. Dam what a waste of time.
    Paul, Feb 2, 2011
    #11
  12. mathieu

    Paul Guest

    "Leigh Johnston" <> wrote in message
    news:...
    > On 02/02/2011 01:49, Paul wrote:

    <snip>
    >>>
    >>> I have been a C++ programmer for 18 years; how long have you been a
    >>> C++ programmer?
    >>>

    >> 18 years and your still clueless. Dam what a waste of time.

    >
    > I see that you failed to answer my question which is an answer in of
    > itself.
    >
    > I am fed up with you wasting my time with your ignorant posts, your
    > unwillingness to learn and/or be corrected, your trolling and your
    > obnoxious insults. I have killfiled you. No need to reply.
    >


    You create an argument then you run away, accusing me of obnoxious insults
    and trolling, when things don't go your way.
    I wonder why you are so determined to prove me wrong.

    Looks like you're going to have to accept you have the error prone gene and
    perhaps you should get some practise at apoligising.
    In fact I suggest that you create and apologising signature for your posts.
    :)
    Paul, Feb 2, 2011
    #12
  13. mathieu

    gwowen Guest

    On Feb 2, 12:13 am, Leigh Johnston <> wrote:

    > You have a lot to learn.  Troll off.


    STOP F******G PRODDING HIM THEN!

    Sheesh.
    gwowen, Feb 2, 2011
    #13
  14. mathieu

    Paul Guest

    "gwowen" <> wrote in message
    news:...
    On Feb 2, 12:13 am, Leigh Johnston <> wrote:

    > You have a lot to learn. Troll off.


    STOP F******G PRODDING HIM THEN!

    Sheesh.
    ..............................................................................

    Your the trolls here not me.

    If you ever even tried to prod me with anything I would kill you there an
    then you lowly piece of shit.
    Paul, Feb 2, 2011
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anonymous
    Replies:
    20
    Views:
    4,276
    Pete Becker
    Mar 30, 2005
  2. Jason Heyes
    Replies:
    8
    Views:
    711
    Andrew Koenig
    Jan 15, 2006
  3. Replies:
    8
    Views:
    1,896
    Csaba
    Feb 18, 2006
  4. none
    Replies:
    3
    Views:
    449
    Juha Nieminen
    Apr 14, 2007
  5. Rune Allnor
    Replies:
    4
    Views:
    929
    Rune Allnor
    Dec 11, 2008
Loading...

Share This Page