Slashdot Mirror

You can do functionnal programming in C++ too.
See the Boost library and in particular this paper.

You can do functionnal programming in C++ too.
See the Boost library and in particular this paper.

A downside to QT is that it is not free under windows. While this might be okay with companies, if you ever considered writing crossplatform OSS programs, this can hamper things. There is a project porting the X11 version to windows, so its not a complete roadblock..

Of course there is always GTK which has been known to also run under windows and OS X. It is not my intention to start any flamewars -- I am just pointing out that for those in favour of either toolkit there is plenty of crossplatformability.

If either TK holds any major advantage its that GTK+ natively supports C code, but also has C++ bindings. The signalmm library that came out of gtkmm is actually really nice, and usable for other projects. However, in that case don't forget about boost, which also contains a signal library, not to mention a *really* nice interface to python (which I'm currently using in a project). Just be warned, you need a fast computer for compiling.

A downside to QT is that it is not free under windows. While this might be okay with companies, if you ever considered writing crossplatform OSS programs, this can hamper things. There is a project porting the X11 version to windows, so its not a complete roadblock..

Of course there is always GTK which has been known to also run under windows and OS X. It is not my intention to start any flamewars -- I am just pointing out that for those in favour of either toolkit there is plenty of crossplatformability.

If either TK holds any major advantage its that GTK+ natively supports C code, but also has C++ bindings. The signalmm library that came out of gtkmm is actually really nice, and usable for other projects. However, in that case don't forget about boost, which also contains a signal library, not to mention a *really* nice interface to python (which I'm currently using in a project). Just be warned, you need a fast computer for compiling.

A downside to QT is that it is not free under windows. While this might be okay with companies, if you ever considered writing crossplatform OSS programs, this can hamper things. There is a project porting the X11 version to windows, so its not a complete roadblock..

Of course there is always GTK which has been known to also run under windows and OS X. It is not my intention to start any flamewars -- I am just pointing out that for those in favour of either toolkit there is plenty of crossplatformability.

If either TK holds any major advantage its that GTK+ natively supports C code, but also has C++ bindings. The signalmm library that came out of gtkmm is actually really nice, and usable for other projects. However, in that case don't forget about boost, which also contains a signal library, not to mention a *really* nice interface to python (which I'm currently using in a project). Just be warned, you need a fast computer for compiling.

Soya 3d This is a 3d library for python built on top of openGL. I find it's a lot higher level than calling OpenGL directly. It handles collision detection, rendering, animation, model loading etc, with a very shallow learning curve but still flexible.

A little off-topic from Java, but modern C++ from my experience is quite portable (at the source code level)---as long as you don't use Microsoft C++. If you stick to the STL and any number of free C++ extension libraries it works pretty well. We have very large and complex code that works equally well under Linux/gcc3, HP-UX's C++ compiler, and AIX's C++ compiler.

C++ portability seems to mostly be a big issue for those how are using old pre-standard compilers, or are using Microsoft compilers and using their proprietary extensions without knowing it.

Aw, c'mon now, props to Larry Wall and the fellas.
Perl pushed the envelope on language design. Later efforts may have been less ideosyncratic, e.g. python, but, hey.
Perl6, if you've been following the summaries, P6 will raise the bar yet again.
I just wonder if this parrot chassis underneath will permit something as groovy as Boost.Python.

1) A kid (or adult) with some brains, but little actual low level computer knowledge can come up with an interpreter

On that note, interpretation also gives a language designer an amount of conceptual freedom by abstracting the architecture. That's why languages with paradigms that don't translate well onto von Neumann-y notions (eg, LISP or Prolog) are interpreted as a rule. Interestingly, some of these concepts can then migrate into compiled languages, for instance the Boost Lambda library for C++.

In C++ the way to work around lack of of finally{} clause is to use smart pointers, which deallocate their resources as soon as they go out of scope. Your main point however, which is that exception handling in C++ is not trivial is absolutely correct (as opposed to in Python, say).

There is only one kind of smart pointer in the standard library, but many more are available in Boost.

The main advantage of templates vs. #defines is syntax checking by the compiler. They also allow you do to pretty spectacular things like compile-time evaluations of complex expression (template meta-programming). I didn't think generics could do that, but maybe I am mistaken. Some libraries are now using template meta-programming for things such as matrix operations optimization (avoiding duplication and transposition, in particular).

Cheers

An addendum: your experiments don't have to be anything spectacular. Here are a few:

• Try adding a few printk statements throughout the code, decide when you expect they will print and what they will say, and confirm it.
• Try tuning a sysctl or hardcoded value. See how it affects performance. Do microbenchmarks or benchmark real systems. Make pretty graphs. (Graphs are fun!)
• Add a likely() or unlikely() option to help the compiler's branch prediction. Again, test the performance. Or take one away - it's possible someone was wrong about the performance

• compile with -ftest-coverage to see what code is run and design unit tests to that uses every line. This will help your understand, could find existing bugs or dead code, and will help you be confident in your changes if you later make any.
• compile with -ftest-coverage -fprofile-arcs to see what code branches are very likely or unlikely to be taken, then use likely() and unlikely() to change the branch prediction. Benchmark the results.

Another project I've considered is adding likely() and unlikely() equivalents to boost. A lot of people use this code, so increasing its performance a little would be pretty beneficial.

1.) Type checking is much weaker? How could

int i = container.get(0);

be weaker (where container is a template instanciated for int specifically, so you get compile time error) than

Integer i = (Integer)container.get(0)

where you'll get a runtime cast exception if you happen to be unlucky?

2.) Compile time checking of capabilities can be done with templates. Check out for example the Concept Check library of boost.

3.) reusability rubbish? not if you want a type safe, efficient container library for example (no, the current java library is not type safe. See point 1. And it's not efficient either (try storing ints in a HashMap for example)

4.) I've never heard about any such constraints for banking software, but you might be right on this one. I'd be surprised though, since I'm pretty sure some banking software is written in c++, and the standard library is using templates heavily) Templates creating security holes are beyond me, though...

5.) Compilers getting slower doesn't really matter. Correctness proof is not possible in general (at least, not feasible for real world applications). Templates make this maybe twice as hard. So?

oh well, at least your post was not "informative", but "interesting"...

cheers,
mitch

The advantages you've listed just aren't that important against C++:

• Compex numbers aren't built-in, but who cares? C++ classes let you do anything you can do with a primitive type, both as far as optimizations are concerned and syntactically (through operator overloading)
• Likewise, multidimensional arrays can have all the syntactic sugar you want, through magical things like boost::multi_array.
• I don't know as much about the parallel stuff, but obviously a lot of thought has gone into doing that kind of thing in C++. Intel also has a compiler that will auto-parallelize C++ (and Fortran), though I've never played with it.

It's very commonly said that Fortran is faster than any other language. I don't think that's actually true. This article, written back in July '97, talks about a lot of other techniques possible in C++ to close the performance gap and even outperform Fortran. And in the seven years since, C++ compilers have improved greatly, and these techniques have been widely adopted. There are a lot more papers here.

I admit, the template syntax is painful at times, but it works, and I do believe it'll get better. Take a look at boost.org, there they do a lot of neat stuff, and when they hit some barrier, those barriers will be dealt with in the next c++ standard. At least that's the point, as far as I know.

I haven't used exceptions really in C++ (I've been doing java for some time now, and before that exceptions in c++ were not really supported), but I'm going to do some c++ development again for fun, and I'd really like to know what's wrong with exceptions. Thanks

cheers,

mitch

Some points:

• OO-programming and C++ classes.

  Everybody thoughs that C++ should be an OO language. C++ is quite bad about OO (as imho is also Java... the main Java advantage is having an inbuilt garbage collector, so you don't need to create you're own reference counting template or something similar, as in C++). OO wants more dynamically typed language than C++ and its alikes are. Statically typed OO problem is too much casting into derived types (dynamic_cast in C++ for example).

  The fact is that C++ "classes" are very good for almost anything else but OO in the classic sense (which uses class hiearchies). They are a great way to create a custom data types (about as some smart structs). They can be used for creating something like continuations and for giving some temporary "static" variables to some function group (which are then the class members).

• Resource allocation is initialization. This shall be burned into every C++ programmers brain...

  If you have something that requires allocating resources and freeing them, it is usually good idea to put it into an C++ class and use constructor/destructor for allocating/freeing the resource. This is very useful together with objects put into stack - the resources are then automatically freed, when you leave the block.

  In a good C++ program you find very few explicit delete usage - and most of these delete's should be in some destructors.

• Resources shouldn't be "owned" by alone pointers in stack. This creates exception nightmare, where you must use try-catch to free resources when exception comes. When pointers are in wrappers, everything is nice and exceptions cleanup by themselves (since all objects in stack will be destructed, when exception flies through).

  As a sidenote, the resource allocation is initialization thing is the reason why finally is left out of C++ language - finally is not needed when used resources are freed by stack object destructors.

• Error handling should be done using exceptions in most cases.

  For some reason many C++ programmers ignore exceptions and make their lives hard with this. Since the STL (and new) uses exceptions you cannot avoid them anyway. Ignoring standard exceptions just leads to a flawed program. Inventing your own error handling instead of using exceptions is just an unnecessary additional work to recreate a feature that is inbuilt into language and leads usually to error handling code bloat.

• C++ compiler creates a working copy constructors and assignement operators for you, when all your class members are value types. And any class with working copy constructors and assignement operators is a good value type for this.

  This is a very useful, but quite a few C++ programmers seem to know about it. It basically means that you may assemble you're data types with very few trouble. The fact that pointers are not a good value types in this context can be often over come using reference counting wrappers for them (but it is usually a good idea to threat these shared pointers as read-only, unless you implement copy-on-write in you're pointer wrapper).

• Templates are one of the most useful C++ features, giving an ability to reuse code for different data types. STL is a fine example of template usage and libraries like Boost give an idea about what can be done with templates. It is often useful to create some template classes/functions for handling similar operations on different data types (and avoid things like void* and casting in the code).

Sorry for bad spelling, I'm not a native english speaker.

the meta-object compiler

non-standard classes, e.g. string

The bad news is that the lack of standardization plays right into Redmond's game. "Keep them injuns fragmented, and we'll never get pushed into the ocean".
It hurts Open Source in general, and C++ in particular.
Qt is clearly a fantastic toolkit, if the success of KDE is any measure.
Now, if TrollTech had hair one, they would tidy up their free version (in terms of code and licensing) and submit it to Boost. Probably partitioned into a 'lite' version for cross-platform purposes, and a 'pro' version to keep the business model afloat.
Juat my $0.02

SWIG is nice, but you might also want to checkout Boost.python. This combined with Pyste truly make for some tight and clean integration.

SWIG is nice, but you might also want to checkout Boost.python. This combined with Pyste truly make for some tight and clean integration.

Boost.Python
I sort of hope that Parrot will help Perl overcome its introversion, and let it integrate more readily with other languages.
I think that C++ and Python form a dynamic duo. You can put the effort into compiling items that benefit from such, and glue them together in Python most agreeably.
The C++ standard library focused on Platonic abstractions, but Boost is pulling C++ in more mainstream directions. And that's a beautiful thing.
While issuing random plugs, check out Leo. It's not too often you see a fresh interface on an editor.

boost.python, one of the boost libraries, makes binding to python very easy.

It uses C++ and lots of template mojo, but you don't really need to understand all that to use it.

Well, I think the idea of a C++ desktop is just swell, but the whole meta-object compiler thing is a turn-off, as is the non-standard string class, and such.
IANAT. Qt has to be understood in the context that it was way ahead of its time with the signals/slots business, far ahead of C++ standardization. Props to Trolltech.
Nevertheless, the better long-term bet seems to lie with boost, wherein is much goodness, at least on the backend. There was some fascinating discussion of a boost interface library a while ago, which served to point out the diversity of the requirements, but it doesn't seemed to have condensed as far as vaporware yet. So Qt's "yeah, but we happen to exist" argument trumps any theoretical whining I can offer. ;)
One wonders if any Trolltechies read /., and if they can comment on the likelihood of Qt getting more in synch with mainstream C++.
Disclaimer: my knowledge of Qt comes from reading a circa-KDE 3.0 tome.

I think Boost.Python does what you're asking.

C++'s templates are basically textual substitution, you can't type-constrain template arguments, you just have to see if it works;

It's trickier than that. Some libraries contain inline functions. In fact, some libraries use hardly any "out-of-line" functions.

So your compiled binary can include a bunch of code copyrighted by someone else. Isn't that a derived work?

It is nice that I can map a "int" to a register on DSPs (instead of having to have my 20-bit architecture emulate a 32-bit one with 2 registers).

The worst thing is that C++, AFAIK, is still even more of a mess than C in this regard.

At least with C, it is possible to write portable code. With C++, it's much much harder. Since the C++ standard apparently still ignored this issue, you're best off using the (awesome!) Boost libraries that bring the best parts of C to C++, such as their cstdin.hpp header file that takes care of fixed-sized types.-

They're difficult to master for the library developer, for sure, but they provide unprecedented ease for the library user.

The idea has definitely caught on with other languages, too.

No, I cannot agree with you at all that C++ is broken.

It is "complicated" due to its expressiveness. The STL is generally well designed (and the folks at Boost are continually improving upon it).

It is popular because its templates allow generation of high quality code that matches C for speed, but is light years beyond in type checking (provided that you tell your compiler to do it). It's also popular because it's OO works well - it's a common misconception to cite C++'s lack of a single root object hierarchy as a flaw - Bjarne Stroustrup gives some compelling reasons for C++'s lack of it (in his FAQ - can't remember the URL).

I do admit that I miss anonymous classes and functions in C++, and I often find it easier to write a for loop than to use something like foreach (which takes a start and end iterator and a function to apply) simply because writing a function is a pain if you just want to print names in a list!

The final reason for C++'s success is that it is not bound to a particular vendor, and this is a major deficiency of C#. I'm not blasting M$ here - this is true for any vendor.

Between the STL and Boost Smart Pointer's, I haven't had a memory leak or buffer overflow in a while.

Aside from the Comeau compiler, you have Microsoft's, Intel's, IBM's, and G++.

I believe that MS VC++ 7.0 (or whatever it's marketed under now) and G++ are the most compliant of the bunch. IBM's compiler may be standard, but their linker is anything but -- thanks to it we can't use dbx or gdb on our code base (both simply core either while loading the core image or when you do a "where"; IBM's dbx occasionally works but never gives proper symbol names and setting break points is impossible). I don't have any experience w/ Intel's compiler so I can't say there. HP's compiler is abysmal.

One interesting place to look at compatibility is the Boost library -- Boost is a rather large C++ library being developed by some of the big names in C++ that may wind up in the next standard -- and how well it compiles on various platforms and compilers. Check out the compiler status page. It's certainly not a definitive test of what is and is not standard, but it's a data point.

You're certainly correct in that C++ compilers and their STL libraries have come very far in the past couple of years. One of the worst (Microsoft) is now one of the best -- largely due to them hiring a project lead that's a STL advocate.

Aside from the Comeau compiler, you have Microsoft's, Intel's, IBM's, and G++.

I believe that MS VC++ 7.0 (or whatever it's marketed under now) and G++ are the most compliant of the bunch. IBM's compiler may be standard, but their linker is anything but -- thanks to it we can't use dbx or gdb on our code base (both simply core either while loading the core image or when you do a "where"; IBM's dbx occasionally works but never gives proper symbol names and setting break points is impossible). I don't have any experience w/ Intel's compiler so I can't say there. HP's compiler is abysmal.

One interesting place to look at compatibility is the Boost library -- Boost is a rather large C++ library being developed by some of the big names in C++ that may wind up in the next standard -- and how well it compiles on various platforms and compilers. Check out the compiler status page. It's certainly not a definitive test of what is and is not standard, but it's a data point.

You're certainly correct in that C++ compilers and their STL libraries have come very far in the past couple of years. One of the worst (Microsoft) is now one of the best -- largely due to them hiring a project lead that's a STL advocate.

Has he now seen the error of his ways? Is contracting (in any form other than an assert) going to get added to C++?

I have been thinking of learning Python ever since I found the Boost.Python library at http://www.boost.org.

I suppose that it is time to go find a good tutorial. Anybody had luck using C++ and Python together with this?

I have been thinking of learning Python ever since I found the Boost.Python library at http://www.boost.org.

I suppose that it is time to go find a good tutorial. Anybody had luck using C++ and Python together with this?

Its support for functional constructs is very limited. In particular, the lack of type inference and proper lambdas makes functional code painful to write.

Its support for functional constructs is very limited. In particular, the lack of type inference and proper lambdas makes functional code painful to write.

Its support for functional constructs is very limited. In particular, the lack of type inference and proper lambdas makes functional code painful to write.

Its support for functional constructs is very limited. In particular, the lack of type inference and proper lambdas makes functional code painful to write.

You can get the same effect using Smart Pointers and not give up the control that using a garbage collection system entails. See Boost and Alexandrescu, Andrei. Modern C++ Design. There is also a nice article on CUJ.

What are your views on the difficulty of writing correct code in C/C++ versus say Java or C#?

The question wasn't directed to me, but I hope you won't mind if I chime in here.

Modern C++ allows you to cut out whole classes of errors by following just a few simple rules. If you're interested, here are some starting points to consider.

• You should almost never use a "raw" array. Arrays are a primitive, low-level tool. In higher level code, they are best replaced by container classes. The standard library provides several useful basic cases: vector, string, list and map are perhaps the most useful. These are all more powerful and safer than raw arrays.
• You should almost never use a "raw" pointer. For many tasks where pointers were used in C, references are a cleaner and safer solution in C++. For simple dynamic memory allocation, "smart pointer" classes are both more powerful and safer: the standard library provides the somewhat limited auto_ptr, and several more are widely available. For complex data structures involving many indirections, smart pointers are a good starting point, and may be enough even in quite complicated cases. If not, you can build your own tools using the same ideas, and then use these in your higher level code.
• Understand the "resource acquisition is initialisation" idiom, and use it religiously. It's mentioned in several of the better textbooks, and I'm sure a quick web search will find you an explanation. This idiom is the basic reason why containers and smart pointers are safer than the raw equivalents. Using it always will pretty much guarantee that you never leak a resource -- memory or otherwise -- from a C++ program again.
• Read Josuttis's book on the standard library.
• Visit Boost. There are many wonderful toys here, some fixing basic limitations the standard library forgot, some useful general purpose tools (such as various smart pointers, as mentioned above) and some just awesomely powerful extensions (full blown libraries for regular expressions, expression templates, and other goodies).

If you're interested in learning how to program C++ safely, cleanly and efficiently, I promise you that all of the above are worthwhile investments of your time. When you're done, you'll find it even more offensive that so many C++ programs have memory leaks, buffer over-run vulnerabilities and seg faults through following NULL pointers. Your programs won't, though.

With the first example I belive the point is that the string and vector classes will clean up themselves when they go out of scope (when their destructors are called). STL is very helpful especially when supplemented with the Boost libraries.

Perl, cpp, m4, C++, and other code-generation systems do TEXT substitution/rewriting.

There is a lot more going on here (for instance) than text-substitution. The syntax for C++ templates may make LISP's seem downright pleasant, even for a LISP-hater, and some of the techniques border on language abuse, but it forms a full-blown compile-time functional programming language that integrates fulling into the C++ type and class mechanism. The Boost library collection is full of such metaprogramming, such as this.

-Ed

Perl, cpp, m4, C++, and other code-generation systems do TEXT substitution/rewriting.

There is a lot more going on here (for instance) than text-substitution. The syntax for C++ templates may make LISP's seem downright pleasant, even for a LISP-hater, and some of the techniques border on language abuse, but it forms a full-blown compile-time functional programming language that integrates fulling into the C++ type and class mechanism. The Boost library collection is full of such metaprogramming, such as this.

-Ed

> Every bit of the code that is in Qt to
> implement signals/slots is standard ISO C++
> code. No different than with Boost::Signals

But Qt code uses non-standard keywords such as "public slots" and "signals". Code which uses these keywords need to be fed into a preprocessor which then converts that code into legal C++. The Comeau C++ compiler is a C++-to-C translator. Your argument is like saying any C++ code is perfectly legal ANSI C code; you just have to feed the C++ code into a "preprocessor" (such as Comeau's compiler) first before you actually compile it.

A signal/slot implementation like boost::signals, on the other hand, is ANSI C++ code.

> But it can't.

What about boost::signal?

Without debating the whether C++ is the best choice for beginners, I wish new books on the subject would stop rehashing the same old concepts and methods - not everyone is a C programmer trying to transition to C++. There are a lot of areas that merit greater attention and that will get beginners started on the right foot - and messing with raw pointers isn't one of them.

On top of trying to get the basic OO mindset accross (yes instantiation, polymorphism and encapsulation are big words but the concepts are essential and not that difficult to explain), I'd like to see some more modern and useful concepts explored in depth. For instance:

• Everything you can find that has to do with automated memory management (smart pointers and such)
• The STL. The STL. I know it's a rite of passage, but I'm tired of seeing every newbie struggling with his own linked list implementation
• Reuse. The Boost library can teach you a lot about this and demonstrate that focusing on your problem is more fun than writing boring code that's been done a million times before
• Design patterns. At least an introduction, dammit.
• Generic programming, in general ;)

Just my $0.02 for potential authors out there.

You could probably implement inline regular expressions in C++ using expression templates, actually. Check out Spirit, which gives you inline BNF grammars in C++.

typedef std::vector<std::pair<std::string, std::string> > StringPairVec;

StringPairVec tuples = AddressBook.getEntries();
for (StringPairVec::const_iterator i = tuples.begin() ; i != tuples.end() ; i++)
std::cout << i->first << " lives in " << i->second << std::endl;

I see Perl 6 as kind of a pantheon of programming gurus, and you can subscribe to whichever you like (or tell them all to screw off). The most important thing about Perl 6 is you can use whatever programming style suits you best. In a corporate environment, that style can even be dictated down by the powers that be, too. If you're one of those people that thinks that Lisp (et all) is (or is not) understandable, or thinks Java is a brain-dead C++, or that C++ is error prone Java, then Perl 6 may not be for you. You let (percieved) flaws obscure the important benefits, and as a result you miss out. Objectively, you would be examining the trade off between learning curve and increased efficiency over the time period of the project. In many cases, it is in fact better to stick with the tool you know, even if a different tool would be twice as effecient. Since it's just not possible to learn every single tool available, as professionals, we have to pick the most effective set of tools that we care to know given our interests and other expertise. This brings us around to the great thing about Perl 6: in one cohesive, sensible framework, it gives you really broad coverage. You don't have to learn it all at once--you start out using Perl 6 like Perl 5; then when you decide you want to do some lispy type things, you don't have to learn Lisp and a whole new toolchain, you can learn to do lispy types things in Perl. If you want to do things that would be well suited for C++ templates, you can learn the Perl 6 mechanisms for it instead of undertaking C++. And what is really, amazingly cool is that Perl 6 is shaping up to be a cohesive, well considered framework; it's not a jumble of competing ideas that don't play nicely with each other.

If you've worked with C++ templates and metaprogramming, then you certainly understand the benefits being offered by a lot of the Perl 6 constructs. But the Perl 6 way is much more comprehensive, direct, clear, and intentional. Everything with blocks, anonymous subs, closures, multi methods, named parameters, operator overloading, and macors offers unbelievable oportunities for meta-programming. Once Perl 6 gets rolling and starts developing its own equivalent of Boost, then programming will never be the same. Boost changed everything already, but you've probably never heard of it; but Perl 6 will have mainstream appeal, acceptance, and use that Boost will never have.

Check out Artima if you want to see Bruce Eckel's take on the Python language which, incidentally, with the addition of things like a logging API, and with long-existing additions like Jython, is beginning to look more and more like a viable competitor to Java.

Why?

Python carries a LOT of the same advantages, but with a dramatically accelerated prototyping and general development speed, and a few tricks of its own. Plus, via Boost, it interoperates with C++, too. I'm an avid Perl hack, but I have to admit that Python, which even has a whole API for basic game programming is looking more and more attractive for quite a number of things.

Download soon and often.

When are they dumping the Meta Object Compiler (moc) and switch over to Boost.Signals?