## a question!

### a question!

in general the size of a pointer in 32 OS is 4 bytes
in a embedded OS the size of a pointer is still 4 bytes??

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated.    First time posters: Do this! ]

### a question!

> in general the size of a pointer in 32 OS is 4 bytes
> in a embedded OS the size of a pointer is still 4 bytes??

The C++ standard does not specify the specific sizes of any intrinsic data
type. It does specify a relationship between sizes for some of the intrinsic
data types. You need to consult the implementation docs for your embedded OS
to see what is the size of the various C++ pointer types.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated.    First time posters: Do this! ]

### a question!

> in general the size of a pointer in 32 OS is 4 bytes
> in a embedded OS the size of a pointer is still 4 bytes??

The best thing to do is write a program which runs on the embedded OS
and reports the size of a pointer.

But in general a 32 bit embedded OS will have 4 byte pointers. (Of
course there are 16 and 64 bit embedded OSs.)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated.    First time posters: Do this! ]

### a question!

Quote:> in general the size of a pointer in 32 OS is 4 bytes

Typically, yes.  A byte is typically 8 bits, and a 32 bit operating
system addresses memory using 32 bit addresses.  The
logic is simple:  32/8 == 4.

There is no formal guarantee that this is the case, but in
practice it tends to be.

Quote:> in a embedded OS the size of a pointer is still 4 bytes??

Several modern embedded operation systems are also
32 bit systems.   So ....

There are older operating systems (embedded and otherwise)
that are not 32 bit though.   And embedded operating systems
that aren't 32 bit are still likely to be around.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated.    First time posters: Do this! ]

### a question!

> > in general the size of a pointer in 32 OS is 4 bytes
> > in a embedded OS the size of a pointer is still 4 bytes??

> The C++ standard does not specify the specific sizes of any intrinsic data
> type. It does specify a relationship between sizes for some of the intrinsic
> data types. You need to consult the implementation docs for your embedded OS
> to see what is the size of the various C++ pointer types.

I thought that sizeof char is ALWAYS 1 ...

--
For an idea to be fashionable is ominous, since it must afterwards be
always old-fashioned.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated.    First time posters: Do this! ]

### a question!

on 2 Aug 2003 18:24:57 -0400,

>> > in general the size of a pointer in 32 OS is 4 bytes
>> > in a embedded OS the size of a pointer is still 4 bytes??
>>
>> The C++ standard does not specify the specific sizes of any intrinsic data
>> type. It does specify a relationship between sizes for some of the intrinsic
>> data types. You need to consult the implementation docs for your embedded OS
>> to see what is the size of the various C++ pointer types.
>
> I thought that sizeof char is ALWAYS 1 ...

sizeof(char) *is* always 1. That doesn't automatically mean that
sizeof(char) != sizeof(char *)

Regards,
Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
how fast light travels it finds the darkness has always got there first,
and is waiting for it."                  -- Terry Pratchett, Reaper Man

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated.    First time posters: Do this! ]

### a question!

> The C++ standard does not specify the specific sizes of any intrinsic data type.

sizeof(char) == sizeof(signed char) == sizeof(unsigned char) == 1

Furthermore, all arrays of character types of any dimensionality
have a size exactly equal the number of elements they contain.
Eg., sizeof(unsigned char[3][3][3]) == 27.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated.    First time posters: Do this! ]

How does VB deal with this?  You have a form with a timer on it.  The
timer events fires off, but before the code completes, the timer event
fires again.

What actually happens?  Does the code that was executing continue
until it runs out of code to execute or a doevents, _then_ the code
for the subsequent timer event begins?  Or do they execute
concurrently?  Or does the most recent timer event suddenly take over?

If there's a doevents in the code that was first running, and the same
set of code starts executing because the timer has again fired, then
what states are the variables in?  Is it like a recursive routine and
all the local non-static variables start from scratch and can be
altered by the code originally running without affecting the values of
the same variable in the code being executed by the second timer
event?  And all the static and module scope/global scope variables --
when they get altered by one instance of the code then the they are
altered for the other instance of the timer code?

And does this apply to controls such as winsock and the serial port
control where data can arrive before previous data has been processed?

I'm asking all this because I'm trying to develop a client-server
system using winsock & IP as the communications mechanism.  I suspect
that I may really be wanting multithreading, but I'm not sure that I
can really justify spending the time setting up a multithreading app.
On the other hand trying to do it without threads may be a
fundamentally flawed approach.  Can anyone cast some light on these
issues or refer me to a site that discusses them?

thanx for any help.