Bjarne Stroustrup Previews C++0x

Szplug writes "Bjarne Stroustrup has a sneak peek at the additions to C++ that he expects will be completed (hopefully) by 2009. Included are language-defined threads, optional garbage collection, some automatic type deduction, and template concepts. From the article: 'The list of current proposals is still quite modest and not anywhere as ambitious as I'd like. However, more proposals are being considered and more libraries will appear either as part of the C++0x standard itself or as further committee technical reports.'"

Comments

Worth it?

[Max Romantschuk]

Having programmed in numerous languages I can't help wonder if it's really worth it. There's a reason why languages come and go. Bolting on new features might be more like treating the symptoms rather than the cause?

Time will tell, I guess.

Re:Worth it?

[Anonymous Coward]

There's a reason why languages come and go.

I agree that ADA and FORTRAN are out and Java and Python are in, but isn't C/C++ an expection?

C/C++ have been around for many years and show no signs of going away - C++ was initially developed in 1983, while C itself hails from the early 1970s - and they're still popular to this day. And, of course, C++ "bolted on new features" to C. In fact, C++ was initially called 'C with classes'.

As far as I'm concerned, as long as C++ is "the standard language" in so many places we may as well make it not suck in comparison to other languages, which we can do by appropriating the nice features of those other languages.

Just my $0.02,

Michael

Re:Worth it?

[Greyfox]

C++ is evolving via committee, so its growth tends to be both slow and seemingly ridiculously complex. Also usually for the better though. The last major change I recall seeing from them added templates and exceptions. Arguably neither was necessary for the language, but I think both additions helped it out. Since then folks like Alexandrescu have been doing nifty things with those features, and the boost library is based on a lot of that work. From what I can tell, the committee is actually looking at that work and are shaping C++ in a way that tries to help it in the future. Thats much better than having them go off and do their own thing without looking at what the community is doing.

C++ is a tremendously type safe language, to the point where every time I work with it I feel like about 90% of the work I do is in accounting for type. Most of that work is thrown away after the code has been compiled, too, but it does make for a rock solid program if you do it right. It seems to deliver on a lot of the promise of ADA, really. If they can improve access to its features without compromising that type safety, I'm all for it.

Re:Worth it?

[frantzdb]

C++ is a tremendously type safe language, to the point where every time I work with it I feel like about 90% of the work I do is in accounting for type. Most of that work is thrown away after the code has been compiled, too, but it does make for a rock solid program if you do it right.

From my experience using C++ in the field, I basically agree. While type safety can be a headache, there are many errors that strong typing eliminates entirely, almost to the point that "if it compiles, it's correct". While much type information is "thrown away" at compile time, I always find that careful consideration of type is necessary to correctly implement something large. When I have trouble mapping the problem domain onto a strictly-typed mental model, it generally means I really don't understand the problem.

Re:Worth it?

[LucidBeast]

To us stuffy old farts things keep moving way too fast. I just got gazillion errors from the spanking new compiler, because the scope change to the variables declared inside for loops.

Re:Worth it?

[DrXym]

Arguably the principle thing which is "broken" about C / C++ is that nowadays it is far more powerful than many programs or programmers actually need. If you want to screw around beyond the end of an array or write to some arbitrary place in memory, or keep allocating memory forever without releasing it, then C and C++ will let you. The problem is that most apps don't need to do these things and any crashes are usually through code which unwittingly invokes these "features". Hence the reason that Java et al have taken off since they protect developers from themselves in many cases.

Obviously if you're writing a number crunching app, a game, a driver, a kernel, a shared library or something with high performance, low level or compatibility requirements then you need C++. Otherwise I'd go elsewhere.

Java works plenty well for most things. C# is fine too but is nowhere near as portable by any stretch.

Re:Worth it?

[BadassJesus]

Worth it?
C++ is the cornerstone of computing today, 90% of all serious software under your cursor is C++. It is robust (type safe & object oriented) and performance horse as well. Any contributions to it's base is worth. You may fiddle around with java, basic, python, lua or whatever but C++ is still the tool of the pros. I am using it on regular basis, with the right libraries it is as easy as "basic" but with the lighting speed of "C". Not to mention portability. I can run my OpenGL based apps on Linux, OS X and Windows natively with no speed penalty of the interpreter of Java alikes.

languages come and go
This one makes me laugh. I can asure you that C++ is not gonna "go". Its like to say "English" is gonna go.

Re:Worth it?

[Comboman]

C++ is a tremendously type safe language

Huh?!? C++ is a tremendously type dependant language, which is a very different thing from being type safe. If you type x = y * 3; where x is an unsigned integer and y is a float, a "type safe" language would generate a type-mismatch error at compile. A "type unsafe" language (like C++) would auto-cast without telling you and leave you scratching your head for hours trying to figure out why the results are not what you expected. Yes, that's a programmer error, but a good language should be designed to catch programmer errors at the earliest possible point (compile time).

Re:Worth it?

[Weedlekin]

"Obviously if you're writing a number crunching app, a game, a driver, a kernel, a shared library or something with high performance, low level or compatibility requirements then you need C++"

You don't need C++ for any of these things, because they can be just as easily written in C. In fact, C is usually a better language for these things than C++ because it is far more widely supported by other languages: C libraries can be used by (to name a few) BASIC, Python, Ruby, Pascal, Fortran, Objective-C, Objective CAML, Eiffel, Smalltalk, etc., etc., etc. By contrast, C++ libraries can be used by, well, C++.

Re:Worth it?

[hobuddy]

From my experience using C++ in the field, I basically agree. While type safety can be a headache, there are many errors that strong typing eliminates entirely, almost to the point that "if it compiles, it's correct".

If you were talking about ML, you might be right, but in the case of C++, that's unadulterated bullshit. C++ can never approach the "if it compiles, it's correct" ideal because it allows unsafe memory operations. I recently worked on a large C++ code base that "compiled" the day I arrived. Within a couple of months, I had fixed about 90 memory handling bugs, which type safety did absolutely nothing to guard against.

Re:Worth it?

[frantzdb]

It's not ML, sure; perhaps I overstated things. What I meant to say is that careful use of the type system gives one to option to create code that is fairly typesafe. Anyone can come along and write bad C in C++, or break the type system with reinterpret_cast, but you can write "statically type-robust" code in C++, which can't be said of many production lanugages.

Re:Worth it?

[Da VinMan]

with the right libraries it is as easy as "basic" but with the lighting speed of "C"

I find that to be an interesting thought. Care to elaborate on what the "right libraries" are? And I'm not baiting you either; just curious. I've always found working in C/C++ to be extremely tedious and onerous, so it's not my preferred toolset at this point. But I've been wondering what, given the right tools, I might be missing.

Re:Worth it?

[BadassJesus]

But I've been wondering what, given the right tools, I might be missing.

I personally like these (well established and well supported)
http://www.codeblocks.org/ // dev kit
http://www.wxwindows.org/ // 2d lib
http://irrlicht.sourceforge.net/ // 3d lib

Re:Worth it?

[samkass]

"Within a couple of months, I had fixed about 90 memory handling bugs, which type safety did absolutely nothing to guard against."

Let me guess... 89 of them were where people used "delete[]" instead of "delete" or vice-versa. There are definitely weaknesses of the C++ language, many of them in regards to allocation and deallocation. Since the article specifically mentions that as an area they're working on, perhaps things are looking up.

Re:Worth it?

[DrXym]

You don't need C++ for any of these things

C++ is virtually a superset of ANSI C so I don't make the distinction between the two. C++ is C with classes, exceptions & rtti to me. The difference that exist are mostly irrelevant to modern programming. These days as far as most programmers or indeed compilers go, C++ and C are one and the same with a few switches to control stack unwinding or other behaviour for .c or .cpp extensions but little else.

As long as your library's entry points are not mangled, and use a standard calling convention it makes no odds what language it is implemented in on the other side. And even if it were C++ mangled, it would be hardly a supreme effort to write some stubs around them. I do think that using C is better for the APIs but QT has bindings so clearly it's not strictly necessary. Personally I prefer the GTK approach to its API and would call Win32 directly than through MFC any day, but I don't care how it works internally.

Re:Worth it?

[aichpvee]

All what has a born has a death.

Good to see you doing your part to make it happen.

Re:Worth it?

[Rei]

That's what you get for using 'new' when you should be using vectors or smart pointers. Shame on you.

Re:Worth it?

[deadlinegrunt]

While I am neither siding for or against the GP I will comment on your statement since you prefaced it with a genuine interest of knowledge seeking:

"Care to elaborate on what the 'right libraries' are?""

Looking at my sig will do just that as they are geared for various different tasks. The list is not inclusive nor is it necessarily correct. In fact it may very well be the most subjective thing you have ever read and total crap waste of time, but I have provided it for people just like you.

Re:Worth it?

[Rei]

You can be warned about that on almost every C/C++ compiler out there. Most compilers don't by default, but if it's something that you care about, enable it; it takes seconds.

Re:Worth it?

[Anonymous Coward]

I agree that ADA and FORTRAN are out and Java and Python are in, but isn't C/C++ an expection?

As someone who's been paid to program in each of those over my career, I'd say that each of them have their places.

• Fortran remains good at numerical libraries. Due to restrictions on the language, it's much easier for fortran compliers to optimize loops for various vector architectures (that range from the old Crays that I used to use in the mid 80s, to MMX and modern supercomputers from NEC.
  
• ADA remains interesting for applications where bureaucracy (for lack of a better word) is more important than programmer efficiency. If a program can kill me if it goes wrong I'd much rather it be written in ADA than Python. (the Boeing 777's fli-by-wire system uses ADA.
  
• C is an excellent platform for almost directly dealing with register-based CPUs without wasting time in assembly language. Any medium/small embedded system will probably be mostly C. Actually, most stuff that runs directly (as opposed to under an OSS) on most popular CPUs should probably be mostly C.
  
• Python (though I refer Ruby) is extremely efficient to program in. IMHO almost all programs today should be written in Python or Ruby with C extentions/libraries for the parts that need it. The combination of Ruby with appropriate C libraries (often NArray) is my platform of choice for any program that will run on top of an operating system.
  
• Java, C++, and C# are mediocre compromises of languages that such at efficient development (compared to Ruby&Python) and suck at low level asks (like C) and have really lame half-assed object-oriented pieces that don't work well (compared to Ruby/Lisp/SmallTalk/OCaml). I group them together because none will be picked for technical merits - which of the three you choose will have far more to do than politics (Microsoft fanboys C#, Anti-microsoft-cliques Java, standards fanatics C++). The *ONLY* reason I can imagine using one of these languages is if you're in a disfunctional corporate culture that doesn't allow people to use the best tool for the job, but instead wants to "standardize" on something that does a mediocre job at most any task. This most often happens when a MSFT or IBM salesguy takes a Product Marking EVP out to lunch; and is almost never the right technical decision.
  

Re:Worth it?

[Pxtl]

Agreed. The first step to coding C++ is to forget all the C you ever knew. Arrays are used for optimizing and nothing else. Combine that with the type safety of the language, and using references instead of pointers, and you basically get Java without all the flaws of Java/C# - it's faster, more typesafe, backwards-compatible, better hardware access, and more expressive than it's newer offspring. If only the 9x standard had come out (and been supported by mainstream compilers) earlier and there were some solid GUI libraries, we could've dodged the whole Java/C# thing altogether... well, if there were some way to put pointers in a collection and have them be deleted on removal in standard C++ (either support for auto_ptrs or inclusion of smart_ptrs in C++).

Re:Worth it?

[emarkp]

If you type x = y * 3; where x is an unsigned integer and y is a float, a "type safe" language would generate a type-mismatch error at compile.

Heaven help us from such "type safe" languages.

In C and C++ the arithmetic conversions are a bit less strict than I'd like, but they at least allow you to do work. I know what the conversions do, and I use them appropriately. And it's a pain in the butt when a compiler tells me, "oooooh if you convert to an int you may lose data!"

Thanks Mr. Compiler. I knew that, but I had to grow my integer-sized buffer by 1.5 and I want that integer result. At least 90% of the warnings of these conversions are this kind of worthless warning.

UDTs don't have implicit conversions but you can define them, which is a good thing. If a language doesn't have strict typing, I'd expect it to have some sort of contract enforcement. Otherwise it's really hard to define safe interfaces.

Re:Worth it?

[Anonymous Brave Guy]

I just got gazillion errors from the spanking new compiler, because the scope change to the variables declared inside for loops.

The one required by a standard that was basically finished about 9 years ago, and which has been supported by pretty much every mainstream compiler for at least two or three versions now, you mean? :-)

Yours,
A stuffy, not-quite-so-old fart

Re:Worth it?

[Anonymous Brave Guy]

If you type x = y * 3; where x is an unsigned integer and y is a float, a "type safe" language would generate a type-mismatch error at compile.

If we're talking about genuine strong typing, then yes, I suppose that's probably required. I would argue that generating predictable and expected behaviour is a more useful standard a lot more often.

Re:Worth it?

[Weedlekin]

"C++ is virtually a superset of ANSI C so I don't make the distinction between the two. C++ is C with classes, exceptions & rtti to me. The difference that exist are mostly irrelevant to modern programming. These days as far as most programmers or indeed compilers go, C++ and C are one and the same with a few switches to control stack unwinding or other behaviour for .c or .cpp extensions but little else."

What you see is demonstrably incorrect .A partial list of incompatibilities follows (based on the latest standards, i.e. C99 and C++98) follows. You can find plenty more by Googling.

1) C++ has synonyms for certain operators such and "and" for "&&", "not" for "!", etc. and the macro preprocessor "knows about" them. These tokens could however be defined in a C program as having specific meanings other than those that are assumed by the C++ compiler.

2) Boolean types. C++ has them, C doesn't. Obviously, this can cause problems if a C program tries to define ones with the same names, but different values than the C++ ones.

3) Character literals in C are ints, whereas those in C++ are chars. Thus, sizeof('x') in C will return sizeof(int), whereas sizeof('x') in C++ will return sizeof(char).

4. in C, clog is declared in math.h as a complex natural logarithm function, whereas in C++ it is the standard error output stream declared in iostream.

5. The comma operator in C always results in an r-value even if its right operand is an l-value, while in C++ the comma operator will result in an l-value if its right operand is an l-value.

6. C allows literals having types other than primitive types (e.g., user-defined structure or array types) to be specified in constant expression, whereas C++ does not.

7. const qualifiers in C result in a variable that has external (static) linkage and therefore is visible to other modules; in C++, const items by default have internal linkage, and must be explicitly prefix by "extern" to behave as C const objects do.

8. C distinguishes between a function declared with an empty parameter list and a function declared with a parameter list consisting of only void. The former is an unprototyped function taking an unspecified number of arguments, while the latter is a prototyped function taking no arguments. In C++ on the other hand assumes both to be a function that takes no arguments.

I could go on and on, as there are around 50 known and documented syntactic or semantic differences between C99 and C++98. These do not include stuff that C++ has which are not in C, but are items that are nominally common to both languages, but which each compiler will see differently to the other, and therefore either choke on, or compile into code that does not behave identically. C++ is not therefore a superset of C, and anyone who compiles C code with it, or uses it to write code for a C compiler assuming that it is a C superset could be in for a very rude awakening indeed.

Re:Worth it?

[Anonymous Coward]

C doesn't die because you're system is designed to work with it anyway.
C++ isn't even a proper superset of C.

C++ doesn't die because it became vastly popular and it will take a long time for people to rewrite all that code or even move it to better compilers.

I view C++ as a nightmarish half-step between systems programming and high-level languages. It's only advantage over c is support for OO programming styles. That's nice, but when other languages offer: OO Programming that doesn't seem tacked on, managed memory, and complete libraries: C++ looks less and less attractive.

People will probably be writing videogames in C++ for ages though. So, I suppose this excites them.

Re:Worth it?

[AlvySinger]

C++ is evolving via committee, so its growth tends to be both slow and seemingly ridiculously complex.

OT: So's Wikipedia but there it's apparently a good thing...

Re:Worth it?

[FuzzyDaddy]

The category that C++ is good for is processor intensive but not hardware tied applications. For example, video games are well served by C++ where the object orientation is extremely useful, but direct hardware interfacing is not crucial for most of it.

When I worked on a real time radio simulator years ago, I used C++ and Python. Python did the initialization and made a call to a function that never returned. That function was C, but it linked to quite a bit of C++ code, which was great for managing the various objects in the simulated environment.

Re:Worth it?

[Hosiah]

But wait! There's more! We could still have C**2, ~C, C%2, low-carb C, After-C, C_on_a_bed_of_rice...

There's a reason why languages come and go.

Tell that to the camp who won't release Basic until you pry their fingers from it!

*grins, ducks, and vanishes*

Re:Worth it?

[DrXym]

What you see is demonstrably incorrect

Actually it isn't. I said quite clearly virtually a superset since I am well aware that there are mostly minor differences that can be and are controlled by switches in most compilers. The differences for what they are, certainly are not compelling reasons at all to use C over C++ unless you have some constraint which demands you must avoid an overhead associated with C++.

Re:Worth it?

[14erCleaner]

I agree that ADA and FORTRAN are out and Java and Python are in, but isn't C/C++ an expection?

Clearly you use C++ but not Java, or you'd be able to spell "exception".

Besides, Java is so on-the-way-out these days. Didn't you get the memo? I'll forward you a copy.

Re:Worth it?

[iliketrash]

I know what the conversions do, and I use them appropriately.

Glad to hear that you don't make mistakes. You're the guy that C etc. were designed for.

Re:Worth it?

[KrispyKringle]

It's "more typesafe" than Java or C#? How?

Re:Worth it?

[Pxtl]

You could re-implement the primitives in such a way that would not allow implicit typecasting for example. Because of the lack of operator overloading in Java, you are stuck with the true primitives as is unless you want the headache of boxing/unboxing.

Also, you can avoid the NULL case (which is a giant hole in preventing runtime errors) by passing by value or reference only.

Re:Worth it?

[Pxtl]

Hmmph. You hear about the successes, like C++'s spectacularly awsome template system, but people simply don't talk about the failures. Exception specifications anyone? Run-time handling of thrown exception specifications is worse than useless.

Re:Worth it?

[Pxtl]

And you can tell the compiler "I know" by casting properly. You can write "no warning" C++, which will protect you the one time that you _didn't_ realise that you floored your floats.

Re:Worth it?

[KrispyKringle]

Ah, I see. What you're saying is that you can use it in a way that makes it appear typesafe. That may be. Nonetheless, neither Java nor C++ are actually typesafe; C++ still allows you to do things that aren't safe and thus isn't itself typesafe (maybe I'm just arguing semantics, but it's an important distinction--any system allows you to be correct; only some systems require you to be correct).

Re:Worth it?

[Decaff]

C/C++ have been around for many years and show no signs of going away

It is certainly not going away, but it is showing signs of losing its role as the major general-purpose development language.

Whatever you think of them, Java and C# seem to be taking over for everyday business coding, and dynamic languages such as Python and Ruby are now getting much wider use than the 'scripting' role they have been in for years.

Re:Worth it?

[Pxtl]

My attitude: if you produce code that uses any of the obscure (and bizarre) features of C that do not cross over into C++, then you're already a bizarre four star coder and anything you produce will be of no value anyways.

Re:Worth it?

[Old Wolf]

A "type-paranoid" language would generate a comple error.
If I write:

    unsigned int x;
    float y; .....
    x = y * 3;

then I want y to be multiplied by 3 and then assigned to x.

A "type unsafe" language (like C++) would auto-cast without telling you and leave you scratching your head for hours trying to figure out why the results are not what you expected.

What else could you possibly expect from the above code?
If you wanted a float result you would have used a float variable.

I, for one, find

    x = y * 3;

far easier to read and maintain than

    x = (unsigned int)(y * 3);

Yecch.

Re:Worth it?

[Pxtl]

Yes, but my point is that C++ allows you to produce typesafe code if you limit yourself to a subset of the language while still maintaining most of the functionality. If you constructed more tools for yourself in C++ outside of the typesafe environment, you could improve this toolset to an impressive level. Meanwhile, you would be hard pressed to find a useful subset of pre-1.5 Java that is typesafe.

Re:Worth it?

[alphamugwump]

That one caused a hell of a lot of grief for a hell of a lot of people, all because Microsoft didn't want to adopt the standard because it would break compatability. And its only just now that they are fixing it. Sigh.

Re:Worth it?

[Old Wolf]

Your points seem to be a list of syntax incompatibilities between C and C++. This misses the point of the OP, who said that to him, C++ works well as C with some extensions. He never claimed the syntax was identical and he wasn't claiming that he compiles C with a C++ compiler. Obviously if he ran into any of the issues you listed, he'd have to make a slight code modification.

C++ has synonyms for certain operators such and "and" for "&&", "not" for "!", etc. and the macro preprocessor "knows about" them.

Actually these were first defined in the 1994 revision of the C standard (also known as TC1), and then adopted by C++. Try #include <iso646.h> in your C program.

const qualifiers in C result in a variable that has external (static) linkage and therefore is visible to other modules; in C++, const items by default have internal linkage, and must be explicitly prefix by "extern" to behave as C const objects do.

Slightly odd way of writing that; as the C++ behaviour is far more desirable.

If you're talking about a header file, then defining an object with external linkage (const or not) causes undefined behaviour in both C and C++ if the header file is used in two or more units.

If you're talking about a non-header file, then it is a stupid idea to deliberately declare an object with external linkage without having an extern definition in a corresponding header file. (Either it will never be used by another TU, in which case it might as well have internal linkage; or the other TU will have to include an extern declaration, which is prone to error). And if there is an extern declaration in a header file then the definition is automatically extern, whether it's explicitly specified or not.

Re:Worth it?

[dkf]

When you say "typesafe" do you mean with respect to run-time type-safety or compile-time type-safety? Hmm, you're talking about C++, so I guess it's "compile-time"; to code in C++ is to reject the concept of managed code and strict enforcement of basic language guarantees. Which means that if there are any bugs in the compilation, you're in trouble. Note that that's true for many other systems too; it's not a specific dig at C++.

Of course, type-safety is a much lesser concept than program correctness. All it does is catch a larger subset of lower-level problems (FWIW, there's an infinite number of possible layers of abstraction and nothing as simple as a type system can tackle them all tractably) and occasionally get horribly in your way when you're coding something. But all too often people don't want to pay for correctness; they assume (usually correctly) that they can get "good enough" for less cost.

Re:Worth it?

[Anonymous Brave Guy]

IMHO that's rather unfair. When Visual C++ 6 was released, the standard hadn't yet been finalised, and the now-incorrect scoping wasn't uncommon. All more recent versions of VC++ have provided the /Zc:forScope option or something similar that allowed the proper scope to be enforced, and aside from VC++ 7 (the 2002 disaster where using the corresponding option actually broke things like MFC, making it effectively useless to many Windows-based developers) it's worked fine.

Re:Worth it?

[UnknownSoldier]

> C++ is a tremendously type safe language,

Eh?

* The fact that it is impossile to distinguish between ARRAYS and POINTERS causes all sorts of problems.
* There is no native NULL pointer
* There is no way to DISABLE the automatic up-casting of floats to doubles. (This SUCKS for console programming.)
* No way to prevent integers being promoted to FLOATS. (SUCKS again, for console programming)

Counter-examples:

void func( const int v[3] ) // init from vector

void func( const int v[4] ) // "already defined" // won't compile since arrays == ptr

void func( const int n )

void func( const int *aArray ) // func( NULL); // doesn't call the pointer version!

I _really_ wish there was a way to declare/define arrays, and functions via keywords. If C was consistent in reading from Right-To-Left, you wouldn't need the typedef hackery to define function pointers, etc.

i.e.
func( int ) *pFunc;
int* aPointers[3];
int array[3] *pArray;

That said, I love C++, because it is a pragmatic language.

--
Forgotten Christian History

Re:Worth it?

[emarkp]

And you can tell the compiler "I know" by casting properly.

Define "casting properly". The language precisely defines the conversions. I used the conversions as the language specifies. What you're saying is that I should add a cast to tell the compiler "yes I really mean this", but that's an arbitrary decision about numerical conversions. What other programming styles do you think the compiler should enforce? I don't get a warning if I write:

if (i==0)

instead of

if (0==i)

Even though many people recommend the second style to avoid the mistype of

if (i=0)

Why should the compiler enforce your style choice over mine?

The compiler is free to add the ability to turn on these "newbie" warnings. But experienced programmers should easily be able to leave them off. And extraneous casts shouldn't be added when the language has clearly defined conversions.

Re:Worth it?

[Thoran]

C++ is a tremendously type safe language.

I can't stop laughing about that sentence. Like another comment said, have a look at ML to see what is a language with a safe type system.

You can't expect to have any reasonable type safety when keeping so much compatibility with C. The changes between C and C++ about the typing rules for basic types was made with performance improvement in mind, not safety. They added a bool type to C++, which might be considered a step toward type safety. But they allow bool and int to be implicitely cast one into the other. They did not want to break all the idiomatic constructions of C you usually find in clauses like:

int i;
[...]
if(i) ...

So why did they introduce bool? The only reason I can imagine is that the generated code will be faster.

The best illustration of that is an example I found in the famous c++ pitfalls at http://www.horstmann.com/cpp/pitfalls.html. Look for the example that starts with "The stream classes support a type conversion basic_ios "

And I'm not talking about the other implicit conversions like the one from int to float (already made in other comments) with all the nifty interactions it has with overloading, inheritance, whatever...

We can forgive Kernighan and Richie for that design. 35 years ago, we did not have clear ideas about type systems. And C was a portable assembler to write OS. On a CPU, there is no differences between an integer and a boolean. Thus, no need to have a bool type in your language. But today , this is absolutely terrific that in the mainstream programming language, you can still write that program:

#include <iostream>

int main(int argc, char **argv)
{
int z = 5;
if(1 <= z <= 3){
std::cout << "I love Stroustroup\n";
}
else{
std::cout << "I hate Stroustroup\n";
}
}

It will compile without a warning. When run, it produces aberrant results.

Re:Worth it?

[Anonymous Brave Guy]

I'm not sure I follow your criticism of C++ over bugs at compilation time. A compiled C++ program will reveal certain classes of error at compile-time, but you can and should still use assertions, exceptions, and so on to guard against logic errors at run-time.

Sure, you can't 100% guarantee that no-one's code will ever dereference a null pointer or divide by zero, but I don't see that much advantage to having some unexpected "logic error" exception generated in a program running on a virtual machine either. If you thought to catch such an exception at a meaningul level and take some useful recovery action on a virtual machine, couldn't you have asserted that the invalid data shouldn't be there on the way into the module and handled it much the same way in C++, at least the vast majority of the time?

And of course, on several major platforms, you can configure handlers for such fatal errors when the OS detects them, or even treat them as exceptions within C++ exactly as you would under a VM, although sadly this isn't standardised, nor supported on all platforms.

Re:Worth it?

[Anonymous Brave Guy]

As long as your library's entry points are not mangled, and use a standard calling convention it makes no odds what language it is implemented in on the other side.

Ah, if only that were true. Suppose you're writing a library in C++, and will be advertising a C-compatible interface (i.e., C calling convention, no name mangling, only POD types used in the interface, etc.). Now consider the effect of using any sort of static object of a type with a non-trivial destructor within your C++ code, even if it's never referenced by the interface.

It's certainly not completely straightforward to write a C++ library that can be called from an arbitrary second language using the C calling convention. However, it certainly can be done, and we do it all the time at work despite the fiftywhatever issues someone else seems to have with it. Maybe we just thought that writing a function called "and" might be a bad idea even before C++ came along. ;-)

Re:Worth it?

[GenSolo]

x = (unsigned int)(y * 3);
Hey now, in C++ the correct version is x = static_cast(y * 3);

Seriously though, the cast is a reminder to a maintenance programmer that "hey, x is an unsigned int!". It's also a step in the self-documenting code process. If I turn on all the "did the original programmer make any stupid mistakes" warnings (sorry, but "newbie" warnings as used above wasn't the best term), the version with the cast will, reasonably, not generate a warning. The version without a cast says generates a warning, and the new maintenance programmer has to inspect it to make sure x really was supposed to be an unsigned int in this case.

Re:Worth it?

[Old Wolf]

Hey now, in C++ the correct version is x = static_cast(y * 3);

Actually my code was correct. An alternative form would be:

    x = static_cast(y * 3);

which is even uglier.

Seriously though, the cast is a reminder to a maintenance programmer that "hey, x is an unsigned int!". It's also a step in the self-documenting code process.

How about later when you decide you really did want x to be a float?
Now you will have an obscure bug of the same sort that the OP was complaining about, which would not have been present had you not used the cast! There will be no compiler warning or error in either C++ or Java (which allows widening conversions without a cast).

Re:Worth it?

[angel'o'sphere]

No,

C/C++ is not an exception. COBOL was invented in the mid/late 60s. So it lasted till 2000 (and sadly it still lasts as OO COBOL), thats about 35 years. The same is more or less true for FORTRAN.

C++ is only 22 years old now (if your quote about 1983 is correct, I thought it was from 1887/88). C/C++ still has 10 years until it gets as aged as COBOL is right now.

As language researchers/designers learn more and more about how to make a programming language its only natural that more modern languages have a longer life time.

Sure, you are right. Make C++ less sucking! Call it C<< and make it a new language. Don't even attempt to make it compatible to C++. No, a C++ program is not a C<< program like a C program for a long time was a C++ one.

Add GC and multi threading support, concepts (not only for templates) and a way to enhance syntax, blocks is a minimum.

angel'o'sphere

Re:Worth it?

[JFitzsimmons]

Parent mentions that classes are the only thing that make C and C++ different. Parent is wrong. Perhaps he was thinking of Objective-C?

Re:Worth it?

[DavidHOzAu]

Your whole post stems around this:

The fact that it is impossile to distinguish between ARRAYS and POINTERS causes all sorts of problems.

Right. And I suppose that's because "char *array2d[]" is exactly the same as "char **array2d".

If you actually did your stuff right, you'll use [] for arrays, and a list of pointers to index into each extra dimension.

Re:Worth it?

[LucidBeast]

Well, I propably heard about it, but being old fart, I mostly fix and upgrade stuff that I have coded over the decades. So most of my code doesn't compile unless the flag is turned off (or on now days). Only last year I started really running into this standard.

Re:Worth it?

[Minna Kirai]

Also, you can avoid the NULL case (which is a giant hole in preventing runtime errors) by passing by value or reference only.

How do you think NULL is a weakness? The inability of C++'s references to be set to Null (like a Java reference can) is one of the biggest reasons C++ programs muse use so many pointers instead of references.

Combine that with the type safety of the language, and using references instead of pointers, and you basically get Java

That sounds very suspicious. C++ references cannot substitute for either Java references or C++ pointers. To fill those roles, they need to be reseatable, and be able to have a NULL value. (Which is equivalent to OPTION datatypes in some functional languages... the ability to talk about a value which might not be present is semantically important)

Re:Worth it?

[Minna Kirai]

IMHO that's rather unfair. When Visual C++ 6 was released,

The fair complaint is that Microsoft waited more than 7 years between compiler releases. VC6 was justly maligned by people stuck using it into the 200Xs. There was no reason several simplistic compiler changes couldn't have been issued prior to the full VC7 rollout.

Re:Worth it?

[BuildMonkey]

Try using Boost smart pointers. We are using them in a large, embedded project. We are now going on two years without a resource handling bug.

Re:Worth it?

[Weedlekin]

"The differences for what they are, certainly are not compelling reasons at all to use C over C++ unless you have some constraint which demands you must avoid an overhead associated with C++"

I never claimed otherwise. My point is that C++ is not a superset of C, and should not therefore be used to compile C source files or write files that target C compilers unless one is fully aware of the fact that C++ is _not_ C with some added features.

Re:Worth it?

[Weedlekin]

Then the Linux and BSD kernels are obviously of no value, because they will not compile into usable code with a C++ compiler.

Re:Worth it?

[Weedlekin]

"Actually these were first defined in the 1994 revision of the C standard (also known as TC1), and then adopted by C++. Try #include in your C program."

Read what I said. This does not make the macro preprocessor aware of them, and they can therefore be changed by including a subsequent header which redefines one or more of them.

"Slightly odd way of writing that; as the C++ behaviour is far more desirable."

I never said otherwise. My point is that they are not the same, not which is preferable.

"it is a stupid idea to deliberately declare an object with external linkage without having an extern definition in a corresponding header file. (Either it will never be used by another TU, in which case it might as well have internal linkage; or the other TU will have to include an extern declaration, which is prone to error). And if there is an extern declaration in a header file then the definition is automatically extern, whether it's explicitly specified or not."

Again, I never made any claim about whether this particular C "feature" is desirable or sensible. I cited a difference between the way C and C++ handle something that could be a source of potential problems when compiling valid C source with a C++ compiler, and said nothing else about it.

Re:Worth it?

[jandersen]

ADA may be 'out' for all I know, but FORTRAN isn't; it still has a place in numerical computing such as physics and chemistry. Just because the average PC amateur can't be bothered with doesn't mean it isn't useful.

Both FORTRAN and C are still relevant because they are concise and to the point; FORTRAN as a FORmula TRANslator, C as a generalized assembler.

C++ on the other hand is far too complex and overengineered; it was so from the very beginning. I think it began as an attempt at keeping the good things in C while amending the features that were seen as 'the reasons why programmers make errors'. IOW, C++ tries to force you to write correctly. I think there are meny good ideas in C++, but the problem it tries to solve is one that should be solved by the programmer being able to think without moving his lips. The result has been that far too much C++ code is a conceptual spaghetti, where you can't easily follow the logical flow of the program simply by reading the code (I have worked on a number of that kind of projects).

No, the best way would be to add a few useful features to C - say exceptions - and stop at that. And then teach programmers to write code properly.

Re:Worth it?

[BitchKapoor]

Sure, you can't 100% guarantee that no-one's code will ever dereference a null pointer or divide by zero, but I don't see that much advantage to having some unexpected "logic error" exception generated in a program running on a virtual machine either. If you thought to catch such an exception at a meaningul level and take some useful recovery action on a virtual machine, couldn't you have asserted that the invalid data shouldn't be there on the way into the module and handled it much the same way in C++, at least the vast majority of the time?

No, simply checking the inputs doesn't guarantee that the module won't encounter an unexpected exception. Bugs in the implementation of a module, by definition, result in errant behavior when provided with valid inputs as per the specification. You need appropriate mechanisms to isolate modules from each other in order to prevent these errors from spreading throughout the whole system.

And of course, on several major platforms, you can configure handlers for such fatal errors when the OS detects them, or even treat them as exceptions within C++ exactly as you would under a VM, although sadly this isn't standardised, nor supported on all platforms.

To some extent, yes, but it's generally not enough to robustly isolate modules. Handler mechanisms such as UNIX signals don't provide structured event handling, so recovering from a call to an errant module is difficult. You can probably combine signals with setjmp/longjmp, but uniform exception support is easier to use and hence more robust. Also, operating systems generally don't protect against one module corrupting another's memory within the same process address space.

Re:Worth it?

[renoX]

While I tend to dislike Microsoft, I agree that C# is getting new features that looks interesting. But past experience with Java make me beleive that a new language is ready 5 years after all advocates swear their god that their language is the 'greatest things since sliced bread' before the implementation is too buggy to care.

And there is the problem of portability, once C# v3 will be mature on Windows, it'll take quite a long time for Free software programmers to have it running safely on Linux: difficult to match Microsoft full time team pace of development.

So it'll take a long time before C# becomes interesting, and it'll still be JIT which have lower performance usually that language compiled ahead of time..

Re:Worth it?

[GenSolo]

Actually my code was correct.
I understand that C-style casts are legal in C++, but I was attempting humor by pointing out that the recommended casts are even uglier. Clearly that was a miserable failure.

How about later when you decide you really did want x to be a float?
You remove the cast? I mean, if you change the type of x, part of that process is changing the code that uses x to treat x as the new type. I was simply suggesting that the cast may aid the maintenance process by providing extra information. As with most things, changing the context can totally screw that communication up.

PS. As a correction to the /. posting typo I made earlier: x = static_cast<unsigned int>(y * 3);
Must remember to preview and use entities for angle brackets in Plain Old Text.

Re:Worth it?

[SB7980]

Within a couple of months, I had fixed about 90 memory handling bugs, which type safety did absolutely nothing to guard against.

Obviously the system was written more in C than C++, otherwise RAII would have been used. The reason people think C++ cannot handle memory automatically is because many people still write code in C++ that looks too much like C. Real C++ programs use smart pointers where appropriate. Real C++ also never use 'new' directly - use allocators. Double points for polymorphic allocators :)

Re:Worth it?

[grahamlee]

Erm, don't know much Objective-C? How about runtime symbol lookup or exceptions? "C with classes bolted on" sounds like "C with classes" to me, which is of course how C++ started out...

What a name!

[Caspian]

"C" was an unusual enough name for a language. Then "C++", which makes sense to you or I but would only mystify a non-geek. Now "C++0x"? How is that even pronounced? "See Plus Plus Zero Ecks"? Or maybe just "C...ocks"?

Names like this serve to only further mystify computing and programming among the non-geek population.

Re:What a name!

[melonman]

Sounds like a great name if it is supposed to appeal to C programmers. What would you call it? Brenda? Somehow I can't see C ever catching on with the non-geek population.

Also, I was assuming that it would be called C++09 once the launch date is sorted out. Or should that be C+=9?

Re:What a name!

[gravij]

Seems like the 0x will be replaced with the year it is ratified by the ISO, eg. 09. The same as the ISO standard C++98.

Re:What a name!

[lhorn]

Personally I went immidiately with the second pronounciation, it is easy to remember and fits my sense/level of humour...

Re:What a name!

[RedNovember]

You thought that was a weird name, yet you didn't blink at Bjarne Stroustrup?

As us unfortunate VBers would say, GeekFactor.Value = True

Re:What a name!

[Arimus]

If it is C++09 should we read it as (C++)09 or C(++09) (in case of the later why not just C10?)

Re:What a name!

[swillden]

Now "C++0x"? How is that even pronounced? "See Plus Plus Zero Ecks"? Or maybe just "C...ocks"?

Actually, the correct pronunciation will be "See Plus Plus". The name of the language won't change, just as C is just called C, even though K&R C, C89 and C99 are quite different animals.

Re:What a name!

[Kawahee]

It's C++0x because it will be released within 2000 to 2010. The ISO C++ standard is, as stated in the article, C++98.

Re:What a name!

[civilizedINTENSITY]

C(++09) isn't C10, C(09++) would be C10. However, don't expect it until 09 is ready to rollover into 10.

Re:What a name!

[melonman]

Because C10 sounds like 2 of these

(Note to American readers - Citroên is a car manufacturer :))

Re:What a name!

[famebait]

Or maybe just "C...ocks"?

Definitely. That way, all the losers who haven't moved on to modern languages by 2009 can be known as

[drum roll]

            C++0x-suckers!

Re:What a name!

[Caspian]

What would you call it? Brenda?

Actually, I think Brenda would be a fine name for a programming language! And giving a programming language a female name would attract a lot more eager young males to the field...

Re:What a name!

[melonman]

Hmm, I don't think C is the place to start. After all, as Kerningham and Richie say, C is a small language, and young males tend to go for... well, something a bit more bloated. Maybe PHP?

Re:What a name!

[tigersha]

Then rather call it D. Or DD. That should definitely pull in the young'uns

Re:What a name!

[Ekevu]

Or maybe just "C...ocks"?

This is just as bad as the current name. If I look up "cocks" on Google, I will have to sort out between the language and the carnage. Doesn't sound interesting.

Now, if we call it Pu-C, maybe it won't be that big of a problem. :o)

Re:What a name!

[Zog The Undeniable]

It must be l33t-speak, using the two plus signs to form an "H". That makes it "CH0x", so when it goes gold they can put out a press release saying "CH0x Away!".

Or maybe they're just a bunch of inveterate geeks, who knows.

Re:What a name!

[JabberWokky]

The current C++ is C++98. When C++09 (presumably) comes out, it will still just be called C++. Sort of like C99 is called C and Ada95 is called Ada. They year is the published standard. The name is what people call it.

The only language that I can think of that changed names (sort of) during a standards revision was Fortran -- it was all caps in FORTRAN77 and turned to mixed case in Fortran90. But people still just call it Fortran (unless you're in a coding standards meeting).

--
Evan

Re:What a name!

[merc]

Forget how to pronounce C++0x, how do you pronounce Bjarne Stroustrup?

Re:What a name!

[Mr. Bad Example]

> Forget how to pronounce C++0x, how do you pronounce Bjarne Stroustrup?

I know you were probably being funny, but for anyone who wonders, Wikipedia says:

A rough English attempt at pronunciation of his name would be "B-yar-ne Strov-stroop".

Re:What a name!

[tijnbraun]

Ada is named after Ada Byron (Lady Lovelace)...
But it definitely did not attract a lot of eager yound males
Maybe they should have named it Britney or something

Re:What a name!

[CableModemSniper]

How about Miranda?

Re:What a name!

[psmears]

See his FAQ for an explanation and a .wav file!

Re:What a name!

[Anders]

[...] how do you pronounce Bjarne Stroustrup?

This is the first question in his FAQ. Includes a .wav file.

Re:What a name!

[alphamugwump]

Yeah, just try convincing your boss to switch to a "serious" language like Britney!

Re:What a name!

[kin_korn_karn]

If you want to attract eager young males, call it FreeBeerAndBlowjobs++

Re:What a name!

[NuShrike]

Way back then, C as a name made logical sense. Byte usage was expensive, and so the less letters, the better. This is why there's so many two letter commands in UNIX.

So C followed language B which followed language A. Made perfect sense. There's no D or E I guess..

Re:What a name!

[SolitaryMan]

"C" was an unusual enough name for a language

It's not so unusual if you look at the history of that name. Language "C" derived many of its features from language "B", so the name was "promoted" to "C". And name "B" for a language was chosen as just a funny name: there was "A Programming Language" (APL) already, so new language was named "B programming language".

Should've just done it in Python/Ruby anyways

[psavo]

What I started to hate in C++/Java/C# is that there's no easy and standard-conforming way to express complex data 'inline'. Yeah, it's cleaner to make it XML and load it runtime, but there's no simple+quick way to do that either.

Hell, you can't event put known non-uniform data in C++ vector without doing it one-by-one.

Re:Should've just done it in Python/Ruby anyways

[Anonymous Coward]

>> Hell, you can't event put known non-uniform data in C++ vector without doing it one-by-one.

Well, you'll at least be able to do that 2009.. Or to quote Stroustrup from the article:

Vec v = { 2.3, 1.2, 6.7, 4.5 };

Re:Should've just done it in Python/Ruby anyways

[fatmonkeyboy]

Out of curiousity, what kind of work are you doing that you have lots of complex data that you want to store inline with the code?

Re:Should've just done it in Python/Ruby anyways

[sgt101]

On the other hand, we could use COBOL, as that has really good facilities for putting data inline with imperative code.

ohh...

wait...

(reads 30 years of literature on databases, furrows brow)

I think I've seen a problem with that!

(looks up brightly)

Re:Should've just done it in Python/Ruby anyways

[Zathrus]

Hell, you can't event put known non-uniform data in C++ vector without doing it one-by-one.

What are you doing such that you need to put constant data into a vector like that? Is there a reason you're not just using an array?

There are use cases for doing this, but they're pretty rare. We could use it in our codebase for our unit tests, but not in the "real" code.

And, if you'd bothered to read the article, you'd see that this will be supported in C++0x.

Re:Should've just done it in Python/Ruby anyways

[Rei]

One word: Blitz++.

Re:Should've just done it in Python/Ruby anyways

[jgrahn]

Hell, you can't event put known non-uniform data in C++ vector without doing it one-by-one.

Not true, of course. You can initialize a vector using two iterators [start, end), for example two pointers into an array, iterators into any kind of standard container, etc. I'm sure there are plenty of other ways, too.

Re:Should've just done it in Python/Ruby anyways

[abdulla]

Exactly, I believe they're called sequence, there's papers on it by Bjarne if you have a look around.

Re:Should've just done it in Python/Ruby anyways

[Anonymous Brave Guy]

Probably the sort of stuff you'd write directly in a hash in Perl, I guess: months => days in month, perhaps.

Re:Should've just done it in Python/Ruby anyways

[psavo]

Yup, when last needed it was very short and specialized localization of how long weekdaynames map to short ones. That's available from glibc (sortsof), but not everything that I needed.

When I rewrote it for C# I just broke up the structure and used inline strings instead of real data. This then would be picked up by gettext (whatever C# is using).

example: fluffydate, it's plugin for blosxom, so brevity and ease of distribution is needed. like NO required XML -files/associated perl modules. As few places to break as possible too. FWIW, perl's nested structures suck donkey balls big time as well, but at least it makes it possible without sticking shovel halfways down my ass.

Re:Should've just done it in Python/Ruby anyways

[psavo]

Ever heard of "How About A Nice Cup Of Too Little Too Fucking Latte"?

I'd just like to point out - we own it

[Anonymous Coward]

"And C++ programming languages, we own those, have licensed them out multiple times, obviously. We have a lot of royalties coming to us from C++."

http://techupdate.zdnet.com/techupdate/stories/mai n/0,14179,2877578,00.html

You know where to send your royalty checks.

Thanks
Darl McBride

I think it is obvious

[Anonymous Coward]

I think it is obvious that this guy has no idea what he is talking about when talking about C++.

Re:I think it is obvious

[Jon_E]

who? Bjorn Stroustrup the creator of C++? Anders Hejlsberg the creator of J++ and project lead on C#? Danish people in general? or just a general comment on people who post on slashdot?

Lisp

[lisaparratt]

By the time he's finished with C++0x\n==%d, I bet the specification will look suspiciously similar to that of Common Lisp!

Re:Lisp

[Lostie]

And how will that be pronounced: Thee Pluth Pluth?

Re:Lisp

[Anonymous Coward]

By the time he's finished with C++0x\n==%d, I bet the specification will look suspiciously similar to that of Common Lisp!

Do your homework, that's not lisp - that's perl.

Re:Lisp

[Triple Click]

Then it would be: ((C++0x\n==%d))

Re:2009?

[indifferent children]

Yes. Even if a better language comes along in the next few years, it will take more than three years (probably more than fifteen years) for C++ to stop being common.

Adding new features is not always an improvement

[Frans Faase]

The art of making a programming language lies in giving it just enough features to make everything possible that you want without making thing possible that you want. I feel that at the moment C++ already allows to much "wierd" things that you do not really need in practice. I am affraid that adding new features and new language constructs only will make things worse, not better.

I also have come to realize that if there is one bad thing in C++ than it is this preprocessing which it inherited from C. Especially in a large project the trouble of including the right files and linking against the matching libraries becomes a pain in the ass. In this respect I would like C++ be more like Java (or TurboPascal for the matter) where interface declarations and compiled code are unified. At the moment moving around code from one DLL to another is a lot of work, while in my perception, it could have been completely transparent from the users point of view.

I do realize that keeping backwards compatibility was one of the design features of C++, and that it also determined the success of C. But as many C++ tools are now able to make use of precompiled headers, it seems that the problem should be able to be done away with.

More features - is that what C++ really needs?

[JackDW]

I'm a long-time fan of C and C++, but I've been converted to Python recently. Endlessly copying the C model is a bad idea. C++ did it, Perl did it, then Java copied C++, and all are perfectly servicable languages, but they are not clean, simple or pretty.

If we want to write complex and secure programs quickly, we need better languages, and more features does not mean better.

Re:More features - is that what C++ really needs?

[ForeverFaithless]

Python is neat until you discover the power of Ruby. Give it a try, you won't look back.

Re:More features - is that what C++ really needs?

[ObsessiveMathsFreak]

Ruby is OK until you stumble upon 'Rails. Then the addiction truely takes hold.

Re:More features - is that what C++ really needs?

[masklinn]

Sorry, I have.

Ruby and Python are more or less equivalent languages, extremely similar in most constructs and ways of life, and rougly 90% of the "differences" between the languages boil down to syntactic sugar.

And please, I beg you, don't bring Blocks in this by saying something as stupid as "woohoo, blocks are liek magic, no one else has it, they're cruise control for greatness", blocks are anonymous functions period (in the Functional Programming sense of the term, e.g. functions with closures that are first-class objects), the concept is more than 30 years old... (and not OO at all, meaning that the "top of the line" feature of the OO herald language is purely functional).

Ruby is an extremely fine dynamically strongly typed language with an extreme object orientation, Python is likewise. None of them is "better than the other one" in an absolute sense and claiming the opposide is stupid, the one you choose is purely a matter of taste. You prefer Ruby? good for you, I prefer Python, and that makes neither "the ultimate language".

This fucking ruby hype is becoming extremely tiring, and doesn't help Ruby.

End of the rant

Re:More features - is that what C++ really needs?

[16K Ram Pack]

I've just started using it after I found out that Nokia have written an emulator for Series 60 Symbian phones. I had a little play with it, and so far, I'm very impressed.

Re:More features - is that what C++ really needs?

[masklinn]

Ah, so every language should be fucking sloppy and should then add constructs to remove the sloppyness for you to accept to use them?

Ever thought about using a language designed without the sloppyness in the first place?

Re:More features - is that what C++ really needs?

[masklinn]

Python indentation defines blocks (end of blocks, to be precise). I kind of fail to see how using braces or begin/end construct is "cleaner", especially since you indent languages using braces or blocks keywords by blocks anyway (see, getting rid of keywords/braces is all python does).

Less typing, less misindented code and a lower rate of confusing constructs look cleaner to me.

Re:More features - is that what C++ really needs?

[JackDW]

But then, I guess the "more features does not mean better" sums it up pretty perfectly. Why don't we just all go back to coding in Assembler?

Yes, that's right, "more features does not mean better" is equivalent to, "more features never means better".

You use a language that uses indentation to define semantics, and you complain about languages not being "clean"? I'm not sure whether I'm supposed to laugh or cry now.

This rule makes it harder to write incorrect (but valid) code by mistake.

Re:More features - is that what C++ really needs?

[Glock27]

Python is neat until you discover the power of Ruby. Give it a try, you won't look back.

You're both wrong. Once you realize your shiny new languages are running your programs at the speed of molasses flowing in the Antarctic winter, you'll want a similarly powerful language that's in the same runtime efficiency domain as C/C++.

Try Dylan.

Re:More features - is that what C++ really needs?

[robgamble]

For business applications Python, Ruby, PHP, Java, C# and others are not zippy-fast but they make perfect sense in terms of productivity.

Try Dylan? For fun I checked Dice.com to see how many job postings are listed for different languages.

Java..12,781
C++....6,701
C#.....3,657
PHP......682
Python...491
Ruby......59
Dylan......0

Most of the C++ jobs required someone with Java or C# skills too. Draw your own conclusions.

I wasn't very scientific in my search but this guy put a lot of work into it.

Re:More features - is that what C++ really needs?

[masklinn]

It looks cleaner, but it can introduce hidden bugs. Just one person using 4-tabs vs. everyone else using 4 spaces leads to a mysterious bug, since the interpreter takes every tab to be a 8-tab.

The interpreter will more than likely whine because of indentation mismatch.

And tell you where it happens, so that you can nicely normalize indentation (your editor can do that can't it?)

I'm sure any large Python development crew can tell you that this ended up being a problem for them at some point.

And I sure hope that every Python development crew (large or not) has minimum style guidelines in which a single indentation style is specified and required. And uses PyLint/PyChecker to check for that kind of issues.

Re:More features - is that what C++ really needs?

[blair1q]

Cut and paste it a few times, then come back and see me for these: {{{{}}}}

Re:More features - is that what C++ really needs?

[Chris Burke]

Python indentation defines blocks (end of blocks, to be precise). I kind of fail to see how using braces or begin/end construct is "cleaner", especially since you indent languages using braces or blocks keywords by blocks anyway (see, getting rid of keywords/braces is all python does).

Less typing, less misindented code and a lower rate of confusing constructs look cleaner to me.

I can't believe one character (the ending brace) per block is a non-trivial reduction in typing.

Sure properly indented Python code looks nice (though I find the simplicity of a '}' to be fine looking). The problem with Python's cleanliness occurs when you try to edit it. In C, changing blocks is simple because syntatically what is important are the opening/ending braces, so if you get that right you can then hit your auto-indent macro to get nice looking C code. In Python, it is impossible to write an auto-indent for the same reason it's impossible to write an auto-insert-braces macro for C. This means a lot more hand-editing of indentation and the possibility of introducing non-obvious bugs into code that was working fine before.

Don't get me wrong, i like python a lot and don't mind syntactically significant indentation. I just wish they'd left in braces. If you want to require indentation anyway, go ahead, but give me block delimiter characters so that it is simple to programatically determine what the indentation should be.

Re:More features - is that what C++ really needs?

[mad.frog]

No argument, but there is a vast body of C++ code that's not going to go away anytime soon.

Frankly, I could do without the extra template-based features, but adding GC and threads as language features are waaaay overdue IMHO and will be greatly appreciated.

Re:More features - is that what C++ really needs?

[killjoe]

You know I really like python and prefer it to Ruby in many many ways but I still end up using Ruby. This is due to the community of the language rather then the language itself. It seems like the Ruby community learned the right lessons from perl and build GEM. Gem alone is reason to prefer ruby over python and the RAA and rubyforge are just icing on the cake. The python community is just now trying to build something like CPAN or GEM and they still haven't gotten it right. I don't know why this is and I sorely wish it was different but for some reason the people who have advocated "the one true way" over "there is more then one way to do it" completely neglected a centralized, searchable, automatically updateable library for python. Pity because python was just made for such a thing.

Now that rails has become a juggernaut ruby is even a stronger player. It's funny how the ruby community seems to very quickly settle on "the one true thing" and pour their efforts into that while the python community suffers from having dozens of equally popular (and meritorious) frameworks to choose from.

Re:More features - is that what C++ really needs?

[WWWWolf]

The almost canonical counterexample:

Copy and paste some C code from a random PDF or web page and tell your editor to indent that. Then try to do the same thing with Python code.

If you copy code elsewhere, especially from some project that uses completely different editor settings, you get some really weird results. (And I think Guido even said it was a mistake of allowing both tabs and spaces, too! Bet he likes Make syntax, too!)

And I tend to disagree with the goodness of "less typing" and validity of "less confusing". "Less typing" is for people who are pathologically lazy. (One frigging letter more!) "Less confusing" just isn't - I don't mind redundant things if that just makes the things more clearer. (Why do we capitalize the first letter of sentence and add punctuation to the end? That's redundant and nobody gets confused if you drop the punctuation since there's always the capital letters to tell where the sentence starts, right? Not really.)

As for lower rate of confusing constructs - er...

Re:More features - is that what C++ really needs?

[killjoe]

This is why I have always prefered the PHP optional if/endif while/endwhile blocks. I much prefer to see.
          endif
        endforeach
    endif

then

        }
    }
}

Re:More features - is that what C++ really needs?

[TheSunborn]

What problem would adding strings to c++ solve, that can't be solved by a library such as the posix thread library?

Re:More features - is that what C++ really needs?

[Abcd1234]

in the Functional Programming sense of the term, e.g. functions with closures that are first-class objects

You'd be absolutely right, assuming, of course, that Python actually supported true lexical closures, which it doesn't...

Of course, I'm not so silly to think that Ruby is unique in supporting this concept. After all, the creators of Ruby stole most of their ideas from Smalltalk, who, in turn, stole many of their ideas from LISP (although, admittedly, LISP didn't switch to lexically scoped closures until somewhat later in it's lifespan). It's just a shame that Python hasn't done the same.

Re:More features - is that what C++ really needs?

[matfud]

Many languages that use braces as block delimiters allow you to use them anywhere. They are not just associated with for/if/while/bla statements. In java they are just scoping devices. They limit the variables defined within them to he scope they define. so the following works

int bar = 0;
{
    int bar = 1;
    while (bar

And should print "true"

The indentation approach to code blocks misses this aspect and cannot mimick it as two sequential code bloks would be indented similarly.

Re:More features - is that what C++ really needs?

[matfud]

That went to shit

int bar = 0;
{
    int bar = 1;
    while (bar < 10) {
       bar ++;
    }
}
if (bar == 0) {
   System.out.println("TRUE");
}

Re:More features - is that what C++ really needs?

[Simon]

You'd be absolutely right, assuming, of course, that Python actually supported true lexical closures, which it doesn't...

In what way doesn't Python support true lexical closures?

http://en.wikipedia.org/wiki/Python_programming_la nguage#Closures

--
Simon

Re:More features - is that what C++ really needs?

[Abcd1234]

Yeah, too bad it's b0rked (or, more generously, it behaves strangely compared to other languages). Lexically closed variables in Python are read-only.

Re:More features - is that what C++ really needs?

[masklinn]

This is due to the community of the language rather then the language itself. It seems like the Ruby community learned the right lessons from perl and build GEM.

That I perfectly agree, Python Eggs are clearly not in the same league as Ruby's Gems, and it's a shame...

Re:More features - is that what C++ really needs?

[Chainsaw]

You mean, besides that the Posix threading API might not be available in the platform you're currently compiling for?

Re:More features - is that what C++ really needs?

[Breakfast Pants]

Too bad punctuation can effect the meaning of a sentence and so your analogy is flawed, observe:
Yes?
 
Yes.

Re:More features - is that what C++ really needs?

[WWWWolf]

Too bad punctuation can effect the meaning of a sentence and so your analogy is flawed

But that doesn't make the original discussed issue itself go away. I know I can't come up with waterproof analogies, but that's okay because usually people won't start arguing about their applicability, they stick to arguing the actual issues. =)

Re:More features - is that what C++ really needs?

[Zecritic]

But what if you don't need a web framework?

Re:More features - is that what C++ really needs?

[penguin-collective]

It's funny how the ruby community seems to very quickly settle on "the one true thing" and pour their efforts into that while the python community suffers from having dozens of equally popular (and meritorious) frameworks to choose from.

Maybe ther reason is simply that the Ruby community is still smaller. Note that Perl also has half a dozen modules for many common tasks.

C++09???

[mwvdlee]

The work on C++0x has entered a decisive phase. The ISO C++ committee aims for C++0x to become C++09.
C++ octal-9???

Re:Heh

[Mung Victim]

Translation : C++ will continue to be a highly useful language, as long as some other sucker does all the hard work

'Some other sucker' being the hundreds of C++ experts across the world who contribute to the C++ Standard Library and others (e.g. Boost). What would you prefer - Stroustrup does it all single-handed?

As the article says, C++ is a 'general-purpose programming language with a bias towards systems programming'. If the libraries were lumped in with the core language, C++ would be a much less flexible and less appropriate tool for those kind of tasks.

Re:Here's an offer

[jejones]

Take what we have now, add whatever we want, for fucking christ sake get something coherent out of it and call it C+++.

How can one add to something incoherent and get a coherent result?

Slashdot interview?

[nyri]

How about having a slashdot interview about C++0x with Strousrup? I think it would be a good forum to gain more insights about C++ and a fine possibility to allow a community (in this case the slashdot readers) to make and to vote on feature proposals.

Re:Slashdot interview?

[joeytsai]

Slashdot has actually already had an interview with Bjarne:

http://slashdot.org/developers/00/02/25/1034222.sh tml

Re:Slashdot interview?

[Hard_Code]

The comments I made about "concepts" notwithstanding, whenever I see a picture of Bjarne Stroustroup it always looks like he spent two nights without sleep trying to debug some diabolical problem or just emerged from under a gigantic pile of bricks that fell on him.

http://www.lstud.ii.uib.no/~s1099/images/Bjarne_th .jpg (some poor guy's home page, can't find this image elsewhere on google images)

I think he needs a vacation and some sort of spa treatment.

This has brought out the C++ haters

[MeridianOnTheLake]

This has really brought out the C++ haters. Still, most commercial applications, games, utilities, OS's, etc are still written in C++ (or a combination of C and C++). There is a reason for this; it is because C++ is both incredibly effective and extremely efficient. Sure, its possible to create artificial benchmarks that prove otherwise, but in te real world where performance counts, people use C++. But when they want flexibility they go for Ruby or Python or something similar. If you want outstanding applications, you use an outstanding language like C++. If you want average applications, you use an average language like Java.

Re:This has brought out the C++ haters

[ultrabot]

This has really brought out the C++ haters. Still, most commercial applications, games, utilities, OS's, etc are still written in C++ (or a combination of C and C++).

And the guys who write those apps are the very ones who hate C++.

You have to use C++ for a couple of years to truly, honestly hate the language.

Re:This has brought out the C++ haters

[Decaff]

Still, most commercial applications, games, utilities, OS's, etc are still written in C++ (or a combination of C and C++).

No, they aren't. C/C++ is still used for the widest range of applications, but in terms of numbers of commercial applications right now, Java dominates.

Sure, its possible to create artificial benchmarks that prove otherwise, but in te real world where performance counts, people use C++.

I'm afraid that is increasingly not the case anymore. For example, Boeing have requested that all new development is in Java, even for real-time mission-critical high-performance work. The reason they give is that Java is simply a more productive language to work with. You may not agree with them, but this is what is happening.

Re:This has brought out the C++ haters

[Anonymous Coward]

This has really brought out the Java haters. Still, many commercial applications, games, utilities, OS's, etc are still written in Java (or a combination of Java and other languages). There is a reason for this; it is because Java is both incredibly effective and extremely flexible. Sure, its possible to create artificial benchmarks that prove otherwise, but in te real world where flexibility counts, people use Java. But when they want needless complexity they go for C or C++ or something similar. If you want outstanding applications, you use an outstanding language like Java. If you want average applications, you use an average language like C++.

Re:This has brought out the C++ haters

[MORB]

"And the guys who write those apps are the very ones who hate C++."

Not all of them. I've worked for 6 years as a game developer, and I've seen (and written myself) some pretty horrible stuff.
Yet I actually love C++ now, even though I hated it at first.

What I hate are people not thinking thing through before they code and hence writing monstruous code.
And most of these monstruosities are not C++ specific. A programmer who is not able to figure out what to put in a separate function or how to make a proper class hierarchy won't magically do better in Java, C#, Python or whatever else.

Re:This has brought out the C++ haters

[magma]

Java is the VB of C-like languages. It "compiles" to VB 1.0 like pcode, it runs slow, like VB 1.0 but it is complex so it must be good. That is the allure of these languages; the complexity attracts people that think carrying around a Swiss Army knife is a good idea when you you have box full of nails. They all say, 'the right tool for the job' but then make C++ fit every job. It is a kind of intellectual ignorance that says the world so flat. We could all be using Ruby, Python, or, dare I say it here, PHP and write extentions in straight C. We would be more productivity and get more CPU speed and scalability. But then I would raise the ire of the device driver writers that would say I was stupid for suggesting scripting + C. But how many people are writing device drivers in Java? We all know C++ is bloated, less portable, more prone to errors, and slower than C but hey, we have to eat right? That's the only reason I ever used C++, I had to eat and uhm, drive and, o yeah make a living. It's a vicious cycle of unnecessary complexity. I had hoped that the popularity of Linux would help people see the light, but instead all the C++'ers are heading to wreck^H^H^H^H^H improve that platform, too.

Re:This has brought out the C++ haters

[Darren Winsper]

So, Boeing want Java, a non-RT language and runtime for their real-time systems? Oh dear. Hmm...perhaps they'll use RTJ, despite it being a horrible hack.

Re:This has brought out the C++ haters

[Decaff]

So, Boeing want Java, a non-RT language and runtime for their real-time systems?

There is nothing about Java that makes it a non-real-time language. It is being used effectively for this purpose, and staring to take over from C++ and Ada in this area.

Oh dear. Hmm...perhaps they'll use RTJ, despite it being a horrible hack.

No, they are using products that implement JSR-1 which allow standard implementations of Java using the Hotspot optimiser to operate in Real Time.

Re:This has brought out the C++ haters

[Profound]

>> numbers of commercial applications right now, Java dominates.

I don't know about that, depends on how you classify "commercial applications right now"

-Number of stand alone applications running on people's PCs around the world? Definitely not.

-Number of programmers employed and/or counting webapps as applications? Probably yes.

Re:This has brought out the C++ haters

[Decaff]

I don't know about that, depends on how you classify "commercial applications right now"

Number of applications that developers are paid to develop.

Re:This has brought out the C++ haters

[plover]

A programmer who is not able to figure out what to put in a separate function or how to make a proper class hierarchy won't magically do better in Java, C#, Python or whatever else.

No, but they have a better chance of accidentally not breaking something. Thus, in management's eyes, they're more productive.

Re:This has brought out the C++ haters

[metamatic]

Boeing have requested that all new development is in Java, even for real-time mission-critical high-performance work. The reason they give is that Java is simply a more productive language to work with.

Great, now all we need to do is make them aware of Ruby and have them fund some work on making it RT capable.

Re:This has brought out the C++ haters

[Profound]

When the original poster said:

"most commercial applications, games, utilities, OS's"

he meant in terms of world wide USEAGE. When you "corrected" them, you said:

"No, they aren't. C/C++ is still used for the widest range of applications, but in terms of numbers of commercial applications right now, Java dominates.

And "Number of applications that developers are paid to develop."

You redefined the criteria so that:

Windows XP: 1
FireFox: 1
Some internal app used by a dozen people: 1
Microsoft Word: 1
The Sims: 1
World of Warcraft: 1
Hello world: 1

Then claimed he was wrong. That's not very fair, is it?

Re:This has brought out the C++ haters

[PenguiN42]

No, they aren't. C/C++ is still used for the widest range of applications, but in terms of numbers of commercial applications right now, Java dominates.

An earlier poster commented that the very programmers who have to write the C++ apps are the ones who hate C++.

I would like to add that the very users who have to use the Java apps are the ones who hate Java.

Re:This has brought out the C++ haters

[Decaff]

I would like to add that the very users who have to use the Java apps are the ones who hate Java.

Yes, I am sure that businesses and corporations are moving to Java because their users hate it.

Re:This has brought out the C++ haters

[Decaff]

he meant in terms of world wide USEAGE. When you "corrected" them, you said...

Then claimed he was wrong. That's not very fair, is it?

He didn't say anything about usage. He said 'most commercial applications' - an unqualified phrase.

If you want to consider usage, then Java (being the de-facto language mobile phone games) is overwhelmingly popular.

Re:This has brought out the C++ haters

[diamondsw]

You have to use C++ for a couple of years to truly, honestly hate the language.

Whereas Perl only takes a few minutes. Such efficiency!

Re:This has brought out the C++ haters

[Decaff]

Anything that's written in Java -- that'd fit in with Decaff's usual level (ie. making stuff up and circular definitions).

I am not in the habit of making things up. Unlike many posters here, I deal with reality.

If you want actual evidence, go to any job site, and look for Java, C++, C or .NET. There are plenty of commercial applications NOT written in Java, of course, but Java dominates, with C++ usually a very close second.

If you don't like job sites, check for developer surveys, or IT book sales. They tell the same story.

Oh, and if you want to be taken seriously, don't post such insults anonymously.

Re:This has brought out the C++ haters

[Decaff]

Great, now all we need to do is make them aware of Ruby and have them fund some work on making it RT capable.

That would be a great idea, but is likely to take a lot of work. Getting reasonable performance and real-time capability for Java has taken years. However, there is no reason why this should not be possible for Ruby.

Re:This has brought out the C++ haters

[HungWeiLo]

I'm not familiar with the usage of RTJ, but how does the implementation get around GC in a real-time system? What guarantees are there for adequate heap space given that, in theory, it is possible that GC would not gain enough priority to ever run in the system?

Re:This has brought out the C++ haters

[MORB]

"Still, many commercial applications, games, utilities, OS's, etc are still written in Java (or a combination of Java and other languages)."

Can you cite me a single console game written in Java ?
Can you cite me any well-known MMORPG written in Java ?
Can you cite me any well-known PC game written in Java ?
How many OSes written in Java do you know, or written in major part in Java ?

Re:This has brought out the C++ haters

[Decaff]

I'm not familiar with the usage of RTJ, but how does the implementation get around GC in a real-time system? What guarantees are there for adequate heap space given that, in theory, it is possible that GC would not gain enough priority to ever run in the system?

I have no idea.... I expect this is very implementation-specific. However, it certainly does work.

Re:This has brought out the C++ haters

[Decaff]

I hate Java apps.

A very silly comment, as it is impossible for you to tell if you are using one. If you really hate Java apps, then you will obviously hate the majority of commercial websites. Do you use E-Bay? Do you hate it? It runs on Java.

Re:This has brought out the C++ haters

[jgrahn]

What I hate are people not thinking thing through before they code and hence writing monstruous code.

And the people who think things through too much before they code, and hence write monstruous code.

Re:This has brought out the C++ haters

[jgrahn]

This has really brought out the C++ haters.

As it always does. Nothing new here.

Still, most commercial applications, games, utilities, OS's, etc are still written in C++ (or a combination of C and C++). There is a reason for this; it is because C++ is both incredibly effective and extremely efficient. Sure, its possible to create artificial benchmarks that prove otherwise, but in te real world where performance counts, people use C++. But when they want flexibility they go for Ruby or Python or something similar. If you want outstanding applications, you use an outstanding language like C++. If you want average applications, you use an average language like Java.

You're missing the point, I think. I couldn't care less how many commercial applications are written in C++. I use none of them; most of the software I run is written in C, Perl or /bin/sh.

I use C++ because it's fun, fast, flexible and compatible with all the C code out there. And because it's not tied to a vendor or an OS, and because I trust Stroustrup's good judgement. That's enough.

(When I don't need all those things, I go for Python, but there's no conflict implied. The One True Language is a myth.)

Re:This has brought out the C++ haters

[jgrahn]

A very silly comment, as it is impossible for you to tell if you are using one.

If you modify that to "I hate Java GUI apps", it's very obvious which are written in Java, and I loathe them all. I assume that's what the grandparent meant, too.

If you really hate Java apps, then you will obviously hate the majority of commercial websites.

I rest my case ...

Re:This has brought out the C++ haters

[Decaff]

If you modify that to "I hate Java GUI apps", it's very obvious which are written in Java, and I loathe them all. I assume that's what the grandparent meant, too.

You loathe them all. I assume that means the considerable number of mobile phone games written in Java. It also means very popular open source apps like Azeureus, which - by the way - uses the native GUI of whatever platform you are on (so I assume this means you hate GTK+). It also means the large number of Java apps that run on MacOS/X and use an Apple designed and approved version of Swing.

"If you really hate Java apps, then you will obviously hate the majority of commercial websites."

I rest my case ...

So, you dislike the Apple-designed user interfaces, GTK+, virtually all mobile games, and the majority of commercial websites.

Interesting :)

Re:This has brought out the C++ haters

[Breakfast Pants]

That's pretty hard to do since GC isn't deterministic--standard implementations of new/delete aren't deterministic either but C++ allows you to override them and there are deterministic algorithms available.

Re:This has brought out the C++ haters

[Decaff]

That's pretty hard to do since GC isn't deterministic--standard implementations of new/delete aren't deterministic either but C++ allows you to override them and there are deterministic algorithms available.

It it a lot less hard than it used to be, because a lot of work has been put into Java garbage collection to prevent it having an impact on performance. The possibility of using Java for real-time work was realised some time ago. Here is an article from 2001:

http://www.commsdesign.com/design_corner/showArtic le.jhtml?articleID=16503463

I am not an expert in this area, but I have seen demonstrations of how effective this can be. In 2004 Sun even demonstrated real-time device control and non-real time general Java apps running on the same VM.

My personal view is that garbage collection is now finally mainstream, and manual management of memory will be eventually relegated to niche uses.

Re:This has brought out the C++ haters

[Decaff]

Well, I don't know anything about Apple

Then you aren't in a position to judge the quality of their Java applications....

but I do know that every mobile phone game ever is a piece of crap.

This sounds a pretty broad assessment - every game ever - you must have a lot of time to try them all :)

A lot of commercial websites are pretty poor too, though that's more due to low content and high graphics, and zero thought for accessibility. Whatever the backend runs on makes fuck-all difference to me, obviously.

But if the backend makes no difference, that means you don't know if it is Java (most will be).

Azureus is quite good. But that's basically it from a GUI app perspective.

Azeureus is Java.

Sorry to be persistent, but are you getting my point? You don't loathe all Java applications - you haven't even tried them on many platforms. You have probably (like me) tried out some badly written Swing apps and that has put you off (it put me off years ago). But - things have changed!

The thing is, I remember exactly the same sort of fuss about C++ in the 80s - there was a huge amount of fuss about it being 'slow' simply because it wasn't 'cool assembler'. There were complaints about any GUI being too demanding of hardware and slow, with developers preferring text terminals. Of course, it wasn't slow.

The same thing is happening with Java. No amount of real evidence seems to be able to shift an outdated view that it is slow and bulky. For years Java has benchmarked as fast as C for major applications, and people have been using Java-based GUI applications on many platforms without even noticing. Java has been used in hard real-time high-performance applications, in games (even PC games).

I seriously expect in another ten years or so, Java will be totally accepted, and Slashdotters will be complaining about some new language being slow and how much they 'loathe it' :)

Re:This has brought out the C++ haters

[Pseudonym]

Yet I actually love C++ now, even though I hated it at first.

This is a very common sentiment. I used to make exactly the same statements about how horrible C++ was that everyone else does. And then I actually used it to write something nontrivial.

(Even more shockingly, I knew Haskell before I grew to like C++. I must be a heretic.)

Having said that, there is a special kind of pain involved with maintaining old C++ code. By "old", I mean pre-ISO, pre-Boost style C++. Especially if it had to be compilable by MSVC6.

In fact, I'm so sold on modern C++ that I find Qt clunky these days.

(Disclaimer for the comprehension-impaired: Despite the fact that Qt has no better alternatives, it's still clunky by modern standards.)

Re:Here's an offer

[nickos]

Surely that should be C+=2

Lots of detractors here

[Dante Shamest]

But considering that lots of OSS projects like Firefox and KDE still use C++, not to mention commercial games like World of Warcraft, C++ probably does have some saving merits.

Re:Lots of detractors here

[Shillo]

This is a surprise? C++ is what many of us use at work. Of course we hate it. :)

Re:Lots of detractors here

[HumanTorch]

Perhaps it's because all the Python folks have more spare time from programming in a more productive language.

Re:Lots of detractors here

[coolGuyZak]

Concerning Firefox: it is OSS now, and that is what matters.

Concerning KDE: Wrong on several counts.

Re:Lots of detractors here

[magma]

Concerning Firefox: it is OSS now, and that is what matters.

No, it doesn't. The commenter was holding up Firefox as an example of a good OSS C++ project. This might be it's current identity but is not how it started out. It became an OSS project only after it failed in the marketplace.

Concerning KDE: Wrong on several counts.

From your first link: "Qt also includes a closed source development license option available from Trolltech."

So it is closed source, like I said. The license discriminates against people that work for a living. Try and create a license that discriminates say against Arabs, or blacks or whites. It's the same thing. TrollTech is not OSS.

Smarten up, sir.

Re:Lots of detractors here

[coolGuyZak]

No, it doesn't. The commenter was holding up Firefox as an example of a good OSS C++ project. This might be it's current identity but is not how it started out. It became an OSS project only after it failed in the marketplace.

You know, I could spend time coming up with an eloquent response to this reasoning, but I fear that it is somehow not worth my time...

So it is closed source, like I said.

Actually, I believe your message said: " KDE; is not open source.", which is wrong. Both KDE and Qt are released under the GPL. Last I checked, that was the paragon of open source licenses around these parts. That Qt has a proprietary license is irrelevant to the statement, as open and closed source are not mutually exclusive.

My wish-list for c++

[Eternal Annoyance]

property keyword: Used that in object-pascal (the language sucks otherwise). Just define a read and write function, make a property which calls those functions and you can go ahead. Very simple in use (less bug prone), fast to implement and nice on the compiler. While you can achieve the same in c++ it's not as clean and friendly on the compiler.

interface and implementation (both are keywords, comes from pascal) section: lets get rid of seperate header and code files. The idea is aged, inefficient and doesn't help clarity nor ease of coding.

Bit-arrays: yesyes, I know. Boost contains a class which does that. But I think it would be so much nicer if the language had that feature.

Re:My wish-list for c++

[mrsbrisby]

Properties are worthless and good at hiding side effects.

Interface/Implementation split is good- Objective-C does that. Maybe you should consider that.

Bit arrays are dead simple in C, and boost::'s version is complicated as hell. What exactly did you have in mind?

Re:My wish-list for c++

[masklinn]

Properties are worthless and good at hiding side effects.

Properties are a tool, their main goal is to ensure a pure abstraction of the class interface (properties are virtual members, meaning that the outside of the object cannot know and doesn't care wether an attribute is "real" or "virtualized" and they're very good at that, and at allowing clean and straightforward construct with readable syntaxes.

As every tool (C++ operator overloading debacle), they can be abused, badly. That doesn't mean they're *bad*, no more than an oven is inherently bad just because you can burn babies alive in it.

Re:My wish-list for c++

[markov_chain]

interface and implementation (both are keywords, comes from pascal) section: lets get rid of seperate header and code files. The idea is aged, inefficient and doesn't help clarity nor ease of coding.

The only thing I agree about is that the idea is old :) Headers make things vastly more efficient when dealing with system libraries; it would be crazy to compile everything (Didn't Turbo Pascal split things up?). Further, putting an explicit line between interface and implementation helps both clarity and ease of coding.

Re:My wish-list for c++

[andersa]

Headers make things vastly more efficient when dealing with system libraries; it would be crazy to compile everything

There is no reason the compiler shouldn't be able to ignore the implementation section when you are just using the interface. Of course you need the entire source, instead of just the header files, but that's a minor inconvinience in my opinion.

And whether it makes coding easier is a matter of taste.

Btw: I am a total Delphi fan..

Re:My wish-list for c++

[andersa]

Properties are worthless and good at hiding side effects.

Properties are fantastically useful, and the fact that you can hide side effects is totally cool. Of course it's something that must be respected and not used carelessly, but if it's used right it is a very neat feature.

Re:My wish-list for c++

[Malc]

There's already a better approach than interface and implementation. It's IDL. This provides a language neutral interface, with binary portability of the implementation. I can implement it in C++, you can use it in whatever language you want.

Re:My wish-list for c++

[eraserewind]

pretty minor issues in comparison, but:

* automatic namespaces for enums. This omission in the original language bugs the hell out of me.

* standard for automatic/inline documentation. So that it's not just randomly dependent on whatever the developer happens to like.

Re:My wish-list for c++

[Eideewt]

What's with these bit arrays? I'd think that any system small enough to worry about the amount of space a byte array takes up would either be more concerned with the additional time it takes to access a single bit or would not be processing large enough amounts of data for the array size to be a problem. What am I missing?

Re:My wish-list for c++

[NoOneInParticular]

properties... What is wrong with:

class C { T var_; public: const T& var() const; /* getter */ void var(const T&); /* setter */ };

All that this differs from properties is that instead of saying 'a = c.var;' you need to say 'a = c.var();', and instead of 'c.var = a;', you need to say 'c.var(a)'. Not much more typing and it's clear in the code that you're actually calling a member function.

Re:My wish-list for c++

[kailoran]

Ah yes, and why bother with that fancy "operator overloading" concept, after all you're just calling a function, and add(a,b) isn't much more typing than a + b... right? If you have a lot of code that uses c.var = sth and such, and suddenly you realize you need to do some checking on the value passed, then you can't just add the code to the class, you need to change the interface so it's actually a function. The property stuff I'd really like to see.

Re:My wish-list for c++

[Pulzar]

What's with these bit arrays? I'd think that any system small enough to worry about the amount of space a byte array takes up would either be more concerned with the additional time it takes to access a single bit or would not be processing large enough amounts of data for the array size to be a problem.

The one use I'd have for it is writing hardware simulation tests in C++... Right now, it's a bit of a pain to handle individual bits which is absolutely necessary when accessing hardware registers, signals, and forcing/poking into the design. I'm sure the grandparent had another use in mind, though.

Re:My wish-list for c++

[tchernobog]

a) If with "bit-arrays" you mean "bitsets", then I think that is a standard header
b) I'm strongly opposed to keep in the same file interface and implementation. Having header files let you to ship to your users implementation-free documented classes and functions, following the principle of information hiding and making them clearer to read and document. Moreover, this speed up the pre-processing phase of compilation.

I'm not sure to understand this "property" keyword... what do you mean with the sentence "a property which calls [..] functions"?

Re:My wish-list for c++

[MORB]

When you want to reduce the size of something, it's not necessarily because you have a small system. It may be because you have a lot of data. I think there are some situations where you want to be able to store a huge array of booleans, and in this case, you definitely don't want to waste space by storing them as bytes.

Re:My wish-list for c++

[MORB]

"Bit-arrays: yesyes, I know. Boost contains a class which does that. But I think it would be so much nicer if the language had that feature."

There is vector. The standard define that this is a specialization that packs bool into bits.

Re:My wish-list for c++

[Eideewt]

That's good though. Just the kind of answer I was looking for.

Re:My wish-list for c++

[Eideewt]

Yeah, that was all I could think of as well, but I haven't managed to come up with a situation in which you'd want to store so many booleans that you could afford processing power more than extra space, since hard drives and memory are relatively cheap these days.

Re:My wish-list for c++

[cnettel]

So is operator overloading. I mean, if you can write a.plus(b), you can write set_FancyPropertyName(b). Both, done correctly, are much nicer as a = a + b and a.PropertyName = b. I think the dangers of hiding side effects are more or less equivalent. It's also possible to implement properties in current C++ in a quite C#-esque manner, if you just allow a small define (and black art pointer arithmetics to use an offset).

While I would like properties, I think that GCC-esque "statements as expressions" would be great if the syntax was tidied up. Inside those, you can write a nameless class with a () operator and voilà, you have an anonymous functor. And, yes, I think that the need to place a use-once functor where it's actually used in the code would help legibility. I've seen the magical lambda and I want it in a clean language like C++!

Re:My wish-list for c++

[tchernobog]

So, for example: class C { public: int x; }; int a = foo.x; foo.x = a; would produce the same results, no?

Re:My wish-list for c++

[MORB]

It's not a common situation indeed.
I think one I can think about is PVS visibility determination techniques in 3D. Basically, you split your world into convex volumes, and for each of them, you have a pre-calculated array containing one flag for each other volume in the world, to indicate whether they are visible from this one or not.

Re:My wish-list for c++

[NoOneInParticular]

Ah, you mean that you have public variables in your classes?? And want the language to help you to dig yourself deeper in that hole? Good luck with programming, you need it.

Re:My wish-list for c++

[Eli Gottlieb]

In other words, let's add bit arrays to Object Pascal and ditch C++ for it. I really don't get why people don't do that, really.

The only problem I can think of is that there needs to be a way to create interface-only headers that you can ship to users who might want to link to your software.

Re:My wish-list for c++

[daVinci1980]

Bit-arrays

Use std::bitset (for known size at compile time). Or, use std::vector<bool> if you need to resize. (std::vector<bool> is defined to be a special case of std::vector to only take one bit per entry).

Neither are particularly complicated, and bit arrays (imho) do not deserve a special place in the language core.

In general, the language should be as simple as it can possibly be to achieve all it's stated goals. The libraries around the language should be as comprehensive as they can be, however.

Re:My wish-list for c++

[kailoran]

This is not about having public variables, this is about simplifying the syntax a little bit, so you can do c.var = x that works like c.var() = x or c.setvar(x). I don't see it as something so *wrong*.

Re:My wish-list for c++

[bored]

This is just a silly statement and refects a very shallow knowledge or programming. I've seen what happens when "no public variables" type people try to write real applications. 30% of the application code is just simply getter and setter methods, which really makes things ugly.

The whole OOP paridigm could be called "syntatic sugar" after all I can write code like myfun(var) rather than var.myfun(). The idea with properties is that its often times a _LOT_ clearer to simply say window.width=50; than window.setwidth(50). Especially when instead of 50 its another function call, or a complex expression. Its all sort of a matter of taste, also having the ability to design a class and then go back and change the behavior on the fly when someone changes a variable completely removes the need for shitloads of getter and setter methods.

Re:My wish-list for c++

[EvanED]

Of course you need the entire source, instead of just the header files, but that's a minor inconvinience in my opinion.

Depends. If you're releasing a commercial (to the naysayers, fine, a proprietary) library, you could very well not want to do that.

It's not a total wash of the idea because you could still support separate files (in fact, you'd very nearly have to with the code base that's out there).

Re:My wish-list for c++

[EvanED]

(std::vector is defined to be a special case of std::vector to only take one bit per entry).

No, it's not. It's defined to be a special case of std::vector with modifications that ALLOW implementers to make it take one bit per entry.

At least a couple books say that most libraries don't do that.

Re:My wish-list for c++

[tchernobog]

So in "free pascal" the "property" keyword allows you even to give a check range? Or have you to code the function anyway, like you did? This is the point.

Re:My wish-list for c++

[NoOneInParticular]

You must be from the Java school of OO-thought. If you indeed get into the situation that much of your code is setter functions (getter functions don't matter, these don't hurt), you should seriously consider if you shouldn't actually be using structs instead of classes and a library of functions to manipulate these structs. I.e., write C-code instead of classes with members. Personally I use classes sparingly, usually in two cases: (a) when there is a clear invariant that needs to be maintained for the data. Member functions are supposed to hold this invariant, which means that setters are in general dissallowed. (b) for functors, even though C++ structs can do them as well. In the end, about 30% of my code ends up being class based code, the rest is algorithmic code: simple functions that use these classes (some of this algorithmic code does end up in a functor, but I don't really think that counts: the functor is a workaround for not having real closures.).

When I for instance look at the code 'window.width = 50', the principle of least surprise is violated (as is too often the case in C++ already). With properties I have to look at the header file to see if actually this action means that the window will be resized, or that it will happen after some 'window.update()' function is called. 'setwidth()' or 'width()' (or preferably, 'resize()') doesn't have this problem, I can safely assume that the window is resized. With properties in the mix this is not clear, as practically every assignment can actually mean a function call. This is the main issue with properties: with these floating around it becomes even less obvious what a piece of code does. I don't think they provide an improvement in syntax as they really obscure what is going on.

Re:My wish-list for c++

[daVinci1980]

Whoops!

I had read The C++ Standard Library, by Josuttis, and remembered that in section 6.2.6 he said the following:

"For Boolean elements of a vector, the C++ standard library provides a specialization of vector. The goal is to have a version that is optimized to use less size than a usual implementation of vector for type bool."

I had forgotten that in the next paragraph, the book said: "However, how vector<bool> is implemented is implementation specific."

Mybad. However, the implementations I have used have all treated a vector of booleans as a resizable bit field. At any rate, resizable bit arrays still don't (imho) deserve special status in a language. They should be possible, but not necessarily part of the language proper.

Re:My wish-list for c++

[EvanED]

I had read The C++ Standard Library, by Josuttis

Good book. I've got it sitting a few feet away.

However, the implementations I have used have all treated a vector of booleans as a resizable bit field.

I can't easily check to see if what I'm using does, so I'll take your word for it.

At any rate, resizable bit arrays still don't (imho) deserve special status in a language. They should be possible, but not necessarily part of the language proper

Agreed. If the standard committee drops the bool specialization (unlikely), they should add a resizable bit array. If they don't, they should consider mandating the space optimization. (It's at the cost of speed though, so who knows. Hard to say.)

Re:My wish-list for c++

[Old Wolf]

The "property" keyword lets you do the "private data, public accessor" thing without having trivial wart functions all over the place. Have you ever looked at a Java file? Half of it is " int getFoo() { return foo; } " .

Here's some syntax from the Borland compiler (which supports properties):

    class X
    {
        int m_foo;

    public:
        __property int foo = { read=m_foo, write=m_foo };
    };

Then, when you want to make the set-function do something non-trivial, you can change the class definition and not have to re-write any client code:

    class X
    {
        int m_foo;
        void set_foo();
    public:
        __property int foo = { read=m_foo, write=set_foo };
    };

The major problem (for me) with properties is that it means a simple assignment can have side-effects, which might be unexpected. I'm not sure whether this means I should flame properties, or change my attitude. :)

Re:My wish-list for c++

[bored]

You must be from the Java school of OO-thought. If you indeed get into the situation that much of your code is setter functions (getter functions don't matter, these don't hurt), you should seriously consider if you shouldn't actually be using structs instead of classes and a library of functions to manipulate these structs.

Thats funny, you should talk to the java programmers here. It might be funny, I personally dislike the java OO model. I think it sucks. I do like C++ though, and I really like the VCL that borland makes (since C++ doesn't enforce an OO model). In my opinion what is taught as OO (especially with java) is so far away from what it was meant to be, i've decided to sign onto the "component" bandwagon. This better describes the way I use, and the way I write code. Small components which have definite purposes and are _SELF_ contained. In other words they don't tend to depend on big inheritance tree's and they can be used simply by learning smaller well contained interfaces. I'm not afraid of procedural code using objects, nor am I afraid of setting a public member variable. Hell I even create global classes to deal with global resources instead of passing a refrence around to every method in my program just to access 1 instance of a class. I rarely use static members, and I use constructors and destructors for what they were meant to do rather than making start() and stop() methods. Personally after having seen getter and setter messes created by other programmers I never use them unless they acually have work to do. I would rather go back and change 1000 x.y=z's to x.sety(z) than write a bunch of useless code that doesn't do anything and has to be maintained.

When I for instance look at the code 'window.width = 50', the principle of least surprise is violated (as is too often the case in C++ already).

I agree with this, and that particular example comes from the VCL, which tends to do a lot of things automatically for you. This means that you pretty much never have to call the repaint() method. It makes sense after using it for about 30 seconds. The VCL follows a simple rule. Variables (accually properties) which affect something have there affects felt as soon as they are changed. So you simply set the width and if the window is visible it resizes, you set the visible=true property and becomes visible, you create a new button giving it a parent window in its constructor and it paints on the window you specified. If you set a database field to something it updates the result set. The list goes on. Once you get used to this it is a _VERY_ natural way to program. There is sort of a unwritten rule about what ends up as a properly and what ends up as a method though. Its a fine line, and i'm sure a lot of people cross it (maybe even me sometimes). In general if the method accually does something then it gets a method. Which isn't very clear, but if the intention is to resize() the window then you make a method which takes the height and width. Its like operator overloading, a.add(b), a=add(a,b), or a=a+c. Which makes more sense, well in this case the last one does but it may not be clear all the ugly stuff going on behind the behind the scene especially if you didn't relize that a and c were vectors. Same with win.width=50; If the window isn't visible all I wan't to happen is have the width set, if its visible I want the width set and the window repainted.

Re:My wish-list for c++

[mrsbrisby]

So is operator overloading.

Operator overloading is stupid as well.

I want it in a clean language like C++!

You really think this:

template>Random_access_iterator Ran, Predicate Cmp< where Can_call_with<Cmp,C::value_type> void sort(Ran first, Ran last, Cmp less);

is clean!?

Cleaner than this?

@protocol MySort
-(int)compareTo:(id)x;
@end
NSArray *sort(NSArray *in, id f);

(equivilent Objective-C code)

Re:My wish-list for c++

[mrsbrisby]

the fact that you can hide side effects is totally cool.

Can this fail?

a = a + b;

Of course it's something that must be respected and not used carelessly, but if it's used right it is a very neat feature.

By right, how exactly do you mean?

Lots of things are said to be "bad in almost every case, but good in at least one, so let's put it in"- I'd like to know exactly when properties should be used correctly.

Every single example I've ever seen either indicates seemingly-random exceptions should be thrown, or unexpected delays should occur.

At least with actual functions/messages/methods/etc these things can actually be understood by mortals :)

Re:My wish-list for c++

[mrsbrisby]

As every tool, they can be abused, badly. That doesn't mean they're *bad*, no more than an oven is inherently bad just because you can burn babies alive in it.

That's an excellent argument for goto. I expect to see more of it in your code.

Unfortunately, it's a bad argument for side effects- One has to actually put babies into the oven to burn them with it. With properties, it's like putting them in the crib and the oven rips itself out of the wall, goes down the stairs, into the baby's room, and proceeds to burn the baby.

When properties are in use, they can make things happen that make no sense.

Properties could be useful if they were restricted to no function or method calls - i.e. set a flag for later, or to forward the member update into a parent class.

Of course, you could get to the magic mode if you'd put:

IM_DOING_SCARY_SHIT_HERE

right above using them from outside the class- failure to do so and the compiler would warn you that dangerous magic is afoot.

Re:My wish-list for c++

[masklinn]

That's an excellent argument for goto. I expect to see more of it in your code.

I'm sorry to say that I currently use goto-less languages (although I expect a patch to implement come-from in them soon). That said, goto is indeed a tool and has it's uses despite the hatred of Dikjstra and Wirth for it, see the Linux Kernel code for uses of goto. I would use gotos if I coded in languages allowing it and if the situation required it.

When properties are in use, they can make things happen that make no sense.

How about blaming the designer of the api/lib/whatever for his misuse/abuse of properties instead of the properties mechanism itself?

Re:My wish-list for c++

[Anonymous Brave Guy]

There is vector. The standard define that this is a specialization that packs bool into bits.

And in doing so, violates just about every sane property of every other container type in the language. D'oh! :-)

Re:My wish-list for c++

[angel'o'sphere]

property keyword:
IMHO the ugliest and silliest invention ever.
Yes, a simple way to write get/set methods is nice.

But a property like in C# and the rest of .Net is the stupids thing I ever saw. You write code like variable . and hit the dot. Intellisense or your favorite code completition mechanism shows the identifiers you may write behind the dot. But: what comes then? Some ( and ) as in a method? Or nothing as in a property?

I have compiler errors all day long just because I don't know if a thing I reference is a property or a method. (untl th compierl tells me)

WTF I only can say. ALL PROPERTIES have on machine level a get/set method. So the fucking language should use propertie definitions only as syntactical sugar to declare a set/get method pair. And when I want to access a property the fucking compiler has to fix it for me if I write a method call and not give a: oops you can't call a property as method - error.

And then again, you see ppl posting they prefer C# over Java. /me shaking head over such ignorance

angel'o'sphere

Re:My wish-list for c++

[tepples]

there needs to be a way to create interface-only headers that you can ship to users who might want to link to your software.

Why not ship the whole source code to your library? Or are you talking about language-level support for dynamic linking?

Re:My wish-list for c++

[andersa]

Can this fail?
a = a + b;

I don't see how. In the case that both a and b are properties, and the properties have read methods, which is not necessarily the case (most often it's not in fact), then the read methods must complete entirely before the expression can be calculated. The result is stored in a, which might be a write method, but this happens only after the read method has completed, so we are ok.

Essentially a property is not much different from a method without arguments, and it should be treated as such, and not as a standard variable. Actually you can also have properties with arguments in certain cases. They work mostly like arrays. You can even use a string as the array key.

At least with actual functions/messages/methods/etc these things can actually be understood by mortals :)

The major point is that you should always consider calling a property to be the same as calling a method. Methods can cast exceptions if they feel like it, and a method could take an unexpected amount of time. It's nothing more than a very convinient interface. When I say "used right" I am mainly saying that nothing unexpected should occur when you call a property. And that it might take a while to complete should not be unexpected if you consider a property to be equal to a method. Documentation is important here. Every possible side effect should be documented.

Re:My wish-list for c++

[Minna Kirai]

meaning that the outside of the object cannot know and doesn't care wether an attribute is "real" or "virtualized" and they're very good at that

I don't think that properties could hide the nature of attributes very convincingly in an elaborate language like C++. They work in the case of
    M.x = 10;//property, or public var? Can't tell
but probably fail for
    SetCursor(M.x++, M.y++);//fine with public var
and
    LimitToRange(&M.x, 0, 640);//also fine with public var

Prehaps there's a way to implement properties to handle those cases, but it won't be a simple fix, and I doubt C++ linkers have enough authority to handle it.

Re:My wish-list for c++

[Minna Kirai]

Every single example I've ever seen either indicates seemingly-random exceptions should be thrown, or unexpected delays should occur.

That bridge was already crossed back when operator-overloading was first allowed. Your example statement "a = a + b" might be invoking operator+() and operator=(), which could randomly throw exceptions or take a long time to complete.

The bigger objection to properties is that they do a poor job of emulating true public member variables. The goal of properties is that they allow necessary side effects to happen when a member is changed. But how could the following code work if x was an int "property"?
      void foo(int *p){ *p = 20;};
      void bar(){
            int i = 10;
            foo(&i);
            G g;
            foo(&g.x);
            }

How is foo() able to cause a side effect when passed &g.x, but not when it gets &i? Unless that question can be answered satisfactorilly, properties won't fit well in C++.

Re:My wish-list for c++

[Minna Kirai]

properties... What is wrong with:

Moreover, people who demand "property" support in the C++ language should consider building it themselves. As a dense 1-line macro, even!

#define PROPERTY(T, N) private: T N##_;public:const T& N()const{return N##_;};void Name(const T& t){N##_=t;};

They could use the PROPERTY macro to build their classes, and in the event that a variable turns out to need side-effect code run before/after it is read/written, that macro can be replaced with manually-editted getter/setter functions.

Re:My wish-list for c++

[Minna Kirai]

And in doing so, violates just about every sane property of every other container type in the language.

The reason it must do that (as you probably know) is because the CPU's pointers are not capable of addressing individual bits. Addresses can only point to whole bytes.

Interestingly, this means that the choice to add a special vector into a library is analogous to the argument for adding a "property" keyword to C++ (discussed elsewhere in this thread). In both cases, a situation is created where the programmer may temporarily think she is accessing actual variables in a structure, but the illusion cannot be maintained.

You can tell that vector is fake by trying to take the address of one of its elements (which fails because sizeof(bool)>sizeof(bit)). Likewise, using "property" to masquerade a function-call as a variable fails when the user asks for the address of the "variable".

Re:My wish-list for c++

[Minna Kirai]

your favorite code completition mechanism shows the identifiers you may write behind the dot. But: what comes then? Some ( and ) as in a method? Or nothing as in a property?

File a bug report on your IDE. It already parsed the class definition to know what the member variables are named, so it should also know if they are properties or methods, and be able to insert any needed parentheses on its own.

Re:My wish-list for c++

[masklinn]

Duh, well, C++ doesn't have properties anyway.

But the first case would in fact be extremely simple to implement: extract the value of the property (call the getter method under the hood), send the retrieved value to the function, add "1" to the retrieved value, call the setter method of the property.

Here you are, done, I don't see the issue here, this is completely trivial.

The second case would prove more problematic philosophically: shall we send the method a reference to the property object itself, or to the value retrieved from it? Sending the property object would probably break the type system, so we'd have to go with the object retrieved (makes sense). Luckily, languages implementing properties don't have that kind of insanity, so the issue is moot.

(Final note: calling C++ "elaborate" may be going a bit too far, Smalltalk, Ruby or Python seem much more "elaborate" to me.)

Re:My wish-list for c++

[Minna Kirai]

But the first case would in fact be extremely simple to implement:

Actually, it's exactly as difficult as the second case. I gave the same problem twice in different guises. You can't be sure that ++ really means to add 1. There could be an overloaded operator++ involved, and it might do absolutely anything. In light of that possibility, the concerns are exactly the same as when a non-const reference is passed to an arbitrary function.

See also this comment for a longer example of the implications of C++ property. And this comment, while you're here.

Luckily, languages implementing properties don't have that kind of insanity, so the issue is moot.

Since the topic was a proposal to add "property" to C++, it certainly wasn't moot.

(Final note: calling C++ "elaborate" may be going a bit too far, Smalltalk, Ruby or Python seem much more "elaborate" to me.)

I intentionally chose to call it "elaborate" because although there are languages which are more powerful and flexible, C++ has more explicitly different features in its specification (instead of allowing more of the features to be a natural consequence of fundamental capabilities). Inheritance, templates, operator-overloading, and exceptions don't flow naturally out of the primitive structures; they are all separate features.

I was particularly thinking of the functional languages like Lisp, which have more expressive power than C++, and from smaller language definitions.

I'll agree that Perl and ADA are possibly more elaborate than C++ (depending on how you measure).

Re:My wish-list for c++

[masklinn]

Actually, it's exactly as difficult as the second case. I gave the same problem twice in different guises. You can't be sure that ++ really means to add 1. There could be an overloaded operator++ involved, and it might do absolutely anything.

Aah, perfectly true, I had forgotten about the potential overloading of that operator and stand corrected

Re:My wish-list for c++

[jgrahn]

automatic namespaces for enums. This omission in the original language bugs the hell out of me.

It's not an omission, it's C compatibility and thus vital to C++.

It wouldn't surprise me if Boost contained the thing you want. Or else, wrap your enum in a struct and add a typedef.

Re:My wish-list for c++

[eraserewind]

I know how to workaround it. Having to bugs the hell out of me as I said.

Also, I don't really see why it is a C compatability issue. The enums only live in the source code. They don't make it to the binary.

Who cares if C thinks the values of:

enum animal { cat, dog };

should be referenced globally as "cat" and "dog"? You are writing C++, why not reference them as "animal::cat" and "animal::dog"? It'll all become the same integer value in the function call to whatever C library you use anyway.

Re:My wish-list for c++

[mrsbrisby]

Can this fail?
a = a + b;

I don't see how

What about a database engine that locks the records a and b for reading?

What about performing a division operation or some write system call?

What if + is overloaded?

Essentially a property is not much different from a method without arguments, and it should be treated as such,

That's the problem. a = a + b doesn't look like a property. In fact, it might not be, YOU DON'T KNOW JUST BY LOOKING AT IT. It might be that + is overloaded, or that a has a write property that does something funny.

You simply don't know just by looking at it, and I'll bet that if we weren't talking about properties right now, you would NEVER give a statement like a = a + b a second thought.

Re:My wish-list for c++

[mrsbrisby]

That bridge was already crossed back when operator-overloading was first allowed. Your example statement "a = a + b" might be invoking operator+() and operator=(), which could randomly throw exceptions or take a long time to complete.

I think operator overloading is a bad idea for the same reasons.

The bigger objection to properties is that they do a poor job of emulating true public member variables. The goal of properties is that they allow necessary side effects to happen when a member is changed.

That's why I recommend when writing code intended to do those kinds of side effects (in your example code) you'd write a:

IM_EXPECTING_SERIOUS_MAGIC (or something like that)

Immediately surrounding your second foo() call.

properties won't fit well in C++.

Preaching to the choir... :)

Re:My wish-list for c++

[mrsbrisby]

How about blaming the designer of the api/lib/whatever for his misuse/abuse of properties instead of the properties mechanism itself?

Because it's not the API fault: They could be using the tool completely correctly (by someone's definition of the word) and someone looking at code calling that API wouldn't know it.

They might get curious if they see something like this:

while (a = b);

But chances are they'd think that they meant == instead of = - and THAT's the fault of the mechanism itself.

By the way, I use goto and when I do, people can see exactly where any why I'm using it. Not so with properties, which is why I said comparing the two doesn't work very well...

Re:My wish-list for c++

[andersa]

First of all, in practice there is never any doubt whether you are using a property or a variable. You can not be handed a variable and not know if you are really dealing with a property.

Properties are always part of classes. The case of 'a := a + b' (as it would be written in Delphi) would only make sence inside the scope of a method that belongs to the same class as a and b. This means you can just look up the documentation of this class and immidiately know that a and b are properties. With experience you will remember in your head if you are using a property or not.

In all other cases you will be explicitly stating which object you want to use the property from. It would look like this: 'myObject.a := myObject.a + myObject.b'. This is not much different from the case where a and b are methods of myObject, the only difference is that myObject.a accepts assignments. Again using Delphi as model, this is just a shorthand notation for writing 'myObject.SetA(myObject.a + myObject.b)'.

Properties can not be global. They are always part of some class. And it is always obvious which class they belong to.

The IDE also helps you with its code completion feature, which puts up a hint on the screen while you are coding that the member you are using is a property. This is cheating of course.. :)

The only nasty example you give is a case where reading the property 'a' results in 'a' being not writable afterwards. A property that behaves this way is rather stupid. In any case such behaviour should be well documented. Typically attempts to write any property which is not ready to take input will raise an exception. Properties that does not support write at all (these are pretty common in fact), always causes a compilation error if you try to assign to them.

I can't really see what the difference should be between summation and division in this context. Since properties always have clearly defined types (like integer or real) it is always obvious what the result of such an operation should be. It will work just like it would if you tried to perform the same operation on variables of the same type as the property.

If + was overloaded, it would in fact be a member function of the property 'a'. Again since 'a' must be a clearly defined type, it is obvious what the result would be. First of all you fetch the value of 'a'. 'a' is of class myClass that overloads + to make 'a + b' meaningful. If the overloaded + doesn't take arguments of the type that b belongs to the code will fail to compile (this is standard operater overloading behaviour). The result of the operation 'a + b' is defined by the overloaded + operator. Now it is simply a matter of whether it is legal to assign this result to 'a'. If it's not, again the compiler should complain.

Re:My wish-list for c++

[mrsbrisby]

First of all, in practice there is never any doubt whether you are using a property or a variable. You can not be handed a variable and not know if you are really dealing with a property.

Sure there is. There's doubt as to whether a was a member or not- Even though I repetedly referred to API issues with properties in this thread.

In all other cases you will be explicitly stating which object you want to use the property from. It would look like this: 'myObject.a := myObject.a + myObject.b'. This is not much different from the case where a and b are methods of myObject, the only difference is that myObject.a accepts assignments. Again using Delphi as model, this is just a shorthand notation for writing 'myObject.SetA(myObject.a + myObject.b)'.

Nobody is talking about Delphi except for you. Delphi is trying to be a better pascal, and if you ask me, that's not a very difficult thing to do.

C++ on the other hand, is trying to be a better C. In C, m.a = m.b + m.c NEVER means anything but m.a is equal to the machine-sum of m.b and m.c (which of course includes things like overflows).

It doesn't mean assign(&m.a, sum(&m.b, &m.c)) and nobody thinks it should either. That's why properties were invented, so that people wouldn't have to think it should mean that.

Properties can not be global. They are always part of some class. And it is always obvious which class they belong to.

Sure they can: That's what a static, public property would be.

If + was overloaded, it would in fact be a member function of the property 'a'.

I say properties are bad, I'm no where saying overloading operatiors is good. That's not good either for all the same reasons I'm giving here.

Re:My wish-list for c++

[andersa]

Well perhaps we are not talking about the same thing here, so it will be hard for us to agree.

You say that "m.a = m.b + m.c NEVER means anything but m.a is equal to the machine-sum of m.b and m.c".

It works exactly the same with properties, so I fail to see where your problem lies.

Ok, so weird stuff MIGHT happen when you perform m.a or m.b or m.c if they are properties because you are actually calling a method, that's undeniable. But unless reading the property fails entirely, you are still going to end up with a perfectly normal variable that you can add together with another one to get a result. There is no chance that reading m.b might suddenly result in a string, if you expected an integer.

Re:My wish-list for c++

[StrawberryFrog]

a property like in C# and the rest of .Net is the stupids thing I ever saw. ... But: what comes then? Some ( and ) as in a method? Or nothing as in a property?

And you're too wrapped up in C-style semantics to realise that this is a distinction without a difference. In Delphi/Object-Pascal, for all it's faults, one good thing is that a function call with no arguments can omit the brackets, so if "foo.BarValue" returns an int, you do not need to know or care if "BarValue" is public data, function or property. So then it can be changed from one to the other without affecting client code - which must be a good thing.

After stepping back and taking a better look, requiring () after a method name looks like the stupid thing.

Properties in c# are not perfect, due to the wart that you have pointed out, but it is simply not sensible to think they are "useless" and "stupid" because of this.

Re:My wish-list for c++

[mrsbrisby]

Ok, so weird stuff MIGHT happen when you perform m.a or m.b or m.c if they are properties because you are actually calling a method, that's undeniable.

Not only that, it's also a problem. If the programmer doesn't know what's going on by reading the code, how is this a good thing? Why is it good to hide even more from the programmer?

But unless reading the property fails entirely,

That's just it, consider a read-property that reads from a database. Now the database is down so the read-property loads garbage but never checks its error- simply "returns 0" or something.

Programmers do this crap all the time in API and nobody ever notices until it starts causing a problem. The programmer using the API might've either assumed that it throws an exception, or that the values were loaded by an earlier call (The constructor?) that checked for errors. Who knows.

There is no chance that reading m.b might suddenly result in a string, if you expected an integer.

So what? Type checking isn't the issue. Type checking isn't even a problem!

What is a problem is that reading m.b might take a long time, draw on the screen, read from the disk, or send data to the network, and nobody will know because the programmer thinks they're just reading a memory location.

The only time the programmer might notice is if they single step into the assignment operation and see their debugger jump into some assembly dump.

And that is just wrong.

Why is it even needed? Because putting () all over the place is ugly?

I've seen real code that looks like this:

m.update(m.key(),
    m.add(m.value(m.key()),
          n.value(n.key())));

That in Objective-C would be written as:

[m update:[m key]
    withValue:[m add:[[m key] value]
                  to:[[n key] value]]];

And you know what? People can read it with or without seeing the documentation or the headers- they understand exactly what would be going on, and that we've got a lot of message send operations (maybe something to optimize there), and several classes/selectors that might be involved.

Introduce properties, and it looks like this:

m.key.value = m.key.value + n.key.value;

And it doesn't cary ANY of the semantic information that either of the two previous examples had. The programmer won't know how fast or slow this'll run (and assume pretty fast), and won't know either getting the value can fail, or have side effects, or etc.

The end result is that we've confused the programmer, and they'll make a mistake. I'm sure the C++ example is hard to read to some people (even some C++ people), so they say the problem is that our C++ here needs to take advantage of overloading and properties so that it'll be easier to read INSTEAD OF making the API itself better, or using intermediates, or anything else that can make the code better, faster, and easier to follow.

Meanwhile, in Objective-C, that construct is fairly common and nobody complains. nil rocks.

Re:2009?

[frantzdb]

I doubt Google, Adobe, or many of the thousands of other companies depening on C++ will be throwing their code base away any time soon. Rather, they will want their C++ code to be more robust and more managable. The features the article lists all seem to do this.

(See Stroustrup's C++ Applications page for more.)

Re:Downhill at a fast rate

[famebait]

Tell me about it! And those fancy editor thingamajiggs? A-phoooey! Real Programmers use cat(1) and do it right the first time!

Re:Downhill at a fast rate

[jcr]

I still think C++ was invented as a joke.

Not a joke, a research project. Thus, Stroustrup's willingness to include any "feature" that someone suggests: "Oh sure, we'll put that in and see how it works out."

The upshot is a language that is accreted instead of designed.

When I found the C language, I stopped looking. Ah well.

Too bad.

-jcr

the state of being advanced

[digitaldc]

In my opinion, many people are trying too hard to be clever and advanced.

I was advanced once, but unfortunately it just left me waiting for everyone else to catch up.

Re:the state of being advanced

[the eric conspiracy]

Debugging is 10x harder than programming, so if you write code at the edge of your abilities there is no way in hell you will be able to debug it.

Re:2009?

[famebait]

There'll be good money in it in a few years, when noone who graduated this century masters it, and all the non-masochists have moved on too, but stuff still needs to be maintained. The old COBOL story all over again.

Re:Make Bjarne leave it alone!

[AuMatar]

They do redefine C every few years, the last time was in 99. Of course, the changes were minor. The biggest one I remember was that // is now a comment, and a few other tweaks. No whole features added.

Re:Heh

[mrsbrisby]

What would you prefer - Stroustrup does it all single-handed?

It might be nice if he could.

Stroustrup lives in a fantasy world where the only reason C++ isn't as fast as C, or produce as small of assembly as C is because of the compilers- which he conveniently disavowes responsibility for.

Compare to Objective-C: You'll note that these new C++ "concepts" feature are extremely similar to Objective-C's "protocols"- only not only can a moderate programmer produce a fast Objective-C compiler, they'll know exactly where it can be slowed down and why.

It'll also already be able to do these things in C++ that are so new and innovative.

Meanwhile, some C++ compilers can make "cout << 1 << endl;" slow- and others only do it when the programmer tries to make their own "cout" like device.

If the libraries were lumped in with the core language, C++ would be a much less flexible and less appropriate tool for those kind [systems programming] of tasks.

No, it's if those libraries imposed greater responsibilities on the runtime. As it stands, the C++ runtime already has an awful lot to do- albeit less than Java or Objective-C.

Worse still: The C++ runtime isn't a peer to your own code as it is in Objective-C: With Objective-C you can interact with the runtime as if it were regular library calls.

C has a mountain of library code available, and the functionality of that library code drives new extensions to the C core language (TLS extensions, for example)

But then, C has almost zero runtime (and if you reject certain extensions: it actually has no runtime), and that's what makes it suitable for systems programming.

I don't think C++ is now, or ever was (or with the way these "extensions" keep showing up) - or ever will be suitable for Systems Programming.

Because the C++ programmer infrequently can understand what his runtime is doing- and is not encouraged to know the interface by which C++ does it's magic (because nobody knows- they're still trying to figure out how to make some C++ magic work in a way that isn't slow)- a C++ systems programmer needs a C++ runtime. Nobody has one in systems-space, so the C++ programmer (which isn't a programmer of C++) needs to write it.

The inventor of C++ can't even do this, but any moderate programmer could do this for Objective-C.

Just get rid of it altogether

[sillybilly]

What I'd really like is a fully vertical programming environment that's more humane, lets me get to the bare metal if I want to, or be very lazy and high level, if I want to, it would do assembler, C, C++, and higher than C++ level, a set of languages where I know what each statement expands to in the lower level, where the compiler sort of holds my hand, and shows me what's going on, and I'd rather have a more plain english compiler output even if it's not optimized, or if it's optimized and difficult to follow the jumps, then a plain english description of why it's doing it. What happens when I write a statement and get a bug is too much behind the scenes for me, too much of a smoke and mirrors, too cryptic. I'm lazy and prefer writing programs the easy way, in very high level languages, say in basic, python and perl, unfortunately they lack performance because most are interpreted. There should be a way to do high level without interpretation, but instead compiling into lower level stuff, after all, instructions in one language should have a 1 to 1 matching of what happens in another language, or there could be such an optimized matching. If I was allowed to constantly inspect what each high level construct translates to in the lower level language that's still higher than assembler, in a human readable form, that could improve the overall performance and bug issues for all the levels of programming, because if there is a problem, a bug, the programmer could inspect and figure it out and submit patches. I find myself learning things mostly when I'm involved with a task at hand, if I didn't have a problem, I'd never learn about something. I'm sure most people are intelligent enough to figure things out if they really need to, but they have no transparent and easy way these days, it's all or nothing, C++ to straight assembler, and they are stuck with starting off writing a program in a difficult and low level language because that's all you can do - once you made choice and settled on a language, or even a set of libraries, you're stuck with it, and if you don't like the language code, you're welcome to look at the compiler output in assembler. I'd rather see some smoother transition layers, something that starts out very nonverbose and progressively gets more verbose and difficult as you go lower on the layers. Something that starts out as simply as drawing a few diagrams to generate some very high level code, almost in plain english, that a compiler translates into C++, that I can look at, and even see what C++ would translate into in C, and then C into assembler. Some Microchip PIC c compilers retain the original C code next to the assembler part, so it's readable what's going on. Even dotnet that's an interpreted language, that too can list the bytecode next to the original code. I'd like to see what happens, all the way to the bare metal. Yes compiling time would go up, but you could skip intermediate stages if you wanted to. One of the worst things these days is that there is no single programming environment where I can sit down and 'own' the computer, without working my ass off, unless I want to. An environment that debugs the speed of the code, shows you what happens where, what code consumes a lot of memory, what code portion took how many milliseconds to execute, and with this constant feedback, I could concentrate my efforts on the portions I'd like to concentrate on. You could have the 4 level layers called C-02, C-01, C+00, C+01, C+02, etc. C-02 equivalent to the architecture layer, C-01 to the C layer, C+00 to what currently C++ is, C+01 to something like basic or python, and C+02 to some diagramming software (like VB/VBA macro record or Visio or something similarly super-easy). You could then directly compile C+02 to C-02 if C+02 diagramming software is all you know, or go deeper in the in-between levels, depending on how much elbow-grease you'd like to put in and what your skill level is, you could go from C+02 to C+01 to C+00, each code expandable if it has a hand-coded equivalent, or just using the de

Re:Just get rid of it altogether

[ForeverFaithless]

Dude, have you ever heard of text formatting?

Re:Just get rid of it altogether

[Slow Smurf]

If you don't preview and use the default option, it removes line breaks that you may have seen in the comment box.

Re:Just get rid of it altogether

[Anonymous Coward]

"Dude, have you ever heard of text formatting?"

As a die-hard C/C++ fan, he figures redundant whitespace will just compile out in the end.

Re:Just get rid of it altogether

[guitaristx]

What I'd really like is a fully vertical programming environment that's more humane, lets me get to the bare metal if I want to, or be very lazy and high level, if I want to, it would do assembler, C, C++, and higher than C++ level, a set of languages where I know what each statement expands to in the lower level, where the compiler sort of holds my hand, and shows me what's going on, and I'd rather have a more plain english compiler output even if it's not optimized, or if it's optimized and difficult to follow the jumps, then a plain english description of why it's doing it.

What I'd like is more line breaks and periods. =P

I do like your ideas. However, I would be quite uncomfortable with translating C++ into C; the C code is going to be rather scary with stuff like class inheritance, and, in many cases, wasted effort. In general, I think that the belief that C++ as a language is translatable to C without either reaching down into the assembly code or creating hideous obfuscation is flawed. As an alternative, I would like a platform-independent mangling scheme for C++ functions that cannot be easily translated to C, so we can see the mangled names in the debugging symbols. I have experienced endless frustration from the compiler-specific mangling schemes for C++ functions within libraries.

Re:Just get rid of it altogether

[KrispyKringle]

Wow. Too bad I don't have mod points and Slashdot doesn't have a "-1, illucid" option.

I might've missed some of what you said because it's so incoherent and unformatted (yes, syntax does matter), but a few notes:

1) Language is independent of implementation. Many high level languages (Python, Ruby, Perl) are indeed interpreted or bytecode compiled (Python--and, I believe, Ruby--is bytecode compiled, which does introduce a performance gain), but they need not be. Those are simply the dominant implementations (Python has, in fact, multiple implementations, including PyPy, Jython, and Cpython).

Not only could any of those languages be re-implemented as machine-code-compiled languages, but many other languages are both high level and have native code compilation (OCaml and Haskell spring to mind).

2) Allowing people to mix styles or languages breaks type safety. If Haskell allowed inline assembly, it wouldn't be a type safe, purely functional language (some may argue this is a valid compromise; OCaml is not purely functional, but as a result it can't be lazy--you give up features).

3) Many popular languages do have profilers (which you described in great detail as if they do not exist) to determine which parts of the code are particularly compute-intensive, and many allow you to write those parts in more optimized languages. Python, Perl, and Ruby allow you to write modules in C. OCaml lets you write modules in C. Haskell lets you write modules in C, though the process is fairly involved (requiring the use of monads to maintain the above described features). C# allows managed and unmanaged code (though the latter has some serious safety implications). You get the idea.

4) The assumption that lower level languages are faster is, I think, a bit over-played. Nobody has time to optimize their entire program, so we usually want to invest in compilers and infrastructure that do that for us. Many higher level languages optimize very well, but perhaps don't optimize as well as hand-optimized C or asm. Does this mean we should do everything in C or asm? Of course not. It means we hand-optimize the really intensive parts and let the compiler worry about the rest.

It would be a mistake for someone to think that writing his entire program in C will make it faster than writing it in a higher level language, unless he truly has the time (and skill) to optimize it all by hand. For most people, for most applications, it's just better to let the compiler do it.

Re:Just get rid of it altogether

[sillybilly]

I did use preview, it's all my fault, I guess long run on and on paragraphs don't bother me as much as they do others, especially if I'm just blurting out something vague that I don't really have a structured idea of, and it just all runs together anyway. Plus it conserves space on other people's screens.

Re:Make Bjarne leave it alone!

[lordholm]

No features??? Try complex numbers, inline functions (i.e. typesafe macros) and variable declarations which does not have to follow the start of a scope and restricted pointers.

Re:Downhill at a fast rate

[BenjyD]

It's not that hard to see if there's a 'const' in the function prototype, is it?

The GUI.

[nighty5]

I was pleased to notice that Bjarne Stroustrup has acknowledged that they won't be pursuing to include a GUI framework into the new C++ standard.

Although this might be considered a disappointment, his citing the fact of low resources, time and money are best spent in other areas. Lets get something out the door that we can use now instead of waiting for the GUI. I'm no C++ expert, as a matter of fact I'm only into about 400 pages of my first teaching book ;)

Nobody will deny the power of some of the C++ GUI's out there, QT is probably best of breed. Its probably good to have commerical interest in the GUI space, since the desktop is forever evolving faster than a C++ committee could handle.

Re:The GUI.

[ObsessiveMathsFreak]

Nobody will deny the power of some of the C++ GUI's out there, QT is probably best of breed.

Using a procedural, compiled programming languague for GUI's is a fundamentally flawed concept to begin with. If you want to create a user interface, just use HTML, XUL, XAML whatever. 300+ lines of Visual C++ code just to display hello world is indicative of an underlying problem.

Re:The GUI.

[trollable]

300+ lines of Visual C++

If you're right, WTF would you want to use a MS product? You can do a hello world in C++ with just 3 lines (TUI) or 12 (GUI with QT).

Concerning XML-based GUI descriptors, it is in general not smaller. It is smaller to define and place the components but things goes wrong when you have to manage events. In fact, from my experience, a GUI in HTML+JS, C++/QT and Java/Swing has more or less the same number of SLOC.

Re:The GUI.

[ivec]

There are many C++ GUI libraries, but I'm afraid that they all share a common weakness: the lack of reliance on the standard C++ library. Except maybe gtkmm, but how well is this library supported?

All the frameworks I know tend to use their own string class, their own containers, etc -- and obviously as well their own threading library.

Re:The GUI.

[plover]

All the frameworks I know tend to use their own string class, their own containers, etc -- and obviously as well their own threading library.

Because they're all OLD. People have needed to do graphics for longer than the STL has been a standard (1997? 1998?), and certainly for longer than the STL has been widely adopted. We're stuck with a YACF (Yet Another Crappy Framework) at our shop, complete with its own string class and container classes. I've asked the vendor recently "why don't you use the STL?" His answer: "code bloat."

This from a guy whose architecture revolves around every class implementing an IsKindOf(int) method that lets the calling program figure out if it's safe to statically cast to yet another homegrown type.

I think the real answer is a severe case of NIH syndrome: Not Invented Here. So I gotta put up with his unextensible, non-standard crap because his shop is filled with arrogant wunderkinder? I need a new vendor.

Re:The GUI.

[everphilski]

If you are gonna use microsoft products look into Windows Forms... a lot simpler and cleaner. 300 is a slight exaggeration of MFC although not much...

-everphilski-

Re:The GUI.

[everphilski]

He's talking about MFC (Microsoft Foundation Classes), its an exaggeration but not an extreme one. Windows Forms is the .net era replacement and is a lot slicker. Think similar to QT (Except without QT's reliance on its own data types :/).

-everphilski-

Re:The GUI.

[luzr]

The reason is that C++ standard library clearly sucks...

Re:The GUI.

[spongman]

// 10 lines in c#

using System.Windows.Forms;

class F
{
    public static void Main ()
    {
        Button button = new Button ();
        button.Text = "Hello, World!";
        button.Dock = DockStyle.Fill;
        button.DialogResult = DialogResult.OK;

        Form form = new Form ();
        form.Controls.Add (button);
        form.ShowDialog ();
    }
}

Re:The GUI.

[bored]

Borland C++ can do it without any code. Click add new project, drop a label on the form type "Hello world" into the caption property, click run.

Of course there are about 4 lines of code generated when you create the project and a line to create a new Tform but other than that....

Re:The GUI.

[trollable]

Show me the code ;)
The whole code: typed, generated and resources.

Re:The GUI.

[2008]

It's one line in Basic, and in Visual Basic - you even get a GUI dialog box with the VB one liner. MS isn't always so bad.
Well, the box is one of those nonsensical ones that just has an OK button and a cross to quit, maybe they are that bad.

Re:The GUI.

[Minna Kirai]

the power of some of the C++ GUI's out there, QT is probably best of breed

I deny that Qt is actually C++. Code which uses Qt in the intended manner (as opposed to a completely ugly mess) must first be run through a non-C++ precompiler to expand out concepts like signals and slots.

It is rather ironic that Bjarne's homepage cites KDE as a major example of C++, when evidently C++ wasn't good enough for them to write in. (Note that expanding C++ inside the language, like boost does, is not comprable to using an external precompiler)

Re:The GUI.

[trollable]

Same answer than for the Borland C++ code.
Show me the code ;)
The whole code: typed, generated and resources.

(the spec is given by the C# code)

Re:The GUI.

[trollable]

Thanks for your informative post. No lameness here, I really want to compare.
The .BPR file should not be counted. Also, when mentioning generated code, I meant generated source code. So the result is 84 SLOC.

Concerning BCB, I like it (still have a copy at home). In fact, in '97 we had to decide which tech we will use for the next 10 years (mainly to developp GUI and integration of numerical computing programs). We implemented a small project with different techs. BCB and Java won. We finally went for Java because we also use unix boxes.
PS: Turbo C++ and Borland C++ Builder were great but Borland C++ was horrible...

Re:The GUI.

[bored]

Not counting comments white space and other crap (couple of includes etc), here is the code that gets generated. Formatted to avoid the lame filter.

WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{try
{Application->Initialize();
Application->CreateForm(__classid(TForm1), &Form1);
Application->Run();
}catch (Exception &exception)
{Application->ShowException(&exception);
}return 0;
}

Of this the only real line that gets inserted to create the form with the text box is the CreateForm() call. There are a few more comments and a couple lines of #include in the module for the form, the only real part is the empty constructor. I don't count the resource fork as code, since In a few years of using BCB I've never had to edit it so its effectivly transparent.

Re:The GUI.

[trollable]

I don't count the resource fork as code, since In a few years of using BCB I've never had to edit it so its effectivly transparent.

I disagree, you should count it. I'm sure you have edited it regulary, just not with a text editor. So IMHO you should add the number of lines of the textual representation of your resources. Because they require real work to create and maintain.

Re:Downhill at a fast rate

[ObsessiveMathsFreak]

When I found the C language, I stopped looking. Ah well.

Go hack mplayers source code, and then come back saying that. C++ might not be a panaeca, but danm, C code can get very, very, very ugly sometimes.

Re:Downhill at a fast rate

[mustafap]

>> When I found the C language, I stopped looking. Ah well.
> Too bad.

I guess I should have qualified my comment, really. I suppose in part it comes down to what problems one is trying to solve. I'm an embedded designer, working on small systems. Assembly and C turned out to be the right tools for the job. So I guess I should really have qualified my rant with "in my line of work".

The red mist has lifted now!

C++ template concepts vs. C# generics constraints

[dalleboy]

The difficulty in the design of "concept" is to maintain the flexibility of templates so that we don't require template arguments to fit into class hierarchies or require all operations to be accessed through virtual functions (as for Java and C# generics). In "generics", an argument must be of a class derived from an interface (the C++ equivalent to "interface" is "abstract class") specified in the definition of the generic. That means that all generic argument types must fit into a hierarchy. That takes foresight. For example, if you write a generic and I define a class, people can't use my class as an argument to your generic unless I knew about the interface you specified and had derived my class from it. That's rigid.

C++ template concepts are no better (or worse for that matter) than C# generics constraints, they only bind differently: C++ binds to a name, C# binds to an interface. Both are equally rigid. Both require foresight. In C++ you don't have to derive your class from a specific interface, but on the other hand you still need to implement the function knowing what name it will be accessed through (i.e. should it be named begin or Begin or GetBegin).

Threads Cannot be Implemented as a Library

[putko]

It is good for a language to have threads "built in". As mentioned in this paper, "Threads Cannot Be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-20 9.pdf

if you do threads in a library, you run into problems with semantics or performance. Semantic problems == compiler breaks your multithreaded program. Performance problmes == compiler does naive translation of program, terrible performance.

Re:Downhill at a fast rate

[Anonymous Coward]

It can get ugly, if it isn't designed.
But if you spend just a little up-front design time, it is also very easy to create nice clean code.

Refactoring C after a year of development is not that hard.
Refactoring C++ after a year of development can be impossible.
Did you say reuse? Bah.

what's in a name

[Claire-plus-plus]

they should call it ++C, so then the "shouldn't you iterate the language BEFORE you use it" jokes can go away.

Re:Heh

[Kjella]

Translation : C++ will continue to be a highly useful language, as long as some other sucker does all the hard work.

Well, the power of most languages is in the libraries anyway. What is Java or C# without the standard libraries? I program in C++/Qt and rarely if ever touch all that is ugly about C++. The very few places I allocate memory myself for operation with other code I check it rigorously, Qt objects handle themselves. I use QString and QBytearray and never have issues with zero-termination or buffer overflows. Signals and slots will never crash on a dangling pointer. The new Qt4 containers with foreach are brilliant. So yeah, core C++ may be functionally poor but if you need the equivalent of java or C# it's a library away.

Kjella

Re:Adding new features is not always an improvemen

[mwvdlee]

The thing is that one of C++ main design points is that it should be able to do everything a computer can do; it is a system programming language.

That is why it will always include features which will force the programmer to think whilst typing, unlike in Java (my current job) which is a lot easier but won't allow such low level access to the computer.

As for the preprocessor issue you describe; it's type-safety.

Re:C++ template concepts vs. C# generics constrain

[Rakshasa Taisab]

I think you have missed, or underestimated the effects, of having to pre-define the interface rather than just using it. In C++ you just write the template code, in C# you need to have an interface defined. How many do you think get a bit lazy and use a more generic interface that includes constraints not nessesarily used in the specific function call?

Re:run-time compiling?

[xcham]

Sure; let's add in closures, inline FORTRAN support and programmer mind-reading too.

Re:Adding new features is not always an improvemen

[DJStealth]

At the very least, the new name could be Y2K compliant.
C++09 doesn't seem to do that. At this rate, they'll still be making updates in 2109, so maybe they should clear the ambiguity and rename it from C++0x to C++200x

Don't worry - We'll license you case-by-case

[Anonymous Coward]

http://www.mozillaquest.com/Linux03/ScoSource-02_S tory03.html

"C++ is one of the properties that SCO owns today and we frequently are approached by customers who wish to license C++ from us and we do charge for that. Those arrangements are done on a case-by-case basis with each customer and are not disclosed publicly. C++ licensing is currently part of SCO's SCOsource licensing program."

Thanks
Blake Stowell

-o9

[wild_berry]

It's the ninth-circle-of-hell compiler optimisation. It does some form of distributed computation using hell's citizens' bones for data storage and avian carriers for data transfer, and will protect your Windows box from spyware because its binaries are more evil.

Re:Downhill at a fast rate

[Bloater]

> And reference variables?

There is no such thing as a reference variable, you clearly don't know the C++ language. references are not variables. references are newly defined identifiers that refer to an object that already has identifiers referencing it, they don't change, ever, hence are not variable... But I see that you *really* meant *pass* by reference, if you want to ensure that the function can have no side effects, cast the parameter to const. Otherwise, if you expect to write software without knowing what the functions do, you should not be writing software.

BTW, when you say "fancy allowing standard operators to be overloaded" I think you mean "overrided". C has overloaded operators (+ is defined for int, char, short, long, float, double, etc). overriding lets you tell the compiler how to do addition for your custom bigint library, or whatever. You can misuse operator overriding, or you can misuse macros, each are there for a purpose, and each get misused by bad programmers.

> And now garbage collection? That just a feature to fix poorly written code.

No it isn't, it is a feature to simplify the determination of object lifetime when that lifetime depends on complex (or more likely, merely chaotic) runtime factors. Bad programmers use it to fix poorly written code. Sure, every lifetime can (maybe) be determined by some complicated equation, but when you have limits on how much CPU you can use and limits on how much time you can spend on maths, you use garbage collection.

The trick is only to use garbage collection when you know that you need it and what it means. There's the problem with most dynamic languages.

Re:Downhill at a fast rate

[dghcasp]

You young'uns have it so easy. When I was a youngun, this is how we booted the operating system:

cat > /vmunix

Re:Adding new features is not always an improvemen

[hackstraw]

I also have come to realize that if there is one bad thing in C++ than it is this preprocessing which it inherited from C. Especially in a large project the trouble of including the right files and linking against the matching libraries becomes a pain in the ass.

Even though headers and libraries are the most common problem I come across from day to day, it wasn't until now that I thought about it as an implementation problem.

I'm not sure about the preprocessing bit. ifdefs and includes to get prototypes and other global/module specific variables are very handy. Its just a little silly that there is not a common preprocess and link flag that you can tell your compiler to find includes and libraries. How about gcc -F /usr/local/strange_module-2.3.7 and that would pass -I /usr/local/strange_module-2.3.7/include to the preprocessor and -L /usr/local/strange_module-2.3.7/lib to the linker.

How tough would that be? You can always explicitly add linker or preprocessor flags if you need to, but I would find this method superior to the current one by far. One of the biggest issues with preprocessing and linking is the order of the search path. Having it as one flag to pass to both of preprocessor and linker would simplify things.

Telling Comment

[Anonymous Coward]

C++ is a tremendously type safe language, to the point where every time I work with it I feel like about 90% of the work I do is in accounting for type. Most of that work is thrown away after the code has been compiled, too, but it does make for a rock solid program if you do it right.

(emphasis ed.)

And if you don't "do it right"?

Re:Telling Comment

[masklinn]

You shoot yourself in the foot and blow the whole leg up to the hip (but including your groin) in the process.

C++x0r

[CharAznable]

I think he means to call it C++x0r. Cause the type safety makes you ub4r.

Why wait to 2009?

[shenanigans]

I personally have more hope in this alternative.

To me, D has surfaced to become what I always thought C++ should have been. I hope (and believe) that it will be giving C++ more competition in the comming years. It might not be ready for full production yet (due to lack of big supporters and libraries, mostly), but I have tried it out on several of my own projects, and I love it.

Re:Why wait to 2009?

[Glock27]

To me, D has surfaced to become what I always thought C++ should have been.

From what I've seen and heard of it (I've not yet used it) I'd tend to agree. I can't understand why so many programmers stick with C++. It's just not a very good language. I'll never understand why it's not possible to even enable bounds checking in STL arrays...

For those willing to look at something a little less C-like, Dylan is quite nice also. There are two high-quality OSS compilers.

I think we're soon going to see a resurgence in "traditional" compiler technology. No sense throwing away cycles for no particular reason.

Re:Why wait to 2009?

[deadlinegrunt]

"I'll never understand why it's not possible to even enable bounds checking in STL arrays..."

If you read "The C++ Programming Language" you will find out exactly why this isn't enabled in the default libraries. Also how to provide a trivial wrapper with just a few lines using at() and why it is left to you to do so instead of specified by the standard and implimentation details. Granted you said it's not "even possible to even enable..." when in fact this is not true. There are implimentations of C++ that actually do enable such switches during compilation.

Re:Why wait to 2009?

[Crayon Kid]

I can't understand why so many programmers stick with C++. It's just not a very good language.

That may be true (subject to debate). But the main reason is that it's everywhere. It spread and support is simply unmatchable. Even a huge corporation like Microsoft, trying to push an alternative (.Net) has a tough time making a dent in C++. Whatever shortcomings C++ may have, it's already here, everywhere, and it's not that bad as to provoke mass migration.

Re:Why wait to 2009?

[Anonymous Brave Guy]

I can't understand why so many programmers stick with C++. It's just not a very good language.

That depends on your benchmark. Mine is pragmatism, where it remains unrivalled for many jobs.

And while C++ has many theoretical design flaws that could be improved in a language without the historical baggage, lack of bounds checking on a vector isn't one of them. Just use at() instead of [] if your implementation doesn't do bounds checking already.

Re:Why wait to 2009?

[jimktrains]

I've only used it a little, but ObjC? A valid C prog will compile on a ObjC compiler and Obj supports classes....

Re:Why wait to 2009?

[Old Wolf]

I'll never understand why it's not possible to even enable bounds checking in STL arrays...

It is possible. STL vectors (I suppose that is what you mean) have two forms of syntax for member access: one with bounds-checking, and one without.

The C++ standard doesn't define what happens if you use the non-bounds-checking syntax and do an out of bounds access. It is then up to the individual compiler to decide what to do. For example, the Borland compiler suite (the non-free version) can catch out-of-bounds memory access and cause the debugger to stop and tell you what happened, etc.

Re:Why wait to 2009?

[Glock27]

And while C++ has many theoretical design flaws that could be improved in a language without the historical baggage, lack of bounds checking on a vector isn't one of them. Just use at() instead of [] if your implementation doesn't do bounds checking already.

I was quite aware that you can use a *different syntax* to accomplish bounds checking. What I'd like (and what most languages that support arrays offer some form of) is the ability to use a #define or a #pragma and *turn on* bounds checking for the regular [] accesses.

gcj does it the other way around - bounds checking on by default, turned of with -fno-bounds-check.

Re:Why wait to 2009?

[Glock27]

It is possible. STL vectors (I suppose that is what you mean) have two forms of syntax for member access: one with bounds-checking, and one without.

That is called "using a different syntax" not "enabling bounds checking". Unbelievably silly.

what is he taking OUT?

[Russ Nelson]

It's much more interesting to me to hear about what Barne will be taking OUT of C++. Adding features is the easy, wimpy part of the job. Removing them is the part that takes cohones.
-russ

Re:what is he taking OUT?

[cnettel]

And this will be very little. He actually discusses this for a bit in TFA. On the other hand, compiler vendors can naturally choose to allow warning levels that clearly discourage use of obsolete or dangerous language constructs, whatever those may be. That way, your old code compiles cleanly with the right settings, but in writing new code, you can get the helping hand to stay away from the dark side.

Re:what is he taking OUT?

[Anonymous Brave Guy]

If this is anything like what Microsoft just did with Visual C++ 2005, where using perfectly good standard library functions results in a wave of warning messages that they are deprecated (by Microsoft, not the standard, mind) and you should use the "safe" versions instead (which only work on the MS compiler, of course) then thanks, but I'll take backward compatibility for 100.

I know you can, if you read enough, identify the appropriate #define voodoo to set in all your projects and shut this lot up, but having just done it on even a single, moderately-sized project, it's just wasted effort I shouldn't have had to expend.

Re:Naming...

[ClintBartonWannabe]

++ is the increment operator, C++ is C that has been incremented with new OO features (be that for better or worse is a personal opinion in the same league as religion)

Re:Downhill at a fast rate

[amightywind]

I still think C++ was invented as a joke. I mean, fancy allowing standard operators to be overloaded.

C++ was well intentioned, but yes, it has turned into a bit of a joke. Operator overloading is indeed a carnival of confusion that would have been best avoided. As a Lisp programmer I chuckle at the artificial distinction between operators, functions and methods.

And reference variables? I now have to carefully examine very function prototype when I need to know if a function call might have side effects.

I don't find these to be egregious. C's pass by value is a bit idiomatic, although it is simple and works well. Use const properly to avoid side effects.

And now garbage collection? That just a feature to fix poorly written code.

Agreed. I would rather see threads in the standard library instead of GC. GC promotes sloppy programming. It appeals to legions of Java and C# programmers, the bottom feeders of the programming world.

When I found the C language, I stopped looking. Ah well.

C will always be useful because assembler will always be with us. So yes, everyone should program in C. But for even more karmic hacking I prefer Lisp.

Is the C++ standards committee serious?

[master_p]

Why do they want so many years to decide on so simple things that are other languages take for granted for more than 15 years now? Let's see what they have in store:

1. the using declaration for making type aliases. First of all, template typedefs are there for the exact same reason. Secondly, C++ lacks the ability of making strong types out of other ones, templates or not; a feature present in Ada 83, for example. We programmers need the ability to define strong types out of anything, primitive, template or not.
2. sequence constructors; what an utterly hopeless idea! it will introduce more problems than anyone ever thought. The correct thing would be to make the expression {2.3, 1.2, 6.7, 4.5}, and any expression contained in curly brackets, a composite literal! Just like an integer can be written as {0, 1, 0, 1 ... 1, 0, 0, 0, 1}, i.e. a sequence of bits, so should any other data structure. Array syntax would be more than enough for accessing the individual elements of a composite literal. For example: auto x = {1, 2, 3}; auto sum = x[0] + x[1] + x[2];
3. template concepts; correct solution, but why they say it is difficult to implement? The problem with templates was that the type system was applied after template substitution. In fact, templates were little more than C macros. Languages that implement generics correctly (Haskell, Ml, Erlang, Ada, etc) have sold these problems many moons ago. Applying a type in compile time is nothing more than executing the program at compile time. Currently C++ templates are turing complete, so I just do not see 'big problems' with concepts.
4. type deduction using the auto keyword. C++ already does type deduction, so where is the problem? And why should we wait 4 years for compilers to adopt those things?
5. .

But what makes the most negative impression is the willingness to recognize that the programming language world has made huge steps in the last few years, and C++ is light years behind. Here are some of the negative points, in random order:

• No garbage collection. Come on C++ guys! how many times have we got to beg for C++ having garbage collection? it's the easiest thing to do, and you can put it there as an option! no, the Boehm gc does not cut it, because it does not take advantage of type information, so it is much slower and much more complicated than what it needs to be. C++ designers, please stop telling us how garbage collection will mess up C++, because it will not! Microsoft already has managed C++, and then there is the programming language D which offers garbage collection! Of course gc goes hand-in-hand with strong and weak pointers.
• the bias towards systems programming . Come on guys! in the world that Java is used for handheld devices, no one really cares about C++ being used in a few embedded controllers anyway. No one has used C++ for any major operating system, and no one has used C++ for any hardcore military project. Where is C++ used as for system programming? nowhere. C++ is mainly used in application programming, because of compatibility with C without an FFI.
• the lack of import declarations. In the year 2006, we still have to duplicate code between header and source files, we still have to take care of includes, we still have to make decisions if we should place code in header files or in implementation files in order to make code inlined or not.
• no static virtual methods. It is dead easy to do, and sometimes it is badly needed. For example, the pattern factory heavily depends on it.
• no properties. For example, GUI libraries have 100s of widgets, yet we still have to write getFoo(), setFoo(), isFoo() etc. By using properties, code would be greatly simplified, and there would be no run-time overhead since properties is about syntactic sugar.
• no variable argument li

Re:Is the C++ standards committee serious?

[frantzdb]

type deduction using the auto keyword. C++ already does type deduction, so where is the problem? And why should we wait 4 years for compilers to adopt those things?

C++ only does type deduction for function calls. This would allow one to write auto foo = bar(A, B) and have it compile even if bar(A, B) returns some essoteric templated type based on the types of A and B.

I think it is Blitz++, a linear algebra library, that does templated magic to eliminate the need for large temporary arrays when doing summation by having operator+(const matrix&, const matrix&) return essentially a continuation. That is, it returns something of type Evaluator<sum, matrix, matrix> . Then A+B+C evaluates to a Evaluator<sum, Evaluator<sum, matrix, matrix>, matrix> , and then matrix has a copy constructor that accepts Evaluator<Op, T, T> things so you can do matrix D = A + B + C; and not have a temporary matrix allocated.

The auto keyword would allow you to save intermediate results.

no variable argument lists in templates.

This may be because variable-length argument lists aren't type-safe. See the Boost format library for an example of a type-safe version of printf.

I agree with you on most of the rest of those.

Re:Is the C++ standards committee serious?

[DoofusOfDeath]

... and no one has used C++ for any hardcore military project.

I'm surprised that you feel qualified to make this statement, since it would require you to have the rare combination of having top secret clearange (in order to know about all military projects) and have a "need to know" about each one of them and be in the habit of posting what you know to Slashdot.

But you're simply incorrect in your statement.

Re:Is the C++ standards committee serious?

[tchernobog]

If these are your points, then use another language, like Java.
I don't want C++ to look like Java.
I want C++ to solve a different kind of problems in an easy way.

Frankly _none_ of your points would be something that I'd like to see added to the language; it would be likely to introduce complexity and confuse users even more, instead of helping them; and maybe it would also break compatibility with old C++ programs. It seems that the ISO committee agrees with this idea.

Some of your points debated:

• Garbage collection: making this the default would be utterly insane. GC has to run on another thread, thus making a program unpredictable.
• the lack of import declarations: thanks God we don't have them! Keeping headers and implementation in two different files is a wonderful idea; and I can ship to the user directly my clean and documented header files. No Java-style cluttered and bloated source files. Btw, Java is different because it's compiled in bytecode. C++ isn't, so implementing an import semantic would break C++ ABI (yet) another time.
• no standard GUI library: different systems get this done in different way. What would be the point of laying out a framework in the C++ standard when nobody would use this because they already do it their own way? We're talking about graphical toolkits with millions of users and bindings in a lot of different languages. Changing the way they do things without breaking binary compatibility for library users is just impossible.
• No closures: I don't know if I understood your example correctly, but with Gtkmm + sigc++ I do what you said without particular problems.
• No initialization of an object's fields at the point of their declaration: yes, this is left as a boulder for the programmer. No harm in that, you're just speaking about syntactic sugar.
• properties: mark a member public if you want to spare some typing. Else use an IDE that generates accessors for you. All in all, it's just laziness...
• No true message passing: use a library that provides them. As simple as that.

So please: change programming language and don't complain non-sensically trying to look cool because you can speak a little jargon.

Re:Is the C++ standards committee serious?

[pradeepta]

No run-time substitution of a vtable's method pointers : why?? How is that in anyway more efficient, needed. You still need to write boilerplate code to make the decision to actually change the vtable method pointers change to something else. You could always move that decision to compile time (use templates)

Re:Is the C++ standards committee serious?

[sethg]

One of the main design goals of C++, from the very beginning, is that "you don't pay for what you don't use"--in other words, if you write a C++ program that doesn't use the language's OO or generic-programming features, it should be just as fast as the equivalent C program. I'm not sure how you could extend C++ to include all of your desired features (particularly GC) without throwing out that goal.

(I think "you don't pay for what you don't use" is a fundamental design flaw of the language, but if you dismiss it, you're no longer arguing about how to extend C++; you're arguing about what language to replace C++ with.)

Re:Is the C++ standards committee serious?

[neutralstone]

I think you're being a bit unfair.  You must understand a few things:

First,  the work of the ISO C++ committee is (and always has been) a volunteer effort.   Everyone on the committee has a day job that has practically nothing to do with committee work.  (The organizations they represent may pay some or all of the expenses associated with committee membership, but the "real work" rests purely on the shoulders of each individual member.  It's truly a labor of love.)  On top of that, most of them have a family life.

Second, C++ was a fairly mature language even before they finished drafting for the first Standard back in 1997 -- and adding features to *any* mature system always takes a lot more work than designing features for a new system.

Third, it's a committee.  Each individual has in mind a set of features that they would like to see added to either the core language or the library, and whatever they propose must meet with the consensus of the majority, or *the*proposal*doesn't*move*forward*.  A lot of the features you're asking for have been proposed in one form or another, and a good number of them will simply be left out of C++0x because a number of reasonable people made sound objections on technical grounds.  This doesn't mean they object to the general notion of, say, strong typing.   It's just that they objected to the specific way in which it was proposed.

Fourth, their time is limited.  Each ISO meeting lasts for only five (5) days, and there are only two meetings per year.  They do get a lot done on mailing lists, but nothing beats face-to-face communication for rapid development, and they don't get very much of that.

Fifth, they have to be *really*careful* when they consider the addition of a major new feature.  They really got burned by the likes of 'export' -- i.e., features that sounded good to a lot of people but ended up adding a **HUGE** amount of complexity for practically no real benefit.  They clearly understand that a lot of the features you're asking for would be nice to have, but specifying the details of that feature to fit into Standard C++ in a non-disruptive and straightforward way -- and *proving* that it will be non-disruptive and straightforward to implement -- is a difficult thing to do correctly.

To sum up:  they're over-worked, under-supplied, forced to be highly cautious, pressed for time, and under-paid (in fact, they're *not* paid -- at least, not paid for committee work).  And somehow they're giving us a language that's fairly portable and is a superior tool for a broad range of applications.  So cut them some slack.  Better yet, join the committee and help out if you can. 

Re:Is the C++ standards committee serious?

[ari_j]

I think that the gpp's points are all (save for one or two) valid, given that this /. story is about adding all sorts of wacky and unnecessary features to C++ that make it look like a different language, anyhow.

Some of your contention is that syntactic sugar is inherently bad. This is not the case. For instance, being able to initialize a member where it is declared makes it easier to avoid bugs and easier to maintain code. It is not inherently bad just because you can do it somewhere else already. This seems to be part of the underlying philosophy of C++0x, anyhow: the parts of C++ syntax that make it difficult to write clean, bug-free, maintainable code should be covered up with better syntax.

The same thing applies to the mutable vtables, closures (although I think that anonymous functions that are not closures would fit better into C++), and message passing - all of these common problems' solutions would be cleaner, more maintainable, and less bug-prone if they were part of the language and not a buggy, ad hoc implementation written every time the problems are encountered. (But see Greenspun's Tenth Rule of Programming.)

Re:Is the C++ standards committee serious?

[master_p]

C++ only does type deduction for function calls.

I know (isn't it obvious?). What I mean is that "what is the problem with 'auto' so as that we don't have it yet".

This may be because variable-length argument lists aren't type-safe.

No, I am talking about compile-time va-lists. If you have ever tried to program a generalized callback framework, then you may understand what I mean.

Re:Is the C++ standards committee serious?

[swillden]

I agree with many of your points, have no opinion on some and disagree with others, so I'll only call out the ones I disagree with.

sequence constructors; what an utterly hopeless idea! [...] The correct thing would be to make the expression {2.3, 1.2, 6.7, 4.5}, and any expression contained in curly brackets, a composite literal!

Can you expand on how you would write the constructor for, say, a list class that can take a composite literal as a parameter? I suspect that what you might write is very similar to what Stroustrup is thinking about. I do like the idea of generalizing the composite literal to be useful in many contexts, though. Why don't you write up a detailed description and send it to Stroustrup? Clean, easy-to-explain-and-implement suggestions are exactly what he's looking for right now.

type deduction using the auto keyword. C++ already does type deduction, so where is the problem? And why should we wait 4 years for compilers to adopt those things?

I don't see a problem. Seems a simple idea, easy to implement. It's a good thing to add to the language standard. As for how long it will take compilers to add the features... that's a question for compiler writers. Lots of C compilers haven't fully adopted C99 yet.

No garbage collection. Come on C++ guys! how many times have we got to beg for C++ having garbage collection?

RTFA. Stroustrup wants to add optional GC. I'm going to be very interested to see how they choose to address destructor invocation. The two obvious choices are (1) don't call destructors on collected objects and (2) have the GC call the destructors when it collects objects and both problematic. (1) will break lots of classes and (2) will break some classes and will hugely complicate the GC, which will have to determine in what order it can call the destructors and may have to re-evaluate the set of collectible objects after each destructor invocation.

and then there is the programming language D which offers garbage collection!

How does D handle destructors?

the lack of import declarations. In the year 2006, we still have to duplicate code between header and source files, we still have to take care of includes, we still have to make decisions if we should place code in header files or in implementation files in order to make code inlined or not.

I don't duplicate code between header and source files. I actually like the separation of declaration and implementation rather than the Java style of combining them, and I prefer to specify what should be included. As for why inlined methods can't be defined in implementation files, I think that would be a good idea. It would require changing the linker, which was something Stroustrup originally wanted to avoid, but I don't see any problem with it these days, particularly since linkers already include C++-specific features.

no static virtual methods. It is dead easy to do, and sometimes it is badly needed. For example, the pattern factory heavily depends on it.

There are enough different ways to interpret 'static virtual' that I'm not sure which one you mean. Can you clarify?

no standard GUI library. It requires lots of work, but basic GUI functionality should be there. Nothing spectacular, just the basic stuff (windows, menus, buttons, toolbars, etc) so we can easily write the most basic GUI applications.

The problem with this is that it's a huge job to create a complete cross-platform GUI framework and there's no point in creating a simplistic one that no one will use. The most reasonable thing the committee could do here would be to pick an existing cross-platform GUI framework and call that the standard. But which one? Deciding would be a big political battle and it's not clear that the end result would really benefit users of the language, since it wouldn't make any new functionality available, and it's unlikely

Re:Is the C++ standards committee serious?

[Surt]

Just a note: interface == .h for java. Document all you want, and ship to your customer, along with a crypted jar with the actual binary.

Re:Is the C++ standards committee serious?

[master_p]

If these are your points, then use another language, like Java.

But I never said that C++ should look like Java. All that I want can easily fit in the C++ style, and they can be optional.

Garbage collection: making this the default would be utterly insane. GC has to run on another thread, thus making a program unpredictable

Nope, not at all. First of all, GC does not need to run in a separate thread. I have programmed several GCs, some of them naive, some of them hardcore, and sent them to Stroustrup. None of them required a separate thread. Secondly, you shouldn't talk about predictability and C++ in the same sentence, since C/C++ pointers can easily make a program unpredictable. And if you want "predictability", as you mean it, then be aware that GC can be optional.

the lack of import declarations: thanks God we don't have them! Keeping headers and implementation in two different files is a wonderful idea

It makes code management difficult. I have to type the same things twice. I have to decide if a piece of code goes in the header or implementation file.

I can ship to the user directly my clean and documented header files. No Java-style cluttered and bloated source files. Btw, Java is different because it's compiled in bytecode.

First of all, you do not need to ship source files. Take a look at programming language D, in which the compiler produces symbol files to be directly imported to programs. Secondly, it is totally irrelevant that a language is in bytecode or not. There are bytecode compilers for C, for example.

C++ isn't, so implementing an import semantic would break C++ ABI (yet) another time.

Importing a file it is just another way of accessing declarations between programs. The difference is that imports are already pre-compiled in compiler format, and therefore faster to compile. As for compatibility between compilers, just define a standard (like D does).

What would be the point of laying out a framework in the C++ standard when nobody would use this because they already do it their own way? We're talking about graphical toolkits with millions of users and bindings in a lot of different languages.

But new projects will not use the existing graphical toolkits, but the standard one.

Changing the way they do things without breaking binary compatibility for library users is just impossible.

Nobody said "stop using the other libraries". But the other libraries are a pain in the a$$ to use. Qt requires MOC, GTK sucks, wxWidgets sucks more, Motif sucks even more. Swing is nice though.

No closures: I don't know if I understood your example correctly, but with Gtkmm + sigc++ I do what you said without particular problems.

Nope, you did not. What you are referring to is a callback framework. I am talking about closures. See Smalltalk's blocks, or lambda functions of Haskell/Perl for examples.

No initialization of an object's fields at the point of their declaration: yes, this is left as a boulder for the programmer. No harm in that, you're just speaking about syntactic sugar

properties: mark a member public if you want to spare some typing. Else use an IDE that generates accessors for you. All in all, it's just laziness...

Yes, syntactic sugar, but a very important one: it will save much reduntant work.

No true message passing: use a library that provides them. As simple as that.

Obviously, you have no idea.

Re:Is the C++ standards committee serious?

[master_p]

No, the principle "don't pay for what you don't use" is the reason that I want all these features in C++. You say that you don't know how these features can be implemented. Well, some of them are partially implemented in C++, and some of them are implemented in other compiled languages similar to C++.

Re:Is the C++ standards committee serious?

[Zathrus]

Why do they want so many years to decide on so simple things

Because they have to.

It's an ISO standard language -- by ISO standards, you cannot put out a new standard more than once a decade. The last standard was C++98 (which brought about the STL, amongst other things), so the absolute earliest they could create a new standard is 2008. Go look at the history of FORTRAN ISO standards, or even C ISO standards, to see a long list of once-a-decade revisions.

The reasons for this are quite sane -- it takes time for the new standard to be understood, implemented, and put into wide use. It took nearly 5 years for most of the major C++ compilers to properly implement C++98 (MS being the longest hold out). Most C compilers are still working on C99 compliance. It also takes time for it to become clear what language in the standard needs clarification, which parts are difficult (or outright stupid), and what needs to be fixed.

the using declaration for making type aliases. First of all, template typedefs are there for the exact same reason

And they're poorly implemented in most compilers, 7 years after the standard was ratified, because they're a fucking nightmare to deal with for the compiler and linker. Having a separate keyword makes it easier for the lexical analyzer to figure out exactly WTF you're doing.

No garbage collection.

It's a major issue when you're talking about embedded programming -- the overhead of GC may mean you cannot use a particular microcontroller for your design, either due to lack of CPU or memory. The embedded camp has a lot of strength in design decisions when it comes to C and C++. People who don't ever even think about embedded programming forget (or don't know) this and wonder why certain decisions are made.

That said, the new smart pointers (auto_ptr is such a worthless piece of crap) go a long, long ways toward solving this issue. If you use them. In some code I've written recently we couldn't use the boost::smart_ptr class because the performance overhead was too steep (this was in code that was desperate for every improvement I could throw at it).

no static virtual methods. It is dead easy to do, and sometimes it is badly needed. For example, the pattern factory heavily depends on it.

And Factory can be written in C++ without any issues. I've done it several times. I fail to see your point.

no one really cares about C++ being used in a few embedded controllers anyway

Except for the bazillions of embedded controllers that run C++ code. There's a reason they have a strong voice on the standards committee -- because it is used heavily and there is no real alternative available. Yes, embedded microcontrollers are becoming bigger and beefier everyday, but there's always a group that's pushing them to the limits, and C++ is the only vaguely modern language that lets them do what they need with little overhead.

A lot of your other points are good questions. I suspect that they're answered in the working group's mailing list, but I'm not up to dealing with the volume (or the technical details) produced by that list.

Re:Is the C++ standards committee serious?

[dcw3]

But you're simply incorrect in your statement.

Agreed. Working for one of the major defense contractors, I can tell you that we've been using C++ for many systems.

Re:Is the C++ standards committee serious?

[sco08y]

I'm surprised that you feel qualified to make this statement, since it would require you to have the rare combination of having top secret clearange (in order to know about all military projects) and have a "need to know" about each one of them and be in the habit of posting what you know to Slashdot.

I disagree since if you knew of a reasonable sample of declassified or public military projects and none of them used language X, there's no reason to assume that secret or top secret projects are going to be more inclined to use language X so it would be a reasonable statement.

That said, I doubt the grandparent had a reasonable sample.

Re:Is the C++ standards committee serious?

[Jimmy_B]

Sequence constructors: Your suggestion doesn't work, for reasons which should be obvious. First of all, numbers in curly braces are ambiguous; they could be either an array initializer or an initializer for any struct with that many members. And second, arrays don't carry around their size.

Template concepts: Templates were the one thing most of the compilers got horribly wrong the first time around. What makes you think this time will be better? Hence the need for caution.

The auto keyword: Yeah, it's overdue. But it's a nice thing to have.

Garbage collection: Are you joking? It's anything *but* "the easiest thing to do". It's easy for Java, Perl and the like because they run their programs inside of interpreters; they don't have to handle the case where there not only is no interpreter, the hardware can't even support one (no threads, no memory management unit, no operating system support; all of these are problems for embedded programmers, all of them make garbage collection impossible, and all of them can be gracefully handled by C++.)

Bias towards systems programming: And just what *else* are systems programmers supposed to code with? Just because Linux is written in C doesn't mean that C++ can abandon systems programmers. If C++ were to make a change that made it unsuitable for systems programming, the computer world *would* come crashing down. Or the new version wouldn't be adopted by anyone.

Properties: It's not just syntactic sugar, it's a trap which hinders binary compatibility.

Continuations: Unsuitable for systems programming, because they not only require garbage collection, they require garbage collection *performed on stack frames*. Try maintaining binary compatibility with a feature like that!

Closures: Your example is no good, because window.close() should already be defined as a library function.

Runtime substitution of vtable method pointers: Sounds like an ugly hack which, if given language support, would encourage many people to write extremely bad code.

Re:Is the C++ standards committee serious?

[Arandir]

Some of your points debated:

Don't bother debating the trolls. They're only bitching about C++ because they have a deep psychological flaw that requires justifying their own language choice. It's like Mac users who bitch about Windows, or GNOME users who bitch about KDE. They're just doing it because they're confident in their own dick size.

No true message passing

Actually, I would like that one. Using a library to do it is suboptimal. Some user weird ass macros that are hard to understand (MFC, wxWidgets), some use code bloating templates (boost), and others create subclasses and pass around strings (Qt). Native message passing has would remove much of the messaging overhead and facilitate cross-toolkit components.

Re:Is the C++ standards committee serious?

[tchernobog]

What would be the point of laying out a framework in the C++ standard when nobody would use this because they already do it their own way? We're talking about graphical toolkits with millions of users and bindings in a lot of different languages.

But new projects will not use the existing graphical toolkits, but the standard one.

This is utopia, and unlikely to happen. Moreover, if a feature is missing from whatever toolkit, it[the toolkit] can be adjusted and extended with some effort. But if you get it wrong in an ISO standard... what have you to expect? Year 2018?

Re:Is the C++ standards committee serious?

[Hard_Code]

Well, a lot of the improvements seem like simple, natural, extensions whose time has come (and passed)...but as far as "concepts" are concerned..WTF? So not only is there a type system, and a meta-type system (generics) but now we have an additional layer on top of that which is "concepts"? The only clue as to the utility of concepts is the passing mention that it would be "rigid" to impose an interface on code that wants to call a certain generic function/method. Um, HELLO - isn't this the exact philosophy behind the entire OOP type system to begin with?? I mean, exactly how hard a burden is this, given that c++ *already* supports multiple inheritence. It would seem trivial to simply define a "Container" abstract base class (interface) which all STL containers implement, instead of adding this bizarre and arcane new syntax which will be confusing to everybody except maybe a few black magic template developers who will have wet dreams over it. I mean, all type information is already determined STATICALLY by the compiler, so it's not as if you are adding any new convenience for users, because their class will still have to compile statically against the headers of the library that are going to require that their class have a certain "concept". Ugh.

All that, and we still don't have a standard file system of socket API. Come On. For a language whose designers continually go on and on about Real World Applicability (tm) can we for the love of god have a standard library for file system and socket APIs that have been around for 30 years!?

Rant off. Other than that, the updates seem good, and I really hope some progress is made in standardizing libraries. Until then C++ is a language without a platform, a gigantic gilded frigate that has to float in a little puddle due to scarcity of standard libraries.

Re:Is the C++ standards committee serious?

[Pr0xY]

I agree with your comments for the most part, but I have a couple of points that I can't help but at least play devil's advocate with.

"type deduction using the auto keyword.", I think that while this is a trivial feature to implement, it is being added for two simple purposes. firstly to shorten code: "std::vector::iterator" is quite a bit longer than "auto", sure we can typedef, but why should be have to. secondly to reduce need for modifying code when a container is changed. If i change from a vector to say a deque, they both support random access iterators, but until auto is supported, I'll have to at least update my typedefs, if not many lines of code which use iterators to access the container.

"No garbage collection.", ok, a garbage collection system is a reasonable request, at least it would be nice to have a compiler switch to enable it. But there is a problem, c++ opnly requires you to refer to objects using pointers, that is simply it's address. So how is the c++ language suppose to know at runtime that a pointer was just set to 0 and thus should have what it did point to freed? Or more annoyingly, we've got all sorts of pointers which point to all over the place, now we need reference counting and all sorts of voodoo. Also there is another problem, in c++ pointers dont have to point to a valid object, in java and other garbage collected languages, they don't usually use true pointers, but instead references to objects and such. :( Ok, well there are a few solutions. #1 that comes to mind is do what java/c# do and have a VM, and/or forbid pointing to non-objects, or at least make it difficult (enter managed c++), this way at compile time assignment to pointers/references can be adjusted to also send a message to the GC thread to update it's refernce count on objects and such. But this can potentially kill performance and/or sacrifice the "systems programming" elements of c++. No Bueno. Another solution is use smart pointers, kinda the similar to the idea of only pointing to objects and such and emitting code to update gc data, but leaves it in the hands of the developer AND has the benefit of not needing a language level change, but instead is implemented in the library. The third thing I can think of off hand is a compromise like managed c++ where ordinary pointer use is forbidden except in blocked with a "#pragma unmanaged" or something, outside of such blocks, things like T *p = reinterpret_cast(0x12345678); would be illegal (hey why not make pretty much most casts illegal in a "managed" context?

"no static virtual methods", OMG wanted these for a long time, good point

"the bias towards systems programming", I would beg to differ that it is being used nowhere for systems programming. There are several c++ development libraries for the windows kernel available along with MANY project OSes which intend to use modern language features to implement things in a new way, sure they will likely go unnoticed, but they still exist and we shouldn't take away from what they can do already.

"no standard GUI library." Tough call on this one, while it would be nice, this would destroy a lot of diversity in this field, I mean which API do we settle on? .NET, QT, FOX? And if one, why? If we make a new one, are we shut out from using these others? Why? If we are not shut out, why have it? Personally I think that it would have been nice a while ago when GUIs were still up and coming, but at this point it is too late, there are too many options with too many different benefits to each to pick one. Also, should my command line c++ app need X libraries to run? this leads me to think it would have to be a compile time option. Regardless, I don't feel a single API for GUI is workable with the diverse set of features on todays desktops (should the GUI have a notion of a "window", what if my new special OS doesn't use "windows" to represent programs but instead using a whole new paradim?

"no way to get the size of an array allocated with operator new []

Re:Is the C++ standards committee serious?

[taradfong]

The workaround is good enough that he didn't want to go through the pain to do this feature
....

Most of the people here making shoot-from-the-hip comments about how C++ is stupid and should be better, those people should get the book and read it.

Right. See, you'd see that C++ is great if only you would invest *more* of your time to see how there are all kinds of tricks to work around the things that don't work the way a normal person would expect them to.

This workaround is a perfect example. Yes, here is an answer that 'gets you there' and it's cute. But once again you must learn another non-intuitive trick to do something that is an intuitive piece of cake in other languages. I do not want to make all kinds of extra accessors. Nor can I expect to find anyone else who does it.

I'm too busy being productive in other languages to learn all these arcane hacks.

Re:Is the C++ standards committee serious?

[angel'o'sphere]

But you're simply incorrect in your statement.

Well, he is not that incorrect.

The question is what you consider a millitary project. Even the accounting o f a air base, run on its own system, written in MS VC++ and based on acees might eb a military project. and those are numberous.

However its well kown that most military projects, aka weapon system, telecomunications (oops, likely an exception) and reconesense are written ... no not in C++ but in Ada.

And modern sysems, started over the last 5 years are not written in Ada (as its to complicated ... erm not in my opinon) but in Java ... just read some magazines and you would know, or simply watch the recruiting announcements in newspapers/magazines. Such stuff is not secret at all.

P.S. C++ is a dying language. I know a lot of people on par with Andrew Koenigs or Jim Coplien, and even Bjarne himself. We, me inculded, don't use C++ anymore since 5 or more years. Productivity in Java is so much higher .... the simple pitfalls you drop into when you forget one single thing in C++ ... which is well defined in the standard but requires a Phd to comprehend (and remember when it matters). Today we often meet and laugh about failed C++ projects (especially when we applied for a job years ago there but got rejected because of our payment wishes) where programmers repeat all the majour well known mistakes.

Simple example: people could not cope with, which header to inculde? So they cut/pasted all headers into one. No ... they did not even make a "monster header" that included all, they made ONE BIG HEADER FILE thats included by every C++ file.

Build time: 3 hours for a mediocre system. They have mutlithreading and resource allocation problems all over. The system is slow like hell because its cluttered with if (thatReference != null) ... statements, because they never know if a variable might be null or can't be null or what ever.

Exception handling? Sure, constructors and destructors thow exceptions. Both cases are problmatic .... in C++ not in Java.

Yes: they are primarily bad programmers and bad architects .... but C++ is simply to hard to excercise your skills on if you have to get a job done. And: 90'% of the time, you have a misterioous bug, and no one has a clue: might it be a bad C++ idiom (an anti idiom, e.g like throwing an exception from a destructor)? May it simply be a bug? May it be a COMPILER BUG?

I estimate I found about 70 bugs in Borland/Microsoft/Zortech compilers. All lead to the crash of the program. One compiler bug even was in synch with a bug in the debugger, only on assembler level you saw, the code generated was utter nonsense. You stepped into a method (visualized as C++ lines of code) and on a random line of code the complete system crashed.

Java and C# is that simple people write compilers for it as diploma thesis. The only compiler I did not find a single bug in was Symantec C++ 7.0.2 written by Walter Bright. Guess what: Walter is the mind behind the D programming language.

I wasted more hours debugging C++ code than I wrie Java code. And Java I write since 1998 ....

angel'o'sphere

Re:Is the C++ standards committee serious?

[Minna Kirai]

No garbage collection. Come on C++ guys! how many times have we got to

As someone else has probably already told you, the article says GC is being added to C++.

system, and no one has used C++ for any hardcore military project. Where is

The onboard computers of the new F-35 JSF combat airplane are all C++. As are existing Army air-defense missiles. (A factoid mentioned on Bjarne's homepage, also linked from TFA)

Re:Is the C++ standards committee serious?

[Minna Kirai]

I know (isn't it obvious?). What I mean is that "what is the problem with 'auto' so as that we don't have it yet".

auto will reduce code maintenance is many common situations. Most famously is the cases of iterators:
  for (auto i=c.start();!i.done();++i) foo(*i);
With auto, c can be changed to different kinds of containers (from an array to a linked list) without needing to modify the code which uses it. Without auto, you'd need to declare c as something like "vector<Molecule>::iterator", which is harder to read and maintain.

The auto keyword looks to be the most surefire of these proposed extensions, as it is both useful and easy for compilers to support.

Re:Is the C++ standards committee serious?

[Minna Kirai]

Can you expand on how you would write the constructor for, say, a list class that can take a composite literal as a parameter?

Hopefully Bjarne will notice this (or already has, and just didn't want to go into such detail for a brief article). A "sequence constructor" should really just be a single-argument constructor which happens to take an array-argument. Like
    vector<T>::vector<T>(const T &ar[]) {
              set_size(array_length(ar));//assuming a language addition
              for (int i=0;i<array_length(ar);++i) _v[i]=ar[i];
        }

Also, the concept should be compatible with the implicit keyword, so that a function which takes a vector<int> could be given an array-literal.

Re:Is the C++ standards committee serious?

[Minna Kirai]

Also, I can see some potential difficulties with parameters-by-name. The biggest one is that it will break code of the form

It would only introduce ambiguity if an syntax is chosen that already has a valid meaning in existing programs. You demonstrated one such syntax, but there are many other possibilities. For example, name arguments could be accomplished with
    foo(title := "This is a different title");//pascal-style assignment operator

That's actually the best approach I can think of, because := isn't valid anyplace else in C++. Although it's somewhat desirable to use a familiar-looking syntax for new situations, as you point out, that cannot be done without occasionally producing ambiguity with existing code (Just like you can never make a new keyword without breaking SOME programs. Why, my old C++ code broke when they came out with "or" as a keyword. Lousy continentals with their accented vowels...)

Re:Is the C++ standards committee serious?

[Minna Kirai]

AC: For example, class(should be "static") methods don't define a "this" variable (again, because the class doesn't exist). Yet without a "this" variable, dynamic dispatch is not available inside class methods.

So naturally, any method which is virtual static would have a this_class pointer implicitly available, which instead of pointing to any specific object, just tells which vtable is in effect for the function-call.

Re:Is the C++ standards committee serious?

[Minna Kirai]

Your suggestion doesn't work, for reasons which should be obvious. First of all, numbers in curly braces are ambiguous; they could be either an array initializer or an initializer for any struct with that many members. And second, arrays don't carry around their size.

The suggestion can work- it just implies a few other minor language extensions, which should be obvious. First, numbers in curly braces should represent whatever type is valid in that context- or if there are two valid types, then they should mean "array" unless specifically prefixed with the name of a struct.

Second, arrays could easily carry around their size. In practice, typical malloc systems do have them carry their size, but in an inaccessible space. However, since the arrays in question are of fixed compile-time length, the size can be known even easier.

Re:Is the C++ standards committee serious?

[Minna Kirai]

No parameters-by-name function calls", seems like a nice idea, but also seems fundamentally incompatible with va_args style variable length arguement lists unless

There's no real conflict there. Classic variable-argument functions will just be disallowed from being called with parameter-by-name syntax. (Note that parameter-by-name is essentially a more flexible version of the usual system of default argument values)

I suppose that ... would take precidence and would inhibit the use of named args.

Not likely. "..." is considered as dangerous and obselete by the C++ commitee. It is so steadfastly non-typesafe that they want nothing to do with it.

Re:Is the C++ standards committee serious?

[tslettebo]

This was a long rant... You are aware of that C++ is developed essentially as an "open source" project (like PHP, Python, etc.)? This means that the people working on it get absolutely _no pay_ for their volunteer work, and in fact, have to pay to be allowed to work for free (!) by paying their own expenses (unless their employer contributes) for attending standards meetings, fees to ISO, etc.

If you're dissatisfied with the development of C++ (myself, I'm excited about the development), then YOU can do something about it, rather than just complaining, by contributing to the standards work. Maybe you'll then get an appreciation for the amount of work that goes into standards work.

A lot of the things you mention has been suggested to the committee, but there's a limited amount of manpower to work on these things, so for things to get into the standard requires someone to work for it: Write papers, present it to the committee, perhaps make prototype implementation to get real-world experience with it, etc. (the latter has been done for one of the "concept" proposals, by the way). All this can be a lot of work, for people who have ordinary jobs like others, and who's only "compensation" is the same as other open source work.

However, I guess it's easier to be an uninformed "armchair quarterback"...

Oh, and by the way, your encouragement of the committee's work is much appreciated... </sarcasm>

Re:Is the C++ standards committee serious?

[tslettebo]

P.S. I won't go into a lot of your points, since your criticism is so shallow (a pity, as a good discussion of C++'s development could actually be useful, rather than just "mud slinging", which is just time-wasting...) - based on a shallow understanding or treatment of C++ and other languages and design alternatives (but some of it good points, if we had the manpower to do it...), but to pick one:

"Languages that implement generics correctly (Haskell, Ml, Erlang, Ada, etc) have sold these problems many moons ago."

How do you define "correctly"? It has been argued that Ada's generics "killed Ada", because they turned out to be so cumbersome to use (for one thing, you have to explicitly instantiate each generic type, while that happens implicitly in C++). Secondly, Ada's generics _have_ been considered, in the context of the C++ "concept" proposals, but have been found to provide little, if any help, in the case of C++: They're just too limited, to be useful for C++'s rich type system.

So much for being "correct"...

Re:Is the C++ standards committee serious?

[renoX]

> Swing is nice though.

I'd say that Swing design is nice but it's implementation sucked when I tried to use it, quite a long time ago, and Sun was fixing bugs very slowly when they did..

I admit not having tried to use Swing recently..

I don't know if Sun's GUI admin tools included in Solaris9 used Swing or not, but they were in Java and slow as snails, so if even Sun cannot make fast Java GUI apps, there is a problem..

Re:Is the C++ standards committee serious?

[master_p]

This is utopia, and unlikely to happen

It is utopia only in your mind. A standard toolkit is what everyone prays for. Java's good name is due to the SDK being complete enough to cover 95% of all needs.

But if you get it wrong in an ISO standard... what have you to expect? Year 2018?

First of all, it's not 1990 any more. We already know what works and what does not. Secondly, the idea that it must take 10 years for any change is a totally wrong one. The C++ standard committee should stop behaving like some public state employee in a 3rd world country, get their butts down and work hard. If they are not willing to do so, then they should step down and offer their position to one that is willing to work hard.

Re:Is the C++ standards committee serious?

[copenja]

>> no static virtual methods. It is dead easy to do, and sometimes it is ? >> badly needed. For example, the pattern factory heavily depends on it. How would a virtual static be dispatched? Since virtual methods are dispatched via the runtime type of a particular instance and static methods are not associated with any instance? Example: class Base { virtual static void f() { } } class Derived1 : public Base { virtual static void f() { } } class Derived2 : public Base { virtual static void f() { } } int main() { // how and where would this function call be dispatched? Base::f(); } -Jake

Re:Is the C++ standards committee serious?

[Magius_AR]

No garbage collection.

Well, for one, the poster of this submission states that optional garbage collection IS one of the proposed additions in C++0x, so I don't know where this complaint is coming from. On top of that, if you really did want the equivalent of garbage collection, just use Boost smart pointers for any heap allocations.

the lack of import declarations

Why should this require language changes? Just get (or develop) an IDE that generates the headers for you. Problem solved. This seems like more laziness. There's perfectly sensible reasons to separate the headers from the code.

no properties

Just make class variables protected or public and access them directly. Accessors really are not that important. Frankly, I don't believe in encapsulation for the sake of encapsulation. Most of the time, it simply obfuscates things. Hell, most of the reason I can't stand java to this day is because I tired of dealing with constructs like this:

system.subsystem.lang.util.math.random.Plus(myclas s.GetInteger().intValue(),myclass2.GetInteger().in tValue()) // exaggeration intended.

It's bad enough that Java is too stupid to auto-cast Integers and "int" when it has hundreds of functions that deal exclusively with each. At least if the Integer class had the "int" variable not within a damn accessor, each line of my code might actually be shorter than 80 chars *smirk*

No closures

It is possible to carry over functional programming style into C++, including closures, lambda-expressions, and currying. It's just not pretty. And honestly, I see no reason for it being there. C++ is not, nor was it ever intended to be, a functional programming language. Why not just code in Scheme or Ocaml if that's what you want? Most C programmers can't stand the sight of those constructs.

For example, a button with an optional bitmap would be constructed in one line of code, like this: new Button(parent = mainWindow, text = "hello world", bitmap = bitmap1, click = {mainWindow.close()});.

How is that any different than "new Button(mainWindow, "hello world", bitmap1, &mainWindow.close)", with a single constructor on the backend? And if you really wanted to allow for a dynamic situation, what's wrong with instantiating an object and then manually assigning the values? You could even put them all on one line if you wanted: myButton = newButton(); myButton.text = "hellow world", etc etc...

C++ could have been the dominant language, if it was not for the stubborness of the C++ committee to accept that programming languages are developed based on what the world needs, and not on what a few good men know.

Many of your complaints seem to stem from the fact that alot of functional dogma has not carried over into C++ (such as continuations and closures). Last I recall, functional programming represented a very small subset of the programming populace ("what a few good men know"). Most programmers simply don't think that way. Anyways, most problems that call for a functional solution are better done in other languages anyways.

Alot of the other things you mention would be nice though.

Re:Is the C++ standards committee serious?

[DeVilla]

Boy, there is a lot to answer here. Let start with you complaints about the suggested features.

1. the using declaration for making type aliases: OK. I don't think you can do typedef Foo<int, Y> Bar; in C++. It looks like that's what this is for. I've needed it and I've seen library developers lust for it.
2. sequence constructors: Personally, I'd kill for this. To be able to have a constructor and still be able to have aggrigate initialization. I have tons of code that depends on tables that are generated at configuration time before compilation. If the table is in a vector, I currenting have to generate a function that calls 'pushback()' instead of just spitting out array of entries. As far as I'm concerned, this is just one of the many places where we should be allowed to use a literal value, but can't.
3. template concepts: I've want this for a long time. I'm glad it's possible, but given the number of problems getting template right the first time around and the number of corner case that have been hit with them, I don't think it's as easy as you make it sound. C++ isn't as clean as Haskell in this regard it it will be another feature that the implementor will probably screw up a bunch before all the bugs are worked out in the standard.
4. type deduction using the auto keyword: Again, I've want this for a long time and there have been compile that had something like this as an extention. But I think it will be a little while until all the corner cases are defined.

Now, moving on to the gripes.

• No garbage collection: I gotta agree. This would be nice and I though BS said it wold probably be added as an option. If they add it well that will be cool. If they don't add GC or if they make it a default or something, well that will be nasty.
• the bias towards systems programming: If you don't want a systems's programming language, use Java. Please. I am a systems programmer use C++ in a big ol' kernel for a big ol' propriatary OS. Simply put, you are wrong here. Period. Furthermore, systems programming is more than kernel development. Games a performance critical applications often time use 'systems programming'.
• the lack of import declarations: Well, I do hate maintain separate headers and code. But I love having a header separate from the code. If the compiler could generate a human readable interface file (aka header) from the implementation, then I'm cool with it. Of course that would require documentation hints in the implementation to make the header readable...which could lead to another gripe :-)
• no static virtual methods: Well, being that virual function implies the use of a VFT and static implies a lack of object which further implies a lack of VFT, I'm a little confused by what are suggesting as a solution. Still better factory support would be nice.
• no properties I haven't really used properties, so I don't really have anything against them. If you just mean something to allow you to declare a private/protect variable and implicitly getting setters and getters, I'm cool with that. If you mean something where you create a set and get method to be used as a public psuedo data member, then I start to get scared. Hidden side effect don't bug me. They just have to be done wisely, as always. It's the interaction with the rest of that language that assume a variable is a variable and that you can get the address, reference it, as so forth. C++ already allows complete access to public data member and anything that looks the same and behaves differently create a bunch of new corner cases to be defined and dealt with. It can be done, but I don't feel it is worth the churn. You can get pretty much the same thing with a reusable template prop<typename T, getFunc<T> = get<T>, setFunc<t> = set<t>>

Re:Is the C++ standards committee serious?

[OOGG_THE_CAVEMAN]

the bias towards systems programming: If you don't want a systems's programming language, use Java. Please. I am a systems programmer use C++ in a big ol' kernel for a big ol' propriatary OS. Simply put, you are wrong here. Period. Furthermore, systems programming is more than kernel development. Games a performance critical applications often time use 'systems programming'.

I don't want to claim any particular dispute over your experience in games or OS programming, but I find it quite interesting that C/C++ types seem to emphasize so much the "systems programming" nature of their language. It seems to me they have a very strange view of the term "systems."

Roughly, it seems that when C/C++ people use the term "system" they mean some kind of "low level" programming, and the main attributes the language has to support are

1) ability to specify bit- and byte-wise patterns in memory (e.g., put together some special descriptor for a memory management unit, following some diagram in the MMU programmers' manual, or addressing a section of memory as a char addr[] array without any overhead)

2) ability to create sections of code with controlled stack and memory discipline (e.g., no dynamic memory allocation in an interrupt handler)

Now it's indisputable that you need these attributes to create OS kernels and device drivers, but hey, if that's all you needed, you can always use assembler. So there has to be another attribute

3) syntax at higher level than assembler
3a) no CPU opcodes, just Fortran/Algol style operations
3b) explicit support for abstractions such as arrays and strings

The interesting thing is that C/C++ actually DON'T support many of these things in a standard way. Structure and bit-field layout, for instance, can't standardly deal with endian-ness and alignment restrictions. Your compiler needs to be matched to your architecture, and you need to read the compiler documentation and, typically, check the compiler output, to be sure you get what you need. There's no standard way to disable interrupts, or specify stack layouts. A true "low-level" language would be able to express all this and more, in a standard way.

Really, all C/C++ can claim in this respect is to be "good enough", in that at least one compiler exists for a CPU/architecture combination, with good enough documentation to make things happen. That's not a design attribute, that's a commercial reality.

Surely there is room for improvement here, but none of the developments in C/C++ land really address it.

In the other direction, most people who use the word "system" mean "large structure composed of component parts"; C/C++ is notoriously BAD at supporting the kind of abstraction needed to easily construct these systems.

Re:Is the C++ standards committee serious?

[DeVilla]

Well, you got me there. Standard C++ could be better in this regard. We do have to use some special compiler features to deal with architecure registers and we use assembler too. On the other hand, C++ is every bit as good as C when it comes to systems programming and C+ASM does seem to be a bit of a standard as far as systems programming languages go. C++ adds better support for abstraction and can do some axtra work for you w/ destructors, compiler managed VFTs and type safety (if you use it right).

Still the pack pramga, builtin offsetof() extention and my knowledge of how our compiler lays out structs and bit fields have been more meaningful than the standard seems to care to admit. We needed the full array of [u]int{8|16|32|64} types before anyone was nice enough to standardize a thing and now we don't match the C99 standard. Now it's not in the standard but endian-isms just hasn't been a problem as far as I've seen. The network code would probably be the only high perf code that would need it, but our machine matches network endian-ness, so it no big deal.

Now we do have the special stacks and runtime environments (calling conventions, exception/interupt capabilities, addressability, etc.) for different layers of code and it is all very accessable from the C++ code, but some is not implemented in it. The same is true with the memory addressing support. We have wrapped it all with object interfaces though. I don't think you could standardize what we have done without putting restrictions on the processor design. I would have liked it if we'd have used the inline assembler just to let the compiler do a little more work for us, but it probably wouldn't buy us much in the way of recurring cost.

So ya, standard C++ doesn't do bare metal as perfectly as say, assembler. But is assembler standardized anywhere near as much as C or C++? Does any such standard mention how ALL the registers in ANY archetecture are the accessed? The MMU? FPU? NUMA? All the cache strategies that any given processor may support? Is the a language that does? We where able to at least hide all of this under a pretty high level interface.

Now the world for games is OpenGL, SDL and other libraries. I don't have much real game experience. My knowledge came from the days when you had to have your own driver for every sound card, video card and any other device under the sun while making up for the fact that DOS and (early) windows just wasn't much of an OS. I didn't want to program for hardware at all because of that.

Let's just go back to Assembler...

[Prototerm]

...and stop all this high-level language folderall. Real Men program in raw machine language, not some namby-pamby crutch like C++.

Remember: counting in binary is just like counting in decimal...if you're missing nine fingers!

Re:Let's just go back to Assembler...

[TheSync]

Assembler? Real Men push toggle switches to load programs bit-by-bit!

Re:Let's just go back to Assembler...

[fbartho]

Dude, I count in binary on my fingers all the time... Just imagine every finger is 1 bit, so on one hand you can count to 31, and with two hands you can count to 1023, assuming you're not using a finger to represent the sign.

All you do is start from the right hand thumb, flick it up => 1, flick it down and flick up your index => 2, flick up your thumb again => 3, flick both down and flick up your middle finger => 4, ...

Re:Let's just go back to Assembler...

[cdn-programmer]

Missing 9 fingers? Isn't that like a mouse? A mouse is jsut a binary keyboard in disgiuse?

Re:Downhill at a fast rate

[TheOrquithVagrant]

I've never looked at mplayer's source code, but the fact that last I looked, the default makefiles still use -O4 (a non-existing optimization level) have always made me wonder a bit about the devs. Still, ugly code and Gentoo-noob style compiler opts notwithsdanding, mplayer remains the best media player/encoder around, as far as I'm concerned. Interesting paradox.

Keep garbage collectors out of it!

[marcosdumay]

Implementing a garbage collector for this language, even if optional, will kill it. There is a reason for C++ still not having one, it is because it is impossible to write one without restricting the language. Even if you can disable the collector, you'll can not use the constructions that it doesn't unerstand, so this C++0x wont be suitable exactly to what C++ does well.

If you want Java with native widgets, please, rewrite the widgets, not Java!

Re:Keep garbage collectors out of it!

[cnettel]

I think you misunderstand something here. What will probably appear is an additional keyword you add to a pointer variable, or another symbol in the series (*, &) to add "gced" as a possible option to "pointer, reference". Just like you can't modify the contents of a const reference, you might not be allowed to do arbitrary pointer arithmetics on a gced object, without casting it. If you do, you'll be fine. If what you used was originally a plain newed pointer, you won't even see the GC there. Optional is two pieces here -- optional that the gc framework is linked at all and optionally used for every variable. Bjarne sees this as a possibility for certain objects and I can agree there, the point of having GC in C++ would be to not worry about the deallocation of the syntax tree in the fancy parser of yours, where the consumer code is written by some other moron who may want to keep some of the subtrees, but not all of it, forever. It's not for any object that's currently allocated on the stack, absolutely not for objects encapsulating scarce outside-world (files, sockets, mapped GPU memory, db connections) resources.

It's more like a fictive scenario where only primitives and PODs were allowed on the stack. Adding stack-allocated objects would simplify a lot of scenarios and actually bring performance benefits. You'll shoot yourself in the foot if you pass a pointer to such an object to other code which might reference it after the call ends, but no-one will stop you from taking a malloced void* space and against all sense casting it into any object of your liking, avoiding constructors and all.

I really like what I read in this article and previous notes from Bjarne. I just hope that takeup (as in compiler support) might be faster this time round than with C98, both in G++ and MSVC, as those are the compilers I routinely encounter.

Re:Keep garbage collectors out of it!

[drxenos]

They are not adding a garbage collector to the language. They are adding a smart pointer that will automatically call delete when all handles (pointers, references) to a heap allocated object goes out of scope. It just automates what you would have to do anyways. There is no additional overhead of a GC.

How fascinating

[Weedlekin]

Bjarn says he wants to make C++ an even better systems programming language. The way to do this is apparently by adding features to a language already groaning under the last batch, far from all of which have been consistently implemented in all (or even a majority of) compilers. None of these features seem to address the fact that as a systems programming language, C++ has most of the same shortcomings as C, while adding a few of its own:

1) It is no more portable than C. In particular, various fundamental data types are still dependent on the underlying CPU architecture for their size and format, leading to copious macro #ifdef sections in low-level code that must run on a variety of different systems.

2) Use of the extra abstraction mechanisms provided by C++ tends to result in code that is both larger and less performant. This is not a desirable attribute in a systems programming language.

3) It is already an extremely complex language that requires an extremely complex compiler to implement it. This makes it very difficult to validate, thereby rendering it useless for whole classes of systems programming tasks (e.g. high-reliability embedded systems).

4) The language is a mine-field of ambiguities, overloaded meanings, and counter-intuitive default behaviours that conspire to make it incredibly difficult to learn properly. There are so many potential pit-falls that even very experienced programmers from other languages have trouble writing high-quality code with it, meaning that the language is actually a source of problems in many projects rather than a mechanism for solving them.

It is thus not (as Bjarn claims) a "better C", at least in a systems programming context, because nearly everything it adds is largely superfluous to systems programmers, and comes at a cost that they are unwilling to pay. This is especially true in what is by far the largest segment of systems programming, i.e. embedded systems, many of which are programmed in _significantly simplified_ versions of C, not the goya-esque monster that is modern C++.

NB: it is very difficult to design a single language that is equally useful for both high-level applications programming and low-level systems programming because they have fundamentally different requirements. Systems programmers require precise control of minutiae, whereas applications programmers want something that lets them churn build quality end-user systems with a minimum of pissing around. C++ falls between these two stools, adding nothing useful to C's systems programming capabilities, while being so concerned with nit-picking minutiae that writing high-level applications in it is like scrubbing a very big floor with a very small toothbrush. It is IMO well-suited to only one notable application domain: games development, which is unusual in requiring a mixture of both low and high level code.

Re:How fascinating

[Jerry Coffin]

1) It is no more portable than C. In particular, various fundamental data types are still dependent on the underlying CPU architecture for their size and format, leading to copious macro #ifdef sections in low-level code that must run on a variety of different systems.

C99 includes <stdint.h> that provides standard types for things like integers guaranteed to have exactly 32 bits and such. While I'd expect it to be renamed to <cstdint>, it would be quite surprising if C++ 0x didn't include essentially the same thing.

2) Use of the extra abstraction mechanisms provided by C++ tends to result in code that is both larger and less performant. This is not a desirable attribute in a systems programming language.

This depends heavily upon what you do and how you do it. Some C++ features tend to lead to code that's slower than the most obvious equivalents in C -- but in other cases, exactly the opposite is true. Just for an exceptionally obvious example of the latter, try sorting an array of integers with qsort and then do the same with std::sort.

3) It is already an extremely complex language that requires an extremely complex compiler to implement it. This makes it very difficult to validate, thereby rendering it useless for whole classes of systems programming tasks (e.g. high-reliability embedded systems).

Your premise is that it's difficult to validate, but your conclusion would only be valid if it was actully impossible to validate. From a practical viewpoint, however, the difficulty is more or less irrelevant -- the real question is whether a compiler has been validated or not, and if not the language isn't usable for that purpose, regardless of how easy or difficult the validation might be.

4) The language is a mine-field of ambiguities, overloaded meanings, and counter-intuitive default behaviours that conspire to make it incredibly difficult to learn properly. There are so many potential pit-falls that even very experienced programmers from other languages have trouble writing high-quality code with it, meaning that the language is actually a source of problems in many projects rather than a mechanism for solving them.

To my knowledge, the language contains two actual ambiguities, both of which are resolved by fiat, so to speak. One of these was inherited from C, while the other is new to C++ (though fundamentally similar to the one inherited from C).

My guess is that you aren't talking about those though -- and in fact, there's a pretty fair chance you don't even know what they are.

There are a fair number of things many people misunderstand about C++, and many people call their misunderstanding ambiguities (or various less repeatable names) but that's a rather different sort of thing. I'm personally convinced that the concept of intuition applying to programming languages in general is pretty much nonsense as well. Programming is a learned skill, not a matter of intuition (the comment about the nipple being the only intuitive skill virtually springs to mind).

With that said, however, I tend to agree with the basic spirit I'm pretty sure you had in mind -- a programmer does have to learn quite a bit to make good use of C++. Worse, a majority of books and teachers that purport to teach C++ do so incredibly poorly, making the job substantially worse than it needs to be.

That, however, stems only in part from the language itself -- it's largely a matter of Sturgeon's law, though in this case the percentage might be closer to 99 instead of only 90. A large part of the problem is historical as well -- many books on C++ were originally written well before the language was standardized, and have not be adequately updated since, so much of what they cover really doesn't apply in a modern setting and much of the rest is often just plain wrong (often was all alon

Re:How fascinating

[Weedlekin]

"C99 includes that provides standard types for things like integers guaranteed to have exactly 32 bits and such. While I'd expect it to be renamed to , it would be quite surprising if C++ 0x didn't include essentially the same thing."

I would hope that this will be the case too, and of course there is nothing to prevent particular compiler implementers from including something like it now, but something that currently depends on vendor support is by its nature not an aid to portability at all. This is also a problem with C compilers, because not all of them are fully C99 compliant despite the standard having been ratified and published in 1999. Those writing portable C are thus forced to use older methods, and while I fully admit that this is not a problem with C itself (which is defined by the standard), it is a problem that nonetheless still exists for most real-world coders who must write portable C and C++.

""2) Use of the extra abstraction mechanisms provided by C++ tends to result in code that is both larger and less performant. This is not a desirable attribute in a systems programming language.""

"This depends heavily upon what you do and how you do it. Some C++ features tend to lead to code that's slower than the most obvious equivalents in C -- but in other cases, exactly the opposite is true. Just for an exceptionally obvious example of the latter, try sorting an array of integers with qsort and then do the same with std::sort."

You are of course correct, because getting the most from any programming language is highly dependent on what is being done and how. Note however that while template-based generics are an extremely powerful feature that can produce highly performant code with type safety features that are completely lacking from C's "generics via void pointer" approach, it does not come free of charge. For example, the code for sorting a list of integers in C++ may be comparable in size to the C one, but this is not the case if one is sorting various different types via templates; here, the fact that the compiler will generate what amounts to an entirely separate set of routines for each type can quickly bloat C++ code far beyond that of its C equivalent, and that may not be something that people working in (for example) embedded systems can afford. Of course, such tradeoffs between size and speed are as old as computing itself, and not something particular to C++.

"To my knowledge, the language contains two actual ambiguities, both of which are resolved by fiat, so to speak. One of these was inherited from C, while the other is new to C++ (though fundamentally similar to the one inherited from C).

My guess is that you aren't talking about those though -- and in fact, there's a pretty fair chance you don't even know what they are."

If you read what I said, it is obvious that I was talking about things that are ambiguous to people learning to write programs in C++, not ambiguities that compilers have problems resolving (which should be resolved by compiler writers, and never impinge upon people writing code in a language).

"There are a fair number of things many people misunderstand about C++, and many people call their misunderstanding ambiguities (or various less repeatable names) but that's a rather different sort of thing."

I am not referring to these as ambiguities (and my comment did not restrict itself to ambiguities as the sole source of problems for people learning C++). By "ambiguity", I am referring to symbols whose meanings change with context such as the "&" operator. Note that I do not include operator overloading here, as ambiguities that this may introduce are a matter of software design, not the feature itself (although the way the iostreams class overloads ">" does I think serve as a poor example of the way operators should be overloaded).

"I'm personally convinced that the concept of intuition applying to programming languages in general is pretty much nonsense as well. Programming is a learned skill, not a

Re:How fascinating

[Jerry Coffin]

1. A class is a struct with different default member visibility rules. C++ structs are C structs wth some extra stuff, and _follow C struct copying rules_. In a purely C++ context, this means that classes without a copy constructor will effectively have a default one supplied by the system that does a bitwise copy, which can cause all manner of problems for classes with members that are pointers. Simple solution: get into the habit of writing copy constructors for all classes except those you _know_ can get by with the default one.

This is about half true -- it's true that classes that contain raw pointers generally need copy ctors. What's done, however, is not a bitwise copy, but a memberwise copy. The cure isn't to use copy ctors though. The cure is to not use raw pointers on a regular basis. I can hardly remember the last time I had to write a copy ctor because I used a raw pointer.

2. Classes with non-virtual destructors will not destroy themselves properly when used polymorphically, and this can lead to memory leaks in code that appears to be perfectly correct. Solution: make all destructors virtual unless there is an excellent reason for not doing so (e.g. performance). Such a reason should be documented so that people deriving classes from yours know about it, and can guard against it.

This is a problem part of the time, but not really very often. A class that doesn't have a virtual dtor generally means that class wasn't designed as a base class.

There is (occassionally) a problem with a class that was intended to be used as a base class, but due to oversight the dtor wasn't made virtual. In this regard, C++ could be improved -- rather than requiring an explicit virtual dtor, it should make the dtor virtual if the class contains any virtual function.

There are, however, quite a few classes that really have no use for any virtual functions at all -- and there's no point in making their dtors virtual, because deriving from them won't accomplish anything useful anyway.

IOW, much of the problem really arises from teachers trying to push OO as the answer to everything, and overusing derivation when it's not suitable or useful.

[talking about C++ having advantages for system programming]

If this is the case, then why isn't it used more for systems programming tasks? By far the bulk of systems programming still seems to be done in C, and this includes both embedded code, and OS kernels for general-purpose computing.

Of course, any answer to this is more or less a guess, since it's basically about the motivations people had for the decisions they made.

I suspect part of it is that many (most?) people who write code that works directly with hardware do so largely because they like the "feel" of working directly with the hardware -- and they simply don't like a language taking away that feel, regardless of how well it might work.

Second, OS designs tend to be nearly as conservative as possible. Consider, for example, that Microsoft's OSes prior to Windows NT (e.g. DOS, Windows 1.x, 2.x, 3.x) were still written primarily in assembly language! With Windows NT, they changed to primarily C. Direct from assembly language to modern C++ would be an awfully large jump though.

Third, OS designs tend change relatively slowly. The obvious mainstream OSes right now are Linux and Windows. Both have been around since the early '90s or so. At that time, most of what I'm talking about in C++ hadn't even been defined yet, not to mention actually being implemented. Worse, Microsoft (for one example) has only recently made a serious attempt at getting their compiler close to fully compliant with the C++ standard, so many of the best techniques simply haven't been available to them until quite recently.

On the Linux side things weren't quite as grim, but not really a whole lot better either. Worse, the educa

Re:How fascinating

[Anonymous Brave Guy]

If I may interrupt for a moment, I'd just like to pick up on one of the points you made:

For example, the code for sorting a list of integers in C++ may be comparable in size to the C one, but this is not the case if one is sorting various different types via templates; here, the fact that the compiler will generate what amounts to an entirely separate set of routines for each type can quickly bloat C++ code far beyond that of its C equivalent, and that may not be something that people working in (for example) embedded systems can afford.

While it's clearly true that using templates with many types can increase the size of your code, I think the problem is overstated.

Consider that the size of an executable file can easily run to several megabytes these days on any of the mainstream platforms. (That in itself is a pretty damning indictment of the state of the art, but that's another matter.) Even if I instantiate a fairly substantial class template and several of its member functions for a dozen different types, the extra compiled code that results is unlikely to run to more than a few kilobytes, if that. If we're talking about something like a simple sort function, the extra is probably measured in hundreds of bytes at most.

Sure, if you were using generics where everything was done via RTTI and only a single instance of the code was needed, the output code would be somewhat smaller. However, we should remember that the RTTI itself imposes overheads, and there's far less scope for deep optimisations without the exact type knowledge you have with templates, so the ratio certainly won't be N:1 where N is the number of types over which our template was instantiated.

On the flip side, of course, template code can often be much faster than RTTI-based generics, and there are all sorts of tricks for reducing the number of separate instantiations required without giving up those performance benefits if the context is right.

As you say, in a field like embedded software, it's possible that the extra code size could make a real difference, but in most fields, I suspect it's negligible.

Re:How fascinating

[Weedlekin]

"What's done, however, is not a bitwise copy, but a memberwise copy. "

You are of course correct. My bad.

"The cure is to not use raw pointers on a regular basis. I can hardly remember the last time I had to write a copy ctor because I used a raw pointer."

Indeed. However, the fact that C++ is often advertised as a "better C" means that it attracts C programmers in large numbers, and C programmers use pointers as member variables a lot (I know this, because I've had to maintain their code). I think therefore that _all_ C++ books and courses should expound a rule in big, bold letters in a box that says "C++ has a variety of mechanisms that make the use of pointers for dynamically allocated member variables unnecessary. If however you are going to use pointers as member variables, you should provide your class with a copy constructor that initialises them properly when they are assigned to another variable of the same type."

"A class that doesn't have a virtual dtor generally means that class wasn't designed as a base class."

There is a golden rule in OO which says "Do not make any assumptions about the way people will use your classes". If a class isn't designed to be a base class, then there should be a header comment or some other piece of documentation that says so, otherwise people will assume they can inherit from it, and do so. I know this is true, because I have maintained large commercial code bases where this has happened, and has resulted in memory leaks. It's one of the reasons that Java takes the opposite approach of assuming that all classes are base classes unless prefixed with the "final" keyword, which indicates that they can only be instantiated, not inherited from (note that I am not saying this is a desirable solution, only that it is an attempt at a solution in a language that was heavily influenced by C++).

"There is (occassionally) a problem with a class that was intended to be used as a base class, but due to oversight the dtor wasn't made virtual. In this regard, C++ could be improved -- rather than requiring an explicit virtual dtor, it should make the dtor virtual if the class contains any virtual function."

I can assure you that it is more than occasional, but this is not a point that's worth arguing about, as it would eventually boil down to anecdotal evidence that we obviously do not share. However, I don't really think the language needs changing in that way, because it is specifically designed to do what you tell it instead of making assumptions about what you may or may not be doing, and I would argue that this is a major reason for it being so successful, as well as being a major reason for some code bases having many errors in them. Perhaps a good compromise would be for the compiler to issue a warning whenever somebody derives a class from one with a non-virtual destructor, or better still, warn when such a class is used polymorphically (which is after all the only time that this particular problem arises). After all, what may be an error in one person's code could be a deliberate design decision made for a very good reason in someone else's. It is for this reason that I prefer warnings to errors that prevent compilation, and prefer errors to languages that change my code into something else without being told to (a compiler switch or pragma would of course equate to being told to do it).

"IOW, much of the problem really arises from teachers trying to push OO as the answer to everything, and overusing derivation when it's not suitable or useful."

Agreed. However, this is largely due to the fact that C++ owes much of its popularity to the 1990s wave of pushing OO as a silver bullet that would magically solve all of the programming world's problems. A lot of people came to C++ from other languages (usually not OO ones, because experienced OO programmers knew that it wasn't a magic bullet at all) during that wave, and are pretty much locked into that mind-set, and they're often the people who are writing books and teaching it in

Re:How fascinating

[Weedlekin]

"While it's clearly true that using templates with many types can increase the size of your code, I think the problem is overstated."

For most types of applications, I agree. Remember though that the point of mine that you are quoting specifically addresses embedded systems, which are often far more resource-constrained than general-purpose computing devices.

"Sure, if you were using generics where everything was done via RTTI and only a single instance of the code was needed, the output code would be somewhat smaller. However, we should remember that the RTTI itself imposes overheads, and there's far less scope for deep optimisations without the exact type knowledge you have with templates, so the ratio certainly won't be N:1 where N is the number of types over which our template was instantiated."

In the embedded systems I was addressing in the original point, the overhead of RTTI may also be unacceptable. Remember that such code very frequently targets specialist CPUs whose memory is on the chip die itself, so adding more memory is not an option. In these types of highly constrained environments, every byte that is required to support a language feature means one less byte for application logic, so they are commonly programmed in specialist manufacturer-supplied C dialects that directly support certain pieces of the chip's functionality without requiring any libraries (standard ones or otherwise). I am not saying that this is the case for all embedded systems, as there are some that include a full computer with disk drives and an OS such as Linux, but the bulk of embedded system work still targets specialist CPUs that operate in a much more restricted environment.

Re:How fascinating

[Jerry Coffin]

I think therefore that _all_ C++ books and courses should expound a rule in big, bold letters in a box that says "C++ has a variety of mechanisms that make the use of pointers for dynamically allocated member variables unnecessary. If however you are going to use pointers as member variables, you should provide your class with a copy constructor that initialises them properly when they are assigned to another variable of the same type."

In general, I'd tend to agree. Actually, most of the better books talk about this as the law of the big three. The "big three" are the destructor, the copy constructor and the assignment operator. In nearly every case, if you need to explicitly define any one of them (typically because your class has remote data referenced through a pointer) then chances are that you need all of them. IMO, there's very little excuse for books that (often flagrantly) violate this basic rule. It's been (for one example) in the comp.lang.c++ FAQ list since something like 1991 or so. While I realize Usenet doesn't constitute the entire world, or even the entire programming world, I see little excuse for somebody claiming to teach C++ when/if they don't know at least this much.

There is a golden rule in OO which says "Do not make any assumptions about the way people will use your classes".

IMO, this isn't a golden rule or even a good rule. Quite the contrary, I think code (OO or otherwise) should be designed and written for a particular purpose. If that purpose is to be derived from, good and well. If it's not, throwing in something to halfheartedly support derivation anyway is a poor idea. Going further and fully supporting derivation makes a bad situation still worse. You're still doing extra work, and probably introducing extra bugs, to make the code do something it's not really supposed to do. This is one area I agree with the people who advocate testing-oriented development -- you should define what the code really needs to do, and then write the simplest code you can that does it. Any extra capabilities, features, etc., beyond what it's really supposed to do is a bad thing.

If a class isn't designed to be a base class, then there should be a header comment or some other piece of documentation that says so, otherwise people will assume they can inherit from it, and do so.

The fact that the dtor is non-virtual IS documentation that says so. Better still, this documentation never gets out of sync with the code, because it's part of the code. The problem is that quite a few people reading the documentation don't really understand the language in which it's written (i.e. C++) very well. With that given, it's not necessarily a bad thing to add a comment or other documentation to expound on the fact, but it really should be redundant.

...some commercial RDBMS servers for example have code bases that pre-date C++ (or at least pre-date it becoming well known and popular), as do an astonishingly large collection of other applications. Rewriting such code bases in C++ (and then testing them exhaustively for functional compliance with the old one) would be an extremely expensive endeavour indeed, so any use of C++ is as an addition to the legacy code base, not a replacement for it.

With a minor quibble, I agree. The minor quibble is that I'd say it's really "most" rather than "any" use of C++ being an addition to the legacy code base. Ocassionally, somebody really does start something over from a relatively clean slate rather than adding to existing code -- but I certainly agree that it's relatively unsual.

...I would suggest that a root cause of the poor quality of didactic materials for C++ is that (a) it is an extremely difficult language to teach because it is so complex, and (b) said complexity means that those attemp

Re:How fascinating

[Weedlekin]

"IMO, this isn't a golden rule or even a good rule. Quite the contrary, I think code (OO or otherwise) should be designed and written for a particular purpose. If that purpose is to be derived from, good and well. If it's not, throwing in something to halfheartedly support derivation anyway is a poor idea."

I agree that it boils down to design, and that code should be designed for a specific purpose. However, OO in particular is primarily intended to support re-use by derivation -- without that, there is no real point in using it at all, especially in C++, which offers so many other mechanisms for expressing solutions to problems. I would thus argue that the very act of using OO to write code that does not support re-use is an indication that the programmer(s) did not design and write their code for a particular purpose, but were instead trying to force certain types of problems into a paradigm that is ill-suited to them.

"Going further and fully supporting derivation makes a bad situation still worse. You're still doing extra work, and probably introducing extra bugs, to make the code do something it's not really supposed to do."

See above. If this is the case, then OO is a non-optimal solution anyway.

"This is one area I agree with the people who advocate testing-oriented development -- you should define what the code really needs to do, and then write the simplest code you can that does it. Any extra capabilities, features, etc., beyond what it's really supposed to do is a bad thing."

I fully agree. But I would suggest that in a multi-paradigm language such as C++, trying to lever solutions into one of them that would be better expressed in another violates the "simplest possible" rule anyway. One of the things that makes C++ worth learning and using despite its complexity is its ability to express solutions to problems in ways that fit them naturally, unlike for example Java which forces all solutions into a single pre-conceived model, irrespective of whether that model is an appropriate one for the problem or not.

"The long and short of it is that teaching C++ well is not necessarily terribly difficult or complex. In fact, I think it's far easier to teach people to write reasonable- to good-quality C++ than even meciocre- to fair-quality C."

Agreed, but I would amplify your point somewhat. C++ can be taught more easily than C and indeed be significantly easier to program in than C if use of the STL is emphasised from the beginning, and "inherited" C features such as fixed-length arrays, "dumb" pointers, etc. are either left out entirely, or in the case of training materials for C programmers, discouraged (naturally with good explanations of why the STL solutions are preferable).

"I honestly don't mean to be sarcastic, but by this rule we should all be using really simple assemblers with no macro capability. At least IME, these are about the only languages sufficiently trivial that most users really do understand them almost completely."

I disagree here. It is perfectly possible to write a general-purpose programming language which is well-suited to both systems programming and applications programming without adding undue complexity. Oberon is a good example of such a language: its entire grammar can be expressed in 20 pages, and it is very easy indeed for any experienced programmer to learn, yet it can be (and indeed has been) used to write everything from operating systems through MVC frameworks to applications. I am not for a moment suggesting that it is better than C++, or that it is an equivalent: it merely serves as an example of something that fulfils many of the C++' stated design goals without being either complex or difficult to learn.

"The problem is that the rules being easy to learn doesn't generally seem to translate to good code, because bugs rarely arise from poor undstanding of arcane rules. Rather, they arise from the tedium of constantly ensuring that even the most trivial rule is followed."

I would not argue with this. H

Re:How fascinating

[Jerry Coffin]

However, OO in particular is primarily intended to support re-use by derivation -- without that, there is no real point in using it at all, especially in C++, which offers so many other mechanisms for expressing solutions to problems. I would thus argue that the very act of using OO to write code that does not support re-use is an indication that the programmer(s) did not design and write their code for a particular purpose, but were instead trying to force certain types of problems into a paradigm that is ill-suited to them.

If you can find it, I'd advise reading "Code reuse, concrete classes, and inheritance" by Scott Meyers. Unfortunately, it's an article from the July/August 1994 issue of The C++ Report, so finding it probably won't be easy (and while Scott cites it on his site, he doesn't have a link to an online copy).

Lacking that, you might want to read this Usenet post, which at least discusses the basic problem.

What it comes down to is pretty simple though: in C++, a class should be designed to be used as a base class, OR to be instantiated, but you generally can't write a class that supports both properly.

It is perfectly possible to write a general-purpose programming language which is well-suited to both systems programming and applications programming without adding undue complexity. Oberon is a good example of such a language: its entire grammar can be expressed in 20 pages, and it is very easy indeed for any experienced programmer to learn, yet it can be (and indeed has been) used to write everything from operating systems through MVC frameworks to applications.

Learning Oberon well enough to use it is one thing -- the question was whether most users really know all the rules in their entirety. Quite frankly, I can't answer that very well. Offhand, I don't think I've ever known anybody who really did, but I've known only a few people who used Oberon at all, and it's possible they were the exception to the rule.

OTOH, learning enough of C++ to use it (and even use it quite well) doesn't require memorizing the entire C++ standard or anythign like it either. I doubt that even 5% of the good C++ programmers I've known have ever even attempted to learn all the details of two-phase lookup or anything like that. Of course, it probably helps that there's only one compiler (Comeau) that implements two-phase lookup nearly correctly, so most people have little reason to care a lot about it.

In both cases, the learning process is eased when there is a set of simple grammatic rules that are consistently applied, and becomes progressively more difficult when the complexity of the grammar increases, and / or the number of exceptions to the rules it expresses grow.

I can't say I really agree. FORTRAN has about the most god-awful grammar ever invented, but doesn't seem significantly more difficult to learn than most of the other mainstream imperative languages. At the opposite end of the spectrum, you could probably fit the grammars for Brainfsck, unlambda and Intercal all onto a single page, but good luck on ever really learning any of them.

This is especially true when a new feature is unfamiliar to existing programmers, and may therefore require a degree of training before (a) they can use it, and (b) realise why using it is a good idea, even though it may initially appear to require some extra work to use effectively. It is I think the reason why the STL still isn't utilised anything like as often as it should be: people think "Oh, templates", and start to read up on them, and it looks hellishly complicated and arcane, so they give up before realising that the level of knowledge required for using the pre-built templates in the STL can be grasped in a matter of hours. This would doubtless be even more true for DbC,

Re:How fascinating

[Weedlekin]

"If you can find it, I'd advise reading "Code reuse, concrete classes, and inheritance" by Scott Meyers. Unfortunately, it's an article from the July/August 1994 issue of The C++ Report, so finding it probably won't be easy (and while Scott cites it on his site, he doesn't have a link to an online copy)."

I couldn't find it, which is a shame, because Meyers is usually well worth reading. However, the other reference you included describes the problem quite clearly. It possibly indicates that there is a fundamental design flaw in the language itself, at least in this respect, although Meyers' suggestion of identifying and classifying abstractions would in any case be a good one even if this problem was not present (at least in the conceptual sense, irrespective of what language one is working in).

"Learning Oberon well enough to use it is one thing -- the question was whether most users really know all the rules in their entirety. Quite frankly, I can't answer that very well. Offhand, I don't think I've ever known anybody who really did, but I've known only a few people who used Oberon at all, and it's possible they were the exception to the rule."

I found it extremely easy to learn, but again, that could just be me: I didn't have any great difficulty learning C++ either, at least to the level where I was confidently writing code that worked as expected (which is after all the raison d'etre of any programming language). Of course, this was probably helped by having been exposed to it in its V1.0 days, when it was a considerably simpler beast; I therefore had the luxury of being able to absorb new features as they were added instead of trying to digest today's much bigger and more complex version in one huge, sustained gulp.

"FORTRAN has about the most god-awful grammar ever invented, but doesn't seem significantly more difficult to learn than most of the other mainstream imperative languages."

No, but given the fact that most imperative languages were inspired by grandaddy FORTRAN, and many still contain constructs with similar names that do similar jobs, it's not really very surprising. Unfortunately, I have no evidence about whether those new to programming find the language easy or not, as I've never met a beginning FORTRAN programmer: most people who use it seem to be engineers etc., and were taught to use it as part of their degree courses.

Re:How fascinating

[Minna Kirai]

Sure, if you were using generics where everything was done via RTTI and only a single instance of the code was needed, the output code would be somewhat smaller.

The fact that you even need to be aware of that consequence demonstrates a failing of the language. One of the intractable theoretical problems of C++ is that the programmer's choices in how she describes a concept are so coupled to the efficiency of the eventual machine code.

Ideally, you could program in a manner that provides the most understandable and modifable (ie, well-factored) implementation of the behavior, and leave low-level tuning of size/speed up to the compiler (possibly with hints in compiler switches or pragmas).

C++ doesn't nearly approach that ideal. You have 2 main languages mechanisms for writing generic functions: either virtual inheritance, or template functions. Those methods differ not only in the scope of applicable problems (only one can work on native types or 3rd-party classes), but also in how the outputted machine code will be structured. Inheritance means more CPU usage and some storage overhead, while templates mean code bloat (which can also be a speed drag, if it blows the cache).

With a good language, a library implementor would be able to decide on the look of the API without forcing such far-ranging consequences on the final executable. Sadly, the backwards-compatibility of the C++ build process means it can never be that good.

(Of course, the above problem isn't solvable in general, but I'm talking about a few specific and well-known tradeoffs)

and there's far less scope for deep optimisations without the exact type knowledge you have with templates,

The type knowledge isn't necessarily different. If the compiler were able to consider all source files when producing an executable (rather than producing multiple object files at intermediate stages) then it would have equal type knowledge with both approaches. The reason template code gets exact types even with current non-global compilers is that the programmer has had to manually specify what & where instantiations are needed.

Re:How fascinating

[Anonymous Brave Guy]

Ideally, you could program in a manner that provides the most understandable and modifable (ie, well-factored) implementation of the behavior, and leave low-level tuning of size/speed up to the compiler (possibly with hints in compiler switches or pragmas).

Sure. I don't see how anyone could reasonably argue with that, other things being equal. But the problem is that other things aren't equal: as you say, the problem isn't solvable in general. I'm aware of no language in use today that achieves anything like the performance you can get with C++ while still isolating the programmer from the kind of decision we're talking about. In fact, I'm not sure you can ever truly achieve that isolation, because any artist or craftsman will achieve better results if he has more understanding of his tools and techniques, and programmers are no exception.

In any case, I'll respectfully disagree with your example. My personal view is that using templates and using class-based polymorphism are quite orthogonal techniques in C++, and suitable for solving rather different types of problem. While I suppose you could implement some concepts either way, I've always found the decision about which to use to be easy, usually based on whether I want to consider the static or dynamic type of the object I'm dealing with -- something that is inherently related to the big picture design of the program, and unlikely to change later on. I honestly can't think of a time I've wished I could change my mind later, so IME any theoretical lack of flexibility doesn't really make any difference in practice in this case.

You seem to have some specific example(s) in mind here. Perhaps you could give us more of an idea of what they are?

If the compiler were able to consider all source files when producing an executable (rather than producing multiple object files at intermediate stages) then it would have equal type knowledge with both approaches.

In fairness, C++ implementations increasingly do look at the entire code base when performing optimisations. But the problem with languages with RTTI-based generics, Java for example, is that many of them can't examine the whole code base at compilation time, because they have dynamic loading behaviour that means they can't tell whether they've got everything or not at compile-time.

I've always assumed this is why JIT compilation at load-time makes such a huge difference to performance with some languages: they're not just compiling to native code rather than interpreting pseudo-code; they're also able to see pretty much the whole code base at once for the first time and can optimise accordingly.

Re:Adding new features is not always an improvemen

[Rick Genter]

I agree 100% - C++ is too feature-heavy as it is. Bjarne should stop while he's only a little behind ;-).

As far as the preprocessor goes, one of the things I don't like about Java is the lack of a preprocessor. Sun ended up having to build assert() into the language because of it. Yes, the preprocessor can be abused, and perhaps it needs to be redesigned, but having no preprocessor is too restrictive.

I know there is this grass-roots "D" language floating around, but I'd like to see a C+=2 (or perhaps E?) that started back with the current ISO C standard, then added object-oriented features in a more organized, well-thought-out fashion.

(And no, I don't consider C# to be the answer. C# was just Microsoft's way of cloning Java. Now Sun and Microsoft are in a pissing match with Sun playing catch-up this round, trying to force features into Mustang to catch up to C# 3.0.)

C++ vs Retards on Rails

[zaphle]

I can't believe someone rated you "3 interesting" for a crap post like that.

It's like judging the quality of a car by the features of the glove department. Obviously you haven't been doing any serious C++ programming to come up with this sort of comment. I suggest you try to read Andrei Alexandrescu (google that up yourself) for some real programming power.

I can't believe people can be serious about calling Java and C# more modern than C++; they don't even have multiple inheritance or class-local typedefs. Or how about switching your code to call a memberfunction at compile-time vs at runtime (as in templates vs polymorphism). How will you do that if you are forced to use a virtual machine?

Oh no wait, the next big thing: Ruby on Rails (that's Retards on Rails to me). Everybody in the industry knows the major drawbacks of code generation (generate code, change generated code, IT manager says the specs change, regenerate code, redo the initial changes, notice they don't work anymore, ...) which is why things like templates were introduced as a first in C++ and LATER adapted in languages as Java and C#. So who's leading?

You people make me tired.

Re:C++ vs Retards on Rails

[mustafap]

>I can't believe someone rated you "3 interesting" for a crap post like that.

Maybe it's because I expressed a sentiment felt by others, who maybe didn't want to express it publically here because of the personal insults that would result.

It's only a tool, not a religion.

Re:C++ vs Retards on Rails

[abigor]

You have to remember who you're dealing with here. Many of Slashdot's commenters are kids who have dabbled in scripting or perhaps learned a bit of C in school. Then there are the people who are tangentially involved with IT, read gossip news sites, and believe they are tech authorities. Finally, there are hobby programmers who have no idea what the demands of the industry are, and believe that C is a perfectly fine language for everything, despite the fact that no one uses C except in the few specialised circumstances for which it is well suited (embedded, for example). There are good reasons for this.

C++ runs most of the world's desktop applications. In the open source world, it's used by KDE, Firefox, and many applications. It forms the bulk of the backend to huge enterprises like Google. It will be with us for a long time to come, because it offers structure, speed, and immense flexibility unmatched by most declarative languages (Andrei's Alexandresu's "Modern C++ Design" demonstrates these features well - that book is just mind boggling).

And of course C++'s syntax is not perfect, and of course it is dangerous when used improperly by C programmers who are averse to the STL, smart pointers, and so forth.

About the only thing I can see forcing it out of the application space is Microsoft convincing everyone to develop and rewrite with .Net and Windows.Forms. But that won't happen for ages, if at all.

Anyway, this is why most working programmers I know don't contribute comments to Slashdot. As you observed, it is just too tiresome fighting with people who have absolutely no idea.

Re:C++ vs Retards on Rails

[Anonymous Coward]

Code generation? Obviously you haven't been doing any serious Ruby on Rails programming to come up with that sort of comment. Code generation is a very small, very insignificant part of the framework, only added to make people who don't know any better go "oooh" and "ahhh" when watching the videos. And code regeneration is unheard of.

If you actually play around with rails, I think you might be pleasantly surprised. Or maybe not, but at least you'll be able to make halfway intelligent criticisms. And ruby itself (separate from the rails framework, and the more natural target for comparison with c++) is a thing of beauty.

For what it's worth, I agree with you re: C++ vs. C# and Java. But ruby is in a class on its own.

Re:The difference

[xdc]

0x = the year 200x, where x may equal 9. (?) I'm not sure. Just a thought.

I like some of the proposals for C++0x

[jonwil]

Here are some things I personally would like to see (some of which have been mentioned elsewhere as possible inclusions). Not all of them are 100% appropriate for something like C++ and the C++ standard library but all of them are things that seem (to me) to be usefull things to have as compiler and library provided functionality.

language provided thread support. This would need to provide the following (at least):
1.Proper thread safety at the language level (including mandates that the standard library is thread safe)
2.Thread-local storage (i.e. a way to say "this variable is local to this thread")
3.A way to say "this block of code should only be accessed by one thread at once" or "this variable should only be accessed by one thread at once" (something like a critical section on win32 I guess)
Plus of course ways to create threads and such.

Complete compatibility with C99 (i.e. any valid C99 program is also a valid C++0x program and will compile and run)

something similar to (and compatible with) fstream/ifstream/ofstream except that it reads from a block of memory instead of a disk file

A nice sane cross-platform way to detect memory leaks (i.e. the compiler implements the standards-specific memory leak detection in the implementation of new and delete and then the progammer would enable it e.g. with a new #paragma or something. (this goes with the garbage collector idea mentioned elsewhere)

Complete unicode support throughout the C++ language and standard library (although I think this is already mostly there)

New classes or functions (e.g. a new string class and new/improved collection classes) designed such that they help prevent or miinimize buffer overflows and memory corruption and the resulting effects (sort of like how compiler vendors like microsoft have started to add "safe" string functions only standardized)

Standardized definitions for constants like pi (plus more math functions as standard)

A standard library to do data compression and uncompression (perhaps an implementation of what is defined in RFC 1950, RFC 1951 and RFC 1952 i.e. the algorithim and format used in gzip, pkzip and zlib would be appropriate). Further to this, a new fstream/ifstream/ofstream derivitive that will compress data when writen out and uncompress it when read back in (without the programmer having to do anything).

I like the idea for a standard library way to do directory and file manipulation and the idea for a standard sockets library although (like the compression idea I have above), I do wonder if they are really appropriate for C++ or if they are better provided by third party libraries.

hay now

[sacrilicious]

I ressent your synicism.

Re:hay now

[iscy]

For all that time, I though that slashdot's readers were probably the type of people who can understand something about computers. But now, since I read most of the posts of this thread, I do not believe that anymore. Then unfortunately, I really have to agree with you... iscy

Re:C++ template concepts vs. C# generics constrain

[dalleboy]

And using C++ template concepts - "Oh, in 2009, AC is going to need to use an int in a template that needs the CountDown member function, we better make int implement it".

Same thing, different taste. (Not that primitives have member functions in C++, but feel free to exchange int with something other.)

Stop complaining about things you don't know!

[tchernobog]

As far as I can see:
1) people complaining here about C++ or its will-be features either aren't C++ users or don't understand much of C++;
2) people who have at least managed to RTFA to the end are complaining about new features of the _language_, that will be _few_, while the biggest efforts will be oriented towards extending the STL, which is the really important part.

Btw, only a C user that understand C++ poorly could complain about references. If you find yourself at ease with C, by all means, use it. But don't spit on another well engineered language without the necessary knowledge to do so.

By the way, about references: what's so different when passing to a C function a pointer to a struct, instead of a reference to a C++ one? Don't you have still to read the prototype to know you must pass a pointer indeed? There's just one small difference between C and C++: guess what, if the prototype is a const reference in C++ you've more guarantees the object won't change than with a const pointer in C, since C++ enforces constness. And you don't even have to worry about pointers referencing to free'd memory.

It would also have been nice if this ./ discussion were about the new features of C++0x instead of the old "C is better than C++", "python is better than C" and "x86-assembly beats the pants off both".
Oh, well: it's Slashdot after all. What was I expecting. Sigh.

Re:Stop complaining about things you don't know!

[metamatic]

1) people complaining here about C++ or its will-be features either aren't C++ users or don't understand much of C++;

I guess that's true: I wrote C++ for years, and hate it, but I'm not complaining.

Re:Stop complaining about things you don't know!

[marco.antonio.costa]

constness

is that even a word???? =)

Re:Stop complaining about things you don't know!

[Teckla]

Given the following code:

int i = 42;
foo(i);

In C, you know that foo() can't change the value of i.
In C++, you don't know that foo() can't change the value of i.

Re:Stop complaining about things you don't know!

[mad.frog]

given the following code:

      int i = 32;
      int* j =
      foo(j);

In C or C++, you don't know whether foo() can change the value of i.

Or, for a more likely case:

      char* s = "howdy"; // I'm old-school, I refuse to use const
      foo(s);

Note that changing the contents of s is clearly illegal (or at least a Bad Idea) in most runtime environments, but nothing prevents the code from doing so, nor does anything in the code indicate whether it might happen or not.

Summary: both languages allow you to write unclear code in common cases. You just cherry-picked one case. Yeah, it'd be nice for both languages to require this to be clear in all cases, but till they do, it's your responsibility as a programmer make it clear, either by coding convention or by comment.

Re:Stop complaining about things you don't know!

[stickb0y]

Summary: both languages allow you to write unclear code in common cases. You just cherry-picked one case. Yeah, it'd be nice for both languages to require this to be clear in all cases, but till they do, it's your responsibility as a programmer make it clear, either by coding convention or by comment.

The point is that in C, if you see a pointer being passed as an argument, you know that the callee might mutate it, so yes, you have to investigate that callee's contract. In C++, you never know; you have to investigate all callees.

Yes, the grandparent poster cherry-picked one case, but that doesn't invalidate his point that C++ is more unclear than C in this regard.

Re:Downhill at a fast rate

[blancolioni]

As a Lisp programmer
[...]
GC promotes sloppy programming.

I cannot reconcile these two statements.

Re:Adding new features is not always an improvemen

[Frans Faase]

As for the preprocessor issue you describe; it's type-safety.

I think you haven't understood the issue. Preprocessing is exactly not sufficient to assure type-safety. It has happened often enough (especially in large project with many include paths) that the wrong version of a certain .h file was included to produce a mismatch between to .dll files that would lead to mysterious crashes due to member variables being align differently.

This is because the .dll file does not contain any information of .h files being used during the compilation. And I hope you can change the "effect" of an .h file by defines in other .h files. So, one would have to examine the preprocessed files to determine whether the interfaces would match. The evil of preprocessing is that you lose all kind of information that is essential for the kind of type-safety that you would like to have in an environment where you make use of libraries.

And this problem is not specific to DLL files on MS Windows, but also occurs on other platforms where shared libraries are in use and the libraries do not contain an explicit interface definition that can be validated. (And we all know that a simple version number is not sufficient for interface validation.)

Re:Here's an offer

[DataPath]

it's called C++0x for now because it hasn't been finalized yet. When it's finalized, as expected in 2009, it will be C++09, just as when the last revision was finalized it was C++98

Most languages are revised over the years, deprecating some things, adding others.

Java, for example, has deprecated and added HUGE numbers of features and classes, and there've been many more official/standard versions of it than there have been of C++

C++ is not a type-safe language

[cquark]

While C++ is more strongly typed than C, C++ is not type safe. Type safety means that the language ensures that no operation will ever be applied to a variable of the wrong type. However, C++ supports the ability to access arbitrary memory locations, allows type casting, and automatically converts types in many instances. Java is more strongly typed than C++, as it doesn't allow access to arbitrary memory locations, but it also supports casting and automatic conversions, and so is not type safe. If you want type safety, try a language like Ocaml or SPARK Ada.

Re:C++ is not a type-safe language

[Surt]

Note that java will not let you apply an operation to an object of the wrong type: the type cast will throw exception first, and take you out of scope of the operation.

Re:C++ is not a type-safe language

[Pxtl]

The idea is that you can do both in C++. If you restrict all your operations to a subset of the standard, C++ is safe. If you allow yourself usage of the unsafe objects, then C++ is unsafe. If you make wrappers for all the the core primitives, you can even have a more oop, typesafe language than Java.

The problem is that (a) too many C++ coders treat C++ as a superset of C, instead of a new language that is backwards compatible with C, (b) the standard library is weak, and (c), standard compliant compilers (and the '90s standard) came out too late in the game.

Re:C++ is not a type-safe language

[Pxtl]

There are two ways to think about C++ - C++ is a superset of C, and C++ is a new language that is backwards compatible with C. Both are true, but they produce completely different programming styles.

Re:C++ is not a type-safe language

[iliketrash]

or SPARK Ada [praxis-his.com]

Indeed. And don't forget the excellent open source Ada compiler, GNAT, part of the GNU Compiler Collection (GCC) and available on Mac OS X and integrated with Xcode and Project Builder (yee haw).

Re:C++ is not a type-safe language

[Minna Kirai]

AC: 1. C++ IS a superset of C. C came up short in certain areas. C++ tried to fix that and from TFA it is still evolving.

Back when C++ was first released, "int virtual;" was a valid declaration in C. But of course, that variable name is illegal in C++. Therefore since we've seen at least one sample where valid C code doesn't work in C++, C++ is not a superset. (There are also more substantial ways it is not a superset, which I won't detail)

More generally, no language which introduces a new keyword is a superset of the older language, because it breaks those programs which already used that keyword as a custom identifier.

Re:Downhill at a fast rate

[Rick Genter]

You really need to do this:

ln -s /vmunix /dev/tty

Then you have to type in your OS on each reboot - kind of like having a 1.5 million character password :-).

Re:Adding new features is not always an improvemen

[Frans Faase]

The problem with preprocessing is that you never can establish a reliable relation between the interface definition (.h files) and the compiled code (.exe or .dll), because the compiler does not know which .h files where used after preprocessing has taken place. And I hope you realize that the used of #defines in one .h file can change the definition of classes in another .h file. So, even in a collection of .cpp files that compile into a library or executable, it is possible to introduce "bugs" due to miss-alignment of member variables that are very hard to find. Preprocessing as it is done in C (and C++) is simply bad. But I guess that most people don't realize it, because they have become used to it.

Re:C++ template concepts vs. C# generics constrain

[dalleboy]

What you say is true for C++98 templates, but C++98 templates are not the same thing as C++0x template concepts. C++98 templates grants you to use any member (function, typedef, variable, etc) of a type, but C++0x template concepts does not allow you to use any other member than those specified in the concept of a type.

Re:Adding new features is not always an improvemen

[Profound]

No need, the Unix way is not to compicate a program with features but instead to combine another small tool with it to together achieve the functionality. There are quite a few things around that could do this for you, Make, Ant, etc or even just the shell.

DIR=/usr/local/strange_module-2.3.7
CFLAGS=$(DIR)/include
LIBS=$(DIR)/lib

Re:Downhill at a fast rate

[Anonymous Coward]

Thus, Stroustrup's willingness to include any "feature" that someone suggests: "Oh sure, we'll put that in and see how it works out."

That's actually pretty libellous. You need to read "The Design and Evolution of C++" and get back to us.

Shared library issue

[KenSeymour]

Along these lines, one problem I am aware of from my C++ days is this:

The caller allocates the memory for a new object. The class code initializes the data members. This is ok if everything is compiled together.

But if you use shared libraries, and you change the class to contain more or fewer data members, you must re-compile all the calling code.
So much for data hiding.

You can work around this limitation by providing functions or factory class methods in your shared library to do all your constructing, but this is extra work.

C++ in School

[bean_tmt]

There has been a lot of talk about getting rid of C++ altogether. I can't help but think C++ will continue to be used (and with good reason) by many schools and universities. Being such a low level language, C++ does a good job at teaching one about memory and computer architecture while also teaching principles of programming. Learning C++ with help one with a computer architecture course and vice versa. It is also a nice transition language between learning a programming language and learning assembly programming. Do we really think it will be gotten rid of? Just a thought.

Re:Heh

[Stele]

When Objective C has templates then maybe I'll look at it.

With C++ I can write one piece of code that can process pixels with 8 or 16 bit integer channels or 16 or 32 bit floating point channels. Fanboys of Objective C and Java are obviously not writing image processing software.

Without such important features as operator overloading, constructors, stack-based objects, and references, I really can't take Objective C seriously. I can't imagine it being used for much mission critical software, that's for sure.

Argh...

[ovit]

You know, as excited as I am about a new C++, when I looked at some of the code Bjarne offers up as an example I have to say that I feel a bit underwhelmed.

I know all you C++ guru's out their are just IN LOVE with template classes, but you should pick your head up every now and then and look at how other languages are tackling the issue. Other languages offer the same inherent functionality in MUCH cleaner ways at the expense of a little CPU. You already have RTTI, use it, and save us all the pain of debugging a class with 4 template parameters (which themselves are probably templated classes)....

Don't even get me started on the useless error messages heavily templated code causes the compiler to emit.

        td

How do you spell BMW again?

[infinite9]

Actually, the correct pronunciation will be "See Plus Plus".

As soon as some buzzword-compliant HR department gets a hold of this, they're going to be sending job-reqs to dice through stupid non-tech headhunters. They'll want someone with 10 years of C++0x experience (C++ is insufficient now) and who's willing to take a retarded online test to prove it. How many times have you heard a brain-dead recruiter spell out acronyms that are usually pronounced or pronounce acronyms that are usually spelled out? I vote for Cocks. At least it's a word bimbo T&A recruiters will understand. :-D

Re:How do you spell BMW again?

[ivan256]

How many times have you heard a brain-dead recruiter spell out acronyms that are usually pronounced or pronounce acronyms that are usually spelled out?

Many. It's one of the ways you know not to do business with that recruiter (if they're an independant headhunter) or that you don't want to work for that company (if they're a private recruiter).

Similarly, if a hiring manager asks for more experience than technically possible you know that you either don't want to work there, or if you're desperate for a job that you can lie your ass off, and the manager won't know the difference. Don't like lying? Well come up with some rationalization or redefinition such that you're not technically lying.... Do you work 70 hour weeks? Well then every year you work is effectively 1.75 man years of experience. Take the months off the dates on your resume, and only list years. Then the manager will round up and count the calendar years instead...

Re:How do you spell BMW again?

[infinite9]

If you rule out recruiters who don't know anything, you'll never work again. The silly requirements are infrequent enough to avoid though. Usually, I just politely correct them and move on. Usually, they're grateful for the information.

Re:How do you spell BMW again?

[Anonymous Brave Guy]

I doubt the odd name will be much of a problem. After all, C9x hasn't appeared on any requirements lists I've seen so far, and it's been C99 for 6+ years now.

I do find it entertaining when random HR staff ask me how much experience I've got programming with pearls, though.

Re:run-time compiling?

[cnettel]

Because it can't be done cleanly. It makes RTTI seem pale and benign, and that's still turned off in most projects. It breaks with all C tradition and you would basically need to include debug symbols for everything, including libraries, in your runtime code, as the point of mapping a string to an arbitrary variable is that it's arbitrary. In addition, you can easily do it over select domains of fields by preprocessor and templates, auto-registering stuff as it's run, in your own hashtable.

Here's what I want

[alexo]

Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas!
Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas!
Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas!
Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas!
Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas!

It is tedious, inefficient and unclear to define a functor for single-use transformations, away from where the code is actually used.

C++ is already a multi-paradigm language.
Add some functional concepts while you're at it.

Re:Adding new features is not always an improvemen

[rbanffy]

Your DLL problems are a problem of Windows, not of C++. C++ does not try (nor it should) to fix Microsoft's architecural problems. C++ just tries to be as powerful and the least intrusive it can be.

I often find that programming with C++ for Windows is mostly programming for Windows, with a ver little tiny bit of C++ thrown in to bind things together. Expanding on the reasoning on the first paragraph, it seems C++ succeeds admirably well on this.

My USD 0.02

Re:The difference

[swillden]

What does 0x mean? That somebody got creative?

No, it just means that Stroustroup doesn't know how long it will take the new standard to be finalized, but that he expects it to be done before 2010. '0x' is a year, and the 'x' is a placeholder for the unknown portion of that year. If you prefer regular expression format, we could call it '0[6789]'. In fact, based on the rate at which such things happen, we could probably say '0[89]'.

Re:Downhill at a fast rate

[Profound]

C++ is a better, superset of C. The features can be used individually without forcing you to use other ones or change programming paradigms and you do not pay for any features you do not use.

Are you sure that there are NO features in C++ that would make your life easier? For instance I can think of a few (and you can pick and choose) that drop straight into C programming with no overhead or change from C-style at all but make life much nicer:

-// comments
-better compiler warnings
-stronger type checking, no default int
-ability to define variables throughout the scope, ie for(int i=0 ; i<10;++i)
-namespaces
-overloaded functions, default arguments

Some libraries that are more efficient that what you'd write yourself:
-string vs C's char[]
-list/map/vector etc

And some new ways to think about programming:
-polymorphism/inheritance
-templates
-destructors and RAII

From a former C++ fan

[fionbio]

Sorry for rather long and muddled post, and also for my poor English... Also, if you have allergic reaction to Lisp advocacy, don't read any further.

Some years ago when I had some spare time I was struggling a lot trying to make C++ a better language. I was trying to reinvent reflection, easy serialization, extend metaprogramming facilities and so on. My hopes were mostly in http://www.boost.org/">Boost C++ libraries.

At some point I've decided to try to write some extended metaobject generator, like Qt's moc, but friendlier to "modern C++", using GCCXML. In addition to generating reflection info, I was thinking of generating proxy classes and other stuff like this.

Among other things I've tried to do some of XML translation work using XSL (i.e. XML AST from GCCXML -> some more AST convenient XML representation -> (transformation) -> resulting metaobject AST. I've discovered some interesting things about XSL, e.g. that it's possible to "emulate" iteration (which is somewhat lacking in XSL) with recursion. Nevertheless after a few days of fighting with XSL I've decided to try some language which is more suited for processing various trees. Of course, when C++0x is ready, I thought, it will be the best language in all respects, including tree stuff, but as of now, STL+boost::lambda+whatever is still somewhat quirky (for instance, look at those 10 pages long error messages when you make a typo). So, although I was heavily influenced by standard myth-based mindset concerning Lisps (slow, interpreted, purely academic, "lost in a sea of parenthesis" and so on) I've decided to give Scheme a try, as I've heard that it can be used as a better XSL.

After playing with Scheme for a while, I've found out (to my surprise) that the language can be used for many other purposes besides list (tree) processing and simple scripting (as in Gimp). As an example, there are wonderful things like Scsh. It's possible to write Web applications, many Schemes can do OO. My deep respect to C++ (The Most Powerful Language Ever) began to fade, albeit slowly.

So I've begun to try to do some real things in Scheme. Disillusionment has come rather quickly due to the fact that a lot of critical stuff in Scheme (e.g. OO and packages) is not standardized and thus is 100% non-portable between implementations. Moreover, every implementation has its bugs and limitations, and when you come to the point when you need to change your implementation you discover that most of your code needs to be rewritten from scratch.

I was nearly ready to continue developing my "metaobject generator", pushing Scheme's role back to "better XSL". But something made me try Common Lisp before doing so.

What quickly became apparent to me from my CL experience is that most of problems Boost guys are fighting against are just plain nonexistent for Lispers. Look at this, for example: variant.hpp. A good workaround for C++ typing model. What do we have in Common Lisp?

(let ((x 5))
....
(setf x "abc") ;; no problems with types!
....)

(sorry for mangled indentation)

Now look at this beauty: boost::lambda. Don't forget error messages it produces when you mistype something or stumble across a bug. CL example?

(mapcar #'(lambda (x)
;; any code you want
...)
my-list)

Not to mention Lisp's GC versus boost::shared_ptr.

OK, these are areas where dynamic languages like Perl, Python and Ruby, and even statically typed like C# or Java are catching up to some degree. Now let's look at some CL's more-or-less unique features.

Re:From a former C++ fan

[zeuqsav]

So you're advocating CL over Scheme? It seems like CL suffers from the same fragmentation of features/implementations that you describe for Scheme. Just take a look at what the reddit guys had to do http://reddit.com/blog/2005/12/on-lisp.html because of this [rewrite in Python].

Re:From a former C++ fan

[Arandir]

Don't judge C++ based on Boost. As near as I can tell, Boost is merely the practice grounds for the STL Obfuscation Contest. :-) I can always tell when a software build is sucking in Boost headers because the compilation slows down to a crawl.

C++ is a general purpose object oriented language. As such it's going to be suboptimal compared to more specialized languages. But the generalness of the language far in away makes up for that. I can use it for writing device drivers, real time control code, databases, applications, CGI backends, GUIs, etc, etc. It's the world's best general purpose language, followed very closely by C.

I am NOT arguing that Lisp is a bad language or that you should abandon it. But if you're going to learn one language in depth to last you a lifetime, C++ should be very near the top of your list.

Re:From a former C++ fan

[fionbio]

A lot of stuff that is implementation-specific or DIY in Scheme (packages, classes, structs, "non-hygienic" macros, useful higher order functions, conditions (exceptions), pretty printing and many other things) is standard in CL.

CL's problems actually stem from the lack of Open Source libraries (as there are just too few Lispers). There are two approaches to solving these problems:

• (a) use commercial implementation which has everything included. An example of such implementation is Allegro CL which includes hardly much less functionality than .NET Framework; they also provide mind-blowing CL OODB and a lot of other useful stuff. It's quite expensive though.
• (b) use existing open-source CL implementations & libraries, improving them as you need, and maybe contributing some your code.

Approach (b) is feasible when most functionality of your product resides in your code and not in libraries. E.g. reddit.com code is mostly a rather thin wrapper around database + Web server, so free Common Lisp implementation may not be a best tool for the job. It may be better to use a commercial CL implementation or some other language (such as Python) in such cases, depending on how much money & spare time you have.

Another example - I'm writing an online store now as a semi-holiday project, I don't have too strict time constraints there, so I'm using CMUCL+CLSQL+TBNL to implement it. With severe time constraints it would be better to use Python in my case, as I don't want to pay $$$ for commercial Lisps.

But there are plenty of cases where Lisp proves to be just the ideal tool for the job.

Re:From a former C++ fan

[zeuqsav]

Thanks for the info, I find LISP fascinating but haven't been able to justify using it beyond Emacs LISP use. It does seem like there's a lot of crossover into Ruby (I've not really looked at Python, but I believe the same is true here). I recently built an online store for a family member's business using Ruby On Rails (highly recommended btw!) -- it started out in Java/Tomcat, but was taking *way* too long, the RoR implementation took a couple of days.

Re:From a former C++ fan

[fionbio]

I've used to have rather profound C++ experience (about ten years now). I've wrote a Race-Track Microtron control system in it and some other stuff like that, really :-) But I still fail see in which way it's better than Lisp, besides some (but not 10x-20x as when compared to languages like Python in Perl) performance gain, which is not always critical. It's possible to write applications, device drivers and operating systems in it, as well as databases, compilers, GUIs, web applications and lots of other stuff in it. I have some doubts concerning hard real time, but given the fact that GC can be locally avoided/inhibited using rather simple techniques, I think there should be no much problems there. C++ experience is useful thing, but I think that Lisp is in no way less important.

Re:From a former C++ fan

[Arandir]

It's possible to write applications, device drivers and operating systems in it, as well as databases, compilers, GUIs, web applications and lots of other stuff in it.

The examples in your first link requires a special Lisp machine to run on. I'm sure you could write Tcl drivers for a Tcl machine as well. Try writing a driver for the Linux kernel in Lisp. Heck, try writing a userland driver for X.org!

I am not claiming that C++ is better than Lisp. Go read my post again. Repeat, I am not claiming that C++ is better than Lisp. Every language has its strong and weak points. C++'s strong point is its generality. It may not do any one thing the best, but it will do a very many number of things well.

Re:From a former C++ fan

[fionbio]

The examples in your first link requires a special Lisp machine to run on. I'm sure you could write Tcl drivers for a Tcl machine as well.

CPUs of "Lisp machines" were not Lisp interpretes. Their instruction set resembled something like Java or .NET bytecode actually AFAIK. Later Open Genera was released that allows one to run the Lisp OS on Alphas. Using high-level opcodes is not critical for Lisp (most modern CL compilers save CLisp produce native machine instructions for their target architectures).

Try writing a driver for the Linux kernel in Lisp. Heck, try writing a userland driver for X.org!

Yes, it's rather hard to do so, just because Linux kernel and X.org are written in C. If they were written in Lisp, it would be hard to write drivers in C unless authors cared to provide proper FFI-based "foreign" driver loading mechanism. There's nothing wrong with Lisp itself concerning low level stuff. For example, take a look at this beast (Lisp on bare metal).

As a matter of fact, I agree that C/C++ is safer bet in our world, but not because C and C++ are more general languages than Lisp is. It's just because most of stuff in use is written in these languages. Lisp machines failed (mostly due to management & political reasons), Lisp itself became the scapegoat for failed AI promises, so now curly braces are almost inevitable for serious programmers.

But nevertheless Lisp is worth learning as it can be the best tool for complex problems in many cases, and also due to the fact that it makes programmers more broad-minded. It's actually much more general than C++ in the sense that it easily supports almost any paradigm one can imagine. For instance, it's possible to seamlessly embed SQL, Prolog, HTML, etc. rewritten using S-expressions in Lisp programs.

Re:From a former C++ fan

[MostlyHarmless]

E.g. reddit.com code is mostly a rather thin wrapper around database + Web server, so free Common Lisp implementation may not be a best tool for the job. It may be better to use a commercial CL implementation or some other language (such as Python) in such cases, depending on how much money & spare time you have.

It is funny that you should mention Python as a replacement for LISP in the context of Reddit: they indeed recently switched from Python to LISP, rewriting their whole application in about a week.

Re:From a former C++ fan

[fionbio]

It is funny that you should mention Python as a replacement for LISP in the context of Reddit: they indeed recently switched from Python to LISP, rewriting their whole application in about a week.

(correction: they switched from Lisp to Python) It's exactly the reason why I mentioned Reddit. A perfect example of a situation where most of the job is done by existing libraries/frameworks/etc.

Re:From a former C++ fan

[Arandir]

But nevertheless Lisp is worth learning...

I never said it wasn't! But still, I can't use Lisp to write a device driver on any system I own. C/C++ is like the English language. It's far from perfect, as the Esperanto advocates will tell you in length, and somewhat awkward. But I'm still going to write my documentation in English rather than Esperanto.

Re:From a former C++ fan

[OOGG_THE_CAVEMAN]

CPUs of "Lisp machines" were not Lisp interpretes. Their instruction set resembled something like Java or .NET bytecode actually

The CPUs of Lisp machines were generally micro-coded architectures where

1) the micro-instruction set optimized certain Lisp operations like type-safe generic mathematics, using the specially-designed features of the microcode architecture

2) the memory word-width and microinstructions were optimized to allow efficient (for the time) operation on tagged and relocatable/safe-pointer objects. The virtual memory subsystem was also well-matched to the needs of the garbage collector.

Both of these are relatively Lisp-specific, which is why workstations with generic CPUs, doing operations which weren't Lispy (like text or integer-only processing), eventually beat Lisp machines in speed, especially given the huge engineering effort going into general-purpose CPU development (Intel), vs. custom-ASIC-Lisp-processors (Symbolics,...)

Nowadays, we know enough about Lisp compiling to general-purpose CPU instruction sets that special-purpose hardware offers no real advantage, and 64-bit memories give plenty of room for tag bits.

The reason people kept using Lisp machines, even though performance was generally slow, was that the development environment was integrated in ways that todays "IDEs" can only dream of. Plus, you still had the advantages of high robustness from safe pointers, and well-engineered virtual memory systems. Symbolics Genera was a programmer's dream environment.

Still, you are right in saying that the problems of developing Lisp-language drivers is a impedance mismatch to UNIX rather than an intrinsic language disadvantage. The C compilers for Symbolics machines worked, but it was a true stretch to make things portable between C written for a typical UNIX box and a computer with very non-C-like pointers.

Re:C++ template concepts vs. C# generics constrain

[CrimsonO]

You bring up an excellent point about the rigidity of C# generics constraints. One of the crucial features of the proposals for concepts in C++ is retroactive modeling, which allows you to adapt to the specific syntax of a concept *without* changing your data type. So the problem you mention for C# generics is not actually a problem with C++
concepts.

Here's an example. I'm writing a concept for a Stack, which might look like this:

template
concept Stack
{
typename value_type = S::value_type; // the type of values on the stack
void push_to_top(S& s, const value_type& value);
void pop_from_top(S& s);
value_type& get_top(S& s);
bool is_empty(const S& s);
};

I picked some silly names on purpose. Now, std::stack doesn't match the syntax of this concept. So what if we try to pass a std::stack to a function like the following, which expects something that is (we use the term "models") a Stack?

template
void clear_stack(S& s)
{
while (!is_empty(s)) {
pop_from_top(s);
}
}

It's going to fail to compile, because std::stack does not match the syntax of the Stack concept. If C++ concepts had the same restrictions as C# generics in this regard, we would be stuck writing an adaptor class. Yuck.

Retroactive modeling saves the day. We can fix the problem by writing a model definition like this:

template
model Stack >
{
typedef T value_type;
void push_to_top(std::stack& s, const T& value) { s.push(value); }
void pop_from_top(std::stack& s) { s.pop(); }
value_type& get_top(std::stack& s) { return s.top(); }
bool is_empty(const std::stack& s) { return s.empty(); }
};

In this model definition, we're meeting all of the requirements of the concept by providing function definitions that transform the syntax of the Stack concept (pop_from_top, is_empty, etc.) into calls to the std::stack itself (see the function bodies). Now, when we call clear_stack() with a std::stack, it "just works": the calls to is_empty() and pop_from_top() in clear_stack() go through the model definition. Of course, if we picked more standard names and member functions in our Stack concept, the model definition could be empty or (for implicit/structural concepts) omitted entirely.

Retroactive modeling is *really* important for making it easier to reuse template code. You won't need to be paranoid about matching syntax *exactly* with every concept you need to model, because the compiler will detect any mismatches and you can fix them through a model definition---without having to change the data types, templates,
or concepts. Of course, people will still try to agree on names and concepts when possible, because it saves typing. You can check out the actual proposals before the C++ committee (references follow) for more information. There are two active proposals, but the groups are working together, so expect a final "combined" proposal in the future.

There are other differences between C# generics and C++ concepts. Before starting to design concepts for C++, most of the authors of one of the concepts proposals (N1849; see below) did an extensive study of the generics facilities of several languages (e.g., C# generics, Java generics, Haskell, ML functors, C++ templates). They ran into trouble with every language they tried, and we designed our C++ concepts to avoid those problems. Here's the original paper; there's an extended version (with more languages and more detail) under review:

Ronald Garcia, Jaakko Jarvi, Andrew Lumsdaine, Jeremy G. Siek, and Jeremiah Willcock. A Comparative Study of Language Support for Generic Programming. In Proceedings of the 2003 ACM SIGPLAN conference on Object-oriented programming, systems, languages,

Gnaaaaaa

[dorkygeek]

C(++09) or C(09++), are you guys cracy?? The ++ operator CANNOT be applied to a literal! To variables only!

Re:Gnaaaaaa

[pclminion]

The ++ operator CANNOT be applied to a literal! To variables only!

You meant "lvalues."

Re:Gnaaaaaa

[civilizedINTENSITY]

When projecting project completion dates, literals are variable!

[OT] 'constness'

[tchernobog]

We italians are quite creative with the english language... just another way to say that we invent new words when we don't know them off-hand. Strange enough, the word "constness" exists, and it's a perfectly legal one in English. You can even google for that! :-) Maybe also English people invent new words when they don't exist. ;-)

Re:[OT] 'constness'

[GenSolo]

Maybe also English people invent new words when they don't exist. ;-)
Two words: William Shakespeare

For the most part, looks good

[Metasquares]

I like most of these additions, though I wonder why they're not just standardizing the (currently nonstandard but widely supported) STL hash containers for hash tables. Regexps are also already in the language in the form of a POSIX library (regex.h), though I don't think MSVC++ supports that, and the regex library could definitely become more user-friendly.

The "auto" keyword being used to automatically determine the type of a variable sounds like it can cause no end of trouble, especially when using polymorphism (will auto give you back a pointer to the base class or the derived one? What if the function isn't virtual? etc.), so I probably won't be using it in my future programming.

Garbage collection AND dynamic allocation via new/delete together? That ought to be interesting... and probably very dangerous :)

The "using" thing after the template definition seems pretty useless and confuses the template declaration with potentially unrelated aliases. Why not use a typedef further down in your program?

Concepts were something I wanted to see in the language from the first day I learned about templates. They should make debugging template issues much easier. I'm glad to see that they're considering them.

Re:For the most part, looks good

[scotch]

IIRC, they are adding hash containers (std::hash_set and std::hash_map and multi-variants) to the standard. Also, I believe they are adding the boost::regex library to the standard library as well.

Re:C++ template concepts vs. C# generics constrain

[Profound]

(I didn't write the AC post above) You are getting silly now trying to defend your point. Please google for "duck typing".

You can't add methods to primitives (in C based languages, anyway) but because of operator overloading there are still options available. In fact combining Operator overloading and templates is quite cool:

template<class T> T min(T a, T b) {
        return a<b? a : b;
}

ie this would work for int, float, as well as your own matrix class (if you implemented operator<).

I once made a container that returned the average of all the objects in it (all things I hadn't made myself eg float, int, short, matrix, 2D vector etc). To do this you need to somehow reset a counter to zero, which is pretty hard if eg the matrix class can't accept an assignment constructor of 0. The solution of course is "*= 0", which works assuming that has been defined.

The only way to do that in C# would have been if someone had the foresign with all of those classes to have added a virtual .zero() method.

Re:Downhill at a fast rate

[jcr]

C++ is a better, superset of C.

C++ is to C as Lung Cancer is to Lung.

Also, it's not a proper superset of C.

-jcr

Re:Adding new features is not always an improvemen

[zootm]

(And no, I don't consider C# to be the answer. C# was just Microsoft's way of cloning Java. Now Sun and Microsoft are in a pissing match with Sun playing catch-up this round, trying to force features into Mustang to catch up to C# 3.0.)

As a systems language, right now, no. But there is some really interesting-looking work on the MS Research page (the Singularity project, if I remember) with using it as that with some crazed tools they have, and exploiting the features of "safe" languages to make a different sort of system.

As for "C+=2", have you looked at Objective C? I believe that its general purpose is to provide a "better" OO implementation, although I've never used it myself. That said I think it runs all C code (where C++ does not) so possibly not all that OO from the ground level...

Re:Downhill at a fast rate

[Eli Gottlieb]

(gcl)* (list "Lots of Irritating Superfluous Parenthesis" "Lisp uses garbage collection, you insensitive clod!")
("Lots of Irritating Superfluous Parenthesis" "Lisp uses garbage collection, you insensitive clod!")

Get off your soapbox. Some of us like languages that actually have syntaxes and can really do low-level work.

Get/set syntactic sugar is a bad idea for C++

[Nurgled]

Syntactic sugar for getters and setters can be useful for providing a more natural interface (as long as people don't abuse them), but they don't really have any place in a language like C++, where almost everything is set in stone at compile time. Properties work well in dynamic languages like JavaScript because the binding takes place at runtime, at the very last moment before the member access is resolved. The code to access a plain member field vs. a property is quite different, and in C++ this must be generated at compile time.

The upshot of this is that you can't change a field to a property and vice-versa while retaining binary compatibility. This means that you've essentially added a gotcha to the language which everyone must be wary of when designing their public interfaces. While a.b = c looks a bit prettier than a.setB(c), in my opinion it's better to be explicit about what's going on to avoid problems down the line.

Re:Get/set syntactic sugar is a bad idea for C++

[mattgreen]

I don't recall C++ making any claims about binary compatibility in the standard. It just happens that most compilers implement things in a very similar way and we know what makes and breaks binary compatibility. Heck, you break binary compatibility when you change the virtual-ness of a function, this doesn't mean that we must force all functions to be virtual in the name of binary compatibility.

Re:Get/set syntactic sugar is a bad idea for C++

[bored]

Syntactic sugar for getters and setters can be useful for providing a more natural interface (as long as people don't abuse them), but they don't really have any place in a language like C++, where almost everything is set in stone at compile time.

I don't see how binary compatability has anything to do with it. You can't change a member function to virtual or add a overloaded default parameter either without breaking binary compatabilty. Personally, I've used two diffrent C++ implementations with properites and you would simply be amazed at how useful they really are. Besides its not like C++ to force people to write code that is explicit. Look at the refrence syntax that allows you to pass a variable that may or may not be modified. Ex: in C Myfun(a) could never modify a, with C++ it can. Now I personally _NEVER_ use non const refrences, but it is there.

What C++ needs is some form of binary interface though. Part of the reason so many people are still using C or (extern "C") is because its still the only standard way to write a libary that other languags can access. Hell often times you can't compile your C++ program with one compiler, and another part with another C++ compiler and expect to be able to link them together. This has really got to stop. There are a lot of techical issues why this would be hard (while maintaing the ability for vendors to do a lot of vendor specific optimizations), but it can be done. Especially if another keyword were to be added to specify external interfaces, or the compiler were expected to dump some kind of meta file about the interfaces.

Try reading your own post.

[Some Random Username]

Blocks are just anonymous functions with closures, so ruby and python are equals? But python doesn't have proper first class anonymous functions with closures. It only has a half-assed crippled version that is supposedly being removed in python 3. So clearly python is missing functionality that languages like ruby and pike have.

Re:Adding new features is not always an improvemen

[mwvdlee]

The problem sound rather like "linking an incompatible library version" than header problems occuring through use of the C++ preprocessor.

Java can have the same problem since it links in EVERYTHING at runtime. Put an outdated class in the classpath before or instead of the correct class and you've got a problem.

I don't think any other language handles the situation any better.

The only way to "fix" this is by doing some sort of version-number (timestamp?) checks, the mechanics of which aren't dependant on a specific language or it's features.

I still don't see how this problem is caused by the C++ preprocessor though, perhaps an example would help?

p.s. I hope "And I hope you can change the "effect" of an .h file by defines in other .h files." was a typo.

I Win

[19thNervousBreakdown]

for (vector > p = v.begin(); p!=v.end(); ++p) cout >::iterator p = v.begin(); p!=v.end(); ++p) cout *p endl; Hot damn, somebody get me a cookie, I found a mistake in Bjarne Stroustrup's code!

Re:I Win

[19thNervousBreakdown]

Oh, poetic justice, I hate you.

Re:I Win

[trelony]

... and while explaining why "auto" variables are much easier to use. Right on a spot!

Re:I Win

[Eli Gottlieb]

You can read that?

Re:I Win

[19thNervousBreakdown]

for (vector< double, My_alloc<double> > p = v.begin(); p!=v.end(); ++p)
    cout << *p << endl;

Should be:

for (vector< double, My_alloc<double> >::iterator p = v.begin(); p!=v.end(); ++p)
    cout << *p << endl;

Is what I originally meant to post... now if you mean reading the syntax... yeah, I know. You'll have a hard time finding a C++ programmer that really likes the syntax.

In size, maybe...

[alispguru]

But:

They don't have writers the caliber of Guy Steele or Kent Pitman, so it'll still read like gargling razor blades

Their legacy syntax straightjacket will insure the code stays verbose and hard to read. Compare:

struct ltXMLCh {
        bool operator() (const XMLCh* s1, const XMLCh* s2) const
        {
            return XMLString::compareString(s1, s2) 0;
        };
    };

with

#'string<

or (comparing apples to apples):

(lambda (s1 s2) (declare (string s1 s2)) (string< s1 s2))

Re:In size, maybe...

[Anonymous Brave Guy]

Your C++ is riddled with syntax errors, and appears to be using some hideous naming convention that I've never had to use in my whole C++ programming career. That aside, you do know that something like lexicographical string comparison would be done quite straightforwardly with one line of standard library code, right? And that there are lambda-style libraries that let you write something surprisingly close to a functional programming language's real closures when the operation you're trying to do isn't completely routine anyway?

Your comparison may be apples-to-apples, but I think your C++ apples have been rotting for a decade...

Re:In size, maybe...

[alispguru]

The admittedly ugly code I posted was cut-and-pasted from a recent program I wrote using the STL and Xerces-C++. The money line should have been:

return XMLString::compareString(s1, s2) < 0;

(Slashdot ate the <. I fixed it in the Lisp code, but didn't notice it in the C++ - wonder why... ;-)

That nasty little wrapper around XMLString::compareString allowed me to write:

    STD map<const XMLCh*, const char*, ltXMLCh> label2filename;

when I wanted to map a bunch of Xerces tags to corresponding standard C filenames. There is probably a better way to do this using Boost, but I believe it's the canonical way of using the STL in this instance. This program has to live inside libraries that barely use the STL, much less "exotic" stuff like Boost.

Some of the ugliness here probably comes from Xerces - that's where the STD above came from.

Re:In size, maybe...

[Anonymous Brave Guy]

Fair enough, if you were constrained in what you could use then what you wrote is indeed pretty much textbook stuff. It's just that, given a choice, I doubt any decent C++ programmer would voluntarily use that. The lack of proper lambda/closure/higher order function support in C++ has always been the thing that meant the initially promising STL stuff never lived up to the hype. With the more recent template wizardry -- the sort of stuff the standards people are trying to build on when they talk about improving support for library writers -- we're finally approaching the point where C++ can do at least some of the clever things that appear in chapter 1 of any book on a functional programming language! :-)

Re:In size, maybe...

[CoolGopher]

Well the C++ example can be somewhat understood by someone not familiar with the language (much thanks to 'compareStrings'). The second one I have no idea of what the hell it's supposed to do. It appears to be line noise (hmm, guess that means it's acceptable perl). And the last one appears to possibly be doing a comparison, though it looks like mangled K&R C.

Verbosity is not necessarily a bad thing. I can't remember who said it, but a good quote is "write computer programs foremost for humans to read, and for computers to execute only as an afterthought". If you've ever had to maintain massive amounts of code written by others, you'll quickly come to appreciate verbosity and despise "clever"/"cute" shortcuts that might mean the original author had to type six characters less, but in return has turned maintenance into a severe headache.

Oh, and that '0' before the ; in the C++ snippet - that won't make any compilers happy me thinks =)

Re:In size, maybe...

[edwdig]

#'string<

I'll grant you that that certainly isn't verbose, but there's no way in hell you can say that isn't hard to read. Even the average Perl script is easier to read than that. What does #' mean?

I'm assuming the C++ code is overloading the less than operator. The ugliness of that C++ code isn't from the language, it's from the odd naming scheme used. About the only thing not completely self explanatory in the example is the return value of compareString, but that return value convention is a pretty standard thing.

(lambda (s1 s2) (declare (string s1 s2)) (string< s1 s2))

This you can at least figure out what it's doing fairly easily. It takes a bit of thinking about it to parse though as the syntax isn't at all natural. Without knowing Lisp, it's not at all obvious why things are grouped the way they are. The order of things is a little weird too. "s1 string s2" and "s1 s2 string" both seem more logical a syntax than "string s1 s2".

The verbosity of C++ code is nice because you can read it out loud and understand what it's doing. Lambda expressions might be easy to read if your idea of a good time is solving graph theory problems, but otherwise they really aren't clear.

Re:In size, maybe...

[Anonymous Brave Guy]

The verbosity of C++ code is nice because you can read it out loud and understand what it's doing. Lambda expressions might be easy to read if your idea of a good time is solving graph theory problems, but otherwise they really aren't clear.

So let me get this straight: an in-place function definition isn't clear unless you like graph theory; but a structure pretending to be a function that takes two pointers to unmodifiable hieroglyphics and promises not to change the data members it doesn't have as it calls another function that belongs to another class or namespace and tests whether the answer is negative is nice because (if and only if you know what all the syntax means) you can read it out loud and understand what it's doing?

Wow, you must really hate graph theory. :-)

Re:In size, maybe...

[alispguru]

The C++ code I posted is straight STL, which calls a function in the Xerces-C++ library - it has a major bug in it as posted because Slashdot ate a critical '<'. See this posting for the details.

I object to the C++ STL method of denoting function objects because it's verbose, and it's verbose without being enlightening. In C++, this kind of stuff happens routinely because of having to avoid new syntax and new keywords that might conflict with old C code. Is 'operator()' clear and intuitive to you?

The second line is only cryptic if you don't know Lisp at all. It's short for

(function string<)

and is the standard Common Lisp notation for reference-to-function. In the Scheme dialect, the (function ...) wrapper isn't needed, but the name of the string comparison function is different:

string<?

The last one in normal Lisp source would be indented like this:

(lambda (s1 s2)
        (declare (string s1 s2))
        (string< s1 s2))


It's closer to the C++ because of the (optional in Common Lisp, for speed only) declaration in the second line.

None of this stuff is tricky Lisp - it's just a notation you're unfamiliar with.

On the subject of verbosity, one of the real gurus of Common Lisp, Richard Gabriel, agrees with you. See the "Abstraction Descant" chapter in his book Patterns of Software. Great book if you're at all into software patterns, BTW.

Disagree

[everphilski]

No one has used C++ for any major operating system,

Windows XP, NT, 9x. See: http://public.research.att.com/~bs/applications.ht ml

and no one has used C++ for any hardcore military project.

I'd beg to differ.

-everphilski-

Re:Disagree

[diegocgteleline.es]

Windows XP, NT, 9x

Those kernels are mostly written in C. They allow you to use C++ for drivers but they even "discourage" it in the documentation. Userspace is another matter.

As a linux kernel hacker said: "a language where '+' is allowed to do something that it's not really '+' is not a good choice for a kernel"

Re:Disagree

[master_p]

No, all the code in the kernel and major libraries is written in straight C. Microsoft uses the Visual Studio C++ product, but all the APIs are in C.

As for military projects, I know since I work in that sector. Ada is the primary language in these 'hardcore' military projects.

Re:Disagree

[Gruneun]

As for military projects, I know since I work in that sector. Ada is the primary language in these 'hardcore' military projects.

Many of us work in that sector. Around here, Ada is the primary language of outdated projects that are being maintained by people who don't have an alternative. Anyone who has done government work knows that "working" is a relative term and increased efficiency is rarely justification to allocate funds for replacing a "working" system. Maintenance funds are far easier to come by. Those projects will finally be replaced when the last of the high-priced Ada consultants have died. Maybe.

That's not to say Ada wasn't the best choice at the time, but it's certainly not the "go to" language for any new projects I have seen in the last decade.

Re:Disagree

[Anonymous Brave Guy]

As a linux kernel hacker said: "a language where '+' is allowed to do something that it's not really '+' is not a good choice for a kernel"

Then again, a programmer who would define '+' to mean anything other than the natural sum of its operands probably isn't a good choice for a kernel programmer, either.

Re:Disagree

[everphilski]

As for military projects, I know since I work in that sector. Ada is the primary language in these 'hardcore' military projects.

I work in that sector too. And while older military programs *do* use Ada, I assure you most of the newer programs do not. Contractor I work for uses C++.

-everphilski-

Re:run-time compiling?

[Eli Gottlieb]

>(eval (read))
(format t "~a" "You really should learn LISP.")
You really should learn LISP.
NIL
>

Yep, c++ == good, but not for prototypes

[CarpetShark]

Not to add a pointless "me too", but I would also agree with this. I'd just like to add that this massive time for dealing with types does make C++ very unwieldy for quick prototypes if you just want to test an idea. To that end, I find the common approach of prototyping or doing quick utilities in python, and re-doing mission-critical stuff in C++ to be a great compromise.

Be careful what you wish for...

[alispguru]

Can you imagine what a C++ lambda construct would have to look like?

(lambda (x y) (- y x))

would turn into a mess like:

int lambda(int x, int y) { return y - x; }

And that's a trivial one...

Re:Be careful what you wish for...

[Anthony Liguori]

Can you imagine what a C++ lambda construct would have to look like?

(lambda (x y) (- y x))

would turn into a mess like:

int lambda(int x, int y) { return y - x; }

Actually, it's a bit more elegant than lisp *gasp*:

_1 - _2

See the Boost Lambda library. Boost is the C++ library working group. Most of the library enhancements have come from Boost. Lambda's have been around for a while but aren't a part of the current standardization effort.

They work by having a set of placeholder variables that act as parasitic types so that the above expressions turns into an instance of a templated type who's function operation will evaluate the given expression. Really cool stuff.

Re:Be careful what you wish for...

[alispguru]

Actually, it's a bit more elegant than lisp *gasp*:

_1 - _2

Assuming you actually meant:

_2 - _1

which is what my example did, that does look interesting. It also shows why numbered positional parameters are probably a bad idea, if they require you to trade terseness for readability.

Re:Be careful what you wish for...

[Anthony Liguori]

which is what my example did, that does look interesting. It also shows why numbered positional parameters are probably a bad idea, if they require you to trade terseness for readability.

You can define the placeholders to have any name you want, but I can't think of a convient scoping construct other than maybe the GNUism of ({}). You could have something like lambda(x, y, {y - x}) which would be a pretty reasonable syntax that would expand (via CPP magic) to ({boost::lambda::placeholder x; boost::lambda::placeholder y; {y - x}}).

Re:Be careful what you wish for...

[alexo]

> See the Boost Lambda library. Boost is the C++ library working group. Most of the library
> enhancements have come from Boost. Lambda's have been around for a while but aren't a part of
> the current standardization effort.

That's exactly my gripe.

Slashdot -- just like C/C++

[Latent Heat]

It seems that Slashdot is the only place in the Web forum universe where you have to explicitly place the paragraph-break angle bracket-p-angle bracket. I guess I don't know enough HTML to get that symbol to show up in the posted text to show what I mean, but neither does anyone else around here it seems.

I also end up looking silly by placing paragraph break HTML on other sites I post. Everyone around Slashdot (just like -- name favorite feature -- C/C++) programmers gets in the habit of using proper paragraph breaks, but it is entertaining to watch a noob make a long post, or perhaps an old timer who has passed some brain gas, make a honkin run-on post.

I guess Slashdot could fix this and accept whitespace as a paragraph break, but I guess that would violate some deep principle. But I am not blaming Slashdot -- it is deep in the software developer culture to accept things the way they are and then holler at the newcomers about their mistakes brought on by the fractured syntax. How do you think the C syntax has become so viral?

Re:Slashdot -- just like C/C++

[Zathrus]

I guess Slashdot could fix this and accept whitespace as a paragraph break, but I guess that would violate some deep principle

Or you could change your posting default to "Plain Old Text". But then that would completely and utterly invalidate your entire whine.

C++ successor - D Programming?

[Ignominious]

it would do assembler, C, C++, and higher than C++ level

IMHO those four languages are better unified - that gives the programmer the most control.
Have you heard of the D language? It's not C or C++ precisely but is pretty close, has provision for using C APIs, has assembly, more function/object features and is easier to make more reliable code - see features kept and features dropped from C++:
D Programming overview

Re:C++ successor - D Programming?

[Ignominious]

In some garbage-collected languages (e.g. Java or C#) the garbage collector is responsible for the eventual destruction of local objects and it is thus impossible to know when the destructor will be called; to use RAII in such languages the programmer must define and call a finalization routine.

In other garbage collected languages (such as D), class instances can be declared such that when they go out of scope, the destructor will get called, thereby supporting RAII.

From http://en.wikipedia.org/wiki/Resource_Acquisition_ Is_Initialization

Re:Heh

[Weedlekin]

"With C++ I can write one piece of code that can process pixels with 8 or 16 bit integer channels or 16 or 32 bit floating point channels. Fanboys of Objective C and Java are obviously not writing image processing software."

And C++ fanbois are prone to assume silly things about other languages from what somebody they agree with says about them. As an example of this, the fact that Java has templates seems to have escaped you.

As to image processing:

Objective C: http://en.wikibooks.org/wiki/OsiriX_Specifications . Could have found a lot more stuff, but can't be bothered just to provide even more proof of the fact that you are talking utter crap.

Java: lots of examples here, as Sun's JAI (Advanced Imaging API) is specifically designed for image processing. Google is your friend.

People are also doing image processing in Python because it is used by lots of scientists, and image processing is something they do. And of course good old venerable C, which completely lacks all the "++" bits which you seem to think are necessary for writing any type of software.

"Without such important features as operator overloading, constructors, stack-based objects, and references, I really can't take Objective C seriously."

And these are necessary to write software because... Oh, that's right, you need a Turing complete language to write any conceivable piece of software, and what's that? A language can be Turing-complete without having any of these? What strange heresy is this?

"I can't imagine it being used for much mission critical software, that's for sure."

It seems you are incapable of imagining lots of things that exist, but that's your problem. For example, one thing that has escaped your imagination is the fact that C++ is far from being the language du jour for writing mission-critical software: the bulk of what can truly be classified as mission critical (i.e. extremely high reliability stuff where lives are at stake such as medical embedded systems, aerospace, real-time operating system kernels, etc,) are written in C or Ada, usually with a liberal sprinkling of assembler. How can this be when these languages lack all of those amazing features that you insist are necessary for them to be taken seriously? Is it possible that they are missing critical pieces of functionality that can only be implemented by using references to pass parameters? Maybe you should tell them!

Lisp renaissance

[amightywind]

Get off your soapbox. Some of us like languages that actually have syntaxes and can really do low-level work.

It is very likely that the sugary-syntax language you use is glued to the standard C library to meaningfully interact with your system, assuming you are using a *nix system. I cannot vouch for what goes on behind a Windoze machine. You must be a Python programmer. That is ok. It is a lot better than being a VB programmer. But Python has nearly reached the precipice to oblivion that Perl reached a few years back. It is out of vogue. Go back to the classics. Try guile! You can link C libraries in the same way. I do admit I am hoping for a renaissance for the Lisp languages in 2006. As for the elegant and necessary Lisp parentheses, just use Emacs show-paren-mode and you will never be bothered by matching ')', '}' or anything else.

Re:Lisp renaissance

[Eli Gottlieb]

Actually, I tend to use C, C++ (not much), Object Pascal or Lisp as I please. The parenthesis just annoy me because I hate Emacs and refuse to use it.

And a language really doesn't need to have as little syntax as Lisp does in order to be that powerful. Lisp's advantage is that users build their functions on top of primitive functions, but the primitive functions look the same linguistically as the user-defined ones. This contrasts with, say... C++ where a user-defined can overload standard operators, but no new operators can be defined. I estimate that if you added a keyword to make a statement return a value and allowed user-defined operators an Algol-derived language could probably become almost as powerful as Lisp. "Almost" because Lisp's interpreted nature allows it to treat code as data without invoking the compiler.

Re:Downhill at a fast rate

[scotch]

Oh, you slay us. But you fail to address the central premise of his argument. Sure, C++ is not a proper superset of C, but it a practical superset of C. There will be few or no issues with compiling modern ANSI C code as if it were C++. For new projects, there is no issue at all. All things being equal, if you can write C and just use a few of the features of C++, it will likely be worth it to your project. Though I used C for years, when I am forced to use a pure C codebase these days, I feel severely crippled.

Why not typeof ?

[Spy der Mann]

#define foreach(x,it) for(typeof((x).begin()) it = (x).begin();it!=(x).end();++it)

This can be done because typeof is implemented in the GNU C++ extensions, but not in standard C++. Why not begin with a handy feature such as this?

Re:Why not typeof ?

[BobaFett]

decltype keyword, which does essentially what typeof would do, was considered for the addition to the standard. I'm not sure if the fact that Bjarne does not mention it means that it was dropped from the proposed changes or it's still in play.

Why decltype and not typeof, you might ask? Several compilers implemented the typeoff extension, but in a slightly different way (for example, GCC did it so typeof(int&) is int, someone else made a typeof which preserves refs). The Standards Committee just could not "endorse" someone's version of typeof for the fear of offending everybody else who had one, so they chose the "equitable solution". Amazing how otherwise reasonable people can become childish and petty when they form a committee.

This being said, your example can actually be solved with auto, and even easier. But there are cases when full typeof is necessary.

ditch the long long long long void* already please

[Verity_Crux]

Here's the two features I want:

unsigned, signed, signed, etc. The built in types should have size specifiers and all use the same names. The whole thing about incompatible long size is confusing and unnecessary. This also lends itself to hardware programming better. You could have an unsigned (i.e., seven bit number) handled by the compiler just fine by building in checks on the eighth bit of a byte instead of relying on the carry flag. It would be a wee bit slower, but still useful.

The second feature is some fixed data types. fixed would have sixteen bits for the whole number portion and sixteen bits for the decimal portion. unfixed would be an unsigned version of the same thing. Why do we need this? So that I can have a freakin cross-platform video and image library. libjpeg runs faster on my local box than on the $13k SGI box in the lab. Why? A nice fellow wrote the thing in fixed point MMX assembly and the Itanium chips don't have 32bit MMX support so it kicks back to the floating point overload of the DCT function. Shifting would also work directly on these fixed point numbers. I'm also a fan of making it so that shifting a floating point number inc/decs the exponent.

Re:Downhill at a fast rate

[scotch]

Operator overloading is indeed a carnival of confusion that would have been best avoided.

Who are the idiots you work with for whom this is a real issue? Or is it just you? I just don't see this "carnival of confusion" in the professional programming world that uses C++.

Re:Downhill at a fast rate

[Weedlekin]

Indeed: even C code that compiles under C++ can have a subtly different meaning that can bite hard in the form of intermittent bugs that can be extremely difficult to trace. IMO this is actually worse than languages like Java and C#, which are C-like but don't pretend that they are either supersets or "enhanced subsets" of C. It is also the reason why most C programmers use a C compiler rather than a C++ compiler, and also why most commercial C++ setups ship with a C compiler that gets automatically invoked on modules with a ".c" extension.

NB: Objective-C is a true C superset in that it will compile standard C programs just as a C compiler without the "Objective" bits would.

Re:Downhill at a fast rate

[EvilSporkMan]

BTW, when you say "fancy allowing standard operators to be overloaded" I think you mean "overrided". C has overloaded operators (+ is defined for int, char, short, long, float, double, etc). overriding lets you tell the compiler how to do addition for your custom bigint library, or whatever. You can misuse operator overriding, or you can misuse macros, each are there for a purpose, and each get misused by bad programmers.

No, the GP ws perfectly correct - it's called "operator overloading" (see the title of the chapter on operator overloading in Stroustrup's The C++ Programming Language). Amusingly, it just so happens that the word "overload" and its derivatives are themselves overloaded; in C++, overloading refers both to operator overloading and to function overloading, which refers to creating multiple functions with the same name that are distinguished by their parameters (which is what you were thinking of when you made the comment about the + operator, though + really is an operator, not a C++ function).

Re:Make Bjarne leave it alone!

[AuMatar]

Nothing on the scope that C++ is talking. The inline functions is syntactic sugar, we already had macros. Nice syntactic sugar, but still sugar. Complex numbers already existed, there were dozens of libraries that did them and did them well. Read the list of changes for C++, its a major turn in the language.

Well engineered?

[Svartalf]

Well, I wouldn't go so far as saying that C# or Java is more "modern" than C++ (Which is kinda stupid...); but to say that C++ is "well engineered"...

C++ is well engineered in the same sense of PL/I was well engineered- and it's becoming as complex and convoluted.
"Over engineered" would be a better description- and I'm a proponent of the language.

Re:run-time compiling?

[Jedi Alec]

how about being able to read in a string and use that as a variable name?

How about we sacrifice some virgins while we're at it as well? The word evil doesn't even begin to describe this practice, no matter the programming language. Could you give an example of where this might actually be useful?

Re:Downhill at a fast rate

[Chris Burke]

But I see that you *really* meant *pass* by reference, if you want to ensure that the function can have no side effects, cast the parameter to const. Otherwise, if you expect to write software without knowing what the functions do, you should not be writing software.

That's fine and dandy, but the fact remains that pass by reference makes it more difficult to understand code. There is no syntax at the place the function is called that indicates that it is pass by pointer (which is what pass by reference really is in C++) instead of by value, and this is by no means an insignificant difference. Thus you either have to check the prototypes or possibly miss an important distinction (and have it bite you in the ass later), when using pointer syntax would have made things clear from the get-go.

Bjarne put references into C++ in order to support overloaded operators for complex objects that use the same syntax as operators for basic types. This is pretty much the only reason you should use it (ask Bjarne). In almost every other situation, pointers are equally useful and more clear to someone reading your code and thus preferrable.

Passing references to functions is one of those things that comes from people gleefully trying to use every new feature, like making every member function of a class virtual even though it isn't needed. Thankfully it doesn't tank performance like using virtual everywhere.

P.S. Making a version of an operator/function that works with your object type is called 'overloading'. Making a new version of an operator/function with the same types as an existing one is called 'overriding'. But that's just me being pedantic.

Re:Adding new features is not always an improvemen

[Weedlekin]

"Your DLL problems are a problem of Windows, not of C++"

To be fair, it can also occur on UNIX (a catch-all category which should be read as including Linux) with shared objects. But you are right in saying that this is not a C++ problem as such: shared libraries / DLLs are features of particular OS families that should not be specifically supported by a general-purpose programming language like C++.

NB: I share the general consensus that C++' handling of modularity leaves a lot to be desired. In particular, the loose coupling between headers and source modules together with the ability of any header to redefine the values of constants etc. imported from prior headers is both a potential and actual source of problems. I can understand C++ _supporting this_ for compatibility with C, but Bjarn should IMO have added another better system for use with new C++ code. If something like this had been done properly from the beginning, then they wouldn't have had to retro-fit name-spaces at a later date, because the module name could have also served as a name-space identifier, as was the case with Pascal and Modula-2, later borrowed by more modern languages such as Python and Java.

Instead of more features...

[dingbatdr]

Instead of tacking more features like threads onto an already bloated language, how about making some options that would make C++ codes more debuggable. I would love to have a compiler option that forces strong typing ala Ada in my codes. No automatic type conversions. No default constructors or operators to my classes being built. I would also love a sane I/O syntax. And while you are at it, please simplify the STL API. I know I am just being cranky but I would be surprised if there are a dozen people on the planet that understand the complete C++ standard as it is.

Re:Instead of more features...

[SwashbucklingCowboy]

Most compilers emit warnings for such issues, most compilers also provide a way to treat warnings as errors.

Is anyone else extremely excited about this?

[jinxidoru]

I just read through the article and I must say that I am excited. The changes that they are proposing are so awesome. Each one is something that has frustrated me that C++ does not already do. Must of the past changes of C++ have made it much more complicated. They were good changes, but they did make the language more complicated. Apart from concepts, these proposed changes seem to make things simpler. I especially like the "auto" type. What a brilliantly wonderful idea. This is something that I have longed for. I love it.

Re:Or if you want those features NOW...

[eluusive]

Parent is correct, D is quickly becoming a very robust programming language specification. It still has some rough edges though. Even if the bugs and missing features preclude you from using it right now, at least read the specification thoroughly. You'll be pleasantly surprised, and want to check up on it on a regular basis.

You can now with boost

[Anonymous Coward]

Using the assignment library this is easy.

Here's an example from :

http://boost.org/libs/assign/doc/#operator+=

#include // for 'operator+=()'
using namespace std;
using namespace boost::assign; // bring 'operator+=()' into scope

{
        vector values;
        values += 1,2,3,4,5,6,7,8,9; // insert values at the end of the container
}

This, it seems, is not the way it will be implemented in the new C++. But lots of other stuff mentioned is already in boost (smart pointers, threads).

Re:Adding new features is not always an improvemen

[multipartmixed]

That said, if you're using gcc and GNU make, you may prefer the following:

PREFIX = /usr/local/strange_module-2.3.7
CPPFLAGS += -I$(PREFIX)/include
LDFLAGS += -L$(PREFIX)/lib -R$(PREFIX)/lib

Most people forget the -R and assume that ${LD_LIBRARY_PATH} will be set appropriately by the users. IMHO, that's just dumb.

Of course, the example above is not very good if you're also building the strange module's library at the same time as the executable. But I'll leave *that* solution as an EFTS.

Re:Downhill at a fast rate

[Mr. McGibby]

Bjarne put references into C++ in order to support overloaded operators for complex objects that use the same syntax as operators for basic types. This is pretty much the only reason you should use it (ask Bjarne). In almost every other situation, pointers are equally useful and more clear to someone reading your code and thus preferrable.

Well, I'm not beholden to Bjarne to be the final answer. Just because he designed the language, doesn't mean he understands everything about it. Like any feature in C++, when improperly used, it produces poor code. I really don't care if the parameter passing mechanism is known at the call point. If I know what the function does (which is the first thing you *should* know), then I automatically understand how things are passed around. When using pointers, the NULL issue is rarely brought up because it's hard to deal with. With references, you don't have this problem (ignoring NULL references since they're hard to obtain in the first place).

Re:Heh

[Peter La Casse]

Without such important features as operator overloading, constructors, stack-based objects, and references, I really can't take Objective C seriously. I can't imagine it being used for much mission critical software, that's for sure.

How much is "much"? C doesn't have all of those important features, yet it is the backbone of much mission critical software. Maybe by "take seriously" you meant "consider optimal" and by "used" you meant "preferred"?

Re:run-time compiling?

[multipartmixed]

> Could you give an example of where this might actually be useful?

I use it in both shell and javascript (njs interpreter) to save and restore state. State is stored in a text file, which, when executed by the running program, magically brings back the variables.

Of course, this is patently evil, and would never see the light of day in production code.

In a similarly evil vein, I have been known to grab a CGI query string in shell, split it across the ampersands, and eval the resulting data as code. This causes the CGI form variables to become shell variables, and your shell-script CGI can then merrily truck along and use them as it sees fit.

I'm not sure which is more evil. They are both useful tricks for writing VERY quick and VERY dirty code, but making them robust enough to expose to users would completely negate any benefits they had. If it was even possible.

Re:run-time compiling?

[Jedi Alec]

ye gods. I'll actually admit to having done so in mIRC, which is already plenty evil all by itself, both as a program and in its scripting abilities, but what you're describing is of such an evil nature that it would require at least 4 superheroes to squash it. Bring on the Fantastic 4mat!

All languages evolve towards Lisp

[Julian Morrison]

...C++ is doing it via first evolving into Java 1.0.

So slowly C++ will become Ada?

[ChrisA90278]

So slowly C++ will become Ada? Are there really any substanive differences in Ada and C++0X other then using "{ }" vs. using "begin end" and simalar trivia? Ada, BTW is still very much in use but that use is restrited to a small range of applications. mostly to applications where people will die if there is a software bug like airplane flight control, guidance systems for cruise missles, nuclear power plants and so on. Not many web browsers are written in Ada. I think what kiled Ada for general use is a lack of a huge set of _standard_ libraries. C, C++ and Java and the other hand are populare because of thier libraries

Re:So slowly C++ will become Ada?

[Eli Gottlieb]

So it's the Revenge of the Bondage and Discipline Languages! Actually, I'm still waiting for the rest of the world to realize that clean, bug-discouraging languages are better than others which have no substantial difference from the B&D languages except that they allow you to shoot yourself in the head.

Re:So slowly C++ will become Ada?

[Jerry Coffin]

So slowly C++ will become Ada? Are there really any substanive differences in Ada and C++0X other then using "{ }" vs. using "begin end" and simalar trivia?

C++ templates provide capabilities that are difficult (if even possible) to match with Ada generics. Look through the Boost library at things like bind and lambda, and try to figure out how to do similar things with Ada. I wouldn't say they're impossible, but at best they're considerably more difficult.

Re:Downhill at a fast rate

[J.R. Random]

I still think C++ was invented as a joke. I mean, fancy allowing standard operators to be overloaded. And reference variables? I now have to carefully examine very function prototype when I need to know if a function call might have side effects.

And now garbage collection? That just a feature to fix poorly written code.

When I found the C language, I stopped looking. Ah well.

Suppose I see this call in C:

foobar(&a, &b, &c)

The standard way to pass a large structure in C is by its address, rather than copying the whole thing, whether or not the structure is going to be modified inside the routine. So here I know that a, b, and c might be modified, but then again, they might not. How is this any better than C++? After all, every reference argument in C++ code becomes a pointer argument in the equivalent C code. At least with C++ I have the option of making a reference "const".

Overloading operators allows for useful syntactic sugar -- that's why the C++ Complex class is so much more pleasant to use than the Java Complex class. It can of course be abused. So what? Any language feature can be abused.

As for gargage collection, 95% of the time is isn't needed -- the simple paradigm of allocating storage in constructors and deallocating in destructors does what you need. But for the other 5%, when you have no way to know when the lifetime of an object is over, there's just no good substitute for a garbage collection system. I don't know what the C++ garbage collector will look like, but if it allows some things to be garbage collected and others not it will be a very useful addition to the language while not forcing every damn object to be garbage collected the way Java does.

More info on the "future" of C++

[Maskull]

If you're interested in reading about possible future extensions to C++, check out the official home of the C++ Standards Committee. The papers page links to all the "mailings" containing every paper submitted to the committee, as well as draft standards and such. There's a lot of interesting ideas floating around: true "metacode" macros (like Lisp), flexible initialization (so that the {...} initializer could be "overloaded" on your own classes), automatic type deduction, etc.

We suffer from the poor quality of leadership.

[Futurepower(R)]

I agree.

Bjarne Stroustrup seems to be the only person who has the mental capacity to guide the development of C++. However, he is taking a very leisurely view of improving the language, in my opinion. We need those improvements 8 years ago.

Java is attractive, but writing in it means getting involved with Sun's mismanagement, which is so bad it may eventually kill the language.

C# is attractive, but using it means being under the influence of Microsoft, a company which is often adversarial toward its customers.

As in other fields, we suffer greatly because of the poor quality of our leadership.

Re:We suffer from the poor quality of leadership.

[birder]

Be one of the few, the proud, the users of Borland Development Studio 2006. Delphi, C, C++, and C# programming languages all in one IDE. Pick your poison daily!

Re:We suffer from the poor quality of leadership.

[Pxtl]

Amen. two-thousand-frickin'-9 is their _earliest_ estimate for a standard? I want this shit yesterday.

The apalling pace of development and some brain-dead holes in the standard libs are it's big flaws. The language itself is wonderful, but the standard library has some massive problems. For example, the string stream system in C++ was just dumb, and the fact that there was no mechanism to use STL containers to hold any auto_ptr-like mechanism was just ludicrous. I didn't expect the modern idea of strings-as-immutables-for-fast-hashing to hit them, but a the string stream approach was ridiculously cumbersome and didn't even have efficiency as an excuse. Plus, it provided the prototypical example of operator overloading abuse that became the hallmark embarassment of the language.

And as for the "using" keyword for currying templates - make it typedef, and don't give me any excuses for why typedef doesn't work for such things.

Re:We suffer from the poor quality of leadership.

[Old Wolf]

For example, the string stream system in C++ was just dumb;
the string stream approach was ridiculously cumbersome.
Plus, it provided the prototypical example of operator overloading abuse

Stringstreams don't overload any operators that I/O streams don't.
It is exactly same as a file stream except that it reads and writes
to a memory buffer instead of to a file. Then you can access that
memory buffer as a string at any time.

the fact that there was no mechanism to use STL containers to hold any auto_ptr-like mechanism was just ludicrous.

Huh? You can put auto_ptr-like mechanisms in STL containers.
In fact people use boost::shared_ptr in vectors regularly, to name but one.

(But not auto_ptr itself, which is a design flaw due to it being
rushed in to the last standard without being fully debated, which
is something you are in favour of it seems).

Re:We suffer from the poor quality of leadership.

[Pxtl]

Haven't coded in C++ in a while - my complaint about the syntax was for streams in general, not just the stringstream. And the stringstream is a painful approach to string manipulation compared to other languages - dispite the advantages of having a unified syntax of having strings treated just like i/o streams. A true string library was an annoying omission.

As for my auto_ptr complatint, what I meant was that there was no mechanism in standard C++ to transfer ownership of an object to a container without copying the object. This copy was an unnecessary overhead. auto_ptr didn't work, and if you stuck a conventional pointer into a container, you'd have to delete the object manually.

Re:We suffer from the poor quality of leadership.

[Old Wolf]

As for my auto_ptr complatint, what I meant was that there was no mechanism in standard C++ to transfer ownership of an object to a container without copying the object.

This is called "move semantics" and is part of the plan for C++0x (although Bjarne's article didn't make mention of it). See http://www.open-std.org/jtc1/sc22/wg21/docs/papers /2002/n1377.htm

Re:We suffer from the poor quality of leadership.

[Anonymous Brave Guy]

Stringstreams don't overload any operators that I/O streams don't.

But they suffer from the same fundamental architectural flaw in both cases: they force you to write what should be data (the order and formatting of substituted elements in a string) as code. C did better with printf a generation ago, and almost every other half-decent text-processing language I can think of uses some sort of template string and then substitutes, with the template string encoding the order of elements and, often, any formatting requirements. This sort of thing is of vital importance when you're working on internationalised applications, but for some reason I've never understood, C++'s I/O streams and locale support don't seem to have noticed.

In a sense, this example demonstrates both the best and the worst aspect of C++'s approach to libraries: what it has as standard seems to be some sort of designed-by-committee mess that's unusable in a professional environment, but on the other hand professionals are always free to completely disregard it without cost, and to write or bring in an alternative text processing library instead.

Re:Downhill at a fast rate

[mad.frog]

There is no syntax at the place the function is called that indicates that it is pass by pointer

Not necessarily the case with explicit pass-by-pointer either. e.g.

        int foo = 1;
        int* bar = // a few dozen lines of code here...
        do_something(foo); // so, is this pass by value or by pointer?

Bjarne put references into C++ in order to support overloaded operators for complex objects that use the same syntax as operators for basic types. This is pretty much the only reason you should use it

I strenuously disagree! Passing a parm by reference, rather than pointer, makes it well-nigh impossible for the parm to be null. (If you play truly evil casting games you can manage to make it happen, but it really requires a deliberate attempt.) Our coding guidelines specify that any parms that can't legally be null should be passed by ref (or const-ref, if possible). No more sanity-checking-for-null at the entry to the routine...

In point of fact, I find this the single best use of references -- since I consider operator overloading something to be avoided in most cases. (Overloading operator* to do matrix multiplication -- sure, fine. Overloading the left-shift operator to do stream I/O.... wtf?)

Re:objective-c make it better

[mad.frog]

What are you smoking?

Objective-C has its pros and cons (which I don't want to get into here), but advanced template support is NOT among them.

Reasons to hard-code data structures in C++

[dsplat]

Assuming of course that I want to put a lot of complex data into my code rather than load it from XML or a database, I would seriously consider creating the XML files anyway. That would make switching to loading XML at runtime later a bit easier if I had a change of heart. Then I'd write some XLST to generate the C++ initialization from the XML source. Not that I expect any of this to change anyone's opinion on whether this is a shortcoming of C++ or whether it should be considered as a possible new feature.

Someone else asked why you would want to hard-code complex data. I can think of a couple of reasons. Sometimes your data is essentially static, but isn't composed completely of built-in types. State tables are a rich source of examples. In an embedded system, you may be hard-coding all sorts of things that could be expressed in a database or XML, but you can't afford the storage for the libraries and the database. Finally, if you need to write a small program that loads fast to do a quick job, you don't want the program to load and then have it read it's configuration from somewhere if that configuration is static.

Re:Woo

[CountBrass]

Yes because the thing that C++ really lacks is features bloat.

My wish-list for c++ is D!

[WalterBright]

I got tired of complaining about C++, and decided to do something about it. The result is the D programming language.

Re:Sigh

[Hosiah]

*drooling* awwwwww, hookay!

Re:Downhill at a fast rate

[Chris Burke]

int foo = 1;
int* bar = // a few dozen lines of code here...
do_something(foo); // so, is this pass by value or by pointer?

This case is perfectly clear: foo is passed by value. If we can assume do_something(foo) takes an int instead of an int&. I'd have to know that to say for sure, which is exactly the problem with references.
I'm not sure that example worked as you wanted. Did you mean to pass bar or something (in which case it would still be clear, bar is passed by value, what bar is pointing to is passed by pointer)?

I strenuously disagree! Passing a parm by reference, rather than pointer, makes it well-nigh impossible for the parm to be null. <snip> No more sanity-checking-for-null at the entry to the routine...

But it doesn't make it nigh impossible for the object to be invalid. Checking for input validity is not something you can skip no matter your passing method. And checking for non null is simple:
void pointerPassing(int* foo) {
        assert(foo); //...

In point of fact, I find this the single best use of references

If the best use for references is to avoid a one line check at the expense of making the calling code more difficult to understand, then I'd say there's no use for references at all.

since I consider operator overloading something to be avoided in most cases. (Overloading operator* to do matrix multiplication -- sure, fine. Overloading the left-shift operator to do stream I/O.... wtf?)

The rule I use, which I've heard Bjarne himself utter while simultaneously destroying with the stream operators, is that the operator should have an obvious meaning analagous to the built-in operator. E.g. adding strings and complex numbers both have obvious expected meanings. Writing to a stream is nothing like shifting, so yeah. That's why I still use printf(). :)

But sometimes operators do make sense (e.g. a 'uint128_t' class that is supposed to provide the same functionality as the uint64_t type) and for that you need references.

Re:Adding new features is not always an improvemen

[OOGG_THE_CAVEMAN]

preprocessor metaprogramming. It's a very powerful tool

"powerful" in the sense of "as powerful as a Turing machine", I suppose.

Template/preprocessor metaprogramming is a horrendous hack. It basically happened by accident because the addition of templates "upgraded" the compiler to have a Turing-complete language embedded within it. Not that anyone realized this while they were actually *designing* templates.

Well-designed "metaprogramming" would use, get this, a programming language, with sane syntax, not the mess that template syntax is; C++ was already so crowded with line-noise operators, they had to separate less-than signs with spaces. It would also have real programming semantics, instead of hijacking the type system to provide flow-control.

Lisp basically got this right, by allowing meta-programming to use the same language and operators that the underlying language has.

Re:Adding new features is not always an improvemen

[Ed Avis]

The mere existence of the preprocessor isn't such a problem. After all, no matter how horrible it is, adding an bad feature to a language only harms people stupid enough to use it. So while I don't advocate stuffing new features into a language, I don't think you can argue 'language X sucks because it includes feature Y'. Only, 'language X is ugly' or perhaps 'feature Y creeps up on you and stabs you in the back when you don't realize you are using it, and therefore language X is dangerous for beginners'.

The problem is that you are forced to use textual inclusion to build pretty much any project bigger than a single source file. There isn't a real module system as in many more 'academic' languages like Modula-2. What I mean is: suppose you would like to use libpng in your program. So you #include the libpng headers. Purely as an internal implementation detail, libpng happens to use zlib. Its header files #include some of the zlib things, which means that zlib is now dragged in at the top level even though you did not ask for it. Ideally, the zlib functions should be available only in the libpng source files that asked for them, and if you separately wanted to use zlib (perhaps a different version) in the main project you should be able to do so without needing to know or care about whether libpng also uses it.

Also as the UNIX-HATERS Handbook notes:

The worst problem with the C preprocessor is that it locks the Unix world into the text-file prison and throws away the key. It is virtually impossible to usefully store C source code in any form other than linear text files. Why? Because it is all but impossible to parse unpreprocessed C code.

In other words it is very hard to write automated code browsing tools or refactoring tools for C and C++ because you can't parse a given source file without textually expanding it (and thus dragging in megabytes of headers). Things like etags are only approximations. I guess I'm contradicting what I said earlier: the mere existence of the preprocessor is bad, because it makes life difficult for IDEs and code browser tools. There are some good points to the preprocessor, but in this day and age when any compiler can do inlining, not many.

Re:C++0x misses this feature

[Duhavid]

You cant find the discpline to write simple code within?
You must have it imposed from without?

Perhaps it is not the tools that need changing.

Re:Downhill at a fast rate

[Chris Burke]

I really don't care if the parameter passing mechanism is known at the call point.

Then you don't care about writing maintainable code. That's fine, but having had to frequently maintain and modify code written by others I do care.

If I know what the function does (which is the first thing you *should* know), then I automatically understand how things are passed around.

Do you use expressive variable and function names? Or is your code riddled with X(a) + Y(b) When using pointers, the NULL issue is rarely brought up because it's hard to deal with. With references, you don't have this problem (ignoring NULL references since they're hard to obtain in the first place).

void someFunc(int* foo) {
        assert(foo); // How is this difficult? This argument is a non-starter.

Re:Downhill at a fast rate

[mad.frog]

Did you mean to pass bar or something (in which case it would still be clear, bar is passed by value, what bar is pointing to is passed by pointer)?

Yes, I mistyped :-(

And yes, it is clear that bar is passed by value, but the fact that your local value can be modified is not clear.

But it doesn't make it nigh impossible for the object to be invalid

No, but is a particularly common (and fatal!) case that can be eliminated at compile-time rather than caught at runtime (hopefully in testing, rather than by the customer...)

Borland was scary because of bad management.

[Futurepower(R)]

The Borland of today seems better than the Borland of before, but I got scared by Borland's previous bad management.

Re:Downhill at a fast rate

[Chris Burke]

Geeze, I need to rember to use preview. /smacks self with the clue stick.

Well, I'm not beholden to Bjarne to be the final answer.

Of course you're not, but he does have a good grasp on the language. And he certainly knows why he put something into the language.

I really don't care if the parameter passing mechanism is known at the call point.

Then you don't care about writing maintainable code. That's fine, but having had to frequently maintain and modify code written by others I do care.

If I know what the function does (which is the first thing you *should* know), then I automatically understand how things are passed around.

Do you use expressive variable and function names? Or is your code riddled with X(a) + Y(b) < zz ? After all, the first thing someone should do is look up what X, Y, a, b, and zz are, and then everything will be clear from then on! Or do you helpfully clue people in to what all these things are and what they are for by giving them descriptive names?

You have to look at this from the perspective of someone other than you, the original author of the code. They might be your successor after you leave for greener pastures, or just someone who needs to modify the code without your personal guidance. They probably aren't starting by scrutinizing every function prototype, they're probably trying to understand a particular block of code they care about which calls this function. Yes, they can and should understand what the function does but having the usage of the function implied by it's name, it's parameters, and the way those parameters are used at the calling place makes the code easier to understand, both at initial bring up and when coming back to it in the future.

Pass by pointer makes for easier to understand code and if you care about that is preferrable. If optimizing ease of understanding isn't your goal, that's fine. Not everyone needs to care about that.

When using pointers, the NULL issue is rarely brought up because it's hard to deal with. With references, you don't have this problem (ignoring NULL references since they're hard to obtain in the first place).

void someFunc(int* foo) {
        assert(foo); // How is this difficult? This argument is a non-starter.

sigh...

[IntergalacticWalrus]

KDE is open source. All KDE libraries are either LGPL or BSD. The Free edition of Qt is GPL/QPL. All of those previously-mentioned licenses are OSI-approved.

Please keep your stupid anti-KDE FUD elsewhere.

Re:Downhill at a fast rate

[EvanED]

Not a joke, a research project. Thus, Stroustrup's willingness to include any "feature" that someone suggests: "Oh sure, we'll put that in and see how it works out."

Neither of these statements is true. He was at Bell Labs, but in no ways did he intend C++ to be a research project. He wrote it to solve real-world programming problems, to make real-world programming easier. How much he succeeded you can argue, but he did intend for it to become as widly used as it is.

As to your second point, follow the other fellow's advice and read D&E sometime.

Lipstick

[iliketrash]

I can't believe they're putting still more lipstick on this pig.

Re:Adding new features is not always an improvemen

[scoopr]

What you have just described is Apple's Frameworks This might work on other systems with gcc aswell. Since I got my first iBook and learned about frameworks, I've pondered, why the heck doesn't any of the linux distributions use them.

Re:Downhill at a fast rate

[EvanED]

That's fine and dandy, but the fact remains that pass by reference makes it more difficult to understand code. There is no syntax at the place the function is called that indicates that it is pass by pointer (which is what pass by reference really is in C++) instead of by value, and this is by no means an insignificant difference.

I'll agree to some extent, but I have two things that I feel need to be added:

1. Pass by reference doesn't make it difficult to understand code, the lack of syntax at the call site does. For instance, C# allows reference parameters, but you need to specify that at the call site too.

2. C's style of things hardly makes things any better. If I have a function foo(some struct* x), why am I passing x by pointer? Is it just to save time and duplicating x on the stack, or is it because foo is actually going to change it? You can't tell that from looking at the call site either, even if C had const or in the extensions where it does. My experience is that most of the time most objects are passed by reference or pointer. That means that loss of readability from reference parameters in C++ really only show up when you're dealing with primitive types.

Re:Downhill at a fast rate

[Mr. McGibby]

And he certainly knows why he put something into the language.

Again, I don't care why he put it in the language. I care about how it can be best used in reality. I don't think that current use of templates was envisioned when it was designed, but it seemed like a good idea, so it was added. Your original statement used Bjarne's approval as proof of correctness. That's the false logic that I disagree with. Sure, he has a lot of good ideas. That doesn't mean he's right, not even close.

Pass by pointer makes for easier to understand code

Your entire argument logically follows from this statement. However, I don't agree with this statement, so I don't agree with the rest of your argument.

I don't think it makes for easier to understand code. The presence of pass-by-reference should be obvious from the name of the function, not the requirement to pass a pointer.

Do you use expressive variable and function names? Or is your code riddled with X(a) + Y(b) zz ? After all, the first thing someone should do is look up what X, Y, a, b, and zz are, and then everything will be clear from then on! Or do you helpfully clue people in to what all these things are and what they are for by giving them descriptive names?

Don't be ridiculous. Of course I use descriptive variable names. That's why I don't need to use pointers to pass-by-reference. Because my function names are good. And no, I don't expect my maintainers to understand every last function before they read my code. But I do expect them to go look at the header if they want any more than a basic understanding of what the function does. I don't include comments in my function names, I put them in the header, where they belong.

Yes, they can and should understand what the function does but having the usage of the function implied by it's name, it's parameters, and the way those parameters are used at the calling place makes the code easier to understand, both at initial bring up and when coming back to it in the future.

Ok, so your logic is that the more information is included at the call point, the better. Ok, then why don't we include all kinds of other information there too. How about including a cast to the true parameter type so that I know the true type of each of the parameters? How about adding a little comment for each parameter that gives the name of the parameter local to the function? Or any number of things that might help our plucky maintainer? Because it's all in the header file.

void someFunc(int* foo) {
                assert(foo); // How is this difficult? This argument is a non-starter.

Because if I use pass by reference, I don't need to do it at all. I don't need to even worry about the assert firing in all those rare cases I didn't think about, or know about.

Re:Downhill at a fast rate

[Mr. McGibby]

I've heard Bjarne himself utter

This is religion, not logic.

Re:run-time compiling?

[Eli Gottlieb]

There is Lisp, and there are lower-level languages used for systems programming. That and maybe something for games, multimedia and other performance-critical apps.

Re:Downhill at a fast rate

[EvanED]

C's style of things hardly makes things any better. If I have a function foo(some struct* x), why am I passing x by pointer? Is it just to save time and duplicating x on the stack, or is it because foo is actually going to change it? You can't tell that from looking at the call site either, even if C had const or in the extensions where it does. My experience is that most of the time most objects are passed by reference or pointer. That means that loss of readability from reference parameters in C++ really only show up when you're dealing with primitive types.

Not only that, but I just thought of something else:

If you don't have const in C, the situation is actually better with C++, references, and const, because the almost universal idiom is to pass by const reference to save space. If you see a reference parameter that isn't const, it's at least somewhat safe to assume it will be changed. (The other main possibility is that people were lazy with classes and didn't make them const correct, forcing them to use non constants.) You can tell if a parameter is const by the function signature. Not as good as the call site, but still better than in C where you can only tell from the method implementation (or documentation) that a parameter isn't changed.

Committee doesn't want to add features!!

[copenja]

The goal of C++0x is not to add a bunch of new features to the language.
Two of the driving goals of the committee are to prefer library extension
to language extension and to focus on simplifying current features.

Remeber that the standard library specification is a major part of
the standard. And standard library extensions are very different than
language extensions.

The actual "new features" that the Bjarne was discussing focus on
simplifying and streamlining current features and syntax. For example,
while template typedefs and auto iterator types are language
extensions their goal is to simplify a current language feature: templates.

The possible exception to this is the addition of "concepts". However,
information about the design of "concepts" is so sparse in that article
that it is difficult to form an opinion.

Jake

Too Slow

[oldCoder]

The development of the language is too slow. People and machines are learning and growing faster than that. I don't much like C++, I think it's complexity is a problem. A lot of learning to program C++ is learning to work around the problems of the language, not in solving the problem at hand.

Spoken (Natural) languages are extremely complex and extremely useful. Programming languages can profitably be just as complex if they were good enough to last for as many decades as we use natural languages! If you're going to learn a new language every 5 years it constrains how complex that language can be. If you're going to use it for 50 years it's a different story. C++ isn't good enough to use for enough years to be worth the complexity.

Nevertheless, the choice of programming languages should not determine whether the app is garbage-collected or not. Although that will greatly impact libraries.

C++ is a research language that should be replaced by something that is not afraid to be incompatible with it. Java and "D" are nice tries but tie garbage collection to the language. C# is disappointing considering the size of the organization behind it. And is also tied to GC.

Software systems often contain components that need to be coded close to the machine to obtain maximum performance or flexibility or power. At least the OS. Those same software systems always contains portions of glue and convenience code that does not need to be coded close to the machine and should be coded at as high a level as possible. The challenge to language designers is to create a programming system that spans as great a height as possible without forcing the coder to migrate to different syntaxes and toolsets. C++ and OO are an attempt but don't really make it.

And Java won...

[trollable]

// 6 lines in Java, not sure if the code does exactly the same

import javax.swing.*;

public class F
{
        public static void main (String[] _args)
        {
                JDialog form = new JDialog ();
                form.add (new JButton ("Hello, World!"));
                form.show();
        }
}

Re:Heh

[bored]

Stroustrup lives in a fantasy world where the only reason C++ isn't as fast as C, or produce as small of assembly as C is because of the compilers- which he conveniently disavowes responsibility for.

Or is it you? Show me a piece of code that runs faster with a C compiler than the same piece of code with a C++ compiler from the same manufacture. Maybe you don't understand that if you write code that doesn't use the "slow" features of C++ its the same speed as C. Even then when you use virtual methods, compare them to the performace you get with structures of function pointers in C. Then there are things that acually make C++ faster than C, like for example templates and exceptions. Look up template meta programming on google if you don't believe me. I know of at least 1 compiler that accually generates faster code for the C++ virtual methods can get generated by the C function pointers. I think at this point most of the C compilers out there are acually just C++ compilers with a slightly diffrent parser running on the frontend.

I don't think C++ is now, or ever was (or with the way these "extensions" keep showing up) - or ever will be suitable for Systems Programming.

This is complete and utter BS, I have written a number of drivers using C++ in enviroments that didn't officially support C++. I have also written a microkernel that runs on a number of embedded ARMs in C++. C++ is a wonderful systems programming language, I no longer have to manage function tables, deal with a lot of error handing etc. System calls are a natural place to create a "transaction" that can be aborted by an exception, as are SLIH's the list goes on. I'm not the only one, a number of other people have C++ based kernels and drivers. Writting an OO kernel also encourages you to have interfaces between the diffrent subsystems, this is something linux strongly needs and doesn't have.

cout

cout is in my opinion stupid, and I don't use it, so I don't care if its slow (plus its not internationalized, and hard to convert, unlike the printf family). Plus most people don't understand that it tends to creates temp objects all over the place, and that is what is slow not cout.(this reminds me of Java, which isn't always slow, but it encourages practices that are)

Because the C++ programmer infrequently can understand what his runtime is doing- and is not encouraged to know the interface by which C++ does it's magic (because nobody knows- they're still trying to figure out how to make some C++ magic work in a way that isn't slow)- a C++ systems programmer needs a C++ runtime. Nobody has one in systems-space, so the C++ programmer (which isn't a programmer of C++) needs to write it.

This is utter BS too, it isn't any harder than C, in fact its almost the same as C except for virtual methods, RTTI, and exceptions. The rest is basically all compile time. RTTI is off by default on most compilers because it can slow things down, exceptions and virtual methods usually only take a little while to understand how they work with a given compiler. If its not documented then a few minuits in the RTI and stepping through the call or excption with an assembly debugger should make it perfectly clear. In fact as part of using C++ in a kernel mode enviroment I have implemented a number of C++ startup and basic support libraries, the biggest one was probably 200 lines of code (because you can't include the full C++ or for that matter C runtime for usermode, with C that code is usually already in the kernel so you don't need to generate it again). Mostly it was simply changes like overridding global new and making it call the kernel allocator, setting up the module/driver/kernel load routine to call the constructors/destructors for global objects, and other really simple things like that.

Re:Downhill at a fast rate

[jcr]

All things being equal, if you can write C and just use a few of the features of C++, it will likely be worth it to your project.

All things are not equal of course, and the use of C++ tends to lead to unmanageable complexity, as soon as you get the first coder on the project who's enamored of such misfeatures as templates or operator overloading.

-jcr

Re:Downhill at a fast rate

[Old Wolf]

I realise this is a joke, but don't you have to boot the kernel before you can even access the /dev file system?

C++0x

[c0d3h4x0r]

Great. Just what we need. A language that looks like leet-speek for "cocks".

Re:Downhill at a fast rate

[Old Wolf]

Yes, "overriding" is only used when talking about polymorphic (virtual) functions in derived classes. The function in the derived class overrides the one in the base class.

in C++, overloading refers both to operator overloading and to function overloading, (which is what you were thinking of when you made the comment about the + operator, though + really is an operator, not a C++ function).

There is no semantic difference between a function and an operator that operates on at least one user-defined type. The "function" uses function-call syntax and the "operator" uses infix syntax.
If foo is a user-defined type, then (foo + bar) is entirely the same as operator+(foo, bar) . In fact you can even use the latter form if you want (although that kind of defeats the purpose of operator "overloading").

Re:Downhill at a fast rate

[dkf]

Not as good as the call site, but still better than in C where you can only tell from the method implementation (or documentation) that a parameter isn't changed.

That's not actually true; you're just talking about C code where the author has left out some of the 'const's they could have used. (Of course, given that both C and C++ can cast things away anyway, you're still actually stuck with the source/docs for the information. Neither language promises that no non-type-safe casts can occur.)

Needless twiddling fixing the wrong problem

[jamie(really)]

The problems that I need to solve will not be solved faster by "where" specifications or "using" shorthands. They will be solved by many, many iterations of the problem code, and this requires fast compile and link times - by which I mean near instantaneous.

I've been programming C++ professionally for 10+ years now in a near-real time field. A few years ago I started using C# for offline things (e.g. tools), and most recently, a domain-specific language for large chunks of the runtime. Some of our team uses C++, some use the DSL. The C++ guys are orders of magnitudes slower to produce results. The primary problem is compile and link time. Getting thousands of C++ files to compile quickly is a fulltime job in itself, and requires thought from every programmer all the time not to #include absolutely everything. (Feel free to respond with "try this!", but I probably have). C#, Java and Python are near instantaneous, and do not require time twiddling includes or forward declarations. If the committee could organize compiler developers to progress C++ away from #include files and towards live code databases (or whatever is required) we will be much better served.

excellent writeup

[sentientbrendan]

This sumarizes most of the problems I've seen in C++. Many people seem to be under the impression that because C++ is widely used, that it is a good language, or at least well adapted to the tasks it is used for. In reality, of the many many languages I've used, it is one of the most poorly put together and your writeup sumarizes why that is.

I'd like to add why I believe that C++ *is* so widely used.
1. easy access to C libraries. all the critical libraries are written in C, so there's no need to do language bindings (although wrapping some constructs in a class is still smart).
2. momentum. C++ seems/seemed like the natural next step to the many many C programmers out there. Businesses want to be able to hire from a large pool of talent. Also, C is pretty nice as far as portable assembly languages go, and so programmers who developed an afinity for C tend to assume that C++ will be just as nice to work with.
3. templates. templates are a really horribly implemented in C++, really just a glorified macro, but they are still extremely powerful and not long ago they were a feature that other mainstream languages lacked. Now virtually every language has a better implemented Generics. C#'s are pretty nice. See Ocaml or SML for a language with REALLY nice generics.
4. the belief that C++ is fast. As far as *compiled* languages go... not really. C++ may stack up well against Python and Java, but neither of these languages were designed to be compiled directly to machine code (although hacks do exist...). However, C is generally considered to be faster than C++, and Ocaml (a much higher level language which implements garbage collection) is about the same, maybe a little faster. One reason for this is that C++ tends to suffer from code bloat, which causes cache misses, which majorly slows down modern hardware. The code bloat happens because C++ tends to over-inline, any member functions in a header are automatically inlined, and because instatiations of templates are often duplicated.

One feature that would be nice to bring along from C++ to newer and better languages is easy bindings to C. If this happened, probably the largest real reason to use C++ would disappear. Here's how I'd do it if I were adding this feature to language X.
1. Define what primitive types in X are equivalent to what primitive types in C. Define a special syntax for accessing non-garbage collected C structures and pointers (similar to what C# does with com objects).
2. Make the compiler understand how to read function prototypes and type definitions out of C header files. Treat a C header file like a module in language X (assuming X is statically typed and has something like modules in C/Python/Sml/Ocaml or namespaces in C++/Java/C#). Now C functions can be called as naturally from language X as from C.

Re:C++0x misses this feature

[JebusIsLord]

Ever work on a development team? You have to impose coding standards, especially with a rediculous language like C++, because not everyone will code to the same standards.

You're right though, if working as an individual, you should be able to write clean C++ using a subset of the complete language.

The D language

[Anonymous Brave Guy]

To me, D has surfaced to become what I always thought C++ should have been.

Diffr'nt strokes and all that; to me, the design of D is practically a bullet point list of ways to undo the things that Stroustrup and co. understood and got right but Java and friends got wrong. The design gives up most of the flexibility and power, in exchange for what? A garbage collector and, in Java's case, an extensive library (most of which isn't very good)?

If you want a higher-level language with a different balance of power vs. safety, there are many much better choices than things like D. On the other hand, if you want the power and you're smart enough to take advantage of the lower-level features in something like D, you're probably smart enough not to make rookie mistakes in C++ and to use the extra tools it offers effectively. I just don't see the target audience for the middle-ground languages. Java was born of hype, C# was born of exasperation with Java, and D was still-born, as you say yourself:

It might not be ready for full production yet (due to lack of big supporters and libraries, mostly)

Well, if D is to become even a shadow of what C++ is already, it's pretty much going to have to overcome these fundamental drawbacks. It's tough; obviously a lot of hard work has gone into it. But as I said, I think it's a product with no market, trapped between the more powerful and much more established C++ on one side and the more flexible and productive "scripting" languges on the other, and squashed under theoretically sounder academic languages with better underlying programming models for good measure. You only have to look at the... not entirely representative... features checklist on the D language site to see where the design came from.

Perhaps there is a reason that, as the D site itself notes, most new languages appearing today are either from the academic community and showcasing more theoretically robust programming techniques, or from the business community and based on quick and effective development?

Re:Downhill at a fast rate

[EvanED]

My apologies, you're correct. I was under the impression that const within C was a compiler extension and not standard.

(The point of my original post though, that you still can't tell from the call site if an argument will be modified when passed by pointer, stands.)

Additions to C++?

[DulcetTone]

Doesn't the language need LESS complexity? tone

Re:Downhill at a fast rate

[Chris Burke]

Your original statement used Bjarne's approval as proof of correctness. That's the false logic that I disagree with. Sure, he has a lot of good ideas. That doesn't mean he's right, not even close.

A lot of people would grant more weight to the opinion of Bjarne Stroustrup, inventor of the C++ language, over Chris Burke, random /. poster. It was not intended to be a logical proof, though I won't fault you for assuming it was. Of course he isn't always right. Except in this case he is right.

Your entire argument logically follows from this statement. However, I don't agree with this statement, so I don't agree with the rest of your argument.

You're backwards. "Pass by pointer makes for easier to understand code" is my conclusion, not the axiom.

Don't be ridiculous. Of course I use descriptive variable names. That's why I don't need to use pointers to pass-by-reference. Because my function names are good.

Okay, maybe your function names are way better than mine, then. I'm trying to imagine how that would work for a non-trivial example. functionThatDoesFooWithParameterNPassedByReference () ? Hungarian notation? Help me out here.

Also, does this mean that you do see the value in making the pass by value/pointer distinction clear at the calling point instead of making them refer to the header file?

Ok, so your logic is that the more information is included at the call point, the better. Ok, then why don't we include all kinds of other information there too.

Yes, with the common sense caveat that there can be too much of a good thing. If it isn't an onerous burden on the author, and doesn't as a side effect make the code harder to read (e.g. including the entire function comment block before every call), then indeed why not? A single amphersand is hardly an onerous burden, and provides useful information.

How about including a cast to the true parameter type so that I know the true type of each of the parameters?

If the casts are non-trivial, then this would be good idea. The hidden costs of things like automatic casts creating temporary values are part of why C++ has a reputation for being slow. Making them explicit helps them be found and possibly optimized, eg by doing the cast outside of the loop when possible.

How about adding a little comment for each parameter that gives the name of the parameter local to the function?

This is a very good idea. Positional arguments can be confusing and difficult to remember, especially if you use constants. Something like translateAddress(linearAddress, true, false, true, true) can be maddening to read. Instead, something like translateAddress(linearAddress, true /*generateFaults*/, false /*write*/, true /*read*/, true/*code*/) is vastly more helpful. Python (and other languages) do this one better and don't require positional arguments, you can assign to the parameter name. E.g. optParser.add_option("--wiki", default=False, action="store_true", help="Generate Wiki-friendly table output with '|' between columns"). Nice, eh? In simple cases it isn't needed, in complex cases it keeps you from having to remember the order arguments are required to go in. This can make the code much simpler to read, and prevent you from having to constantly refer to docs/man pages/header files.

Or any number of things that might help our plucky maintainer? Because it's all in the header file.

If it would be helpful and isn't an onerous burden. Making your maintainer refer to the header file unecessarily is a good way to get your name cursed by said maintainer. But I'm a little confused -- on the one hand, you say the maintainer should have to read the header file, but on the other you say that it should be clear that the parameter is passed by reference at the calling point. I'm getting mixed messages.

Beca

Re:Downhill at a fast rate

[EvanED]

But it doesn't make it nigh impossible for the object to be invalid. Checking for input validity is not something you can skip no matter your passing method.

If the input isn't valid, nothing you can legally do will find it.

And even so, it's one less thing that you have to test for.

And checking for non null is simple [then an assertation]

You just moved to runtime what the compiler could have enforced (as much as anything can be) for you at compile time.

If the best use for references is to avoid a one line check at the expense of making the calling code more difficult to understand, then I'd say there's no use for references at all.

It also symplifies syntax in the called function. There are other places where references are "necessary" though (for instance the return value of vector::operator[]), so they couldn't be removed from the language entirely even if you didn't allow them in argument lists.

(And I posted another comment about how I don't find even the readability argument in favor of passing by pointers unconvincing.)

The rule I use, which I've heard Bjarne himself utter while simultaneously destroying with the stream operators, is that the operator should have an obvious meaning analagous to the built-in operator. E.g. adding strings and complex numbers both have obvious expected meanings.

It's good rule, and one reason why I think that the proposed someVector += 5, 6; syntax is absolutely awful.

However, I think that an exception can be made for the shifting operators and input and output partly because of the very long history that they have, and partly because (to my knowledge) the shifting operators were pretty much invented for programming. +, *, etc. all have meanings we've seen since kindergarden or before; << doesn't. It makes sense, but then it also sort of makes sense for stream operations.

That's why I still use printf().

And lose flexability and enforced type safety? ;-)

(I know this is a war I can't win, but: I think that printf syntax often looks nicer, but it's harder to learn, a lot harder to understand if you don't know it, and isn't typesafe. You also have issues with how you output with classes because you can't make the printf formatting string accept new switches, and couldn't pass a non-POD type anyway. There was a language extension proposed to allow typesafe, variable length argument lists, which would have fixed some of those problems. I haven't heard anything about it for a long time though (I didn't necessarily RTFA now though), so I doubt it will come to fruition. That would have been nice though.)

Re:Downhill at a fast rate

[Chris Burke]

No, it was clearly neither. If you read the whole sentence, you'd see it was instead irony.

You're trying to convert every phrase and sub-phrase of a /. post into a step in a formal proof. This is idiocy, not logic.

Lisp / Scheme

[alexo]

fonbio,

As you seem to have some experience with both, could you try to summarize the main differences between Scheme and Lisp?

Re:Lisp / Scheme

[fionbio]

Look here.

Re:Lisp / Scheme

[alexo]

> Look here.

Thanks.

How about something that does not assume familiarity with either language?

Re:Downhill at a fast rate

[EvanED]

But it doesn't make it nigh impossible for the object to be invalid. Checking for input validity is not something you can skip no matter your passing method. And checking for non null is simple:

Ah, here's another point that I didn't think of before:

You're all talking about how passing by pointers is good for readability because it enforces documentation at the call site that it can be modified.

Here's one way, related to the null pointer point (no pun intended), in which passing by pointer hurts the self documentation of the code. It's not uncommon to find functions that can accept a null pointer as an argument. A lot of unix calls in particular will both set a non-null pointer argument to and return a value. (I can't think of any off the top of my head, but if you want I'll find one.) Having a reference parameter documents from the syntax of the code (the strongest documentation you can have) that null values are prohibited; having a pointer does not.

In other words, the issue of the validity of a null value goes beyond just checking for improper parameter values.

I've seen advice that addresses this point, and recommends the use of reference parameters for situations in which null is invalid and pointers for when null is valid for this very reason. Sutter and Alexandrescu give this advice for when to pass by pointer and when to pass by reference:

• Prefer passing by (smart) pointer if the argument is optional (so callers can pass null as a "not available" or "don't care" value [the issue discussed above] or if the function stores a copy of the pointer or otherwise manipulates ownership of the argument
• Prefer passing by reference if the argument is required and the function won't store a pointer to it or otherwise affect its ownership.

C++ detractors unified

[epine]

What I find amazing about the group of C++ detractors as a whole is how rarely I comprehend the claims put forward about the vaguely defined desirable language ~C++.

I think "you don't pay for what you don't use" is a fundamental design flaw of the language.

What is the precise claim here? That the entire language niche of pay-as-you-play languages should have remained empty? That C++ was the wrong language to occupy this niche? That there is a finite set of everyone-pays-all-the-time features that could have been added to C++ without compromising the language's scope or applicability? That any two people asked to write down such a list would produce a non-empty intersection?

Pay-as-you-play enables compositionality: the very idea that libraries like Boost can exist and be 90% as effective as if those same features had been designed into the language. It's the 10% that Boost doesn't achieve that gets folded back into the core language.

One guy was ranting that the true test of cohones is what the designer removes from the language, while another long post was devoted to a laundry list of "how could this language not have all these kitchen sinks so late in the day?" Which is it? You can't have minimalism in all places all of the time. Minimalism to the compiler vendor is a different beast than minimalism to the end user.

Ada had generics in 1983. Yada yada yada. What do you get when you start with a clean slate in 1995?

Does it thrill Marc Andreessen?

http://news.com.com/Andreessen+PHP+succeeding+wher e+Java+isnt/2100-1012_3-5903187.html

"Java is much more programmer-friendly than C or C++, or was for a few years there until they made just as complicated. It's become arguably even harder to learn than C++," Andreessen said. And the mantle of simplicity is being passed on: "PHP is such is an easier environment to develop in than Java."

Does it thrill Miguel de Icaza?

http://www.builderau.com.au/program/work/0,3902465 0,39129961,00.htm

The problem with J2EE really is that it became very, very academic and the complexity of all these perfectly designed systems in schools does not necessarily map when you have deadlines and all kinds of other things.

http://www.informit.com/guides/content.asp?g=cplus plus&seqNum=200&rl=1

When Java designers decided to disallow operator overloading, they cited C++ as an example of the inherent woes of this feature. As usual, they got it wrong, which is why operator overloading is slowly but surely creeping into Java just as generics recently did.

Does it thrill Sun insiders?

http://idevnews.com/CaseStudies.asp?ID=170

Peter Yared, former CTO for Sun J2EE app server unit says Java/J2EE may lose out to Open Source technologies in the future, as IT managers are architects get tired of the time and cost of building in Java.

The sad fact is that few of the C++ detractors out there could do any better than Java, and Java didn't hit its own sweet spot any better than C++ mapped to its own misbegotten design criteria.

Headers versus unification of code and interface

[Trinition]

In this respect I would like C++ be more like Java (or TurboPascal for the matter) where interface declarations and compiled code are unified

One thing that Java does well is put the interface to something in its compiled code. This also means that anyone can look into your interfaces from your compiled code. :)

In C, you could choose not to give someone your headersand they could never (easily) use your code, but the other code you distributed which needs it could still use it. Consider a third party library, for example. In my C/C++ days, I often wanted to use a library that another library I was using called into, but I couldn't do so because I didn't have the headers for it.

In Java you can achieve some of this with signed jars, and good use of public/private/protected/etc., but you simply can't give expose a public method in your JAR to one fellow and not to another.

Still, I manage to just fine without this :)

Java not typesafe?

[msobkow]

With the exception of ADA and maybe Modula-2, J2SE5 is one of the most type-safe languages I've used.

Java's "typecasting" is not like a C-cast, but rather like a full C++ dynamic_cast with RTTI enabled.

There is a big difference between type-safe runtimes and compile time type checking.

Where pretty much every language other than ADA falls down is their lack of numeric precision enforcement -- it's almost impossible to implement correct calculations in C/C++ without unwinding the statements so you can do correct result truncation after each operation involved. Languages which do such precision checking and enforcement don't suffer when automatic type conversions are performed, because you get told about the overflow/underflow issues.

Don't think for a minute that the C++ "void *" is anything like Java's "Object". The former is just an address/pointer, the latter carries type information.

Re:Downhill at a fast rate

[Chris Burke]

If the input isn't valid, nothing you can legally do will find it.

In the sense that your reference/pointer might be referring to a deallocated (and possibly subsequently re-allocated) object, sure. That feeds into the issue that refrences are not a magical fix for memory management bugs, but that's a digression. I meant in the general sense that one must verify all inputs for logical validity. Indicies must be in the correct range, flags must have understood values, that kind of thing. Most substantial functions I write start with a block of assert() precondition and parameter checks, and checking for a null pointer is just one more. Granted, it is one more.

You just moved to runtime what the compiler could have enforced (as much as anything can be) for you at compile time.

I don't see how that is the case. Obviously there is a runtime check that didn't exist before, but in situations where one could actually get a null pointer I don't see how changing to references fixes it at compile time. I can only see it in the sense that you can't use new() to assign to a reference and then forget to check for null like you can with pointers, but that's just avoiding the functionality, not fixing the problem. I'm missing something, so help me out.

There are other places where references are "necessary" though (for instance the return value of vector::operator[]), so they couldn't be removed from the language entirely even if you didn't allow them in argument lists.

No, no, I didn't mean get rid of references, or even disallow them, I just think the other poster's favorite usage of references is anything but 'best'. For operators references are a necessity. Like operator overloading, I think references are a feature that should be used with care and that many C++ programmers go overboard using these features simply because they are there.

The only C++ feature I think should be removed is the 'private' keyword. It has just never worked out for me that I could derive from a class and override its functions without having an intimate knowledge of how the base class worked. The 'has-a' relationship seems much better if you want to treat the base class like a black box. Personally I think "private" should mean what "protected" does today, and "protected" should be changed to mean that members can be accessed but not modified. This would fix my other pet peeve, having to write swarms of getFoo() functions just to disuade random doinking with the internal state. But I digress into a dreamland...

And I posted another comment about how I don't find even the readability argument in favor of passing by pointers unconvincing.

Yeah, and I agreed with your caveats (especially that all my blather only applies to C++ references).

It's good rule, and one reason why I think that the proposed someVector += 5, 6; syntax is absolutely awful.

Ugh, what's that supposed to mean? Is that something using the sequence constructor?

However, I think that an exception can be made for the shifting operators and input and output partly because of the very long history that they have, and partly because (to my knowledge) the shifting operators were pretty much invented for programming. +, *, etc. all have meanings we've seen since kindergarden or before; << doesn't. It makes sense, but then it also sort of makes sense for stream operations.

Sure, now it has history, but at the time << had a long history of being only the shift operator. I agree that if one were going to pick an operator to make into the stream operator, that was the best one. I wish they had created a new one, like ~~, but I can think of a couple reasons why that could have been undesireable.

(I know this is a war I can't win, but: I think that printf syntax often looks nicer, but it's harder to learn, a lot harder to understand if you don't know it, and isn't typesafe. You also have issues with how you output with classes because you

Re:Downhill at a fast rate

[Chris Burke]

I've seen advice that addresses this point, and recommends the use of reference parameters for situations in which null is invalid and pointers for when null is valid for this very reason. Sutter and Alexandrescu give this advice for when to pass by pointer and when to pass by reference:

                * Prefer passing by (smart) pointer if the argument is optional (so callers can pass null as a "not available" or "don't care" value [the issue discussed above] or if the function stores a copy of the pointer or otherwise manipulates ownership of the argument
                * Prefer passing by reference if the argument is required and the function won't store a pointer to it or otherwise affect its ownership.

Hmm, that isn't terrible advice, actually. You don't have to bring up examples of functions that take NULL to mean "don't care", I know of some. time() being the first one that springs to mind, and of course I've written some myself. I would still prefer some syntax that indicates that a value is being passed by reference.

XML? Who cares about XML?

[Anonymous Brave Guy]

Assuming of course that I want to put a lot of complex data into my code rather than load it from XML or a database

Damn, and we used to just use a plain old text file. Why does everything have to be XEverything these days?

XML is a not-particularly-good implementation of a not-particularly-clever idea, whose sole benefit in most cases is that there are libraries to parse it for you. Then again, if your programming language is even slightly good at text processing, you can do enough reading and parsing to handle most configuration files in a line or two of code anyway, and the rest is just overhead.

Or you could just hard-code data that's not really likely to change anyway, and have a much faster, more maintainable program than the guy who wrote more lines to process his XML than there were in the file he was processing. I'm just sayin', y'know, it's a thought.

Re:XML? Who cares about XML?

[dsplat]

My point was that there are C++ libraries to parse XML, and there is are tools to transform XML into other stuff. You can use the tools to generate C++ code containing the data if you want it hard-coded. When the folks in Marketing had down the requirement to make it 100% buzzword compliant, you can throw in a library and a little code to parse the XML.

I certainly have enough old code laying around to parse enough different config files. There are three advantages to XML. The first is that it is text-based, so you can write it from any programming language that can write text to files, or your favorite text editor. That doesn't set it apart from any other text file format. The second is that there are lots of libraries and tools for dealing with it in any programing language. You don't have to write, debug and maintain tools to parse it. The third is only an advantage if you use it right. That is, the tags and attributes document what your data is. If you do it wrong, your data can end up looking like sloppy ASN.1 littered with angle brackets.

Re:Downhill at a fast rate

[EvanED]

You don't have to bring up examples of functions that take NULL to mean "don't care", I know of some. time() being the first one that springs to mind

Wow, I was actually thinking something along those lines, but I didn't think it was something that simple. I checked out stuff like a couple of the itimer functions, gettimeofday, but didn't see it.

I would still prefer some syntax that indicates that a value is being passed by reference.

I would too, with the caveat that it not be required at call sites for functions that take const references. (The latter I think is necessary because there are a lot of places where it's passed by const reference and it's not logically a reference parameter. In fact, I think if you required notices even at those points you'd be at the C/pointer situation, which, as I said, is hardly better. The downside is it wouldn't be perfect, as there are still mutable members, casting away const, etc.)

For instance, I'm a fan of the C# method:
  void swap(ref int a, ref int b) { int t = a; a=b; b=c; }

then
  int one, two; ...
  swap(ref one, ref two);

It even goes further with allowing you to specify just out parameters:
  void assignFive(out int a) { a = 5; }

then
  int one;
  assignFive(one);

(Don't ask me why you'd write that, it was just the easiest demo of an out parameter I could think of.)

The latter has the benefit over making the parameter ref that the compiler would complain that you're using an uninitialized variable in the call to assignFive otherwise. (But now it would also complain if assignFive tried to use a before assigning to it, as it assumes that out parameters can be uninitialized.)

Re:Downhill at a fast rate

[EvanED]

Obviously there is a runtime check that didn't exist before, but in situations where one could actually get a null pointer I don't see how changing to references fixes it at compile time. I can only see it in the sense that you can't use new() to assign to a reference and then forget to check for null like you can with pointers, but that's just avoiding the functionality, not fixing the problem. I'm missing something, so help me out.

I guess it doesn't provide nearly the benefit that I was thinking. The only situation where it might is if you would, with the pointer version, explicitly type NULL as a parameter. You can't say foo(*NULL) so can't call the reference version with a NULL reference explicitly.

(The other time it could help is if you had another static analysis tool that was good enough to detect that at the time of foo(*a) it's possible a was null but either doesn't support annotations that foo can't take a null parameter or don't have the ability to annotate foo.)

Ugh, what's that supposed to mean? Is that something using the sequence constructor?

someVector += 5, 6; would be equivalent to someVector.pushBack(5); someVector.pushBack(6);

I'll agree that writing a bunch of pushBacks or however you do it can get annoying, but the drawbacks of the += greatly outweigh the benefit. (And I'm usually a big fan of both conciseness and syntactic sugar)

[I would like to take a time out of this post and say just how wonderful the UndoCloseTab extension is in Firefox; I had typed out this much and accidentally hit ctrl-w instead of ctrl-v (I use Dvorak layout and W and V are adjacent), but UndoCloseTab keeps any form data you've entered. I just discovered this the other day, and the W thing is something that I've always had problems with (I think I found a way to disable the keyboard shortcut, but I forget how), so I'm still excited about its consequences. We now return you to your regularily scheduled slashdot post.]

Sure, now it has history, but at the time

Or even just ~... I can't think of any parsing ambiguities that would create...

If you're using gcc and -Werror, then printf() is actually pretty type safe. Gcc understands printf syntax and can check the arguments (and it is very picky, e.g. it will complain if you reference an unsigned int with %d, or long on a 64-bit machine with %lld) and won't let you pass non-POD types. There's a directive (gcc extension) you can use to tell gcc that a function is printf-like and get the same argument checking on it.

That's true. I was thinking that you'd have to use Lint or some other third party tool to get the checking.

For printing non-POD types, you have basically the same problem with both printf and cout: each class you want to be able to printf/stream needs a function written for it that allows you to do so. For use with printf, you create something like string MyClass::toString(). For cout, you create an operator

There's another, which is that if you're going to write that function in the class, what does it actually do? Call printf directly? Now you're less general than a good ostream operator in C++, because you can't use it for files or standard error. So you have to pass in a file descriptor. But now you're still less general because you can't use it to help construct strings, a la stringstream.

I think pretty much only best way to do it if you want to stick with printf stuff is to make a toString method, and then you can use that as you please. With ostream, you get the ability to make a function that prints to an ostream directly. I don't know if one of these approaches is better than the other; it's possible that you'd usually just want to write toString and have the << operator call that. I've given it some thought and can't come up with a dramatically convincing argument for either method.

(I do think the situation is worse with input though. You can't write a "read from this string" function because then how does the code that ca

Re:Downhill at a fast rate

[jcr]

For example, you could replace 99% of the type-unsafe macros with templates and const data instances. Or you could use constructors and destructors on your structs to get rid of crap like { foo f; init_foo (&f); ... ; destroy_foo (&f) }. Which is obviously tedious and error prone. The list goes on and on.

Sounds like a hell of a lot of work to address problems that don't arise in other languages.

-jcr

Not quite?

[Trinition]

Just a note: interface == .h for java. Document all you want, and ship to your customer, along with a crypted jar with the actual binary.

I think I know what you're getting at, but I don't think its quite true.

Interfaces in Java are only used like a .h file once they're compiled. The compiled .class file is what you're actually importing... or rather, the API of that .class file. On the other hand, a header file in C++, IIRC, is inline at compile time as plain text before the compile does anything. Thus, you could include anything text you want.. imcomplete syntactical fragments, for example. In Java, this is not possible. This is essentially the difference between a preprocessor which treats source and includes as text and the Java compiler's treats imports as a way for the compiler to be aware of a pre-compiled API. That is, one happens in the text domain while the other happens in the domain of the compiler's understanding of the parsed source. This is nice in some ways, btu also means you can't do some cool tricks you could do with a preprocessor.

As for the crypted jar file, I'm not sure as I don't use them much. But what I am fairly certain of is that Java uses runtime linking, meaning the actual names of methods and classes is stored in the .class file itself so that they can be linked to the right code loaded from elsewhere by name. So in order for Java's runtime linking, the non-private API of a class must be known to the .class. This is why once you have a .class file, you can run javap against it and get its API. Its just dumping the same information that is used at runtime to match of what one class needs to what another provides.

So, I'd say Java's runtime linking info in a .class file is most similar to what C/C++ header files are used for a good deal of the time, but via a var different mechanism that those includes. Thus, it is much cleaner at doing that job, but weaker at doing everythign else you might do in a header file.

Re:Not quite?

[Surt]

That's certainly true. Java's lack of a preprocessor stage is a significant weakness. I was really only replying to the notion that java didn't have an equivalent mechanism for exposing the public interface of a class to a customer without revealing code.

Re:Not quite?

[Trinition]

I was really only replying to the notion that java didn't have an equivalent mechanism for exposing the public interface of a class to a customer without revealing code.

To which I point out, every class has its public API embedded in it, in a well specified format. This information can easily be retrieved using a tool that comes wiht the JDK, javap. For example:

"%JAVA_HOME%\bin\javap.exe" -package java.lang.System

This will list the public, protected and package-protected classes, members and methods in java.lang.System, knowing only the information in the .class (which in this case comes from rt.jar in the default classpath for Java). It does not show implementation of those methods and classes, only their API.

What Java can't do, to my knowledge, is distribute a binary and prevent its API from being retrieved in this manner. Their obfuscators that can slow things down, but you can't prevent it.

Re:Not quite?

[Surt]

That's an odd requirement. You could use gcj for most projects. I mean, if you're doing that, you're talking about needing to strip your c programs and such, I don't know much of anyone who does that.

Maps of Vectors of Hastables of Arrays

[Trinition]

What I started to hate in C++/Java/C# is that there's no easy and standard-conforming way to express complex data 'inline'.

I once worked on a Java programmer (written by a lot of recently C programmers) that had sometime like a Vector of HashMaps, and each HashMap had an element under a a known key that was an Array, and the first item in the array was a Vector of IDs, and the second item in the array was a Map of names to a Vectors where the 1st, 2nd and 3rd items were a crude struct. You couldn't debug crap with this, and even coding was hard unless you had a colorful diagram on your whiteboard explaining what everything meant.

This reminded me a lot of what I used to do with Perl before I started taking advantage of Perl's OO features.

I've often found places where I need to do somethign quick and dirty for a test program and wish I could just use Maps of Arrays rather than defining formal types. But for anything serious, it is much better to just make formal classes for each one. These classes are then types, and which gives not just your language some semantics, but the code you've written now has semantics!

Consider:

(String)((Vector)((Map)((Object[])((Map)vec.get( 0)).get("foo"))[1]).get("email")).get(0)

vs.

customers.getCustomer(0).getContact("foo").getEm ailInfo().getEmailAddresses().getEmailAddress(0)

Re:Maps of Vectors of Hastables of Arrays

[Anonymous Brave Guy]

Consider:
(String)((Vector)((Map)((Object[])((Map)vec.get(0) ).get("foo"))[1]).get("email")).get(0)
vs.
customers.getCustomer(0).getContact("foo").getEmai lInfo().getEmailAddresses().getEmailAddress(0)

Or even, for those of us who use overloaded operators like sensible people ;-)

customers[0].contacts["foo"].emailAddress[0]

Re:Downhill at a fast rate

[jcr]

I'm keeping up just fine, sunshine. Would you care to attempt to make some cogent argument in favor of C++? ('cause you sure haven't yet.)

-jcr

Re:Downhill at a fast rate

[scotch]

MyObject foo();

Interesting, so what does this "foo" function that returns a "MyObject" do?

Re:Downhill at a fast rate

[Rick Genter]

Actually, I don't know. /vmlinuz and /dev/hd?? are specified in grub configuration files. I suppose /dev/tty could be specified in the grub configuration file instead. I'm not insane enough to try it though :-).

But we're getting seriously offtopic now...

Unless C++0x adds a feature that allows booting from /dev/tty...

And get r00ted?

[tepples]

What are you doing such that you need to put constant data into a vector like that? Is there a reason you're not just using an array?

Vectors have more built-in guards against buffer overflows.

Re:And get r00ted?

[Anonymous Brave Guy]

Vectors have more built-in guards against buffer overflows.

True, but since we're talking about const data here, overwriting the end of the array isn't very likely, is it?

Re:And get r00ted?

[tepples]

since we're talking about const data here, overwriting the end of the array isn't very likely, is it?

Who said anything about writing? I can think of at least half a dozen cases where overreading can be just as dangerous as overwriting.

Re:And get r00ted?

[Zathrus]

I can think of at least half a dozen cases where overreading can be just as dangerous as overwriting

As can I, but again -- we're talking about const data here! If you're going past the end of the array/vector then your code is really, amazingly bad.

Besides which, the "safe" methods for vector access are also slow -- at() is considerably slower than [], and iterators are slower than either.

Again, there are still valid uses, but they are exceptionally rare.

Re:Downhill at a fast rate

[scotch]

I wonder why you choose to answer posts like the grandparent rather than dealing with ones like these:

• 14386582
• 14384336
• 14385135

One wonders.

Re:Downhill at a fast rate

[Profound]

>> >> get rid of crap like { foo f; init_foo (&f); ... ; destroy_foo (&f) }.
>> >> Which is obviously tedious and error prone. The list goes on and on.

>> Sounds like a hell of a lot of work to address problems that don't arise in other languages.

The problem of remembering to cleanup resources is not contained to just C and C++. It is not just memory, but also files, sockets, database connections, threads, etc.

in C:

FILE* f = fopen("foo", "r"); // access file
fclose(f); // have to remember

in Java:

FileInputStream file = null;
try {
        file = new FileInputStream("foo"); // access file
} catch (Exception e) {

} finally {
        file.close(); // have to remember
}

in C++:

{
        fstream file("foo");
} // file falls out of scope and destructor calls close

Re:Downhill at a fast rate

[tilde_e]

> Operator overloading is indeed a carnival of confusion that would have been best avoided.

Actually, on the contrary, the entire purpose of operator overloading is to reduce complexity. std::auto_ptr would not be able to hide the memory management semantics from you and still act like a pointer without this feature.

If you do any serious development on any scale, you have problems MUCH bigger to solve then to worry about a tiny semantic. To do any problem solving on a large scale, you need to express and capture your problems as the smallest factors possible, test them in isolation, then scale your usage of that solution. Anything the language can do to hide the fact that you had to solve that problem in the first place will help you keep more important things in your head. So yes, operator overloading works best when the symbols are the natural way you would want to solve a problem, when they are intuitive.

I think one of the main problems with overloading is you can't control precedence, if you could we would probably be writing:

std::cout = "Hello world!" + std::endl;

But if it was implemented that way right now we would be using ()'s all over the place.

Shouldn't it be called ...

[dradler]

C+=2 ?

Re:Adding new features is not always an improvemen

[Minna Kirai]

In other words it is very hard to write automated code browsing tools or refactoring tools for C and C++ because you can't parse a given source file

Some might say that a command like "gcc -E" would solve this, as it runs the preprocessor stage only, creating a file which other tools can parse. However, that's not a real solution, because the preprocessor depends on -D macros set from the makefile / environment-vars / build-script, which may be arbitrarily complex.

As usual, powerful and flexible software has the pitfall that it cannot be sanely analyzed by another program.

Sieve of Eratosthenes

[tepples]

I haven't managed to come up with a situation in which you'd want to store so many booleans that you could afford processing power more than extra space, since hard drives and memory are relatively cheap these days.

Classic example is the Sieve of Eratosthenes. Use a byte array and you've multiplied RAM usage by 8. That said, if you really need it, you can probably implement a bit vector in terms of a byte array.

In Lisp...

[tepples]

after all you're just calling a function, and add(a,b) isn't much more typing than a + b... right?

At least in Lisp they'd be of the same form: (add a b) vs. (+ a b). Common Lisp fans will be quick to point out that the destiny of C++ and every other similarly high-level language is to reinvent the feature set of Lisp, allegedly poorly.

Re:C++0x misses this feature

[Duhavid]

Yes, many many times. By far, the bulk of my career as a
programmer. And for quite a bit of it as a C++ programmer.
Also, visual basic, 5, 6 and .net, C#, powerbuilder, and
various flavors of SQL.

I am lead of a development team just now, in fact. I have
worked on the committees established to publish coding standards
for a couple of the places I worked.

Most of the coding standards I have run into are more about
formatting and clarity rather than "avoid these language
features".

I dont really see how coding standards fit into this, though.
It is not like Java/VB/C# dont require a coding standard, and
dont allow enough flexibility for your developers to go all over
the map. Not as much, but enough.

But on coding standards. If you have a coding standard,
( and you expect to enforce it ), you have code reviews. If you
dont have those, then some small number will adhere to the
standard, most wont. If you use your coding standards to
subset your language that is your choice. My preference
would be to tell my team to code for maintainablity and
clarity, and be darn sure they understand KISS. But
simple means as simple as possible, but not simpler. And use
the code reviews to educate on language features to avoid,
should any crop up. Except for one guy that came up from VB
who thought that assigning to a character arrary ( pointer )
would copy and reallocate the string, I have not had much
need to do this. I would prefer not to be taking tools out
of my programmers hands.

Personally, though, I dont find C++ to be ridiculous. I find it
to be a very powerful language with a ton of warts. And most of
those warts have been the pain points that lead the developers of
Java and C# to have the language they are today. Without that
learning experience, I doubt those two at least would be where
they are today. But I personally dont care to have my hands
tied behind my back by language designers because there are a
large number of people for whom the tool is a bad choice.

All of that does not mean that I will only use C++, I prefer to
use the best tool for the job, and sometimes that is C++, and
sometimes it is not.

Hell yes.

[Corngood]

Well, not for the property thing, I can live without that.

I would kill for a multipass C++ compiler that lets me write classes like C#/Java. With cross module optimisation (LTCG in visual c++), it pretty much needs to do multiple passes anyway, so they might as well have the option.

This would be a major change, so at the same time, I would suggest a tidying of the language to get rid of any syntax hacks (ahem, pure virtual = 0), and anything that's simply for legacy support. I guess you'd end up with a quite different language, which is fine, so why not have profiles like with XHTML (strict, etc), to ease migration?

There are loads of languages I'd like to try, which are going for a lot of the same goals, but they always have a dealbreaker. D looks ok, but then I can't live with forced garbage collection, and there aren't going to be compilers for PS2, Xbox, etc. Therefore I would say that any solution would have to have the possibility of being compiled to current C or C++, like C++ was in the old days.

Variable-sized stack arrays and big integers

[Myria]

I want variable-sized stack arrays:

void function(size_t size)
{
        char array[size]; ...
}

There is no technical reason that this can't be done. Even if you have a type with a destructor instead of "char", there is nothing bad about this. The compiler can store a copy of size for later and iteratively destruct them one by one. That's what would happen anyway if you used new[]. (If there is only one variable-sized array being used in the function, it can actually avoid storing the value entirely because it can deduce it by comparing ebp with esp.) GCC implements this feature already and there are no breaking problems with it.

Another thing C++ needs is a standard implementation of big integers. C# and Java have this. Even Perl has this. It's such a pain when doing cryptography to either reinvent the wheel or use some library with annoying DLL/SO dependencies (GMP).

Finally, someone needs to get on Microsoft's case and force them to implement stdint.h like everyone else has.

Melissa

Re:Variable-sized stack arrays and big integers

[Anonymous Brave Guy]

Is there some reason you can't use std::vector<char> array(size); for your purposes? The performance overhead would be negligible for just about any purpose, and it avoids putting large objects on what could be quite a limited amount of stack as well.

Big integers would be useful, though, as would fixed point arithmetic.

the big new invention: concepts

[mateub]

Stroustrup writes "This illustrates the most significant proposed C++0x language extension that is likely to be accepted: concepts. Basically, a concept is the type of a type; ..."

Templates brought considerable power to the class idea in C++, but templates are fundamentally a static, compile-time issue, while many things can happen to classes during runtime. For a while now, I've been working on a simulation application (remember when everyone seemed to point to simulation as the major application for C++?) where the type of the input file data elements (e.g. long list of integers, floats, shorts, etc) isn't known until runtime. The simulator uses a pipe and filter architecture, so you'd love to have templates Pipe<D> and Filter<D> where D is the data type, but oooh you won't know that until runtime. And you'd love to make the software future proof for arbitrary types of D. The concepts uh concept discussed in the article look like they could fix this problem. And if they don't, the committee should keep working until they do.

adéu,
Mateu

PS why, when I say the post is plain old text, does <D> still require me to use &lt; and so forth?

Re:Downhill at a fast rate

[Minna Kirai]

E.g. adding strings and complex numbers both have obvious expected meanings. Writing to a stream is nothing like shifting

Shifting is nothing like being incomprably smaller than another number.... but that's what "<<" means. (And furthermore, multiplication is unrelated to footnoting)

Re:Downhill at a fast rate

[Minna Kirai]

[then an assertation] You just moved to runtime what the compiler could have enforced (as much as anything can be) for you at compile time.

A good compiler can validate many assertions before runtime. There's no reason assert(0) couldn't be flagged by a compiler, and other situations evaluating to assert(0) can be caught by static analysis as well.

Of course, due to the requirement to be backwards-compatible with the C build system, real C++ compilers are rarely good enough to make these fairly easy checks.

operators were pretty much invented for programming. +, *, etc.

In my kindergarten * meant "peek down at the bottom of the page"..

Re:Downhill at a fast rate

[Minna Kirai]

never worked out for me that I could derive from a class and override its functions without having an intimate knowledge of how the base class worked. The 'has-a' relationship seems much better if you want to treat the base class like a black box

Doesn't work. In normal times, when Child is-a Parent, then Foo(Parent*) can be passed either a Child or Parent and operate on it transparently.

For use with printf, you create something like string MyClass::toString(). For cout, you create an operator<< with the right types. The big advantage of cout here is that its interface is part of the standard, so if a class implements it you don't have to guess its name.

cout has multiple speed advantages over printf. First, cout is overall more amenable to optimization, because the compiler knows the types from the typesystem, rather than the program parsing a formatter string at runtime. Second, any toString function you write will probably use a hefty bit of dynamic memory, or be non-reentrant.

Even so, the syntax of printf is nicely more compact, and the speed is not hugely important, so one may wish for a "C++ aware" printf. Such a function could work by adding an additional format specifier (say %P), which indicates that the argument is a pointer to a class derived from PrintfCompatible. PrintfCompatible would have a single pure virtual toString function.

With that in place, you could freely say
    printf("My personal fav object is %P\n", &favorite);
no matter what kind of class you had written.

If you're using gcc and -Werror, then printf() is actually pretty type safe. Gcc understands printf syntax and can check the arguments

That goes back to Bjarne's goal of providing user-created systems the same power as native language features. If you write your own class highly resembling cout, it will enjoy all the typechecking the official cout does. But implement your own printf analog, and gcc won't know to check the format string for type information.

(Hypothetically, a compiler could be smart enough to statically analyze the code to my_printf and notice that a "%c" in the string means that the input needs to be safely usable as a char, but that'd be highly ambitious)

Re:Downhill at a fast rate

[Minna Kirai]

had a bit of BASIC experience before moving to C++, and cout is a lot closer to PRINT than printf is (somewhat ironically given the names),

C++0x will finally bring the long-awaited operator" "() feature into C++, so the next version of cout will look even more like the old BASIC PRINT. No more << between variables; just type them out one after another.

I don't think the committee has decided if operator() will be replaced with operator" "() or operator,() yet, though. They've already rejected operator""(), which is a shameful lack of vision.

Re:Heh

[Stele]

You seemed to have entirely missed my point about writing image processing software. While I was talking about writing one piece of high-performance code (using templates) that can deal with multiple image formats (and gets automatically inlined by the compiler) automatically, you countered with using prefab Java LIBRARIES (what language do you think THOSE are written in?) or Python (that also uses libraries written in C++ for high-performance image processing).

The mission-critical reference I was making was to Objective-C's runtime binding of functions. Without the compile-time checking you get from C++, Objective C lets you write code that calls functions that might not even exist.

I didn't mention C at all but since you brought it up - it's possible to write far more robust programs in C++, with less code, than C, so people should really prefer C++ over C in almost all cases.

Ha! Validates my remark.

[Latent Heat]

I guess I didn't know about the "Plain Old Text" option either, but that proves my point.

The topic, to get back on topic, is about C++0x, and any discussion of C++ promotes a flamefest. The parent post to this thread was flaming/whining/ranting about some aspect of C++ while neglecting to use any paragraph breaks, and people piled on to the parent post lecturing the dude/dudette about the need for paragraph breaks when posting.

I was trying to point out a parallel between C++ and Slashdot posting -- they are both feature-full and expressive at the risk of making a dumb mistake, and when the dumb mistake is made, people pile on telling you how dumb you are rather than considering whether C++/Slashdot could be more dumb resistant. And when a person dares suggest that something be made more dumb resistant, that suggestion triggers a response that a person is also dumb and a complainer to boot.

For more background on this, I defer to Cooper of "Inmates are Running the Asylum", anything by Donald Norman, and the infamous "Unix Hater's Handbook." There is this culture that any user-interface problems are the fault of the luser and that anyone pointing out such problems is a whining complainer. I was reading a book on Boost, and barely made it into the first chapter on auto pointers when my head started to spin on different flavors of auto pointer and how one worked in one situation but would result in a GP fault in another situation -- geez, Louise, in Java you just have garbage collection and don't have to wrap one's head around such issues. Of course, I am probably mentally deficient for not grasping Boost/C++ auto pointer flavors and I will go through life writing mentally-deficient Java.

Re:Downhill at a fast rate

[Chris Burke]

Doesn't work. In normal times, when Child is-a Parent, then Foo(Parent*) can be passed either a Child or Parent and operate on it transparently.

True, if you use virtual functions. If that's the goal, has-a won't work. I still think that if you do want your child class to be used 'transparently' you're going to have to be able to access or change the child classes 'private' members. In many cases, anyway.

Even so, the syntax of printf is nicely more compact, and the speed is not hugely important, so one may wish for a "C++ aware" printf. Such a function could work by adding an additional format specifier (say %P), which indicates that the argument is a pointer to a class derived from PrintfCompatible. PrintfCompatible would have a single pure virtual toString function.

No, I don't wish for that. It's unnecessary. To make my objects 'printf compatible' I give them a function which returns a string, and use %s in printf. Actually it returns a std::string, which is nicer than returning a char* for a lot of reasons.
Thus it looks like this: printf("%s", someObject.toString().c_str())

So reentrancy isn't a problem. Dynamic memory still is. I'm not certain the room for compiler optimization is that large (my off-the cuff guess is avoiding branch mispredicts by avoiding the indirect branch of a case statement is the most help). I'd be interested to compare the performance of cout and printf, with and without non-POD types. For printing to a console or other such, I highly doubt it matters. But for buffered file io or other in-memory operations it may.

But implement your own printf analog, and gcc won't know to check the format string for type information.

If your printf analog uses the same format specifiers as printf, then it can with a gcc-specific directive. In the general case though, yeah, varargs lack type safety.

Re:Heh

[Weedlekin]

"You seemed to have entirely missed my point about writing image processing software. While I was talking about writing one piece of high-performance code (using templates) that can deal with multiple image formats (and gets automatically inlined by the compiler) automatically, you countered with using prefab Java LIBRARIES (what language do you think THOSE are written in?)"

Mostly Java, actually. This wasn't originally the case, but as Java's performance has increased, various parts of its core libraries have been rewritten in itself. The primary reason for this is to make porting it to other platforms easier: the less non-java code there is, the easier the system is to bootstrap with only a Java compiler.

"or Python (that also uses libraries written in C++ for high-performance image processing)."

Most Python libraries are written in C because that is what Python binds to. There are some C++ ones (usually with C "wrappers"), but then there are some written in other compiled languages as well.

"The mission-critical reference I was making was to Objective-C's runtime binding of functions. Without the compile-time checking you get from C++, Objective C lets you write code that calls functions that might not even exist."

You are missing the fact that Objective-C is perfectly capable of using static typing if required. You simply declare a pointer to a type directly as you would in C, e.g. "MyClass *aClass;", and voila! Any attempt to send a message isn't a member of "MyClass" on "aClass" will result in a compile-time warning. Dynamic types are therefore an option that you can use or not use, much like many C++ features. Note also that for those times when one wishes to avoid the overhead of the message dispatch system, Objective-C allows methods to be directly called by address. This is as fast as calling a C function by address (because that it what it is doing).

Re:Downhill at a fast rate

[Chris Burke]

Shifting is nothing like being incomprably smaller than another number.... but that's what "

Just like calculus means different things to a dentist and a mathematician, the C/C++ programming language is a specific field with its own jargon and the 'obvious meaning' of an overloaded operator should be derived from that. Obviously. Since 1970-ish, << has meant bitwise left-shift in the realm of the C programming language and its derivatives.

Perhaps a better way to put it would have been to say that a programmer should be able to intuit the behavior of an operator based on the behavior of that operator on all other types.

Re:Downhill at a fast rate

[Chris Burke]

Interesting, so what does this "foo" function that returns a "MyObject" do?

As an Real Programmer would know, it snafucates the enabalizer.

Re:Downhill at a fast rate

[Chris Burke]

someVector += 5, 6; would be equivalent to someVector.pushBack(5); someVector.pushBack(6);

I thought from the article that it would have to look like someVector += {5,6}, like it would if 5,6 was intended to be a normal array initializer. That doesn't seem so bad. That is what I would expect array addition to do -- concatenate two arrays.

The main problem with 'vector' and operators as far as I'm concerned is the name. Absolutely terrible name for "better array". While a (math) vector is an array, an array isn't necessarily a vector. I would expect to be able to do a vector dot product with '*', but of course I can't. And then if you want to make a useful mathematical vector class, the name is already taken. :P

I think pretty much only best way to do it if you want to stick with printf stuff is to make a toString method, and then you can use that as you please.

Yeah, like I said, that's what I do. printf("%s", myObject.toString().c_str()) is the kind of thing you'll see in my code.

I do think the situation is worse with input though. You can't write a "read from this string" function because then how does the code that calls it doesn't know how much to read from the keyboard before it calls it; if it reads too little, the object can't be built, but if it reads too much it's extracted too much from the stream.

Serializing non-POD types from keyboard input is evil. :)
But yeah, this is more difficult. To solve the problem, the interface would have to do two things: tell the caller how many bytes it read from the string, and second tell it if there were insufficient bytes to create the object. The second you can do either by returning an error code like pre-glibc2 snprintf(), or better by returning how many bytes the function -would- have read if there were enough, like post-glibc2 snprintf(). Returning the number of bytes needed being more difficult if not impossible to implement in every case.

I'm not a big fan of plain-ol text serialization of objects though. If the objects are complex, then the format should be structured (like xml or length encoding) such that the program -can- know how much data is intended for each object.

I had a bit of BASIC experience before moving to C++, and cout is a lot closer to PRINT than printf is (somewhat ironically given the names), so that's my theory as to why I almost always use cout.

*shudder* I have a lot of BASIC experience pre-dating my move to C, which pre-dated my move to C++ by several years. I never made a connection between PRINT and cout, but it could be that my subconscious is rejecting anything related to those long, dark years of GW-BASIC.

Heh. Remember when /. used to be full of cool geeky coding discussions like this one?

I would like to take a time out of this post and say just how wonderful the UndoCloseTab extension is in Firefox

I'll check it out. I use a dvorak keyboard, but have never had that problem (but I tend to be mouse-driven when using a browser anyway).

Re:Downhill at a fast rate

[EvanED]

I thought from the article that it would have to look like someVector += {5,6}

That's a separate proposal. I don't know about +=, but I know that at least they're looking at ways to initialize vectors with arrays.

The main problem with 'vector' and operators as far as I'm concerned is the name. Absolutely terrible name for "better array". While a (math) vector is an array, an array isn't necessarily a vector. I would expect to be able to do a vector dot product with '*', but of course I can't. And then if you want to make a useful mathematical vector class, the name is already taken. :P

I can't find any information, but it makes me wonder how long the term 'vector' has been used for stuff like that. I know at least Java too has the term, but it could have borrowed it from C++ for all I know.

(As to your last point, that's why the standard committee introduced namespaces!)

I'm not a big fan of plain-ol text serialization of objects though. If the objects are complex, then the format should be structured (like xml or length encoding) such that the program -can- know how much data is intended for each object.

That's true; if you used XML or something you could read out the right amount before calling the object's function. I hadn't thought of that benefit of using that sort of data format.

it could be that my subconscious is rejecting anything related to those long, dark years of GW-BASIC.

Ah, see, most of my basic experience was with QBASIC, which, as much as I could tell with the little GW experience I had, is a whole lot easier to use.

Heh. Remember when /. used to be full of cool geeky coding discussions like this one?

Every now and again they pop up again.

(Now we need someone with an ID of like 17 to pop up and say "do I remember? what do you think?" ;-))

I'll check it out. I use a dvorak keyboard, but have never had that problem (but I tend to be mouse-driven when using a browser anyway).

Ah. That's a mistake I do incessently. And it's really obnoxious because usually if you're pasting something you're in a nice discussion like this, and often you've typed out quite a bit...

Re:Downhill at a fast rate

[Minna Kirai]

Thus it looks like this: printf("%s", someObject.toString().c_str())

To many programmers, the need to use those additional 16 characters everyplace you print something is itself symptomatic of a problem, and cout is valued for alleviating it.

So reentrancy isn't a problem. Dynamic memory still is

If you're willing to make toString non-reentrant, it has a much lesser need to use dynamic memory (especially if it returns a char* instead of a str::string, which you'd want to do anyhow if speed was important)

Re:Downhill at a fast rate

[Chris Burke]

And then there are those of us who actually utilize our brains and realize that if a statement cannot be proven, it is not worth making.

There are many things that are true that cannot be proven. There are many decisions one must make where one cannot prove what the best solution is. There are many things that are simply matters of opinion, which intelligent people can discuss reasonably, realizing you cannot "prove" your position.

Then there are idiots like you, who failed 1st grade "fact or opinion?" exercizes. No, really. This whole thread is little more than a discussion of opinions on coding style and if you think your 'opinion' is 'fact' then you are indeed a retard of the highest order.

That's just my opinion though, lol.

Re:There are plenty of type-safe languages

[msobkow]

Never used (most) of them, so I didn't comment on them.

But seriously, Python?!?!?! It's a spacing-dependent scripting language. Just because it's been used for bigger problems than it was originally intended for does not mean it's suddenly a general-purpose language.

I'm really curious as to why you lump in functional languages with your list of "type safe" languages. The very definition of functional languages is that they generalize implementations instead of defining type-specific implementations.

If removing type concepts and support are your idea of making something type-safe, you should love LISP. You're down to two types: atom and list. And technically the former is just a member of the latter, so you've only got one "complex" object to deal with. :p

Re:There are plenty of type-safe languages

[cquark]

Whether a language is functional or imperative says nothing about its type system. There are imperative languages that are typed much like Lisp, and there are functional languages that are typed much like Ada. However, the vast majority of research into type safety and types in general occurs in functional languages. See Benjamin Pierce's Types and Programming Languages, which uses ML, or almost any paper in the field. It's also worth looking at Microsoft Research's work in types (usually tested in their Cw language, though C# 3.0 looks to be inheriting some of ML's type features.)

Re:Downhill at a fast rate

[jcr]

Do you have any real experience programming with C++ or any real experience programming at all?

Do you have any real experience with software engineering, or have you just memorized enough of the minutia of a horrificaly complex language to think you're hot stuff?

I've been writing code in many, many languages since 1977, and doing so professionally since 1982. I once considered C++ an improvement over C, but I revised that opinion once I saw Objective-C, which made me understand just how badly Stroustrup had botched his attempt to add object orientation to C.

As a specific example, C++ gives you RAII which when used properly helps avoid all kinds of resource finalization errors.

Thrillsville. You're a fan of side-effects. May you spend the rest of your career sorting out static constructors executing before main().

For an encore, want to tell me how templates can save loads of time writing code, which you then lose debugging the fucking templates?

I could provide (as others have) more examples of C++ features (many of which can be used alone) which make C++ often a good replacement for C

No, you can't. You can trot out yet another of the C++ misfeatures that people like you are so proud of, and crow about how they solve issues that I left behind a decade ago.

-jcr

I admit, I exaggerated...

[zaphle]

Well, the heat was on the other day and I must admit I got carried away. In the same way as others have critisized C++ while never having done anything serious with it I was critisizing on the rails framework, knowing to little about it. In retrospect, it actually reduces the value of my other comment - which does hold a lot of truth as for the other part.

The only thing with Ruby is that I fail to see why we would need yet another language - except maybe to introduce object orientation in scripting languages. But I'm not so much in favor of scripts in the first place; configuration files and good software are a better alternative imho. But that's another discussion.

I do seem to have drawn attention with my rant though... ;-)

Re:C++

[zaphle]

> You have to remember who you're dealing with here. Many of Slashdot's commenters are kids who have dabbled in scripting or perhaps...

Yes, that is true, however:

- today's script kiddies on /. may become tomorrow's next generation of programmers. That's what concerns me if now they turn away from C++.

- companies use internet forums as a source of marketing research and can in the long run - wrongfully - get the idea that mature languages like C++ haven't got it anymore and as a result no longer produce software for it (such as compilers, editors, ...)

- IT managers, often having no clue at all about the programming language anymore may use such forums as a source of information to select the language in which to develop.

etc.

I think it is usefull to provide a counterweight in the discussion in order to protect a beautiful language that too few people calling themselves programmers bother to master.

> Andrei's Alexandresu's "Modern C++ Design" demonstrates these features well - that book is just mind boggling

Amen to that. This is the future of programming languages. Nowadays, OO is being taught, in a few years time, aspect oriëntation and policy-based design will be the norm.

The only thing I wish to add is that my rant about Ruby (on or off rails) being retarded was exaggerated. What I should have said is that I don't see why we need another language.

Re:C++

[abigor]

Well, I stick by my comment about a great deal of Slashdot posters. Many are poorly informed about programming. Most don't work as programmers. I wasn't really referring to just "script kiddies" by that. Basically, "hard" things that deviate from the Unix norm (C and Perl, basically) are denigrated. C++ has a difficult syntax, exploits some of the more nether regions of object oriented design, and does not have a Unix-friendly history. Therefore, it is "bad", even to people whose total C knowledge amounts to "Hello World".

I agree about Ruby being Yet Another Language that tries to occupy a niche already filled by Python. That said, there is a great deal to be said for virtual machine-based languages. Python is just awesome. It boils down to requirements, and balancing the demands of rapid deployment with application speed. A VM language with a nifty, list-based syntax (I've heard it said that Python is Lisp with conventional syntax) is just the ticket if app speed is not the highest priority, but time to market is. Then you can profile what you've done and touch up the hot spots with custom modules written in C or C++, if you need to. It works quite well.

I too regard C++ as a beautiful and deep language whose possibilities are only just being explored.

All that said, I work in a startup with nine programmers. What we're doing with Python may allow us to succeed. If we were using a more time-costly language like C++, we would fail. So everything has its place ;)

Re:ditch the long long long long void* already ple

[el_muchacho]

Probably this : http://www.digitalmars.com/d/property.html which is incomparably more elegant than the C way.

what C++ really needs

[penguin-collective]

Those are useful features, but the most important thing C++ needs is a notion of safe modules, analogous to what C# has.

But, frankly, to me, C# is what C++ should be anyway. The only thing that is annoying about C# is its Microsoft connection and the concerns that causes.

Re:C++ template concepts vs. C# generics constrain

[SB7980]

A major difference that I can think off the top of my head is that C++ concepts are not "hard-wired" into the language. People can create non-standard extensions to these concepts and it will "just work".