Topic: Why's of C++ -- Part 6 (packed discussion)
Author: Pete Becker <petebecker@acm.org>
Date: 1999/09/04 Raw View
Barry Margolin wrote:
>
> In article <37CEAEB6.879B6523@acm.org>,
> Pete Becker <petebecker@acm.org> wrote:
> >Nick Ambrose wrote:
> >>
> >> Barry Margolin wrote:
> >>
> >> > In article <7qhdjb$nrc$1@sass1828.sandia.gov>,
> >> > rob <post_replies_ple@se.thanks> wrote:
> >> > >And what about COM? Doesn't it rely on a particular
> >> > >object layout?
> >> >
> >> > Unless someone has patented that particular layout, it shouldn't be a
> >> > problem.
> >>
> >> Believe it or not, I think Microsoft is indeed attempting to patent
> >such a thing.
> >>
> >
> >They've applied for various patents on their C++ compiler's object
> >layout, but I haven't heard of any patent applications on the layout of
> >COM objects. Since a COM object is nothing but a vtable pointer, there's
> >lots of prior art, so it isn't patentable.
>
> What's being talked about is the layout of marshalled data in the network
> protocol.
>
??? What's being talked about here is many different things, all
involving variations of a few undefined terms.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1999/09/06 Raw View
Adam Spragg wrote:
>
>
> And there isn't ample prior art with regards to compiler object layout?
>
They weren't asking for a patent on "object layout," which is only a
broad description, but on particular details that they handle
differently from others.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: zivca@netvision.net.il (Ziv Caspi)
Date: 1999/09/06 Raw View
On 03 Sep 99 14:49:59 GMT, Barry Margolin <barmar@bbnplanet.com>
wrote:
>What's being talked about is the layout of marshalled data in the network
>protocol.
IIRC, what they're trying to patent is their method of handling
multiple inheritence, with thunks and all.
---------------------------------------------
Ziv Caspi
zivca@netvision.net.il
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: postmast.root.admi.gov@iname.com (blargg)
Date: 1999/09/02 Raw View
In article <MPG.12374f71ba4d5c1f9896d9@news.nabs.net>, Jeff Rife
<jrife-news@nabs.net> wrote:
> blargg (postmast.root.admi.gov@iname.com) wrote:
>
> > In article <7qe39l$qk6$1@news.hal-pc.org>, "Greg Brewer"
> > <nospam.greg@brewer.net> wrote:
> >
> > > Define incorrect alignment.
> >
> > In C++: An object at an address that doesn't meet the alignment
> > requirements for the object.
> >
> > For a particular architecture: Two cases, one is a non-opitmal alignment
> > where accesses take longer, but are still handled in hardware. The other
> > is a misaligned case where the processor takes some type of alignment
> > exception. The exception handler could abort the program, or emulate the
> > acces (at a great speed hit compared to the other alignment cases).
> >
> > I was talking about the latter case for a particular architecture, where
> > the processor raises an exception for the OS to handle.
>
> Oh, yuck. I never thought of this (mostly because it is horrendously ugly,
> but I suppose an implemenation would be conforming if it handled the
> "suitably aligned" problem by throwing OS exceptions (or other equivalent
> behavior), and providing a handler.
>
> It might be conforming, but such a compiler would be deleted from *my* hard
> drive, real fast.
I am unclear on what you're referring to here. An OS that emulates
misaligned accesses in software (with a great speed hit)? Don't laugh,
that's what MacOS does :-) Fortunately (at least on the version of the OS
I use) it is possible to patch the CPU misalignment handler and break into
the debugger. I much prefer catching misaligned accesses than having them
silently turned into a major speed hit.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1999/09/03 Raw View
rob wrote:
>
> And what about COM? Doesn't it rely on a particular
> object layout?
>
Yes, but a very simple one. A COM object is just a vtable pointer.
Everything else is just implementation details, of interest to the
person writing the code for the object, but irrelevant to COM itself.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1999/09/03 Raw View
Nick Ambrose wrote:
>
> Barry Margolin wrote:
>
> > In article <7qhdjb$nrc$1@sass1828.sandia.gov>,
> > rob <post_replies_ple@se.thanks> wrote:
> > >And what about COM? Doesn't it rely on a particular
> > >object layout?
> >
> > Unless someone has patented that particular layout, it shouldn't be a
> > problem.
>
> Believe it or not, I think Microsoft is indeed attempting to patent such a thing.
>
They've applied for various patents on their C++ compiler's object
layout, but I haven't heard of any patent applications on the layout of
COM objects. Since a COM object is nothing but a vtable pointer, there's
lots of prior art, so it isn't patentable.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Greg Brewer" <nospam.greg@brewer.net>
Date: 1999/09/01 Raw View
blargg <postmast.root.admi.gov@iname.com> wrote in message
news:user-3108990259340001@aus-as5-147.io.com...
> > > But what if some of the fields aren't even accessible, due to their
> > > incorrect alignment? That would make them quite usless as even having
> > > typed members. Better to just define a list of offsets to the members,
and
> > > use some other means of accessing them. I suppose the user could
define
> > > them in such a way that they would be accessible if the structure
itself
> > > were misaligned (odd byte boundary, for example).
> >
> > Define incorrect alignment.
>
> In C++: An object at an address that doesn't meet the alignment
> requirements for the object.
>
> For a particular architecture: Two cases, one is a non-opitmal alignment
> where accesses take longer, but are still handled in hardware. The other
> is a misaligned case where the processor takes some type of alignment
> exception. The exception handler could abort the program, or emulate the
> acces (at a great speed hit compared to the other alignment cases).
>
> I was talking about the latter case for a particular architecture, where
> the processor raises an exception for the OS to handle.
Even in the later case, it might be possible for the compiler to handle it.
Just bit copy the value to a temporary aligned location, use it, bit copy
any changes back afterward. I do see problems such as passing the address
of this misaligned object. The answer may be to disallow taking the address
of a misaligned floating point value. In any case, I see the need for a
data structure with no padding so that it may be exchanged with other
executables.
> > The standard would dictate the scope and syntax. Something we don't
have
> > now.
>
> I don't really see any question as to what is right. When the #pragma is
> encountered, any structure definitions after that will have their members
> arranged using some alternate layout (for example, no padding). There
> would also be a corresponding #pragma to go back to normal structure
> member layout.
I have no way of knowing if your definition of the scope fits any actual
implementation or not. I tried to look it up; however, my Borland C++ 5.01
does not document a packed pragma. Moreover, it does not provide a
mechanism for limiting the scope of the change. I could use an option to
change to packed. Once I no longer care though, I can't go back to what it
is. I can change it to unpacked but there is no assurance that it was
unpacked earlier.
> If a compiler supports some form of alternate structure member layout, it
> should follow this model.
>
> > > > I like the chances that two compilers interpretation of a packed
> > > > structure are compatible than that they are for two plain
structures.
> > >
> > > I can't parse this.
> >
> > Can't help you.
>
> You wrote it. I was assuming you'd rewrite it so that it was parsable. I
> guess you aren't. Why even bother posting if your goal isn't for others to
> be able to read (parse) what you write?
>
> > > > Still, I do need to pass data between dll's
> > > > compiled with BC++ 5.01 and the latest version and with MS and with
> > other
> > > > platforms. It would make my life easier if they could understand
that
> > these
> > > > dll's are expecting/sending data in a packed format.
> > >
> > > Tell them that. If they think it's important, then one (or both - but
> > > probably not both :-) will make it easier to exchange data.
> >
> > I don't know how. That's the point; I standard method for telling a
> > compiler. Suppose I need to share a structure definition to the ABC
Super
> > C++ compiler.
>
> Then ABC Super C++ compiler needs to have some sort of compatible
> structure layout. As others have mentioned, this is usually accomplished
> with a common ABI.
That is evasive. I need to tell the compiler to pack one -- and only one --
structure. Other than that one, I don't care. What is the syntax of the
pragma I need to accomplish this?
> > > > I would disagree on the endian-ness one; that is primarily a cpu
issue.
> > >
> > > The CPU of the machine I use can be put into either little-endian or
> > > big-endian mode.
> >
> > Hence, the word "primarily".
>
> And it's a compiler issue too. The compilers have to agree on the
> endian-ness of the representation, just as they have to (commonly) agree
> on the size of int, etc.
Only when the cpu doesn't dictate the endian-ness. That is rare.
> > > What are you asking for, exactly, then? Your compilers to be more
> > interoperable?
> >
> > No, I want all compilers to be more interoperable.
>
> *All* compilers. Can you elaborate? Across platforms too?
Perhaps. Interoperability on the same platform is my primary concern. It
helps make reusable tools possible if you can pass someone a .dll along with
a header file or two and let them use it. I wish .lib files were
exchangable; however, that is not a compiler issue.
> > That is my point. The syntax for asking for packed is not standard, nor
is
> > the scope.
>
> But packed is up to interpretation too. Argh. There are more issues than
> you seem to want to acknowledge. These are for vendors of a particular
> platform/hardware architecture to agree on. The issues vary from one
> hardware platform to another, so that trying to standardize them would do
> more harm than good.
No, you are trying to create issues where there are none. I want to be
able to tell a compiler to optimize a structure for size. I want to tell
the compiler this in a header file so the that compiler used can be BC++,
VC++, ABC++, etc. Right now, I can tell all of these compilers to do this
and, if I do, the structure's will match up. The problem is that I don't
know how to tell all the compilers to do it. Worst, there is a way to tell
BC++ to start byte alignment and start some other alignment; but, there is
no documented way to resume a previous alignment. I want precise syntax and
precise scope. Nothing more.
> > > > > I think the language as it stands is quite adequate for this task.
> > > >
> > > > Sorry, but you are wrong.
> > >
> > > I am wrong. Well, show me where I'm wrong. And don't say that I am
wrong
> > > about "adequate", since that's subjective. Put up or .....
> >
> > That is self evident.
>
> Welcome to my "friends" list... *plonk*
I am honored. I suspect I am in good company.
Greg Brewer
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Jeff Rife <jrife-news@nabs.net>
Date: 1999/09/02 Raw View
blargg (postmast.root.admi.gov@iname.com) wrote:
> In article <7qe39l$qk6$1@news.hal-pc.org>, "Greg Brewer"
> <nospam.greg@brewer.net> wrote:
>
> > Define incorrect alignment.
>
> In C++: An object at an address that doesn't meet the alignment
> requirements for the object.
>
> For a particular architecture: Two cases, one is a non-opitmal alignment
> where accesses take longer, but are still handled in hardware. The other
> is a misaligned case where the processor takes some type of alignment
> exception. The exception handler could abort the program, or emulate the
> acces (at a great speed hit compared to the other alignment cases).
>
> I was talking about the latter case for a particular architecture, where
> the processor raises an exception for the OS to handle.
Oh, yuck. I never thought of this (mostly because it is horrendously ugly,
but I suppose an implemenation would be conforming if it handled the
"suitably aligned" problem by throwing OS exceptions (or other equivalent
behavior), and providing a handler.
It might be conforming, but such a compiler would be deleted from *my* hard
drive, real fast.
--
Jeff Rife | "Maybe it won't be so bad. Just think what life
19445 Saint Johnsbury Lane | would be like without Tiffany."
Germantown, MD 20876-1610 | "We'd be unemployed! We're on the WB *with* her!"
Home: 301-916-8131 | -- Ryan and Jack Malloy, "...Unhappily Ever After"
Work: 301-770-5800 Ext 5335 |
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Nick Ambrose <nicka@interdyn.com>
Date: 1999/09/02 Raw View
Barry Margolin wrote:
> In article <7qhdjb$nrc$1@sass1828.sandia.gov>,
> rob <post_replies_ple@se.thanks> wrote:
> >And what about COM? Doesn't it rely on a particular
> >object layout?
>
> Unless someone has patented that particular layout, it shouldn't be a
> problem.
Believe it or not, I think Microsoft is indeed attempting to patent such a thing.
Nick
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Lisa Lippincott <lisa_lippincott@advisories.com>
Date: 1999/09/02 Raw View
Greg Brewer <nospam.greg@brewer.net> pleads:
> I want to be able to tell a compiler to optimize a structure for size.
I think others have done a fine job of pointing out why your needs
can't be met in a useful, portable way; and why such a mechanism
shouldn't be enshrined in the language.
But, for what it's worth, here's a darn-close-to-portable bit of code
you might be interested in:
template <class T>
class Packable<T>
{
private:
char bytes[ sizeof(T) ];
public:
Packable() {}
Packable( const T& a ) { memcpy( bytes, &a, sizeof(T) ); }
Packable& operator=( const T& a )
{
memcpy( bytes, &a, sizeof(T) );
return *this;
}
operator T() const
{
T result;
memcpy( &result, bytes, sizeof(T) );
return result;
}
};
Now you can declare a packed POD like this:
struct PackedPOD
{
Packable<char> a;
Packable<short> b;
Packable<int> c;
Packable<long> d;
};
Any you get roughly the packed structure you wanted. The behavior of
Packable<T> for a POD-type T is entirely determined by the standard;
the only problem you might run into is that an implementation could
add padding to either Packable<T> or PackedPOD. But I've never run
into an implementation that would.
Of course, if you want to make the format of this structure really
portable, you should really be using more flexible templates, like
Packable_Integer<Little_Endian, 32, Twos_Complement>. I leave
the definition of that template as an exercise for the reader.
--Lisa Lippincott
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/09/02 Raw View
In article <7qjqll$1thi$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>Perhaps. Interoperability on the same platform is my primary concern. It
>helps make reusable tools possible if you can pass someone a .dll along with
>a header file or two and let them use it. I wish .lib files were
>exchangable; however, that is not a compiler issue.
Which is exactly what an ABI is for. Unfortunately M$ in its wisdom has
not provided an acceptable ABI for its OS's. If I understand the issues
correctly M$ has even made matters worse by claiming intellectual
property rights on certain aspects of the layout of their code (vtables
etc.) as well as doing stupid things such as distinguishing between
struct and class in name mangling.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Adam Spragg <adam_spragg@novaclarion.com>
Date: 1999/09/03 Raw View
Pete Becker wrote:
>
> Nick Ambrose wrote:
> >
> > Believe it or not, I think Microsoft is indeed attempting to patent such a thing.
> >
>
> They've applied for various patents on their C++ compiler's object
> layout, but I haven't heard of any patent applications on the layout of
> COM objects. Since a COM object is nothing but a vtable pointer, there's
> lots of prior art, so it isn't patentable.
And there isn't ample prior art with regards to compiler object layout?
--
Apparently [...] police in many lands are now complaining that local
arrestees are insisting on having their Miranda rights read to them,
just like perps in American TV cop shows. When it's explained to them
that they are in a different country, where those rights do not exist,
they become outraged. Starsky and Hutch reruns, dubbed into diverse
languages, may turn out, in the long run, to be a greater force for
human rights than the [United States] Declaration of Independence.
-- Neal Stephenson (Cryptonomicon -
http://www.io.com/~mccoy/beginning_print.html)
----------------
The opinions expressed in this email are mine alone, and do not
neccesarily represent those of my employer, my parents, or the people
who wrote the email software I use.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1999/09/03 Raw View
In article <37CEAEB6.879B6523@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
>Nick Ambrose wrote:
>>
>> Barry Margolin wrote:
>>
>> > In article <7qhdjb$nrc$1@sass1828.sandia.gov>,
>> > rob <post_replies_ple@se.thanks> wrote:
>> > >And what about COM? Doesn't it rely on a particular
>> > >object layout?
>> >
>> > Unless someone has patented that particular layout, it shouldn't be a
>> > problem.
>>
>> Believe it or not, I think Microsoft is indeed attempting to patent
>such a thing.
>>
>
>They've applied for various patents on their C++ compiler's object
>layout, but I haven't heard of any patent applications on the layout of
>COM objects. Since a COM object is nothing but a vtable pointer, there's
>lots of prior art, so it isn't patentable.
What's being talked about is the layout of marshalled data in the network
protocol.
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Jeff Rife <jrife-news@nabs.net>
Date: 1999/09/03 Raw View
blargg (postmast.root.admi.gov@iname.com) wrote:
> I am unclear on what you're referring to here. An OS that emulates
> misaligned accesses in software (with a great speed hit)?
No, a compiler that does this. An OS *should* catch these things, to
make running a program more bulletproof.
There are 3 cases that a conforming compiler could do:
1. Aligned correctly for the processor and access is optimum
2. Aligned incorrectly for the processor, and access is slow, but works
3. Aligned incorrectly for the processor, and attempted access throws
a hardware exception, which the compiler supplies a handler for that
does something to make the data accessible
Number 1 is what we all want, I would think.
Number 2 could happen if you turn on "packing" or use weird casts on
certain hardware.
Number 3 would be where the compiler subsumes the OS's job on mis-aligned
data. The thing that made me say "yuck" was that this behavior can be
part of a conforming implementation, because your code does what it should,
regardless of the way the OS handles things.
--
Jeff Rife | "Only one human captain has ever survived battle
19445 Saint Johnsbury Lane | with a Minbari fleet...he is behind me...you are
Germantown, MD 20876-1610 | in front of me. If you value your lives,
Home: 301-916-8131 | be somewhere else."
Work: 301-770-5800 Ext 5335 | -- Ambassador Delenn, 2260
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1999/09/03 Raw View
In article <MPG.123a08a59ef59b1b9896db@news.nabs.net>,
Jeff Rife <jrife-news@nabs.net> wrote:
>There are 3 cases that a conforming compiler could do:
>
>1. Aligned correctly for the processor and access is optimum
>2. Aligned incorrectly for the processor, and access is slow, but works
>3. Aligned incorrectly for the processor, and attempted access throws
> a hardware exception, which the compiler supplies a handler for that
> does something to make the data accessible
One problem with #3 is that it make "fix" things that it shouldn't. Some
misaligned accesses are due to use of pointers that were not initialized
properly. Of course, the language doesn't require the system to catch
these; doing an incorrect fixup is just as conforming as crashing the
program.
Also, it should be noted that this is only applicable to processors that
signal a hardware exception on unaligned accesses. I don't know if any
extent processors do it, but it's also conceivable that a processor would
simply perform the access incorrectly. E.g. if an operation requires
4-byte alignment, it could simply ignore the two low-order bits when
interpreting the operand address. Only technique #2 can be used to work
around this.
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Adam Spragg <adam_spragg@novaclarion.com>
Date: 1999/09/04 Raw View
Barry Margolin wrote:
>
> What's being talked about is the layout of marshalled data in the network
> protocol.
>
I didn't think that that was even theirs. Aren't they using a published
standard (the OSF's DCE RPC protocol) for that?
Or are they attempting to patent the 'folded-in extended functionality'
they've bound to have added to the standard?
Adam
--
Why is it that the smaller and easier a bug is to fix, the less I want
to actually fix it?
----------------
The opinions expressed in this email are mine alone, and do not
neccesarily represent those of my employer, my parents, or the people
who wrote the email software I use.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: postmast.root.admi.gov@iname.com (blargg)
Date: 1999/09/01 Raw View
In article <7qe39l$qk6$1@news.hal-pc.org>, "Greg Brewer"
<nospam.greg@brewer.net> wrote:
> blargg <postmast.root.admi.gov@iname.com> wrote in message
> news:user-2908990554310001@aus-as5-025.io.com...
> > > I'm not suggesting that the standard dictate anything. My experience on
> the
> > > intel platform suggests that there are two ways of building a structure:
> > > optimized for speed and optimized for size. The only thing that I would
> > > expect the standard say about a pact structure is that it should be
> > > optimized for size.
> >
> > But what if some of the fields aren't even accessible, due to their
> > incorrect alignment? That would make them quite usless as even having
> > typed members. Better to just define a list of offsets to the members, and
> > use some other means of accessing them. I suppose the user could define
> > them in such a way that they would be accessible if the structure itself
> > were misaligned (odd byte boundary, for example).
>
> Define incorrect alignment.
In C++: An object at an address that doesn't meet the alignment
requirements for the object.
For a particular architecture: Two cases, one is a non-opitmal alignment
where accesses take longer, but are still handled in hardware. The other
is a misaligned case where the processor takes some type of alignment
exception. The exception handler could abort the program, or emulate the
acces (at a great speed hit compared to the other alignment cases).
I was talking about the latter case for a particular architecture, where
the processor raises an exception for the OS to handle.
> > > Some my say that is so vague as to be meaningless; however,
> >
> > Well, yeah. I assume you agree. Might as well just define "packed" as some
> > implementation-defined layout. Or we could just say that #pragma packed
> > means that. Ooops, it already allows the latter.
>
> The standard would dictate the scope and syntax. Something we don't have
> now.
I don't really see any question as to what is right. When the #pragma is
encountered, any structure definitions after that will have their members
arranged using some alternate layout (for example, no padding). There
would also be a corresponding #pragma to go back to normal structure
member layout.
If a compiler supports some form of alternate structure member layout, it
should follow this model.
> > > I like the chances that two compilers interpretation of a packed
> > > structure are compatible than that they are for two plain structures.
> >
> > I can't parse this.
>
> Can't help you.
You wrote it. I was assuming you'd rewrite it so that it was parsable. I
guess you aren't. Why even bother posting if your goal isn't for others to
be able to read (parse) what you write?
> > > Still, I do need to pass data between dll's
> > > compiled with BC++ 5.01 and the latest version and with MS and with
> other
> > > platforms. It would make my life easier if they could understand that
> these
> > > dll's are expecting/sending data in a packed format.
> >
> > Tell them that. If they think it's important, then one (or both - but
> > probably not both :-) will make it easier to exchange data.
>
> I don't know how. That's the point; I standard method for telling a
> compiler. Suppose I need to share a structure definition to the ABC Super
> C++ compiler.
Then ABC Super C++ compiler needs to have some sort of compatible
structure layout. As others have mentioned, this is usually accomplished
with a common ABI.
[snip]
> > > > > I'm wondering if it would not be of benefit if C/C++ had
> > > > > a similar structure modifier [packing - no padding].
> > > >
> > > > Nope. They would have to define a universal format. Other issues than
> > > > alignment are representation, endian-ness, bitfields, enums, integral
> > > > sizes, references (yes, really), etc.
> > >
> > > I would disagree on the endian-ness one; that is primarily a cpu issue.
> >
> > The CPU of the machine I use can be put into either little-endian or
> > big-endian mode.
>
> Hence, the word "primarily".
And it's a compiler issue too. The compilers have to agree on the
endian-ness of the representation, just as they have to (commonly) agree
on the size of int, etc.
> > > Personally, I would be happy if two compilers
> > > agreed on the alignment of data when the POD structure contained nothing
> but
> > > chars, shorts, longs, floats, doubles, and pointers. That list
> purposely
> > > omits ints. I'm not asking for something that guarantees agreement.
> >
> > What are you asking for, exactly, then? Your compilers to be more
> interoperable?
>
> No, I want all compilers to be more interoperable.
*All* compilers. Can you elaborate? Across platforms too?
[snip]
> > What's the difference? (as my comment a few reply blocks above mentions)
> >
> > #pragma packed
> >
> > <packed>
> >
> > Either is implementation-defined. Either requires some agreement between
> > compiler vendors. The first requires agreement on the #pragma name and
> > packed representation, while the second requires agreement on just the
> > packed representation. I don't see any real difference between the two.
>
> That is my point. The syntax for asking for packed is not standard, nor is
> the scope.
But packed is up to interpretation too. Argh. There are more issues than
you seem to want to acknowledge. These are for vendors of a particular
platform/hardware architecture to agree on. The issues vary from one
hardware platform to another, so that trying to standardize them would do
more harm than good.
> > > > > but that should negate the programmers ability to define a
> > > > > structure. Of course, some mechanism will have to be provided for
> > > moving
> > > > > to/from the packed format in those invironments.
> > > >
> > > > I think the language as it stands is quite adequate for this task.
> > >
> > > Sorry, but you are wrong.
> >
> > I am wrong. Well, show me where I'm wrong. And don't say that I am wrong
> > about "adequate", since that's subjective. Put up or .....
>
> That is self evident.
Welcome to my "friends" list... *plonk*
[snip 14 lines of . characters]
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1999/09/01 Raw View
Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37CBBF29.1B1DF138@acm.org...
> > On some hardware, some data types must be at addresses that are a
> > multiple of some number other than one. For example, a float might have
> > to be at an address whose value is a multiple of four. If the address
> > doesn't meet the requirement (i.e. the data is incorrectly aligned) the
> > program crashes. On such hardware, if a float occupies four bytes and a
> > char one byte, a struct like this must have padding:
>
> I am aware that some hardware has the restrictions you mention. It will not
> crash just because a float is incorrectly located. It will not crash until
> an attempt is made access the value of the float. On such a system, there
> are two possibility. One would be that floating point values would not be
> directly accessible in a packed structure. Two, and probably the more
> desirable, would be to pad the structure. If I remember correctly, a form
> of the restriction you speak of exists on the intel platform; it's just that
> the intel cpu will perform the necessary shift. However, this takes time
> and if the alignment has already been done then performance is improved. I
> would expect packing to have the most significant meaning on systems that
> can go either way rather than systems that must have it.
>
Yes, my answer was a bit simplified, because your question suggested
that you hadn't heard of this. Since you apparently have heard of
alignment, it's not at all clear why you asked for an explanation of it.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Jeff Rife <jrife-news@nabs.net>
Date: 1999/09/01 Raw View
Greg Brewer (nospam.greg@brewer.net) wrote:
> I am aware that some hardware has the restrictions you mention. It will not
> crash just because a float is incorrectly located. It will not crash until
> an attempt is made access the value of the float.
Actually, it shouldn't, not on a conforming implementation.
Although "packing" is not discussed in the standard, "suitable alignment" is,
and I can't imagine a conforming implementation going to the trouble of
setting up that "suitable alignment", only to throw it away to do the
"packing".
--
Jeff Rife | Coach: What's the story, Norm?
19445 Saint Johnsbury Lane |
Germantown, MD 20876-1610 | Norm: Thirsty guy walks into a bar. You
Home: 301-916-8131 | finish it.
Work: 301-770-5800 Ext 5335 |
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1999/09/01 Raw View
In article <7qhdjb$nrc$1@sass1828.sandia.gov>,
rob <post_replies_ple@se.thanks> wrote:
>And what about COM? Doesn't it rely on a particular
>object layout?
Unless someone has patented that particular layout, it shouldn't be a
problem.
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "James Kuyper Jr." <kuyper@wizard.net>
Date: 1999/08/28 Raw View
Barry Margolin wrote:
>
> In article <user-2708990131340001@as1-dialup-77.io.com>,
> blargg <postmast.root.admi.gov@iname.com> wrote:
> >What is a "packed structure" exactly? I haven't heard of such a universal
> >concept.
>
> Yet somehow many languages over the decades have managed to incorporate it.
>
> However, I believe that the way the standards define it, it's more like a
Incorrect - the standards do not define it at all. It's a pure
extension, no mention of it in the standard at all. What the standard
does describe is padding. Typically, "packed" means "no padding", but
the standard itself doesn't describe any way of turning off padding.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/08/28 Raw View
In article <37C5E43D.A2E31F63@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Microsoft has applied for patents on their C++ object layout. Nobody
>else likes their layout, thoush, so it's not a big loss.
But I guess that is going to cause awful problems to implementers that
need to support linking to VC++ generated executables.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 1999/08/28 Raw View
In article <7q6okl$1n8p$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>I'm not suggesting that the standard dictate anything. My experience on the
>intel platform suggests that there are two ways of building a structure:
>optimized for speed and optimized for size. The only thing that I would
>expect the standard say about a pact structure is that it should be
>optimized for size.
That is plain stupid. The best packing for size probably uses a
lossless compression algorithm of some form. Much of the time
optimisation of size and space is a matter of balance. Such decisions
are rightly QoI issues.
>
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@eng.sun.com (Steve Clamage)
Date: 1999/08/29 Raw View
"Greg Brewer" <nospam.greg@brewer.net> writes:
>I'm not suggesting that the standard dictate anything. My experience on the
>intel platform suggests that there are two ways of building a structure:
>optimized for speed and optimized for size. The only thing that I would
>expect the standard say about a pact structure is that it should be
>optimized for size. Some my say that is so vague as to be meaningless;
>however, I like the chances that two compilers interpretation of a packed
>structure are compatible than that they are for two plain structures.
>Historically, Borland compilers optimized for size and MS compilers were
>optimized for speed. Now that Borland has gone in MS's direction, the
>general need for a packed modifier is diminished.
If you limit the discussion to different compilers on the same
platform, the answer is not a "packed" keyword or pragma, whose
meaning would still depend on the compiler. The answer is an ABI,
which specifies class layouts. All implementations conforming
to the ABI generate compatible objects, by definition. You don't
need any help from the language standard to get compatibility.
If you are not limited to a single platform, the packed keyword
doesn't help at all. You would have to deal with different
sizes, endianness, and representation of basic types, quite
apart from class layout issues.
You might like to find some agreement among different platforms,
but history works against you. Intel and VAX have always been
little-endian, MC680x0 and SPARC have always been big-endian,
for starters. Even though Intel and VAX share endianness, the
bit patterns in memory of (for example) IEEE floating-point
values area different. (Yes, it is possible for each of two
fully-compliant IEEE implementations to be incompatible.)
But wait, it gets worse. On the SAME platform you can have
incompatible class layouts with the SAME compiler! Example 1:
The VAX supports several incompatible floating-point formats;
you choose which you want with compiler options. Example 2:
Solaris 7 running on UltraSPARC supports both 32-bit and 64-bit
programs; the data sizes and alignment are different in
different modes, and you select the mode by means of compiler
options. I won't mention the fact that different releases of
a given compiler on any platform might use different layouts.
The only thing a "packed" keyword or pragma can do is allow you
ask for smaller class size. It cannot, except by merest accident,
help you with portability of binary objects.
--
Steve Clamage, stephen.clamage@sun.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david@tribble.com>
Date: 1999/08/30 Raw View
Steve Clamage wrote:
>
> "Greg Brewer" <nospam.greg@brewer.net> writes:
>
>> I'm not suggesting that the standard dictate anything. My
>> experience on the intel platform suggests that there are two ways
>> of building a structure: optimized for speed and optimized for size.
>> The only thing that I would expect the standard say about a packed
>> structure is that it should be optimized for size. Some my say that
>> is so vague as to be meaningless; ...
>
> If you limit the discussion to different compilers on the same
> platform, the answer is not a "packed" keyword or pragma, whose
> meaning would still depend on the compiler. The answer is an ABI,
> which specifies class layouts. All implementations conforming
> to the ABI generate compatible objects, by definition. You don't
> need any help from the language standard to get compatibility.
> ...
>
> The only thing a "packed" keyword or pragma can do is allow you
> ask for smaller class size. It cannot, except by merest accident,
> help you with portability of binary objects.
Quite the contrary, in fact. For example, if you're selling a
library to customers for several platforms, you invariably end up
using macro magic in your header files, so that things like structure
packing (e.g., '#pragma pack') and function calling conventions
(e.g., '__cdecl' and '__declspec(dllimport)') don't get overridden
by the customer when he enables certain compiler flags. Multiply
this by the number of platforms you are targeting, and you can see
how quickly this leads to noisy header files containing all sorts
of macro magic. These kinds of things you end up fighting when you
try to be portable.
-- David R. Tribble, david@tribble.com --
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Greg Brewer" <nospam.greg@brewer.net>
Date: 1999/08/31 Raw View
blargg <postmast.root.admi.gov@iname.com> wrote in message
news:user-2908990554310001@aus-as5-025.io.com...
> > I'm not suggesting that the standard dictate anything. My experience on
the
> > intel platform suggests that there are two ways of building a structure:
> > optimized for speed and optimized for size. The only thing that I would
> > expect the standard say about a pact structure is that it should be
> > optimized for size.
>
> But what if some of the fields aren't even accessible, due to their
> incorrect alignment? That would make them quite usless as even having
> typed members. Better to just define a list of offsets to the members, and
> use some other means of accessing them. I suppose the user could define
> them in such a way that they would be accessible if the structure itself
> were misaligned (odd byte boundary, for example).
Define incorrect alignment.
> > Some my say that is so vague as to be meaningless; however,
>
> Well, yeah. I assume you agree. Might as well just define "packed" as some
> implementation-defined layout. Or we could just say that #pragma packed
> means that. Ooops, it already allows the latter.
The standard would dictate the scope and syntax. Something we don't have
now.
> > I like the chances that two compilers interpretation of a packed
> > structure are compatible than that they are for two plain structures.
>
> I can't parse this.
Can't help you.
> > Still, I do need to pass data between dll's
> > compiled with BC++ 5.01 and the latest version and with MS and with
other
> > platforms. It would make my life easier if they could understand that
these
> > dll's are expecting/sending data in a packed format.
>
> Tell them that. If they think it's important, then one (or both - but
> probably not both :-) will make it easier to exchange data.
I don't know how. That's the point; I standard method for telling a
compiler. Suppose I need to share a structure definition to the ABC Super
C++ compiler. Tell me how to tell that compiler that the structure is byte
aligned.
> > > > The Pascal language has
> > > > a keyword packed that is supposed to require a data structure exists
in
> > > > a condensed format.
> > >
> > > Packing isn't the only issue.
> > >
> > > > I'm wondering if it would not be of benefit if C/C++ had
> > > > a similar structure modifier.
> > >
> > > Nope. They would have to define a universal format. Other issues than
> > > alignment are representation, endian-ness, bitfields, enums, integral
> > > sizes, references (yes, really), etc.
> >
> > I would disagree on the endian-ness one; that is primarily a cpu issue.
>
> The CPU of the machine I use can be put into either little-endian or
> big-endian mode.
Hence, the word "primarily".
> > Personally, I would be happy if two compilers
> > agreed on the alignment of data when the POD structure contained nothing
but
> > chars, shorts, longs, floats, doubles, and pointers. That list
purposely
> > omits ints. I'm not asking for something that guarantees agreement.
>
> What are you asking for, exactly, then? Your compilers to be more
interoperable?
No, I want all compilers to be more interoperable.
> > > > For years, MS C++ and Borland C++ had trouble exchanging data
because
> > they
> > > > did not agree on the alignment. With the Builder product line,
Borland
> > > > finally bent to MS conventions. Some may point out that it is
possible
> > to
> > > > accomplish what I am suggesting using #pragmas;
> > >
> > > That is how it's done.
> >
> > I know someone would say that. Yes, that is how its done. How about
using
> > a packed modifier to indicate that a structure is packed and using
pragmas
> > to define what packed means?
>
> What's the difference? (as my comment a few reply blocks above mentions)
>
> #pragma packed
>
> <packed>
>
> Either is implementation-defined. Either requires some agreement between
> compiler vendors. The first requires agreement on the #pragma name and
> packed representation, while the second requires agreement on just the
> packed representation. I don't see any real difference between the two.
That is my point. The syntax for asking for packed is not standard, nor is
the scope.
> > > > but that should negate the programmers ability to define a
> > > > structure. Of course, some mechanism will have to be provided for
> > moving
> > > > to/from the packed format in those invironments.
> > >
> > > I think the language as it stands is quite adequate for this task.
> >
> > Sorry, but you are wrong.
>
> I am wrong. Well, show me where I'm wrong. And don't say that I am wrong
> about "adequate", since that's subjective. Put up or .....
That is self evident.
Greg Brewer
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
............................................................................
.............................................
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1999/08/31 Raw View
Greg Brewer wrote:
>
> blargg <postmast.root.admi.gov@iname.com> wrote in message
> news:user-2908990554310001@aus-as5-025.io.com...
> > > I'm not suggesting that the standard dictate anything. My experience on
> the
> > > intel platform suggests that there are two ways of building a structure:
> > > optimized for speed and optimized for size. The only thing that I would
> > > expect the standard say about a pact structure is that it should be
> > > optimized for size.
> >
> > But what if some of the fields aren't even accessible, due to their
> > incorrect alignment? That would make them quite usless as even having
> > typed members. Better to just define a list of offsets to the members, and
> > use some other means of accessing them. I suppose the user could define
> > them in such a way that they would be accessible if the structure itself
> > were misaligned (odd byte boundary, for example).
>
> Define incorrect alignment.
>
On some hardware, some data types must be at addresses that are a
multiple of some number other than one. For example, a float might have
to be at an address whose value is a multiple of four. If the address
doesn't meet the requirement (i.e. the data is incorrectly aligned) the
program crashes. On such hardware, if a float occupies four bytes and a
char one byte, a struct like this must have padding:
struct S
{
float f1;
char ch;
float f2;
};
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Greg Brewer" <nospam.greg@brewer.net>
Date: 1999/08/31 Raw View
Pete Becker <petebecker@acm.org> wrote in message
news:37CBBF29.1B1DF138@acm.org...
> On some hardware, some data types must be at addresses that are a
> multiple of some number other than one. For example, a float might have
> to be at an address whose value is a multiple of four. If the address
> doesn't meet the requirement (i.e. the data is incorrectly aligned) the
> program crashes. On such hardware, if a float occupies four bytes and a
> char one byte, a struct like this must have padding:
I am aware that some hardware has the restrictions you mention. It will not
crash just because a float is incorrectly located. It will not crash until
an attempt is made access the value of the float. On such a system, there
are two possibility. One would be that floating point values would not be
directly accessible in a packed structure. Two, and probably the more
desirable, would be to pad the structure. If I remember correctly, a form
of the restriction you speak of exists on the intel platform; it's just that
the intel cpu will perform the necessary shift. However, this takes time
and if the alignment has already been done then performance is improved. I
would expect packing to have the most significant meaning on systems that
can go either way rather than systems that must have it.
Greg Brewer
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1999/08/31 Raw View
In article <37CBBF29.1B1DF138@acm.org>,
Pete Becker <petebecker@acm.org> wrote:
>Greg Brewer wrote:
>> Define incorrect alignment.
>On some hardware, some data types must be at addresses that are a
>multiple of some number other than one. For example, a float might have
>to be at an address whose value is a multiple of four. If the address
>doesn't meet the requirement (i.e. the data is incorrectly aligned) the
>program crashes. On such hardware, if a float occupies four bytes and a
>char one byte, a struct like this must have padding:
>
>struct S
>{
>float f1;
>char ch;
>float f2;
>};
It's always possible to make a time/space tradeoff. If the structure were
packed, the floats would be accessed by first performing a 4-byte copy to a
properly aligned temporary, and then using this as the operand of the
floating point instruction. Voila, no padding, but no crashes.
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1999/08/31 Raw View
In article <7qe39l$qk6$1@news.hal-pc.org>,
Greg Brewer <nospam.greg@brewer.net> wrote:
>blargg <postmast.root.admi.gov@iname.com> wrote in message
>news:user-2908990554310001@aus-as5-025.io.com...
>> > I like the chances that two compilers interpretation of a packed
>> > structure are compatible than that they are for two plain structures.
>>
>> I can't parse this.
>
>Can't help you.
I think you meant: I like the chances that two compilers['] interpretation
of a packed structure are compatible [better than the chances of this] for
two plain structures.
Or, more simply: I think it's more likely that two compilers will interpret
a packed structure the same way than they will for plain structures.
This is probably true. Perhaps the standard could simply say that for a
packed POD, all members must be in the same order as the structure
declaration, and no padding is permitted between members or at the end of
the structure. Thus, sizeof(structure) should be the same as the sum of
sizeof(members), and if member1 immediately precedes member2 in the
structure then offsetof(structure,member2)-offsetof(structure,member1) ==
sizeof(member1).
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "rob" <post_replies_ple@se.thanks>
Date: 1999/08/31 Raw View
And what about COM? Doesn't it rely on a particular
object layout?
rob.
Francis Glassborow wrote in message ...
>In article <37C5E43D.A2E31F63@acm.org>, Pete Becker <petebecker@acm.org>
>writes
>>Microsoft has applied for patents on their C++ object layout. Nobody
>>else likes their layout, thoush, so it's not a big loss.
>
>But I guess that is going to cause awful problems to implementers that
>need to support linking to VC++ generated executables.
<snip>
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: postmast.root.admi.gov@iname.com (blargg)
Date: 1999/08/29 Raw View
In article <7q6okl$1n8p$1@news.hal-pc.org>, "Greg Brewer"
<nospam.greg@brewer.net> wrote:
> blargg <postmast.root.admi.gov@iname.com> wrote in message
> news:user-2708990131340001@as1-dialup-77.io.com...
> >
> > In article <7q43gp$2seb$1@news.hal-pc.org>, "Greg Brewer"
> > <nospam.greg@brewer.net> wrote:
> >
[snip]
> I'm not suggesting that the standard dictate anything. My experience on the
> intel platform suggests that there are two ways of building a structure:
> optimized for speed and optimized for size. The only thing that I would
> expect the standard say about a pact structure is that it should be
> optimized for size.
But what if some of the fields aren't even accessible, due to their
incorrect alignment? That would make them quite usless as even having
typed members. Better to just define a list of offsets to the members, and
use some other means of accessing them. I suppose the user could define
them in such a way that they would be accessible if the structure itself
were misaligned (odd byte boundary, for example).
> Some my say that is so vague as to be meaningless; however,
Well, yeah. I assume you agree. Might as well just define "packed" as some
implementation-defined layout. Or we could just say that #pragma packed
means that. Ooops, it already allows the latter.
> I like the chances that two compilers interpretation of a packed
> structure are compatible than that they are for two plain structures.
I can't parse this.
[snip]
> Still, I do need to pass data between dll's
> compiled with BC++ 5.01 and the latest version and with MS and with other
> platforms. It would make my life easier if they could understand that these
> dll's are expecting/sending data in a packed format.
Tell them that. If they think it's important, then one (or both - but
probably not both :-) will make it easier to exchange data.
[snip]
> > > The Pascal language has
> > > a keyword packed that is supposed to require a data structure exists in
> > > a condensed format.
> >
> > Packing isn't the only issue.
> >
> > > I'm wondering if it would not be of benefit if C/C++ had
> > > a similar structure modifier.
> >
> > Nope. They would have to define a universal format. Other issues than
> > alignment are representation, endian-ness, bitfields, enums, integral
> > sizes, references (yes, really), etc.
>
> I would disagree on the endian-ness one; that is primarily a cpu issue.
The CPU of the machine I use can be put into either little-endian or
big-endian mode.
[snip]
> Personally, I would be happy if two compilers
> agreed on the alignment of data when the POD structure contained nothing but
> chars, shorts, longs, floats, doubles, and pointers. That list purposely
> omits ints. I'm not asking for something that guarantees agreement.
What are you asking for, exactly, then? Your compilers to be more interoperable?
> > > For years, MS C++ and Borland C++ had trouble exchanging data because
> they
> > > did not agree on the alignment. With the Builder product line, Borland
> > > finally bent to MS conventions. Some may point out that it is possible
> to
> > > accomplish what I am suggesting using #pragmas;
> >
> > That is how it's done.
>
> I know someone would say that. Yes, that is how its done. How about using
> a packed modifier to indicate that a structure is packed and using pragmas
> to define what packed means?
What's the difference? (as my comment a few reply blocks above mentions)
#pragma packed
<packed>
Either is implementation-defined. Either requires some agreement between
compiler vendors. The first requires agreement on the #pragma name and
packed representation, while the second requires agreement on just the
packed representation. I don't see any real difference between the two.
[snip]
> > > but that should negate the programmers ability to define a
> > > structure. Of course, some mechanism will have to be provided for
> moving
> > > to/from the packed format in those invironments.
> >
> > I think the language as it stands is quite adequate for this task.
>
> Sorry, but you are wrong.
I am wrong. Well, show me where I'm wrong. And don't say that I am wrong
about "adequate", since that's subjective. Put up or .....
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Greg Brewer" <nospam.greg@brewer.net>
Date: 1999/08/26 Raw View
One of the problems I have experienced has to do with data alignment in a
POD class or struct. The standard makes it implementation defined as to how
data in the structure aligns the data. Which ever alignment is adopted by
the compiler is okay as long as the data structure stays within modules
build by the same module.
However when moving the data between modules, it is critical that data
offsets within the structure be the same. There are at lease two mechanism
that exist for this: 1)fwrite/fread, and 2) passing a pointer to a structure
as the argument to a function that is implemented inside a .dll. Of course
there are other mechanisms such as pipes that do the same thing.
The point is that it is necessary to have some point of agreement between
two modules that may have been compiled seperately. The Pascal language has
a keyword packed that is supposed to require a data structure exists in a
condensed format. I'm wondering if it would not be of benefit if C/C++ had
a similar structure modifier.
For years, MS C++ and Borland C++ had trouble exchanging data because they
did not agree on the alignment. With the Builder product line, Borland
finally bent to MS conventions. Some may point out that it is possible to
accomplish what I am suggesting using #pragmas; however, there is a problem
in that the pragma syntax may be different and I'm not sure about the scope
of the pragma. I believe that Borland now supports that MS pragma but the
original Borland C++ did not. If you wanted to back a data structure, you
used #pragma -options -a in one and some other syntax for the other. If you
wanted to created a header file for use by the other compiler, you had to
know the syntax or you were out of luck.
As I said, I'm not sure what the scope is of the #pragma. Consider,
#pragma pack ? // start packing
struct XYZ {
char x[3];
float y;
int z;
};
#pragma pack ? // go back to previous setting
struct ABC {
char a[3];
float b;
int c;
};
...
int foo1(XYZ *); // does this expect a pointer to a packed structure?
int foo2(ABC *); // does this expect a pointer at structure with default
packing?
...
{
XYZ xyz; // Is this created in a packed format?
ABC abc; // is this created in another format?
}
Not all cpu's can allow data to be accessed while it is stored in a packed
structure but that should negate the programmers ability to define a
structure. Of course, some mechanism will have to be provided for moving
to/from the packed format in those invironments.
Greg Brewer
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1999/08/26 Raw View
In article <7q43gp$2seb$1@news.hal-pc.org>,
Greg Brewer <nospam.greg@brewer.net> wrote:
>The point is that it is necessary to have some point of agreement between
>two modules that may have been compiled seperately. The Pascal language has
>a keyword packed that is supposed to require a data structure exists in a
>condensed format. I'm wondering if it would not be of benefit if C/C++ had
>a similar structure modifier.
The general expectation is that things like structure layout should be
specified by the ABI of the OS/CPU combination.
Just declaring something packed is not sufficient -- you also need to have
agreement on sizes of types (e.g. is a long 32 or 64 bits?), byte ordering,
etc.
The OS developer should specify the ABI, and all the compiler implementors
should conform to it, and then they can interoperate.
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 1999/08/27 Raw View
Greg Brewer wrote:
>
> One of the problems I have experienced has to do with data alignment in a
> POD class or struct. The standard makes it implementation defined as to how
> data in the structure aligns the data. Which ever alignment is adopted by
> the compiler is okay as long as the data structure stays within modules
> build by the same module.
>
> However when moving the data between modules, it is critical that data
> offsets within the structure be the same. There are at lease two mechanism
> that exist for this: 1)fwrite/fread, and 2) passing a pointer to a structure
> as the argument to a function that is implemented inside a .dll. Of course
> there are other mechanisms such as pipes that do the same thing.
>
> The point is that it is necessary to have some point of agreement between
> two modules that may have been compiled seperately. The Pascal language has
> a keyword packed that is supposed to require a data structure exists in a
> condensed format. I'm wondering if it would not be of benefit if C/C++ had
> a similar structure modifier.
[...]
The packed keyword in Pascal is not the solution to data
compatibility between compilers (two Pascal compilers could
still disagree f.ex. in the size of integer or the
representation of real). Instead packed is the Pascal solution
for bit fields:
/* C/C++ version */
struct int_properties
{
int size: 4;
int signed: 1; /* Would bool signed: 1 be allowed in C++? */
};
{ Pascal version }
type int_properties = packed record
size: 0..15; { takes 4 bits }
signed: boolean; { takes one bit }
end;
(I hope I got the syntax right - I've never used that
feature in any language.)
Another use of packed in Pascal is on arrays; f.ex.
packed array[0..999] of boolean;
is roughly eqivalent to C++'s
std::bitset<1000>
So the "packed" keyword doesn't give you what you want it for.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david@tribble.com>
Date: 1999/08/27 Raw View
Barry Margolin wrote:
>
> Greg Brewer <nospam.greg@brewer.net> wrote:
>> The point is that it is necessary to have some point of agreement
>> between two modules that may have been compiled seperately. The
>> Pascal language has a keyword packed that is supposed to require a
>> data structure exists in a condensed format. I'm wondering if it
>> would not be of benefit if C/C++ had a similar structure modifier.
>
> The general expectation is that things like structure layout should be
> specified by the ABI of the OS/CPU combination.
>
> Just declaring something packed is not sufficient -- you also need to
> have agreement on sizes of types (e.g. is a long 32 or 64 bits?),
> byte ordering, etc.
>
> The OS developer should specify the ABI, and all the compiler
> implementors should conform to it, and then they can interoperate.
I should point out that one way to approach the goal of
nearly-portable data structures is to 1) use data types of known
sizes, and 2) arrange the struct members so that extraneous padding
is avoided.
For example:
struct Data
{
void * handle; // Pointers first
uint32_t flags; // 32-bit type
int16_t dtype;
unsigned u_mode: 3;
unsigned g_mode: 3;
unsigned o_mode: 3;
unsigned : 16-9; // Define all bits
char tag; // Chars last
// Padding, if any, occurs here
};
Here I've used types like 'int32_t' instead of 'int' or 'long' so
that the data sizes are more well-defined. Second, I've arranged
the members in decreasing order of alignment strictness, i.e.,
members with the widest alignment restrictions occur before (to the
left of, whatever) members with less strict alignments. If done
properly, all of the padding needed by the struct will occur solely
at the end of the struct.
-- David R. Tribble, david@tribble.com --
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Pete Becker <petebecker@acm.org>
Date: 1999/08/28 Raw View
Barry Margolin wrote:
>
> The OS developer should specify the ABI, and all the compiler implementors
> should conform to it, and then they can interoperate.
>
Microsoft has applied for patents on their C++ object layout. Nobody
else likes their layout, thoush, so it's not a big loss.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Barry Margolin <barmar@bbnplanet.com>
Date: 1999/08/28 Raw View
In article <user-2708990131340001@as1-dialup-77.io.com>,
blargg <postmast.root.admi.gov@iname.com> wrote:
>What is a "packed structure" exactly? I haven't heard of such a universal
>concept.
Yet somehow many languages over the decades have managed to incorporate it.
However, I believe that the way the standards define it, it's more like a
hint to the compiler, like "register" or "volatile". The precise
implementation isn't specified, it's just a way of telling the compiler to
treat certain things in a different, implementation-dependent way.
But it doesn't solve the OP's problem. Two different implementations could
have a different idea of how tightly packed a packed structure should be.
--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Greg Brewer" <nospam.greg@brewer.net>
Date: 1999/08/28 Raw View
blargg <postmast.root.admi.gov@iname.com> wrote in message
news:user-2708990131340001@as1-dialup-77.io.com...
>
> In article <7q43gp$2seb$1@news.hal-pc.org>, "Greg Brewer"
> <nospam.greg@brewer.net> wrote:
>
> > One of the problems I have experienced has to do with data alignment in
a
> > POD class or struct. The standard makes it implementation defined as to
how
> > data in the structure aligns the data. Which ever alignment is adopted
by
> > the compiler is okay as long as the data structure stays within modules
> > build by the same module.
>
> Yep. It works fine in practice.
Opps. That was supposed to say "... built by the by the same compiler."
> > However when moving the data between modules, it is critical that data
> > offsets within the structure be the same.
>
> If you have a decent compiler, it will generate compatible code for two
> different compiled files. If you are working between compilers, then they
> must agree on a convention. This is not for the standard to mandate - the
> market will push vendors to adopt a standard convention. How would this be
> specified anyway? "The company with the alphabetically first name will
> determine the standard for the platform". :-)
I'm not suggesting that the standard dictate anything. My experience on the
intel platform suggests that there are two ways of building a structure:
optimized for speed and optimized for size. The only thing that I would
expect the standard say about a pact structure is that it should be
optimized for size. Some my say that is so vague as to be meaningless;
however, I like the chances that two compilers interpretation of a packed
structure are compatible than that they are for two plain structures.
Historically, Borland compilers optimized for size and MS compilers were
optimized for speed. Now that Borland has gone in MS's direction, the
general need for a packed modifier is diminished. And such a conflict may
not exist on other platforms. Still, I do need to pass data between dll's
compiled with BC++ 5.01 and the latest version and with MS and with other
platforms. It would make my life easier if they could understand that these
dll's are expecting/sending data in a packed format.
> > There are at lease two mechanism
> > that exist for this: 1)fwrite/fread, and 2) passing a pointer to a
structure
> > as the argument to a function that is implemented inside a .dll. Of
course
> > there are other mechanisms such as pipes that do the same thing.
> >
> > The point is that it is necessary to have some point of agreement
between
> > two modules that may have been compiled seperately.
>
> Yep.
>
> > The Pascal language has
> > a keyword packed that is supposed to require a data structure exists in
a
> > condensed format.
>
> Packing isn't the only issue.
>
> > I'm wondering if it would not be of benefit if C/C++ had
> > a similar structure modifier.
>
> Nope. They would have to define a universal format. Other issues than
> alignment are representation, endian-ness, bitfields, enums, integral
> sizes, references (yes, really), etc.
I would disagree on the endian-ness one; that is primarily a cpu issue. On
the other points, you are right and I'm not advocating any standards for
what is done with them. Personally, I would be happy if two compilers
agreed on the alignment of data when the POD structure contained nothing but
chars, shorts, longs, floats, doubles, and pointers. That list purposely
omits ints. I'm not asking for something that guarantees agreement.
> > For years, MS C++ and Borland C++ had trouble exchanging data because
they
> > did not agree on the alignment. With the Builder product line, Borland
> > finally bent to MS conventions. Some may point out that it is possible
to
> > accomplish what I am suggesting using #pragmas;
>
> That is how it's done.
I know someone would say that. Yes, that is how its done. How about using
a packed modifier to indicate that a structure is packed and using pragmas
to define what packed means?
> > however, there is a problem
> > in that the pragma syntax may be different
>
> So may all the things you need to specify for the struct layout. Different
> platforms have different issues. Defining some universal set of directives
> to control this would be difficult and limiting, forcing #pragmas in the
> end anyway.
No directives are involved. Just optimize for size.
> > and I'm not sure about the scope of the pragma.
>
> It depends on the compiler (quality-of-implementation issue).
>
> > I believe that Borland now supports that MS pragma but the
> > original Borland C++ did not. If you wanted to back a data structure,
you
> > used #pragma -options -a in one and some other syntax for the other. If
you
> > wanted to created a header file for use by the other compiler, you had
to
> > know the syntax or you were out of luck.
> >
> > As I said, I'm not sure what the scope is of the #pragma. Consider,
> > #pragma pack ? // start packing
> > struct XYZ {
> > char x[3];
> > float y;
> > int z;
> > };
> > #pragma pack ? // go back to previous setting
> > struct ABC {
> > char a[3];
> > float b;
> > int c;
> > };
> > ...
> > int foo1(XYZ *); // does this expect a pointer to a packed
structure?
> > int foo2(ABC *); // does this expect a pointer at structure with
default
> > packing?
> > ...
> > {
> > XYZ xyz; // Is this created in a packed format?
> > ABC abc; // is this created in another format?
> > }
>
> Well, it depends entirely on the compiler. Check the documentation if you
> want to find out (unless you're satisfied with just guessing).
Don't have any documentation so I can't check it. My current problem is
with passing data for 5.01 to Builder. I'm satisfied with just dictating to
Builder that the data is packed.
> > Not all cpu's can allow data to be accessed while it is stored in a
packed
> > structure
>
> What is a "packed structure" exactly? I haven't heard of such a universal
> concept.
As I said, I would define a packed structure as vaguely optimized for size.
> > but that should negate the programmers ability to define a
> > structure. Of course, some mechanism will have to be provided for
moving
> > to/from the packed format in those invironments.
>
> I think the language as it stands is quite adequate for this task.
Sorry, but you are wrong.
Greg Brewer
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1999/08/28 Raw View
David R Tribble wrote:
...
> sizes, and 2) arrange the struct members so that extraneous padding
> is avoided.
>
> For example:
>
> struct Data
> {
> void * handle; // Pointers first
> uint32_t flags; // 32-bit type
> int16_t dtype;
> unsigned u_mode: 3;
> unsigned g_mode: 3;
> unsigned o_mode: 3;
> unsigned : 16-9; // Define all bits
> char tag; // Chars last
> // Padding, if any, occurs here
> };
>
> Here I've used types like 'int32_t' instead of 'int' or 'long' so
> that the data sizes are more well-defined. Second, I've arranged
> the members in decreasing order of alignment strictness, i.e.,
There's no portable way to know which types have the strictest alignment
restrictions. A good rule of thumb is that the strictest requirements
tend to go with largest types, but that's nor required.
> members with the widest alignment restrictions occur before (to the
> left of, whatever) members with less strict alignments. If done
> properly, all of the padding needed by the struct will occur solely
> at the end of the struct.
This should tend to help, but nothing's guaranteed about that.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]