keyword extern

[tweak]

What's the best way to use extern when using multiplefiles that is
easiest to maintain?

Is it best to declare:

extern int a;

in a header file and include the header file in all files except
where it's defined.

Or is it better to write

extern int a;

in all the files except where it's originally defined?

I'm just curious what the best practice is since I code
as a hobby. And I'm still learning and making lotsa
mistakes.

Thanks,

Brian

P.S. Thanks to whomever recommended Advanced Unix Programming
Second Edition. It's cleared up a lot for me. And it's
making me question as to whether I should drop linux and
move to openBSD.

[Emmanuel Delahaye]

In 'comp.lang.c', tweak <xb**********@cox.net> wrote:

What's the best way to use extern when using multiplefiles that is
easiest to maintain?
First of all, try to avoid the use of global scope variables. Read-only are
acceptable, but read/write are source of trouble. However, if you insist ...
Is it best to declare:

extern int a;

in a header file and include the header file in all files except
where it's defined.
Almost. The header should also be included in the definition source file.
This is the only way to check the match between the declaration and the
definition.
/* data.h */
/* usual guards ommited */
extern int x;

/* data.c */
#include "data.h"
long x; /* ERR! */

It also allows nice things like :

/* data.h */
/* usual guards ommited */
extern int a[128];

/* data.c */
#include "data.h"
int a[];

The size definition is now unique, public and centralized. It helps reading
and maintenance.
Or is it better to write

extern int a;

in all the files except where it's originally defined?

Certainly not.

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Yashesh Bhatia]

tweak <xb**********@cox.net> wrote in message news:<0a3Dc.3$151.1@fed1read02>...

What's the best way to use extern when using multiplefiles that is
easiest to maintain?

Is it best to declare:

extern int a;

in a header file and include the header file in all files except
where it's defined.

Or is it better to write

extern int a;

in all the files except where it's originally defined?

I'm just curious what the best practice is since I code
as a hobby. And I'm still learning and making lotsa
mistakes.

Thanks,

Brian

P.S. Thanks to whomever recommended Advanced Unix Programming
Second Edition. It's cleared up a lot for me. And it's
making me question as to whether I should drop linux and
move to openBSD.

Well, my preferred way would be to declare it in all the .c files that
need the extern variable rather than put the extern declaration in the
header file and include the header file in the c files. The reason
being.

- If the variable was used by all c files, it would be better to make
it a global variable in the .h file.

- Keeping the extern declaration in the .c file instead of the .h
file will make it easier for other .c files that dont need the extern
variable but need other declarations from the .h file to include it.

[umbs.sairam]

> What's the best way to use extern when using multiplefiles that is

easiest to maintain? Is it best to declare:

extern int a;

in a header file and include the header file in all files except
where it's defined. Or is it better to write

extern int a;

in all the files except where it's originally defined?

One of the purposes of using extern in multiple files is restricting
the visibility of the variable only to the file that needs to "see"
it. In your question, in both the cases the variable "a" is visible in
all the files. In such a situation, there is no benefit in using the
keyword "extern. You might as well declare the variable as global.

sarma

[Emmanuel Delahaye]

In 'comp.lang.c', ya******@gmail.com (Yashesh Bhatia) wrote:

Or is it better to write

extern int a;

in all the files except where it's originally defined?
Well, my preferred way would be to declare it in all the .c files that
need the extern variable rather than put the extern declaration in the
header file and include the header file in the c files. The reason
being.

- If the variable was used by all c files, it would be better to make
it a global variable in the .h file.

No. A header is certainely not the place for an object definition for an
obvious reason. If you include the header in more than one compile unit, you
will have more than one definition of the object with the same name. This is
the kind of situation a linker can't handle, except by an error message.
- Keeping the extern declaration in the .c file instead of the .h
file will make it easier for other .c files that dont need the extern
variable but need other declarations from the .h file to include it.

The maintainers of such a code will doom you for ever. Please don't do that.
The OP's first proposal was nearly the good one. Please read my previous
answer to learn why.

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Emmanuel Delahaye]

In 'comp.lang.c', um*********@gmail.com wrote:

One of the purposes of using extern in multiple files is restricting
the visibility of the variable only to the file that needs to "see"
it.
It certainely is a bad practice. What if the type changes (int to long, float
to double, etc.) ? Because the compiler has no way to check the consistency
of the code, if you miss a change the code becomes inconsitent. This practice
is obviously wrong.

If you are concerned with the visibility of the global variables, which
is a good thing, there are other options:

- don't use global at all. (Use ADT's)
- give the user no right to change the data (a const pointer to the data)

/* data.h */
extern int const *px;

/* data.c */
#include "data.h"
static int x;
int const *px = &x;

Of course, in real life, data are gathered in some structure and a single
'context' pointer is enough.

Note that this 'protection' is just an intention. There is no way to prevent
an sloopy programmer to write and compile a code that uses a typecast to
force the pointer to a read/write access to the data. But it will invoke an
undefined behaviour. The ADT solution is safer.
In your question, in both the cases the variable "a" is visible in
all the files. In such a situation, there is no benefit in using the
keyword "extern. You might as well declare the variable as global.

Sorry, I failed to understand your point. 'extern' doesn't make global a
variable. It's the lack of 'static' that makes it.

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[umbs.sairam]

> > In your question, in both the cases the variable "a" is visible in

all the files. In such a situation, there is no benefit in using the
keyword "extern. You might as well declare the variable as global.

Sorry, I failed to understand your point. 'extern' doesn't make global a
variable. It's the lack of 'static' that makes it.

I am sorry if I did not explain myself clearly. If we have the
following files
(pseudo-code)

head.h
/* common to all files */

head1.h
/* used in file1.c */

file1.c
include "head.h"
include "head1.h"
/* code of file1.c */
......

headN.h
/* used in fileN.c */

fileN.c
include "head.h"
include "headN.h"
/* code of fileN.c */

Now, declare a variable in head1.h as int i and define it in file1.c
as i = 10. My argument in the above post is, if "i" is declared
multiple times using extern in all the files file2.c ... fileN.c then
the significance of "extern"ing is lost. The programmer could have
acheived the same functionality by declaring the variable in head.h

sarma

[tweak]

Emmanuel Delahaye wrote:

In 'comp.lang.c', tweak <xb**********@cox.net> wrote:

What's the best way to use extern when using multiplefiles that is
easiest to maintain?

First of all, try to avoid the use of global scope variables. Read-only are
acceptable, but read/write are source of trouble. However, if you insist ...

Is it best to declare:

extern int a;

in a header file and include the header file in all files except
where it's defined.

Almost. The header should also be included in the definition source file.
This is the only way to check the match between the declaration and the
definition.
/* data.h */
/* usual guards ommited */
extern int x;

/* data.c */
#include "data.h"
long x; /* ERR! */

It also allows nice things like :

/* data.h */
/* usual guards ommited */
extern int a[128];

/* data.c */
#include "data.h"
int a[];

The size definition is now unique, public and centralized. It helps reading
and maintenance.

Thanks. I'm just trying to understand best practice use of the keyword
extern since I do not program for a living, but I would like to start a
project at source forge this year. And I am just double checking the
basics.

So the best practice would be to use global static variables in practice
rather than modifiable extern variables? How should extern be used then?

And structures are preferred when appropriate?

Thanks,

Brian

[Jack Klein]

On Sat, 26 Jun 2004 10:19:23 -0700, tweak <xb**********@cox.net> wrote
in comp.lang.c:

Emmanuel Delahaye wrote:

In 'comp.lang.c', tweak <xb**********@cox.net> wrote:

What's the best way to use extern when using multiplefiles that is
easiest to maintain?

First of all, try to avoid the use of global scope variables. Read-only are
acceptable, but read/write are source of trouble. However, if you insist ...

Is it best to declare:

extern int a;

in a header file and include the header file in all files except
where it's defined.

Almost. The header should also be included in the definition source file.
This is the only way to check the match between the declaration and the
definition.
/* data.h */
/* usual guards ommited */
extern int x;

/* data.c */
#include "data.h"
long x; /* ERR! */

It also allows nice things like :

/* data.h */
/* usual guards ommited */
extern int a[128];

/* data.c */
#include "data.h"
int a[];

The size definition is now unique, public and centralized. It helps reading
and maintenance.

Thanks. I'm just trying to understand best practice use of the keyword
extern since I do not program for a living, but I would like to start a
project at source forge this year. And I am just double checking the
basics.

So the best practice would be to use global static variables in practice

Note that the word "global" does not exist in the C standard. The
term you are looking for here is "file scope" which is well defined by
the C standard.

All declarations and definitions written outside of any function in a
file have "file scope". Their scope lasts from the point of the
definition or declaration until the end of the translation unit being
compiled.

File scope definitions and declarations have external linkage by
default, unless the keyword static is added.

One never needs to use the extern keyword with a function definition,
prototype or declaration. All references to functions have external
linkage by default.

One needs to us the extern keyword for declarations (not definitions)
of data objects that are defined elsewhere. That is because of the
tentative definition feature in C.

If, outside of any block in a file, you have the three file scope
declarations:

extern int x;
int y = 0;
int z;

....then here is how a C compiler understands them.

-- extern int x; If there is no other file scope declaration of this
object in the source file, the compiler will treat it as a simple
external declaration. If any code in the source file access 'x', the
compiler will generate an external reference for it. In the final
stage of creating the executable program, usually called linking, the
int 'x' must be provided by another source file or library.

-- int y = 0; This is a definition of an int named 'y' that has
static storage duration, external linkage, and file scope. It will be
initialized with the value 0 before main() is called, and its lifetime
will be the entire execution time of the program. Even if none of the
code in the source file access 'y', the compiler will generate an
external definition for it. If there is more than one external
definition of this object in the final program, the result is
undefined.

--- int z; This is a 'tentative definition'. If there is no other
declaration for this object, then at the end of the file the compiler
will automatically create a definition "int z = 0'" and create the
object.
rather than modifiable extern variables? How should extern be used then?
As to the use of variables with external linkage, modifiable or not, I
will say this: All absolute rules are rubbish, including this one.

Modifiable objects with wide scope, whether they have external linkage
or not, can be and often are abused and become the cause of hard to
find program defects. Nevertheless, like almost every other feature
of the language, they can be used properly and sometimes they are the
best solution to a problem. On the other hand, many times there are
better solutions possible.
And structures are preferred when appropriate?

Thanks,

Brian

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Minti]

Emmanuel Delahaye <em**********@noos.fr> wrote in message news:<Xn***************************@212.27.42.72>. ..

In 'comp.lang.c', um*********@gmail.com wrote:

One of the purposes of using extern in multiple files is restricting
the visibility of the variable only to the file that needs to "see"
it.

It certainely is a bad practice. What if the type changes (int to long, float
to double, etc.) ? Because the compiler has no way to check the consistency
of the code, if you miss a change the code becomes inconsitent. This practice
is obviously wrong.

If you are concerned with the visibility of the global variables, which
is a good thing, there are other options:

- don't use global at all. (Use ADT's)

Could you elucidate this point?

--
Imanpreet Singh Arora
isingh AT acm DOT org

[tweak]

Jack Klein wrote:

On Sat, 26 Jun 2004 10:19:23 -0700, tweak <xb**********@cox.net> wrote
in comp.lang.c:

Emmanuel Delahaye wrote:

In 'comp.lang.c', tweak <xb**********@cox.net> wrote:

What's the best way to use extern when using multiplefiles that is
easiest to maintain?
First of all, try to avoid the use of global scope variables. Read-only are
acceptable, but read/write are source of trouble. However, if you insist ...

Is it best to declare:

extern int a;

in a header file and include the header file in all files except
where it's defined.
Almost. The header should also be included in the definition source file.
This is the only way to check the match between the declaration and the
definition.
/* data.h */
/* usual guards ommited */
extern int x;

/* data.c */
#include "data.h"
long x; /* ERR! */

It also allows nice things like :

/* data.h */
/* usual guards ommited */
extern int a[128];

/* data.c */
#include "data.h"
int a[];

The size definition is now unique, public and centralized. It helps reading
and maintenance.

Thanks. I'm just trying to understand best practice use of the keyword
extern since I do not program for a living, but I would like to start a
project at source forge this year. And I am just double checking the
basics.

So the best practice would be to use global static variables in practice

Note that the word "global" does not exist in the C standard. The
term you are looking for here is "file scope" which is well defined by
the C standard.

All declarations and definitions written outside of any function in a
file have "file scope". Their scope lasts from the point of the
definition or declaration until the end of the translation unit being
compiled.

File scope definitions and declarations have external linkage by
default, unless the keyword static is added.

One never needs to use the extern keyword with a function definition,
prototype or declaration. All references to functions have external
linkage by default.

One needs to us the extern keyword for declarations (not definitions)
of data objects that are defined elsewhere. That is because of the
tentative definition feature in C.

If, outside of any block in a file, you have the three file scope
declarations:

extern int x;
int y = 0;
int z;

...then here is how a C compiler understands them.

-- extern int x; If there is no other file scope declaration of this
object in the source file, the compiler will treat it as a simple
external declaration. If any code in the source file access 'x', the
compiler will generate an external reference for it. In the final
stage of creating the executable program, usually called linking, the
int 'x' must be provided by another source file or library.

-- int y = 0; This is a definition of an int named 'y' that has
static storage duration, external linkage, and file scope. It will be
initialized with the value 0 before main() is called, and its lifetime
will be the entire execution time of the program. Even if none of the
code in the source file access 'y', the compiler will generate an
external definition for it. If there is more than one external
definition of this object in the final program, the result is
undefined.

--- int z; This is a 'tentative definition'. If there is no other
declaration for this object, then at the end of the file the compiler
will automatically create a definition "int z = 0'" and create the
object.

rather than modifiable extern variables? How should extern be used then?

As to the use of variables with external linkage, modifiable or not, I
will say this: All absolute rules are rubbish, including this one.

Modifiable objects with wide scope, whether they have external linkage
or not, can be and often are abused and become the cause of hard to
find program defects. Nevertheless, like almost every other feature
of the language, they can be used properly and sometimes they are the
best solution to a problem. On the other hand, many times there are
better solutions possible.

Thanks for being very clear.

I am trying to avoid problems of maintenance before I finish writing my
project. I see too many open source projects, where I cannot easily
navigate through the code, and I'm trying to avoid that from the onset.

I saw extern as being a probable maintenance problem since tracking down
definitions has never been any fun.

Thanks Again,

Brian

P.S. I'm still learning.

[CBFalconer]

um*********@gmail.com wrote: (and stripped all attributions)

In your question, in both the cases the variable "a" is visible in
all the files. In such a situation, there is no benefit in using the
keyword "extern. You might as well declare the variable as global.

Sorry, I failed to understand your point. 'extern' doesn't make
global a variable. It's the lack of 'static' that makes it.

I am sorry if I did not explain myself clearly. If we have the
following files
(pseudo-code)

head.h
/* common to all files */

head1.h
/* used in file1.c */

file1.c
include "head.h"
include "head1.h"
/* code of file1.c */
.....

headN.h
/* used in fileN.c */

fileN.c
include "head.h"
include "headN.h"
/* code of fileN.c */

Now, declare a variable in head1.h as int i and define it in
file1.c as i = 10. My argument in the above post is, if "i" is
declared multiple times using extern in all the files file2.c
... fileN.c then the significance of "extern"ing is lost. The
programmer could have acheived the same functionality by
declaring the variable in head.h

NEVER, ever, define a variable in a header file. Define it in the
..c file where it most naturally belongs. If this is a 'global'
variable, omit the "static" qualifier, otherwise include it for
all file scope variables. To make it available in other files
declare it with the "extern" qualifier in the header file for the
..c file in which defined.

Remember, the purpose of header files is to make something in the
..c file accessible to other .c files. Nothing more or less. The
fact that #include can be misused in various ways does not affect
this.

The very presence above of a head.h common to all files suggests
misuse. A variable visible in another file is subject to
accidental modification by a typo, or simply failing to remember
something obscure. Minimize and control scope as far as possible.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Emmanuel Delahaye]

In 'comp.lang.c', mi************@yahoo.com (Minti) wrote:

- don't use global at all. (Use ADT's)

Could you elucidate this point?

I assume you meant 'elaborate'. Well, it's a piece of cake...

In a few words, Abstract Data Types (ADT) allow the process of some data
being kind of anonymous from the user pof view. All the processes are
implemented by functions : Creators, Deletors, Accessors, Processors etc.

A good example is given by the implementation of the streams in C.

You have the type FILE. Its inner description in not specified by the
language, but obviously, the user has not to know about the details. This is
an Abstract Data Type.

You have a creator : feopen() that creates an instance of a FILE object
according to the parameters, and returns the address of it. Of course, the
the address must be stored into a pointer of the same type for future use :

FILE *fp = fopen (...);

Then, you have the deletor fclose(). You just pass the address of the object,
and it will do the job.

fclose (fp);

You have processors like fread(), fwrite() etc, accessors, like feof() etc.

One way to make the data invisible from the user is share the definition of
the structure in two parts :

The public part is anonymous:

struct my_adt;

or

typedef struct my_adt my_adt_s;

for typesavers like me. It belongs to the interface (header: .h).

the other part is private. It holds the complete definition of the object.

struct my_adt
{
/* inner details */
};

it belongs to the implementation (source: .c).

Of course, creation/deletion implies the use of malloc()/free(), as you
guessed...

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[John Ilves]

tweak wrote:

Jack Klein wrote:

On Sat, 26 Jun 2004 10:19:23 -0700, tweak <xb**********@cox.net> wrote
in comp.lang.c:

Emmanuel Delahaye wrote:

In 'comp.lang.c', tweak <xb**********@cox.net> wrote:

> What's the best way to use extern when using multiplefiles that is
> easiest to maintain?

First of all, try to avoid the use of global scope variables.
Read-only are acceptable, but read/write are source of trouble.
However, if you insist ...

> Is it best to declare:
>
> extern int a;
>
> in a header file and include the header file in all files except
> where it's defined.

Almost. The header should also be included in the definition source
file. This is the only way to check the match between the
declaration and the definition.

/* data.h */
/* usual guards ommited */
extern int x;
/* data.c */
#include "data.h"
long x; /* ERR! */

It also allows nice things like :

/* data.h */
/* usual guards ommited */
extern int a[128];
/* data.c */
#include "data.h"
int a[];

The size definition is now unique, public and centralized. It helps
reading and maintenance.
Thanks. I'm just trying to understand best practice use of the
keyword extern since I do not program for a living, but I would like
to start a project at source forge this year. And I am just double
checking the basics.

So the best practice would be to use global static variables in practice
Note that the word "global" does not exist in the C standard. The
term you are looking for here is "file scope" which is well defined by
the C standard.

All declarations and definitions written outside of any function in a
file have "file scope". Their scope lasts from the point of the
definition or declaration until the end of the translation unit being
compiled.

File scope definitions and declarations have external linkage by
default, unless the keyword static is added.

One never needs to use the extern keyword with a function definition,
prototype or declaration. All references to functions have external
linkage by default.

One needs to us the extern keyword for declarations (not definitions)
of data objects that are defined elsewhere. That is because of the
tentative definition feature in C.

If, outside of any block in a file, you have the three file scope
declarations:

extern int x;
int y = 0;
int z;

...then here is how a C compiler understands them.

-- extern int x; If there is no other file scope declaration of this
object in the source file, the compiler will treat it as a simple
external declaration. If any code in the source file access 'x', the
compiler will generate an external reference for it. In the final
stage of creating the executable program, usually called linking, the
int 'x' must be provided by another source file or library.

-- int y = 0; This is a definition of an int named 'y' that has
static storage duration, external linkage, and file scope. It will be
initialized with the value 0 before main() is called, and its lifetime
will be the entire execution time of the program. Even if none of the
code in the source file access 'y', the compiler will generate an
external definition for it. If there is more than one external
definition of this object in the final program, the result is
undefined.

--- int z; This is a 'tentative definition'. If there is no other
declaration for this object, then at the end of the file the compiler
will automatically create a definition "int z = 0'" and create the
object.

rather than modifiable extern variables? How should extern be used
then?

As to the use of variables with external linkage, modifiable or not, I
will say this: All absolute rules are rubbish, including this one.

Modifiable objects with wide scope, whether they have external linkage
or not, can be and often are abused and become the cause of hard to
find program defects. Nevertheless, like almost every other feature
of the language, they can be used properly and sometimes they are the
best solution to a problem. On the other hand, many times there are
better solutions possible.

Thanks for being very clear.

I am trying to avoid problems of maintenance before I finish writing my
project. I see too many open source projects, where I cannot easily
navigate through the code, and I'm trying to avoid that from the onset.

I saw extern as being a probable maintenance problem since tracking down
definitions has never been any fun.

Thought I'd mention that cscope can be very useful for that:
http://cscope.sourceforge.net/

Thanks Again,

Brian

P.S. I'm still learning.

[Dan Pop]

In <Xn***************************@212.27.42.72> Emmanuel Delahaye <em**********@noos.fr> writes:

In 'comp.lang.c', tweak <xb**********@cox.net> wrote:

What's the best way to use extern when using multiplefiles that is
easiest to maintain?

First of all, try to avoid the use of global scope variables. Read-only are
acceptable, but read/write are source of trouble. However, if you insist ...

In incompetent hands, read/write globals can be, indeed, a source of
trouble. If you know what you're doing, they work just fine.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <cgiDc.1466$151.1398@fed1read02> tweak <xb**********@cox.net> writes:

So the best practice would be to use global static variables in practice
rather than modifiable extern variables? How should extern be used then?

And structures are preferred when appropriate?

The first rule you have to learn about computer programming in general is
that what is best depends exclusively on your application and your skills.
What is best for an application is not necessarily best for another and
what is best for a professional programmer is not necessarily best for a
beginner.

It is you and only you who can decide the best solution and it's better
to avoid any religious rules.

WRT your original question: when you need to share a global variable,
you declare it as extern in a common header that is included by all the
files using that variable, *including* the one that actually contains
its definition (to be sure that there are no conflicts between the
common declaration and the private definition). It's not impossible to
change one of them, but forget to change the other accordingly and this
safety measure has no extra costs or strings attached.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <e8*************************@posting.google.com> mi************@yahoo.com (Minti) writes:

Emmanuel Delahaye <em**********@noos.fr> wrote in message news:<Xn***************************@212.27.42.72>. ..

In 'comp.lang.c', um*********@gmail.com wrote:

> One of the purposes of using extern in multiple files is restricting
> the visibility of the variable only to the file that needs to "see"
> it.

It certainely is a bad practice. What if the type changes (int to long, float
to double, etc.) ? Because the compiler has no way to check the consistency
of the code, if you miss a change the code becomes inconsitent. This practice
is obviously wrong.

If you are concerned with the visibility of the global variables, which
is a good thing, there are other options:

- don't use global at all. (Use ADT's)

Could you elucidate this point?

No need to, as it's a religious issue.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Emmanuel Delahaye]

In 'comp.lang.c', Da*****@cern.ch (Dan Pop) wrote:

- don't use global at all. (Use ADT's)

Could you elucidate this point?

No need to, as it's a religious issue.

Noone care about your opinion. BTW, that's unfair. You quote a single line
that was part of an alternative.

<quote="-ed-">
If you are concerned with the visibility of the global variables, which
is a good thing, there are other options:

- don't use global at all. (Use ADT's)
- give the user no right to change the data (a const pointer to the data)
</quote>

Don't you have more interesting things to do than trying to tease me? You are
so good at technical matters. Stick to it.

--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=c99
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Dan Pop]

In <Xn***************************@212.27.42.74> Emmanuel Delahaye <em**********@noos.fr> writes:

In 'comp.lang.c', Da*****@cern.ch (Dan Pop) wrote:

- don't use global at all. (Use ADT's)

Could you elucidate this point?
No need to, as it's a religious issue.

Noone care about your opinion.

Then, I everybody should have already plonked me. Makes me wonder why
do so many people reply to my posts...

And if *you* don't care about my opinion (or are you the exception to
your own statement?), why do you read my posts?
Don't you have more interesting things to do than trying to tease me?
It's not a matter of teasing you, it's a matter of debunking your
religion presented as technical advice.
You are so good at technical matters. Stick to it.

When I need your advice, I'll kindly ask for it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de