

C++0x - the next ISO C++ standard - m3mb3r
http://www2.research.att.com/~bs/C++0xFAQ.html

======
haberman
> 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...](http://stackoverflow.com/questions/1030521/is-deriving-square-from-
rectangle-a-violation-of-liskovs-substitution-principle)

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

~~~
foljs
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.

~~~
haberman
> 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.

~~~
foljs
> 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.

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

~~~
woan
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...

~~~
danieldk
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.

~~~
slug
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.

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

------
Groxx
> _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.

------
SeanLuke
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>

~~~
tbrownaw
"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?

~~~
SeanLuke
That it's become too difficult to learn.

~~~
chancho
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.

