531f2635
24567043
From: joshuamaurice@googlemail.com
On May 8, 12:30 pm, Jack Adrian Zappa
wrote:
> On May 8, 8:22 am, Andy Champ wrote:
> > Remember that the format of the numbers themselves may vary. I've
> > worked on systems where a native integer is 16, 24, 32 and 36 bits
> > long. To force the 36-bit one down to 32 bits would require an
> > operation on every memory store - probably every operation, for
> > true compatibility - and to force some of the 16-bit ones, which
> > have no hardware multiply or divide, to perform every operation in
> > 32 bits would be far too slow.
>
> > IMHO the best place to perform these conversions is during
> > I/O. I'm going to stand on the battlements and defend the castle
> > alongside those who produce the specification.
>
> Yes, these types do exist and need to be accounted for. And yes,
> these would be slower than native representations, but this is for
> interoperability, not for speed. Not using these parts of the
> language would not cause a performance degradation. Using them
> would allow the compiler to select the least amount of degradation
> possible.
I don't see a use case. You still haven't provided one. What is a
specific concrete example where you would use this?
I just thought of something. Is this because you want an executable
compiled for one system to be executable by another? Is this your use
case? That's unrealistic, and padding and endianness are the least of
your concerns. C++ is not the language you want if you want to be able
to port an executable to many different systems. That just runs
counter to several of the design goals of C++, and changing C++ to do
that would probably result in an almost completely compiler
implementation (and VM) to make "C++" executables executable on many
different systems. Ex: Java.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
