const field in structure

Discussion in 'C Programming' started by Skybuck Flying, Aug 11, 2004.

  1. 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
     
    Skybuck Flying, Aug 11, 2004
    #1
    1. Advertising

  2. Skybuck Flying

    Rob Kennedy Guest

    Skybuck Flying wrote:
    > 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

    --
    Rob
     
    Rob Kennedy, Aug 11, 2004
    #2
    1. Advertising

  3. 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.

    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

    "C is a sharp tool"
     
    Emmanuel Delahaye, Aug 11, 2004
    #3
  4. "Emmanuel Delahaye" <> wrote in message
    news:...
    > 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.


    Well now I'm confused.

    Does it mean

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

    ?

    :)
     
    Skybuck Flying, Aug 11, 2004
    #4
  5. On Wed, 11 Aug 2004, Skybuck Flying wrote:
    >
    > "Emmanuel Delahaye" <> wrote...
    >> 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;

    [...]
    > 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
     
    Arthur J. O'Dwyer, Aug 11, 2004
    #5
  6. Skybuck Flying

    Rob Kennedy Guest

    Skybuck Flying wrote:
    > Does it mean
    >
    > 1. The pointer is read only.
    > 2. The structure is read only.


    The second one.

    --
    Rob
     
    Rob Kennedy, Aug 11, 2004
    #6
  7. Skybuck Flying wrote on 11/08/04 :
    >>> Struct {
    >>> Type1 Field1;
    >>> const struct Type2 *Field2; /* -ed- qualifier fixed */
    >>> } Structure1;


    > 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.

    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

    "C is a sharp tool"
     
    Emmanuel Delahaye, Aug 11, 2004
    #7
  8. Skybuck Flying

    Chris Torek Guest

    In article <>
    Arthur J. O'Dwyer <> writes:
    > 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.)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Aug 11, 2004
    #8
  9. Skybuck Flying wrote:

    > "Emmanuel Delahaye" <> wrote in message
    > news:...
    >
    >>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.

    >
    >
    > 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.

    --
    Richard Pennington
    Email:
    http://www.pennware.com ftp://ftp.pennware.com
     
    Richard Pennington, Aug 12, 2004
    #9
  10. Skybuck Flying

    Thomas L. Guest

    Emmanuel Delahaye <> wrote in message news:<>...
    > Skybuck Flying wrote on 11/08/04 :
    > >>> Struct {
    > >>> Type1 Field1;
    > >>> const struct Type2 *Field2; /* -ed- qualifier fixed */
    > >>> } Structure1;

    >
    > > 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.


    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
     
    Thomas L., Aug 12, 2004
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    11
    Views:
    1,124
  2. Javier
    Replies:
    2
    Views:
    584
    James Kanze
    Sep 4, 2007
  3. 0m
    Replies:
    26
    Views:
    1,142
    Tim Rentsch
    Nov 10, 2008
  4. fungus
    Replies:
    13
    Views:
    901
    fungus
    Oct 31, 2008
  5. Replies:
    2
    Views:
    545
    Andrew Koenig
    Feb 9, 2009
Loading...

Share This Page