Anyone else feel like C++ is getting too complicated?
Zachary Turner
just getting way too complicated to be as practical as I feel it
should (and could) be. Before you start, I've been doing C++
professionally for probably 12 years, it's easily my strongest
language, and I consider myself a "C++ programmer", not a programmer
of some other language. I'm pretty comfortable with probably 90% of
what's in C++98, and have played around quite a bit (and actually
rather enjoy) things such as template metaprogramming and other more
advanced applications of C++.
But looking at what's coming in C++0x, I'm starting to feel like it's
just going too far. It actually started with Boost. I mean I greatly
value the genericity and flexibility of the utilities that boost
provides, but honestly, every time I need a new class that Boost
provides, it takes me an hour just to figure out what the heck the
documentation is talking about. Even for things which SHOULD be
simple. The other day I needed a pool, I figured "hey I bet boost has
a pool". Sure enough it did, and after an hour I realized it was a
waste of time and I could have written the class I needed in about 5
minutes, so I did. As another example, look at the date time library
in boost. It's insane and it takes forever even to figure out how to
use it in the most basic ways. MPI is even more ridiculous, if you
can even come close to understanding how MPI and Lambda work, you
deserve a PhD in something, for real.
I'm getting off a little off topic talking about boost, but the
principle is carrying over into C++0x, albeit with basic syntax
issues. There are a few saving graces to C++0x, most notably I think
the type inference features being introduced are long overdue and
frankly pretty amazing. But rvalue references? I've tried explaining
these to FIVE different C++ programmers, and nobody has any idea what
I'm talking about. It's like I'm trying to teach them Haskell or
Hungarian, or something. But it sure doesn't sound to them like I'm
talking about C++. Concepts are almost as bad. I mean the intention
is in the right place, but that was the case with templates as well,
and I've actually quit TWO jobs over the fact that I had inherited
someone else's template code, and it was fundamentally ruined because
the person didn't understand how to correctly design large-scale
template libraries. In one case, after I quit I was told by a former
colleague that the company wrote into their coding standard that
templates were strictly forbidden from all future use, with the
exception that standard library templates could be used. Just that no
future template classes could be created.
My heart is and always has been with C++, but honestly if these trends
continue I might find myself honing my expertise in other languages in
the (near) future. C++ is still an amazing language if you're on a
team full of other people who have written a standards conformant C++
compiler, but in the real world where most of your colleagues are
average (by definition of the word average), it's becoming more
painful than it is enjoyable.
Agree? Disagree? Flame?
Alf P. Steinbach
At meeting of Oslo C++ User Group I asked how many knew of MPL. 1 out of approx
12 did. I think, in fact pretty sure, that those 12 were among the most
enthusiastic C++ programmers in Norway.
So I think you're right that there's a gap between the direction the language &
library is taking, and ordinary use of the language.
If you care to look at old threads (not so very old) in [comp.std.c++] you'll
find the one where Andrei argued for reasonable defaults for the new random
number generators, so that you'd not need a PhD to use them. It seemed to me
that his arguments were not understood.
One of the most useful things in Boost, boost::intrusive_ptr, is not in C++0x.
That's a shame.
And I think the reason is that it's simple and useful. It's not academic enough.
If it was just a lot more complicated and subtle and less practically useful,
so that it could be discussed for ages with no clear conclusion, always with
some new subtlety pointed out by someone, then I think it would be in C++0x.
Modules, ditto. They would be simple and practically useful. But unfortunately,
no modules, at least not this time.
That's what I'm missing the most in C++. It's kind of ridiculous having a
language designed for "programming in the large", without module support. So we
swing it by manually creating header files, manually adhering to various
conventions, manually tweaking things by employing compiler-specific
pre-compiled headers, all that stuff that should have been standardized and
automated and checkable by the compiler, or at least the build system.
Also missing among practical features, a standard way to disable some common
silly-warnings, I think that could help a lot for the practical use of the
language. In particular the silly-warnings about implicit conversion to bool,
warnings about unused argument or local variable (the latter isn't really so
much an issue because a conforming compiler should detect non-trivial
constructor and not warn in that case), and warnings about constant condition
expression in 'if' or other selection. As it is, without a standard way to avoid
diagnostics all kinds of compiler-specific means are brought to bear.
However, there are some good things.
Type deduction, as you write, is basically just good, although the way it's
designed lets you very easily access otherwise practically inaccessible types.
With 'auto' in the picture, no longer does it suffice to declare a type private
or protected. Anyone can 'auto' to declare a holder for the result of a
function, so e.g. that useful C++98 proxy you've designed can easily outlive the
expression where it was meant to exist, with its referent no longer valid...
Argument forwarding is decidedly good, I think.
With argument forwarding we can finally, /I believe/, haven't tried this with
C++0x compiler, create reasonable smart pointers that take care of creation, not
just destruction. And that opens a large new frontier. Really usable things.
It's very awkward to do this with macros, and there's a syntax issue, for
default construction. I started exploring that but didn't go very far (for
various non-technical reasons).
Function attributes, good. But I'm missing the one really useful attribute, the
one that says this function will never throw. An empty throw specification
"throw()" doesn't do quite the same, because it obliges the standard-conforming
compiler to add a catch clause in order to invoke std::unexpected; an attribute
would on the other hand enable the compiler to avoid adding that catch clause.
In particular this would enable the style I prefer, a 'bool throwX(char
const*)', without using compiler-specific means to suppress warnings.
Cheers,
- Alf
PS: I think this thread ideally would belong in [comp.std.c++], but few read
that group.
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
Michael DOUBEZ
> I know I'm going to get flamed here, but I really feel like C++ is
> just getting way too complicated to be as practical as I feel it
> should (and could) be. Before you start, I've been doing C++
> professionally for probably 12 years, it's easily my strongest
> language, and I consider myself a "C++ programmer", not a programmer
> of some other language. I'm pretty comfortable with probably 90% of
> what's in C++98, and have played around quite a bit (and actually
> rather enjoy) things such as template metaprogramming and other more
> advanced applications of C++.
>
> But looking at what's coming in C++0x, I'm starting to feel like it's
> just going too far. It actually started with Boost. I mean I greatly
> value the genericity and flexibility of the utilities that boost
> provides, but honestly, every time I need a new class that Boost
> provides, it takes me an hour just to figure out what the heck the
> documentation is talking about. Even for things which SHOULD be
> simple. The other day I needed a pool, I figured "hey I bet boost has
> a pool". Sure enough it did, and after an hour I realized it was a
> waste of time and I could have written the class I needed in about 5
> minutes, so I did. As another example, look at the date time library
> in boost. It's insane and it takes forever even to figure out how to
> use it in the most basic ways. MPI is even more ridiculous, if you
> can even come close to understanding how MPI and Lambda work, you
> deserve a PhD in something, for real.
MPI and Lambda are not so bad if you are familiar with the problem they
solve.
Have you had a look at GIL ? It is terrible. I succeeded in using it and
was very happy with the result but I had to double my ration of caffeine
to keep up with the concepts, how they interact and how they were
implemented.
I agree in the sense that IMHO C++ is becoming more and more expert
friendly but I think it reflects the organization in the C++ community:
some write libraries with very elaborate stuff and MPL, others write
applications and use those libraries with the expressiveness they provide.
The problem is now a problem of communication between these two groups.
Typically Boost has a formal way of documenting (with Concepts ...)
which IMHO is useful for other library builders but not so much for
users who are looking for a solution and not necessarily the
architecture or the underlying idea of a tool.
From what I have seen in the software factory (in France), very few
people use templates and, if so, in a very limited manner. The questions
regarding C++ I saw in interviews (Looking for a job - hint, hint) were
all related to OOP and expert questions were related to patterns of the
GoF book (I even saw evaluation test still using the old headers).
All of that to say, yes modern C++ is very powerful and very difficult
to harness but the next standard provides many tools to overcome the
limitations of the language which helps in closing the gap between
library builder and user. Ideally, the users won't have to debug tons of
output for a deeply nested error but will have a clean static_assert
error and they won't have to understand the limitation of the language
that skewed the design or the possibilities of a lib.
--
Michael
Juha Nieminen
> But rvalue references? I've tried explaining
> these to FIVE different C++ programmers, and nobody has any idea what
> I'm talking about. It's like I'm trying to teach them Haskell or
> Hungarian, or something. But it sure doesn't sound to them like I'm
> talking about C++. Concepts are almost as bad.
You don't have to know anything about rvalue references or concepts in
order to benefit from them.
Concepts help the compiler give you more understandable error
messages. Is that a bad thing? Rvalue references help making your code
more efficient. Is that a bad thing?
If it's not a bad thing, then who cares if the internal details are
complicated to understand? I don't understand how exceptions work
internally, but that doesn't stop me from benefiting from them. So why
should I care if the details are complicated?
If you don't like rvalue references because they are too complicated,
then the solution is rather simple: Don't use them. You can keep
programming exactly as you have done to this day. You don't need to
understand them. It's not like you would be forced to understand rvalue
references in order to program in C++0x. I honestly can't see the problem.
Noah Roberts
> Zachary Turner wrote:
>> But rvalue references? I've tried explaining
>> these to FIVE different C++ programmers, and nobody has any idea what
>> I'm talking about. It's like I'm trying to teach them Haskell or
>> Hungarian, or something. But it sure doesn't sound to them like I'm
>> talking about C++. Concepts are almost as bad.
>
> You don't have to know anything about rvalue references or concepts in
> order to benefit from them.
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.
> Concepts help the compiler give you more understandable error
> messages.
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.
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.
> If you don't like rvalue references because they are too complicated,
> then the solution is rather simple: Don't use them. You can keep
> programming exactly as you have done to this day. You don't need to
> understand them. It's not like you would be forced to understand rvalue
> references in order to program in C++0x. I honestly can't see the problem.
Exactly. The standard philosophy of C++ still stands: don't make anyone
pay for anything they don't need to use.
People complaining about these things should go talk to the people who
are behind why they are going in. Go sit down with Steven Wantanabe, as
I did, and have it explained to you why rvalue references are important.
Frankly, they're a mystery to me too but he was able to point out
several cases where all these "complex" language features will make
writing code easier.
I don't know what the complaint about boost::lambda is besides the fact
that it actually doesn't work that great. Unlike boost::bind, for
instance, it can't deal with smart pointers and the like. The new
lambda syntax going into the language is a might bit strange but I don't
have to use it.
Variadic templates fall into this category as well. The whole pack
thing is quite a change in perspective, but the template code that
results is a whole lot better than the preprocessor code required to
work around the language limitation that currently exists. Furthermore,
nobody has to use them.
I'll tell you what though, you're going to benefit from all of these
features in the form of very nice additions to the standard library.
The whole bind1st, bind2nd crap is GONE! Well, it's there, you can use
it, but there's much better in its place: bind(). Function pointers are
basically a thing of the past to be replaced by a function object that
can store and use any function that is callable with the arguments
supplied...no more undefined behavior because your void function pointer
points at a function returning an int.
The threading stuff is also a major improvement and relies upon at least
one of the features being complained about here: rvalue references.
Because threads are "movable" they can be stored in a container that can
hold movable objects. As I said, the new standard containers will.
So your really trying to toss out the baby with the bathwater. Ok, the
bathwater is gross and ugly to some people...but the baby will be loved
by most. If you don't want the bathwater, don't drink it.
Kai-Uwe Bux
> Zachary Turner wrote:
>> But rvalue references? I've tried explaining
>> these to FIVE different C++ programmers, and nobody has any idea what
>> I'm talking about. It's like I'm trying to teach them Haskell or
>> Hungarian, or something. But it sure doesn't sound to them like I'm
>> talking about C++. Concepts are almost as bad.
[snip]
> If you don't like rvalue references because they are too complicated,
> then the solution is rather simple: Don't use them. You can keep
> programming exactly as you have done to this day. You don't need to
> understand them. It's not like you would be forced to understand rvalue
> references in order to program in C++0x. I honestly can't see the problem.
That is _not_ the solution unless you program in solitude. As soon as you
are a maintenance programmer or have to deal with code of others, you have
to be fluent in the C++ _they_ use. That can include all the new features.
Related: code should not be regarded solely as a means of instructing a
computer. It is also a means of communicating with other programmers. In
that regard a language can fail by being overly complex. At some point, a
language can get so large that the investment it takes to familiarize
yourself with all features becomes too large to make (after all, there are
other things competing for my attention). But a language needs to be shared
in order to serve as a means of communication.
Best
Kai-Uwe Bux
Zachary Turner
The problem is, who's going to want to program in a language if they
know that only, say, 50% of the language is going to be accessible to
them at their IQ level? Why would the person not just pick another
language in that case, a language where they personally would feel
more productive since they know they're getting everything out of the
language that it has to offer?
It's like trying to get your grandmother to use Linux. It's more
powerful and she can do more stuff with it, but if the only thing she
can *figure out* how to do is click the Firefox icon, while in Windows
she can also figure out how to change her password and her desktop
wallpaper, then she's not going to use it.
The problem is that C++ markets itself as a mainstream language, a
language for the masses so to speak (where the masses is anyone who
wants to write code that is close to the OS level), yet ALOT of the
constructs it provides are almost solely of academic interest.
So then what happens? You get your C++ programmer who deep down would
love to to start a national C++ Bee (http://www.christiannewswire.com/
news/513588015.html) to see who can recite more of the C++ Standard
conducting all the job interviews (everyone knows there's 1 of these
guys at every company), and the guy who answers "no" when asked if he
understands r-value references doesn't get the job, because the next
guy answers "yes" and answers something that remotely resembles a
correct answer, and then when he gets the job he ruins the entire
product because he started sprinkling all these cool features all over
the code for no other reason than that they're advanced and cool, and
he thinks that using them everywhere will make people respect him more
because he's obviously smart. Another product destroyed....
Honestly, if 90% of the users of a language aren't going to understand
how to use something effectively, or for that matter AT ALL, it
shouldn't be in the language.
Zachary Turner
Just to add one more thing, I'm not saying that these things like
concepts and r-value references aren't useful. I just don't think
they should be *in the language*. Designining the standard libraries
with them would be great since it would allow people to benefit from
them without introducing the inevitability that they will cause more
harm than good over the long run. I would argue that maybe even
templates have done more harm than good, I honestly have never
maintained a single usable code base where the original author used
templates. It's always a complete nightmare, even though I personally
understand templates perfectly.
Obviously the idea of implementing the libraries in a superset of the
language raises its own set of issues, but I don't think it's a
totally unsolvable problem. Maybe that's not even the best solution,
but I'm pretty sure that the current direction things are heading is
one of the *worst possible* solutions from a practical standpoint.
Noah Roberts
> It's like trying to get your grandmother to use Linux.
My grandmother uses Linux.
Matthias Buelow
> Exactly. The standard philosophy of C++ still stands: don't make anyone
> pay for anything they don't need to use.
The "standard philosophy" rather seems to be: trade programmer time for
execution time. C++ has become so spectacularly unproductive for me, I
even have written ad-hoc interpreters to implement parts of an app in a
less bureaucratic language (a small dialect of Lisp, in that case) for
the simple reason that juggling with C++ only is so utterly unwieldy and
frustrating.
Noah Roberts
Whatever. Then stop using it.
Jeff Schwab
I humbly suggest that the language isn't the problem.
Juha Nieminen
> The "standard philosophy" rather seems to be: trade programmer time for
> execution time. C++ has become so spectacularly unproductive for me, I
> even have written ad-hoc interpreters to implement parts of an app in a
> less bureaucratic language (a small dialect of Lisp, in that case) for
> the simple reason that juggling with C++ only is so utterly unwieldy and
> frustrating.
That kind of whining makes no sense.
There's no such a thing as the perfect programming language which is
optimal for all possible tasks. That's a physical impossibility.
Many fanatics of some languages will boast how superb their pet
language is and how it can be used for basically anything, but usually
when you start studying the language in question, you always find
shortcomings and things which it's not very suited for.
Bashing a language for the reason that it's not the optimal language
for all possible tasks is just stupid.
Juha Nieminen
> That is _not_ the solution unless you program in solitude. As soon as you
> are a maintenance programmer or have to deal with code of others, you have
> to be fluent in the C++ _they_ use. That can include all the new features.
>
> Related: code should not be regarded solely as a means of instructing a
> computer. It is also a means of communicating with other programmers. In
> that regard a language can fail by being overly complex. At some point, a
> language can get so large that the investment it takes to familiarize
> yourself with all features becomes too large to make (after all, there are
> other things competing for my attention). But a language needs to be shared
> in order to serve as a means of communication.
Many people benefit greatly from the new features. Some people might
require extra studying to understand these features.
Your argument basically says that it's better to deny the former
people the useful tools for the sake of the latter people.
I can't say I agree with that.
Juha Nieminen
> The problem is, who's going to want to program in a language if they
> know that only, say, 50% of the language is going to be accessible to
> them at their IQ level? Why would the person not just pick another
> language in that case, a language where they personally would feel
> more productive since they know they're getting everything out of the
> language that it has to offer?
Are you seriously suggesting that C++ should be dumbed down so that
people with lower IQ can use it?
I'm not even sure how I should understand that.
Matthias Buelow
> There's no such a thing as the perfect programming language which is
> optimal for all possible tasks. That's a physical impossibility.
Agreed...
> Many fanatics of some languages will boast how superb their pet
> language is and how it can be used for basically anything, but usually
> when you start studying the language in question, you always find
> shortcomings and things which it's not very suited for.
> Bashing a language for the reason that it's not the optimal language
> for all possible tasks is just stupid.
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. IMHO, C (or the early, much simpler C++) isn't a vehicle
suitable for building a complex multi-paradigmatic language upon, like
C++ is trying to be. It's all hacks and horrible ad-hoc voodoo. C is,
despite quite a few sores and tumours, a relatively elegant language for
what it was designed to be. The early C++ was a working add-on hack,
neither particularly elegant, rather quirky but practical enough that
people picked it up. Modern C++, however, is an abomination and has lost
the point a long time ago.
Michael Mol
> The problem is, who's going to want to program in a language if they
> know that only, say, 50% of the language is going to be accessible to
> them at their IQ level? Why would the person not just pick another
> language in that case, a language where they personally would feel
> more productive since they know they're getting everything out of the
> language that it has to offer?
There's a major difference between IQ and ability to learn a language--
and that difference is motivation. The type of person you're warning
about is the type of person who's not actually motivated to learn to
use the tools available to them effectively.
As far as choice goes, if they actually *have* a choice in the
language they're going to use, then they should make a choice based on
their project's requirements. There have to be at least 50 mature
general-purpose languages out there, and hundreds more which are
targeted to specific problem domains.
> The problem is that C++ markets itself as a mainstream language, a
> language for the masses so to speak (where the masses is anyone who
> wants to write code that is close to the OS level), yet ALOT of the
> constructs it provides are almost solely of academic interest.
As quantifiers go, "a lot" is a pretty poor punt. As I've used C++,
I've discovered that a lot of things that I thought of as academic
turned out to have very practical uses. But then, that's the way it
normally goes, isn't it? Something has to be studied before it
becomes practical.
[ snip straw man anecdote ]
>
> Honestly, if 90% of the users of a language aren't going to understand
> how to use something effectively, or for that matter AT ALL, it
> shouldn't be in the language.
90% of all users aren't competent enough to truly understand the
language they're using, be it Haskell, PHP, C++, C, ANSI BASIC or a
four-function calculator with an M+ button. And, again, it comes down
to an issue of motivation and how much you care about effectively
writing good code.
(Google: "90% of everything is crap")
Juha Nieminen
> Modern C++, however, is an abomination and has lost
> the point a long time ago.
Yet people use it to write elegant, efficient and easily maintainable
code.
Why do some people have the obsession that
tons of features = you must understand all of them to use the language
?
Noah Roberts
It's an abomination I tells you!!! It's too complicated!!! Really, it
is!!!
Don't expect me to expand on that, it's all I gots.
Kai-Uwe Bux
a) That you do not like the conclusion of an argument does not make it
invalid :-)
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.)
Best
Kai-Uwe Bux
Zachary Turner
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. 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 currently, it's not anywhere close to that. It's no
longer the best at anything really, 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). But what exactly *is* the
compelling use case for C++ anymore? For all its complexity, it
should at the very least offer a clear advantage in *something*, and I
honestly don't think it does anymore, and furthermore that it's
accelerating away from such a goal. The only possible advantage it
might offer anymore is that its standard libraries are reasonably
mature, but any language can achieve the same thing given enough time,
and this still of course assumes that you can figure out how to use
the standard libraries.
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. 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, when you can achieve exactly
the same things in other languages much simpler), 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.
Zachary Turner
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.
pa...@lib.hu
> 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
pa...@lib.hu
> 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.
pa...@lib.hu
> > 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,
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%2B%2B0x
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
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.
--
Ian Collins
Juha Nieminen
> Ian Collins <ian-...@hotmail.com> writes:
>> 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.
>
> 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?
Juha Nieminen
> Juha Nieminen <nos...@thanks.invalid> writes:
>> A professional C++ programmer who has to modify existing programs and
>> doesn't know the language well enough to do so?
>
> 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
> On Mar 19, 11:28 pm, Zachary Turner <divisorthe...@gmail.com> wrote:
>>> 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,
>
> 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
> Juha Nieminen <nos...@thanks.invalid> writes:
>> doesn't know the language well enough to do so?
>
> the extend it is used in the field, but can not
> just select some »easy« parts of it. That was what
> I wrote.
>
>> internally too complicated and thus no TV repairman should be
>> expected to be able to do their job?
>
> 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
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
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.
>
> 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
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?
Balog Pal
> Some people here argue that C++ is not overly complicated.
Care to give some reference to any of those people?
> 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. ...
> 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.
Yeah, name lookup rules are complicated.
Yeah, no human being can recite them.
Yeah, we don' like it.
However, in practice this is not as big an issue as looks, as it has natural
mitigation.
It is:
- use names as they make sense
- overloads must be semantically equal
- avoid using directives on a namespace unless you really mean to drag in
everything and know all of it
You do just that, and don't need to care how many candidates are there and
which one got called if the set has more than one.
And those guidelines are good to follow regardless of name lookup rules...
(The dark side is unfortunately introduced via Koenig lookup that can drag
in stuff you are not aware exists... But it is not a 'complexity of C++'
issue, but a design flaw.)
> 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.
Quite bad, that we have all kind of tools around, and they still fail to
address this very situation. I.e. MSVC shows you tooltips on mousing -- but
it is not based on compilation data even if it exists, and you're not told
what was picked up. Nor is is straightforward to see on a sensible listing.
The call graph of the function does not list the correct function (and btw
the internally involved invisible calls either), that would help so much.
> The great majority of C++ programmers doesn't know *exactly*
> what are they doing when do a simple thing like overloading
> a function...
Now that is really BAD -- but blame the programmer, not the language.
Overload is a programmer-made decision and shall be a good one.
> Is this really necessary?
What?
Overload is a powerful and needed feature. Without it you have a bigger
mess. And if your fellows misuse it, slap them.
I know way more cases where a programmer assigned the wrong value. Is it
grounds to get rid of assignment or claim it bad?
> 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?
Huh? Of course not. Care to explain how it comes into a picture?
Let's see a very simple concept, copyable. Used in many std:: collections
too.
That works fine for int, for char*, all POD types, etc... How you define it
via inheritance?
> 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?
Guess no, but show me on the above example...
just for reference the aim is to get:
std::vector<int> v1; //okay
std::vector<std::auto_ptr<int> > v2; // error: std::auto_ptr<int> fails is
not Copyable
Just as another thought: "concept" is meant for the template library
programmers. The people doing that correctly know how to use it and why it
is good. The rest of the public can ignore it entirely, just sit back and
enjoy the ride -- getting sensible checks and compile-time error flagging
when using the library. Making their life way less complicated than it is
now, when you get a 50-line message claiming it can't convert [20-line name]
to [similar 20-line name] just having std::map< std::string, std::string >
in a simple operation.
Juha Nieminen
> But wasn't *inheritance* supposed to define this stuff?
Object-oriented programming and inheritance hierarchies were all the
hype in the 80's and early 90's. While certainly not the silver bullet
of programming, it was nevertheless considered one of the greatest
advances in programming.
As years passed and the overall experience on OOP and especially
inheritance grew, it became more and more clear to the programming
community in general that OOP and especially inheritance is not, after
all, such a great tool. It's very useful, and it has great ideas in
theory, but... just somehow it's not everything that it promised to be.
While there are situations where inheritance is the perfect solution,
these situations are not as abundant as once thought. OOP and
inheritance is not the silver bullet of programming, not even close.
(IMO the modular part of OOP is still extremely useful, and an inherent
part of almost any well-designed program. It just can't do everything by
itself.)
In the last decade the paradigms have shifted more towards dynamic
programming. Dynamic code/object generation (at compile time or at
runtime), dynamic creation of first-class objects (including first-class
functions), runtime type information (which allows things like
reflection), etc. Template metaprogramming can be considered a subset of
this. Also there has been a clear shift towards a more functional
approach, inspired by lambda calculus.
peter koch
No. Inheritance indicates "is-a" relationships, while what is needed
is a "has-a" relationship.
>
> 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?
For several reasons, one being that inheritance does not solve the
problem. But even if it did, you would require an inheritance relation-
ship that would quickly be unmaintainable. Just imagine all those
properties you would have to define in order to even simple types: are
they default-constructible, assignable, copy-constructible, can you
compare them, do they have a "less-than" relationship a.s.o. Using
concepts, all old code would have to be thrown out if inheritance or
something like that were to be used instead.
/Peter
Balog Pal
"Zachary Turner" <diviso...@gmail.com>
>>
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.
<<
hm, we all know that dreaming up stuff is unlikely to lead anywhere. And
real systems like C++ are buiild from executeable proposals. The language
doesn't have a separation of interface and implementation, neither even the
concept of "CPP files". What you say just can not be done in the current
language -- only in a new one, dropping backwards compatibility. (Or if you
think otherwise, you should have written a proposal, or at least a seed for
one...)
Introducing "modules" failed to get in for this very reason -- while most
everyone agrees on the need no one (I aware of) could show a way to get it
actually. And it will not happen by magic in the future either.
The story you mentioned on 'export' is at least a good learning case, the
mtivation there was on your line, aiming separation. And even despite a good
description it failed on the practical side -- the compiler writers did not
implement it. Because it would have needed completely new ABI that did not
fit well with the existing linker concept, that allow together objects from
C and many other languages.
A new module thing would require even more separation and rigidity. Likely.
> This way normal C++ could make use of libraries written in extended C++.
The is done well by C#. Also you can use CORBA, COM, etc to have such
things, and practically with good compiler support in MSVC (just #import the
typelib) starting 10+ years ago. Yet it doesn't seem too popular or even
used. Cant't we use it as evidence that is not so much desired?
> 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.
Who wants or likes to work with idiots? But my experience shows that idiots
are not tied to any set of features. Instead they just break anything
around, and very inventive to abuse the least abuseive tools. While the
hard-to-get features are actually safer from them.
And where I can't ret rid of idiots, all tools that help to detect problems
are more than welcome. Like a 'concept' detecting misuse at compile time
instead of just having UB or misbehavior in the release build.
>I know it's shocking, but your average C++ programmer *really* cannot
even figure out how to use templates effectively.
You mean write templates? Well, so then he should not. Use templates? Like
vector? I don't think that accnts for a problem, or lesser one if we were
back to template-less state and polymorphic collections...
And peopleware problems shall be handled down in teams by having at least a
couple knowledgeable engineers, use them as reviewers and mentors. And
for programmers juse the Joel Spolsky method of selection, go for bright and
caring persons, nuke all the rest. And in a few years everyone will be able
to do proper work.
>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.
Interesting, I'm yet to hear about a language or a system where workers do
not face these kind of idiots-at-helm problems.
Java was (in one big part) motivated by what you say. After its decade+ and
6th version and popularity did it make things better? I don't see that.
In fact I see way bigger mess in java programs, and it looks increasing like
a rolling showball.
jacob navia
>
> For several reasons, one being that inheritance does not solve the
> problem. But even if it did, you would require an inheritance relation-
> ship that would quickly be unmaintainable. Just imagine all those
> properties you would have to define in order to even simple types: are
> they default-constructible,
yes
assignable,
yes
copy-constructible,
yes
can you compare them,
yes
do they have a "less-than" relationship
yes
a.s.o.
Well, primitive types (int, double,char,short,long,
double, float,long double,long long) are all numbers.
If you exclude strings and arrays, they have all the above
properties. Those properties do not have to be specified,
since they are intrinisc to the language!
Using concepts, all old code would have to be thrown out if inheritance or
> something like that were to be used instead.
>
Why?
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.
The only reason that this is not done is that OO is no longer
"in", i.e. the OO "FAD" has disappeared. We have new fads
now.
It will be left to the maintenance programmer to figure out
then, why the mixture of old+new fads doesn't work.
> /Peter
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
peter koch
Because e.g. int is a primitive type, that does not inherit from these
concepts. Therefore, I would not be able to use my new concept-based
container with integers. What is worse, I would not be able to rewrite
the standard library so that it could take advantage of concepts.
Remember: one advantage of concepts is that they should simplify
programming for the users of the libraries. Not having concepts in
std::vector probably would not be acceptable.
>
> 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.
>
> The only reason that this is not done is that OO is no longer
> "in", i.e. the OO "FAD" has disappeared. We have new fads
> now.
OO is not the silver bullit, and it never was considered so - at least
by the C++ community.
C++ always was a multi-paradigm language and will continue to be so.
>
> It will be left to the maintenance programmer to figure out
> then, why the mixture of old+new fads doesn't work.
Old code will continue to work - what are you getting at? And just as
important: you can use existing code in new concepts-based code,
something that would not be possible with your proposal to abuse
inheritance.
/Peter
jacob navia
>
> Old code will continue to work - what are you getting at?
In the shop I work we are tied to gcc 3.2 / MSVC 6.0.
Why?
Because those compilers allow to define a template without checking
until template expansion time if all symbols used in
the template are defined. Newer compilers do not.
The language changed.
The problem is that the header files contain thousands of definitions
and no human mind can untangle them now. Depending on the order
of header files inclusion, some things will be defined when the
templates are defined and others are not. All will be defined when the
template is used but that is not enough for language purists.
We have attempted several times to solve this but it needs at least
4-5 man-months to do that. And we do not have the resources,
we are a small shop...
And we are stuck then.
Yes, "Old code will continue to work" until somebody decides otherwise.
jacob navia
> jacob navia wrote:
>> But wasn't *inheritance* supposed to define this stuff?
>
> Object-oriented programming and inheritance hierarchies were all the
> hype in the 80's and early 90's. While certainly not the silver bullet
> of programming, it was nevertheless considered one of the greatest
> advances in programming.
>
That was the fad of those days.
Everything was object oriented, mind you.
> As years passed and the overall experience on OOP and especially
> inheritance grew, it became more and more clear to the programming
> community in general that OOP and especially inheritance is not, after
> all, such a great tool. It's very useful, and it has great ideas in
> theory, but... just somehow it's not everything that it promised to be.
This is the typical way of all fads.
> While there are situations where inheritance is the perfect solution,
> these situations are not as abundant as once thought. OOP and
> inheritance is not the silver bullet of programming, not even close.
> (IMO the modular part of OOP is still extremely useful, and an inherent
> part of almost any well-designed program. It just can't do everything by
> itself.)
>
> In the last decade the paradigms have shifted more towards dynamic
> programming.
New fad. This is like reading "Vogue"...
> Dynamic code/object generation (at compile time or at
> runtime), dynamic creation of first-class objects (including first-class
> functions), runtime type information (which allows things like
> reflection), etc.
Yes, that is considered sexy now.
Look, I am French, and even worst, I live in Paris. I know
something about fads really.
> Template metaprogramming can be considered a subset of
> this. Also there has been a clear shift towards a more functional
> approach, inspired by lambda calculus.
Yeah. Like the mini-skirt, that always returns, fads tend to run into
circles. Lambda calculus,invented in the thirties was THE fad
that led to LISP in the fifties.
We are there again, for the third time.
And Vogue tell us that the mini-skirt is IN again!
Actually, it never left us. Women like to show their legs!
So, we are served with mini-skirts 2009 style, not at all
the same like in 1969 but so deliciously similar!
And the fad goes on...
:-)
SG
>
> 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.
You can certainly do that. But in many cases you don't need the extra
level of indirection. If you don't need the extra level of
indirection you could use templates. If you want to use templates
then a nice "type system for types" would be nice. That's where
concepts come in.
Not requireing unneeded levels of indirection is in the spirit of C++
("You don't pay for what you don't use.")
Of course, sometimes you *want* this indirection (runtime
polymorphism). Generic programming doesn't invalidate object oriented
programming. These "styles" both have their use cases.
> The only reason that this is not done is that OO is no longer
> "in", i.e. the OO "FAD" has disappeared. We have new fads
> now.
>
> It will be left to the maintenance programmer to figure out
> then, why the mixture of old+new fads doesn't work.
They can work pretty well together. The buzzword here is "type
erasure". See boost::function, for example.
Cheers!
SG
Balog Pal
"jacob navia" <ja...@nospam.org>
>> Old code will continue to work - what are you getting at?
>
> In the shop I work we are tied to gcc 3.2 / MSVC 6.0.
msvc 6 is a pre-standard compiler.
> Why?
>
> Because those compilers allow to define a template without checking
> until template expansion time if all symbols used in
> the template are defined. Newer compilers do not.
Yeah, I wasn't too happy about that change at the time either, but
rearranged the code to have the declarations, it wasn't that much work (with
also adding a few typenames, etc...)
Moving ahead was kinda relief after all.
> The language changed.
Yeah, and that version was from the MS era of 'we shit on the standard',
they even managed to lose their voting rights in the committee by not
attending... The tide turned a few years later fruiting at ver 7.1.
> The problem is that the header files contain thousands of definitions
> and no human mind can untangle them now.
Still it is hard to imagine havig *that much* template code for a project.
After all they are to cover generic stuff and an application is limited on
that. While standalone libraries do not use direct function calls to
unknown functions directly from the text, do they?
> Depending on the order
> of header files inclusion, some things will be defined when the
> templates are defined and others are not. All will be defined when the
> template is used but that is not enough for language purists.
You only need declaration of the function. Or make it dependent (via this->
or similar additions...) Why not declare the functions used in the template
right there in the template header?
> We have attempted several times to solve this but it needs at least
> 4-5 man-months to do that.
It's so hard to believe to go even over 4-5 man-days. How many lines of
template code you have and how many errors flagged on compile?
> And we do not have the resources, we are a small shop...
Sure, that amount sounds gross. Still there may be even more implied costs
in being locked in -- especially into archaic stuff that will gett
increesingly abandoned around theese years (IMO).
> And we are stuck then.
>
> Yes, "Old code will continue to work" until somebody decides otherwise.
It referred to old standard-compliant code, yours is not such. It never
worked in a standard compiler and never will be. While C++98 code will
happily work in a C++0x compiler.
Ian Collins
> peter koch wrote:
>>
>> Old code will continue to work - what are you getting at?
>
> In the shop I work we are tied to gcc 3.2 / MSVC 6.0.
>
> Why?
>
> Because those compilers allow to define a template without checking
> until template expansion time if all symbols used in
> the template are defined. Newer compilers do not.
>
> The language changed.
The language became standardised. The upcoming standard should not
break code conforming to the current standard.
> The problem is that the header files contain thousands of definitions
> and no human mind can untangle them now. Depending on the order
> of header files inclusion, some things will be defined when the
> templates are defined and others are not. All will be defined when the
> template is used but that is not enough for language purists.
>
> We have attempted several times to solve this but it needs at least
> 4-5 man-months to do that. And we do not have the resources,
> we are a small shop...
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?
--
Ian Collins
peter koch
> peter koch wrote:
>
> > Old code will continue to work - what are you getting at?
>
> In the shop I work we are tied to gcc 3.2 / MSVC 6.0.
>
> Why?
>
> Because those compilers allow to define a template without checking
> until template expansion time if all symbols used in
> the template are defined. Newer compilers do not.
>
> The language changed.
No - this is not correct. There has been no change in that direction.
Your problem rather is that you used compilers that did not follow the
standard (MSVC did not because among other things it predates the
standard).
>
> The problem is that the header files contain thousands of definitions
> and no human mind can untangle them now. Depending on the order
> of header files inclusion, some things will be defined when the
> templates are defined and others are not. All will be defined when the
> template is used but that is not enough for language purists.
The actual problem is not a question about language purism. Rather it
is a problem of your code which is extremely fragile. For that reason
alone it would be worth trying to change the code.
>
> We have attempted several times to solve this but it needs at least
> 4-5 man-months to do that. And we do not have the resources,
> we are a small shop...
>
> And we are stuck then.
>
> code will continue to work" until somebody decides otherwise.
Exactly. Work is not the entirely correct word.
/Peter
Juha Nieminen
> This sounds strange too me. Template metaprogramming is
> exactly the opposite. It is static programming - template
> instantiation is happening at compile time. That's why the
> afficinados are fond of it: It does not consume runtime.
> »dynamic« means »at runtime«. Templates are static in
> comparison to OOP, which means run-time polymorphism
> (late binding while templates are early binding).
It could be argued that there are many levels of "dynamic".
Completely "static" programming can be considered a 1-to-1
relationship between written source code and produced machine code: What
you write is basically exactly what you get.
However, templates are a bit different. They do not produce any code
when the compiler first parses them. Moreover, there's no 1-to-1
relationship between source and compiled machine code, but a 1-to-many:
The same source can produce "dynamically" many different types of
compiled machine code, depending on how the template is instantiated.
In other words, the compiler dynamically adapts your template code to
the specified types (and scalars, in some cases).
> Object-oriented programming languages (Smalltalk
> and Lisp) always included functional sublanguages.
I thought Lisp has always been nothing but a functional language.
Object-oriented features were later devised by "abusing" its versatility.
SG
> However, templates are a bit different. They do not produce any code
> when the compiler first parses them. Moreover, there's no 1-to-1
> relationship between source and compiled machine code, but a 1-to-many:
> The same source can produce "dynamically" many different types of
> compiled machine code, depending on how the template is instantiated.
>
> In other words, the compiler dynamically adapts your template code to
> the specified types (and scalars, in some cases).
I don't think this use of "dynamically" is in alignment with how it is
generally understood:
dynamically = at runtime
statically = at compile-time
Cheers!
SG
Preston
> On Mar 19, 11:28 pm, Zachary Turner <divisorthe...@gmail.com> wrote:
>>> 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,
>
> 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.
Of course it is constructive criticism. It's a valid complaint.
Declaring that it's not doesn't make the complaint less accurate.
Preston
Absolutely nobody cares what you're sick of. Absolutely nobody cares
that your epeen growth hormone is based on your amount of esoteric C++
knowledge.
Preston
> Zachary Turner wrote:
>> 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.
Constructive criticism doesn't have to offer suggestions on how to
improve something. The suggestions for improvement are
implied--removing the reasons for the criticism.
Preston
> Matthias Buelow wrote:
>> Modern C++, however, is an abomination and has lost
>> the point a long time ago.
>
> Yet people use it to write elegant, efficient and easily maintainable
> code.
>
> Why do some people have the obsession that
>
> tons of features = you must understand all of them to use the language
>
> ?
It can be a problem if you have to maintain someone else's code, for starters.
Preston
> Zachary Turner wrote:
>> The problem is, who's going to want to program in a language if they
>> know that only, say, 50% of the language is going to be accessible to
>> them at their IQ level? Why would the person not just pick another
>> language in that case, a language where they personally would feel
>> more productive since they know they're getting everything out of the
>> language that it has to offer?
>
> Are you seriously suggesting that C++ should be dumbed down so that
> people with lower IQ can use it?
>
> I'm not even sure how I should understand that.
I don't think anyone has suggested it be "dumbed down" or even used
that phrase.
Balog Pal
>> 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.
>
> Of course it is constructive criticism. It's a valid complaint.
> Declaring that it's not doesn't make the complaint less accurate.
Care to look to meaning of 'constructive'?
I don't recall anyone denying C++ being complex or stating such complaint
is invalid.
(Though OP implied like C++ is getting complex in next release while common
opinion is that it got way complex well before that.)
Tony
"Ian Collins" <ian-...@hotmail.com> wrote in message
news:72l48kF...@mid.individual.net...
> jacob navia wrote:
>> peter koch wrote:
>>>
>>> Old code will continue to work - what are you getting at?
>>
>> In the shop I work we are tied to gcc 3.2 / MSVC 6.0.
>>
>> Why?
>>
>> Because those compilers allow to define a template without checking
>> until template expansion time if all symbols used in
>> the template are defined. Newer compilers do not.
>>
>> The language changed.
>
> The language became standardised. The upcoming standard should not break
> code conforming to the current standard.
The solution is to not use the std library.
Lionel B
So you implement your own containers, streams, algorithms, ... (easy-peasy)
debug them to a high standard of reliability (shouldn't take much work)
and you're fine (except that nobody else understands your code).
--
Lionel B
Noah Roberts
*plonk*
Matthias Buelow
> The same source can produce "dynamically" many different types of
> compiled machine code, depending on how the template is instantiated.
Then C is also "dynamic", given that:
int i = 0; i++;
can generate a potentially infinite number of different machine code
output, depending on compiler, architecture, and even compiler options.
> I thought Lisp has always been nothing but a functional language.
Mainstream dialects have always had assignment and destructive operations.
df
Wow, people still say "plonk?" Is this 1994?
bonch...@gmail.com
Trolls are often a one-way mouthpiece; they love to rant but hate to
listen. Please, continue whining about other people whining while
your programming language sinks further into obscurity.
Noah Roberts
join him
Michael Mol
>
> >>> p...@lib.hu wrote:
> >>>> On Mar 19, 11:28 pm, Zachary Turner <divisorthe...@gmail.com> wrote:
> >>>>>> 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,
>
> >>>> 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.
>
> >> Absolutely nobody cares what you're sick of. Absolutely nobody cares
> >> that your epeen growth hormone is based on your amount of esoteric C++
> >> knowledge.
>
> > *plonk*
>
> Wow, people still say "plonk?" Is this 1994?
Some people still have killfiles: http://en.wikipedia.org/wiki/Killfile
Juha Nieminen
> Juha Nieminen wrote:
>
>> The same source can produce "dynamically" many different types of
>> compiled machine code, depending on how the template is instantiated.
>
> Then C is also "dynamic", given that:
>
> int i = 0; i++;
>
> can generate a potentially infinite number of different machine code
> output, depending on compiler, architecture, and even compiler options.
Yes, master nitcpicker.
df
Yes, we know what killfiles are, thanks. I was mocking the usage of
the ancient term "plonk" from 1994-era Usenet.
Noah Roberts
> Yes, we know what killfiles are, thanks. I was mocking the usage of the
> ancient term "plonk" from 1994-era Usenet.
>
Gad! Troll central in these here parts.
Tony
"Lionel B" <m...@privacy.net> wrote in message
news:gqaj9p$122$2...@south.jnrs.ja.net...
"My code" huh? What do you know about "my code"? Hmm? Do tell. Well then
STFU!
Juha Nieminen
>>> The solution is to not use the std library.
>> So you implement your own containers, streams, algorithms, ...
>> (easy-peasy)
>> debug them to a high standard of reliability (shouldn't take much work)
>> and you're fine (except that nobody else understands your code).
>>
>
> "My code" huh? What do you know about "my code"? Hmm? Do tell. Well then
> STFU!
What does he know? You told him: "The solution is to not use the std
library".
If you are indeed not using the std library, I wouldn't really like to
maintain your code.
Noah Roberts
Had to work under a guy like this once; no std library, no stl, no
exceptions. Eventually he sort of gave up ever getting anything done
and quit. Best thing that ever happened to the team.
Paavo Helde
> On Mar 19, 1:45 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> Are you seriously suggesting that C++ should be dumbed down so that
>> people with lower IQ can use it?
>>
>> I'm not even sure how I should understand that.
>
> 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. But if they're going to claim that it's a language
I believe academia would like something better tractable theoretically,
like Lisp or Pascal. From C++ I think only the template sublanguage would
qualify as a research object.
> for use in solving mainstream, practical problems, then that's what it
That's precisely what C++ is strong in. In practice, you will encounter
endless unanticipated problems, and the maximum flexibility of C++ actually
helps to overcome them.
Paavo
Ian Collins
> Zachary Turner <diviso...@gmail.com> kirjutas:
>
>> for use in solving mainstream, practical problems, then that's what it
>
> That's precisely what C++ is strong in. In practice, you will encounter
> endless unanticipated problems, and the maximum flexibility of C++ actually
> helps to overcome them.
In many different ways!
--
Ian Collins
Tony
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
news:1W_yl.57$A17...@read4.inet.fi...
> Tony wrote:
>>>> The solution is to not use the std library.
>>> So you implement your own containers, streams, algorithms, ...
>>> (easy-peasy)
>>> debug them to a high standard of reliability (shouldn't take much work)
>>> and you're fine (except that nobody else understands your code).
>>>
>>
>> "My code" huh? What do you know about "my code"? Hmm? Do tell. Well then
>> STFU!
>
> What does he know? You told him: "The solution is to not use the std
> library".
(Aside: I don't mean it when I say "STFU" (it means I was out partying and
am all cocky). I'm in reality, quite mild-mannered).
"Not using the std library" is only a solution if on is able to create or
procure an alternative.
> If you are indeed not using the std library, I wouldn't really like to
> maintain your code.
I feel the same way about code that uses the std library. So it goes both
ways. "Progress" (a subject term perhaps, so in quotes) in library design
has been hindered by the std library. Don't "get my drift" wrong: I think
C++ is the best thing out there. I just think it is quite far from the
ideal.
Tony
Tony
"Noah Roberts" <no...@nowhere.com> wrote in message
news:49cd076b$0$29744$cc2e...@news.uslec.net...
Sounds like you were an experiment wondering if you could rise to the
challenge.
Tony
Matthias Buelow
>That's precisely what C++ is strong in. In practice, you will encounter
>endless unanticipated problems, and the maximum flexibility of C++ actually
>helps to overcome them.
As flexible as a brick that lands on your head, yes.
Tony
"Zachary Turner" <diviso...@gmail.com> wrote in message
news:ffcaf34e-d42a-484e...@t3g2000yqa.googlegroups.com...
C++ is great. C++ is good. Let us thank it for our food.
Jerry Coffin
says...
[ ... ]
> 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.
Now we run into rather a problem though: contrary to your earlier
statement, floating point numbers really canNOT be sorted. In
particular, sorting (at least as normally implemented) requires that if
!(a<b) && !(b<a) then (b==a). A floating point NaN violates that
requirement -- a NaN doesn't compare equal to another NaN, and generally
doesn't even compare equal to itself!
Since we want to allow assignment from integer to floating point, but
not the reverse, floating point should be an ancestor of integer. We've
already seen, however, that string needs to descend from something that
is NOT an ancestor of floating point -- ergo, floating point ends up as
a base of both string and integer. This allows something we really DON'T
want though -- an implicit conversion from any string to floating point.
The alternative is for string and integer to be only distantly related
(sensible) and do the sorting on some abstract type near the root of the
tree that's an ancestor of integer, floating point AND string, and then
check at run time to ensure against attempting to sort things like
floating point numbers that can't be sorted.
> The only reason that this is not done is that OO is no longer
> "in", i.e. the OO "FAD" has disappeared. We have new fads
> now.
Quite the contrary. 30+ years of experience with using inheritance has
shown that while it models some relationships quite well, there are many
other relationships it models quite poorly.
Inheritance requires us to specify similarity in an all or nothing
fashion. Specifically, a derived object shares ALL the characteristics
of its base. If there is too much difference to allow that, then we
can't use inheritance, which prevents us from taking advantage of ANY
similarity.
Concepts allow us to specify the exact degree of similarity between
types necessary for a particular operation. There's no need to create a
new type specifically to encapsulate the similarity needed for this
particular operation, and there's no need to operate on excessivly
abstract objects, and then do run-time checks to ensure that the objects
really do support the operations we care about. Likewise, we don't end
up with unwanted implicit conversions just because SOME operations imply
a relationship that doesn't work otherwise.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin
says...
[ ... overload resolution: ]
> 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.
Quite the opposite: compiler writers need to implement these rules. A
normal programmer only really needs to know one incredibly simple rule:
if it matters in the least which of a set of overloaded functions gets
called under any circumstance, then you shouldn't be using overloading
in the first place.
The whole point of overloading is to provide a set of functions that do
the same thing, but for different input types. As long as they all
really do the same thing, it doesn't matter a bit which one of them gets
selected for any given call.
The only time you care which one is called is if they DON'T do the same
thing -- and in that case, the first step is to decide whether 1) you
have a bug in the set of overloaded functions, or 2) your design was
wrong, and you're using overloading when you really shouldn't have in
the first place.
> 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.
Again, that's simply not true. The maintainence programmer is faced with
the same two possibilities as above: either he doesn't care at all which
of the functions gets used, or he fixed the fact that overloading was
being abused in the first place.
[ ... ]
> 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?
Yes and no. A class allows you to define a set of characteristics of a
type. Inheritance allows you to state (in essence) that a new type has
(at least) the characteristics of some existing type.
In this case, however, we're interested in allowing usage of ANY type
that has a set of characteristics. In some cases separate types come
about more or less by accident (e.g. different libraries in use). In
other cases we have things that support similar operations, but we still
definitely want them to be different types (e.g. the numeric types in C
or C++).
Now, it's (sort of) true that you can accomplish most of the same things
with inheritance IF you use it pervasively. For example, quite a few
things that will be done with Concepts in C++ could be done with
inheritance in something like Smalltalk, where everything is an instance
of some class. Even there, however, it's difficult to apply well -- in
particular, you frequently end up having to use types much closer to the
root of the whole tree than you'd like. In the process, you end up
allowing a lot of types that you didn't really want to allow.
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. Single inheritance implements the hiearachical
model. Multiple inheritance implements the network model. Concepts
implement the relational model.
jacob navia
YES!
What a SUBSTANTIVE argument
C++ right or wrong!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
James Kanze
> In article <49c4c21f$0$12621$ba4ac...@news.orange.fr>, ja...@nospam.org
> says...
> [ ... overload resolution: ]
> > 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.
> Quite the opposite: compiler writers need to implement these
> rules. A normal programmer only really needs to know one
> incredibly simple rule: if it matters in the least which of a
> set of overloaded functions gets called under any
> circumstance, then you shouldn't be using overloading in the
> first place.
I've argued that a lot myself in the past. But it is worth
pointing out that you don't always have a choice: you can't give
several different names to the constructor, for example. (In my
experience, this doesn't create that many problems in practice,
but it is worth pointing out.) Also, if you get carried away
with overloading (or overload too little), you can get
ambiguities---one helpful rule here is that if the overload set
contains any integral type, it should also contain int.
It's probably also worth pointing out that if you do want a
specific overload, for whatever reason, or if you encounter an
ambiguity, you can always use casts to achieve an exact match.
Even in such cases, you don't really have to understand all of
the details.
And finally, the fact remains that in most reasonable cases,
overload resolution does the right thing; i.e. what you'd
intuitively expect.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jerry Coffin
972d59...@k2g2000yql.googlegroups.com>, james...@gmail.com says...
[ ... ]
> I've argued that a lot myself in the past. But it is worth
> pointing out that you don't always have a choice: you can't give
> several different names to the constructor, for example. (In my
> experience, this doesn't create that many problems in practice,
> but it is worth pointing out.) Also, if you get carried away
> with overloading (or overload too little), you can get
> ambiguities---one helpful rule here is that if the overload set
> contains any integral type, it should also contain int.
>
> It's probably also worth pointing out that if you do want a
> specific overload, for whatever reason, or if you encounter an
> ambiguity, you can always use casts to achieve an exact match.
> Even in such cases, you don't really have to understand all of
> the details.
Right -- but these are things to know about overloading, not really
about overload _resolution_. There are definitely some rules of thumb
that are handy to know about overloading -- but you don't really have to
know _any_ of the overload resolution rules to know how to do
overloading perfectly reasonably. In fact, most of the time you can do
overloading perfectly reasonably without knowing many rules at all.
When you get down to it, the only rule I've seen people getting confused
about with respect to actual overload resolution is that when a scope is
found to contain at least one instance of the right name, no further
searching of outer scopes is conducted -- only names in that scope are
considered for overload resolution.
If you want to get really technical, that rule isn't really about
overload resolution per se either. Overload resolution only _starts_
after that search is conducted, and more than one candidate is found.
James Kanze
> In article <d9315332-f47e-498c-91ff-
> 972d593fb...@k2g2000yql.googlegroups.com>, james.ka...@gmail.com says...
The other one that seems to confuse people is that overloading
doesn't come into play until type deduction for template
functions has finished, and the rules concerning implicit
conversions aren't the same for template type deduction.
> If you want to get really technical, that rule isn't really
> about overload resolution per se either. Overload resolution
> only _starts_ after that search is conducted, and more than
> one candidate is found.
It's not really a question of overload resolution per se.
Still, they're small problems that do affect actual programmers,
even those writing clean code. In practice, probably not
seriously, but worth mentionning.
Tony
> Juha Nieminen wrote:
>> Zachary Turner wrote:
>>> But rvalue references? I've tried explaining
>>> these to FIVE different C++ programmers, and nobody has any idea what
>>> I'm talking about. It's like I'm trying to teach them Haskell or
>>> Hungarian, or something. But it sure doesn't sound to them like I'm
>>> talking about C++. Concepts are almost as bad.
>>
>> You don't have to know anything about rvalue references or concepts in
>> order to benefit from them.
>
> 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.
>
>> Concepts help the compiler give you more understandable error
>> messages.
>
> 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
> 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?".
Tony
> In article <49c51f63$0$2727$ba4a...@news.orange.fr>, ja...@nospam.org
> says...
>
> [ ... ]
>
>> 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.
Jerry Coffin
says...
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
says...
> Jerry Coffin wrote:
>
> > 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.
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.
> > 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?".
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.
namekuseijin
> Juha Nieminen wrote:
>
> Mainstream dialects have always had assignment and destructive operations.
The only purely functional language I'm aware of is Haskell (and perhaps
Miranda, its direct predecessor). ML, OCaml, Common Lisp, Scheme and
Erlang all incorporate non-lazy semantics and direct imperative
constructs, though some use more than others. Scheme and ML are very
purist languages.
namekuseijin
> However, templates are a bit different. They do not produce any code
> when the compiler first parses them. Moreover, there's no 1-to-1
> relationship between source and compiled machine code, but a 1-to-many:
> The same source can produce "dynamically" many different types of
> compiled machine code, depending on how the template is instantiated.
>
> the specified types (and scalars, in some cases).
C++ templates act similar to Common Lisp macros in that they are recipes
to generate (expand) code at compile-time.
nick_keigh...@hotmail.com
> Look, I am French, and even worst, I live in Paris. I know
> something about fads really.
almost sig material!
:-)
nick_keigh...@hotmail.com
> jacob navia wrote:
> > peter koch wrote:
> >> Old code will continue to work - what are you getting at?
>
> > In the shop I work we are tied to gcc 3.2 / MSVC 6.0.
>
> > Why?
>
> > Because those compilers allow to define a template without checking
> > until template expansion time if all symbols used in
> > the template are defined. Newer compilers do not.
>
> > The language changed.
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.
>
> > The problem is that the header files contain thousands of definitions
> > and no human mind can untangle them now. Depending on the order
> > of header files inclusion, some things will be defined when the
> > templates are defined and others are not. All will be defined when the
> > template is used but that is not enough for language purists.
>
> > We have attempted several times to solve this but it needs at least
> > 4-5 man-months to do that. And we do not have the resources,
> > we are a small shop...
>
> 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...
--
Nick Keighley
Jeff Schwab
In what way do "non-lazy semantics" prevent something being a functional
programming language? My understanding is that any language in which
all data are immutable is inherently "purely functional." If that
understanding is flawed, please post a link to a more formal definition.
> Scheme and ML are very purist languages.
I thought Scheme was meant to be a purely functional version of Lisp.
Did you just say it isn't purely functional, though?
Tony
"Jerry Coffin" <jco...@taeus.com> wrote in message
news:MPG.245f90735...@news.sunsite.dk...
>> 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.
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).