 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Andrei Alexandrescu
Guest
|
 Posted: Tue Aug 26, 2003 8:28 am Post subject: Re: Can we measure it? |
 |
|
"White Wolf" <wolof (AT) freemail (DOT) hu> wrote
[snip]
Hah! That's very interesting.
I guess it's pretty hard to decide which are language problems and which
are application problems. For one thing, there are many language problems
that appear when tackling /application/ problems that even aren't
approachable with other langugages!!!
So for example writing dimensional analysis code is like pulling teeth and
there are so many details to take care of, it boggles your mind - and most
of them are language-related I'd say, in the sense that one can easily
imagine the features that would greatly simplify the task. Yet there's no
language that I know of that solves dimensional analysis this completely
and this efficiently.
So it's hard to put each thing in one of the two bins...
But recording the obvious stuff would be great. For example, most COW
schemes primarily address the language issue that there's no way to tell
temporaries from non-temporaries. COW is more than that, but I'd bet money
that COW would be vastly less used if temporary elimination wouldn't be a
problem. Or, difficulties with implementing efficient and expressive matrix
operations stem from language's inability to either (1) allow the
programmer to control loop fusion (which is an AOP staple) or (2) allow the
programmer to compute the type of an expression (typeof), which could
greatly help ET-based implementations. Several contortions in Visitor and
Double Dispatch code in MC++D stem from inconsistent lookup rules for
member and nonmember functions... and so on.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Attila Feher
Guest
|
| Posted: Tue Aug 26, 2003 6:44 pm Post subject: Re: Can we measure it? |
|
|
Andrei Alexandrescu wrote:
[snip]
| Quote: | Hah! That's very interesting.
|
Thanks.
| Quote: | I guess it's pretty hard to decide which are language problems and
which are application problems.
|
Definitely. That is the reason why I have said that it is a big task. IMHO
at least 3, very experienced people (possibly not only with C++!) should
look at each problem. Since (hopefully usually) there are 2 possible
answers with a sort of "statistical lie" we could just take the "winner".
| Quote: | For one thing, there are many language problems
that appear when tackling /application/ problems
that even aren't approachable with other langugages!!!
|
Definitely. My gut feeling is that many of those might be tracked back to a
fundamental language design issue or to one or more "missing features".
| Quote: | So for example writing dimensional analysis code is like pulling
teeth and there are so many details to take care of, it boggles your
mind - and most of them are language-related I'd say, in the sense
that one can easily imagine the features that would greatly simplify
the task. Yet there's no language that I know of that solves
dimensional analysis this completely and this efficiently.
|
Uh oh. I must believe you because I have no idea what dimensional analysis
is. But IMHO if we meet tasks where no existing tool is good enough we can
safely put them (for the first round at least) to the "does not apply"
category and simply rule them out of the results. Of course, this could
also result in a by-product: a list of computing problems the IT community
(University research?) could look into.
| Quote: | So it's hard to put each thing in one of the two bins...
|
Possibly the effect of the problem should be taken into account as well.
Does it affect most of the C++ community or is it a small group, making
something very special? This does not mean their needs are not important,
but it does mean that from the point of view of a general purpose language
and its user community their problem weights less.
| Quote: | But recording the obvious stuff would be great.
|
Exactly. And the non-obvious one might create a healthy debate, possibly
some of them even new languages to tackle that particular problem. Or the
could support the addition of long awaited features (like typeof) into C++
by new arguments.
| Quote: | For example, most COW schemes primarily
address the language issue that there's no way to
tell temporaries from non-temporaries.
|
Sure. IMHO many things involving the handle-body idiom (or its variants)
are suspicious. Andrew Koenig is very good at explaining about that matter
and looking at his two books I have I am amazed that how many pages
(percent) are dealing with explaining it.
| Quote: | COW is more than that, but I'd bet money that
COW would be vastly less used if temporary
elimination wouldn't be a problem.
|
Sounds convincing.
| Quote: | Or, difficulties with implementing efficient
and expressive matrix operations stem from
language's inability to either (1) allow
the programmer to control
loop fusion (which is an AOP staple)
|
I have absolutely no idea what the last line means. :-(
| Quote: | or (2) allow the programmer to compute the type of an
expression (typeof), which could greatly help ET-based
implementations.
|
ET... phone home? Expression Templates? The need for typeof shows up in
many places. AFAIK working implementation exists. So this seems to be an
obvious need.
| Quote: | Several contortions in Visitor and Double Dispatch
code in MC++D stem from inconsistent lookup rules
for member and nonmember functions... and so on.
|
You have to use a less rich vocabulary when taling to me. :-)
IMHO in the troublesome cases (like for example boost template
metaprogramming library) one could look at the discussion of those things
and just make a "local divide and conquer" approach and say: 25% of the work
is done because of missing typeof, 50% is done because of... so that we
could see what percentage of the issue (this is especially true for large
issues) deals with workarounds and how much is the "real work". Then the
result could be added, like 75%/25% as 4 issues, one of which is language, 3
of which is "algorithmic".
--
Attila aka WW
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Andrei Alexandrescu
Guest
|
| Posted: Wed Aug 27, 2003 9:02 am Post subject: Re: Can we measure it? |
|
|
"Attila Feher" <attila.feher (AT) lmf (DOT) ericsson.se> wrote
| Quote: | Andrei Alexandrescu wrote:
So for example writing dimensional analysis code is like pulling
teeth and there are so many details to take care of, it boggles your
mind - and most of them are language-related I'd say, in the sense
that one can easily imagine the features that would greatly simplify
the task. Yet there's no language that I know of that solves
dimensional analysis this completely and this efficiently.
Uh oh. I must believe you because I have no idea what dimensional
analysis
is.
|
It's a google "dimensional anaylisis c++" away.
| Quote: | Or, difficulties with implementing efficient
and expressive matrix operations stem from
language's inability to either (1) allow
the programmer to control
loop fusion (which is an AOP staple)
I have absolutely no idea what the last line means. 
|
Loop fusion means fusing together two consecutive loops with the same
bounds:
for (int i = 0; i != N; ++i)
a[i] += b[i];
for (int i = 0; i != N; ++i)
a[i] += c[i];
becomes:
for (int i = 0; i != N; ++i)
{
a[i] = a[i] + b[i];
a[i] = a[i] + c[i];
}
which can be further transformed. The motivating example is implementing
matrix operations efficiently, starting from infix notation.
Aspect-Oriented Programming (AOP) puts things such as loop fusion under
programmer's control.
| Quote: | Several contortions in Visitor and Double Dispatch
code in MC++D stem from inconsistent lookup rules
for member and nonmember functions... and so on.
You have to use a less rich vocabulary when taling to me. 
|
Not a biggie. Member symbols hide one another, phenomenon not encountered
with nonmember symbols. I believe that it's a mistake to treat the two
kinds of symbols differently.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
llewelly
Guest
|
| Posted: Wed Aug 27, 2003 9:24 am Post subject: Re: Can we measure it? |
|
|
"Andrei Alexandrescu" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> writes:
| Quote: | "White Wolf" <wolof (AT) freemail (DOT) hu> wrote in message
news:bi8tbl$19r$1 (AT) phys-news1 (DOT) kolumbus.fi...
[snip]
Hah! That's very interesting.
I guess it's pretty hard to decide which are language problems and which
are application problems. For one thing, there are many language problems
that appear when tackling /application/ problems that even aren't
approachable with other langugages!!!
So for example writing dimensional analysis code is like pulling teeth and
there are so many details to take care of, it boggles your mind - and most
of them are language-related I'd say, in the sense that one can easily
imagine the features that would greatly simplify the task. Yet there's no
language that I know of that solves dimensional analysis this completely
and this efficiently.
So it's hard to put each thing in one of the two bins...
[snip] |
In part because you think of distinct non-overlapping bins, a notion
the real world does not support.
Perhaps it would be better to ask ' what portion of this problem is duen
the language, and what portion is due the application? ' Still a
hard question, but I think easier than yes/no .
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Andreas Harnack
Guest
|
| Posted: Wed Aug 27, 2003 10:22 pm Post subject: Re: Can we measure it? |
|
|
You might want to have a look at www.ppig.org (Psychology of Programming
Interest Group). I'm not sure whether there's any relevant work regarding
C++ so far, but there you'll find people who are looking exactly into
such kind of problems.
Andreas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Nicola Musatti
Guest
|
| Posted: Thu Aug 28, 2003 8:35 pm Post subject: Re: Can we measure it? |
|
|
llewelly <llewelly.at (AT) xmission (DOT) dot.com> wrote
[...]
| Quote: | In part because you think of distinct non-overlapping bins, a notion
the real world does not support.
Perhaps it would be better to ask ' what portion of this problem is duen
the language, and what portion is due the application? ' Still a
hard question, but I think easier than yes/no .
|
I would consider it more important (and harder!) to try and answer
these kinds of question:
Does this language aspect, which makes it very hard to solve my
current problem, make it easy to solve other kind of problems?
Would this new language feature, which would make it very easy to
solve my problem, make it harder to solve other problems?
Cheers,
Nicola
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Attila Feher
Guest
|
| Posted: Thu Aug 28, 2003 8:37 pm Post subject: Re: Can we measure it? |
|
|
Andreas Harnack wrote:
| Quote: | You might want to have a look at www.ppig.org (Psychology of
Programming Interest Group). I'm not sure whether there's any
relevant work regarding C++ so far, but there you'll find people who
are looking exactly into such kind of problems.
|
I have checked it fast. I could not find out really what they do, there is
rather a chronological ordering (newsletters etc.) rather than topical. I
was happy to see that although they have chosen a Pig for logo they left the
P (pee) part out. :-)
Do you have some link (I really have not enough brain capacity to browse
this site - headache for days now again) into this site, to something
deailing with a similar topic?
--
Attila aka WW
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
llewelly
Guest
|
| Posted: Fri Aug 29, 2003 11:08 am Post subject: Re: Can we measure it? |
|
|
[email]Nicola.Musatti (AT) ObjectWay (DOT) it[/email] (Nicola Musatti) writes:
| Quote: | llewelly <llewelly.at (AT) xmission (DOT) dot.com> wrote
[...]
In part because you think of distinct non-overlapping bins, a notion
the real world does not support.
Perhaps it would be better to ask ' what portion of this problem is duen
the language, and what portion is due the application? ' Still a
hard question, but I think easier than yes/no .
I would consider it more important (and harder!) to try and answer
these kinds of question:
Does this language aspect, which makes it very hard to solve my
current problem, make it easy to solve other kind of problems?
Would this new language feature, which would make it very easy to
solve my problem, make it harder to solve other problems?
[snip] |
Very clever. I'm trying to think about your new questions with respect
to ADL right now.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Andrei Alexandrescu
Guest
|
| Posted: Sun Aug 31, 2003 8:14 am Post subject: Re: Can we measure it? |
|
|
"Graeme Prentice" <gp1 (AT) paradise (DOT) net.nz> wrote
| Quote: | On 27 Aug 2003 05:02:58 -0400, "Andrei Alexandrescu"
[email]SeeWebsiteForEmail (AT) moderncppdesign (DOT) com[/email]> wrote:
Several contortions in Visitor and Double Dispatch
code in MC++D stem from inconsistent lookup rules
for member and nonmember functions... and so on.
You have to use a less rich vocabulary when taling to me. :-)
Not a biggie. Member symbols hide one another, phenomenon not
encountered
with nonmember symbols. I believe that it's a mistake to treat the two
kinds of symbols differently.
I can't understand what you mean by this. Can you give an example of
both member and non member case that illustrates what you mean?
|
struct A {
void Foo(int);
friend void Foo(A&, int);
};
struct B : A {
void Foo(double);
friend void Foo(B&, double);
};
The two member Foo's obey different lookup semantics than the two friend
Foo's.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Andreas Harnack
Guest
|
| Posted: Sun Aug 31, 2003 5:19 pm Post subject: Re: Can we measure it? |
|
|
Attila Feher wrote:
| Quote: | I have checked it fast. I could not find out really what they do, there
is
rather a chronological ordering (newsletters etc.) rather than topical. I
was happy to see that although they have chosen a Pig for logo they left
the P (pee) part out. :-)
Do you have some link (I really have not enough brain capacity to browse
this site - headache for days now again) into this site, to something
deailing with a similar topic?
--
Attila aka WW
|
I think we all agree that a programming language should be easy to use.
Measuring the 'easiness' of a language is a challenging task, however,
you'll find it already difficult just to decide what 'easy' exactly
means in the context of a programming language. The people in PPIG are
looking exactly into this kind of problems. They do real research by
giving subjects task in different languages and see how good they
perform (and this with sometimes surprising results).
As I said I'm not sure if there's any C++ related work so far,
basically since C++ as a real world language has many features
which would bias an experiment that tries to awnser a particular
question. I could try to find some dedicated links but I would
need a more specific question you are interested in.
Andreas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Nicola Musatti
Guest
|
| Posted: Thu Sep 25, 2003 1:43 pm Post subject: Re: Can we measure it? |
|
|
llewelly <llewelly.at (AT) xmission (DOT) dot.com> wrote
| Quote: | Nicola.Musatti (AT) ObjectWay (DOT) it (Nicola Musatti) writes:
[...]
I would consider it more important (and harder!) to try and answer
these kinds of question:
Does this language aspect, which makes it very hard to solve my
current problem, make it easy to solve other kind of problems?
Would this new language feature, which would make it very easy to
solve my problem, make it harder to solve other problems?
[snip]
Very clever. I'm trying to think about your new questions with respect
to ADL right now.
|
[I apologize for the long delay]
It is true that sometime a feature introduced to solve one problem
creates new problems: namespaces were added to reduce name clashes,
but made function and especially operator lookup a nightmare. ADL was
introduced to solve this, but...
Cheers,
Nicola Musatti
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Nicola Musatti
Guest
|
| Posted: Thu Sep 25, 2003 1:51 pm Post subject: Re: Can we measure it? |
|
|
"Attila Feher" <attila.feher (AT) lmf (DOT) ericsson.se> wrote
| Quote: | Nicola Musatti wrote:
[...]
I would consider it more important (and harder!) to try and answer
these kinds of question:
Does this language aspect, which makes it very hard to solve my
current problem, make it easy to solve other kind of problems?
Would this new language feature, which would make it very easy to
solve my problem, make it harder to solve other problems?
We have to be careful here! The study is just meant to find the limitations
in the language *not* the solutions to them! So it is in this way just the
start of a realization process, where we realize what is way too hard to do
in the language. *How* should it be made easier is a completely separate
step.
|
[I apologize for the long delay]
I'm not suggesting that the problems and their solutions should be
discovered at the same time. My point is that even in a language as
complicated as C++ each feature has a reason to be there, i.e. it is
meant to solve at least one problem. Ignoring the purpose of a feature
and seeing it only as a liability hides half of the picture.
Cheers,
Nicola Musatti
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
WW
Guest
|
| Posted: Thu Sep 25, 2003 11:39 pm Post subject: Re: Can we measure it? |
|
|
Nicola Musatti wrote:
[SNIP]
| Quote: | Does this language aspect, which makes it very hard to solve my
current problem, make it easy to solve other kind of problems?
Would this new language feature, which would make it very easy to
solve my problem, make it harder to solve other problems?
We have to be careful here! The study is just meant to find the
limitations > in the language *not* the solutions to them! So it is
in this way just the > start of a realization process, where we
realize what is way too hard to do > in the language. *How* should
it be made easier is a completely separate > step.
[I apologize for the long delay]
I'm not suggesting that the problems and their solutions should be
discovered at the same time. My point is that even in a language as
complicated as C++ each feature has a reason to be there, i.e. it is
meant to solve at least one problem. Ignoring the purpose of a feature
and seeing it only as a liability hides half of the picture.
|
Hm. How to put it into a more understandable context. You buy something.
You use it. It turns out that it is hard to use or to understand and you
spend more time on solving problems with the equipment than spending time
solving the problems you have bought the equipment for. You are locked with
that thing: there is nothing else you can use for that task - or you have
convinced yourself so. There is nothing to compare to. In such a case it
is absolutely irrelevant why the whole thing s*cks. Someone cooking dinner
for me can explain why it is terrible, what ingredients and how had to be
mixed and so foth. But honestly (if I am paying for that dinner) the max.
to get out of me is: then you should have cooked something else.
I am not saying this is the case. But I am sorry, I do not buy the idea of
first listening to excuses when trying to examine something objectively.
I have a "rule" along these lines, which I have never been able to put into
effect, because noone seems to understand it. Never allow the writer of the
code talk to those who review the code before the review is finished. All
what they should get is the specifications what the writer of the code have
got and the code. Absolutely zero communication until the reviewers has
seen, tried to understand or understood every single line of the code, asked
every single question they had and checked every single requirement if it is
met or not. Then, and only then, they can start to communicate.
So if we look at what are the most debated/frequent problems solved in the
C++ community we must not look at anything else, but: are they problems with
the language or problem we get our salaries to solve. I do not care and
must not care *why* the problems are there. I want to see that if C++ would
be a car, would anyone buy it?
--
WW aka Attila
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Nicola Musatti
Guest
|
| Posted: Sat Sep 27, 2003 10:12 am Post subject: Re: Can we measure it? |
|
|
"WW" <wolof (AT) freemail (DOT) hu> wrote
| Quote: | Nicola Musatti wrote:
[...]
I'm not suggesting that the problems and their solutions should be
discovered at the same time. My point is that even in a language as
complicated as C++ each feature has a reason to be there, i.e. it is
meant to solve at least one problem. Ignoring the purpose of a feature
and seeing it only as a liability hides half of the picture.
Hm. How to put it into a more understandable context. You buy something.
You use it. It turns out that it is hard to use or to understand and you
spend more time on solving problems with the equipment than spending time
solving the problems you have bought the equipment for. You are locked with
that thing: there is nothing else you can use for that task - or you have
convinced yourself so. There is nothing to compare to. In such a case it
is absolutely irrelevant why the whole thing s*cks. Someone cooking dinner
for me can explain why it is terrible, what ingredients and how had to be
mixed and so foth. But honestly (if I am paying for that dinner) the max.
to get out of me is: then you should have cooked something else.
|
This example is meaningful only if you consider C++ in its entirety,
not if you consider each of its features separately. To be able to
decide honestly whether something "sucks", you have to make sure you
understand its purpose, and to an extent to consider if better
alternatives exist. Otherwise your opinion will be unacceptably
superficial.
| Quote: | I am not saying this is the case. But I am sorry, I do not buy the idea of
first listening to excuses when trying to examine something objectively.
|
Calling reasons excuses is not what I would call the right approach to
objective examination.
[...]
| Quote: | So if we look at what are the most debated/frequent problems solved in the
C++ community we must not look at anything else, but: are they problems with
the language or problem we get our salaries to solve. I do not care and
must not care *why* the problems are there. I want to see that if C++ would
be a car, would anyone buy it?
|
But if you don't consider the actual purpose of each feature how can
you judge whether it isn't solving more problems than it causes? And
another related point: how many of these purported problems are
actually caused by misunderstanding and misuse?
Cheers,
Nicola Musatti
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
WW
Guest
|
| Posted: Sat Sep 27, 2003 2:52 pm Post subject: Re: Can we measure it? |
|
|
Nicola Musatti wrote:
[SNIP]
| Quote: | This example is meaningful only if you consider C++ in its entirety,
not if you consider each of its features separately. To be able to
decide honestly whether something "sucks", you have to make sure you
understand its purpose, and to an extent to consider if better
alternatives exist. Otherwise your opinion will be unacceptably
superficial.
|
You suggest that Scott Meyers, Herb Sutter, Andrei Alexandrescu, the CUJ,
the C++ Report is all a collection of hopeless fools, who are just solving
problems, because they do not udnerstand the langauge???
| Quote: | I am not saying this is the case. But I am sorry, I do not buy
the idea of > first listening to excuses when trying to examine
something objectively.
Calling reasons excuses is not what I would call the right approach to
objective examination.
|
Again: NO reasons and NO excuses. If I want to know if something sucks I
don't go there and ask those who made it: do you think it could have been
done better?
[SNIP]
| Quote: | But if you don't consider the actual purpose of each feature how can
you judge
|
I do *not judge*. And I do not judge *features*. I have suggested and
*independent* and *objective* study of how much of our time is spent on
solving language shortcomings (not working on the domain but on the
langauge, see missing typeof for one example, aligment specifications, no
variable arguments for templates(*) etc.) and how much do we spend on
working on the actual task. There is no place in an objective observation
for any other judgement than: is this
class/function/template/macro/technique/whatever part of the solution for a
programming problem or are we patching up the langauge.
(*) I deliberately listed thing for which core language change proposals
exist in various stages.
| Quote: | whether it isn't solving more problems than it causes? And
another related point: how many of these purported problems are
actually caused by misunderstanding and misuse?
|
If the problem solved does not exist...
| Quote: |
I know that such a research job is huge, it would need a fair amount of |
hours to do it and it has to be done by people who can make such a decision
(is this a langauge issue or not) etc. So making it should be a community
effort of professionals who are able to put aside their preconceptions about
what C++ is, and just look at it from the outside.
<<<<
As I have tried to point out up there the weakest part of this research is
that it must be done by people who posess two very rare abilities: they know
C++ inside out so they can detect if something is just plain wrong and has
to be ignored. OTOH they also be able to be such gurus, who can put aside
their knowledge of *why* C++ is what it is today and take an *objective*
look (without preconceptions) at the issue. This rules out nearly everyone
who has time. It even rules out the Dalai Lhama, since he probably could
take an objective look, but he is only a beginner in C++. :-)
You have to understand that the study I have proposed (as an idea to
consider) is to objectively wrap up where we are. Do we spend 20% or 70%
fighting with the language? What percent of those is due to missing but
"addable" features and how much is due to plain wring things... We possibly
do not care at first. And IMO if we fight 20% (in general, all around the
world) with the language it might even be considred as a good score. C++ is
not a domain specific language, where even 5% might be inacceptable.
And one more thing to add. I have said rule out misunderstanding. Yes. If
it has happened only *once* and you *know* that it does not happen everyday
in public. Andrei, please do not hate me but I will refer here to that
article you want CUJ to burn and throw the ashes into a nuclear reactor.
Andrei's article (I wont tell which, who knows knows) is a one time (public)
display of a misunderstanding. But it is *very common* one. After reading
that article I had to learn from a very friendly person (Terekhov) that it
is wrong. I had the *very* same misconception. And then I had to find out
that *all* I know had (at some point of their time, many even today) the
same misunderstanding. Is that something to be ignored? I say not. And I
know that the article itself had nothing to do (finally) with the C++
language. But the problem it has demonstrated had *everything* ot do with
the fact that C++ is way too silent about threads. Do we *know* that it
*is* a problem? Yes.
Any programming language is written for people. If people have serious
trouble learning it or have common misconceptions or misunderstandings it
*is* the fault of the language. Of course there are no extremes so if a
"guru feature" is not understood by newbies is one thing. But we still need
to start to think about what went wrong that the newbie did not know that
using that feature will make him blind and it will make hair grow on his
palms.
As this study is being done, since it is a *lot* of work, it is just obvious
we have to try to shortly pick out those problems. And then categorize
them. Let me guess a part what would we end up:
- better support for metaprogramming
- portabality issues
- clear up the relations to other standards (C, POSIX)
- get rid off inferior std library designs
- threading support
- define void main as exit(0) and get done with it :-)
- dynamic memory allocation issues (better langauge support for RAII *and*
gc, support for efficient small objetc allocations/allocation reuse, support
to get aligned memory without new/malloc etc.)
I could continue but let's not start a war about gc and stuff here. You can
see from the above list that I take a non-conventional (or very
conventional) approach to this and not dive a dime for what is the currently
defined scope of the language or what belongs (today) to the happy world of
QoI. I concentrate on a pragmatic approach: these are the jobs we have
today and these are the places where it all s*cks. That's it. I want to
see the standard telling that std::copy for PODs must be at least as fast as
memcpy with non-overlapping areas and as memmove with overlapping ones
(think as big O, we ignore the constant time the task of finding out if they
do overlap). And I am sure we all could list some such things.
Today some work in C++ not because they like, but because there is no
better. It was written here, in this moderatated newsgroup. We could lean
back, put out feet up(*) and say: there is nothing to do then, we are the
best. If any of you have no doubt that we should do that I have just one
thing to say: the dinosoars were the best, too. With no one to rival them.
Or so they thought.
(*) I know, I am a stinker! But I could not shoo the mental image that I
have seen that "lean back and feet up" thing somewhere along C++.
And I also know He did not stop making the language better.
http://www.research.att.com/~bs/homepage.html
--
WW aka Attila
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
