Slashdot Mirror

Though its not obvious how to do it, it is possible to make some assertions work at compile time in C++.

For a good example of this check out the boost library and look for static_assert.

The problem with on-line C++ is that many people who claim to write about it don't know their subject, and consequently write superficially correct code that actually sucks. I'm sorry to name names, but the much-recommended-here CPlusPlus.com is one such site; their "Hello, world!" program at the start of their isn't even correct. I'd give sites like that a miss if you're seriously interested in learning C++.

One good source of information about C++ (and many other programming-related subjects) on-line is the related Usenet newsgroups, particularly the group specifically for learners if you're just starting out, or the moderated C++ group for more advanced subjects.

Many of these groups also have helpful FAQs, available (as usual) via the Internet FAQ Consortium. Again, for those just starting out, I'd particularly recommend the alt.comp.lang.learn.c-c++ FAQ, which has links to helpful on-line resources, free compilers, etc.

There are a few web sites of which anyone in the C++ field should be aware.

• You can get generally pretty sound book reviews for thousands of books on these and related subjects at the Association of C and C++ Users web site.
• Herb Sutter's web site has lots of informative and thought-provoking C++ articles by one of the guys who's advanced C++ programming technique a lot in recent years.
• Similarly, Scott Meyers' publications page has many worth-reading articles on C++.
• It would be remiss not to mention Boost, a collection of very good general-purpose C++ libraries. If you can't see how to do something with the standard stuff, the answer -- or a useful idea to find it -- may well be here.

There are a few decent on-line references to the standard library:

• Dinkumware make a standard library implementation, which is shipped with Visual C++ amongst other things, and provide some helpful documentation on-line. (NB: The version that shipped with VC++ 6 was flawed in many horrible ways, but that wasn't really Dinkumware's fault given the compiler limitations at the time when they wrote that library; please don't judge them by that alone.)
• SGI's implementation of the "STL" parts of the C++ standard library is excellent, and well-documented on-line.

About the only decent on-line C++ tutorial I know of the electronic version of Bruce Eckel's "Thinking in C++" books. You can find a complete copy of these, and several of his other books, at his books web site. (He also has books on Java, C#, Python amongst other things, and all of his work I've read has been reasonably good.)

First, thanks for replying. Seems like we'll probably agree to disagree, though :)

The subtleties you have worked hard to understand and work within don't exist in other, more perspicuously designed GUI frameworks.

Mostly, the subtleties I have worked hard to learn are subtleties of GUI programming in a WIMP environment. There's pretty much no way around knowing what events are generated for various things and what data comes along for the ride. Whatever your environment is, you will occasionally need to know what the construction order is of your windows and other frustrating items. And I won't believe for a minute that there exists a toolkit worth using without subtleties.

I would rather have something behave the right way the first time than in some peculiar way to be vaguely deduced/read about.

I find that newbs tend to get confused/frustrated because it's so easy to get started with appwizard that they get misled into thinking that you don't have to know anything to make it work. A lot of them, being fresh out of school, have never done event driven programming, and are just overwhelmed by the whole model ("where's the f*#@ing main() function?!?"). These people should do some windows programming straight to the API before trying MFC or some other toolkit, because they will find any machinery peculiar and has to be read about.

I understand your affinity for MFC: once you've gone through the pain and considerable expense in time of learning it, it's hard to believe there's something else out there that's much simpler to use and equally, if not more, powerful.

Let me clarify that I do not like MFC. It has the same problem as pretty much every toolkit that I've worked with: it bundles a GUI toolkit with an application framework with a bunch of utility classes. The GUI toolkit is pretty reasonable given the windows API it has to work with. The app framwork kinda sucks, and I don't like the utility classes much. Now, while people like boost.org are working on utility classes that will rock, they're not ready yet, and nobody that I know of really cares much about app frameworks.

Finally, porting fromanything to anything is by definition more work that simply writing that one thing once.

On the surface, this seems like a truism. However, lets say that you have a tool that will save 10% of your development time if you use A instead of B, and that you already know A but not B, and you can port from A to B without really having to know a lot about B, and so you can port in about 1% of the development time. In other words, I think that given this guy's situation, it is very reasonable to expect that appwizard and classwizard will save him more time than he spends porting to wxWindows.

This is a valid point. I made the assumption that hardly anyone with this cursory a knowledge in GUI programming on windows would be creating yet another chess program for commercial purposes.

Consider the possibility that he's using this as a learning experience for a future commercial project. Not necessarily a deciding factor, but you do want to keep in mind how your skillsets will help you in the future :)

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

Look at the Boost++ library as an example of using C++ to get levels of numerical performance near to Fortran--which was almost impossible with plain C.

Either you're confused or had a temporary brain-fart. Boost is a library of classes, algorithms, and other features that, in a general consensus, developers feel should be added to the standard C++ library. Blitz++ is a numerical computing library based heavily on C++ template expressions and specialization.

What's shocking to me is that almost no open source authors or advocates give a hoot about automated testing of any kind. The only free software I've found with a test suite is gcc. As much as I hate to say it, there's a good chance that the relative inexperience of most open source authors is a factor here.

Perl is really good about this. The Test::Harness and Test::More modules make it very easy to write test suites, so CPAN modules have lots of automated tests. It might even be a requirement to get a module into CPAN; I'm not sure.

PostgreSQL has regression tests.

There's a really nice test environment for Java code called JUnit. Lots of stuff is using it. Lots of articles about how to write effective tests. There's a project to develop mock versions of common objects (servlet requests, SQL queries) that fail in interesting, predefined ways. I'm using a C++ workalike called CppUnit in one of my projects.

The Boost code has automated testing.

There's a project called qmtest.

The Wine people have recently started using regression tests.

Writing STL-style iterators is, in my opinion, an enormous pain in the ass, involving lots of tedious coding.

... or half an hour's worth of less tedious coding using the Boost iterator adaptor library?

There's some stuff that didn't make it into the ANSI C++ standard that probably should have. Stuff like reference-counted smart pointers makes doing things a lot easier sometimes, especially once you start throwing pointers around inside STL containers. The stuff is quasi-standard; many of the driving people behind boost.org were members of the ANSI committee itself. Definitely worth a look.

www.boost.org

Regular expressions are, in all likelihood, going to be included in the next version of the Standard Library. The standardization committee is meeting in Curacao discussing it right now. There are already excellent C++ libraries for doing regular expressions that integrate cleanly with STL. There is regex++ and GRETA, take your pick. I wrote GRETA, and it passes PCRE's regression test, FYI.

I just wanted to point out that asking about something like the STL here on /. will not give you much breadth of opinions on the matter. When it comes to programming and software development, /. has a high concentration of scripting language users for web site backends and administrative tasks, and a relatively small number of "application" developers. There are also a disproportionate number of systems programmers. From reading /., you might get the impression that C++ is not very widely used. While this is true in the Open Source world where there are many *many* more viable options, commercial software development is still pretty dominated by C++ with Java seeing use in some sectors. So what's the takehome message here? Even given /. bias, you're still getting a pretty positive response to STL. Anyway, here are a few things you should know:

1) Get STLPort. Use STLPort. STLPort addresses many, many, STL issues. They add extra nice classes like hash tables. STLPort is thread safe. STLPort has nice extra debugging features. STLPort has readable code. STLPort is PORTABLE (thus the name!). OpenOffice uses STLPort, in case you're still dubious.

2) Get a couple of STL books. There aren't any really good ones (IMHO), but it's handy to have a printed reference with some examples.

3) You wanted downsides, so here's one. You will have to learn STL. Not the library, but the techniques--the API is easy. You have to write your own C++ classes well to take really good advantage of STL. The way you leverage the STL for absurd productivity is through generic programming and STL's pluggable component architecture. Still, though, even you all you ever use is map, string, and streams (or some other subset), you'll probably become a convert.

4) STL will keep getting better to use. Other people have mentioned it, but look at Boost for some ideas about where STL is headed. Also, the compiler people are aware of and are working on the error message and debugging problems. Both VC++.Net and gcc 3.x are making progress here.

Kitchen sink syndrome: There are a lot of features in STL, and to use some of them you need functors, etc. Sometimes it's just easier to read if you use a normal for loop instead of using for_each, etc.

This is a known problem in the STL. As some gurus have put it, "STL is not STL enough." What that means is that the STL falls short of using the full power of templates. Check out the Boost bind library (and later, the Lambda Library) for a solution to the for_each problem.

verbose type syntax: When you use the containers, like (say) std::vector, you have to declare your iterators as:

std::vector::iterator i;

If you change to a std::list container, you'll have to change your declarations. Of course, you can mitigate that by using typedefs, and then you only have to change the typedef, but it can still get a bit wordy.

typedef makes this a non-issue. I find the "wordiness" a nice form of in-code documentation.

unexpected results: Understand the difference between remove() and erase() in the containers.

It's unfair to label this "unexpected," but you're right in that knowledge of the API is important. As it is for all libraries.

The benefits of using STL are wonderful. If you write your custom containers/streams/etc. using the STL interface, you can seamlessly use the algorithms portion of the library.

This is the real power of the STL. IMHO too many people concentrate on "containers of X." This goes doubly for the C++ template engine as a whole.

I recommend reading the first part of Generic Programming and the STL. It'll help you undestand the thinking behind the design.

Then get Modern C++ Design , join the Boost mailing list and take it to the next level.

The STL is great. Some of the stuff coming in the next library standard revision is even better. The stuff in Boost is outstanding.

The biggest problem I have had with the STL is convincing people to use it. The available implementations could be better (smaller, more template specialization, etc.) but the savings in programmer time is well worth the slight cost.

Kitchen sink syndrome: There are a lot of features in STL, and to use some of them you need functors, etc. Sometimes it's just easier to read if you use a normal for loop instead of using for_each, etc.

This is a known problem in the STL. As some gurus have put it, "STL is not STL enough." What that means is that the STL falls short of using the full power of templates. Check out the Boost bind library (and later, the Lambda Library) for a solution to the for_each problem.

verbose type syntax: When you use the containers, like (say) std::vector, you have to declare your iterators as:

std::vector::iterator i;

If you change to a std::list container, you'll have to change your declarations. Of course, you can mitigate that by using typedefs, and then you only have to change the typedef, but it can still get a bit wordy.

typedef makes this a non-issue. I find the "wordiness" a nice form of in-code documentation.

unexpected results: Understand the difference between remove() and erase() in the containers.

It's unfair to label this "unexpected," but you're right in that knowledge of the API is important. As it is for all libraries.

The benefits of using STL are wonderful. If you write your custom containers/streams/etc. using the STL interface, you can seamlessly use the algorithms portion of the library.

This is the real power of the STL. IMHO too many people concentrate on "containers of X." This goes doubly for the C++ template engine as a whole.

I recommend reading the first part of Generic Programming and the STL. It'll help you undestand the thinking behind the design.

Then get Modern C++ Design , join the Boost mailing list and take it to the next level.

The STL is great. Some of the stuff coming in the next library standard revision is even better. The stuff in Boost is outstanding.

The biggest problem I have had with the STL is convincing people to use it. The available implementations could be better (smaller, more template specialization, etc.) but the savings in programmer time is well worth the slight cost.

Aside from the debugging nightmare (much improved by tools such as STLFilt, BTW) and the portability issues, IMHO the biggest problem with the STL at present is the lack of glue to take best advantage of it.

For example, there is auto_ptr but that's incompatible with the standard library container classes. Instead you need to head for something like Boost to plug the gaps.

Similarly, you have all these fabulous algorithms that take optional predicates, but then you start writing rubbish about binders and less<int> to get them to do anything useful. Again, the answer is perfectly possible (check out the various expression template libraries in circulation), but relies on a good level of template support in C++ and isn't (yet) standard.

Fortunately, the next version of the C++ standard should address these shortcomings and plug the gaps, at which point the C++ STL implementation will become one of the most fabulous libraries in existence.

Obviously not, because the containers rely on the safety of the copy constructor and auto_ptr implements RAII through the copy constructor. Conceptually, aren't both part of the "STL" anyways?

This is one of the reasons Boost has a templated shared_ptr, which does reference counting instead of source/sink pointers.

This is covered in Effective C++, but it's also pretty obvious from the APIs.I question designs that want source/sink pointers in containers anyways; part of the idea behind using containers is to centralize the storage of objects.

In practice, the big problem with the STL is that Microsoft doesn't like it. ... So they support it, but badly.

I'm not sure this is a valid criticism:

• Microsoft uses Dinkum STL, which is actually an exceedingly good implementation. The only problems I've had are concurrency issues.
• Compare Microsoft's problem to Solaris. Forte uses bizarro Rogue Wave STL, which is not an exceedingly good implementation of the STL.

Replace it with:

std::vector bufmem(n);
char* buffer = &(bufmem.front());
//...


uh, sounds like you need an auto_ptr for arrays. I don't think the STL std::auto_ptr does not work for arrays, but the Boost libraries have a nice scoped_array for arrays.

Replace it with:

std::vector bufmem(n);
char* buffer = &(bufmem.front());
//...


uh, sounds like you need an auto_ptr for arrays. I don't think the STL std::auto_ptr does not work for arrays, but the Boost libraries have a nice scoped_array for arrays.

I heard that there's no sparse matrix (or any sort of matrix) container in the STL. Where would one go for that?

for math:

Blitz++

for everything else:

BOOST

In practice, the big problem with the STL is that Microsoft doesn't like it. It's one of those standards that Microsoft doesn't control, yet is so widely used that they can't ignore it. So they support it, but badly. (OpenGL gets similar treatment. So does C++ itself. Microsoft prefers their own dialect of C++, which is not fully compatible with the ISO standard.)

This should get better soon, since Herb Sutter and Stan Lippman are both at Microsoft now, and seem dedicated to standards compliance

The STL doesn't help too much with the big problem of C and C++ programming: keeping track of who owns what. auto_ptr and the STL don't play well together. That's a lack, and it's not easily fixed. There have been three iterations of auto_ptr semantics, all of which have some painful problem. See "comp.std.c++" for discussions on this subject.

If you haven't yet, you should look at boost. They have a very useful smart pointer library.

Secondly: Be very, very careful about using pointers to dynamically allocated objects. If you are copying pointers around, you could very easily get into a dangling reference. A smart-pointer template (which SHOULD have been part of the STL) is a handy thing to have.

The dangling pointer problem is hardly anything to do with STL. You should be careful with pointers always. Also the STL DOES include a smart pointer template class - called auto_ptr. Of course a reference counted version like boost.org's shared_ptr would have been nice. I believe adding garbage collection to C++ and/or STL is being considered (a far superior option to using referenced counted pointers without language support IMHO).

Hello, from my own experience as a graphics engine & tools developper, I can tell you that we wrote our own core-framework for rapid application development, much like Java comes with a batch of toolkits. Up to the point where we wanted to include serialisation, our concept worked brilliantly and we had come a long way. When we then wrote container wrapper classes on top of existing stl classes to act in a COM-like fashion (in order to be able to support serialisation and interface resolving), we used the widely used stlPort version.

STLPort is a very decent stl implementation. Using Microsoft's Dev Studio, we could have used the microsoft implementation but it's not as compliant as STLPort, so it was the best possible option (but I still have to check out Boost as well, which offers very nice features). That said, the biggest problem with compiling subclassed STLPort classes was the compiler. In no time, template instances of the templated class definitions would fill up the compiler heap and compilation would either halt or take forever to finnish.. even if we used the /m2000 option, which pumps the heap to 2000% of heap memory, things would freeze up. Since we had quite a lot of containers in combination with quite a lot of basic types, we were litteraly stuck. After STLPort gave such bad results, I tried the same with the MS version of STL but this gave us very much the same results + tons of other problems. So we fell back on our initial solution, which was to use 1 template instance of our Object* interface and define wrapper class objects for each basic type. which sucked, but it compiled. We should have tried the Metrowerks compiler which is (so I've heard) supposedly better at compiling stl than MS'es DevStudio. We'll see.

The biggest downside of the STL is when it doesn't work.

Sure, the standard is >3 years old now, but a lot of compiler vendors are still working out bugs with either the STL, their compiler, or their linker still.

Under AIX, we've run into relatively few problems with the STL itself, but the linker is pretty bad. Between it and the compiler compiles take forever (which is why I've been surfing /. more recently), and the executables are freaking huge.

This is, obviously, an AIX-specific problem. And it's pretty much an old story - every vendor has their own quirks with the compiler and/or linker.

Beyond that -- I've found a few things missing in the STL that would be really nice to have.

First, the only smart pointer is std::auto_ptr. It's pretty useless, since you can't use it in a collection, and you can't have more than one thing pointing at an object/memory block at once. This can be worked around though, since there are libraries that have better smart pointers. Check out Loki or Boost for two.

Second, there's no way to automagically ignore case on a std::string, or to upper/lower case it easily. Yes, I know, you can muck around with traits, but that's a PITA and renders your string uncopyable to other strings easily. Yes, I also know that you can use a transform() to do it. But this still isn't as nice as myString.lower().

Third, there's no date or datetime classes. You have to fall back on C time functions for them. I haven't looked for a good C++ library to handle date/time, but I'm sure there's one out there.

Fourth, there's no regular expression matching on strings. We use PCRE with a C++ wrapper and it works fine for what we need though.

Both 2 and 3 are due largely to internationalization issues... in the case of 2 there's a lot of languages in which upper and lower case are non-sensical. And after having thought about the i18n issues regarding dates, I don't blame the standardization committee a bit for running away screaming from them (what date range? which calendar? how do you change between calendars? what about date weirdness with some calendars (like the missing days in the Gregorian calendar)? etc).

I used RogueWave prior to this job, so I tried to think of some of the things I was used to in RW and weren't in the STL. By and large I prefer the STL though. The container classes in particular are a lot more sane than RW's.

It's too bad the "bs" moderation you suggested doesn't exist, because I'm afraid that, being entirely neutral and objective, several of your statements would qualify for it.

To correct a few of the more glaring errors...

• Java's proposed generics in 1.5 are nowhere close to the power of C++'s templates. They're a quick hack to get generic containers into the language, which is a far cry from the state-of-the-art C++ template research.
• In answer to your four questions: yes, I have used MI in C++, though only rarely, and having written and maintained such code I think it was the correct solution close to 100% of the time. I have not suffered from memory leaks or dangling pointers any time I can remember in the last few years. Oh, and Java can leak resources faster than a broken fuel tank, so please don't consider it superior in any way here. Java's GC only deals with memory; its overall resource management is years behind the sophistication of the C++ approach.
• The STL doesn't need a GC, neither does most of C++, because we have concepts like passing by value and local variables, so we don't have to clutter code with using new everywhere. Why do Java-ites insist on the myth that memory leaks are everywhere in C++? It's actually quite hard to create them. Granted, STL containers of pointers are a problem for the current standard C++ library, but hey, you can just download a better set from Boost for now, and they'll probably be standard in the next revision anyway. Considering that Java can't even make the distinction between storing by value or by reference, I hardly think this qualifies as a superior feature for that language, either.
• Oh, yeah, and Java's libraries frequently do suck. They have been put together and expanded far too fast, without adequate forethought, and now they have to live with the mess forever to avoid breaking old code. AWT and Swing are hideous, the containers are a joke, writing the basic "Hello, what's your name?" function for the first class requires a deep understanding of dozens of stream classes, the use of Integer and such are just a hack to cover an obvious flaw in the language. I could go on, but I'm not here to bash Java, just your assertion that what the previous poster wrote was bs.

Please, before you go shouting at people at such length, check the facts.

I've have found it an excellent relief from the mundane of C/C++ while re-inforcing the natural idioms of generic programming. I'm Looking forward to working with the Boost Python Library

A survey contrast of Python and C++ http://mail.python.org/pipermail/python-list/2002- April/096602.html Cross platform, Batteries included, good natured community, and script -> OO Ready got me interested, "like I think" factors got me hooked. (I'm a C++/C applications developer.) The Weekly Guide to Python Resources

Both of the concepts you mentioned are implemented in boost's library (http://www.boost.org). Actually, std::auto_ptr is implemented in the C++ standard library, but boost has many different pointer types, including reference-counted pointers, weak-referenced pointers, and plain-jane scoped pointers. The library is robust and easy to use, and I highly recommend it.

How much of ISO C++ is supported by the GCC compiler?
Not just the intel backen, but all the other popular ones (Sparc, PPC, etc.)

The only document I saw, is the BOOST library compile logs [note, boost.org is down at the moment, try a google cache.]

I know GCC beats the pants out of VisualC++ interms
of standard compliance, but how much better is it?

--

1. intuitive and easy to use IDE
   Does such a thing exist??? Every language has an IDE. Visual Studios, JBuilder, Emacs, KDevelopers, etc.
   
   
2. simplified GUI design and event handling
   Well, this really depends on the operating system. Java's the good place to go here. If that can't be done, GTK and Qt are good libraries and they use the standard X style callback mechanism which is so much nicer than message based systems. What your really looking though is for a WYSIWYG GUI designer so I'd recommend Glade or whatever comes with the IDE you go with.
   
   
3. advanced error handling
   Such a buzz word... Java and C++ both use exceptions. Good error handling has more to do with a projects design though and not really the particular language...
   
   
4. advanced object oriented design including multiple inheritance, abstract classes, and garbage collection
   Lets get our terminology right :) GC is not an OO feature. GC is a generic programming concept and it is by no way the only way to avoid memory leaks. In C++, reference counting is much preferred over GC and it's probably the better choice since C++ programs tend to not use enough memory for GC to really be effective. Check out boost for some good reference counting classes.
   
   IMHO, MI is necessary for advanced projects but Java interfaces _almost_ make MI unnecessary. You may do well to evaluate whether you truly need MI. What really matters, is how good your development team is.
   
   
5. full support for operator and function overloading
   This really should be in Java if you ask me but it isn't. You really don't need it. You could use interfaces instead. Of course, C++ support for operator overloading is great. Again though, you should really evaluate if you truly need such an advanced feature. If you just going to use it to concat strings then you don't need it.
   
   
6. and portable (at compile-time) across various platforms
   Java or GCC. C++ is portable as long as it's GCC on both platforms :) Don't expect C++ to be very portable across different compilers though...
   

That said, C++ does not have any built-in garbage collection which is in my opinion a shame. Still, you can plug in garbage collection if you want, though the URLs escape me. In my experience, this has slowed down the execution of my C++ applications considerably but that said, my applications tend to allocate and deallocate memory quite frequently.

Garbage collection is highly overrated. GC is useful for systems that make use of a great deal of non-stack memory (such as Java) but for low-profile processes, reference counting is much more useful. In fact, overall memory use will be significantly lower.

STL has auto_ptr which sucks. Writing a reference counted class is rather easy but it's been done so why not benefit from it? Take a look at Boost for a bunch of neat reference couting classes or for a fully reference counted object library, OPP.

The idea is to essentially not use the new operator at all. Instead of deleted new objects with no references when memory is needed, reference counting deletes an object as soon as the last reference goes away. With STL containers, there is really no justification for having any new's anywhere in a C++ program.

Check out More Effective C++ for ways on making it illegal to even call the new operator in your program. That should ensure no memory leaks...

GCC can already do that, or at least it does an reasonably OK job. It's really more a question of having a good STL implemenation, IMHO. Here are a couple of links (shamelessly ripped from the compilers part of Bjarne Stroustrup's C++ FAQ):

C++ conformance roundup and boost.org's compiler status page.

It is worth noting though that GCC version 3 is one of the most standards-conforming C++ compilers available.

It is significantly better than Intel's on weird template and STL stuff, and a vast improvement over Microsoft's Visual C++ (which even in its latest incarnation has failed to address partial specialisation bugs dating back to vanilla 6.0.) Just because these template issues are weird, does not make them useless. On the contrary, they can allow code which is both more easily maintained and faster. For examples, consider Blitz (templated numerics library) and Boost (a very well thought out set of extensions to the standard C++ library.)

OOP implies polymorphism (also known as ad-hoc polymorphism) through inheritance. Inheritance is one of the strongest possible relations you can express in an OO language. When you express such strong relationships between types (or class if you want to take a more pure approach) you are actually making your components extremely cohesive.

Yes of course, you can always treat objects as "Object", but that doesn't help you much. You still need to know the least common denominator, and in most cases, it is NOT Object (or whatever your favorite root class is named). Thus you have to specialize your code to a specific purpose, or at least adapt to an older concept (by inheriting from a foreign class).

Generic programming promotes something called true polymorphism. Generic polymorphism does not require inheritance. In fact, it does not require anything if you wish. For instance, look at containers. There you don't require anything of the polymorphic types (depending on implementation details of the language. C++ containers may for instance require copy constructable types and such). Of course you can do this with Object as well, just look at java. But you get a bonus here, and it's called "type safety".

Not only do you get true polymorphic types, but you also get true polymorphic functions based on the types it processes. See it as instead of adapting the types (your required inheritance), you make the functions adapt to your types instead. For free. No hassle. No manual overloading required!

Of course, not all things can be made generic, but thats where YOUR ideas come into play. You fill in the blanks. And that my friend, you can use good old fashioned imperative programming, functional programming, OO programming, logic programming, or whatever makes you tick.

I used to be a believer in the saying "OO solves any problem". But then I discovered generic programming, and I changed my mind. OO does not solve all problems.. cleanly and efficiently. I started getting an idea during functional programming class, but then the FP-zealots don't want to hear about anything called generic. "It's functional, not generic!". 2 years later I started to use STL at work when I used C++. Guess what? Jesus [read ANSI C++ committee] reached out and touched me.

STL not only gives you remarkably nice containers, it also gives you algorithms for free, the notion of functors and iterators. Mix these together, you'll never have to write retarded loops again working of your sets of data. They provide 100+ algorithms, tested and bugfree just for you to use. STL also have some real cool things in store: Models and concepts. These are interface descriptions for how components can be interacted with. It's similar to that of javas interfaces. The difference is that it no inheritance is required (java calls it implements, but its just an "pure virtual class being inherited"). A concept may just state something like "the type must be copy constructible and provide a function called size(), where the return value is compatible with the type size_t". If there is no copy constructor or size() function for that type, then the compiler will yell at you. In other words, extremely low cohesion.

Try STL for your problem solving and you will like I, find that most of the boiler plate cruft has already been implemented for you. And the best part is that you don't have to commit yourself to some other class hierarchy.

Those who are interested in STL, I dearly recommend the book "Generic Programming and the STL: Using and Extending the C++ Standard Template Library" by Matt Austern (amazon link). That one is really great learning STL and how/why it works, but it assumes that you know the basics of templates and C++. Starts out with the concept of iterators (quite a big deal in STL!), goes on with gory C++ details, continues with the different models and concepts STL has to offer, and finally provides a reference for pretty much everything in STL so that you can interpret the components in STL as well as providing your own component which are compatible with STL (in terms of concepts and models). Quite a good read actually, eventhough you don't plan on doing any generic programming.

Another book is "Modern C++ Design: Generic Programming and Design Patterns Applied" by Andrei Alexandrescu (amazon link). This one is really advanced and can make your brain explode. But nonetheless it's a really good read. Eventhough many of the things in there may be called "too radical" by todays standard, it's a great source of ideas. This guy, Andrei, really pushes C++ to the limits. It's quite a spectacular show!

The best part about Andrei is that he's an open source dude. Perhaps not a GPL-zealot, but nonethless, he likes to contribute code which may be used w/o restrictions by anyone else. His library "Loki" is currently being ported and integrated into the boost library. The boost library is the natural extension of STL, written and maintained by C++ committee members and other excellent engineers. All code that goes into boost must go through a rigorous peer code review as well as document review, thus you can count on the quality!

Ok. This wasn't exactly on-topic, but it's a valid alternative to OO for engineering stuff. The way I see it, GP is most likely well suited for those kinds of applications.

The parent of this post refers to COM objects as the main code reuse strategy in Windows. Guess what serious Windows developers use to write COM objects? Yep, you guess right: STL and ATL (Active Template Library). Infact, these two libraries make it a breeze to implement COM objects in Windows (although, I prefer the UNIX environment. I wish the customers of the firm where I work could see it that way too..)

Increase usage of Standard C++ STL objects throughout. I am as interested in learning YANSI (Yet Another Novel String Implementation) as I am in learning C#.
Where the STL falls short, go to Boost.
Borland, if you're listening, please make your VCL/CLX libraries work more easily with STL. Still waiting for C++ Builder on Linux, BTW.
The theme of this post is that platform- and vendor-specific implementations are a PITA.

An open source project that uses their own version of Jam are the boost libraries at http://www.boost.org/

Ahh, you are a knowledgeable one. :) I was hoping someone would mention jam. It not only handles platform-dependent tasks, it's a full replacement for make and actually generates correct dependencies. It might be a little tough to convert a make-based project to jam, but it's the way I would go starting out.

boost.build is the build system for the Boost libraries which, as mentioned, uses jam. In fact it uses an advanced version of jam with many new features. I'm not sure if those will be rolloed back into the "official" jam sources (boost jam is actually a derivative of FT Jam, from the FreeType project).

Jamfiles (analogous to Makefiles) are platform-independent. A "Jamrules" file holds all the configuration-specific information. Some systems use autoconf to generate this. Boost does not and their build system is very flexible, allowing one to not only define platform-dependent things but also specify build features such as whether to make static of shared libraries (or both!), optimization levels, etc. A single build run can build shared and static libraries at several optimization levels, for example.

An open source project that uses their own version of Jam are the boost libraries at http://www.boost.org/

Ahh, you are a knowledgeable one. :) I was hoping someone would mention jam. It not only handles platform-dependent tasks, it's a full replacement for make and actually generates correct dependencies. It might be a little tough to convert a make-based project to jam, but it's the way I would go starting out.

boost.build is the build system for the Boost libraries which, as mentioned, uses jam. In fact it uses an advanced version of jam with many new features. I'm not sure if those will be rolloed back into the "official" jam sources (boost jam is actually a derivative of FT Jam, from the FreeType project).

Jamfiles (analogous to Makefiles) are platform-independent. A "Jamrules" file holds all the configuration-specific information. Some systems use autoconf to generate this. Boost does not and their build system is very flexible, allowing one to not only define platform-dependent things but also specify build features such as whether to make static of shared libraries (or both!), optimization levels, etc. A single build run can build shared and static libraries at several optimization levels, for example.

As for the preprocessor, I don't see why it's a "bad thing".

It's a bad thing because the compiler doesn't see it. Debug symbols can't be generated, macros can't be called from within the debugger, constants are only visible as raw numbers, etc. Of course, moc doesn't have all of these problems but it does do a significant amount of translation not visibile to the compiler.

That said, moc was a fine solution to the C++ compiler problem back in its day. At this point, most compilers can handle the template code necessary to implement signals and slots within the language. An advanced signals and slots library is being developed for Boost, a collection of peer-reviewed C++ libraries. Some have already been submitted for inclusion in the standard committee's library technical report (i.e. to be considered for the nex rev. of the standard).

They don't "duplicate it"

Well, they do parts of it. std::string is a fine string class. Actually, probably a little too featureful. As for containers, one can have containers of pointers in the std C++ library provided they are wrapped in smart pointers like Boost's shared_ptr.

As for "poorly", the Qt collection classes do a much better job than STL of avoiding the "template bloat" problem (they do this by using for the most part pointer containers based on the void* implementation)

The "template bloat problem" should really be called the "template implementation problem." It's only because most std C++ library implementations follow the original SGI offering that we have bloat problems. Andrei Alexandrescu (of Modern C++ Design fame) annouced some time back that he is working to build an ultra-efficient STL based on void * implementations where appropriate. I'm not sure what the status on that is, as he is getting heavily involed with Boost. Note that sometimes one wants template bloat because that's where expression templates and functor templates get their efficiency (because they are inlined).

Boost is also a very good set of libraries.

- Ithil

auto_ptr is about as close as C++ gets to supporting an explicit concept of "ownership". auto_ptr, though, has several severe problems: [...] auto_ptr is a great concept, but C++ and the STL make it almost unusable.

And yet, the version they have still solves a significant class of ownership problems, where someone gets a pointer back from some other function and then forgets to release it. If you want more advanced semantics, I recommend a visit to the Boost website, and a look at their shared pointers.

boost has a cross-platform threading library. also, at least some of the boost libraries will probably make it into the next C++ standard so they're a good wagon to hang your hat on, so to speak :)

OpenGL, OpenAL, Boost++, and sometimes PLib

Julien.

Absolutely,

As someone using ACE at the moment (well, in another screen). I can say that I've never found a more well-constructed cross-platform middleware package. You can find it here. In addition, the DOC group's TAO package provides a CORBA implementation on top of ACE that works really well for... well, those CORBA things *grins*.

One drawback when using any middleware package that I've seen is that you have to buy in pretty heavily to the package, somewhat adopting the development philosophy of the package's designers. With ACE that hasn't been as much of a problem (For instance, it provides a method of dispatching QT events) mostly because the underlying design is heavily pattern based.

On other fronts, I also continually find the Boost libraries to be very useful. They can be found here.

Probably the last thing to consider is that if you vary your development platform, you are likely going to be changing your C/C++ implementation--and they are not all created equal. Personally, I've found that the cross-platform availability and easy integration of the Dinkumware C/C++ libraries are pretty much worth the middle-of-the-road costs involved. Dinkum's located here.

A lot of people I meet can't really cope with C++ so some simplification would not be a bad thing.

But we can already do this. If one isn't comfortable with certain features of C++, just don't use them!

Similarly as someone said earlier, I like operator overloading. If you're doing matrices etc. then it's cool. I also like templates - ugly, but type-safe.

Agreed, but operator overloading and templates go far beyond simple datatypes and containers. The entire C++ iostream library would be impossible without operator overloading and templates allow easy-to-use locales, custom memory management of data structures, metaprogramming, generators, concept checks, traits, generic algorithms and a whole boatload of other things that go way beyond vectors of tuples of maps of strings to functors.

Sorry to rant, but I've come across too many people who see the STL simply as a container library and entirely miss the beauty of it. It's a shame it was never really completely finished. Thankfully we have things like Boost to fill in the gaps.

Oh, and get a proper auto_ptr class and then we're done.

We do have a proper auto_ptr class. It's just not what most people think it is. Herb Sutter's Exceptional C++ covers auto_ptr usage nicely. Sometimes auto_ptr is the only way to make code exception-safe. If you need a more-featured smart pointer, look at Boost::smart_ptr.

auto_ptr is less then 100 lines of code. You can take the one from and template it up a bit more to use any allocate/free functions you like. You can even get some counted versions from boost.

finally may still be nice for some things, but following the "all resource allocation is object creation/all deallocation is destruction" design will eliminate 99% of those.

integral i32; integral i128;

or integral_at_least which would give you a 64-bit integer or whatever is fastest and at least that size for any given architecture.

Download boost and have all that and more...

Two of Python's biggest strengths are its easy extensibility and its object-orientedness. When it comes to writing Python extensions in C++, however, I have to use Python's plain C extension API to wrap my C++ objects. While it's certainly functional, most of my extension code seems to be boilerplate and housework (e.g., validating arguments and keeping track of reference counts) that could be handled more transparently if Python provided a C++ extension API. I realize that there are third-party Python extension libraries such as Boost.Python for C++ programmers, but at this point I still prefer to use the C API despite its verboseness as it gives maximum control and allows me to make my extensions more "Pythonic" by, for example, allowing me to map C++ get/set method pairs to Python object attributes.

All of which is a very roundabout way of asking if you are considering rewriting CPython in C++ or at the very least providing an "official" C++ API to Python's underlying object model?

P.S. Thanks for a great language!

I'd like you to understand why cross-platform code is incredibly important (note that this page quotes Judge Jackson of the MS vs. DOJ case as to why Microsoft felt it was so important to put a stop to cross-platform code as to break the law.)

But I think what we have lost sight of is maintaining both the usefulness of our code and our independence as programmers by not remembering how to write cross-platform code.

What Sun got wrong was not making Java cross-platform, but trying to bind us all into proprietary platform of Java while sweetly singing into our ears that it was platform independent. Sun did this and continues with it to serve its own marketing and political purposes, purposes which may not serve the interests of either the public or the independent developer.

You too can write cross-platform code, in almost any compiled language. Check out the ZooLib cross-platform application framework for C++, as well as the Boost C++ Libraries.

Jon Watte of Be, Inc. told me "Portable, to some people, means it builds on at least two linux distributions with several flavors of GCC".

Here's a list of a bunch of application frameworks, many of which are cross-platform, and many of which are open source - so there's more than just ZooLib to pick from.

Get off your duff and ship your executables for all platforms in common use - and not just ones with POSIX system call APIs!

And here's a hint for making your code buildable cross-platform - ever try to run "./configure" on a computer that doesn't have a command shell? Pretty hard. Makes folks like me struggle to write all the makefile's and config.h's by hand. But look at how many platforms the Independent JPEG Group's JPEG codec library builds on - DOS, MacOS, Cray, you name it, and it builds with both ANSI-C and old K&R c compilers (using macros for the function interfaces).

Kids these days... damn it makes me mad.

Michael D. Crawford
GoingWare Inc

I think Guillaume's nice discussion about some of the drawbacks of Gtk-- mixed memory management policy is fine as far as it goes, but I would like to add some points.

First, there are really many alternatives to choose to decide what kind of memory management to use for a C++ program. Telling is that the C++ standardization committee could only agree on one memory management class (auto_ptr<>). It uses gross hacks for ensuring the type checker does the right thing (And I'm not convinced it's right as it is).

Ok, to get to my real point, here is a list of all memory management policies I could remember having seen used in C++:

1) explicit deallocation (programmer responsible for deleting; e.g. C++ plain pointers)
2) strict ownership (e.g. a creation function returning a smart pointer )
3) transferrable ownership (e.g. auto_ptr)
4) Stack (objects created first are deleted last)
5) Static allocation (memory for object always exists)
6) no deallocation (sometimes you just can leave memory as leaks)
7) garbage collection (The garbage collector takes care of deallocation)
8) Cluster allocator (see "Ruminations on C++" by Andrew Koenig; basically objects are deallocated in clusters, and whenever the cluster is deallocated, all the objects in it are deallocated as well).
9) reference counting with explicit ref/unref.
10) Intrusive reference counting (the objects being pointed to contain a reference count)
11) Non-intrusive reference counting (the reference count is separate from the object, e.g. like boost shared_ptr template)
12) Handle-Body idiom (you write a specialized handle for managing memory for your class)
13) Container-managed (like Gtk-- manage())
14) Containment (like Gtk-- containment based solution)
15) Library-owned objects (library only returns references without ownership to users)
16) Distributed garbage collection
17) Evictor (the objects are maintained in a fixed size array, and the least used objects are deleted when new objects are created that would o verflow the array When the object is next needed after being deleted, it's re-created).
18) Copy semantics (you always do a copy)
19) Lazy copy semantics (you make a copy when you have to)
20) Reaper (The memory is scanned at fixed intervals for freed-up objects, and any objects marked to be deleted are freed).
21) Shared memory allocation
22) Persistent allocation (You mmap() some disk space for your objects, and leave it there to allow it to be used on subsequent invocations of your program)
23) Class allocator (overloading operator new and operator delete for allocating small objects efficiently)
24) Self-managed allocation (the object deallocates itself)
25) Singleton (The object is allocated when it's first used, and deallocated at the end of the program)
26) Mixture of several of the above policies

The design space for memory allocation of C++ objects is really HUGE. So it's no wonder there is some disagreement on what is the preferred way to handle memory management, especially as many of these alternatives are actually contradictory in that it is hard to combine many of these strategies.

I personally prefer auto_ptr combined with a non-intrusive reference counted pointer class and creation functions that return memory wrapped in auto_ptr. You do need some solution for putting references to objects in containers, plain auto_ptr doesn't work for that.