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

SG wrote:
On 23 Apr., 05:35, "Tony" <t...@xxxxxx> wrote:
I could have said something like, "Is C++ worth "evolving" rather
than

Sure. It may depend on what "worth" means to you in this context,
though.

I think backward compatibility is a weak foundation to build upon and the
more that gets built on top of that weak foundation makes the quality of the
language lower. You can only build levies so high.

You might not have the same goals as the C++ committee. In
fact, I'm pretty sure you don't.

Well I'm designing my own language. Whether it will ever get to native
compiler level is uncertain. The language is not *that* different than C++
so I constantly wrestle with staying with C++ or moving farther and farther
away from it via my own replacement constructs (there's only so much one can
do with a preprocessor and other coding tricks) until someday when I flip
the switch and break away from it completely.


[...] 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.

You don't have to use C or C++. You're complaining about things you
don't have to use.
And complaining seems to be a major theme in most
of your posts. Some might even say you're trolling.
Use C#, Java,
Python, Ruby, ... instead if it makes you any happier. Don't hold your
breath until you find the "perfect language", though.

Can't anyone bring up something without someone always labeling it something
other than what it is? You're the one complaining that people think outside
of the box. Don't read provocative posts if they make smoke come out of your
ears. Seesh already. NG police really need to find something to do. This
isn't c.l.c++ you know.


If you do use C or C++, however, you can choose to ignore exceptional
cases, of course. You can even make your code NOT compile on
"exceptional platforms" where your assumptions about built-in types
don't hold. You should prefer to make it not compile instead of fail
at runtime, of course. For this purpose there are standard header
files which allow you to access implementation properties.

That was just one simple example I used. The question has much greater
implication than that.


#include <limits.h>

#if CHAR_BIT != 8
#error This implementation is not portable. Sorry!
#endif

I'm not using any standard headers in my R&D code any longer. I don't even
let the compiler initialize the std library.
I'm probably using C++ as "free-standing' rather than "hosted"
implementation (?).


What you might not know already: The new C++ version will include
another header <cstdint> and catches up with C99's <stdint.h>. This
header contains typedefs for exact-width integer types (i.e. int32_t)
if and only if the machine supports these types.

I didn't know that but I don't keep up with that standard though since I'm
more interested in my R&D code than existing or in-progress C++ code. My
proprietary header performs the width checks and I have a runtime check
function also.

The existence of a
typedef for a signed exact-width type also guarantees that this type
uses two's complement for representing negative values. If the machine
doesn't support some of types there won't be typedefs for them in the
header and your code won't compile.

Also, "C++0x" will support static
assertions which allows you to write

static_assert(sizeof(int)*CHAR_BIT == 32, "Sorry. The author "
"doesn't care about your platform. He chose to make more "
"assumtions about built-in types than needed.");

This is a bit better than macro trickery because you're not limited to
testing macro definitions only (see "sizeof(int)").

I do compile-time asserts using a macro. I don't understand what you mean.


.

Relevant Pages

  • Re: C++ errors
    ... >I am new to linux and trying to compile my program. ... You are having problems learning ... a language, not using an OS. ... You need to #include another header or headers. ...
    (Fedora)
  • Re: GMP vs. straight C arithmetic
    ... ordinary data structures that don't impose an additonal performance ... Side-effects are another crucial part of the language. ... > Take the tree structure example I gave earlier. ... determined at compile time, is this a compile time error? ...
    (comp.programming)
  • Re: Cpp Considered Harmful
    ... >> I will observe that many Java IDEs do this rather successfully. ... > Look, if a tool author is willing to fully parse the underlying language, ... > compiler version. ... mentions a header file is in the C compatability appendix. ...
    (comp.lang.cpp)
  • Resolved: NOT. --WAS: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming:OO
    ... I certainly want more errors detected at compile time, ... > advocate reaching that goal through beefier type systems. ... in a procedural language, or in an object based language. ... Relativistic mechanics - solves the transaction thing, ...
    (comp.object)
  • Re: Teach myself C++.
    ... That seems to be an objection to the quality of implementation of ... The language IS the compilers. ... should be possible to compile some code more than once, ... I'd say that string handling is something most other languages get ...
    (sci.crypt)