Slashdot Mirror

Furthermore, we could not port our C++ code to the umpteen platforms that marketing wanted to target.

See, here you have a requirement that was fulfilled by Java. That's a good reason. Also, you don't mention whether the system was completely rearchitected or not. Anyway, from the reasons given for this guy's question, I don't see a clear requirement, just somehow they think things will magically work better in Java. With many of the new libraries and frameworks like Boost and Qt there isn't the disparity as there once was, perhaps. I'd suggest they define their requirements, goals, develop a prototype (keeping in mind Alexander Cockburn's excellent advice on prototypes - if the prototype doesn't work, don't assume everything will magically work once it's in production!), and also, as you did, reuse the libraries as much as possible, using CORBA or some similar solution, until they can switch over completely.

The Eclipse IDE boosted our productivity considerably, and the product is very successful. So I guess it makes sense.

So what were you using before, vi? Emacs? Maybe if you had switched to Visual Studio (and Eclipse supports C++ too) you could've save alot of trouble ;)

Not trying to belittle their achievement, but it's not that hard run faster than straight malloc if you use a memory pool, eg. http://www.boost.org/libs/pool/doc/index.html . In fact, for most applications doing a lot of allocation, you better be doing better than malloc/free as those a very slow.

C++ Coding Standards... by Herb Sutter. This book is a summary of other fine books. See them for details.
Effective C++ by Scott Meyers
More Effective C++ by Scott Meyers
Effective STL by Scott Meyers

Check out http://boost.org/

After reading some of the replies, most people seem to take it for granted that C++ is inherently unstable. The main reason cited is memory leaks. Well, guess what, C++, if written properly, can have garbage collection. The answer is smart pointers. Specifically, check out the boost smart_ptr module. I find that if I wrap all calls to new in a shared_ptr or shared_array, my memory leaks go away. If I need bounds checking on an array, I'll use a std::vector class. And whenever type casting a class, I'll use a dynamic_cast, followed by an assert() of the result. Of course, there's always the possibility of introducing a memory leak when sharing pointers with another library, but at some point, you have to trust some code to be crash proof (like the .NET runtime or the JVM). In short, the key to safe C++ is smart programming techniques.

Also, this is intended to be run primarily under Linux, with the possibility of a Windows port later. Can anyone tell me how good the Mono class libraries are? I would think that, like GCJ, Mono is somewhat incomplete and/or buggy.

• Write unit tests. Make a policy to include one test for each new function/method introduced to the base code.
• Run Valgrind tests on the unit tests periodically.
• Use Smart Pointers, maybe from Boost. Do not allocate new naked (regular) pointers in the heap.
• Re-use code. Re-factor as much as possible. Do not allow for large, obscure, zillion-line functions.
• Use well known, well debugged libraries such as the stlport (for STL) as much as possible. Maybe Qt.
• Be const-correct. Pass const-references as much as possible.
• Make simplicity and readibility of the code a strong requirement. Good code should look damn clean.
• Don't ask in ./, we are a bunch of asses after all ;-)

1. I don't mean to bash your idea, but unless your "modules" are seperated into seperate processes, any part of your code or libraries can affect any other part. Writing a multi-process system has it's own complexities and issues.

And FYI, detecting hangs is a pretty hard problem.

2. Like was said, heavily consider going to a VM langauge (Java, .NET), unless you are willing to invest a lot of extra time in testing, code review, analysis, etc.

3. If you are going to use C++, consider using Smart Pointers, garbage collectors, etc, available for C++ at http://www.boost.org/

4. Test early and often, and aim for full code coverage with code coverage tools. Code you don't run is code you haven't tested. Test also with memory tools such as Bounds Checker. I beleive Linux has robust gcc-enabled tools in this area also. Throw anything and everything at your code, including strange data, bad inputs, etc.

5. Use static code analysis if possible. You will have bugs in your code, period. Historically, this generates a lot of false positives. MS VStudio 2005 Team Edition is not free, but it may be available to you through MSDN or something. This has pretty good basic analysis of common errors available through the /analyze switch. Coverity is also a better ($$$) commercial static analysis tool.

6. Use plenty of assertions in your code

7. Make sure you have a good crash handler setup to generate relevant crash data and hopefully semi-automatically get it back to you.

8. Write solid unit tests WITH your code, and make sure the code is built often /w automated running of unit tests & other tests.

Honestly, everyone seem to believe that all C/C++ code is unstable (probably because of all those people working for companies like Sun/Microsoft, who are promoting The Next Big Thing in Software Development), but it's far more to do with how you go about using the language and its features.

However, it is honestly an improvement on C. I think Bjarne Stroustrup (I'm almost certain I spelled that wrong) said it best: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." (http://public.research.att.com/~bs/bs_faq.html; apart from the quote, it has a whole lot of useful tips).

So, here's my advice, from my experience working in all sorts of languages (professionally I've used everything from TCL through PHP to Java/C#, but at home I use C++ exclusively). This is just my experience, though; take this with the requisite grain of salt:

STL is your friend. I cannot stress this enough. STL allows you to leverage complex containers (automatically resizing lists, hash tables, ropes - which are mega-long strings, etc) with complete type safety: you can create a container for a particular type, and the compiler will balk if you ever try to put something incompatible in. Also, the generated code will be optimized for your particular storage type. In this respect, C++ is actually better than most other languages (only with Java 1.5 and .NET 2.0 do Java and C# implement Generics, and in the case of Java, it's only implemented in the compiler).

Pointers are not always your friend. When you allocate data structures on the stack (e.g. "string blah;"), they will automatically be taken care of by the language. Even if an exception is thrown, these objects will still have their destructor called (which in turn will call all other necessary destructors) and the memory will be deallocated freely.

Of course, this will not work everywhere (large numbers of polymorphic, dynamically allocated objects). But in these cases, you can use helper classes (such as auto_ptr in the STL, or something like shared_ptr from Boost or nsCOMPtr from Mozilla). Look around; lots of other people have already solved this problem. In fact, there are even Garbage-Collection libraries available for C++!

Use exceptions instead of value checking, dammit! Every time you call a function that "returns 0/false/-1 on error" you are exposing yourself to possible bugs. Try to avoid this wherever possible, and try to keep all your OS-specific calls in one spot.

Check out Boost: (www.boost.org) There is a LOT of useful stuff in here, and it will certainly speed up the development process.

Finally, make sure you design it properly! A couple of well-defined interfaces to separate things out will go a LONG way towards simplifying code, as it will ensure there is less coupling between different code modules (i.e. they don't depend on eachother as much, so you can rewrite one without affecting others). This goes for ANY language. C++ doesn't directly support interfaces, but abstract classes will do the same thing.

As for separating modules out, you could try CORBA (as you mentioned): ORBit (orbitcpp.sourceforge.net) is a free implementation (that happens to be used by GNOME). But to be honest you probably won't need to go to this effort. If written properly, your code should be stable enough that you don't even need to separate code out into separate processes. The furthest I'd go in your situation would be to write a command-line application that does all the work, then have a graphical client (although you could write this in a different language; don't get me started on graphics library support under C++) that uses a socket or TCP/IP to communicate with the worker thread. In this case, you could just use a very simple protocol to

*smiles* C++ is a languages in which it is possible--albeit complex--to overcome the language's own limitations and express things with nearly the beauty of Lisp.

http://www.boost.org/libs/python/doc/

You really don't mean C
You really mean C++'s C-compatible subset

Completely worth it for the boost-python interface

You're way off. So far that I'd say you've never read or written modern C++ code. There's a lot of metaprogramming. Look into templates sometime. Try out the STL and the boost libraries. There are significant C++ programs that are not object-oriented and would be nearly impossible to duplicate in C with the same kind of efficiency.

I find C++ to be an ugly, ugly language, but it's also a lot more than the "C + classes" that it used to be.

I think C++ wants to be a low level language that can also do high level constructs.

And I do think this is a great goal, a goal that not many languages are able to do well.
Actually I don't know of any other language that allows you to type raw assembler and at the same time use higher order functions like boost::bind (http://www.boost.org/libs/bind/bind.html).
(Please not that C# and D delegates don't have all the features of bind, that is binding any argument to a precomputed value, not just the first argument).

But while the low level programming in C++ is good, writing high level functionnality is still very complicated. Just have a look at the code at the previously mentionned boos::bind and you'll probably run away (http://cvs.sourceforge.net/viewcvs.py/boost/boost /boost/bind/mem_fn_template.hpp?rev=1.7&view=auto) .

After reading the article, I understand that they are willing to fix this issue, at least partially.

But there are many other issues that preclude it to be really "comfortable" to use as a high level language :

Some of them are old issues, already solved many years ago by a lot of languages like parent post said (introspection (compile-time and run-time), modules, lambdas...).

Some other issues are old but require some carefull thinking to integrate well with C++: multi-methods, garbage collection, mixing functional and imperative programming...

An finaly there are new needs arising like compile-time code generation, aspect-oriented programming, multi-process programming, interfaces (as in the Heron language or the boost interface library, not Java interfaces)...

Of all these features, very few will be added in C++0x.

Other C++-like languages do offer these features or a subset of them.
Here is a short list for reference :
D : http://www.digitalmars.com/d/index.html
Heron : http://www.heron-language.com/
Boo : http://boo.codehaus.org/Language+Features
Nice : http://nice.sourceforge.net/
etc.

But to my knowledge none of them has fully succedeed in offering both a good low and a good high level programming, while keeping the zero-overhead principle of C++ (that is: if you don't use a feature of the language, you don't pay for it).

Seeing this situation, I'm afraid we have only 2 options :
1- split programs into 2 parts: high level and low level, and use 2 different languages for these parts.
2- create a new language

Actually, this is already happening:
I see more and more programmers using high level languages like Python and doing some system or high performance routines in C (with Pyrex for example) and then glue them together.

The languages I mentionned before (D, Heron, etc) are an attempt at creating a successor of C++ but IMHO they are not mature enough and/or feature complete.

So... I forsee option 1 will become more and more comomon for years to come, until we hit option 2, because I think C++ will not be fixed.

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

Have a look at Boost::Lambda and friends. Very handy:

http://www.boost.org/doc/html/lambda.html

Here is one way I used it in a program which generated Perl functions:

for_each(parameters.begin(), parameters.end(),
                  s constant(" my $")
                        bind(&RPC::SymbolMap::value_type::first, _1) constant(" = ")
                        bind(&RPC::SymbolMap::value_type::second, _1) constant(";\n"));

Have fun! (And, there are many "functional concepts" in the STL-- just have a look
and enjoy!)

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).

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.

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.

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.

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?

no variable argument lists in templates.

In 1989 ObjC was a much better OO language than C++ but the world has moved on since C++ was simply an Object Oriented Language.

Personally I think C++ in 1989 was far less defensible than it is now. Compare the NIH Class library of 1990 or so with the 1998 ISO C++ Library, in particular the STL, or far more interestingly the BOOST libraries.

I doubt you've looked very hard or argued with the C++ committee (unless you count trolling comp.std.c++) because here is an obvious counterexample:

http://www.boost.org/doc/html/lambda/le_in_details .html#lambda.lambda_expressions_for_control_struct ures

This index doesn't even contain Boost (http://www.boost.org/) and Loki libraries!

It can't be called 'comprehensive' after that...

There is a great C++ library for shared memory support: SHMEM. It can place complex objects and STL-like containers in shared memory. And it is crossplatform (POSIX and Windows are supported).

And it will soon (hopefully) be a part of Boost!

Was involved with a similar project but we were ripping out crappy Labview apps for a biological research company with lots of robots. Labview is initially easier but you get stuck after a while.

Tool selected was python

Boost Python (http://www.boost.org/libs/python/doc/) is a library for wrapping C++ libraries that already exist to make them accessible from Python. Includes the boost python library. A favorite for wrapping c++ code.

Swig (http://www.swig.org/) is another library for connecting C and C++
code with Python

ctypes http://starship.python.net/crew/theller/ctypes/
ctypes allows loading dlls/shared libs and calling functions in that lib.

PyInline (http://pyinline.sourceforge.net/) is a module which will allow
you to write methods inline in C.

Python can use COM or you can create COM objects. Make apps with simple web interfaces (Medusa) and webservices style interfaces. Also can check out jython etc.

The game will be written entirely from scratch using flexible XML data files, as well as the Python scripting language. Boost.Python (this allows for seamless interoperability between C++ and the Python programming language) will be used as the interface layer between the C++ game code and Python. Python is used in the game for map generation, interface screens, game events, tools, tutorials, etc. If you want to see how this will affect customization of the game (or any other aspect relating to customization).. The new 3D engine will also allow for greater possibilities.

Your criticism of Java for making early, hasty changes is dead on, but I would like to think that the damage was lessened because the changes were mostly confined to libraries - deprecating APIs and the like. Had the changes been to language features, things would have gotten much nastier (as if AWT->Swing wasn't nasty enough!)

But all of these proposed changes are to the C# language proper, not libraries. I think that's an essential difference.

Stroustrup (did you call him "its inventor" because you couldn't spell it either? I had to look it up!) wrote in that link "Library extensions will be preferred to language extensions." Hooray! IMO, it's too little, too late for C++, but I'm happy that he's made that distinction. I hope that the C# folks get that message soon, because they haven't yet.

Compare their approach to LINQ (from, where, select, in, etc. all become keywords) to, say, Apple's new Predicates stuff, which accomplishes the same thing (or at least appears to) without relying on new keywords.

Regarding C++ sublanguages - ok, my Mozilla link wasn't very good. But I stand by my point, that any given project will cherry-pick C++ features to construct their own internal C++ subset. Boost makes heavy use of exceptions and templates; wxWidgets doesn't. The STL barely uses inheritance. If you're programming for Boost, you should try to avoid using catch to catch exceptions. If you're programming for SGI, you shouldn't use C++ strings. Etc.

Java doesn't have issues like these. Java programs by and large all make heavy use of exceptions and inheritance, and recommending that you avoid catch() or strings is unthinkable! Keeping the language features trim and widely relevant is a big help.

You're right that, in principle, new users can learn best practices and start writing in the corresponding shared subset of the language, and really good C++ programmers do. If it weren't so damned hard to become a really good C++ programmer, this might actually happen in practice. Until then, best-practice libraries like Boost will remain out of reach for the majority of C++ programmers

(Though Stroustrup acknowledges that C++ makes things "unnecessarily difficult" for newbies. Maybe there is yet hope.)

Your criticism of Java for making early, hasty changes is dead on, but I would like to think that the damage was lessened because the changes were mostly confined to libraries - deprecating APIs and the like. Had the changes been to language features, things would have gotten much nastier (as if AWT->Swing wasn't nasty enough!)

But all of these proposed changes are to the C# language proper, not libraries. I think that's an essential difference.

Stroustrup (did you call him "its inventor" because you couldn't spell it either? I had to look it up!) wrote in that link "Library extensions will be preferred to language extensions." Hooray! IMO, it's too little, too late for C++, but I'm happy that he's made that distinction. I hope that the C# folks get that message soon, because they haven't yet.

Compare their approach to LINQ (from, where, select, in, etc. all become keywords) to, say, Apple's new Predicates stuff, which accomplishes the same thing (or at least appears to) without relying on new keywords.

Regarding C++ sublanguages - ok, my Mozilla link wasn't very good. But I stand by my point, that any given project will cherry-pick C++ features to construct their own internal C++ subset. Boost makes heavy use of exceptions and templates; wxWidgets doesn't. The STL barely uses inheritance. If you're programming for Boost, you should try to avoid using catch to catch exceptions. If you're programming for SGI, you shouldn't use C++ strings. Etc.

Java doesn't have issues like these. Java programs by and large all make heavy use of exceptions and inheritance, and recommending that you avoid catch() or strings is unthinkable! Keeping the language features trim and widely relevant is a big help.

You're right that, in principle, new users can learn best practices and start writing in the corresponding shared subset of the language, and really good C++ programmers do. If it weren't so damned hard to become a really good C++ programmer, this might actually happen in practice. Until then, best-practice libraries like Boost will remain out of reach for the majority of C++ programmers

(Though Stroustrup acknowledges that C++ makes things "unnecessarily difficult" for newbies. Maybe there is yet hope.)

You could have just linked to the zlib licence at the website for the... Open Source Initiative.

Have you seen the MIT or Boost Software License? They have even fewer restrictions. I think the BSD license is actually less restrive than the zlib license...

This would be a boon to boost::spirit in C++. In fact, they're thinking of reusing the auto keyword to add this functionality to C++0x.

Check out this page to see why it'd be so useful.

I'd love to help you out, but you haven't actually told us what you want improved in C++. Not garbage collection, so D (http://www.digitalmars.com/d/) is probably not interesting to you.

But seriously, I find modern C++ a pretty amazing language, and you can get enormous benefits from libraries such as boost (http://www.boost.org/

The new hand-written recursive descent parser added in 3.4 improved performance a fair bit (making 3.4 the fastest g++ version ever as of the release they claim). The performance for compiling without optimization was improved even more in 4.0. For Gentoo users and other OCD-level recompilers it might not matter, but it does help developers everywhere. This is what I would personally call the place where it matters, end users that obsess over recompiling stuff themselves for no reason can wait.

It is overall a general consensus among gcc developers that performance should be improved. Don't expect C-level compilation speeds from C++ though, it is a heavy language to compile by nature. This keeps getting worse with the increasing prevalence of extreme template metaprogramming libraries like Boost, to a great part in meaningless areas in a quest for performance that will never matter or materialize (I don't claim that Boost or template metaprogramming is a bad thing, just that people obsessivly use it in places where normal coding practices would do just as well except for imagined performance/purity issues).

About how these problems are being addressed, or why they may remain as is:

1. [Member function pointers & lack of delegates]
Derived from boost::function http://www.boost.org/doc/html/function.html, function objects are being added to the standard library. They will support callbacks in a way that is comparable to what is found in C# (and in compiler-specific extensions such as Borland's).
It was always intended to have this as a standard library.

2. "virtual =0" syntax - what's wrong with nice words
C and C++ have always made trade-offs to avoid introducing additional keywords that could break backwards-compatibility.
Personally, I'm not bothered much by this syntactic detail. "#define abstract =0" if you wish. But it would be nice to have explicit overrides vs new function, as supported in other languages and vendor-specific extensions (e.g. Microsoft's C++/CLI).

3. new & delete, delete doesn't take a parameter
If you want both new and delete to take a parameter, what you are looking for is a container that stores your elements.
Low-level usage of new & delete overload is an advanced technique, that only experts should have to use. If it appears clunky to you, don't use it. I understand its logic.

4. typeof operator
This is an extension that is expected to be part of the next C++ standard, and that an increasing number of compilers are supporting. [plus there are today some (ugly) library hacks to provide that functionality in standard C++98]

C++ is capable of much much more than just object-orientated programming. Look at all of the template craziness going on by Alexandrescu for generic programming. See the Boost Lambda library for some functional programming examples. Heck, even wikipedia says "C++ is designed to directly and comprehensively support multiple programming styles (procedural programming, data abstraction, object-oriented programming, and generic programming)" [Ref. And it does *all* of this without any sort of major performance detriment.

I agree that major additions to the language like a garbage collector should be put in a library and not become part of the language to keep the flexibility that has been one of the major advantages of c++. At the same time, the standards committee has moved pretty slowly in adopting new features into the standard library. There's a pretty good community of people creating new public libraries for C++, such as boost, but few C++ programmers take any time to use libraries that are not part of the standard.

I think something like Perl's CPAN would be an excellent thing to have for C++, and many other languages. There's a lot of rich external libraries for C++ that just go unnoticed by too many programmers.

C++ has indeed a steep learning curve, but C++ still has lots of advantages: low memory overhead (even modern Java/C# collectors have LOTS of overhead) and fast execution speed.

It's still impossible to create a snappy application with complex GUI in Java/C# - even the leaders in UI-performance like Eclipse and IDEA are slower than mostly-native VisualStudio (I don't argue about their feature sets right now).

In fact, most of Java/C# people underestimate power of C++. For example, it was long time taken for granted that _runtime_ reflection is neccessary to implement easy-to-use serialization library and RMI (Remote Method Invocation) facility.

But look at this: http://boost.org/libs/serialization/doc/index.html and http://www.codeproject.com/threads/RMI_For_Cpp.asp ! It appears it's possible to implement serialization and RMI in pure C++ without lots of hassle and with full _typesafeness_!

C# people boast that their language has built-in delegates support. And here is implementation of multicast delegates in C++: http://boost.org/doc/html/signals.html

C++ has even some functional programming support: http://boost.org/doc/html/lambda.html and http://boost.org/libs/spirit/doc/phoenix.html

Even such features as pure C++ BNF grammar or FSM automaton are possible.

And so on...

IMNSHO, C++ is now the most powerfull language in the world (only Lisp has a comparable number of supported features).

C++ has indeed a steep learning curve, but C++ still has lots of advantages: low memory overhead (even modern Java/C# collectors have LOTS of overhead) and fast execution speed.

It's still impossible to create a snappy application with complex GUI in Java/C# - even the leaders in UI-performance like Eclipse and IDEA are slower than mostly-native VisualStudio (I don't argue about their feature sets right now).

In fact, most of Java/C# people underestimate power of C++. For example, it was long time taken for granted that _runtime_ reflection is neccessary to implement easy-to-use serialization library and RMI (Remote Method Invocation) facility.

But look at this: http://boost.org/libs/serialization/doc/index.html and http://www.codeproject.com/threads/RMI_For_Cpp.asp ! It appears it's possible to implement serialization and RMI in pure C++ without lots of hassle and with full _typesafeness_!

C# people boast that their language has built-in delegates support. And here is implementation of multicast delegates in C++: http://boost.org/doc/html/signals.html

C++ has even some functional programming support: http://boost.org/doc/html/lambda.html and http://boost.org/libs/spirit/doc/phoenix.html

Even such features as pure C++ BNF grammar or FSM automaton are possible.

And so on...

IMNSHO, C++ is now the most powerfull language in the world (only Lisp has a comparable number of supported features).

C++ has indeed a steep learning curve, but C++ still has lots of advantages: low memory overhead (even modern Java/C# collectors have LOTS of overhead) and fast execution speed.

It's still impossible to create a snappy application with complex GUI in Java/C# - even the leaders in UI-performance like Eclipse and IDEA are slower than mostly-native VisualStudio (I don't argue about their feature sets right now).

In fact, most of Java/C# people underestimate power of C++. For example, it was long time taken for granted that _runtime_ reflection is neccessary to implement easy-to-use serialization library and RMI (Remote Method Invocation) facility.

But look at this: http://boost.org/libs/serialization/doc/index.html and http://www.codeproject.com/threads/RMI_For_Cpp.asp ! It appears it's possible to implement serialization and RMI in pure C++ without lots of hassle and with full _typesafeness_!

C# people boast that their language has built-in delegates support. And here is implementation of multicast delegates in C++: http://boost.org/doc/html/signals.html

C++ has even some functional programming support: http://boost.org/doc/html/lambda.html and http://boost.org/libs/spirit/doc/phoenix.html

Even such features as pure C++ BNF grammar or FSM automaton are possible.

And so on...

IMNSHO, C++ is now the most powerfull language in the world (only Lisp has a comparable number of supported features).

C++ has indeed a steep learning curve, but C++ still has lots of advantages: low memory overhead (even modern Java/C# collectors have LOTS of overhead) and fast execution speed.

It's still impossible to create a snappy application with complex GUI in Java/C# - even the leaders in UI-performance like Eclipse and IDEA are slower than mostly-native VisualStudio (I don't argue about their feature sets right now).

In fact, most of Java/C# people underestimate power of C++. For example, it was long time taken for granted that _runtime_ reflection is neccessary to implement easy-to-use serialization library and RMI (Remote Method Invocation) facility.

But look at this: http://boost.org/libs/serialization/doc/index.html and http://www.codeproject.com/threads/RMI_For_Cpp.asp ! It appears it's possible to implement serialization and RMI in pure C++ without lots of hassle and with full _typesafeness_!

C# people boast that their language has built-in delegates support. And here is implementation of multicast delegates in C++: http://boost.org/doc/html/signals.html

C++ has even some functional programming support: http://boost.org/doc/html/lambda.html and http://boost.org/libs/spirit/doc/phoenix.html

Even such features as pure C++ BNF grammar or FSM automaton are possible.

And so on...

IMNSHO, C++ is now the most powerfull language in the world (only Lisp has a comparable number of supported features).

• A comma-separated list:

  vector<int> v;
  v += 1,2,3,4,5,6,7,8,9;

• A parenthesis-separated list:

  map<string,int> m;
  insert( m )( "Bar", 1 )( "Foo", 2 );

• Repeats:

  vector<int> v;
  v += 1,2,3,repeat(10,4),5,6,7,8,9;
  // v = [1,2,3,4,4,4,4,4,4,4,4,4,4,5,6,7,8,9]

I won't argue the relative merits of C++ to other languages. For many organizations, switching from C++ (regardless of whether it would make things easier) is often not an option, and not considered as an option. I will also not argue whether that is bad.

The fact is, there's a huge C++ user and code base out there, and if they are going to stick with C++, there's exciting stuff coming.

I feel that C++ is having its second coming, primarily due to developments like the boost library and the Modern C++ Design book.

For example, I've been using a combination of boost::function and boost::bind to make powerful, flexible callbacks like nobody's business. Finally, there's a function "pointer" that can work with both freestanding functions, member functions and function objects, and finally there's an easy way to delay calling functions and use closures, respectively. (Also see boost::lambda).

Sure, almost all of this has been possible one way or the other (the flexible callback has been typically implemented via function ptr and void ptr argument, C-style), but it's very refreshing to actually have the code say what you mean: "I want to delay calling this function", or "this callback doesn't give a crap whether the function you're giving it is a member function or not".

Then there are smart pointers, which have easier-to-follow, clearer semantics, and can be used in STL containers and such. No more using easy-to-shoot-yourself-in-foot auto_ptr. It's been possible to write large chunks of code that have multiple "new" statements, but have no "delete" statements, all while maintaining exact control over the memory allocation.

Of course there's more... Maybe it's stuff that LISP/Scheme programmers have been using for ages, but the key difference is I can now apply tools in production commercial C++ code, during my everyday work. I no longer sit and say: "oh, crap, I could really use a closure here." I just do it.

A big problem is that the new features require greater understanding of the language and thus better training of the run-of-the-mill C++ developer. Many C++ developers I encounter do not have the sufficient understanding of these tools, and of the language. We should strive to educate our fellow developers, ... For Great Code!

I won't argue the relative merits of C++ to other languages. For many organizations, switching from C++ (regardless of whether it would make things easier) is often not an option, and not considered as an option. I will also not argue whether that is bad.

The fact is, there's a huge C++ user and code base out there, and if they are going to stick with C++, there's exciting stuff coming.

I feel that C++ is having its second coming, primarily due to developments like the boost library and the Modern C++ Design book.

For example, I've been using a combination of boost::function and boost::bind to make powerful, flexible callbacks like nobody's business. Finally, there's a function "pointer" that can work with both freestanding functions, member functions and function objects, and finally there's an easy way to delay calling functions and use closures, respectively. (Also see boost::lambda).

Sure, almost all of this has been possible one way or the other (the flexible callback has been typically implemented via function ptr and void ptr argument, C-style), but it's very refreshing to actually have the code say what you mean: "I want to delay calling this function", or "this callback doesn't give a crap whether the function you're giving it is a member function or not".

Then there are smart pointers, which have easier-to-follow, clearer semantics, and can be used in STL containers and such. No more using easy-to-shoot-yourself-in-foot auto_ptr. It's been possible to write large chunks of code that have multiple "new" statements, but have no "delete" statements, all while maintaining exact control over the memory allocation.

Of course there's more... Maybe it's stuff that LISP/Scheme programmers have been using for ages, but the key difference is I can now apply tools in production commercial C++ code, during my everyday work. I no longer sit and say: "oh, crap, I could really use a closure here." I just do it.

A big problem is that the new features require greater understanding of the language and thus better training of the run-of-the-mill C++ developer. Many C++ developers I encounter do not have the sufficient understanding of these tools, and of the language. We should strive to educate our fellow developers, ... For Great Code!

I won't argue the relative merits of C++ to other languages. For many organizations, switching from C++ (regardless of whether it would make things easier) is often not an option, and not considered as an option. I will also not argue whether that is bad.

The fact is, there's a huge C++ user and code base out there, and if they are going to stick with C++, there's exciting stuff coming.

I feel that C++ is having its second coming, primarily due to developments like the boost library and the Modern C++ Design book.

For example, I've been using a combination of boost::function and boost::bind to make powerful, flexible callbacks like nobody's business. Finally, there's a function "pointer" that can work with both freestanding functions, member functions and function objects, and finally there's an easy way to delay calling functions and use closures, respectively. (Also see boost::lambda).

Sure, almost all of this has been possible one way or the other (the flexible callback has been typically implemented via function ptr and void ptr argument, C-style), but it's very refreshing to actually have the code say what you mean: "I want to delay calling this function", or "this callback doesn't give a crap whether the function you're giving it is a member function or not".

Then there are smart pointers, which have easier-to-follow, clearer semantics, and can be used in STL containers and such. No more using easy-to-shoot-yourself-in-foot auto_ptr. It's been possible to write large chunks of code that have multiple "new" statements, but have no "delete" statements, all while maintaining exact control over the memory allocation.

Of course there's more... Maybe it's stuff that LISP/Scheme programmers have been using for ages, but the key difference is I can now apply tools in production commercial C++ code, during my everyday work. I no longer sit and say: "oh, crap, I could really use a closure here." I just do it.

A big problem is that the new features require greater understanding of the language and thus better training of the run-of-the-mill C++ developer. Many C++ developers I encounter do not have the sufficient understanding of these tools, and of the language. We should strive to educate our fellow developers, ... For Great Code!

I won't argue the relative merits of C++ to other languages. For many organizations, switching from C++ (regardless of whether it would make things easier) is often not an option, and not considered as an option. I will also not argue whether that is bad.

The fact is, there's a huge C++ user and code base out there, and if they are going to stick with C++, there's exciting stuff coming.

I feel that C++ is having its second coming, primarily due to developments like the boost library and the Modern C++ Design book.

For example, I've been using a combination of boost::function and boost::bind to make powerful, flexible callbacks like nobody's business. Finally, there's a function "pointer" that can work with both freestanding functions, member functions and function objects, and finally there's an easy way to delay calling functions and use closures, respectively. (Also see boost::lambda).

Sure, almost all of this has been possible one way or the other (the flexible callback has been typically implemented via function ptr and void ptr argument, C-style), but it's very refreshing to actually have the code say what you mean: "I want to delay calling this function", or "this callback doesn't give a crap whether the function you're giving it is a member function or not".

Then there are smart pointers, which have easier-to-follow, clearer semantics, and can be used in STL containers and such. No more using easy-to-shoot-yourself-in-foot auto_ptr. It's been possible to write large chunks of code that have multiple "new" statements, but have no "delete" statements, all while maintaining exact control over the memory allocation.

Of course there's more... Maybe it's stuff that LISP/Scheme programmers have been using for ages, but the key difference is I can now apply tools in production commercial C++ code, during my everyday work. I no longer sit and say: "oh, crap, I could really use a closure here." I just do it.

A big problem is that the new features require greater understanding of the language and thus better training of the run-of-the-mill C++ developer. Many C++ developers I encounter do not have the sufficient understanding of these tools, and of the language. We should strive to educate our fellow developers, ... For Great Code!

I won't argue the relative merits of C++ to other languages. For many organizations, switching from C++ (regardless of whether it would make things easier) is often not an option, and not considered as an option. I will also not argue whether that is bad.

The fact is, there's a huge C++ user and code base out there, and if they are going to stick with C++, there's exciting stuff coming.

I feel that C++ is having its second coming, primarily due to developments like the boost library and the Modern C++ Design book.

For example, I've been using a combination of boost::function and boost::bind to make powerful, flexible callbacks like nobody's business. Finally, there's a function "pointer" that can work with both freestanding functions, member functions and function objects, and finally there's an easy way to delay calling functions and use closures, respectively. (Also see boost::lambda).

Sure, almost all of this has been possible one way or the other (the flexible callback has been typically implemented via function ptr and void ptr argument, C-style), but it's very refreshing to actually have the code say what you mean: "I want to delay calling this function", or "this callback doesn't give a crap whether the function you're giving it is a member function or not".

Then there are smart pointers, which have easier-to-follow, clearer semantics, and can be used in STL containers and such. No more using easy-to-shoot-yourself-in-foot auto_ptr. It's been possible to write large chunks of code that have multiple "new" statements, but have no "delete" statements, all while maintaining exact control over the memory allocation.

Of course there's more... Maybe it's stuff that LISP/Scheme programmers have been using for ages, but the key difference is I can now apply tools in production commercial C++ code, during my everyday work. I no longer sit and say: "oh, crap, I could really use a closure here." I just do it.

A big problem is that the new features require greater understanding of the language and thus better training of the run-of-the-mill C++ developer. Many C++ developers I encounter do not have the sufficient understanding of these tools, and of the language. We should strive to educate our fellow developers, ... For Great Code!

Check out the spirit parser for the boost project. Define your grammars and parse your way to the end of the rainbow.

We are using Zope in our current project, because Python can seamlessly interoperate with C++ (http://boost.org/libs/python/doc/index.html).

http://boost.org/ are also migrating to SVN.

Is the type system in Pascal Turing complete in the sense that you can use it to perform arbitrarily complex computations at compile time? If not, then I have a very long list of things you can do with a C++ compiler that you can't do with a Pascal compiler.

Whether you think of them as ugly kludges or not and whether you think of them as an acceptable solution or not (and you certainly have the right to your opinion (informed or not) on both points), the conventional C++ solutions for exception-safe dynamic memory management do work.

And you don't have to "catch exceptions at every point to free stuff".

Well - it's kind of difficult to defend against a criticism so vague and (going by context) inconsistent. I mean, if you're going to say that C++ smart pointers are all ugly kludges (as I can't see a way you'd think auto_ptr is an ugly kludge but shared_ptr isn't), then you should really be comparing it to the alternatives - umanaged raw pointers which (as you've pointed out) leave you fucked in the case of exceptions. And if you think that they're ugly kludges too, then you pretty much think all of C++ is an ugly kludge :). Which is fine with me, don't get me wrong - just that you shouldn't specifically point towards the smart pointer technique as being an ugly kludge of a solution (to the problem of exception-safe dynamic memory management without automatic garbage collection).

There's also the minor detail that writing auto_ptr<T> t; inside one block is much tidier (and, IMO, clearer) than writing T* t = new T(); in one block and then matching that pointer up with a corresponding delete somewhere else. It's also safer - even before you bring exceptions into the picture.

As a final point, C++ does have true garbage collection as an optional extra. I haven't used it myself, but apparently some people do, and it works fine.

if you really are interested in c++ regex, you should get to know Boost. It is a fantastic set of libraries that play nice with the standard c++ library, and includes regexes, parser generators, threads, algebra and probability packages, serialization, custom memory handling, and more.