const field in structure

S

Skybuck Flying

Hello,

What does Const mean in this c structure ? and what is the delphi equivalent
?

I think const struct just means it can't be modified... is that correct ?

Struct {
Type1 Field1;
Const struct Type2 *Field2;
} Structure1;

So my guess would be:

Type
Structure1 = record
Field1 : Type1;
Field2 : ^Type2;
end;

Delphi doesn't have constant fields in structures/records ?

Why would someone make the field const in C, is it really that important ?

I am guessing it's just a safety precaution during coding... ?

Bye,
Skybuck
 
R

Rob Kennedy

Skybuck said:
What does Const mean in this c structure ? and what is the delphi equivalent
?

I think const struct just means it can't be modified... is that correct ?

Struct {
Type1 Field1;
Const struct Type2 *Field2;
} Structure1;

That is a pointer to a const struct. The value of the pointer field may
change, but that value may not be used to modify the thing being pointed
at. Delphi has no equivalent.
Why would someone make the field const in C, is it really that important ?

I could try to answer, but since you've cross-posted this to a C
newsgroup, I'll let the experts there explain that. I don't know how
similar C and C++ are in this regard, but you may be interested in the
C++ FAQ category on "const correctness":

http://www.parashift.com/c++-faq-lite/const-correctness.html
 
E

Emmanuel Delahaye

Skybuck Flying wrote on 11/08/04 :
What does Const mean in this c structure ? and what is the delphi equivalent
?

Struct {
Type1 Field1;
Const struct Type2 *Field2;
} Structure1;

Nothing I'am aware of. 'Const' is not a C-word. If you are talking of
'const', it's a different story.It means that the pointer Field2 is
only allowed to make read acces to the pointee.

A big difference between Pascal and C : C is case sensitive.
 
S

Skybuck Flying

Emmanuel Delahaye said:
Skybuck Flying wrote on 11/08/04 :


Nothing I'am aware of. 'Const' is not a C-word. If you are talking of
'const', it's a different story.It means that the pointer Field2 is
only allowed to make read acces to the pointee.

Well now I'm confused.

Does it mean

1. The pointer is read only.
2. The structure is read only.

?

:)
 
A

Arthur J. O'Dwyer

Emmanuel Delahaye said:
Skybuck Flying wrote on 11/08/04 :
[...]
Well now I'm confused.

Does it mean
1. The pointer is read only.
2. The structure is read only.
?

It means the structure is read-only. The structure pointed to by
'Field2', that is, of course; not the whole 'Structure1' structure!


For the experts: It surprised me just now to learn that 'gcc -ansi'
actually permits

struct foo {
const int bar;
};

Does this mean what I think it means --- 'bar' can only be given a
value during initialization --- or is this just a quirk of GCC or
of the Standard?

-Arthur
 
E

Emmanuel Delahaye

Skybuck Flying wrote on 11/08/04 :
Does it mean

1. The pointer is read only.
2. The structure is read only.

It means that the 'struct Type2' pointed by 'Field2' is read only when
you use Field2 to access it.
 
C

Chris Torek

For the experts: It surprised me just now to learn that 'gcc -ansi'
actually permits

struct foo {
const int bar;
};

This fragment is strictly conforming. The "bar" member of a "struct
foo" is const-qualified and thus read-only. (Note that this is
different from the original example, which -- after spelling
corrections -- declared one member as "pointer to const struct
....", i.e., a read/write pointer to a read-only object.)
Does this mean what I think it means --- 'bar' can only be given a
value during initialization --- or is this just a quirk of GCC or
of the Standard?

The member named "bar" can indeed only be given a value via
initialization (in strictly conforming code anyway -- in practice,
"going behind the compiler's back" to write on the member tends
to "work", for some definition of "work" anyway).

Consider a larger structure:

struct S {
int a;
const int b;
int c;
};

An object of type "struct S" has three members named a, b, and c,
with a and c being read/write and b being read-only -- but by the
other rules about structures, the address of b has to be "between"
that of a and c. On conventional machines with page-granular memory
protection (e.g., 4096 or more bytes at a time are either read/write
or read-only), a "struct S" object will have to occupy wholly-read/write
memory. Thus, "sneaky" code such as:

struct S s_obj = { 1, 2, 3 };
...
int *p = &s_obj.a;
p[1] = 99; /* UNDEFINED, but tends to compile and run anyway */

will tend to overwrite s_obj.b (note that I have assumed there
is no padding here!). The compiler is of course allowed to *assume*
that s_obj.b has not changed (in this case) so whether you can
*see* the change tends to be optimization-level-dependent, for
instance. (In other words, "don't do this". :) )

On another note, many embedded-systems C programmers like to
use volatile-qualified types for hardware register layout
data structures:

struct fooreg {
volatile int csr;
volatile int dar;
/* etc */
};

This is also valid, Standard C (although the precise meaning of
"volatile" is up to the compiler anyway). I do not share their
enthusaism: I prefer to make the structure contain ordinary,
unqualified types, and then have the pointer that points to that
structure carry the qualifier:

struct fooreg {
int csr;
int dar;
/* etc */
};
...
volatile struct fooreg *reg = (volatile struct fooreg *)addr;

I have two reasons for this, one of which I think is easier to
argue for: the unqualified "struct" version allows you to copy the
hardware registers to software data structures for debugging, and
yet get the software-structure access optimized without having the
optimization interfere with real hardware access. (As it turns
out, to make device drivers portable across widely different
architectures, it is often a good idea not to use such structures
in the first place -- at least not directly, anyway.)
 
R

Richard Pennington

Skybuck said:
Well now I'm confused.

Does it mean

1. The pointer is read only.
2. The structure is read only.

?

:)

Lot's of good answers below this, but...

Here is another:

const struct Type2 *Field2; // Field2 is a pointer to a const struct Type2.

struct Type2 * const Field2; // Field2 is a const pointer to a struct Type2.

In the first the struct is read only. In the second the pointer is readonly.

-Rich

P.S. Am I the only one who has found reading declarations from the
inside out helps in C? e.g:
int (*f)[10]; // f is a pointer to an array of 10 int.

You have to understand the rules of "inside out" unfortunately.
 
T

Thomas L.

Emmanuel Delahaye said:
Skybuck Flying wrote on 11/08/04 :


It means that the 'struct Type2' pointed by 'Field2' is read only when
you use Field2 to access it.

so:
imagine we define somewhere,
struct Type2 {
int foo;
};

int bar;
struct Structure1 s1;
bar = s1.Field2->foo; //Valid because read-only?
s1.Field2->foo = bar; //Non valid because Field2 is read-only through
s1.Field2

struct Type2 *s2_;
s2 = s1.Field2; // Is it valid? There is an implicit const cast
here
s2->foo = bar; // if previous line ok, it is an access to
s1.Field2 but via // a different pointer.

If the example given is valid (the structure that s1.Field2 points at
can be modified provided you do not use the s1.Field2 access), could
the restrict keyword help the programmer in having a truly read-only
part of Structure1?

Thomas
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,767
Messages
2,569,571
Members
45,045
Latest member
DRCM

Latest Threads

Top