C++0x - the next ISO C++ standard | Hacker News Reader

C++0x - the next ISO C++ standard

www2.research.att.com

26 pointsm3mb3r18 comments

> Rely on the old mantra: If you think of it as a separate idea or object, represent it directly in the program; model real-world objects, and abstractions directly in code.

I think this is terrible advice. Thinking of object-oriented programming as "world modeling" leads to complicated designs that came from someone's pointless ontological analysis rather than practical considerations of what will make the best, easiest-to-understand program.

A simple example of this is the OO conundrum: should square derive from rectangle? After all a square is-a rectangle. If we're world-modeling, then the inheritance relationship is a beautiful and consistent expression of this platonic idea that a square is a special kind of rectangle.

But in practice, this inheritance relationship has lots of problems. http://stackoverflow.com/questions/1030521/is-deriving-squar...

And what was it really buying you to begin with? Pretty much nothing.

Actually it buys polymorphism.

And the square/rectangle example is rather contrived, not to mention wrong, as it assumes a naive constructor, er, construction:

a) of course a square is a rectangle. b) who said that you cannot add constraints to your model?

Oh, and by the way: the rectangle/square relationship is not "world modeling" --it's mathematics, as close to pure logic as it gets.

> Actually it buys polymorphism.

So does "square and rectangle both derive from polygon," but without the problems. (For "polygon" substitute "shape" or "drawable_thing" or whatever based on what your program is doing).

And "polymorphism" by itself isn't an end unless it makes your program better.

> of course a square is a rectangle.

Let me ask you this: is it your opinion that because a square is mathematically a rectangle that you should automatically express this with an inheritance relationship, even if it makes the program worse?

If so you are exactly the person that my message needs to reach. Please take it to heart and think about the hurt you are inflicting on the people you work with.

> Oh, and by the way: the rectangle/square relationship is not "world modeling" --it's mathematics, as close to pure logic as it gets.

It's absolutely "world modeling." You're trying to take some ontological fact about some object (in this case, a mathematical object) and express that in a software design.

> So does "square and rectangle both derive from polygon," but without the problems.

Well, there are SEVERAL kinds of modeling you can do, depending on your application needs. I mean, no shit Sherlock! Still, the problem with polygon -> rectangle still exist, you still need to have contraints.

> And "polymorphism" by itself isn't an end unless it makes your program better.

The same holds true for EVERY language feature: it's only useful if it makes your program better --so it's a tautology irrelevant here.

> Let me ask you this: is it your opinion that because a square is mathematically a rectangle that you should automatically express this with an inheritance relationship, even if it makes the program worse?

No, it's my opinion that if you express mathematical truths right, programs generally get BETTER. The right way is not always inheritance ―it's not even a basic feature of OO programming according to Alan Kay―, but in this case the example fits, and the "problem" spot you mention is contrived and easily solved.

And if you don't like theory, here's practice and history for you: a) almost EVERY successful game and drawing program written in a OO language, or C with some hacks (that makes 99% of 'em), uses such a shape hierarchy.

> It's absolutely "world modeling." You're trying to take some ontological fact about some object (in this case, a mathematical object) and express that in a software design.

Math (and logic) != world.

And a "mathematic object" is not an object, it's the expression of some axioms and constraints. The more faithfully you capture those in your code, the better off you are.

I think going through the ISO committees was a mistake. Too many years wasted in pointlessness.

That's why there is boost and lots of experimentation by compiler developers commercial and in academia.

C/C++/Fortran and other de jeur standard languages do seem to have a very long life with multiple implementations on multiple platforms...

Much of Boost is the next standard. It's awesome stuff. I love C++.

If I had my wish, the QT containers would become the standard.

I know c++ and complexification go together like bread and jam but STL in general and especially Boost seem to go too far for even for the rest of c++.

Of course, I'm sure if I worked with it enough, I'd learn it's strange beauty. It's just I hadn't so far.

ISO standardization also makes things too static at times. For instance, the hash table omission accident gave us non-standard hash tables for years, until TR1 was finally settled.

Boost is nice, but usually only ancient versions are available on clusters (where RHEL 4 or even 3 is still common). The more complete the standard language library, the better.

You can always compile boost and install it locally, the full 64bit version only takes about 100MB:

  $ du -hsc boost/1.45.0/*
  68M     boost/1.45.0/include
  37M     boost/1.45.0/lib
  104M    total

Add cmake/autoconf and it's fairly trivial to make it work with your software or even ship it with your source code: after all the Boost license is fairly permissive.

Yes, that is what we do. We include a Boost subset. But that shouldn't be necessary. It's extra maintenance, duplication, and annoying.

On what distributions do you find ancient versions of boost but recent versions of GCC? If the standardization process moved faster you'd still have to wait.

de jeur => du jour? de jure?

>However, to minimize confusion, I'll keep referring to the upcoming C++ standard with the feature set defined here as C++0x. Think of 'x' as hexadecimal (most likely 'B', i.e. C++11).

Just have to point this out: this C++ goes to eleven.

I should look into C++0x some time; I've been hearing good things, but I've never touched it.

The hamming and hawing on this one says everything one needs to know about C++0x:

http://www2.research.att.com/~bs/C++0xFAQ.html#learn

"everything you need to know" being ...that it doesn't lock you into a single paradigm? ...that you're permitted to specify things that other languages keep hidden?

That it's become too difficult to learn.

Do you need to pass C++0x to graduate or something? If it's too difficult, don't learn it. There are plenty of non-C++ jobs.

Reply on news.ycombinator.com