"Concepts" were removed from C++0x
Ioannis Vranos
"The Rise and Fall of C++0x Concepts":
http://www.devx.com/cplus/Article/42365
--
Ioannis A. Vranos
C95 / C++03 Developer
Ioannis Vranos
> I just happened to find the link in a forum:
>
>
>
> "The Rise and Fall of C++0x Concepts":
>
> http://www.devx.com/cplus/Article/42365
Two other interesting links on the topic:
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
Bjarne Stroustrup's thoughts:
http://www.ddj.com/cpp/218600111
Brian Wood
> Ioannis Vranos wrote:
> > I just happened to find the link in a forum:
>
> > "The Rise and Fall of C++0x Concepts":
>
> >http://www.devx.com/cplus/Article/42365
>
> Two other interesting links on the topic:
>
> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
>
The conclusion may be the best part of that article:
"Every new proposal seems neat and promising at first but after
a few iterations and redesigns, it might easily turn into a
bloated tumor that impedes the natural growth and evolution of
the language (namespaces anyone?). If we're ever going to have
concepts in C++, it's "the marketplace", not the committee,
that needs to do its work first and only then should the
committee bless the result -- if it so chooses. Doing things
the other way around is a recipe for failure."
> Bjarne Stroustrup's thoughts:
>
> http://www.ddj.com/cpp/218600111
>
I'm not sure why he describes "Yank and ship" as
"seven year's work down the drain." That seems
overblown. I agree with the decision to remove
concepts. The misplaced ' is kind of interesting.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
Ioannis Vranos
>>
>> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
>>
>
> The conclusion may be the best part of that article:
>
> "Every new proposal seems neat and promising at first but after
> a few iterations and redesigns, it might easily turn into a
> bloated tumor that impedes the natural growth and evolution of
> the language (namespaces anyone?). If we're ever going to have
> concepts in C++, it's "the marketplace", not the committee,
> that needs to do its work first and only then should the
> committee bless the result -- if it so chooses. Doing things
> the other way around is a recipe for failure."
Regarding namespaces, I think it is a great concept and not a failure.
I consider the namespaces example "unfortunate".
Brian Wood
I don't care for how a number of Boost libraries reuse
names like list -- there's boost::intrusive::list. I'd
like to change the name of the intrusive class and use
a website to regulate names used in C++ programs.
Balog Pal
"Brian Wood" <co...@mailvault.com>
Note, that the author Danny Kalev has a reputation to write BS in books and
articles...
For the curent instance seem like not exception by comments:
<< Two Committee members (Herb Sutter & Robert Klarer) have commented on
that
article, and to quote Herb Sutter: "This article is correct when it says
that concepts are no longer part of C++0x. Beyond that, it's hard to know
where to start with the major errors in fact and characterization, and the
rest is best ignored." >>
> Bjarne Stroustrup's thoughts:
>
> http://www.ddj.com/cpp/218600111
>
>I'm not sure why he describes "Yank and ship" as
>"seven year's work down the drain." That seems
>overblown. I agree with the decision to remove
>concepts. The misplaced ' is kind of interesting.
Overblown how? The work was put in. The time, the thinking. Also much
collaterally.
It is being rolled back -- and I'm not sure how the stuff is dealt with
where proposals were withdrawn because 'concepts provide a better and more
general solution'.
Down the drain is pure reality -- another standard release will not happen
in another 10 years following 0x release, by that time C++ may be pretty
obsolete, and/or many current professionals already moved to other fields or
retired. I sure don;t expect to use a concept-implementing C++ compiler in
my life. :(
The time figureas are also not too convincing, that the chosen way will
provide the standard sooner compared to the 'fix it' version, or the
difference being more than 0.5-1 year.
OTOH the compiler writers' approach gives some justification.
Stephen Horne
<ivr...@freemail.gr> wrote:
>Regarding namespaces, I think it is a great concept and not a failure.
>
>I consider the namespaces example "unfortunate".
I like namespaces, but I found it pretty funny some time back when I
read that the C++ hashtable classes are called "unordered_map" etc
because names like "hashmap" are likely to clash with pre-existing
non-standard hashtable implementations.
Avoiding that kind of clash is exactly why the standard library is in
the "std" namespace. But of course people love to write "using
namespace" - and not just for the standard library, but for pretty
much every namespace they have an interest in. End result - the whole
point of using namespaces is defeated, since name clashes are still an
issue regardless.
And it's hard to dismiss this as "if you use this bad style, you
deserve what you get" when the standards guys themselves are fussing
about name clashes where no name clash should ever happen. Kind of
suggests that the battle for good style WRT this issue has already
been lost.
Personally, I think namespaces are ok, but "using namespace" was a
mistake. It would have been better to have a single universal alias
construct, so that any overlong name (type, function, constant, or
whatever) could easily be given a convenient alias when needed.
That is, a command-line utility with lots of standard output use might
have...
alias std::cout cout;
alias std::endl endl;
Rather than...
using namespace std;
Of course it's easy to criticise, everyone has opinions, and hindsight
is no substitute for foresight, etc.
Balog Pal
>>Regarding namespaces, I think it is a great concept and not a failure.
>>
>>I consider the namespaces example "unfortunate".
>
> I like namespaces, but I found it pretty funny some time back when I
> read that the C++ hashtable classes are called "unordered_map" etc
> because names like "hashmap" are likely to clash with pre-existing
> non-standard hashtable implementations.
>
> Avoiding that kind of clash is exactly why the standard library is in
> the "std" namespace. But of course people love to write "using
> namespace" - and not just for the standard library, but for pretty
> much every namespace they have an interest in. End result - the whole
> point of using namespaces is defeated, since name clashes are still an
> issue regardless.
just because there are ways to defeat the benefits (not using NS or using
using directives) doesn't lead to 'still an issue'. Those who want to
control names in general, can do it. Those who stumble in a class with a
couple of independent libraries can deal with it in a not so hard way.
Unfortunately namespaces are not THAT good as looked on paper, and
definitely brought some weird interactions. And some lateral stuff, that
looked good, turned out broken (ADL...)
Ignoring existing libraries with similar names and similar-but-not-same
semantics than something going to standard is IMO bad thinking, and would
create problems. name unordered_* looks strange at first, but makes sense.
> And it's hard to dismiss this as "if you use this bad style, you
> deserve what you get" when the standards guys themselves are fussing
> about name clashes where no name clash should ever happen.
Why?
Since standard I avoid names 'string' 'vector' 'list' 'map' as possible for
types or object names. Even where std:: is not used. To avoid mental
confusion. I do not avoid a ton of other names that are also appear in
std:: but are rare beasts.
> Kind of
> suggests that the battle for good style WRT this issue has already
> been lost.
Also note that writing using declarations [example: using std::string; ] is
NOT considered bad style. The code becomes much more readable if you have a
couple such declarations. hashmap would be a good candidate to be included
in such group.
> Personally, I think namespaces are ok, but "using namespace" was a
> mistake.
It is extremely handy for some real life situations. Like you stumble on a
clash situation in a few sources and decide to move a library from global to
a namespace. That part is easy. But what with all the existiing code, it all
need prefixes... unless you introduce using there, and add them only in the
problem files. Or even there only use :: operator at the clashing names for
disambiguation.
Also, if you ever use CORBA, and the usual component package convention,
you'll very soon discover the value of using and namespace aliases ;-))
> It would have been better to have a single universal alias
> construct, so that any overlong name (type, function, constant, or
> whatever) could easily be given a convenient alias when needed.
Length is just one particular problem.
> That is, a command-line utility with lots of standard output use might
> have...
>
> alias std::cout cout;
> alias std::endl endl;
>
> Rather than...
>
> using namespace std;
Why not do it the suggested way:
using std::cout;
using std::endl;
Well, you can't provide a new name -- but you didn't want one in the
example, and it's a usual situation.
> Of course it's easy to criticise, everyone has opinions, and hindsight
> is no substitute for foresight, etc.
LOL
Stephen Horne
>Down the drain is pure reality -- another standard release will not happen
>in another 10 years following 0x release, by that time C++ may be pretty
>obsolete, and/or many current professionals already moved to other fields or
>retired. I sure don;t expect to use a concept-implementing C++ compiler in
>my life. :(
Even if that is the right timescale for the next standard (and I
wouldn't be that surprised if it was longer), I don't agree.
As quoted by Brian Wood...
: If we're ever going to have
: concepts in C++, it's "the marketplace", not the committee,
: that needs to do its work first and only then should the
: committee bless the result -- if it so chooses. Doing things
: the other way around is a recipe for failure.
Prior to standardisation, the language was pushed forward rapidly,
first by Stroustrup himself and then by the standardisation process.
Features such as templates had compiler developers chasing the draft
standard. In many cases this worked out well, but in some cases,
mistakes were (at least arguably) made. I'd mention one in particular,
but it might re-open an old argument with James Kanze.
As a language matures, it makes sense to be more conservative and
cautious about changes. And given that concepts are a quite
substantial feature, I doubt we'll see an extension in GCC in a few
months. But I suspect an experimental feature will be available in a
year or so.
These days, we tend to try out new libraries in Boost before
standardising them. It makes sense to be just as cautious about the
core language features.
With Stroustrup himself being "disappointed" that concepts have been
dropped from C++0x, it seems unlikely that the idea will just die.
That said, Stroustrup had an idea for multimethods (aka multiple
dispatch) in C++ once, and the term "vapourware" probably isn't unfair
WRT that. Particularly annoying every time you have to use the visitor
pattern, though several source-to-source translators and DSLs have
been written to work around the issue. I used treecc for a while,
until I wrote my own alternative to work around some issues.
Stephen Horne
>"Stephen Horne" <sh006...@blueyonder.co.uk>
>> That is, a command-line utility with lots of standard output use might
>> have...
>>
>> alias std::cout cout;
>> alias std::endl endl;
>>
>> Rather than...
>>
>> using namespace std;
>
>Why not do it the suggested way:
>
>using std::cout;
>using std::endl;
>
>Well, you can't provide a new name -- but you didn't want one in the
>example, and it's a usual situation.
1. The new name thing is directly relevant to the unordered_map
rather than hashmap issue I was discussing. Remember, the clashes
they are trying to avoid are with pre-existing non-standard
libraries. Someone wanting to mix hashmap implementations (e.g.
during a transition from old in-house libraries to new standard
ones) may well want an alias.
2. A single uniform alias construct would be convenient anyway,
irrespective of namespaces. I get annoyed when I just want an
alias for something, and need to figure out what it is in order to
choose the right way to alias it.
For example, is std::endl a constant? A function? What type is it?
Obviously, I never actually alias it, but these are questions I'd
have to answer if I ever did. No big deal - but still a
distraction when all you want is an alias. In fact, rather than
answer those questions, a lot of people would probably take the
easy (in the short term) path - #define. It doesn't seem such a
bad idea - until you use Doxygen, or ...
std::endl might seem exceptional in that the user doesn't
necessary know the type of the thing he's using, but that isn't so
rare as it might seem, especially WRT templates. For example...
template<typename T> void blah<T> ()
{
// what is the type of T::some_member?
}
Also, how exactly do you alias a variable without causing a
run-time overhead? What I tend to do is use a reference
variable...
thing_t& shortname (longname);
But in doing that, I'm risking a significant run-time overhead.
Often I don't care (not an inner loop etc), and very likely the
optimiser can eliminate that overhead anyway, but it's still a
potential issue that IMO should never exist.
3. I'd forgotten that I could use 'using' that way. Personally, I
tend to have a lot of "std::" in my code. And "sh::", for my own
libraries. Occasionally, I'll put "using namespace" in a local
scope somewhere, but I only ever put it at the global level in
trivial (usually regression test) programs.
Brian Wood
That's a good point, but how is it decided what makes it
from Boost to the standard? I'm not excited about some of
the libs that get added. And some others that I think should
make it haven't yet. To a certain extent I guess a library
author who pushes his library and is willing to put in time
writing proposals is able to influence things. What do
people think of adding Boost Intrusive to the standard?
This last go round with the standardization process has been
a mess. I would like to see a new standard every two years
or so. A lot of what will be in the next version of C++
should have already been available for years.
Brian Wood
> "Brian Wood" <c...@mailvault.com>
If you're right about it taking 10 years for another release
then there's probably some truth to what you say, but I don't
expect it to be 10 years or even 5 years until there's another
version of the standard.
Stephen Horne
<co...@mailvault.com> wrote:
>This last go round with the standardization process has been
>a mess. I would like to see a new standard every two years
>or so.
That's very rapid revision for a programming language standard.
Fortran has been revised maybe 7 or 8 times since 1953, IIRC. I
believe that the 2008 revision, planned to be a minor revision, missed
2008 and is still not complete.
Ada standards were dated 1983, 1995 and 2005, giving a roughly
decade-long cycle.
Of course there are languages that evolve much more quickly - but how
many undergo formal standardisation? Pascal has IIRC two standard
versions, neither of which is relevant to the real world since "Object
Pascal". And some of these rapidly evolving languages probably have a
generally accelerated fad-driven lifecycle - will Perl, Python, PHP
and Ruby *all* survive in the long term? Will C# be replaced with F#?
And whatever happened to J++ and J#? Or Icon? Or...
I still haven't figured out whether Perl 6 is just a long-running
practical joke or not ;-)
> A lot of what will be in the next version of C++
>should have already been available for years.
True - but concepts aren't something I want to see rushed. The main
thing I think should have been in the C++ standard years ago is
alignment handling. Also, unrestricted unions IMO should never have
been so severely restricted in the first place - an unrestricted union
can save a lot of hassles. For a data structure node, for instance...
template<typename data_t, size_t node_size> struct node_t
{
union item_t { data_t m; };
size_t m_Size;
item_t m_Items [node_size];
...
};
The point of the union? - it keeps the size and alignment of the
single member, but blocks the automatic constructor and destructor.
The items can then be explicitly constructed and destructed according
to the current size of the node. Achieving this ATM is an awkward and
non-portable pain. I've often wondered (but never checked) how
std::vector and std::deque handle this issue, since both can have
memory allocated for unused and uninitialised objects.
Stephen Horne
<sh006...@blueyonder.co.uk> wrote:
>And given that concepts are a quite
>substantial feature, I doubt we'll see an extension in GCC in a few
>months. But I suspect an experimental feature will be available in a
>year or so.
Whoops...
Jerry Coffin
99b9e7...@d4g2000yqa.googlegroups.com>, co...@mailvault.com says...
[ ... ]
> This last go round with the standardization process has been
> a mess. I would like to see a new standard every two years
> or so. A lot of what will be in the next version of C++
> should have already been available for years.
The ISO process makes a two year cycle nearly impossible. Expect to
see over a year from the time the last change is made to the standard
until the standard is officially accepted and finalized.
--
Later,
Jerry.
Brian Wood
> > This last go round with the standardization process has been
> > a mess. I would like to see a new standard every two years
> > or so. A lot of what will be in the next version of C++
> > should have already been available for years.
>
> The ISO process makes a two year cycle nearly impossible. Expect to
> see over a year from the time the last change is made to the standard
> until the standard is officially accepted and finalized.
>
If there's less to review in each version, maybe the
ISO process could be shortened. At any rate, something should
be done to see to it that it doesn't take 10+ years between
updates. Five years seems too long, but at the moment it
would be great.
red floyd
> Ioannis Vranos wrote:
>> I just happened to find the link in a forum:
>>
>
Dr. Stroustrup mentioned that Howard Hinnant was one of the movers.
Maybe Howard could provide further enlightenment past Dr. S's
(excellent) article?
tni
> Also, how exactly do you alias a variable without causing a
> run-time overhead? What I tend to do is use a reference
> variable...
>
> thing_t& shortname (longname);
>
> But in doing that, I'm risking a significant run-time overhead.
> Often I don't care (not an inner loop etc), and very likely the
> optimiser can eliminate that overhead anyway, but it's still a
> potential issue that IMO should never exist.
I would argue that it's the other way around. Using the reference will
give the compiler the option to generate faster code in some cases.
E.g.
std::vector<size_t> blah;
blah.resize(20);
for(size_t i = 0; i < 50; i++) {
size_t& ref = blah[10];
ref += std::rand();
ref += std::rand();
}
Having the reference gives the compiler the guarantee that the address
of vector[10] won't change, so it doesn't have to call operator[] again
(the call is actually inlined, but not eliminated). Of course, semantics
are different, with the reference you have the danger of it going stale
(which can lead to very nice obscure bugs).
The loop with reference is 15 instructions with VS 2005 (release build),
the loop without reference is 24 instructions. With GCC 4.4 (-O2), it's
17 vs. 19 instructions.
(With only one 'ref += std::rand();' in the loop both generate the same
code with or without reference.)
Balog Pal
"Stephen Horne" <sh006...@blueyonder.co.uk> az al�bbiakat �rta a k�vetkezo
h�r�zenetben: h1df65d83afqpgi6p...@4ax.com...
> On Thu, 23 Jul 2009 02:39:56 +0200, "Balog Pal" <pa...@lib.hu> wrote:
>
>>Down the drain is pure reality -- another standard release will not happen
>>in another 10 years following 0x release, by that time C++ may be pretty
>>obsolete, and/or many current professionals already moved to other fields
>>or
>>retired. I sure don;t expect to use a concept-implementing C++ compiler
>>in
>>my life. :(
>
> Even if that is the right timescale for the next standard (and I
> wouldn't be that surprised if it was longer), I don't agree.
Sure, using the "wishful thinking" magic I wouldn;t agree either, but we
have the real world to face.
> : If we're ever going to have
> : concepts in C++, it's "the marketplace", not the committee,
> : that needs to do its work first and only then should the
> : committee bless the result -- if it so chooses. Doing things
> : the other way around is a recipe for failure.
That is the very nail in the coffin -- this approach works with libraries,
maybe for some light core extensions, definitely not for a profound change
as concepts.
> As a language matures, it makes sense to be more conservative and
> cautious about changes. And given that concepts are a quite
> substantial feature, I doubt we'll see an extension in GCC in a few
> months. But I suspect an experimental feature will be available in a
> year or so.
Compiler writers will be implementing whatever the current standard will be.
Then dealing with the fallout. Light features. Pour work into a thing
yanked will hardly gain priority, espevially for the amount of work needed
to have an already working subset.
> These days, we tend to try out new libraries in Boost before
> standardising them. It makes sense to be just as cautious about the
> core language features.
>
> With Stroustrup himself being "disappointed" that concepts have been
> dropped from C++0x, it seems unlikely that the idea will just die.
The ide will not die, I was talking about feature I could actually pick for
use. ;-|
But time will tell, there is hardly much point in guessing this early.
Balog Pal
"Brian Wood" <co...@mailvault.com>:
>> Down the drain is pure reality -- another standard release will not
>> happen
>> in another 10 years following 0x release, by that time C++ may be pretty
>> obsolete, and/or many current professionals already moved to other fields
>> or
>> retired. I sure don;t expect to use a concept-implementing C++ compiler
>> in
>> my life. :(
>If you're right about it taking 10 years for another release
>then there's probably some truth to what you say, but I don't
>expect it to be 10 years or even 5 years until there's another
>version of the standard.
We had standard in '98, and the next real thing will be, as looks now not
earlier than '12. (I don't count '03 as anything but a sour patch.)
Work on 0x started around '00 and being kept in 10 years seemed realistic by
all means. yet it will quite overextend.
I expect the thing repeating: in 5 years after the current release we'll
likely see a TC, that just fixes what turned out broken (even without
concepts there is a ton of new stuff, includeing wild interactions due to
threads) without any attempt to real change.
We also may see pure library extensions like tr1 -- those are relatively
easy to manage, if the source is written and is working for years, and only
need replacing boost:: to tr1::.
What wuld you think could make the core changes faster to standardise?
Balog Pal
>>And given that concepts are a quite
>>substantial feature, I doubt we'll see an extension in GCC in a few
>>months. But I suspect an experimental feature will be available in a
>>year or so.
>
> Whoops...
>
> http://en.wikipedia.org/wiki/ConceptGCC
Whoops what? One of the main motivations in pull of concepts were that
conceptgcc, that implemented an early version became not usable, and people
doing it abandoned the project completely, years ago.
Ioannis Vranos
>
>
> Down the drain is pure reality -- another standard release will not happen
> in another 10 years following 0x release, by that time C++ may be pretty
> obsolete, and/or many current professionals already moved to other fields or
> retired.
C++ is relatively a new language. Its first standard was in 1998, I think if no major change happens in
computing, we will have it for at least another 40 years.
For example, consider Fortran 66 which now has reached Fortran 2008.
Stephen Horne
>Stephen Horne wrote:
>
>> Also, how exactly do you alias a variable without causing a
>> run-time overhead? What I tend to do is use a reference
>> variable...
>>
>> thing_t& shortname (longname);
>>
>> But in doing that, I'm risking a significant run-time overhead.
>> Often I don't care (not an inner loop etc), and very likely the
>> optimiser can eliminate that overhead anyway, but it's still a
>> potential issue that IMO should never exist.
>
>I would argue that it's the other way around. Using the reference will
>give the compiler the option to generate faster code in some cases.
>
>E.g.
>
> std::vector<size_t> blah;
> blah.resize(20);
> for(size_t i = 0; i < 50; i++) {
> size_t& ref = blah[10];
> ref += std::rand();
> ref += std::rand();
> }
That's not an alias - at least, not in the sense I'm using the word.
An alias is purely a new name - not a mechanism for precalculating a
subscripting operation, pointer dereferences, member selection or
whatever.
Obviously using a reference is a good thing in your example - and yes,
I use references like that from time to time.
Similarly, I might alias a constant by declaring a new constant. That
may have a run-time impact in terms of initialising that constant and
memory used to store it - as always, depending on the optimiser. You
could argue that the constant may be a faster and more readable than
repeating a constant expression over and over, but if your constant
expression does anything more than identify an existing constant, it
isn't an alias. An alias is a new name for something that already
exists and already has a name.
const int shortname = some_other_const_int; // an alias, sort of
const int shortname = some_other_const_int + 1; // NOT an alias
Stephen Horne
I didn't know that, but whatever the status of the project, it's
relevant here and I only just noticed that it is/was out there. What
it says about the probability of GCC getting concepts in, e.g., my
year-or-so may be unclear, but it says something.
Balog Pal
"Stephen Horne" <sh006...@blueyonder.co.uk>
>>Whoops what? One of the main motivations in pull of concepts were that
>>conceptgcc, that implemented an early version became not usable, and
>>people
>>doing it abandoned the project completely, years ago.
>
> I didn't know that, but whatever the status of the project, it's
> relevant here and I only just noticed that it is/was out there. What
> it says about the probability of GCC getting concepts in, e.g., my
> year-or-so may be unclear, but it says something.
cGCC, as the only implementation to use for experimenting, implementiong the
conceptized stl, was very much needed. Yet it was dropped in this time of
most need.
The 'something' it says to me, this really smells graveyard.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2893.pdf
see 2.3, 3.2.
I'm very unhappy about the pull, but I accept the "will not be implemented"
argument, and the picture quite shows it.
For the future I only see a decline in motivation.
Jerry Coffin
24g2000yqm.googlegroups.com>, co...@mailvault.com says...
[ ... ]
> If there's less to review in each version, maybe the
> ISO process could be shortened.
Not much. Just for example, the regulations for the US standards
bodies require that the committee release two drafts for public
review, and each requires a minimum of a 90-day public review period.
As I recall, after the committee votes out its final draft, there's
another 90-day review period for the rest of the NCIS to look over
what they've done.
There's also a requirement that _every_ comment about the draft
standards (that's sent in via the officially approved channels) must
receive an individual reply. Admittedly, in some cases the official
reply might be a single sentence, but it has to be written for every
single thing that's sent in.
I don't know (or at least remember) all the details, but the original
C standard ran into this -- somebody had sent in a comment and
somehow or other the comment didn't get an official reply. This came
to light after the committee had produced their final draft. The
simple process of sending the final draft back to the committee,
writing and sending and official reply to the comment, and then re-
submitting the draft for approval added almost a _year_ to the time
it took to approve the C standard.
> At any rate, something should
> be done to see to it that it doesn't take 10+ years between
> updates. Five years seems too long, but at the moment it
> would be great.
There are some possibilities, but I doubt they'll be given serious
consideration. The most obvious possibility would be to do the work
via a different standards body, then use the ISO's "fast track"
process to add their stamp of approval to that result as an existing
standard.
I don't see the entirety of the committee quitting and joining
another standards body, and the ISO going along with it and just
shutting down an active committee. That means an attempt along this
line would probably have almost the worst possible result: two or
more mutually incompatible, competing standards.
--
Later,
Jerry.
Stephen Horne
>> Even if that is the right timescale for the next standard (and I
>> wouldn't be that surprised if it was longer), I don't agree.
>
>Sure, using the "wishful thinking" magic I wouldn;t agree either, but we
>have the real world to face.
You think "even longer" is wishful thinking?
Do you also see visions of having your fingernails slowly torn out as
"wishful thinking"?
>> : If we're ever going to have
>> : concepts in C++, it's "the marketplace", not the committee,
>> : that needs to do its work first and only then should the
>> : committee bless the result -- if it so chooses. Doing things
>> : the other way around is a recipe for failure.
>
>That is the very nail in the coffin -- this approach works with libraries,
>maybe for some light core extensions, definitely not for a profound change
>as concepts.
Why? This approach seems to work in other languages. In fact, if you
read the blurb from standards organisations, standards are *supposed*
to formalise *existing* best practice.
C++ itself started life as an experimental C language extension - a
more than slightly unfair claim given that the early development of C
and C++ was pretty much concurrent in a just-down-the-corridor sense
IIRC, and C itself certainly wasn't standardised at the time. Even so,
cfront was a source-to-source compiler developed as an experiment in
object-oriented extensions to C. I have no idea whether the original
intent was to fork the language into two, but it doesn't matter - with
any sufficiently complex language extension experiment, that may be a
possibility, and it's not necessarily a bad thing.
Consider the "Aspect C++" experiment. It seems unlikely to ever gain
the kind of critical mass that would lead to aspects being merged into
the main C++ language. The fact that it is considered a
related-but-distinct language is a good thing, but it's still at heart
an experimental language extension. If the experiment succeeds, the
ideas can be copied back into C++ - if it fails, there's no harm.
Similarly, consider "cmm" - a C++ extension experiment that supports
multimethods.
The same thing would apply to an experimental "Concept C++" language,
but then it seems the ConceptGCC experiment may have already failed.
Substantial language extension experiments are actually pretty common.
True, they don't often seem to succeed, at least in the sense of being
merged back into the main language - but then isn't it better for
features to fail as experiments than as impossible-to-get-rid-of
clutter in the standard?
Brian Wood
Yeah, I think it is fair to say it was a failure. Adding anything
significant to gcc seems a mistake to me. Mr. Gregor may
have seen the light as I think he's now working on a C++
compiler written in C++... better late than never.
> Substantial language extension experiments are actually pretty common.
> True, they don't often seem to succeed, at least in the sense of being
> merged back into the main language - but then isn't it better for
> features to fail as experiments than as impossible-to-get-rid-of
> clutter in the standard?
Yeah.
Balog Pal
> 2. A single uniform alias construct would be convenient anyway,
> irrespective of namespaces. I get annoyed when I just want an
> alias for something, and need to figure out what it is in order to
> choose the right way to alias it.
I agree There was a proposal for scoped macros, that would cover much of
that (and regular macros do now, just with unwanted side effects...). I
didn't follow how that proposal fared.
> Also, how exactly do you alias a variable without causing a
> run-time overhead? What I tend to do is use a reference
> variable...
>
> thing_t& shortname (longname);
>
> But in doing that, I'm risking a significant run-time overhead.
IMO you need a broken compiler for that. I recall a single problem with
such alias (at local scope, class member is a different beast), MSVC created
a copy for some ?: initialiser.
> Often I don't care (not an inner loop etc), and very likely the
> optimiser can eliminate that overhead anyway, but it's still a
> potential issue that IMO should never exist.
The reference is a genuine alias, so using it as such sould not be an
'optimisation' by any means.
With the new standard auto will hopefully remove many alias and temporary
related headaches.
> 3. I'd forgotten that I could use 'using' that way.
It's good to remember, as some situations almost require it, to create the
overload set. (there was a good article on how to deal with swap... too bad
we need such magic). Also needed in class hierarchies sometimes, to import
names.
Dealing with prefix xlutter is only one of the use cases.
Balog Pal
>> std::vector<size_t> blah;
>> blah.resize(20);
>> for(size_t i = 0; i < 50; i++) {
>> size_t& ref = blah[10];
>> ref += std::rand();
>> ref += std::rand();
>> }
>
> That's not an alias - at least, not in the sense I'm using the word.
> An alias is purely a new name - not a mechanism for precalculating a
> subscripting operation, pointer dereferences, member selection or
> whatever.
>
> Obviously using a reference is a good thing in your example - and yes,
> I use references like that from time to time.
>
> Similarly, I might alias a constant by declaring a new constant. That
> may have a run-time impact in terms of initialising that constant and
> memory used to store it - as always, depending on the optimiser.
A reference is not an object. It is an alias (in its other meaning) to an
existing object. Normally it doesn't need storage, just the compiler keep
track what it refers. (Sometimes it prolongs life of temporary objects a
little, but that is another story).
> You
> could argue that the constant may be a faster and more readable than
> repeating a constant expression over and over, but if your constant
> expression does anything more than identify an existing constant, it
> isn't an alias. An alias is a new name for something that already
> exists and already has a name.
Interesting distinction, the meaning I know does not have the last
requirement -- it is a name introduced to an existing object, period. Who
cares what names it already has or not.
suppose you know to have one of the following:
int i1; int & i2 = i1;
or
int i2; int & i1 = i2;
can you write code that figures out which is the situation? Does i1 and i2
behave differently? Which is alias of which? IMO they are simmetric, two
names for a single object.
You can add int& i3 = i2; now would be i3 alias of what? ;-)
Stephen Horne
>Interesting distinction, the meaning I know does not have the last
>requirement -- it is a name introduced to an existing object, period. Who
>cares what names it already has or not.
Put it this way - if I told you that "Fred" was someones alias, you'd
be pretty surprised to later discover that "Fred" is his one and only
name. You'd also be surprised to hear the term "President of the
United States" described as an alias. Sure, it identifies a particular
person (at any given time), but it's a role or job-title, not an
alias. In my mindset, it's equivalent to having to calculate what
you're referring to rather than using an existing name.
The word "alias" has a meaning in the English language, and that's
what I was trying to use - not any other programming-related meaning.
That said, I haven't fully thought all this through, and certainly in
my mindset, typedef is an alias - even when it aliases something that
hasn't been otherwise named, such as...
typedef std::vector<something_t> my_alias;
I may be being irrational - it happens sometimes.
Is "std::vector<something_t>" a structured name, or an expression for
deriving something that doesn't have a (previously known) name?
Thinking about it, that may well be a silly question - the only
significant point is that typedef is normally considered to provide an
alias type. And the same principle could easily be asserted for...
alias somearray [i] item_alias;
The expression is a way of identifying a variable/value/whatever - in
a sense, it's just a structured name.
*BUT* - how sensible is that hypothetical example? What does that
alias mean? Is it an alias for the array element? Or for the value
that was contained in that element when that statement was executed?
Is it roughly equivalent to...
thing_t item_alias = somearray [i];
Or is it roughly equivalent to...
thing_t& item_alias (somearray [i]);
The whole point of the "alias" idea is to be a convenient notation
giving a shorthand name. That risks ambiguity, which needs managing.
The easiest way to avoid problems - kneejerk bans on anything
potentially scary.
"You must be able to determine exactly what it refers to at compile
time" might be too severe, but it should be sufficient.
>suppose you know to have one of the following:
>
>int i1; int & i2 = i1;
>or
>int i2; int & i1 = i2;
>
>can you write code that figures out which is the situation? Does i1 and i2
>behave differently? Which is alias of which? IMO they are simmetric, two
>names for a single object.
I have no problem with that. Consider a person who's aliasses might be
"Fred", "George" and "Burt". Likewise symmetric. Which one you
consider his genuine name (if any) may be arbitrary or otherwise
unimportant.
There is no requirement in English that aliases should reference each
other in a tree-structure. We might learn them in a tree-structured
dependency-based way, but even that's true, which particular tree
structure is just a fluke of which order we learn those names in - in
practice they're just an equivalence class.
The existing name is not the same as the existing named entity. There
may be many existing names for the same existing entity. Adding a new
alias, whichever existing name you use to do so, is really just adding
a new item to that equivalence-class of aliases.
The whole point of the existing name is that it's the only way you
have to identify the equivalence class, other than by "calculating"
it.
As I said, I may be being irrational.
James Kanze
> On Fri, 24 Jul 2009 01:37:14 +0200, "Balog Pal" <p...@lib.hu> wrote:
> >Interesting distinction, the meaning I know does not have the
> >last requirement -- it is a name introduced to an existing
> >object, period. Who cares what names it already has or not.
> Put it this way - if I told you that "Fred" was someones
> alias, you'd be pretty surprised to later discover that "Fred"
> is his one and only name. You'd also be surprised to hear the
> term "President of the United States" described as an alias.
> Sure, it identifies a particular person (at any given time),
> but it's a role or job-title, not an alias. In my mindset,
> it's equivalent to having to calculate what you're referring
> to rather than using an existing name.
> The word "alias" has a meaning in the English language, and
> that's what I was trying to use - not any other
> programming-related meaning.
> That said, I haven't fully thought all this through, and
> certainly in my mindset, typedef is an alias - even when it
> aliases something that hasn't been otherwise named, such as...
> typedef std::vector<something_t> my_alias;
> I may be being irrational - it happens sometimes.
Since you're discussing a language problem, it's normal. The
language itself is irrational in many ways.
Merriam-Webster gives the definition "an assumed or additional
name". For people, every one has a given name, which is neither
assumed nor additional, so an "assumed or additional name" must
be in addition to the given name. But in C++, some objects
don't have names---any name they have is "assumed or
additional". (And "The President of the United States" isn't an
alias because it's not a name.)
But of course, I just invented that argument after the facts.
It's no more "rational" than yours. You wouldn't call Jim an
alias for James, but it certainly fits the definition. Or if it
was applied to me, would it be an alias for James Albert Kanze,
the name which appears on my birth certificate? For that
matter, is James an alias for James Albert Kanze (or is there
just a "using namespace" in effect---but doesn't "using
namespace" create a set of aliases)?
> Is "std::vector<something_t>" a structured name, or an
> expression for deriving something that doesn't have a
> (previously known) name?
I'd consider it the name of a class. Modulo typedef, it's the
only name that class has. And yes, it's also an "expression",
but then, so is something like Ortega y Gasset or Garcia Lorca.
> Thinking about it, that may well be a silly question - the
> only significant point is that typedef is normally considered
> to provide an alias type. And the same principle could easily
> be asserted for...
> alias somearray [i] item_alias;
> The expression is a way of identifying a
> variable/value/whatever - in a sense, it's just a structured
> name.
> *BUT* - how sensible is that hypothetical example? What does
> that alias mean? Is it an alias for the array element? Or for
> the value that was contained in that element when that
> statement was executed?
It's an "assumed name" for whatever is referenced. If it
references the array element, it's an alias for the array
element; if it references a temporary, it's an alias for the
temporary.
--
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
Tech07
"Ioannis Vranos" <ivr...@freemail.gr> wrote in message
news:h47c90$l80$1...@news.grnet.gr...
> Ioannis Vranos wrote:
>> I just happened to find the link in a forum:
>>
>>
>>
>
>
> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
Were "concepts" a first attempt at invention by the committee? It would
appear from the above links that "the committee" admittedly does not have
such a capability and will stick to "standardizing existing practice". But
again, were "concepts" a test of that concept (that the comittee could
actually invent something useful)? Is it ironic that a committee of
developers (or is it one of those at all?!) cannot develop something? Were
they even trying?!! (or just trying to legitimitize the template concept,
"throwing good money after bad"?).
Christof Donat
> Were "concepts" a first attempt at invention by the committee?
They were a brilliant idea. Sadly the committee was not able to stabilize
the whole thing in a way that would not completely break any remains of the
time schedule.
> Were they even trying?!!
Have you reasons to assume they did not?
> (or just trying to legitimitize the template concept,
> "throwing good money after bad"?).
Sounds like you don't like templates too much. What is wrong about them?
Christof
Krice
> Sounds like you don't like templates too much. What is wrong about them?
Templates are good in restricted use (like STL), but when you start
to use them everywhere it's a road to pain. Concept sounds like
(I didn't actually get what is it) another way to make the
language more abstract and produce less readable source code.
It's not always good to add all kinds of fancy stuff and
I believe there is a certain kind of credit in the simplicity
of C++, even if it means more low level programming.
When people suggest all kinds of additions in C++ I think
they are not aware of the nature of the language. They want
C++ to be Python or something like that.
Rui Maciel
> Were "concepts" a first attempt at invention by the committee? It would
> appear from the above links that "the committee" admittedly does not have
> such a capability and will stick to "standardizing existing practice". But
> again, were "concepts" a test of that concept (that the comittee could
> actually invent something useful)? Is it ironic that a committee of
> developers (or is it one of those at all?!) cannot develop something? Were
> they even trying?!! (or just trying to legitimitize the template concept,
> "throwing good money after bad"?).
A poor attempt at trolling. I'll give it a 2/10 for effort.
Rui Maciel
Rui Maciel
> "Every new proposal seems neat and promising at first but after
> a few iterations and redesigns, it might easily turn into a
> bloated tumor that impedes the natural growth and evolution of
> the language (namespaces anyone?).
Do namespaces present any problem? IMVHO they are one of C++'s most useful features.
Rui Maciel
Ioannis Vranos
I think after C++1x, focus should be probably given to functional programming paradigm.
Pete Becker
> I think C++0x becomes C++1x, which is not necessarily a bad thing.
>
C++0x is still C++0x.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
Rui Maciel
> I think after C++1x, focus should be probably given to functional
> programming paradigm.
If someone wants develop using the functional programming paradigm then why shouldn't that person simply pick
up a functional programming language? I mean, where exactly is there a need to bolt on yet another feature to
an already highly complex programming language?
Rui Maciel
Brian Wood
Namespaces established a "let's agree to disagree" mentality.
I promote using a website to manage the assignment of names.
Using the internet I think it's possible to improve on the
status quo in this area.
Ioannis Vranos
AFAIK, the Functional programming paradigm is *probably* a good approach (it makes it easy) for writing
multithreading programs without thread-sharing.
If it is proven to be an efficient approach, I see no reason why C++ should remain behind and do not adopt it.
But it is really soon for such a discussion.
Rui Maciel
> AFAIK, the Functional programming paradigm is probably a good approach (it
> makes it easy) for writing multithreading programs without thread-sharing.
Yes, and it may even have the potential of simplifying some mundane, frequent programming tasks. Yet, that
doesn't mean that all programming languages should support it.
> If it is proven to be an efficient approach, I see no reason why C++
> should remain behind and do not adopt it.
That's what I don't get. Why exactly is it a good idea to bolt support for yet another programming paradigm
onto C++? Isn't C++ complex enough as it is? In fact, when there is a need for functional programming,
wouldn't it be better to simply use one of the many functional programming languages to perform the tasks
where functional programming shines?
Rui Maciel
Ioannis Vranos
No paradigm is a perfect solution for all problems.
Check the section about "silver bullets" in the following article:
http://linux.sys-con.com/node/32929
So if a paradigm gets proven to be effective, it should be provided by a professional multiparadigm language
such as C++.
Of course, all the stuff you already know, will continue to apply.