Re: C++0x: Scaling up on weak foundations?

Harold Aptroot wrote:
"Tony" <tony@xxxxxx> wrote in message
news:kiRHl.5927$Lr6.4853@xxxxxxxxxxxxxxxxxxxxxxx
I could have said something like, "Is C++ worth "evolving" rather
than putting it in heavy maintenance mode?" I think that efforts put
in defining a new language for new development, the area I think C++
is unwieldly in, is much more important. C and C++ are committed
(committeed?) to run on almost ANY hardware. Since most cellphones
even are 32-bit, I think a simplifying assumption like "32-bit
hardware support" is one of many that can define a GREAT language.
As it stands, it seems like everyone is paying and all the time, for
the exceptional case instead of enjoying the environment of the
general case. A C/C++-like language that jettisons backward-compatibility
and
targets new development and new developers is IMO the top priority.
Comments? (Any/all welcomed).

Tony

This is not a new concept though, for example C# - every type has a
well-defined size except pointers (and related types) which as
defined to be the "native size" [ECMA 335, page 31], byte order is
CPU specific (but it's safe enough to assume it's always little
endian)
The obvious solution: use C anyway and just forget about excessive
portability crap.
As a side note, none of the official 64bit data-models make sense to
me. Why have (excluding pointers) more than 1 name for the same size
of data?

For better compiler warnings? Other reasons.

Here's a suggestion:
byte: 8bits

byte8. Fine. Unsigned.

char: char8, char16, char32. Unsigned. A different type than integer types.
No implicit conversions to integers.

short: 16bits
int: 32bits
long: 64bits
long long: 128bits

They are all integers: int8, int16, int32.... uint8, uint16... Why make it
more confusing than it has to be? Implicit conversions from wider to
narrower width integer must at least give warning.

(why not? division would be slow, but it's slow
anyhow) pointers: native size (obviously)
Even if sizes lower than 32bit aren't available, the compiler could
just silently* upcast them and use range propagation to insert AND
instructions with the right bitmask where needed.
* or perhaps with warning, since it affects atomicity.

I was assuming that if 32-bit integers were available that the
fewer-bit-integers would be also. If that is not the case, that would then
be folded into my example simplifying assumption.


.

Relevant Pages

  • Re: Operator overloading in C
    ... All development of C as an independent language has ... making any changes or improvements to the standard ... The lack of a counted string data structure, ... Pointers can't be used for arg1 or arg2. ...
    (comp.std.c)
  • Re: pointers?
    ... There's absolutely nothing abstract in pointers. ... Take the C array: if you write ... To the assembly language programmers who were the first generation adopters of C, this mental mapping was very tight. ... Forth gained the most traction on machines like the IBM 1130 and the Data General Nova. ...
    (comp.lang.forth)
  • Re: another day, another patch ...
    ... windows weenies started to graduate from being teenage videogame players into application programmers and system managers. ... Would you blame the language? ... But you are then making that code REALLy ugly and dangerous (an non portable because assumption of 32 bit pointers). ...
    (comp.os.vms)
  • Re: which should i learn c or c++ ?
    ... >I have a book to learn the C language, but also I have some ebooks to ... >So I have a real problem. ... They'll jump right into using STL, and from your knowledge of C you'll ... productive code before even delving into pointers (by using STL ...
    (alt.comp.lang.learn.c-cpp)
  • Re: VB6, VB2005, or Something Else?
    ... They documented that this could corrupt binary data. ... Language behavior changes IMHO cannot be prevented over the lifetime of a ... Pointers don't belong in the ... But if it's framework code (lists, ...
    (microsoft.public.vb.general.discussion)