C directives

[vib]

Hi there,

I have seen code which use #ifdef-#else-#endif directive to make sure
not duplicate declaration of variables. From the code below, I could
understand the reason behind of using the
#ifndef __KERNEL_H_
#define __KERNEL_H_.

However, as for the #ifdef __KERNEL_DEF
#undef __KERNEL_DEF
TASK taskreg[2];
#else
extern TASK taskreg[2];
#endif
, isn't that unnecesssary? As the first, one can write it without it,
but with a little more planning. and secondly I don't see many using
this construct.

Perhaps I am ignorant about the benefit of that construct. Appreciate
your comments.

Thanks
vib

-----
#ifndef __KERNEL_H_
#define __KERNEL_H_

typedef struct task_reg_type
{
int stack;
int taskreq;
} TASK;
#ifdef __KERNEL_DEF
#undef __KERNEL_DEF
TASK taskreg[2];
#else
extern TASK taskreg[2];
#endif

#endif
------

[Richard Bos]

"vib" <vi*****@gmail.com> wrote:

I have seen code which use #ifdef-#else-#endif directive to make sure
not duplicate declaration of variables. From the code below, I could
understand the reason behind of using the
#ifndef __KERNEL_H_
#define __KERNEL_H_.

However, as for the #ifdef __KERNEL_DEF
#undef __KERNEL_DEF
TASK taskreg[2];
#else
extern TASK taskreg[2];
#endif
, isn't that unnecesssary?

It's worse: it's probably broken. It looks like an attempt to prevent
duplicate definition of taskreg, by turning subsequent definitions into
declarations instead, which would be legal. Unfortunately, this helps
only if the second definition is inside the same translation unit as the
first - it has no effect at all if this file is #included twice in the
same program, but in different source files. In the latter case, you
still have two definitions for the same object, and still cause
undefined behaviour by doing so.

BTW, identifiers starting with two underscores are reserved for the
implementation. If this file was provided by your implementation, that's
all right, but in your own headers you're not supposed to use names like
__KERNEL_H_, or in fact __anythingatall.

Richard

[Jonathan Bartlett]

Perhaps the point is that you can have a file which handles all of your
defines, just by including the right files and doing

#define __KERNEL_DEF

and including the right files. This way when someone adds a variable
definition, they only have to add it into a single header file, rather
than also having to add it to a regular source file.

Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017

[Christian Kandeler]

Jonathan Bartlett wrote:

Perhaps the point is that you can have a file which handles all of your
defines, just by including the right files and doing

#define __KERNEL_DEF

and including the right files. This way when someone adds a variable
definition, they only have to add it into a single header file, rather
than also having to add it to a regular source file.

But then you'd have to make sure to only include the header file in one
particular source file, so you could just as well define the variables
there.
Christian