Re: Any unusual C++ implementations?
On Jan 4, 2:10 am, "Tom=C3=A1s =C3=93 h=C3=89ilidhe" <t...@lavabit.com> wrot=
e:
I've been writing mostly C code for the last year or so (rather than
C++), and in writing C code I always make it fully portable, allowing for
9-Bit bytes, allowing for padding within integer types, allowing for null
pointers whose bit representation isn't all zeroes, allowing for either
of the three number systems, allowing for character sets other than ASCII
(e.g. 'A' isn't necessarily == 65).
The current project I'm working on is evolving quite a bit though...
and I think I'm being pushed to the edge to switch to C++. First thing I
could do with is namespaces, but also as soon as I get the go-ahead to
use classes I'll be restructuring the code altogether.
Anyway, I'd like to ask if C++ has as wide a variety of
implementations as does C? I mean you'll find a C implementation that has
9-Bit bytes, or 64-Bit bytes, or one that has padding in its integer
types. But what about C++? Is there variety?
Probably. You might check with Comeau; I think that if there is
a C compiler available for the platform, they will manage to
provide C++.
The real question is whether there is still that much variety
left in C. Although the standard allows it, as far as I know,
the last hardware which had padding in an int went out of
production some years ago; the same thing is true for most other
exotics. The only exception I'm aware of is the Unisys
mainframes, which use 36 bit 1's complement integers. And I
would be very surprised if there wasn't a C++ compiler for this
machine. Most of the machines for which there is only C, and
not C++, are very, very small embedded processors, which are all
pretty much 8 bits, 2's complement (when they support signed
arithmetic at all), and IEEE float when they have any floating
point. Similarly, encodings derived from ASCII are universal
outside the mainframe world. (Note, however, that at least some
mainframe compilers present and ASCII world inside C/C++,
translating on the fly whenever the file is opened in text
mode.)
The reason I ask is that if there isn't much variety in C++, then I
might switch to making my code less flexible. For instance I might assume
that an unsigned long has no padding and then go on to use it to
manipulate sizeof(unsigned long) bytes at a time.
The program I'm currently writing is mostly comprised of algorithms
that can be coded fully-portably in C, but now that I've decided to make
an interface for it (including a GUI), it's getting a bit more
complicated. I'd switch to C++ in a heartbeat but I want to maintain as
great portability as I can (and of course I'll lose a good chunk of
portability if I move to C++).
If you support a GUI, you'll loose a lot more portability, a lot
quicker, than just by moving to C++.
Would it be out of the question do you think to leave the algorithmic
code as C, and then write the interface code as C++... ? That way I could
still make commandline programs out of the algorithms.
If the algorithmic code works, why change it?
One thing I won't be doing ever though is assuming 8-Bit bytes or
assuming a 32 or 64-Bit system, because in ten years we could be using
systems with 16-Bit bytes.
There are definitely systems available today with 32 bit bytes.
With C++ compilers. But I don't think that any of them support
a hosted environment.
James Kanze (GABI Software) mailto:james.kanze@gmail.com
Conseils en informatique orient=EF=BF=BDe objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=EF=BF=BDmard, 78210 St.-Cyr-l'=EF=BF=BDcole, France, +33 (0)1 30 2=
3 00 34