Structure size

[Bruce.]

I would like to allocate a structure size of 1024 bytes but I want the
compiler to do the calculation for me.

typedef struct
{
int var1;
int var2;
int var3;
char var4[ ?????? ];
} MYSTRUCT;

What I want to do is replace the ?????? something that will automattically
make the total structure 1024 bytes without having to manually count the
bytes of the other members myself.

Is that possible in c++?

Thanks.

Bruce.

[Bo Persson]

BobR wrote:
:: James Kanze <ja*********@gm ail.comwrote in message...
:: On Jul 22, 9:03 pm, "Victor Bazarov" <v.Abaza...@com Acast.net>
:: wrote:
::
:::: struct mystruct {
:::: int var1, var2, var3;
:::: char data[1024 - offsetof(data)];
::
::: That's "offsetof( mystruct, data )", of course (as you've
::: already corrected).
::
:::: };
:::: Should that alleviate any trouble with possible padding?
::
::: I don't think you can use offsetof on an incomplete type.
::
:: As poor Bruce found out.
::
:: If you can't find a sane way to do it, think outside the box.
::
:: struct dummy{
:: int var1, var2, var3;
:: char data[1];
:: };
::
:: struct mystruct{
:: int var1, var2, var3;
:: char data[ 1024 - offsetof( dummy, data ) ];
:: };
::
:: // cout<<"sizeof dummy="<<sizeof (dummy)<<std::e ndl;
:: // cout<<"sizeof mystruct="<<siz eof(mystruct)<< std::endl;
:: // sizeof dummy=16
:: // sizeof mystruct=1024
::
::
:: We'd have to assume (or prey) that the compiler would construct
:: the two structs the same (up to 'data').
::

Unfortunately, I don't think we can be sure about that (except in
practice:-).

An architecture odd enough to require padding between integers, or
between an integer and a char, could of course have different padding
for an odd number of characters (char[1]) and an even number of
characters (assuming, again, that's what we get :-).

I think [1024 - 3 * sizeof(int)] would work just as well. Otherwise we
should also start to think about the size of a byte. Are there 8 bits
in a char?!

Bo Persson

[BobR]

Bo Persson <bo*@gmb.dkwrot e in message...

BobR wrote:
:: James Kanze <ja*********@gm ail.comwrote in message...
::
::: I don't think you can use offsetof on an incomplete type.
::
:: As poor Bruce found out.
:: If you can't find a sane way to do it, think outside the box.
:: struct dummy{
:: int var1, var2, var3;
:: char data[1];
:: };
:: struct mystruct{
:: int var1, var2, var3;
:: char data[ 1024 - offsetof( dummy, data ) ];
:: };
:: // cout<<"sizeof dummy="<<sizeof (dummy)<<std::e ndl;
:: // cout<<"sizeof mystruct="<<siz eof(mystruct)<< std::endl;
:: // sizeof dummy=16
:: // sizeof mystruct=1024
:: We'd have to assume (or prey) that the compiler would construct
:: the two structs the same (up to 'data').
::

Unfortunately, I don't think we can be sure about that (except in
practice:-).

An architecture odd enough to require padding between integers, or
between an integer and a char, could of course have different padding
for an odd number of characters (char[1]) and an even number of
characters (assuming, again, that's what we get :-).

I think [1024 - 3 * sizeof(int)] would work just as well. Otherwise we
should also start to think about the size of a byte. Are there 8 bits
in a char?!

No, there are 8 bits in a byte (Webster's <G>). If the byte is RAM, it's 9
bits (the parity bit :-}) in many/most machines in use (Intel,AMD (did Apple
completely drop Motorola?)). [ loosely speaking. ]
That's one thing I (slightly) miss about Assembler, being able to lay out
things exactly where I want them. What I don't miss is the memory management
(real, flat, protected (IA32)). So 'char' don't look so bad from where I
sit. I let the compiler worry about it's size in 9999 of 10000 cases.

The OP should be using Assembler for what (s)he wants to do, IMHO.
Or, 'std::vector<un signed charMyStruct(10 24)', and some *heavy* casting
(dang endians!). <G>

--
Bob R
POVrookie

[Richard Heathfield]

BobR said:

<snip>

>
No, there are 8 bits in a byte (Webster's <G>).

Webster's is not normative. In both C and, I am given to understand,
C++, there are CHAR_BIT bits in a byte, where CHAR_BIT is at least 8. A
byte is exactly big enough to store one char.

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

[BobR]

Richard Heathfield <rj*@see.sig.in validwrote in message...

BobR said:
<snip>

No, there are 8 bits in a byte (Webster's <G>).

[ I should have 'double-grin'-ed that line. ]

>
Webster's is not normative. In both C and, I am given to understand,
C++, there are CHAR_BIT bits in a byte, where CHAR_BIT is at least 8.
A byte is exactly big enough to store one char.

Yep. In C || C++, I'd go by the CHAR_BIT.
"...., there are CHAR_BIT bits in a 'char' ", would be more proper
terminology, I think.

--
Bob R
POVrookie

[Jerry Coffin]

In article <F4************ *********@bgtns c04-news.ops.worldn et.att.net>,
re***********@w orldnet.att.net says...

[ ... ]

Yep. In C || C++, I'd go by the CHAR_BIT.
"...., there are CHAR_BIT bits in a 'char' ", would be more proper
terminology, I think.

Not really -- as the terms are used in the standards, 'char' is a type
whereas 'byte' is an amount of storage. As it happens, the standards go
on to require that a byte is always exactly enough storage to hold an
object of type char (and, due to other requirements, signed char or
unsigned char).

Nonetheless, the type char is more or less distinct from the amount of
storage it occupies -- in particular, there are a few requirements on
the char type that go beyond the fact that it has to fit in one byte of
storage.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jul 23, 7:21 pm, "BobR" <removeBadB...@ worldnet.att.ne twrote:

No, there are 8 bits in a byte (Webster's <G>).

Then Webster's wrong. The original use was for 6 bits, on a
PDP-10, it was programmable (7 was conventionally used, but
implementations of C used 9), on a CDC mainframe, 10. Of
course, a byte was 8 bits on an IBM 360, and later on the
PDP-11, and those were very influential machines.

That's why line protocols are defined in terms of octets, and
not bytes.

If the byte is RAM, it's 9
bits (the parity bit :-}) in many/most machines in use (Intel,AMD (did Apple
completely drop Motorola?)). [ loosely speaking. ]

At one time, at least, a lot of machine memory used
auto-corrector codes (not parity). Something like 37 physical
bits for 32 accessible to the program. (Back in the good old
days, of course, memory was core. You could toggle your program
in on the front panel of one machine, turn the machine off, take
the memory board out, and insert it into another machine, and
still have your program. Times have changed, however, and I
don't quite see myself toggling in the machine instructions for
the latest Linux on a front panel. Even if the machine had a
front panel.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[LR]

James Kanze wrote:

On Jul 23, 7:21 pm, "BobR" <removeBadB...@ worldnet.att.ne twrote:

>No, there are 8 bits in a byte (Webster's <G>).

Then Webster's wrong. The original use was for 6 bits, on a
PDP-10, it was programmable (7 was conventionally used, but
implementations of C used 9), on a CDC mainframe, 10.

Did you mean 12? Or maybe you meant 10 characters per CPU word? AFAIR,
on CDC 6600s, Cyber 70s and 700s and and even the 800s in 700
compatibility mode (which I think they had) bytes were 12 bits,
essentially the size of a PP word, and characters were, well, thats a
can of worms, but the 63 and 64 character sets had 6 bit characters and
then I think there were variations on 8 and maybe 9 bit characters with
various packings and also 12 bit characters of two or maybe three kinds,
escaped 6 bit and 8 bits packed in 12. Of course I/O was another set of
problems. And I don't recall at all how the APL character set was
stored, but I think there may have been a few tricks.

Talk about fun! How do we read that file again?

LR

[James Kanze]

On Jul 24, 3:42 pm, LR <lr...@superlin k.netwrote:

James Kanze wrote:

On Jul 23, 7:21 pm, "BobR" <removeBadB...@ worldnet.att.ne twrote:

No, there are 8 bits in a byte (Webster's <G>).

Then Webster's wrong. The original use was for 6 bits, on a
PDP-10, it was programmable (7 was conventionally used, but
implementations of C used 9), on a CDC mainframe, 10.

Did you mean 12?

Maybe. It's been a very, very long time. I seem to remember
something about 6 10 bit bytes in a 60 bit word. But that could
be completely wrong.

My point was only that byte size has always varied.

--
James Kanze (Gabi Software) email: ja*********@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <11************ **********@k79g 2000hse.googleg roups.com>,
ja*********@gma il.com says...

[ 'byte' on Control Data mainframes ... ]

Maybe. It's been a very, very long time. I seem to remember
something about 6 10 bit bytes in a 60 bit word. But that could
be completely wrong.

It's backwards: the most common setup was 10 6-bit bytes in a 60-bit
word.

My point was only that byte size has always varied.

....and that is certainly valid.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[LR]

Jerry Coffin wrote:

In article <11************ **********@k79g 2000hse.googleg roups.com>,
ja*********@gma il.com says...

[ 'byte' on Control Data mainframes ... ]

>Maybe. It's been a very, very long time. I seem to remember
something about 6 10 bit bytes in a 60 bit word. But that could
be completely wrong.

It's backwards: the most common setup was 10 6-bit bytes in a 60-bit
word.

No. It was six bit characters. The bytes were 12 bits, the size of a PP
word.

>

>My point was only that byte size has always varied.

...and that is certainly valid.

Have to agree with that.

LR