preprocessing statements

[Bill Cunningham]

Re: preprocessing statements


<vippstar@gmail .comwrote in message news:1558c10a-2ddb-4221-a5dc-

Use a proper text editor that does this for you.
clc is not a group to ask about text editors.

huh??

Have you read this thread?

[William Pursell]

Re: preprocessing statements

On May 28, 2:19 am, "Bill Cunningham" <nos...@nspam.c omwrote:

I want one header called master.h that includes all the headers that
have been typed. I am tired of typing them all in one at a time. I wish to
have a header with conditional compilation.

There is a problem with the approach you are taking that should be
considered. It is not really adequate to
use the simple pre-processor check of '#ifdef LINUX'. It would
be more appropriate to do something like: (caveat: it
is IMO totally inappropriate to be doing this at all, but
if you really want to, the following approach will be more
robust)

#ifdef HAVE_SYS_FOO
#include <sys/foo.h>
#endif

The fact that the particular Linux you are using today has
sys/foo.h is not sufficient, and neither you nor the
preprocessor really cares if the system is Linux or not...
only whether or not sys/foo.h can be included. Check for
features, not for the system.

[Keith Thompson]

Re: preprocessing statements

William Pursell <bill.pursell@g mail.comwrites:

On May 28, 2:19 am, "Bill Cunningham" <nos...@nspam.c omwrote:
>

> I want one header called master.h that includes all the headers that
>have been typed. I am tired of typing them all in one at a time. I wish to
>have a header with conditional compilation.

>
There is a problem with the approach you are taking that should be
considered. It is not really adequate to
use the simple pre-processor check of '#ifdef LINUX'. It would
be more appropriate to do something like: (caveat: it
is IMO totally inappropriate to be doing this at all, but
if you really want to, the following approach will be more
robust)
>
#ifdef HAVE_SYS_FOO
#include <sys/foo.h>
#endif
>
The fact that the particular Linux you are using today has
sys/foo.h is not sufficient, and neither you nor the
preprocessor really cares if the system is Linux or not...
only whether or not sys/foo.h can be included. Check for
features, not for the system.

Except that you just might care whether you have the the Linux
sys/foo.h or the Solaris sys/foo.h.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ben Bacarisse]

Re: preprocessing statements

"Bill Cunningham" <nospam@nspam.c omwrites:

<vippstar@gmail .comwrote in message news:1558c10a-2ddb-4221-a5dc-
>

>Use a proper text editor that does this for you.
>clc is not a group to ask about text editors.

>
huh??
>
Have you read this thread?

It is likely he has. He is saying that using conditional compilation
and a big master.h header is not the best way to solve the problem of
being "tired typing all the includes". My editor lets me type #incude
<stdio.husing just a few keys. I can "pull in" an outline C program
to write quick test in just a couple of key strokes[1].

If you go your way, you won't really have a portable programs. There
are too many small differences between in ways systems handle the bit
outside of the C standard.

[1] But since it is Emacs most of my fingers are involved in each
stroke!

--
Ben.

[Bill Cunningham]

Re: preprocessing statements


"Ben Bacarisse" <ben.usenet@bsb .me.ukwrote in >

It is likely he has. He is saying that using conditional compilation

and a big master.h header is not the best way to solve the problem of
being "tired typing all the includes". My editor lets me type #incude
<stdio.husing just a few keys. I can "pull in" an outline C program
to write quick test in just a couple of key strokes[1].
>
If you go your way, you won't really have a portable programs. There
are too many small differences between in ways systems handle the bit
outside of the C standard.
>
[1] But since it is Emacs most of my fingers are involved in each
stroke!
>

I see ok well based on earlier posts in this thread perhaps I
misunderstood. Text editors had not been mentioned to that point in the
thread and I understand they are OT. Unless someone was writing one and they
mentioned their code itself. Then editors would still be OT just not C code.
:)
I was going to use conditional compilation and all these headers as a
learning tool for myself. So I wasn't looking so much at the importance of
portability in the program. The using of non-standard headers itself would
destroy portability.

Bill

[Bill Cunningham]

Re: preprocessing statements


"Keith Thompson" <kst-u@mib.orgwrote in message
news:lnlk1vosqh .fsf@nuthaus.mi b.org...

>There is a problem with the approach you are taking that should be
>considered. It is not really adequate to
>use the simple pre-processor check of '#ifdef LINUX'. It would
>be more appropriate to do something like: (caveat: it
>is IMO totally inappropriate to be doing this at all, but
>if you really want to, the following approach will be more
>robust)
>>
>#ifdef HAVE_SYS_FOO
>#include <sys/foo.h>
>#endif
>>
>The fact that the particular Linux you are using today has
>sys/foo.h is not sufficient, and neither you nor the
>preprocessor really cares if the system is Linux or not...
>only whether or not sys/foo.h can be included. Check for
>features, not for the system.

>
Except that you just might care whether you have the the Linux
sys/foo.h or the Solaris sys/foo.h.
>

I only wanted to do this conditional compilation thing as a personal
learning tool for preprocessor directives. Even using non-standard headers
destroys portability which is all important we all understand. It was to
learn and save me keystrokes.

Bill

[Keith Thompson]

Re: preprocessing statements

"Bill Cunningham" <nospam@nspam.c omwrites:

"Keith Thompson" <kst-u@mib.orgwrote in message
news:lnlk1vosqh .fsf@nuthaus.mi b.org...
>

>>There is a problem with the approach you are taking that should be
>>considered. It is not really adequate to
>>use the simple pre-processor check of '#ifdef LINUX'. It would
>>be more appropriate to do something like: (caveat: it
>>is IMO totally inappropriate to be doing this at all, but
>>if you really want to, the following approach will be more
>>robust)
>>>
>>#ifdef HAVE_SYS_FOO
>>#include <sys/foo.h>
>>#endif
>>>
>>The fact that the particular Linux you are using today has
>>sys/foo.h is not sufficient, and neither you nor the
>>preprocesso r really cares if the system is Linux or not...
>>only whether or not sys/foo.h can be included. Check for
>>features, not for the system.

>>
>Except that you just might care whether you have the the Linux
>sys/foo.h or the Solaris sys/foo.h.
>>

I only wanted to do this conditional compilation thing as a personal
learning tool for preprocessor directives. Even using non-standard headers
destroys portability which is all important we all understand. It was to
learn and save me keystrokes.

Saving you keystrokes isn't an issue as long as copy-and-paste exists.

As for portability, there are 3 classes of programs. (I don't claim
this is exhaustive or definitive, just relevant to what you're doing.)

1. Portable programs that depend only on standard headers.

2. Non-portable programs that depend on non-standard headers; these
will compile and run only on a particular system (e.g., Linux).

3. Programs that are a mixture of the above. A program might
conditionally include one or more system-specific headers. Any code
that uses features defined in those headers would itself have to be
conditionalized (surrounded by #if ... #endif or #ifdef ... #endif).
For example, a program might provide a textual interface on all
systems, and additionally provide a GUI only on systems where it's
available.

The stuff you're trying to do:

#include <stdio.h>
#ifdef linux
#include <sys/foo.h>
#endif

makes sense for the third class of programs, but I don't believe
that's what you're trying to do -- and if it is, I suggest that you're
in over your head, given the difficulties you've had mastering the
basic concepts of portable standard C.

Personally, I'm not a big fan of these "everything .h" headers that
just include all the other headers you might or might not need. If a
translation unit uses printf(), then *that* source file should have
"#include <stdio.h>", and likewise for any other standard or
non-standard headers.

Incidentally, portability isn't "all important". It's one among many
important attributes that a program can have. If you need to do
something system-specific, go ahead and do it; your program isn't
going to be portable to other systems, but it doesn't need to be.

Non-portable code isn't necessarily bad, it's just off-topic here,
because we try to discuss portable aspects of the language as defined
by thes standard. If you have Unix-specific questions, for example,
you can ask them in comp.unix.progr ammer.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Thomasson]

Re: preprocessing statements

"Bill Cunningham" <nospam@nspam.c omwrote in message
news:vXX_j.5092 $nx6.2636@trndd c03...

I have been thinking about hiding headers from my compiler's
preprocessor and allowing others to be shown. I want to use the most used
and add others is necessary. Would this be how it is properly done. I want
to ask ahead of time because what I do might work but it might not be the
"correct" or standard way.
>
#include <stdio.h>
#include <stdlib.h>
#ifdef LINUX
#include <unistd.h>
#include <sys/types>
#include <sys/stats.h>
#include <fctnl.h>
#endif
>
Is the #endif needed at the end of this case ?

yes.


Okay. I don't know if this is what your looking for, but when I need to
create a library that needs to run on several platforms and make use of
system specific API's I generally do something like this:


Lets say that I need to have conditional compilation predicated on what
architecture the code is compiling under... Say x86 and SPARC. I would
create three files... First two arch specific headers:







arch_x86.h
----------------------------
#include <limits.h>

/* System Specific */
#define ARCH_X86_WORD_S IZE (32 / CHAR_BIT)
typedef int arch_x86_word;
typedef char ARCH_X86_STATIC _ASSERT[
sizeof(arch_x86 _word) == ARCH_X86_WORD_S IZE ? 1 : -1
];

static arch_x86_word
arch_x86_atomic _swap(
arch_x86_word volatile* const _pthis,
arch_x86_word xchg
) {
[arch specific asm];
}


/* Abstract */
#define ARCH_WORD_SIZE ARCH_X86_WORD_S IZE

typedef arch_x86_word arch_word;

#define arch_atomic_swa p arch_x86_atomic _swap








arch_sparc.h
----------------------------
#include <limits.h>

/* System Specific */
#define ARCH_SPARC_WORD _SIZE (32 / CHAR_BIT)
typedef int arch_sparc_word ;
typedef char ARCH_SPARC_STAT IC_ASSERT[
sizeof(arch_spa rc_word) == ARCH_SPARC_WORD _SIZE ? 1 : -1
];

static arch_sparc_word
arch_sparc_atom ic_swap(
arch_sparc_word volatile* const _pthis,
arch_sparc_word xchg
) {
[arch specific asm];
}


/* Abstract */
#define ARCH_WORD_SIZE ARCH_SPARC_WORD _SIZE

typedef arch_sparc_word arch_word;

#define arch_atomic_swa p arch_sparc_atom ic_swap








and finally an abstract header:

arch.h
----------------------------
#if defined(_X86_)
# include "arch_x86.h "
#elif defined(__sparc __)
# include "arch_sparc .h"
#else
# error ARCH NOT SUPPORTED!
#endif







Now a user can just include "arch.h" to get at the architecture dependant
abstraction...


#include "arch.h"
#include <assert.h>

static arch_word volatile g_word = 0;

int main() {
arch_word const old = arch_atomic_swa p(&g_word, 1);
assert(old == 0);
return 0;
}





Is that even close to what your trying to do? Please note that this
simplistic technique can also be use to abstract OS specific API's away into
common base...

[Richard Heathfield]

Re: preprocessing statements

[I know I'm preaching to the choir here, but maybe some non-choristers will
drop by and pick up a few pearls of what I am pleased to call "wisdom".]

Keith Thompson said:

<snip>

Incidentally, portability isn't "all important". It's one among many
important attributes that a program can have.

Right...

If you need to do
something system-specific, go ahead and do it; your program isn't
going to be portable to other systems, but it doesn't need to be.

....and less right. <g>

We can't tell whether a program needs to be portable purely on the basis of
whether we need it to do something system-specific. Rather, what we have
here is two conflicting characteristics :

(a) portability, and
(b) system-specific features.

If the portability requirement is sufficiently high, the program will
simply have to do without the system-specific features (SSFs for short).
Conversely, if the need for those SSFs is sufficiently high, the program
will necessarily be less portable than would otherwise be the case.

It may be that the portability requirement is present but limited - for
example, the program may need to run on both VM/CMS and MacOS, but no
other platform, in which case there is no particular problem with using
SSFs that happen to be available on both platforms.

The problem with using SSFs even with programs for which the portability
need is perceived to be low is simply that useful programs tend to outlive
their platforms - hence the truism that any sufficiently useful program
*will*, one day, be ported. Making this easier is therefore an important
criterion when designing a "sufficient ly useful program".

To maximise portability, use only those features of C that are guaranteed
to be available in all implementations , even freestanding implementations .

That is quite a high barrier, of course. If we're prepared to eschew
portability to freestanding implementations , we can extend our range of
features to include those that the Standard guarantees to be available on
all hosted implementations .

If that is still too high a price to pay, we can avail ourselves of
features guaranteed by other standards (e.g. POSIX), knowing as we do that
we are now limiting ourselves to POSIX-conforming systems.

And if that is /still/ too high a price, then we can at least isolate the
system-specific parts of our code, providing an interface to them that can
remain constant across rewrites of the underlying SSF-using code.

>
Non-portable code isn't necessarily bad, it's just off-topic here,

True, but I think it's reasonable to consider as topical the ways in which
we might isolate SSF usage, in ISO C.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Re: preprocessing statements

Richard Heathfield <rjh@see.sig.in validwrites:

[I know I'm preaching to the choir here, but maybe some non-choristers will
drop by and pick up a few pearls of what I am pleased to call "wisdom".]
>
Keith Thompson said:
>
<snip>
>

>Incidentally , portability isn't "all important". It's one among many
>important attributes that a program can have.

>
Right...
>

>If you need to do
>something system-specific, go ahead and do it; your program isn't
>going to be portable to other systems, but it doesn't need to be.

>
...and less right. <g>
>
We can't tell whether a program needs to be portable purely on the basis of
whether we need it to do something system-specific. Rather, what we have
here is two conflicting characteristics :
>
(a) portability, and
(b) system-specific features.

Agreed. My phrase "If you *need* to do something system-specific" was
intended to cover that; thank you for saying more clearly than I did
that it's a tradeoff.

[snip lots of good stuff]

>Non-portable code isn't necessarily bad, it's just off-topic here,

>
True, but I think it's reasonable to consider as topical the ways in which
we might isolate SSF usage, in ISO C.

Agreed.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Re: preprocessing statements

Bill Cunningham wrote:

>
I have been thinking about hiding headers from my compiler's
preprocessor and allowing others to be shown. I want to use the
most used and add others is necessary. Would this be how it is
properly done. I want to ask ahead of time because what I do
might work but it might not be the "correct" or standard way.
>
#include <stdio.h>
#include <stdlib.h>
#ifdef LINUX
#include <unistd.h>
#include <sys/types>
#include <sys/stats.h>
#include <fctnl.h>
#endif
>
Is the #endif needed at the end of this case ?

Yes, the #endif is needed. No, this is a terrible idea. Only
#include the headers you need. That depends on the routines,
macros, etc. you call. Everything you have listed in the #ifdef
section above is undefined in standard C, and off-topic on this
newsgroup.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

** Posted from http://www.teranews.com **