"Concepts" were removed from C++0x

[Balog Pal]

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.


--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

 

[Stephen Horne]

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]

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.

 

[Jerry Coffin]

[ ... ]

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.

 

[Balog Pal]

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.

 

[Stephen Horne]

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"?

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]

You think "even longer" is wishful thinking?

Do you also see visions of having your fingernails slowly torn out as
"wishful thinking"?



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.

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.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[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 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 ;

Or is it roughly equivalent to...

thing_t& item_alias (somearray );

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]

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 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.

 

[Tech07]

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

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]

Hi,

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 C++0x becomes C++1x, which is not necessarily a bad thing.


I think after C++1x, focus should be probably given to functional programming paradigm.


--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

 

[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]

Do namespaces present any problem? IMVHO they are one of C++'s most useful features.

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.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net