Re: "Small C++" Anyone?
SasQ wrote:
Dnia Sat, 17 Mar 2007 19:49:35 +0100, Bo Persson napisa?(a):
I guess the committee just wanted to avoid repeating the 500
or so pages of the C standard.
I think it would be convenient to split the standard document
into some smaller parts - the core language definition in one,
the C standard library in another, the C++ [STL?] library in
another, maybe some "additional guarantees for most common
platforms" in another...
There are different chapters in the standard document. :-)
Not copying the C standard was partly to avoid introducing errors in the
process. What if the C and C++ standards turned out to be conflicting,
because of an editing mistake?
I believe that the committee wanted to avoid the blessing of particular
subsets of the language. Therefore they were intentionally vague in some
parts of the document, so that C++ could be implemented on hardware that are
not "the most common platform".
If you want to target 32-bit, two's complement, IEEE floating point
platforms with 8-bit bytes, you can easily do that without the help of the
committee. Just mark the box "Not suitable for 36-bit mainframes".
Also, the "most common platform" might just not be a PC, but an embedded
processor. Some of those have 16-bit or 32-bit bytes. :-)
It might be good also to create a place where language users
could post external libraries proposals, and other users
could compare it and choose the ones fullfilling their needs.
Languages [or platforms ;J] like Java or .NET has the little
advantage that all libraries are gathered in one place and
well defined/documented for their users.
The also have the "advantage" of a single company promoting their own
standard. This leads to interesting portability problems for platforms that
are not directly supported. Very expensive ones, sometimes.
For example, I work with IBM mainframes - a relatively low volume, but very
important platform. To run Java on this system, you need special add-on
hardware to implement the standard requirements. Dotnet doesn't run at all.
And there are
"standard" libraries for GUI, databases, communication,
threading, networking etc. There are many libraries for C++
doing the same, but it's not that easy to find it and compare.
Here C++ looses with its competitors ;J
The Commitee should consider this and do some tiding with
the external libraries, making them more accessible for users.
Some of the committee members are also active in boost.org, doing just that.
36-bit words, and everything. :-)
Hmm... I've always wondered how C++ support 64-bit processors?
The standard and Stroustrup says that the type 'int' has size
most convenient for integer arithmetics and it usually correspond
to machine word and sizes of processor registers / data bus.
On 64-bit machines, that is 64 bit, so does 'int' have 64-bit there?
Or it's still 32-bit, and 'long' is 64-bit?
The problem here is the defintion of "most convenient" or "most natural" for
a given platform.
For x64 platforms, 32-bit ints acually have shorter instructions than 64-bit
operations. That somehow makes it "natural" for the platform, in that AMD
decided to keep opcodes for 32-bit operations the same, and use extended
opcodes for 64-bit operations. That is different from when 16-bit code was
once transformed to 32-bit code.
Bo Persson