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

[Zachary Turner]

Whatever.  Then stop using it.

See, this is exactly the attitude that fails so, so hard and is
unfortunately so, so easy to fall victim to. Are you seriously
suggesting that there is no room for constructive criticism, and that
we should instead just take everything we're given with glowing eyes
because They have graced us with it? Ok, maybe the guy you were
responding to was a little extreme in his criticism, I don't think C++
is "spectacularly unproductive", but it sure as HECK isn't
"spectacularly productive", which ideally is what you want out of a
language.

The reason I bring this issue up at all is because I *do* love C++,
and I would like to be using it 10 years from now. However, if I want
a language that gives me warm fuzzies when I do something that's
incredibly elegant, yet incredibly hard to understand for the average
programmer, I'll program in Haskell (which tbh is where I might end up
going after I abandon C++). But at least there they make no mistake
about their target audience. It's for academia, by academia,
literally. C++ is caught in this purgatory state where it's
pretending to be for the mainstream, yet most of the new things that
get introduced are incredibly academic in nature and there is no hope
of an ordinary programmer understanding it. And every time something
practical that actually MAKES SENSE and is easily understandable is
proposed, it gets shot down. See Alf's response near the top of this
thread, or see Herb Sutter's proposal to remove the export keyword
from the language (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/
2003/n1426.pdf). Another perfectly reasonable and practical
suggestion, shot down because it lowers C++'s academia score.

 

[pasa]

b) You actually misrepresent what I said. All that follows is that
complexity has drawbacks. Whether the advantages outweigh the costs is a
different matter altogether. But what does not fly is pretending the costs
do not exist. (And this is what you did in the part you snipped and that I
responded to.)

The point is, that with the new standard the added/changed stuff makes
the language *use* *less complex*. Compilers possibly will sweat a
little more, but on the end user end you *lose* many awkward tricks or
ambiguity to be replaced with way clearer and easier things.

A few examples:

- threads: memory model, library. Single threaded environment not
effected. MT had to deal with issues "in the wild", now you have
strict guarantees and portable lib in the box.

- auto: finally kill the redundancy and verbosity just to tell the
compliler it already should know

- concepts: as template user you get clear error message on bad use,
and clear documenttion of the intent;
as template writer you can tell the intent in code instead of leaving
to vague comments. as bonus you finally can create defaults,
alternatives, those writing templates have a huge list of pain -- now
mostly gone

- rvalue refs: as library user you can benefit from move semantics
without doing anything. as tweaker remove worries about extra copies.
+bonus, can collect extra types

- bind: nuff said

- more smart pointers, collections: no more hunt for external libs for
stuff you likely want

 

[pasa]

I'm suggesting that they should be honest about who their target
audience is.

Who is "they"?

C++ was thought complex from the start, it sure was at first standard.
The world invented VB, java, C# to be lighter on programmers and
learning curve. (Read Joel Spolsky on javaschools for the result... )

As of now C++ is still considered the second best pick for any
particular task, and beign multi-paradigm you can get way better
results than with a fast pick.
It ceratainly needs more brains on the programmer and more time to
master. If you have bad or lazy programmers, forget it. (industry
shows that those wreak havoc in any language, so its better to just
not use them...)

 If the intended audience is academia, they're free to do

No, the intended audience is bright pragmatic programmers. With a
calling too. Those who are not afraid to read a few books, and pay
attention to learning instead of just experimenting in the editor
until something compiles and "looks like work".

I.e. terms like "lvalue" and "rvalue" were present IIRC even in the
K&R C book. and reference was in CFront 1.0. So what can be the the
problem understanding rvalue reference and lvalue reference? Guess
those without clue never understood the difference of rvalues, and
coded bugs wherever it mattered.

whatever they want with it.  Make it as complicated and impractical as
humanly possible.  But if they're going to claim that it's a language
for use in solving mainstream, practical problems, then that's what it
needs to be.

And it is too. Then if it is not fit for your field, don't use it. Or
if you like the '98 version, stick with that, the compilers will not
disappear, and most have switch to select the acting rules.

 And currently, it's not anywhere close to that.  It's no
longer the best at anything really,

Was it ever? And nowadays with more frameworks, toolsets, the pick is
even less based on language but the libraries, ready components and
stuff like that. For greenfield projects.

And where you contnue the existing job... you're stuck with most
elements anyway.

except perhaps at interfacing with
legacy C/C++ code.  If you want to write code that's in a HLL and
still close to the OS you can use D now.  Indeed, Andrei Alexandrescu
is even a big fan of D now.  (I have no idea what his stance is on C++
anymore, he could very well still love it).  

So then what? People make D, E, F -- should that seal C++? And leave
it as it is, not addressing the many problems and needs of the users?
Hope you don;t claim it is not used and there is shortage of projects
that will need maitainance further.

I'm also noticing that you've sidestepped the real question in every
single one of your responses, and instead chosen to respond with
subtle suggestions that I might, perhaps,
be too stupid to understand C++'s awesomeoness.

Honestly, your posts after the first indeed leave the impression of
empty flame and closed mindset. And there's nothing much to address,
in taste-based stuff. You have the right to not like C++ or think it
is [whatever]. Or flame it or bash it.
If you mean your examples seriously however -- you need to go down to
details and explain what is really YOUR problem. As those you picked
are quite straightforward. Not liek two-phased lookup, or
similars.

 To which I would say that first of all, you should
try to answer the real question (in particular, why should someone
bother using a language for which the learning curve is unnecessarily
high compared to the productivity curve,

Inesrting 'why' before false statements will not form sensible
questions.

And the whole approach is fishy -- many people already know C++ and
used it for a deal of time -- so can pick up the difference easily and
enjoy.
Language and environment for a particular project is decided using
many factors -- but not from the big bang. I heard of 0 cases where
language were decided and company hired greenies all starting to learn
the decided language. Instead you either have the knowledge in house
or hire it. And beyond very trivial scope the learning curve of the
language itself is little compared to the buiness logic/the real
task.

If only language learnability counted we would all use nothing but
scheme, would we? Or maybe python. (and yeah, I suggest pick thse,
or anything if fits).

The advantage of C++ over many others is being multi-paradigm, so it
gives you more tools to cover the task with optimal ones. i.e. with
java you can learn faster, but if your task does not match very
closelt "the one JAVA WAY", you get hosed very soon, and will suffer
for the rest of your time. Whatever good programmers you get early or
late.

when you can achieve exactly
the same things in other languages much simpler),

That depends quite much. A big project can have many different
"things", that are easy to cover by many languages -- and you'll have
the problem unable to put together.
Or pick up such new, non-fitting stuff in V2.5 and later...

and second of all,
when you have to convince a large number of people (and believe me, I
don't think I'm the only one) who have been proponents of C++ for a
very long of C++'s long-term position in the world of programming
languages, then perhaps it's time for some inner reflection.  Instead
of just denying everything people are saying without giving it some
actual thought, think about what people are saying.

Huh? The C++ standard is being made from like '93 and the process is
open to everyone. Whoever have something to say (add, remove, modify)
can do it in the committee directly or submit as proposal, or talk in
forums (comp.std.c++, this, this.moderated has several dozens of
people with drect influence, and pay attention to input.

 

[pasa]

See, this is exactly the attitude that fails so, so hard and is
unfortunately so, so easy to fall victim to.  Are you seriously
suggesting that there is no room for constructive criticism,

Where is the *constructive* part of criticism? 'c++ is complex' is
not that. Especially as it is a fact of life that will not go away:
it applies to C++98 and back-compatibility was always the top
priority.

That one is really 'take it or leave it'. But we're still listening
anything constructive, how to make stuff better?

I don't think C++
is "spectacularly unproductive", but it sure as HECK isn't
"spectacularly productive", which ideally is what you want out of a
language.

I know people and projects where it worked very well, also others
falling in trap of some seemingly "faster" tech and failed to
complete.

It is engineering task to chose the tools/language correctly.

The reason I bring this issue up at all is because I *do* love C++,
and I would like to be using it 10 years from now.  However, if I want
a language that gives me warm fuzzies when I do something that's
incredibly elegant, yet incredibly hard to understand for the average
programmer,

Will you be happier if we post a statement in NY Times that "C++ is
NOT for the average programmer"? IMO programming in general is not
for the average programmer. I mean it. This profession stinks big
time, and shows no signs of clearing up. At least in some fields
programming should be tied to kind of licence and related exams (as
goes for doctors, architects, etc...). 80+% of programmers I saw IRL
are pure danger to leave working on their own.

And yes, C++ is even more demanding. And leaves more dangers too, many
cases of UB, etc.
Let's hope in the next 10 years at least some separation happens, and
who remains with C++ will be the fittest.

C++ is caught in this purgatory state where it's
pretending to be for the mainstream, yet most of the new things that
get introduced are incredibly academic in nature and there is no hope
of an ordinary programmer understanding it.

???
http://en.wikipedia.org/wiki/C++0x
has a summary of changes, please cut the list and mark the bullets
that fit that description. Then we may have some constructive
conversation, also with some figure of the infestation percentage.

 And every time something
practical that actually MAKES SENSE and is easily understandable is
proposed, it gets shot down.

Can you list *worked out* proposals that were just dismissed without
justification?

See Alf's response near the top of this
thread, or see Herb Sutter's proposal to remove the export keyword
from the language (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/
2003/n1426.pdf).

Well, export is a sad story, but how many like that we have compared
to all the proposals? but it hardly fits the above description still.

I didn't follow intrusive_ptr, but would guess there were pretty good
reasons it didn't make it, "every time" dismissing "anything that
makes sense" looks like a gross statement, and you need a fat list to
even start looking supported...

 Another perfectly reasonable and practical
suggestion, shot down because it lowers C++'s academia score.

Just thinking people in the committee, how academy gets in the
picture, really.

 

[snk_kid]

See, this is exactly the attitude that fails so, so hard and is
unfortunately so, so easy to fall victim to.  Are you seriously
suggesting that there is no room for constructive criticism, and that
we should instead just take everything we're given with glowing eyes
because They have graced us with it?  Ok, maybe the guy you were
responding to was a little extreme in his criticism, I don't think C++
is "spectacularly unproductive", but it sure as HECK isn't
"spectacularly productive", which ideally is what you want out of a
language.

The reason I bring this issue up at all is because I *do* love C++,
and I would like to be using it 10 years from now.  However, if I want
a language that gives me warm fuzzies when I do something that's
incredibly elegant, yet incredibly hard to understand for the average
programmer, I'll program in Haskell (which tbh is where I might end up
going after I abandon C++).  But at least there they make no mistake
about their target audience.  It's for academia, by academia,
literally.  C++ is caught in this purgatory state where it's
pretending to be for the mainstream, yet most of the new things that
get introduced are incredibly academic in nature and there is no hope
of an ordinary programmer understanding it.  And every time something
practical that actually MAKES SENSE and is easily understandable is
proposed, it gets shot down.  See Alf's response near the top of this
thread, or see Herb Sutter's proposal to remove the export keyword
from the language (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/
2003/n1426.pdf).  Another perfectly reasonable and practical
suggestion, shot down because it lowers C++'s academia score.

I'm sorry but all your comments about new features and/or changes in
the next standard revision (C++0x) being only targeted at academia are
just ridiculous. I use C++ in my job, as far as I can see every new
proposed feature/change is not motivated by research papers in
programming language theory. The only new feature that remotely comes
close to this is the new Concept system but they where only part of
researching a solution to a common problem, which is not even a
problem unique to C++ & templates, it is a more general problem of
providing bounded quantification of parametric polymorphism where the
method used to implement parametric polymorphism in this case is
templates. .NET generics provide a mechanism to bounded quantification
as does Haskell, it is a necessity not a novelty. These features are
not a new idea that is being tried out just for the sake of it.

 

[Juha Nieminen]

Are you seriously
suggesting that there is no room for constructive criticism

Well, feel free and go ahead.

Personally I didn't find that post very constructive. It didn't have
any suggestion on how to improve the situation. It was just whining.

 

[Juha Nieminen]

I'm suggesting that they should be honest about who their target
audience is. If the intended audience is academia, they're free to do
whatever they want with it. Make it as complicated and impractical as
humanly possible.

The main problem in your argumentation is that you make it sound like
the new features make using the language more complicated. You have not
presented any reason or evidence of this whatsoever. Your only evidence
seems to be "there are more features than before". In other words, you
are simplistically equating "more features" with "more complicated to
use", without even trying to explain why these two things would go hand
in hand.

Since one of the goals of the new features is to make the language
easier to use, you are basically implying that they are wrong, that the
new features do not make the language easier to use, but harder. Again,
you have presented absolutely no arguments or evidence of this
whatsoever. Again, you seem to naturally assume that "more features"
equals "more complicated to use".

Just as a concrete example: The new 'auto' feature is being added to
make it easier and simpler to write code. It seems that, according to
your logic, because this is an additional new feature, it makes using
the language more complicated. Care to explain how the 'auto' feature
makes writing code more complicated, as opposed to its actual goal,
which is to make writing code easier and simpler?

As long as you don't give convincing arguments about why the new
features make using the language harder, I don't think your point has
any basis.

If you don't want to use C++ because it's "too complicated" in your
opinion and has "no advantages over other languages", then by all means
don't use it. There are tons of languages out there. Feel free to choose
whatever you want. But don't start bashing C++ based on no evidence,
only on the really simplistic assumption that "more features" equals
"more complicated to use".

 

[Ian Collins]

Yes.. I haven't tried to "bash" C++ for not being optimal. I was merely
substantiating the OP's point that C++ is getting too complicated, from
my perspective.

But you don't have to bother with the bits you find too complex.
There's nothing to stop you sticking to the subset you understand.

I'm currently helping a C team transition to C++ and that's what we're
doing: small steps.

 

[Stefan Ram]

But you don't have to bother with the bits you find too complex.
There's nothing to stop you sticking to the subset you understand.

Except from the fact that professional programmers more often
have to modify existing code than to write new code. This
means that a professional programmers has to read code more
often than he has to write code. The authors of the code he
has to read usually will not know which bits he finds too
complex, so they can not avoid them.

»C++ is already too large and complicated for our taste«

(This message is signed by a group of names including
»Bjarne Stroustrup« and was posted to Usenet as

From: (e-mail address removed) (Bjarne Stroustrup)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: C++ Language Extensions
Message-ID: <[email protected]>

The current C++ specification has about 700 pages, but one
needs to know the C specification it is based upon, too.
This C specification from 1990 is not easy to obtain, and
it has about 300 pages. So alone the specification of C++
has about 1000 pages (plus parts of other ISO specifications
needed to understand some wording). Reading specifications
will not educate about common usage, such as template
metaprogramming or Doxygen - which has to be learned in
addition to the language fundamentals.

 

[Stefan Ram]

Except from the fact that professional programmers more often
have to modify existing code than to write new code.

Maybe this is, why someone wrote »Today's C++ programs will be
tomorrow's unmaintainable legacy code.«

 

[Juha Nieminen]

Except from the fact that professional programmers more often
have to modify existing code than to write new code.

A professional C++ programmer who has to modify existing programs and
doesn't know the language well enough to do so?

I don't know what you call that, but I call it incompetence. You
should know your field of expertise, especially if you do it as a
profession.

Are you going to tell, for example, a TV repairman that TVs are
internally too complicated and thus no TV repairman should be expected
to be able to do their job?

 

[Stefan Ram]

A professional C++ programmer who has to modify existing programs and
doesn't know the language well enough to do so?

Yes, to use C++, one needs to know the language in
the extend it is used in the field, but can not
just select some »easy« parts of it. That was what
I wrote.

Are you going to tell, for example, a TV repairman that TVs are
internally too complicated and thus no TV repairman should be
expected to be able to do their job?

In fact, when a TV is broken, often, I believe,
the repairman will not try to understand what
actually is wrong, but either suggest to buy a
new one or swap each of a few modules until it
works again. But this discussion about TVs
distracts from C++.

 

[Juha Nieminen]

Yes, to use C++, one needs to know the language in
the extend it is used in the field, but can not
just select some »easy« parts of it. That was what
I wrote.

In the process, maybe this professional might learn something useful.
"Hmm, perhaps I could use these so-called rvalue references to make this
old library of mine more efficient and easier to use."

That's a bad thing? Some people certainly make it sound like it is.

I don't think anybody has denied that the C++ language is large and
with lots of features, some of which are complex to understand and fully
utilize. However, it can be reasonably argued to what extent this
hinders the usability of the language.

IMO equating "tons of features" with "is complicated to use" is too
simplistic. That same equation could be used to argue that a basic
command-line version of linux with no GUI is easier and less complicated
to use than a full graphical version with a fancy window manager and
tons of software. The latter version will undoubtedly have a lot more
features (especially since it will usually be a pure superset of the
former), but that doesn't automatically mean it's harder to use. Usually
it means the exact opposite.

 

[Noah Roberts]

Where is the *constructive* part of criticism? 'c++ is complex' is
not that.

Exactly. I'm just sick of the crying. Anyone that is going to reply to
a set of statements explaining why these constructs are necessary and
helpful with, "Waaaa, I had to write lisp in C++ because I couldn't
think of a better way," and expects people to care...needs to do a lot
more thinking on the matter. The poster didn't bother to respond to a
single point I made and apparently can't see past the horizon of their
own inability.

Last thing I want is for C++ to be designed to cater to people who do
nothing but wine. Use some other language, PLEASE.

 

[Noah Roberts]

Yes, to use C++, one needs to know the language in
the extend it is used in the field, but can not
just select some »easy« parts of it. That was what
I wrote.


In fact, when a TV is broken, often, I believe,
the repairman will not try to understand what
actually is wrong, but either suggest to buy a
new one or swap each of a few modules until it
works again. But this discussion about TVs
distracts from C++.

Quite frankly, the fact that people have to maintain existing C++
programs doesn't work that well for those claiming we should keep these
new features out of C++. The proposed features, and the ones people are
complaining about, are proposed because they simplify things. The kinds
of preprocessor garbage necessary to fake the existence of variadic
templates for instance is just horrid, horrid stuff. In my place of
work I am *the only one* that understands it. The addition of variadic
templates will require some learning and some new terminology but vastly
simplifies the problem so that people WILL be able to maintain such code.

The same applies to the other features people are complaining about
here. As I posted quite a while ago (with the only reply being some
crap about needing to write lisp) the new language and library solves
many of the issues that C++ developers face that make their lives
tougher than need be and their code less maintainable.

So really, you guys should get off this particular soapbox...it stands
against you.

 

[Noah Roberts]

The point is, that with the new standard the added/changed stuff makes
the language *use* *less complex*. Compilers possibly will sweat a
little more, but on the end user end you *lose* many awkward tricks or
ambiguity to be replaced with way clearer and easier things.

A few examples:

- threads: memory model, library. Single threaded environment not
effected. MT had to deal with issues "in the wild", now you have
strict guarantees and portable lib in the box.

- auto: finally kill the redundancy and verbosity just to tell the
compliler it already should know

- concepts: as template user you get clear error message on bad use,
and clear documenttion of the intent;
as template writer you can tell the intent in code instead of leaving
to vague comments. as bonus you finally can create defaults,
alternatives, those writing templates have a huge list of pain -- now
mostly gone

- rvalue refs: as library user you can benefit from move semantics
without doing anything. as tweaker remove worries about extra copies.
+bonus, can collect extra types

- bind: nuff said

- more smart pointers, collections: no more hunt for external libs for
stuff you likely want

Yup. In reality this fear of the new features is nothing BUT fear. As
is true of most fear, it's based on ignorance. People just scared of
change without really understanding why the change is being made to
begin with.

People need to go study what's being proposed and why instead of just
looking at a few blogs and running away in terror.

 

[Matthias Buelow]

People need to go study what's being proposed and why instead of just
looking at a few blogs and running away in terror.

It's called 'experience'. 25 years of optimising the shovel and you want
us to believe that, all of a sudden, the ladder has been produced?

 

[Zachary Turner]

Yup.  In reality this fear of the new features is nothing BUT fear.  As
is true of most fear, it's based on ignorance.  People just scared of
change without really understanding why the change is being made to
begin with.

People need to go study what's being proposed and why instead of just
looking at a few blogs and running away in terror.

It's also based on experience. It's quite possible that at your
current and past jobs, all the other programmers you've worked with
and whose code you've had to maintain were just like you. If so your
opinion is understandably biased and you haven't seen the other side
of the fence that alot of us have seen. Trust me, I've looked at
what's being proposed and my post is most certainly not based on
ignorance, lol. If all disagreements to your opinion you simply chalk
up to ignorance, then you need to take a step back and reflect a
bit.

Alot of the things in the new standard are flat out good, as others
have pointed out. Threads, initializer lists, type inference, all
examples of things that are just good any way you look at it. Oh, and
unicode is probably the biggest win of all.

Concepts I'm on the fence about. Obviously I understand what they're
for, why they're being introduced, and in general why they're
awesome. I think however, that like most other things, the library
writers will get them right and most other people will get them wrong,
making them more of a PITA than anything else. Honestly a lot of
people can't even figure out how to correctly use (runtime) asserts, I
have no reason to think this will be any different.

Constructors being allowed to call other constructors. Cool, not
earth-shattering, but I guess this is handy.

Typed enums. Another pure win, these are long overdue.

changes to 'explicit' keyword. Most people I know dont even
understand what the purpose of explicit in its current form. This is
a change almost exclusively for library writers.

Unions. They should have just deleted unions from C++, not enhanced
them.

I'm not crazy about variadic templates, I get the use case, and it's a
template lovers dream, but the normal programmer actually isn't a
template programmer believe it or not. Overall I think these will end
up being used almost exclusively by library writers, with occasional
exception.

Type traits are for library writers, in fact metaprogramming in
general is for library writers, and even that's arguable (in theory I
guess a lot of the changes in C++0x will reduce the need for
metaprogramming). Metaprogramming is awesome, don't get me wrong, but
only if I'm the person doing it. There is no way I want to look at
someone else's metaprogramming code.

Rvalue references. Mostly for library writers, and micro-
optimizations for the normal programmer, assuming of course they
understand them.

All in all, alot of C++0x is win, as I said in the original post. But
the stuff that is for library writers, leave it at that. As crazy as
it sounds, what I would really have liked is if the language forked
into a normal version and an "extended" version, such that code
written in the extended C++ could almost always be organized such that
the "extended" features were limited only to CPP files. This way
normal C++ could make use of libraries written in extended C++. I
like the features, what I DON'T like is the fact that I'm going to
have to work with other people who are going to try and use them. I
know it's shocking, but your average C++ programmer *really* cannot
even figure out how to use templates effectively. And if most of my
time is going to be spent toiling over terribly written code, it's
much more pleasant to just find a different language.

 

[Michael Mol]

It's also based on experience.  It's quite possible that at your
current and past jobs, all the other programmers you've worked with
and whose code you've had to maintain were just like you.  If so your
opinion is understandably biased and you haven't seen the other side
of the fence that alot of us have seen.  Trust me, I've looked at
what's being proposed and my post is most certainly not based on
ignorance, lol.  If all disagreements to your opinion you simply chalk
up to ignorance, then you need to take a step back and reflect a
bit.

Alot of the things in the new standard are flat out good, as others
have pointed out.  Threads, initializer lists, type inference, all
examples of things that are just good any way you look at it.  Oh, and
unicode is probably the biggest win of all.

I think however, that like most other things, the library
writers will get them right and most other people will get them wrong,
making them more of a PITA than anything else.  Honestly a lot of
people can't even figure out how to correctly use (runtime) asserts, I
have no reason to think this will be any different.

I don't see your point. There are plenty of terrible programmers out
there. There are *no* perfect programmers out there. How does a
feature not being intuitive first-year programmers support not having
it in the language to begin with? Where I work, when I don't
understand a bit of code, or can't resolve a bug, I call a coworker
over and have him take a look. The next time (or perhaps the time
after that, if it's tricky), I'll know what's what. That's how I went
from being a first-year programmer to something perhaps a bit better.

This is a change almost exclusively for library writers.
....

Overall I think these will end up being used almost exclusively by
library writers, with occasional exception.

Type traits are for library writers, in fact metaprogramming in
general is for library writers, and even that's arguable (in theory I
guess a lot of the changes in C++0x will reduce the need for
metaprogramming).
....

Rvalue references.  Mostly for library writers.
....

All in all, alot of C++0x is win, as I said in the original post.  But
the stuff that is for library writers, leave it at that.

Your complaints make it sound like you don't care for library writers,
and don't think features helpful for writing libraries should be in
the language. You realize that if it weren't for the library writers,
we wouldn't even have the STL. Heck, without library writers, any non-
trivial program you've seen would likely qualify for TDWTF. Heck,
without library writers, the definition of "non-trivial" would slide
back to what it was before I was born...

 As crazy as
it sounds, what I would really have liked is if the language forked
into a normal version and an "extended" version, such that code
written in the extended C++ could almost always be organized such that
the "extended" features were limited only to CPP files.  This way
normal C++ could make use of libraries written in extended C++.

That completely breaks templates, as your template function bodies
typically reside exclusively in header files which the preprocessor
dumps into your cpp file before subsequent compilation stages.

 I
like the features, what I DON'T like is the fact that I'm going to
have to work with other people who are going to try and use them.  I
know it's shocking, but your average C++ programmer *really* cannot
even figure out how to use templates effectively.  And if most of my
time is going to be spent toiling over terribly written code, it's
much more pleasant to just find a different language.

You haven't been asking for a fork. A fork implies that two instances
of a project can grow in different, incompatible ways. What it
*sounds* like you're asking for is pegging the C++ standard at a
version with features your coworkers already understand. If you're
worried about having to rework shoddy source code, then I suggest that
finding a different language won't help; You either need to put
yourself in a work environment where that doesn't happen frequently*,
or you need to get out of the software field entirely. There will
always be programmers who write shoddy code in every language with
more than one user, and as long as you look at code someone else
wrote, you risk interacting with their code.

This is a problem universal to the software industry, not one specific
to C++.


* Judging by their signatures, I'm certain that many folks in c.l.c++
have done this by working for themselves...

 

[jacob navia]

Some people here argue that C++ is not overly complicated.

I am reading "C++ Templates, the complete Guide". There,
the authors say (page 15)

"The rules for this decision may become rather
complicated even without templates. In this section we
discuss overloading when templates are involved. If
you are not familiar with the basic rules of overloading
without templates please look at Appendix B, where we
provide a reasonable detailed survey of the overload
resolution rules".

Great. That Appendix is 12 pages long! And it is not
complete of course!

Every C++ programmer *must* know those rules but maybe
1% of them know the WHOLE set of rules because the human
mind is not adapted to absorbing tons of programming trivia.

THEN, it is obviously the task of the maintenance programmer
to debug all those cases where the byzantine rules go
completely in other direction that the poor programmer
intended, when some new code using indirectly those
overloaded functions is written, 2 years AFTER the original
programmer left.

The great majority of C++ programmers doesn't know *exactly*
what are they doing when do a simple thing like overloading
a function...

Is this really necessary?

Now, look at this "concept" concept again. (Sorry but I find
no other way of saying it)

Behind it is the need to declare a set of types so that
template arguments can be checked by the compiler. OK.

But wasn't *inheritance* supposed to define this stuff?

If you make a standard "super-class" that describes a
concept, wouldn't it be necessary just that your class
INHERITS from that super class to be cleanly checked
in the template argument list? Why is it necessary to
introduce YET ANOTHER huge construct?