Re: question on structs and memory blocks



Alfonso Morra wrote On 09/28/05 17:21,:
>
> ajm wrote:
>
>
>>Hi Alfonso,
>>
>>1) no you do not need to disect your struct and compute the sum of the
>>component sizes in this fashion ! you can just apply sizeof() to
>>MyStruct and in fact it is better to do so since sizeof() includes any
>>padding etc. necessary to accommodate the structure components. Also I
>>see a strlen in there (?) your structure does not contain the strings
>>but merely pointers to them, it is the cost of these pointers that
>>contributes to the size of the structure rather than the length of the
>>strings.
>
>
> Think about it. If one stucture contains a string (char*) of length
> 1024, and the another variable of the same data type contains a string
> (char*) of length 16, sizeof (DataStructure) will not report any
> difference in size between the two variables. This is patently wrong
> (see below)

I can't find anything called DataStructure in the
code you posted (see up-thread). Are you referring to
MyStruct? That seems likely, because the first question
you asked was

>>> 1). Is my calculation of the number of bytes used by
>>> MyStruct correct?

For the usual C meaning of "number of bytes used" the
answer is "No." The size of MyStruct is sizeof(MyStruct),
not the sum of the sizes of its elements plus the size of
other things in other places that some of its elements
happen to point at.

What you're really after, it seems, is not the size of
a MyStruct instance, but the number of bytes in a "serialized
version," that is, the length of some kind of encoding of
the data represented by a MyStruct and its dependents. This
latter count depends on the "on the wire" representation you
choose; if you like, it depends on your protocol.

>>2) you need to be clear by what you mean by "copy" a structure e.g., do
>>you want to "copy pointers" (after which both structures contains
>>pointers to the same string in memory) or do you want to "make copies
>>of pointers" (after which each structure has pointers to its own copies
>>of strings which could change over time) - in the former a memcpy of
>>size sizeof(MyStruct) suffices, in the latter a component copy (perhaps
>>using strdup for char pointers) might be what you need.
>
> I may have not asked the question correctly. But put simply, I need to
> make a copy of a nested structure. A 'proper' copy, so that the
> structure can be sent to another process on a different machine - you
> may recall that I DID say that I was writing a messaging library. It
> would be the second type of copying that I am interested in since the
> data is being sent accross process boundaries and any raw pointers would
> be meaningless in another process space.

Put simply, this is not what is usually called a "copy."
(Nor do I see anything in your code that I'd call a "nested
structure:" There's only one struct type shown, and it contains
no other struct types.)

You'll probably find it helpful to think not of "copies"
but of internal and external representations of your data.
The two machines may use entirely different representations
even if the MyStruct declarations are identical (the struct
padding may differ, the sizes of ints and enums and whatnot
may differ, the endianness of numbers may differ, and so on).

To reconcile their idiosyncratic internal representations,
the two machines must agree on a common external representation
or "wire format." The sender converts its internal data to
the agreed-upon wire format and transmits it, and the receiver
converts the incoming bytes to its own internal representation.

Since the two internal representations may use different
byte counts to represent "the same" data, the number of bytes
used by one machine is pretty much irrelevant to the other,
and pretty much useless as a component of the wire format.
You might be interested in the number of bytes in the external
representation of some data -- for example, if your protocol
involves a header that declares how many payload bytes follow
it -- but that's not the same thing as the number of bytes
the local in-memory representation requires.

--
Eric.Sosman@xxxxxxx

.

Relevant Pages

  • Re: question on structs and memory blocks
    ... MyStruct and in fact it is better to do so since sizeofincludes any ... but merely pointers to them, it is the cost of these pointers that ... To reconcile their idiosyncratic internal representations, ... the two machines must agree on a common external representation ...
    (comp.lang.c)
  • Re: Increasing efficiency in C
    ... >> The representation of a string in C is the sequence of characters, ... strings, they are passed the addresses of strings. ... supports pointers the way it does. ... Competent programmers make mistakes, too. ...
    (comp.lang.c)
  • Re: ptr conversions and values
    ... >> precision complex number can have the same representation as a double. ... >> There's no sense in which a memory location and an integer are the same ... The standard doesn't either. ... What do pointers to _different_ struct types have in common ...
    (comp.std.c)
  • Re: A taxonomy of types
    ... I am describing how to represent the representation (and, ... if the system follows static typing rules (such as in a compiler), ... so, the hardware sees pointers and pointer arithmetic, but the compiler ... "Besides the char types, up to three sizes of integer, declared short int, ...
    (comp.lang.misc)
  • Re: ptr conversions and values
    ... > A complex number is not an array, ... representation, without providing an explanation of what pairs of values are ... to say it about pointers and integers. ... >>> and joins it with a complex type that expresses the same value. ...
    (comp.std.c)