Comment by shin_lao | Hacker News Reader

Comment by shin_lao | Hacker News Reader

Too bad the points raised about C++ aren't valid. Ok, I admit, I get easily upset by language bashing (C++ or another).

The problem is that when you notice something inaccurate in a document, you have the tendency to ignore the rest...

It is a superior alternative for classic application development, and some nice slim and full-featured GUI toolkits use its qualities well.

I would say C++ is the way to go for servers, not really GUI. As much as I love C++ I wouldn't recommend using it for writing a GUI.

dynamic_cast<MyData>(funky_iterator<MyData &const>(foo::iterator_type<MyData>(obj))

I get it's a joke, but it would be a better joke if it was actually valid C++ or close to something you would actually write.

contemporary C++ using STL looks like a classic case of the "If all you have is a hammer"-syndrome

I don't understand what it means. The STL is a very powerful tool to implement complex data processing and work on structure. Is this another case of someone using the containers without using the algorithm's functions?

Except that code isn't really that far from what you might type. I've spent a lot of time working with code that uses templates heavily (including "well designed" libraries like Boost) and it's just a god-awful mess. Make an error in instantiating a template class and you get an error message that refers to code deep in an STL header. Want to make your container class iterable? Get read to write dozens of lines of inscrutable boiler-plate code. Even something simple as iterating over a container is braindamaged. Before the auto keyword you had:

    for(vector<some_really_complex_type>::iterator itr = something.begin(); itr != something.end(); ++itr)

Then you need to use "itr." It's a pointer-like thing that isn't quite a pointer, and when you hold pointers in your container, which you often (usually) want to do you have to deal with a pointer-to-a-pointer which is almost never pleasant. And when you deal with keyed containers you have to remember the iterator actually points to a pair so you have to do .first and .second (why not .key and .value?)

Braindamage doesn't even begin to describe it.

I rarely use the "for" or "while" keywords. I use the algorithms instead.

The containers have been designed with this is mind.

If you don't use the algorithms, indeed, the STL can be cumbersome to use.

But then you have to define the loop internal logic elsewhere because C++ has no lambda (yet, at least in most places where it's used in production).

But then you have to define the loop internal logic elsewhere because C++ has no lambda (yet, at least in most places where it's used in production). God help you if you have a lot of variables that need to be compared or referenced inside the loop.

Without lambdas you use functors.

> then you have to define the loop internal logic elsewhere

The loop is performed by the algorithms.

See std::for_each, std::transform, std::accumulate, std::partition, etc., etc.

The algorithms are a PITA without lambdas, and are not easily composable or extensible to express more complex iteration. None of them can work with multiple containers, which makes writing even something as simple as a "zip" function using the algorithms an exercise in futility.

And predictably you were downvoted...

First of all, like you've mentioned, his C++ example code is bogus. Second of all he says "modern funkiness of dynamic languages" only to continue with lambda, map/reduce and type independence. The first two are unrelated to dynamic/static typing, the latter is incorrect or badly phrased. You don't get "type independence" in dynamic typed languages, the types are still there. Thirdly, he greatly exagerates the complexity of templates (thousands of incorrect syntax options for smart pointers, all you have is a hammer, etc)

It's a classic case of fishing for arguments to support an idea.

I agree, the STL is a great resource and I miss it in other languages. However, the long type declarations clutter up code. Type inference would make STL code much, much, much, much, much easier to read. Mentioning a container's type once improves readability. It is nice to know that you're dealing with a vector<map<string, set<int> > > if someone has written some crazy code that uses one. Having to repeat the type over and over again, for example, needing to declare that your iterator variable is of type vector<map<string, set<int> > >::const_iterator, makes STL code unnecessarily painful to write and to read. The STL's consistency and feature set certainly makes other language's collection libraries look amateurish by comparison, but the lack of type inference in C++ makes the STL a mixed blessing.

C++0x has type inference via the "auto" keyword: http://en.wikipedia.org/wiki/C%2B%2B0x#Type_inference

It is available in compilers today -- for example, Visual C++ 2010 supports "auto".

Reply on news.ycombinator.com