Slashdot Mirror

Literally anything that you might think C++ would be good for is better solved by either C#, C, or a combination of both.

This makes literally no sense. With minor caveats, C++ is C with more stuff. Even if you only use (say) namespaces or a modest amount of ad-hoc overloading, C++ is a better C.

The main cause of problems with C++ is using it as an object-oriented language, but you'd have the same problem in C#. What Alex Stepanov rightly said about Java equally applies to C#: "I spent several months programming in Java. Contrary to its authors prediction, it did not grow on me. I did not find any new insights - for the first time in my life programming in a new language did not bring me new insights. It keeps all the stuff that I never use in C++ - inheritance, virtuals - OO gook - and removes the stuff that I find useful."

Frankly said, I think that this is rather overstating things. Modern C++ has plenty of idioms that you should use first, without attempting to come up with your revolutionary redesigns of a common wooden wheel. Effective C++ and Modern Effective C++ are required reading, as well as Strostrup's most recent (at any time) edition of The C++ Programming Language. Also Exceptional C++, and Modern C++ Design. I can't help but mention the interview with Alex Stepanov, where he explains the mathematical basis for STL (You thought that software engineering requires no abstract, higher non-CSy math? Think again!)

C++ is a big language, and people who know their craft actually do know all of its features, and can probably point to relevant sections in the standard when they talk about things. I'd say: meh, pebkac.

Pseudonym posted this earlier in the thread, and I think that some of the ideas in the interview are what they're referring to.

I knew that would get voted down. Let's just say I'm in good company.

Any program that uses the stl is going to be a c++ program by definition. It will have classes that use the stl (how often do you see a c++ program with no classes?), and since most people don't write one-off classes, and you have to guard access to the stl with locking primitives anyway (STL_LOCK, STL_UNLOCK) which the programmer usually stuffs into a class and then derives their objects so that they don't have to worry about locking, it's pretty much inevitable that you'll end up with vtables in your runtime when you use the stl.

Hey, I didn't write that code - I just nuked it wherever possible because it is fugly; Besides, the STL doesn't really belong in an OOP environment - even Stephanov agrees that the STL is not OOP., so no wonder it looks ugly.

Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work: Bill Gosper's Hakmem is one of the best things for a programmer to read. AI might not have had a serious foundation, but it produced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, together with Guy Steele). I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

But back "sort of" on topic - how often have you seen a non-trivial c++ program that used the stl that didn't also use inheritance?

I'm pretty sure VC++ and g++ don't do this

I know this isn't exactly what the article is looking for. But, if you are using the STL (which you SHOULD be!) you may be interested to know that the STLPort STL implementation includes a debug mode which contains loads of error checking to make sure you aren't misusing STL.

The advantages of OOP have been very well researched and understood for nearly 30 years.

Well, the so-called "advantages" of OOP have at least been well propagandised for at least some of the last 30 years. :)

It is unquestionably a major advance in software development, with relevance to all areas, including websites, allowing re-use, encapsulation, isolation and testing of code [...]

None of those concepts you mention have anything in particular to do with OOP. And you shouldn't really be terribly surprised that more than a few programmers find OOP evangelism more than a little extreme. See Andrei Stepanov and Paul Graham for a couple of good examples.

Alexander Stepanov went onto SGI after HP and continued his work with implementing and extending the STL while there. It improved many implementation details (the HP version was not thread safe for example), as well as adding several templates (hash'es etc) that did not get into the standard for political reasons. Like the HP version, the SGI code was freely available (BSD-like license).

The SGI implementation of STL has pretty much become the defacto-standard implementation. It is definately the most widely used implementation in the open source world and probably in the proprietary world as well.

On a related note, this is a pretty interesting interview with Stepanov.

Both Java and C++ are fundamentally object-oriented languages, so what, if I may ask, is wrong with forcing you to use OO design?

C++ supports object-oriented programming, but it is intended to be agnostic in terms of OO, procedural, generic programming, etc. It's up to the user how they use these features.

Tell Stepanov that C++ should only be used for OO, and see how far you get...

STL, at least for me, represents the only way programming is possible. It is, indeed, quite different from C++ programming as it was presented and still is presented in most textbooks.

But then, he is a bit of a zealot, so add salt as required:

STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people.

...And if they cannot implement max or swap or linear search, what chances do they have to implement really complex stuff? These are my litmus tests: if a language allows me to implement max and swap and linear search generically - then it has some potential.

After downloading the VC++ Toolkit 2003 it was sad to see that the C++ standard library implementation appears to lack iostreams..

I've managed to build STLPort and Boost with it though (but not without hacking the source!). Gave me working iostreams at least, but i dont think it was worth it.

I rather use MinGW but it has broken support for wide-char strings :(.

Multi-Language: Please, they're all the same language designed to look like other languages

Sure, C# and Visual Basic share a lot, but they're the odd ones. See F#, COBOL.NET, Managed Extensions for C++ and the excellent Managed C++ in the works

Java has multi language support to (Jython). This is not a fundamental reason.

Java has poor abstractions, and is based too much on the fallacious "less syntax, more library" principle. Java is the C of managed environments. Sure, you can compile anything into it, but that's just because it's Turing-complete. Must be a lot of fun implementing any useful compiler without delegates and value types

Value Types: Use escape analysis and a better GC. This is a hack so programmers can give hints to a stupid GC.

Value types aren't garbage-collected at all. And they are important for performance and interoperability. Oh, and the .NET GC does pretty fine, thank you. Whidbey will even let you allocate managed objects on the native heap, and native objects on the managed heap. And you can't do that in C#, this is an uber-geek feature designed for Managed C++, that only further underlines the multi-language and multi-paradigm goal of .NET. Java, in its arrogant engineered "perfection", will never get actually useful stuff like this. Useful how? it gives you a GC heap for free to allocate your own objects on. It lets you use managed objects with the STL, or the excellent Boost. Or use a different GC, like Hans Boehm's, if you don't like .NET's (in fact, the syntax for Managed C++ has been designed with the goal of not conflicting - or even overlapping features - with any of the major C++ frameworks). Without writing a single line of glue code in C

Generics: Where are the C# generics? The version we're using at work doesn't have them.

Whidbey (.NET 2.0). Also previewed in Rotor

Java Generics will arrive first, but be worse off in the beginnnig.

It doesn't matter, because they are a lie. And Java only got them because .NET did

C# language: The only even marginally valid claim. However, the lack of checked exceptions

Microsoft maintains a longeve C++ compiler: they've been there, done that. They never believed in checked exceptions. Nowadays they are mostly agreed with. By all means, look for Herb Sutter's site: like most Microsoft techies with blogs, he gives no-nonsense explanations of all the design choices he's been involved with, and that includes checked exceptions and lack thereof

Ah. I see. I'm used to using strings or ints as keys in std::map functions.

Most C++ programmers would do that. Then again, most C++ programmers would also bother to deallocate the arrays returned by strdup(), too, so I guess this guy isn't a C++ programmer.

I don't normally use hash_map because it's not in the g++ 3.1 distro (my company mandates this version).

IME, most people don't use hash_map, since it's not standard. My understanding is that it will be standard in the next revision of the C++ standard, so maybe it will gain more popularity then.

Is there another source for free STL implementations out there besides the archaic SGI STL?

Ever used STLPort? It's supposed to be pretty decent, considering that it's free.

not sure about ::hash_map, but the ::map lookup calls a function in this case. using k->second would dereference an ESI pointer to memory, which is faster than an inline call to a member function. not sure if hash_map does the same. yes?

You're right. It probably would improve performance to some measurable extent. The previous post stating otherwise is probably wrong.

Other than stlport?

Well unless you use .data() instead of .cstr() where NT/Solaris use the same implementation for both and libstdc++ doesn't

...or you want to use <strstream.h> er I mean <strstream> ... errr I mean <stringstream>

...and the first time you could get something that comes close to a std. c++ implementation is within the last few months.

The last time I used Sun's C++ compiler, the only problems I had were with the antiquated version of the STL that they insist on using for backwards compatilibity purposes.

I found that STL Port fixed the problem nicely.

It's true.
If you took the time to understand its principles - you'd agree.
But perhaps it's not your cup of tea - it's more for experienced programmers.

Alex Stepanov famously described Java as "a money-oriented programming language". I guess that makes the name "Jackpot" an appropriate name. I suppose the next projects will be "Jingle" and "Jyp".

Templates only seem to be a necessary evil in OO languages that don't ultimately inherit all objects from one object.

This is a naive view that circa 1992 C++ collection class designers used to share. The OO-container strategy was proven to be slow and not type-safe. The designer of the C++ Standard Template Library (STL) Stepanov does not even believe in OO programming - he calls OO a hoax. I personally would not go that far, but I appreciate that OO and generics are completely independent concepts. Furthermore, an STL map or vector working on types directly is much more space efficient than any OO container-based approach because each object contained does not require OO overhead. Indeed, native types (ints, doubles, etc) in vectors can be nearly as efficiently stored and accessed under STL as would C style arrays. No need for awkward casting or unnecessary and slow boxing/unboxing. To sumamrize, C++ templates and the STL fit in perfectly with the C++'s "zero overhead" principle.

If you need total standards compliant though, Comeau C++ is the tool for you.

Don't like their STL? Use STLPort! Bonus points if you can compile it under Windows using their incredibly sucky installation instructions, which sorta ... stop in the middle of the process.

Don't like their STL? Use STLPort! Bonus points if you can compile it under Windows using their incredibly sucky installation instructions, which sorta ... stop in the middle of the process.

The ISA paradigm sees classes as nouns (e.g. an Image IS A collection of pixels.) I think that classes can also be adjectives - so for example I might have a 'Rotatable' class, so then my Image class IS A (collection of pixels) and IS rotatable

class Image : public std::vector, public Rotatable
{ ...
};

Try to remember that the container classes provided in the C++ standard library were not designed for use as public base classes. In fact, Stepanov (designer of the STL) does not even like OOP, calling it technically and philosophically unsound. Unfortunately, this code uses inheritance to expose an _implementation detail_ (the usage of std::vector for storing its elements) that it should keep hidden. The std::vector class provides no added benefit to classes that derive from it because it has no virtual member functions and no (standard) protected members. The code, as it stands, is essentially equivalent to

class Image : public Rotatable {
public: std::vector<Something> elems;
};

with the difference being that one writes code like a.size() for the first example and a.elems.size() for the second example (not a huge difference, in the grand scheme of things).

You should avoid exposing implementation details, so, at the very least, write a PixelCollection class if you want to expose a pixel collection in a class interface. The PixelCollection class would then _contain_ a private vector to store its elements. That way, you will hide the storage implementation and be able to change it later. At that point, whether or not PixelCollection should be a private member of the class or a public base is another matter that needs to be dealt with...

Cross platform STL/string/iostream is quite easy, actually: STLPort
I don't trust compiler vendors' implementations being threadsafe.
Just curious - is GCC's std::string threadsafe across all platforms yet? It used to have some serious problems.

Steve Streeting had a similar concept in mind when he implemented his OGRE 3D Engine. He also has designed his engine so that it is written in C++, has a modular plug-in architecture that enables extensibility without recompilation (for certain portions of it, obviously), offers multiple 3D API support and builds both with MSVC++ 6 & 7 and also gcc 3+. The MS builds require STLport, an open-source replacement STL that's more compliant than Microsoft's -- ha, imagine that ... -- but that's along the lines of what you're talking about.

He's got a number of interesting design ideas and, from what I understand, is fairly accessible.

Also, and let me offer this, I have no idea about your programming skill and knowledge other than what you've claimed, but please ignore whatever posts come up that try to tell you how incredibly difficult this all is and how you're just better off joining an open source project or buying a package and saving yourself the hassle. If you want to do it, can really do it, and enjoy doing it then, not meaning to quote Nike's marketing department or anything, but: Just do it.

A. Stepanov: "At that time I also discovered books of two great computer scientists from whose work I learned the scientific foundation of my trade: Donald Knuth and Edsger Dijkstra. Knuth taught me the answers. Dijkstra taught me the questions."

If you chose to use C++ for its object-oriented abilities, you may be surprised to know that Alexander Stepanov (the inventor of STL) himself said he never uses what he calls "inheritance, virtuals - OO gook" of C++, and says, "I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people."

This may or may not be of any importance in your choice of language features and development practices.

This interview with Alexandre Stepenov is pretty amusing. He apparently calls OO programming "a big hoax". He also states "quite clearly that Bjarne [Stroustrup] is the preeminent language designer of my generation."
A very interesting read.

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.

Not to "me too!" this thread, but I also program with the STL on Solaris, and I find it excellent.

I own the STL Tutorial and Reference Guide and Effective STL.

On the web, I use the SGI docs and also the Rogue Wave Docs since the Solaris STL is from Rogue Wave. I find them both adequate for 99% of the programming that I do. The one thing to note on Solaris is that the STL is missing a hash map. The hashmap is technically not part of the STL spec yet, but it most likely will be for the next iteration, and the stlport implementation has one available.

Several people have mentioned one of the downsides being unintelligible error messages. This is true, but I think that (on Solaris anyways) error messages coming from templated code generally suck.

Our company has to switch between two different implementations to compile between MSVC for a Win32-based build and MS Embedded C++ for a WinCE-based build.

Instead of hacking around with two different Microsoft STL implementations, why not standardize on the cross-platform, open-source STLport? It is very complete and has helpful runtime assertions. My only complaint is that debugging STLport is difficult because of its impenetrable naming conventions..

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

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.

It compiles on many platforms.

It compiles on many platforms.

Sure. Here's the quote from An Interview with A. Stepanov:

STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people... I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

For those too busy fawning over OOP here is some help:

http://www.embedded.com/1999/9908/9908feat1.htm

And if you're a bit too enamored with the C++ new operator try this:

http://www.scs.cs.nyu.edu/~dm/c++-new.html

And to see how STL guy A. Stepanov feels about OOP proponents see this:

http://www.stlport.org/resources/StepanovUSA.html

Although I have met quite a few talented (and effective) practicioners of OOP, much more often I run into hyper-political, resume-stacking, rabid and incompetent advocates of OOP. Mostly, they never finish what they start.

Who cares what Grady Booch and his two quack partners say anyway? I mean besides the rabid advocates...

One way to get around the various vendor differences in STL implementations is to use somethings like SGI's STL port on multiple platforms.

http://www.stlport.org

| Oh, I have my criticisms of C++: A new standard
| is a mistake when no on produces a fully-ISO
| compliant compiler today. The STL is an ugly
| mess designed by committee; I'd like to see
| restricted template arguments, inheritable
| enums, and a few other new ideas.

the stl wasn't designed by committee, but by stepanov ... and is one of the most brilliant designs i've seen to date.

Granted, there are a few STL ports available, but we've experienced headaches getting them to go on some embedded systems compilers, leaving us to come up with our own pure ansi standard library which we use religiously on mac, linux and win32 dev (as well as palm, wince, etc.).

Visual Basic is a functional language from the very beginning with OO added on top of it.

C++ is a multidimensional successor of C. C++ is in itself a language that supports multiple paradigms, which I consider to be the crown jewel of programming world (especially the STL http://www.stlport.org/resources/ StepanovUSA.html - here is a god, kneel.)
However I don't consider C++ to be purely object oriented either, it is as I say multidimentional and supports multiple paradigms. Don't switch, I have to use all of them due to our clients' demands. VB or Java is mostly Money Oriented Programing (MOP). Actually the value of C++ is only increased because it is not completely OO. Templates allow you to write functions independent of objects and that is great. - but that was the idea from the beginning. Idea of VB was QBasic.


If you really don't think what I am telling you about VB is correct, just look at this: http://msdn.microsoft.c om/library/periodic/period00/vb7.htm
better yet look at my post #220.

3 words:
Money Oriented Programming

JVM for Java, VB4/5 for Visual Basic

Both are virtual machines.

VB - a functional not natively Object Oriented language

Java - OO top down, bottom up, an oversimplification of C++ with more natural human Language API's

So what?

Java is nice, it's defenetely less platform dependent than VB
More and more people write in Java (Java is the modern VB, RAD principles + platform independence.)

Look what STL author had to say about Java, go to this page Interview STL creator and search for "java" on the page. "Can I summarize your thinking as "find the [generic] data structure inside an algorithm" instead of "find the [virtual] algorithms inside an object"?

A: Yes. Always start with algorithms. "

The man is absolutely 100% correct.
Real programming has to do with finding the best possible algorithm and reducing your problem to that algorithm (Stephen Cook, creator of Computability and Complexity CSC364 here
in any case, all languages have their use, assembler for speed; Fortran, ADA, Logo, Forth, PL1 for math; basic for kids; lisp, scheme, ml, prolog for AI; C, C++ for systems and game programming; Pascal, Turing for studies; Cobol, VB, Java for Money Oriented Programming

I love assembler, c, c++, my first language was basic for Atari 600, my first hextris was written in tp 7, my first fax driver in assemblerx86 and c++, my first tic-tac-toe game in scheme, first adventure game in prolog, first spreadsheet calculator in c, first AT&T rebiller app in Java, first bellmobility.ca Invoice On Line app in ASP, COM and HTML, first dynamic catalog in VB6, first xerox price calculator in java and c with NetCommerce, first mobile phone service for bell mobility in JSP, JS and java servlets, first Trinity Activeweb mobile server product for davinci.ca in Enterprise Java Beans with OODB and/or LDAP for distributed cache, corba, rmi.........

it's always a first.