<RITZ@discussions.microsoft.com> wrote in
message
news:0ab7fdae-8303-4a4e-95f9-5aee37fb96a6@discussions.microsoft.com
> Hi, I have a small suggestion that I think is neccissary for the next
> C++ standard release. The standard does not denote that structs need
> to be contiguous, I think that it should for a few reasons. I.E.
> Transfering whole structs accross a network and writting whole
> structs to files will be safe.
news:0ab7fdae-8303-4a4e-95f9-5aee37fb96a6@discussions.microsoft.com
> Hi, I have a small suggestion that I think is neccissary for the next
> C++ standard release. The standard does not denote that structs need
> to be contiguous, I think that it should for a few reasons. I.E.
> Transfering whole structs accross a network and writting whole
> structs to files will be safe.
To guarantee that, it is not even remotely sufficient to make structs
contiguous (I assume by "contiguous" you mean "lacking padding between
members"). You need to specify the exact binary representation of every data
type down to the last bit. Every compiler on every platform must agree on
representation (remember - the application on the other end of that network
connection might be running on a completely different platform than
yours).
This is clearly impractical. The C++ fundamental data types should match
the representation native to the platform the program is running on. Otherwise,
you essentially are running an emulation layer, which would be very slow and
inefficient. C and C++ are intended to be "close to the metal", with performance
near to what one could achieve coding in the platform's native machine language
directly.
Besides, padding is necessary to establish proper alignment for struct
members. While on x86 processors an improper alignment is merely an
inconvenience, on many other CPU architectures it is fatal - the CPU generates a
hardware exception (basically, crashes) when asked to access misaligned
data.
> Win32 API even assumes that structs
> are contiguous in a few places such as notify message structs that
> place a NMHDR struct at the beginning of larger structs passed as a
> pointer through the LPARAM on a WM_NOTIFY message.
> are contiguous in a few places such as notify message structs that
> place a NMHDR struct at the beginning of larger structs passed as a
> pointer through the LPARAM on a WM_NOTIFY message.
This is already safe according to the current C++ standard, no change
necessary:
9.2/17: A pointer to a POD-struct
object, suitably converted using a reinterpret_cast, points to
its initial member (or if that member is a bitfield, then to the unit in which
it resides) and vice versa. [Note:
There might therefore be unnamed
padding within a POD-struct object, but not at its beginning, as necessary to
achieve appropriate alignment. ]
> Most IDEs already handle structs contiguously
What do IDEs (Integrated Development Environments) have to do with this
anyway Are you perhaps confusing an IDE with a compiler
--
With best wishes,
Igor Tandetnik
--
With best wishes,
Igor Tandetnik
Suggestion for the next standard...
asmana
Most IDEs already handle structs contiguously so it won't be a big deal...
Even simpler, just add a "contig" keyword for structs...
Yaachiru
I believe that the current C++ Standard already requires this:
1.8/1
The constructs in a C + + program create, destroy, refer to, access, and manipulate objects. An object is a region of storage.
1.8/8
Unless it is a bit-field (9.6), a most derived object shall have a non-zero size and shall occupy one or more bytes of storage. Base class sub-objects may have zero size. An object of POD4) type (3.9) shall occupy contiguous bytes of storage.
The C Standard is even more restrictive:
6.2.6.1/2
Except for bit-fields, objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined.
vmadan16
news:f3787822-6f06-434e-8047-16b3ce7a6ee2@discussions.microsoft.com
>> This is already safe according to the current C++ standard, no
>> change necessary:
> But what if you want to refference more than the first element
> I don't see where your coming from with platform independence, the
> platform is totally irrelevant.
--
With best wishes,
Igor Tandetnik
Russ Monckton
>This is already safe according to the current C++ standard, no change necessary:
But what if you want to refference more than the first element
I don't see where your coming from with platform independence, the platform is totally irrelevant.
Whatever... forget it I guess.