Anyone else feel like C++ is getting too complicated?

[Tony]

Exactly. Unless you're writing a library that uses move semantics I'm
pretty sure you simply don't need to care what rvalue references are or
how they work. The rvalue reference solves an important problem for
library writers. For instance, you'll now be able to store uncopyable
objects in the standard containers because of this language feature.


More than that I believe. The boost::concepts can do that. The concepts
in the new standard, as a feature of the language and not some coding
hack, allows you to write template code that will only activate for types
that represent the required concepts. In other words, you'll be able to
competently decide which template code to use based on the concepts your
type represents! This is a MAJOR benefit, especially for library authors.

Although not everyone understands concepts in C++, everyone SHOULD.
Concepts are far from new and the entire standard library uses them.

"The entire std lib uses them" is hardly a selling point!

They're just not possible to enforce by the language yet and when you
violate the documented concept interface of a type in the STL you get
template error vomit instead of something nice. The new language simply
takes something you've been using all along and makes it a feature of the
language.

Or patching up (bandaging) a feature lacking or under-developed in the
language?

********

RFP: Separate thread for discussion, analysis, politics of C++ concepts.
High level discussion first recommended (as in, maybe the whole
template/concept subsystem could be eliminated with a higher level
architecture).

Tony

 

[Tony]

[ ... ]

If I needed some "concept" I would create an abstract class
that has all those properties and the compiler could check
that the given type conforms to all the properties of the
specified class.

Not so. If you use inheritance, you quickly end up with something
virtually indistinguishable from Smalltalk. In particular, your type
checking ends being done at run-time rather than at compile time.

The problem is fairly simple: inheritance means selecting a type far
enough up the tree that it's an ancestor of EVERY type you might care
to work with. Unfortunately, that almost inevitably includes a lot of
other types you don't want to work with.

You also end up really warping the inheritance tree to make this work.

Consider for example, sorting collections of objects. We can compare
strings, so we want to support sorting collections of strings. We can
also compare integers, so we want to support sorting collections of
strings. To support that, we have to apply 'sort' to some common
ancestor of both 'string' and 'integer' -- so far so good.

Sounds like the solution is to stick with passing in a comparison function
pointer to the container since the alternatives become complex quickly.

 

[Tony]

Looking at it from a slightly different direction, programming
languages are following the same path that databases did decades ago.
Databases progressed from the hierarchical model to the network model
and finally to the relational model.

"finally"??? Most recently the relational model has had some competition in
"certain" domains where the complexity of the relational model is overkill:
See,
http://www.infoworld.com/d/data-management/slacker-databases-break-all-old-rules-599.

Single inheritance implements
the hiearachical model. Multiple inheritance implements the network
model. Concepts implement the relational model.

The question becomes, "what is the *simple solution* that will surface after
concepts?".

 

[Jerry Coffin]

[ ... ]

If I needed some "concept" I would create an abstract class
that has all those properties and the compiler could check
that the given type conforms to all the properties of the
specified class.

Not so. If you use inheritance, you quickly end up with something
virtually indistinguishable from Smalltalk. In particular, your type
checking ends being done at run-time rather than at compile time.

The problem is fairly simple: inheritance means selecting a type far
enough up the tree that it's an ancestor of EVERY type you might care
to work with. Unfortunately, that almost inevitably includes a lot of
other types you don't want to work with.

You also end up really warping the inheritance tree to make this work.

Consider for example, sorting collections of objects. We can compare
strings, so we want to support sorting collections of strings. We can
also compare integers, so we want to support sorting collections of
strings. To support that, we have to apply 'sort' to some common
ancestor of both 'string' and 'integer' -- so far so good.

Sounds like the solution is to stick with passing in a comparison function
pointer to the container since the alternatives become complex quickly.

This isn't really much of a solution. Just for one example, it's how
qsort (from the C standard library) works. Problems include:

1) slow (e.g. std::sort is often three times as fast)
2) not type safe (comparison function receives pointers to void...)
3) complex to use (at least in the case of qsort)

It may be possible to work around the third to some degree (e.g. using
template tricks to determine element size) but the first two are much
more difficult problems.

It's certainly possible to produce vaguely template-like capabilities
using, for one example, macros -- in fact, some of us have done exactly
that. Long ago, before templates were part of the language, there was a
header called generic.h that allowed a degree of generic programming
without templates. This certainly reduces the complexity of the language
-- but it drastically _increased_ the complexity of programs written in
that language. It was a lousy tradeoff then, and it wouldn't be any
better now.

 

[Jerry Coffin]

"finally"??? Most recently the relational model has had some competition in
"certain" domains where the complexity of the relational model is overkill:
See,
http://www.infoworld.com/d/data-management/slacker-databases-break-all-old-rules-599.

I've already seen it. At least to me, it appears that the author thinks
"relational" equates to "SQL". This isn't really true. While it's
certainly true that these depart from the SQL database in various ways,
they all still follow the relational model to a fairly large degree.

Other than that, it's generally true that the relational model is rather
a "middle of the road" solution. A more free-form database tends to give
more flexibility at the expense of computing efficiency. A more
restricted model (e.g. hierarchical) tends toward the opposite. Both
have their uses, but neither appears likely to really dominate any time
soon.

It is, however, true that "finally" was probably a poor choice of words
-- the relational model (or some imitation of it) has dominated database
development for four decades or so, but even a complete implementation
probably wouldn't be the final stage of database development. The trend
toward cheaper computing power favors flexibility over efficiency.

The question becomes, "what is the *simple solution* that will surface after
concepts?".

I doubt that question has much relevance. Even if you could figure out
what language features (and such) were going to be used, say, 50 years
from now, I doubt it'd be much use. Trying to use that future language
on current hardware would be a bit like trying to run a current C++
compiler on an Apple II+ with 32K of RAM and 140K floppy disks.

 

[Guest]

Look, I am French, and even worst, I live in Paris. I know
something about fads really.

almost sig material!

 

[Guest]

Jacob, you're not the only one with code stranded in this way.
Or variations there of. In my case typename.

The language became standardised.  The upcoming standard should not
break code conforming to the current standard.



4-5 man-months?  How many tens of millions of lines do you have?  More
to the point, how many did you have in 1999 when the language became
standardised?

in our case not all the code is ours we have third party libraries.
We don't have the source code. Hacking someone else's header files
fills
me with...

 

[Tony]

I doubt that question has much relevance. Even if you could figure out
what language features (and such) were going to be used, say, 50 years
from now, I doubt it'd be much use. Trying to use that future language
on current hardware would be a bit like trying to run a current C++
compiler on an Apple II+ with 32K of RAM and 140K floppy disks.

Programming languages will become simpler rather than more bloated because
of the abundance of processing power available (primary and secondary
storage too), at least for the majority of mainstream programming (whatever
that is ). Exotic languages and techniques will be for the exceptional
cases and specialized environments. More emphasis will be placed on what is
adequate for the application and platform and how simply can it be
implemented (including how "simple" the libraries and language are in use
and implementation) rather than such esoteric things as container
performance when it wouldn't matter for the application even if an algorithm
was 30 times slower. Comprehensible and maintainable design (and other
things) will be more important that benchmarks. This is not that far off
into the future. (More observable in new development where there is not
existing codebase and infrastructure holding back progress toward
historically unrealized elegance).

 

[Jerry Coffin]

[ ... ]

Programming languages will become simpler rather than more bloated because
of the abundance of processing power available (primary and secondary
storage too), at least for the majority of mainstream programming (whatever
that is ).

I hesitate to predict the future -- it has a habit of ignoring what
seems to make sense, at least to me, and doing what it will.

Exotic languages and techniques will be for the exceptional
cases and specialized environments.

That, however, is an easy prediction to make -- for the simple reason
that it's essentially a tautology. Essentially by definition, the only
way it's exotic is that it is for exceptional cases or restricted
environments.

More emphasis will be placed on what is
adequate for the application and platform and how simply can it be
implemented (including how "simple" the libraries and language are in use
and implementation) rather than such esoteric things as container
performance when it wouldn't matter for the application even if an algorithm
was 30 times slower.

The design of a general-purpose language (by definition) can't take the
application or platform into account, so this is basically just
predicting more use of special-purpose languages, which I think is
probably correct.

As far as general-purpose languages go, however, I don't think it'll be
reasonable to completely neglect things like performance of containers
any time soon. It's been predicted for decades, but reality hasn't
followed suit.

Comprehensible and maintainable design (and other
things) will be more important that benchmarks. This is not that far off
into the future. (More observable in new development where there is not
existing codebase and infrastructure holding back progress toward
historically unrealized elegance).

I agree with this statement -- but it could have been made anytime over
the last 50 years and been equally true!

 

[Tony]

[ ... ]

Programming languages will become simpler rather than more bloated
because of the abundance of processing power available (primary and
secondary storage too), at least for the majority of mainstream
programming (whatever that is ).

I hesitate to predict the future -- it has a habit of ignoring what
seems to make sense, at least to me, and doing what it will.

Exotic languages and techniques will be for the exceptional
cases and specialized environments.

That, however, is an easy prediction to make -- for the simple reason
that it's essentially a tautology. Essentially by definition, the only
way it's exotic is that it is for exceptional cases or restricted
environments.

The suggestion of course was that use of C++ today is an exotic but the
nicer thing is just not yet available.

The design of a general-purpose language (by definition) can't take
the application or platform into account, so this is basically just
predicting more use of special-purpose languages, which I think is
probably correct.

'twas what I was kinda alluding to, yes, but certainly not the emphasis on
"special purpose", as they will be "practically general purpose" rather than
"extremely general purpose".

As far as general-purpose languages go, however, I don't think it'll
be reasonable to completely neglect things like performance of
containers any time soon. It's been predicted for decades, but
reality hasn't followed suit.

But the GP languages of today are the exotics.

I agree with this statement -- but it could have been made anytime
over the last 50 years and been equally true!

The fact that so many languages have been developed and are still be
developed does not bode well for the GP language pursuit: apparently "GP
language" is an oxymoron.

 

[Jerry Coffin]

[ ... ]

The suggestion of course was that use of C++ today is an exotic but the
nicer thing is just not yet available.

It isn't exotic as long as it's used in lots of mainstream applications.
That hasn't happened to C++ yet, and I'm not sure it will any time soon.
It will undoubtedly happen sometime, but exactly how soon I'm uncertain.
There aren't many languages around (right now) that could replace C++ in
a lot of applications, and the few that realistically _could_ (e.g. Ada
95) strike me as extremely unlikely to do so. Of course, at least in
theory, you could write anything in almost any language if you wanted to
badly enough -- but I can't quite imagine anybody deciding to write a
JVM in Lisp, a graphics engine in COBOL, or an operating system kernel
in Fortran.

[ ... ]

'twas what I was kinda alluding to, yes, but certainly not the emphasis on
"special purpose", as they will be "practically general purpose" rather than
"extremely general purpose".

Well, there are certainly a number of applications (e.g. network stuff)
where the performance of something like Java or Perl is perfectly
adequate for quite a few purposes. These certainly form a large class of
applications, but I don't see them growing to the point that they really
relegate C++ to "exotic" status anytime soon.

But the GP languages of today are the exotics.

In that case, I can only guess that you're defining "exotic" rather
differently than anybody else I know about.

At one time, for a short while, C++ was a "hot" language -- claimed by
many to be the cure of all the ills of programming in general. That made
it a default choice of languages for a lot of projects to which it was,
quite frankly, not particularly well suited (including some for which it
was really poorly suited). The language of the month club being how it
is, however, that dubious honor has long since passed on to other
languages. As such, C++ is now more often chosen for other reasons. That
has undoubtedly reduced its usage somewhat, but not nearly to the point
that I can imagine calling it exotic -- and the same is true for most of
the other general purpose languages as well.

[ ... ]

The fact that so many languages have been developed and are still be
developed does not bode well for the GP language pursuit: apparently "GP
language" is an oxymoron.

Two basic points: first of all, you're right to a limited degree -- not
really about the languages themselves, but about the terminology.
Nothing (C++ or anything else) is equally suited to every possible task.
At the same time, the use for C++ and similar languages still exists;
the language remains useful regardless of the fact that I don't know of
a way to describe the type of situation for which it's best suited in a
word or two. The problem there is that despite it's not being entirely
general purpose, the tasks for which it is well suited vary over a
rather wide range.

 

[Tony]

[ ... ]

The suggestion of course was that use of C++ today is an exotic but
the nicer thing is just not yet available.

It isn't exotic as long as it's used in lots of mainstream
applications.

No, that is not correct. (See "Holocaust").

Well, there are certainly a number of applications (e.g. network
stuff) where the performance of something like Java or Perl is
perfectly adequate for quite a few purposes. These certainly form a
large class of applications, but I don't see them growing to the
point that they really relegate C++ to "exotic" status anytime soon.

You are thinking way too narrowly: you chose an IT (read: within the
forrest) "domain". Think out of the box.

In that case, I can only guess that you're defining "exotic" rather
differently than anybody else I know about.

But you don't know anyone else (but yourself), do you? (?)

At one time, for a short while, C++ was a "hot" language

I remember that! I "had learned" C (read made low-volume production programs
in C, having suffered with handed-down handed-over "engineered" (code not
engineered, but made by engineers not of the IT variety) FORTRAN and even
BASIC ) and was "burning it in to my mind or trying to find the "what am I
missing in all this?"" via (available at my place of employment) video tapes
from Borland featuring David Intersimone! (I'd time-travel back, (in a
second! (not for a second!)) then for a few of the girls that actually
wanted something with me! Yowza!). Some people were suggesting I should
"take a look at C++". I did, a few years later, as it was a natural
progression..... long story short, now I'm here to perturb y'all.

-- claimed by
many to be the cure of all the ills of programming in general.

Do you think that it is the solution to the H1N1 virus? If I didn't know
English, reading this NG would lead me to "BELIEVE" (REPENT! Ye all
sinners... REPENT!) that C++ could defeat Megalon. (Aside: Is Infra Man
still living?).

That
made it a default choice of languages for a lot of projects to which
it was, quite frankly,

[got A LOT of money for "consultantcies"!]

not particularly well suited (including some
for which it was really poorly suited).

What? ... What??? I thought C was a GENERAL PURPOSE language. (WTF?!).
(Lawsuits abound).

The language of the month

But it was the old timer! (Go figure).

club being how it is, however, that dubious honor has long since
passed on to other languages. As such, C++ is now more often chosen
for other reasons.

History has repeated itself and we are talking about history.

That has undoubtedly reduced its usage somewhat,

Are you sad?

but not nearly to the point that I can imagine calling it exotic --

"Death and taxes". (DEATH, and taxes?? (see: Joe Black)).

and the same is true for most of the other general purpose languages
as well.

May I have some "peanut butter"? I find it astonishingly good.

[Epitaph snipped]