Re: Future of C++

On Aug 10, 12:53 am, Razvan Cojocaru <razva...@gmx.net> wrote:


May I take this opportunity to say that I think quite the opposite?

I must apologize in advance for offending Ye Ole Great Masters of C++,
but I think overemphasis on abstract programming is one of worst
mistakes made in introducing C++ to the young engineering community.

Abstract programming, IMO, is like a narcotic. Yes it works. Yes it's
powerful. But It should be used sparingly. Typically, something less
exotic like aspirin is not only sufficient, but superior, in that it
does its job without causing side-effects. The "aspirin" is getting
aggregates to behave like scalars, a primary early goal of OO-
programming.

Perhaps the masters of OO programming were so afraid that young
engineers would stall in the aggregates-behaving-as-scalars rut, they
deliberately pre-defined OO programming to be synonymous with abstract
programming. They implied:

"If you are not using abstract polymorphism, you are not doing OO
programming".

What they should have been implied, IMO, is..

"If you are not using abstract base classes, you are probably not
realizing the full benefits of OO programming."

Anyhow, I think the current state of affairs is a mess. I have
encountered countless programmers in my career, both junior and
senior, who use virtual functions as if they were adding decorative
whitespace. [It's sad - one engineer had gotten into the habit of
makinv every member function virtual, no matter what.] They bypass the
aspirin at every opportunity and go straight for the hydrocodone.
Then they suffer through concomitant side-effects. And we all know
that there are definitely "side-effects".

But we must put side-effects in quotes because technically, there are
no "side-effects", as it implies that there is something defective
about the language itself, which there is not. If one uses virtual
functions, certain subsequent events will inevitably result. That's in
the contract. It's when the programmer wants it both ways when serious
issues arise:

"I have made all my classes abstract, but I would like to be able to
copy one derived to another without thinking too hard."

Ok, well, perhaps you should not have done that.

I see countless posts in this group and elsewhere of programmers
trying in vain to force their abstract classes to behave as if they
were concrete, when they could have just made the classes concrete to
start with.

My preference:

Aim for nickel-and-dime facilities of C++.

Given a class, I would be predisposed to make it concrete, then ask
the following questions about two objects of that class:

1. Can I assign one to the other?
2. Can I provide comparison >, <, >=, <=, ==, != ?
3. How do I construct one from the other?
4. What conversion operators are there, if any?
5. Can I serialize it?
6. Does it operate on state _only_ within itself?

Belive it or not, for any non-GUI project, 95%+ of my code fits this
model.

Then...

For those classes that are necessarily abstract, I allow a bit of
hydrocodone. :)

-Le Chaud Lapin-

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]