Pragma

[muttaa]

Hello all,

I'm a beginner in C...May i like to know the difference between a
#pragma and a #define....


Also,yet i'm unclear what a pragma is all about as i can find topics on
it only in high-standard books...


Thanks in advance!

 

[Eric Sosman]

Hello all,

I'm a beginner in C...May i like to know the difference between a
#pragma and a #define....


Also,yet i'm unclear what a pragma is all about as i can find topics on
it only in high-standard books...

For a beginner, the difference is simple: #define is
something you use, but #pragma is something you avoid.

#define creates a macro. When the macro name appears
later on in the program, the text of the macro definition
replaces the name. (That's a loose description, not perfect
but good enough for all but language lawyers.) A macro is
a kind of shorthand; using the shorthand, you may be able
to write your program more briefly and more clearly.

#pragma tells the compiler to do something peculiar. It
may tell the compiler to allocate a variable on an 8192-byte
boundary, or to use a non-standard mechanism for calling a
function, or that some special action is to be taken before
main() is called, or ... With a very few exceptions, the
effect of a #pragma directive is entirely defined by the
particular compiler you happen to be using; switch to a
different compiler and the same #pragma in your source code
may have an entirely different effect. In other words, #pragma
ties your code to just one compiler, thus giving up nearly all
the portability C is famous for.

Use #define when it seems useful. When #pragma seems like
a good idea, you are probably hallucinating and should get some
bed rest.

 

[swengineer001]

When #pragma seems like
a good idea, you are probably hallucinating and should get some
bed rest.

So what would you suggest when stucture packing is required for a
program. As far as I know there is no standar C way to do it but it is
often required in embedded systems. Am I wrong on this?

 

[Gordon Burditt]

When #pragma seems like

So what would you suggest when stucture packing is required for a

structure packing is NOT required for a C program. I don't know
what kind of program it is, but it's not C.

program. As far as I know there is no standar C way to do it but it is
often required in embedded systems. Am I wrong on this?

Gordon L. Burditt

 

[Ian Collins]

structure packing is NOT required for a C program. I don't know
what kind of program it is, but it's not C.

It may not be required, but it is often used in embedded environments.
Packing might even be required, if its use reduced code size.

 

[Tomás]

So what would you suggest when stucture packing is required for a
program. As far as I know there is no standar C way to do it but it is
often required in embedded systems. Am I wrong on this?

If you're looking for a TRULLY portable method, you can use pointer
trickery.

All the three "char" types are guaranteed to use all of their bits in
their value representation. Armed with this knowledge, plus with the help
of CHAR_BIT, you can manipulate the bits in memory directly.

If CHAR_BIT != 8, then it will be a little harder... but not impossible.

I posted an example of this within the last two days on this newsgroup. If
you want to use Google to search, search for "pointer trickery" in a post
by me.

-Tomás

 

[Eric Sosman]

It may not be required, but it is often used in embedded environments.
Packing might even be required, if its use reduced code size.

Structure packing (if it can be done at all) seldom if
ever reduces code size. In my experience, it either increases
code size and slows the program down a little, or leaves code
size unchanged and slows the program down a lot.

Structure packing can reduce data size, which is another
matter. However, there are other ways to reduce data size if
that's a concern. For example, one might transform

struct {
char x;
double y;
} thing[BIG_COUNT];

to

char thing_x[BIG_COUNT];
double thing_y[BIG_COUNT];

Structure packing is also used to make a struct match an
externally-imposed format like a packet header or some such.
This is a snare and a delusion; in the long run, It Doesn't Work.

 

[pete]

Tomás wrote:

All the three "char" types are guaranteed to use all of their bits in
their value representation.

The signed char type isn't guaranteed to be padding free.
I don't think there's ever been a case where
there has been padding in a signed char,
but there's no guarantee.

 

[Ian Collins]

Structure packing is also used to make a struct match an
externally-imposed format like a packet header or some such.
This is a snare and a delusion; in the long run, It Doesn't Work.

It does if the externally imposed format is hardware registers.

 

[swengineer001]

Structure packing can reduce data size, which is another
matter. However, there are other ways to reduce data size if
that's a concern. For example, one might transform

struct {
char x;
double y;
} thing[BIG_COUNT];

to

char thing_x[BIG_COUNT];
double thing_y[BIG_COUNT];

While this does reduce data size it does nothing to maintain data
encapsulation which can be a very useful thing in increasing the
readability of the code.

Structure packing is also used to make a struct match an
externally-imposed format like a packet header or some such.
This is a snare and a delusion; in the long run, It Doesn't Work.

I am not sure that I understand why you think this. I have used, and
probably will again, structure packing for both externally imposed data
structures such as headers and to overlay something on a specific piece
of hardware. I have never had a problem with this, although I have not
had change compilers either which I will admit could cause some
problems but I was not suggesting that i would be portable. Why is it
that you say it does not work.

 

[swengineer001]

structure packing is NOT required for a C program. I don't know
what kind of program it is, but it's not C.

OK, there are other ways to accomplish the same thing but they are
likely, IMHO, to make the code more difficult to read which should also
be a consideration. I am sure many people here could do just about
anything in completely portable C but I would also bet that anyone here
that really knows what they are doing would not suggest that that
should always be the approach taken. Sometimes the best solution to a
problem is a non portable solution (non portable does not mean non
standard).

As far as structure packing not being C, I would suggest that it is C
since #pragma without a STDC preprocessing token immediately following
it invokes implementation defined behavior according to the standard.
Thus anything the implementation wants to implement with a #pragma
directive is by definition standard C compliant. It may not be portable
but it is without question C and in compliance with the standard.
Discussing a specific implementations #pragma directive is off topic
here but I have never worked with an implementation that did not
support a pack direvtive of some sort (I am sure there are some out
there but I have not come accross one).

Just my opinion, and I am sure I will get plentty of feedback on it.

 

[Eric Sosman]

[...]
As far as structure packing not being C, I would suggest that it is C
since #pragma without a STDC preprocessing token immediately following
it invokes implementation defined behavior according to the standard.
Thus anything the implementation wants to implement with a #pragma
directive is by definition standard C compliant. It may not be portable
but it is without question C and in compliance with the standard.
> [...]

C, or not-C?

int main(void) {
#pragma fortran
write (6,10)
10 format(14H Hello, world!)
#pragma c
return 0;
}

All right, that example is perhaps a little bit fanciful!
(Not completely implausible, though: consider all those postings
showing "C" sources with assembly languages embedded in them.)
My point is to offer the notion that #pragma moves the code out
of the noontime glare of the C Standard and somewhere into the
shadowy dusk -- or even, as above, into black midnight.

The semantics of #pragma are not (in my limited experience)
usually as drastic as my illustration. Still, even more "normal"
adjustments can raise issues with the language. The business of
struct packing, for example: Consider the notion of "compatible
type" as defined in the Standard, and ponder how you would need
to adjust it to accommodate a struct-packing #pragma. It is easy
to see that two "compatible" structs meeting all the Standard's
requirements can wind up being incompatible if one is packed and
the other is not. The #pragma thus makes the language not an
extended C, but a divergent C.

I've seen alignment-controlling #pragmas, too -- and they
can be even more deadly, IMHO. That's because lots of compilers
support a `#pragma align <number>' directive, but disagree over
the significance of the <number>: Does `#pragma align 16' specify
alignment to a 16-byte or a 65536-byte boundary? The promise that
the compiler will ignore a #pragma it doesn't recognize is of no
help in this case.

Even "harmless" #pragmas cast doubt on the code. If you
see `#pragma csect shared' you may guess that the linker is
being asked to put something in a "shared" area -- but shared
with whom, and by what kind of mechanism, and with what sort
of initialization, and ...? I opine that the answers to such
questions are essential to the proper operation of the program
(else the #pragma wouldn't be there), but that they almost
certainly change the semantics of the "shared" objects in ways
that are foreign to C.

#pragma transforms C code into "C, but ..." code. In the
context of the original poster's question

> I'm a beginner in C...May i like to know the difference between a
> #pragma and a #define....

.... I think "Don't Do That" is the correct answer, at least for
the time being.

 

[Kenneth Brody]

So what would you suggest when stucture packing is required for a
program. As far as I know there is no standar C way to do it but it is
often required in embedded systems. Am I wrong on this?

On all of the systems I have worked on, the vendors have been kind enough
to supply (admitedly non-standard) header files for this purpose. However,
all of the vendors have also been kind enough to use the same names for
these files -- pshpack1.h, pshpack2.h, pshpack4.h, pshpack8.h, and
poppack.h -- so I have been able to use these headers in the very few
source files that needed them.

They have also included #pragma's to do this, but they are different for
each of the systems. However, the header files they have supplied hide
this.

But, you are correct that there is no standard way of doing this. And,
it may be possible that it's not possible to do this on some platforms.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Clever Monkey]

I'm a beginner in C...May i like to know the difference between a
#pragma and a #define....

Also,yet i'm unclear what a pragma is all about as i can find topics on
it only in high-standard books...

The behaviour of #pragma is implementation defined. On GCC it used to
(does it still?) allow you to play hack/rogue. Very different than a
#define, that.

 

[CBFalconer]

Eric Sosman wrote:
.... snip ...

It does if the externally imposed format is hardware registers.

On one (maybe more) system. Bit picking and packing works anywhere.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Ian Collins]

.... snip ...



On one (maybe more) system. Bit picking and packing works anywhere.

As a developer (or manager) one can either be pragmatic or dogmatic. If
your toolchain offers you non-standard way of simplifying a task, the
choice is yours whether you use it.