Slashdot Mirror
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.
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.
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.
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."
Potato chips are a by-yourself food.
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.
--
--
Don't like it? Respond with words, not karma.
Get in line, sonny. They're still coming out with new versions of Ada, COBOL and FORTRAN.
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++.
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I've been thinking about how to make C++ better in my spare time for the last year or so.
// array 10 pointers to function returning int
// array of pointers to func.
// pointer to func, no more stupid parenthesis matching
// 0x1A2
;-)
(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])())
Easier C^2 way: new func int() * [10]
e.g.
func int () * pFunc;
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;
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*
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.
Someone you trust is one of us.
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.
-- Still waiting for the Nike endorsement
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
Ryan T. Sammartino
"Ancora imparo"