From: RB on
Oh well ok this (your reply below) does sound very convicting, I am going to have
to encompass this also into my immediate learning curve. I did not realize the whole
Class was created on the stack (or maybe all of it isn't, probably the code isn't ) but
if there is a chance of substantial stack overload I don't want to spend time writing
something for that.
So then it appears that I can put structs of different member types into CArray
and/or std::vector and not just the usual data types. I will have to begin reading
and trying some of this.
Thank you.

--------------------------------------------------------------------------------
"Joseph M. Newcomer"
> Generally, because there is no bounds checking done in pure C. Also, it puts large
> objects on the stack (there was some example of this posted here a few weeks ago, where
> somebody had a local array of 17x17xmassive structure on the stack and was getting stack
> overflows). Overall, the advantage of CArray or std::vector is that the stack space
> consumed is very small (a few bytes) and the data is always on the heap.

> If you don't know how many you have in advance, a compile-time-constant array is a Really
> Bad Idea. Either you need to make it big enough to hold the absolute maximum you might
> ever encounter (consuming massive stack space) or be prepared to deal with the fact that
> the program is not adequate to the task because the array bounds, which must be set at
> compile time, are too small. CArray::SetAt will let you set any array element, and do
> bounds checking, and CArray::SetAtGrow will expand the array to the specified size.
> CArray::Add will expand it until memory exhausts. There are analogous features for
> std::vector.
>
> CArray<Inlet> InletA;
> InletA.SetSize(10);
> std::vector<Inlet> InletA;
> InletA.resize(10);


From: Joseph M. Newcomer on
If you do sizeof(classname) you will find out how many bytes an instance of the class
requires. This is all the non-static data, plus, if there are virtual methods, a slot for
the vptr (virtual function table pointer). Then multiply this times the number of
elements in the array to get how many bytes of stack space it requires. A simple model is
that it is the sum of the sizeof() of all the nonstatic data components. THe problem with
the 17x17 problem was that many of the data components were themselves large structs, so
there was a lot of bytes used by every instance.

It is the nature of the C subset of C++ that arrays are allocated on the stack as a
sequence of bytes that is long enough to hold the entire contents of the array. This has
always been true since the first C compilers appeared in the 1970s.

The biggest problem is something that is called "C Programmer's Disease" (see: The New
Hacker's Dictionary) which is creating an array of n elements and writing values in it
where the index exceeds (n - 1) and most commonly the failed index is equal to n. The two
alternatives if your array is too small are The C Programmer's Disease or having your
program come out and tell the user "Too much information!" (not some useless dialog box
that says "Bounds check errror in function .... file .... line ...., which is not
considered User Friendly). Typically I do a throw of an exception which includes the
file, line and function name so I can log the problem and otherwise do not expose the user
to the details.

You can put *anything* into a CArray or std::vector; the parameter to the template is the
data type. So you can do
std::vector<int> Things;
typedef struct {...complex stuff...} SomeType;
std::vector<SomeType> Stuff;
std::vector<SomeType *> MoreStuff;

there is nothing in CArray or std::vector to suggest that you CAN'T use an arbitrary type
in them! So you can use "the usual data types" because EVERY type you define is a "usual
data type" for this purpose!

Note that for std::map, you need to have a value-comparison function defined on the type
(think it has to be a virtual method lessstr, but I have to look this up each time), but
that is easy to write. But no such function is needed if they are in a std::vector.
joe

On Thu, 6 May 2010 19:26:14 -0400, "RB" <NoMail(a)NoSpam> wrote:

>Oh well ok this (your reply below) does sound very convicting, I am going to have
>to encompass this also into my immediate learning curve. I did not realize the whole
>Class was created on the stack (or maybe all of it isn't, probably the code isn't ) but
>if there is a chance of substantial stack overload I don't want to spend time writing
>something for that.
> So then it appears that I can put structs of different member types into CArray
>and/or std::vector and not just the usual data types. I will have to begin reading
>and trying some of this.
>Thank you.
>
>--------------------------------------------------------------------------------
>"Joseph M. Newcomer"
>> Generally, because there is no bounds checking done in pure C. Also, it puts large
>> objects on the stack (there was some example of this posted here a few weeks ago, where
>> somebody had a local array of 17x17xmassive structure on the stack and was getting stack
>> overflows). Overall, the advantage of CArray or std::vector is that the stack space
>> consumed is very small (a few bytes) and the data is always on the heap.
>
>> If you don't know how many you have in advance, a compile-time-constant array is a Really
>> Bad Idea. Either you need to make it big enough to hold the absolute maximum you might
>> ever encounter (consuming massive stack space) or be prepared to deal with the fact that
>> the program is not adequate to the task because the array bounds, which must be set at
>> compile time, are too small. CArray::SetAt will let you set any array element, and do
>> bounds checking, and CArray::SetAtGrow will expand the array to the specified size.
>> CArray::Add will expand it until memory exhausts. There are analogous features for
>> std::vector.
>>
>> CArray<Inlet> InletA;
>> InletA.SetSize(10);
>> std::vector<Inlet> InletA;
>> InletA.resize(10);
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm