Structure with version ??

[Vj]

Hi all,

I'm finding some people in my company defining a version number as a
field to some structure.

The sample code goes as follows:

typedef enum _params_ver_ {
UNDEF = 0,
VERSION_1,
VERSION_LAST
} PARAMS_VER;

typdef struct _xyz_ {
PARAMS_VER version;
ULONG info;
} XYZ;

void DoSomething (XYZ asdf);

The argument for the same is as follows:

Suppose another field info2 is added to XYZ, the client using
DoSomething () needn't write any code to intialise the same.

Personally, I think a structure shouldn't have a version. Has anyone,
come across such an I/F ?? Is it recommended??

If the initialisation of the field is generally 0, a memset to the
structure by the client will solve the problem.

R
V

 

[Manish]

Hi all,

I'm finding some people in my company defining a version number as a
field to some structure.

The sample code goes as follows:

typedef enum _params_ver_ {
UNDEF = 0,
VERSION_1,
VERSION_LAST

} PARAMS_VER;

typdef struct _xyz_ {
PARAMS_VER version;
ULONG info;

} XYZ;

void DoSomething (XYZ asdf);

The argument for the same is as follows:

Suppose another field info2 is added to XYZ, the client using
DoSomething () needn't write any code to intialise the same.

Personally, I think a structure shouldn't have a version. Has anyone,
come across such an I/F ?? Is it recommended??

If the initialisation of the field is generally 0, a memset to the
structure by the client will solve the problem.

R
V

IMHO, I would use inheritance for this purpose.

For example:
struct base {
data_type dt;
};

struct derivedublic struct base {
new_data_type ndt;
};

Now, this way you wouldn't have to worry about changing existing
structure, instead for future releases use the new structure.

 

[Coos Haak]

Op 27 Feb 2007 07:48:14 -0800 schreef Manish:

struct derivedublic struct base {

This isn't C. Go left down the hall, past the watercooler and try knocking
at the door of comp.lang.c++.

 

[Chris Dollin]

IMHO, I would use inheritance for this purpose.

For example:
struct base {
data_type dt;
};

struct derivedublic struct base {
new_data_type ndt;
};

About ten billion people will now point out to you that this
isn't a C++ group. I'm one of them.

 

[Manish]

About ten billion people will now point out to you that this
isn't a C++ group. I'm one of them.

Yeah, I also thought about it just after hitting the send button.

 

[Eric Sosman]

Vj wrote On 02/27/07 05:45,:

Hi all,

I'm finding some people in my company defining a version number as a
field to some structure.

The sample code goes as follows:

typedef enum _params_ver_ {
UNDEF = 0,
VERSION_1,
VERSION_LAST
} PARAMS_VER;

typdef struct _xyz_ {
PARAMS_VER version;
ULONG info;
} XYZ;

Sooner or later, the evil habit of starting identifiers
with underscores will rise up and bite you in the underwear.
See http://www.oakroadsystems.com/tech/c-predef.htm; it's a
bit out of date (in fact, the URL links to a disclaimer which
in turn links to the document), but worth reading.

void DoSomething (XYZ asdf);

The argument for the same is as follows:

Suppose another field info2 is added to XYZ, the client using
DoSomething () needn't write any code to intialise the same.

I think you've slightly misstated the situation, or else
you've glossed over quite a few devilish details. No matter.

Personally, I think a structure shouldn't have a version. Has anyone,
come across such an I/F ?? Is it recommended??

If you can recompile all the source when you change a
struct definition there's not much benefit to versioning:
there is only one version, the current version, and that's
that. But sometimes there are situations where you cannot
recompile everything, or where prior versions of the struct
have been salted away in files and other places where the
compiler can't touch them. In such cases a version number
can be part of the solution -- it doesn't solve very much
all by its lonesome, but it can provide the foothold the
bulk of the solution requires.

If the initialisation of the field is generally 0, a memset to the
structure by the client will solve the problem.

(1) "Maybe" and (2) "It depends what you think `the
problem' is."

 

[Laurent Deniau]

Yeah, I also thought about it just after hitting the send button.

Still, this is probably the best approach to manage version on the long
time. To implement OO features in C, you may have a look to:

http://www.cern.ch/laurent.deniau/oopc.html#OOC-S

Which was specifically written for C programmers.

a+, ld.

 

[Nick Keighley]

I'm finding some people in my company defining a version number as a
field to some structure.

The sample code goes as follows:

typedef enum _params_ver_ {
UNDEF = 0,
VERSION_1,
VERSION_LAST
} PARAMS_VER;

typdef struct _xyz_ {
PARAMS_VER version;
ULONG info;
} XYZ;

void DoSomething (XYZ asdf);

The argument for the same is as follows:

Suppose another field info2 is added to XYZ, the client using
DoSomething () needn't write any code to intialise the same.

Personally, I think a structure shouldn't have a version. Has anyone,
come across such an I/F ?? Is it recommended??

it might make sort of sense is the structure is being used to
communicate between different programs. This is, of course,
fraught with difficulties.

don't do it between disparate platforms (this could include
compiler version).

 

[George Peter Staplin]

Hi all,

I'm finding some people in my company defining a version number as a
field to some structure.

The sample code goes as follows:

typedef enum _params_ver_ {
UNDEF = 0,
VERSION_1,
VERSION_LAST
} PARAMS_VER;

typdef struct _xyz_ {
PARAMS_VER version;
ULONG info;
} XYZ;

void DoSomething (XYZ asdf);

The argument for the same is as follows:

Suppose another field info2 is added to XYZ, the client using
DoSomething () needn't write any code to intialise the same.

Personally, I think a structure shouldn't have a version. Has anyone,
come across such an I/F ?? Is it recommended??

I use a similar versioning scheme for some public structures shared by
different dynamically loadable libraries.

#define MEGAIMAGE_HEADER_VERSION 3
struct megaimage_header {
int version; /*just in case we add features later*/
int width;
int height;
size_t imagesize;
};
/* image bytes follow the structure */

Then the various compiled libraries run a test like this:

if (h->version != MEGAIMAGE_HEADER_VERSION) {
/* report error */
/* exit if needed */
}

Why did I start doing that you may ask? I found that I was sometimes
incrementally updating the libraries for various programs that load the
libraries dynamically, and during testing bugs were showing up that were
caused by the binary incompatibilities. So, this makes sure that they
are updated together in a binary-compatible way -- assuming I remember
to increase the MEGAIMAGE_HEADER_VERSION when making incompatible
changes.

-George