storing arrays in cpp

[Stainless]

I have a public class Globals, which obviously holds all my global data.

I have an array of 243 items, currently structs of type

typedef struct STAR
{
int x;
int y;
int stellar_class;
}t_star;

t_star StarArray[243]={
{.....},
};


If I was doing this app in C I would just have the array as a seperate
C source file, compile it in, and have extern t_star StarArray[] where
ever I needed it.

What's the correct way to do this in cpp?

having global data is frowned upon, you can't put it in the class
header as this is against ansi conventions....

Are you supposed to define the empty array in the class header then
fill it in the class creation tool? What a waste of stack space....

puzzled...





--

 

[Alf P. Steinbach]

* Stainless:

I have a public class Globals, which obviously holds all my global data.

I have an array of 243 items, currently structs of type

typedef struct STAR
{
int x;
int y;
int stellar_class;
}t_star;

1) Style: Don't use all uppercase except for macros, in C or C++.
2) Style: Don't use a typedef for a struct in C++ code.

Just do

struct t_star{ int x; int y; int stellar_class; };

t_star StarArray[243]={
{.....},
};

If this is meant to be a constant, use 'const'.

Instead of stating the number of elements, compute them.

t_star const StarArray[] = { ... };
size_t const StarArrayCount = sizeof(StarArray)/sizeof(*StarArray);

If I was doing this app in C I would just have the array as a seperate
C source file, compile it in, and have extern t_star StarArray[] where
ever I needed it.

What's the correct way to do this in cpp?

There no "the" correct way.

A good way would be to do the same as you'd do in C.

having global data is frowned upon,

Having global _variables_ is frowned on, for good reasons.

you can't put it in the class
header as this is against ansi conventions....

There's no such thing as class header (presumably you mean header file)
and there's no such thing as ansi conventions for C++ programming.

You can put data definitions in a header file.

The easiest way is to just declare the data 'const'; then it has
internal linkage.

If you want the data to be guaranteed to occur only once in the program
you can use a number of tricks.

One such trick is a function that returns a reference to the data.

Are you supposed to define the empty array in the class header then
fill it in the class creation tool? What a waste of stack space....

There's no such thing as "class creation tool" in C++.

Formally there's not even such a thing as stack space, but for that it
is (in contrast to the other things) not difficult to understand what
you mean.

However, you're wrong about that.

 

[Victor Bazarov]

I have a public class Globals, which obviously holds all my global data.

Don't make it a "public class". You're probably going to be better off
with a namespace.

I have an array of 243 items, currently structs of type

typedef struct STAR
{
int x;
int y;
int stellar_class;
}t_star;

t_star StarArray[243]={
{.....},
};


If I was doing this app in C I would just have the array as a seperate
C source file, compile it in, and have extern t_star StarArray[] where
ever I needed it.

What's the correct way to do this in cpp?

There are several ways.

having global data is frowned upon, you can't put it in the class
header as this is against ansi conventions....

Are you supposed to define the empty array in the class header then
fill it in the class creation tool? What a waste of stack space....

No, you're supposed to make those members 'static' and define them outside
of the class definition, and initialise them there.

V

 

[Benry]

I have a public class Globals, which obviously holds all my global data.

I have an array of 243 items, currently structs of type

typedef struct STAR
{
int x;
int y;
int stellar_class;
}t_star;

t_star StarArray[243]={
{.....},
};


If I was doing this app in C I would just have the array as a seperate
C source file, compile it in, and have extern t_star StarArray[] where
ever I needed it.

What's the correct way to do this in cpp?

Alright, I most likely do this the wrong way, but I like to use
standard container classes rather than arrays for things like structs.
The simpliest (not tested) example of this I can come up with:

Globals.h
-------------
class CGlobals{
public:
CGlobals::CGlobals();
CGlobals::~CGlobals();
struct STAR
{
int x;
int y;
int stellar_class;
}t_star;

}

foo.h
-------
include "Globals.h"
class foo{
foo::foo();
foo::~foo();

std::list<CGlobals> StarArray;
}

foo.cpp
----------

static void main(){
CGlobals bar;
bar.t_star.x = 1;
bar.t_star.y = 2;
bar.t_star.stellar_class = 4;

StarArray.push_back(bar);
}

This way, you can have a dynamic array (list in this case), and still
use structs...

HOWEVER...if you're only using this struct and array in one class,
declare it as a private or protected member, and utilize it that way.
If you want the array global, make it a public member, and just include
that class header file whenever you want to use it.

An easier way would be to make a class with the three int's you want,
and then make a std::list of that class. This would eliminate the
struct altogether.

C++ is amazing and I hope I didn't confuse you at all. I do that too
myself sometimes.

Are you supposed to define the empty array in the class header then
fill it in the class creation tool? What a waste of stack space....

What IDE are you using?

puzzled...

If you're working with C, you won't be puzzled for very long .

-ben

 

[Stainless]

1) Style: Don't use all uppercase except for macros, in C or C++.

2) Style: Don't use a typedef for a struct in C++ code.

Style varies depending on where you work, the typedef is the required
format for many places I have worked.

If this is meant to be a constant, use 'const'.

Not constant

Instead of stating the number of elements, compute them.

t_star const StarArray[] = { ... };
size_t const StarArrayCount = sizeof(StarArray)/sizeof(*StarArray);

I only put the size in to give people an idea of the amount of data I
had to store.

Having global variables is frowned on, for good reasons.

I reduced flash usage in a mobile phone by 1437 bytes, and ram usage by
538 bytes by making a single variable global.

I can see problems in multi-threaded environments, but a lot of "don't
do this" coding standards are designed to stop crap coders screwing
things up. Using global variables correctly can be a massive advantage
for a real world application.

There's no such thing as class header (presumably you mean header
file) and there's no such thing as ansi conventions for C++
programming.

Well try initialising a variable in a class definition and see what
your compiler says .

Formally there's not even such a thing as stack space, but for that it
is (in contrast to the other things) not difficult to understand what
you mean.

However, you're wrong about that.

errr no, I have spent a lot of time hacking about with x86 code created
by c++ compilers and I know very well what crap they can generate.

C and C++ are stack based languages, variables and local storage all
come from the stack, the first thing you find in most subroutines is

mov ebp,esp
add esp,<some value>

then variable accesses are all

mov eax,[ebp+<offset]
mov [ebp+<offset],ebx

defining any local variables increases stack usage.

I don't know what would happen if I had a const array in the tool,
possibly the compiler could be smart enough to put that elsewhere, but
I would still have two copies of the entire array in memory somewhere.

The x,y,and stellar_class will be constant, but other booleans I will
be adding to the structure will be dynamic.

 

[Stainless]

No, you're supposed to make those members 'static' and define them
outside of the class definition, and initialise them there.

V

This is one of those c++ static problems, when I use static inside a
function it means "retain value", but outside a class definition, on my
compiler at least it reduces visibility.

Defining the array as static makes it invisible to code outside the
current class implementation.

This would mean I have to add handlers for the array to the class

t_star getStar(int n);
void setFlag(int n, int flag);


etc.

which is just code bloat


--

 

[Stainless]

I see what you mean, but you still end up manually filling the array.

I have seen a lot of people using lists in c++, but I am very suspicous
about how efficent the code will be.

I can see how the compiler will generate code for arrays of struct's
It will generate an array of pointers, the same way it does for
multi-dimensional arrays.

Accessing an element then becomes very efficent.

With lists I am not so sure what the compiler will generate, and
without time to experiment I am loath to use them.

 

[Stainless]

While I am thinking about a clean solution, I am currently using a
frigg.

I have written a c tool that writes the array to disc, I then read this
into the array when the class is created.

Swapped disc space for memory in effect

 

[Gavin Deane]

This is one of those c++ static problems, when I use static inside a
function it means "retain value", but outside a class definition, on my
compiler at least it reduces visibility.

Defining the array as static makes it invisible to code outside the
current class implementation.

This would mean I have to add handlers for the array to the class

t_star getStar(int n);
void setFlag(int n, int flag);


etc.

which is just code bloat

Doesn't this work for you? I think it is what Victor suggested. Note
that he also suggested that you might just as well use a namespace
instead of a class full of only static data.

// Globals.h
struct t_star
{
int x;
int y;
int stellar_class;
};

class Globals
{
public:
static t_star StarArray[];
};
----------------------------------------------------------------

// Globals.cpp
t_star Globals::StarArray[243] = { ... }; // Initialise the array


----------------------------------------------------------------
#include "globals.h"
int main()
{
Globals::StarArray[0].x = 1;
int i = Globals::StarArray[0].stellar_class;
}

Gavin Deane

 

[Alf P. Steinbach]

* Stainless:

[confused]

Well.

 

[Benry]

I guess that would work too.

I'm assuming you're writing this for an RTOS since you're worried about
overhead. The compiler (well..gcc/gpp) will only include those
functions that you're using with std::list, which normally you would
write yourself for a linked list in C.

But, you still want an array . I'm going to stop pushing it because
there is quite a bit of overhead compared with arrays.

Ok, I just read your replies to the other guys. Obviously for embedded
systems. I guess my next question is why c++ when you're using C fine?
I think for what you're trying to do, a class isn't the answer anyway.
I haven't been working in the "real world" for long, but my roots are
in C programming, so I remember thinking stacks, bitwise, memory
allocation on my 16bit motorolas, etc...

When I learned C++ I was scared everyday about overhead that it was
creating.

Basically, I use a struct now when I want a very basic structure, which
no methods belonging to it. I use a class when there are routines that
this class has, and that can be inherited or derived from other
classes...gah, I'm losing it.

Uh, for your example I would use a struct, and not even worry about
classes. If there is some abstraction that requires you to include
this struct in a greater combonation of variables, then, the struct is
part of the class, but don't replace it . You can then use a global
array of that class member, with minimal changes to your code.

(very winded, sorry) Lastly, I think that your coding style is fine for
the application. If my assumption is correct, then there is no reason
that I will frown seeing some global variables. I mean, the compilier
allows them for a reason, right? To answer your original question, the
correct way is the way you can get it to work with your requirements in
your application while sticking to your employer's coding standards. I
would personally change very little with your code when porting from c
to c++.

 

[Stainless]

class Globals

{
public:
static t_star StarArray[];
};

Thank you, this worked.

To me this was counter intuative, I would have expected it to be thrown
out by the compiler syaing something like

"StarArray already defined "

I knew there had to be a work around, but probably wouldn't have found
it by experimentation.

 

[Stainless]

Ok, I just read your replies to the other guys. Obviously for
embedded systems. I guess my next question is why c++ when you're
using C fine?

I am writing portable code that will run on several target OS's.

Thus it has to be c++, as some of the target OS's don't have C
compilers.

The hassle is that all the OS's have different problems, in this case
all the global data for the app has to be in a single holder (could be
a struct but it is far more convenient to be able to have the attached
methods as well). This is for the Symbion port. In there "wisdom" they
decided to make global data illegal for app's. You get a single pointer
which they call "thread local storage", and that's it.

When I learned C++ I was scared everyday about overhead that it was
creating.

For the last, well at least ten years, I have been noticing a trend of
bloated code being prefered to clean code. As an example, when I was
first tasked with evaluating Symbion as a target platform we had a
device on the market, sold tens of millions of units, everybody was
happy with it, and it contained 1Meg of flash and 250K of ram.

Symbion's basic spec required a MINIMUM of 5Meg ram and 5Meg flash.

When you consider that at the time the 1Meg flash comprised almost 25%
of the materials cost for the device, we were looking at a major cost
increase.

I despise working on Symbion now, they have tried to be everything to
everybody, and ended up with a complete mess.

 

[Ben Pope]

class Globals
{
public:
static t_star StarArray[];

//Declaration

};

//Definition


Thank you, this worked.

To me this was counter intuative, I would have expected it to be thrown
out by the compiler syaing something like

"StarArray already defined "

It's only defined once and the declaration is compatible.

Ben Pope

 

[Benry]

I am writing portable code that will run on several target OS's.

Thus it has to be c++, as some of the target OS's don't have C
compilers.

The hassle is that all the OS's have different problems, in this case
all the global data for the app has to be in a single holder (could be
a struct but it is far more convenient to be able to have the attached
methods as well). This is for the Symbion port. In there "wisdom" they
decided to make global data illegal for app's. You get a single pointer
which they call "thread local storage", and that's it.

So this thread local storage is your array? Is it dynamic or like a
buffer? It's actually a pointer, so what is the max mem allocation you
are allowed for it?

I can understand where you're coming from. I would probably use the
Linux v. Windows comparison as an analagy. When looking for Linux
programs, you search for a couple things:
1. How you want to compile it (be it rpm, Makefile, gcc, etc)
2. What platform you're running
3. What options you want.

When installing, you may be missing some libraries!

Where, in Windows, it's all there for you (most of the time), even
though it hardly ever works 100%.

I think customers are Windows, and Programmers/Engineers are Linux.
They didn't mix in the 1950s(people, not OSs), and as much as our
marketing departments wish, it's a huge hurdle to get them to do that
today.

For the last, well at least ten years, I have been noticing a trend of
bloated code being prefered to clean code. As an example, when I was
first tasked with evaluating Symbion as a target platform we had a
device on the market, sold tens of millions of units, everybody was
happy with it, and it contained 1Meg of flash and 250K of ram.

Thank God I have a giant brain and use code ACAP (as clean as
possible). I'm joking, but we did learn to consider your registers,
cache requirements, memory allocation/leaks, etc when writing any level
of code in college. The more stuff I see, though, the more I pull my
hair out wondering what I'm really supposed to be doing! (I graduated
only a short time ago).

I will not continue, because my skills are far inferior and anything I
have to say will be wasting people's time.
-ben