Next Generation C++ In The Works

lamefrog writes: "Bjarne Stroustrup and other members of the C++ community recently met to discuss new work on the language for the first time post-ISO standard (C++0x) in an effort to keep the language moving, avoid fossilization and avoid being overtaken by proprietary extensions. Suggested new features center around the standard library and include support for multi-threading and simple platform-independent systems abstractions (handles, TCP/IP, memory maps etc...)" (Read more.)

"Most intriguing is a suggestion to include extended type information that will eliminate the need for IDLs and make it possible to generate standard bindings to external systems (COM, CORBA, SQL). Clearly Bjarne wants to position this as a platform-neutral, vendor-neutral, standardized alternative to the proprietary, vendor-supported languages that have emerged over the recent years. Audio MP3 and slides available on Dr. Dobb's TechNetCast." Thoughtfully, it's available to download as well (not just streaming), and accompanied by a transcript. Good listening.

Re:What about making it a little less bloated?

Umm, my major problem with C++ is execution time. I try and write as little as possible in C++, sticking mainly to C and Perl for anything which needs to execute quickly.

Some things in C++ are quite slow, but no slower then simulating them in C. Faster in many cases. The C++ STL sort function seems to be about an order of magnitude faster then C's qsort (operating on char, short, and int's).

In fact the STL in general is quite fast, normally faster then the C equivalent (when one exists), definitely faster then what one would whip up in an hour.

C++'s virtual functions are slow. Quite slow. But faster then C calling through a pointer. Sometimes insanely faster because the C++ compiler can actually tell what type the pointer will be at run time. C can almost never tell.

If the only thing you care about is execution speed, use C++. Use the STL. Use C's I/O. Avoid virtual functions, except when you would have used a function pointer before.

I'm going to ignore the bit where you think Perl makes faster code then C++ (I do admit it could in some cases, but not normally).

This is not to say that I think C++ is a wonderful language. I rather dislike it. I love the STL. Everything else in C++ seems to have been done better elsewhere. Still the language has value, if only because of the wide availability.

Re:What about making it a little less bloated?

That isn't surprising at all. The C runtime is very straight forward (except for setjump/longjump). It is pretty clear how things can/should be implemented. C++ does a lot more for you, and it is unclear how they might do it (either because it's hard to guess how anyone might do it, or it's just hard to guess how this one compiler does it).

(the STL's "runtime complexity" requirements is a good start, but it is just big O, the constants can still kill you)

I don't think you will find a higher level language then C with a simpler to guess performance model (unless the model is "everything written in Tcl is slow"). I mean for all Eiffel's wonderful features, or Modula-3's, I don't think looking at two functions and guessing which is faster is among them.

I can't think of any high level language has a simpler runtime then C. That is both high complement, and damnation.

Re:How does this help?

You moron -- that's no way to develop applications. What are you, a first year Fortran student?

The proper way to develop software is to have long, pointless meetings where techies can show off their intelligence, marketeers can display their ignorance and managers can "lead".

Then, everybody pisses around reading Slashdot while a few firebrands argue over what kind of versioning system to use: "CVS!" "RCVS!"

When half of the estimated time has past, the programmers start screaming about the Mythical Man-Month and how marketing is full of shit, while reconfiguring the Cisco switch to cut latency for Quake deathmatches.

Marketing then begins to sell the product to customers, promising to have asked-for features implemented "at beta".

Two weeks before due date, the programmers work 22 hour days cobbling an application from stolen code from previous jobs, algorithms designed in a drunken stupor, and (apparently) one programmer bashing his face into the keyboard.

This fresh, steaming turd gets pushed out the door to tumultuous disdain. Programmers blame marketing, marketing blames management, and the customers get told that it's Microsoft's fault.

So keep your wacky ideas to yourself, okay rookie?

"Beware by whom you are called sane."

Re:How does this help?

Heck, by creating yet another C derivative language, they are just adding to the problem of inefficient, difficult-to-debug, difficult-to-maintain languages.

IMO, the programmer community would, in many cases, be far, *far* better off writing their applications using a very high level language.

This will allow them to spend *less* time creating the main code body, and *more* time debugging. Their applications will be less faulty.

Then, using profiling, they can identify exactly those areas that need to be written using a low-level language for speed.

Imagine: very high productivity, very high maintainability, very large reduction in bugs, and 96% or more of the performance!

It's the intelligent way to work.

--

Re:Time to move on

Get in line, sonny. They're still coming out with new versions of Ada, COBOL and FORTRAN.

What 3.8 *ACTUALLY* says is...

that an implementation of STL (the MS implementation, one presumes) at the time the book was written was immature. The above post makes it seem as though Kernighan and Pike were frothing in their denunciation of C++.

Something I've wanted for a decade...

The C++ standards deliberately leave something open which I think should be defined in a particular way.

Suppose:

you are constructing an instance of a derived class

one of its base classes has "published" a pointer to the partially-constructed instance

the class has a virtual member funciton

the member function is overridden by this class

the class also has a member variable of a class type with construction

the constructor of the member variable (or something it calls) finds the published pointer and calls the virtual member function.

What happens?

My claim is that such a call SHOULD be legal and SHOULD call the BASE CLASS version of the member function. Similarly, during the execution of the DEsctuctors of the member variables you should also get the BASE CLASS version of the member function. You should get the derived class version exactly from the beginning of the execution of the first line of the body of the constructor through the end of the execution of the last line of the body of the desctuctor.

The reasoning is too involved to go into here. Suffice it to say that:

It's a consistent generalization of the philosophy of the C++ constructon-destructon semantics (and of the way that the C++ semantics differs from those of Objective C and Smalltalk.)

It's an compiler implementation that is allowed by all the levels of C++ standardization.

There's a LOT of neat stuff you can do with this guarantee that you can't do without it.

There are a lot more opportunities for programming error if your compiler doesn't work this way. (Not to mention the issue of code that works find with a compiler that does it one way but breaks when run through a compiler that does it a different way.)

The original C++ work didn't specify the behavior in question. The first ANSI standard explicitly left it open. The revised ANSI standard not only explicitly left it open but said "don't do that". B-(

At the time I first proposed it (about 10 years ago) we looked into a sample of the compilers on the market. There are four binary combinations of member constructor/destructor and base/derived version of member function, of which I claim one is "right" and the other three "wrong":

Cfront and the Cfront-derived C++ compilers tested (Sun, SGI) got it "wrong" one way.

The three IBM PC compilers tested got it "wrong" a second way.

Gnu G++ got it "wrong" the third way.

so standardizing on this semantics wouldn't favor any particular vendor's existing product.

IMHO this somewhat obscure issue is one of the major impediments to C++ achieving its potential as an object-oriented language, and it is unfortunate that is wasn't "fixed" in one of the previous standards.

Perhaps there's one more chance here.

C^2 - the next gen of C++

I've been thinking about how to make C++ better in my spare time for the last year or so.

(Unfortunately my notes are at home, so this isn't the full feature set)

Here are some comments I'd love feedback on.

o) New operators:

^ would be the standard math power operator. The compiler would optimize ^2 the much it does now with *2.

@ would be the pointer derefence op. (Allows you to search for where pointers are being used)

?= (replacement for ==, since it is WAY to easy to get = and == mixed up)

$ is also another operator for users.

o) STANDARDIZED and PORTABLE types
NO MORE "long long" crap.

int8, int 16, int32, int64, int128 (signed int's)
real32, real64, real80 (floating point)
fix (fixed-point)
char8 (8-bit ascii)
char16 (unicode-16)
char32 (unicode-32)

int would be the "native" integer type for the cpu.
float would be the "native" floating type for the cpu.

o) New keyboards

"func" would preface all functions/methods. (helps the compiler out, and lets editors be able to expand/collapse functions easier)

"macro" would force the function to be inlined.

"include" is part of the language. No longer needs that ugly pre-processor hack.

o) Cleaner Syntax - CONSISTENT reading of right to left.

Pointers would bind LEFT (instead of right in C/C++)

i.e. Pointer to a function

The old C++ way: new (int (*[10])()) // array 10 pointers to function returning int

Easier C^2 way: new func int() * [10] // array of pointers to func.

e.g.
func int () * pFunc; // pointer to func, no more stupid parenthesis matching

o) C style implicit () casts gone. Only C++ style casts. (Allows for searching of casts)

e.g.
C++ way:
char *pC;
int *pI = (int*)(pC);
*pI = 3;

C^2 way:
int *pI = static_cast(pC);
@pI = 3;

o) standard way to turn OFF implicit up-casting

o) Binary constants. (We have decimal, octal, and hex. Where's the binary notation??)

Preface numbers with "Zero Z"
e.g.
const int mask = 0z0110100010; // 0x1A2

o) "typedef" and "alias" would be extended.
typedef would make a NEW type. (Compiler wouldn't throw away the newnames)
alias would behave like the old typedefs currently

Maybe it's time to download gcc 3 ;-)

*shrugs*

Re:C++ Frustrations

Yes, mdev 7.0 is probably one of the most compliant C++ compilers out there. It is one of the few linkers than handles template-objectfile redundancy propperly without tedious pragma's and bizzare typedefs in cpp files. Also, the msdev implementation of STL and IOStreams is to the letter of the standard with full template iostreams (unlike g++ non-template IOStreams). However, msdev's implementation includes nothing that is not in the standard (like hashtables), except auto_ptr. All in all, Microsoft has embraced C++ big time (MFC and especially ATL). Frankly their devotion to that sad ancient religion, hasn't helped them conjour up the stolen data plans nor given them clairvoyance enough to learn the location of the rebels hidden fort...kha..cc.cka..aaak.

A serious (rather unpopular) hope...

As a programmer who often works on massively cross platform C++ server and client applications, a lot of these proposals (distributed processing, standard thread libraries) are nice, but there's one major gripe with the language under all platforms: the lack of standard sized types. What I mean is, integral types in parallel to the short int, int, long int, long long int (C99 standardized, not C++) etc, with names like int8, int16, int32, int64, int128... allowing portability without meticulous work in wrapping and handling functions, outside libs, autoconf scripts, etc. It would be especially nice if these types were *not* considered, for the sake of signatures, type-identical to counterpart size-variant types, and if enums were also given a generic root type instead of being int in signature (eg, operator(ClassName&, enum) ) and a variant size integral type defined to the size of a pointer were included. Just some thoughts from a person who has to extensively use the language.

Re:Something I've wanted for a decade...

Suppose:

• you are constructing an instance of a derived class that is part of the system dependent side of a bridge
• the other side of the bridge is called by a mediator instance
• the mediator class has virtual functions
• the instantiation of the mediator class makes a system call to create a thread that runs on the other side of the bridge
• the instantiation in the first instance is allocating but is not initialized
• the bus component on one side of the bridge is calling a lambda function that is created on the other side
• the lambda function was created by manipulating a string in memory and casting it to a function call
• but the lambda depends on instantiation data
• the mediator passed some data to the thread
• there are no semaphors

It's 4:00am.

What do you do? What do you do !!

C++ Frustrations

Why are they talking about new stuff when old, standardised stuff doesn't even work yet? (I'm looking at you, MS Visual Crap++)

That's one of the most annoying and frustrating things about C++... it isn't implemented properly and effeciently anywhere yet (g++ comes close, but still enough annoyances to be, well, annoying).

Ryan T. Sammartino