class-in-a-typedef-in-a-class circular trouble

[Jacek Dziedzic]

Hello!

I'm creating a class that has a static method which would
compute a lookup table needed later by all members of the class.
The problem is, the lookup table is composed of records and one
of the record fields is the class itself, i.e. I'm aiming at
something like:

typedef struct {
my_class instance;
int lookup_value;
} lookup_record;

class my_class {
private:
int some_internal_var;
static lookup_record lookup_table[1000];
public:
static void prepare_lookup_table();
// ...
};

but that won't compile with "my_class is used as a type but is
not defined as a type". All right then, the compiler doesn't
know yet, what my_class is. So I tried to add a line with

class my_class;

above it all, but then it says that "field my_class has
incomplete type". If I try to put the typedef after the
class, then the class declaration does not know what the
typedef is. Also classes and typedefs won't accept extern.

What do I do? This all is, btw, in a header file.

tia,
- J.

[Josephine Schafer]

"Jacek Dziedzic" <[e-mail]> wrote in message
news:bj**********@korweta.task.gda.pl...

Hello!

I'm creating a class that has a static method which would
compute a lookup table needed later by all members of the class.
The problem is, the lookup table is composed of records and one
of the record fields is the class itself, i.e. I'm aiming at
something like:

typedef struct {
my_class instance;
int lookup_value;
} lookup_record;

class my_class {
private:
int some_internal_var;
static lookup_record lookup_table[1000];
public:
static void prepare_lookup_table();
// ...
};

but that won't compile with "my_class is used as a type but is
not defined as a type". All right then, the compiler doesn't
know yet, what my_class is. So I tried to add a line with

class my_class;

You need to tell the compiler the size of the class also then.
How is to deduce the size just by looking at a forward declaration.
So one way to solve your problem is to store a pointer to my_class in your
struct instead of the object itself.
my_class *pInstance;.
This way compiler can live just with the forward declaration (i.e.without
seeing it's actual definition)

HTH,
J.Schafer

[Jacek Dziedzic]

Josephine Schafer wrote:

You need to tell the compiler the size of the class also then.
How is to deduce the size just by looking at a forward declaration.
I thought that a forward declaration would tell the compiler to
"look somewhere else for the precise class declaration and
compute the size", but it seems it's not *that* smart, right?
So one way to solve your problem is to store a pointer to my_class in your
struct instead of the object itself.
my_class *pInstance;.
This way compiler can live just with the forward declaration (i.e.without
seeing it's actual definition)

Yes, I thought about this, but I don't think I can afford such
overhead in memory and in speed (it's a look-up table supposed
to speed things up, after all) that would be introduced by
one extra dereferencing. I think I'll just forget about class
neatness and store the internal class variable (an int)
in the lookup record instead of storing the class itself.
That won't look good, but would be effective.

I was hoping for a solution along the lines of "extern class",
one that would tell the compiler to look for the precise
class definition somewhere else (later in the code).

thanks,
- J.

[Ivan Vecerina]

"Jacek Dziedzic" <[e-mail]> wrote in message
news:bj**********@korweta.task.gda.pl...
| I'm creating a class that has a static method which would
| compute a lookup table needed later by all members of the class.
| The problem is, the lookup table is composed of records and one
| of the record fields is the class itself, i.e. I'm aiming at
| something like:
|
| typedef struct {
| my_class instance;
| int lookup_value;
| } lookup_record;
|
| class my_class {
| private:
| int some_internal_var;
| static lookup_record lookup_table[1000];
| public:
| static void prepare_lookup_table();
| // ...
| };
| but that won't compile [....]

Suggestion:
- Make lookup_table a static global in your .cpp file,
instead of a private static member of my_class.
Or better, use an anonymous namespace in the .ccp file
that will include the definition of both lookup_record
and the lookup_table:
namespace {
typedef struct { ..... } lookup_record;
lookup_record lookup_table[1000];
}

Alternatively, change the type of the look-up table:
static lookup_record* lookup_table;
(as Josephine suggested)
You then need to allocate the table in your initialization
function, using new[]:
lookup_table = new lookup_record[1000];
.... and it might be a good idea to free it before
program exit: delete[] lookup_table;
The first solution is nicer/simpler IMO.

This said, this fixed size table (1000 elements) seems
arbitrary. Changing the type of the look-up table to
std::vector<my_class> or std::map<my_class,int> would
probably be a good idea...

hth,
Ivan
--
http://ivan.vecerina.com

[Jacek Dziedzic]

Ivan Vecerina wrote:

Suggestion:
- Make lookup_table a static global in your .cpp file,
instead of a private static member of my_class.
Or better, use an anonymous namespace in the .ccp file
that will include the definition of both lookup_record
and the lookup_table:
namespace {
typedef struct { ..... } lookup_record;
lookup_record lookup_table[1000];
}

Yes, I think I might try that. I've got it all inside
a (named) namespace already, which I stripped for brevity here.
I guess it won't interfere?
This said, this fixed size table (1000 elements) seems
arbitrary. Changing the type of the look-up table to
std::vector<my_class> or std::map<my_class,int> would
probably be a good idea...

It was arbitrary, for it was a simplified example only.
In reality the lookup table would have about a million
elements. The size is known at compile time, and the
look-up table will have to be transferrable between
processors via MPI -- that's why a std::vector is not
a good idea -- it can't be copied "memcpy-wise",
whereas a traditional array can be.

Thanks for the suggestions,
- J.

[tom_usenet]

On Thu, 11 Sep 2003 12:16:49 +0000, Jacek Dziedzic
<[e-mail]> wrote:

Hello!

I'm creating a class that has a static method which would
compute a lookup table needed later by all members of the class.
The problem is, the lookup table is composed of records and one
of the record fields is the class itself, i.e. I'm aiming at
something like:

typedef struct {
my_class instance;
int lookup_value;
} lookup_record;

class my_class {
private:
int some_internal_var;
static lookup_record lookup_table[1000];
public:
static void prepare_lookup_table();
// ...
};

but that won't compile with "my_class is used as a type but is
not defined as a type". All right then, the compiler doesn't
know yet, what my_class is. So I tried to add a line with

class my_class;

above it all, but then it says that "field my_class has
incomplete type". If I try to put the typedef after the
class, then the class declaration does not know what the
typedef is. Also classes and typedefs won't accept extern.

What do I do? This all is, btw, in a header file.

Do it the other way around:

struct lookup_record;

class my_class {
private:
int some_internal_var;
static lookup_record lookup_table[1000];
public:
static void prepare_lookup_table();
};

struct lookup_record
{
my_class instance;
int lookup_value;
};

lookup_record my_class::lookup_table[1000];

static members can have incomplete types.

Tom

[Ivan Vecerina]

Hi Jacek,
"Jacek Dziedzic" <[e-mail]> wrote in message
news:bj**********@korweta.task.gda.pl...
| Ivan Vecerina wrote:
| > Suggestion:
| > - Make lookup_table a static global in your .cpp file,
| > instead of a private static member of my_class.
| > Or better, use an anonymous namespace in the .ccp file
| > that will include the definition of both lookup_record
| > and the lookup_table:
| > namespace {
| > typedef struct { ..... } lookup_record;
| > lookup_record lookup_table[1000];
| > }
| >
|
| Yes, I think I might try that. I've got it all inside
| a (named) namespace already, which I stripped for brevity here.
| I guess it won't interfere?
An unnamed namespace may be nested within another namespace, this
won't be a problem (if that's what you meant by "interfere").
(it just generates longer identifiers for the linker, no big deal).

| The size is known at compile time, and the
| look-up table will have to be transferrable between
| processors via MPI -- that's why a std::vector is not
| a good idea -- it can't be copied "memcpy-wise",
| whereas a traditional array can be.
Note that an std::vector always allocates contiguous storage,
so the whole contents can be copied by memcpy (if items are POD).
But if the data is strictly fixed-size, no need to bother.

hth, Ivan
--
http://ivan.vecerina.com

[Jacek Dziedzic]

Thanks a lot, Ivan! Your namespace idea worked just fine!

- J.

[Jacek Dziedzic]

Amazingly simple, that!

thanks,
- J.

[Stephan Brönnimann]

Jacek Dziedzic <[e-mail]> wrote in message news:<bj**********@korweta.task.gda.pl>...

Hello!

I'm creating a class that has a static method which would
compute a lookup table needed later by all members of the class.
The problem is, the lookup table is composed of records and one
of the record fields is the class itself, i.e. I'm aiming at
something like:
What is struct lookup_record good for? Why do you not put it's member
`int lookup_value' inside my_class?

Try get a clear idea of the responsibilities of lookup_record and my_class.
From the code snippet you've given you can not look-up a instance of
my_class without already having a reference to that class!?

typedef struct {
my_class instance;
int lookup_value;
} lookup_record;

This is C, in C++ you define a struct exactly the same way as a class.

struct lookup_record {
my_class instance;
int lookup_value;
};

regards, Stephan

[Gavin Deane]

Jacek Dziedzic <[e-mail]> wrote in message news:<bj**********@korweta.task.gda.pl>...

Josephine Schafer wrote:

You need to tell the compiler the size of the class also then.
How is to deduce the size just by looking at a forward declaration.

I thought that a forward declaration would tell the compiler to
"look somewhere else for the precise class declaration and
compute the size", but it seems it's not *that* smart, right?

No, it can't do that. Every translation unit (roughly, a translation
unit is a source file and all its includes) is compiled separately. As
each TU is compiled, the compiler has no knowledge whatsoever of any
other TU. When you forward declare a class, the class definition does
not have to appear later in the same TU (it can be in a different -
one that's the point :-) ) even though that happens to be the case in
your example. So in general, the "somewhere else" you want the
compiler to look is not available.

So one way to solve your problem is to store a pointer to my_class in your
struct instead of the object itself.
my_class *pInstance;.
This way compiler can live just with the forward declaration (i.e.without
seeing it's actual definition)

Yes, I thought about this, but I don't think I can afford such
overhead in memory and in speed (it's a look-up table supposed
to speed things up, after all) that would be introduced by
one extra dereferencing. I think I'll just forget about class
neatness and store the internal class variable (an int)
in the lookup record instead of storing the class itself.
That won't look good, but would be effective.

Be wary of confusing your design to save speed unless and until you
have proven that the "slow" way is too slow to be acceptable.
Premature optimisation being the root of all evil and all that.

GJD

[Ivan Vecerina]

"Jacek Dziedzic" <[e-mail]> wrote in message
news:bj**********@korweta.task.gda.pl...
| Thanks a lot, Ivan! Your namespace idea worked just fine!
I'm glad it worked.

While there are alternatives (kudos to Tom, I forgot about
the solution he mentioned), I think it is usually a good
idea to move private static members into an anonymous
namespace in the implementation file. Especially when this
data involves additional type declarations.
This way there are completely hidden from users, and
will cause less compile time overhead (and less
recompilations when they are modified).

Cheers,
Ivan
--
http://ivan.vecerina.com