std::vector and array

[mathieu]

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 !

 

[Ian Collins]

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];
};

 

[mathieu]

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

 

[Paul]

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]

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]

On 01/02/2011 22:25, Paul wrote:

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.

 

[Ian Collins]

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]

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?

 

[Paul]

On 01/02/2011 23:23, Paul wrote:

On 01/02/2011 22:25, Paul wrote:

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 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.

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]

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]

On 02/02/2011 00:03, Paul wrote:

On 01/02/2011 23:23, Paul wrote:

On 01/02/2011 22:25, Paul wrote:

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.

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.

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]

On 02/02/2011 01:49, Paul wrote:

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.

 

[gwowen]

You have a lot to learn.  Troll off.

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

Sheesh.

 

[Paul]

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.