C++0x Concepts fall

I haven't been following Kevin's column for some time. So when I got Artima's newsletter today, it came as a shock to me.

Buried in the list of new articles, in 4th place -- after such otiose articles as a discussion on Ruby's arguable responsible programming characteristics or the hundredth AIR advocate interview this week -- is the actual news of the year; Concepts have been dropped from C++0x. Artima's here and Kevin's here.

Now, I'll take the stance no one seems to want and ask what the hell have these folks been doing all these years. The last paper on the matter was published in January 2006. Since then, there has been no new developments. When last year, around August if memory serves me right, Stroustrup presented the new features to be discussed on this meeting exactly, he mentioned concepts and devoted quite a few paragraphs to it. Just didn't he know he's work was incomplete? Why not just say it then, instead of waiting until last month (pdf link)? I'll let go a little more air and say that since we hardly heard of Dos Reis since 2005 and Stroustrup was busy writting his new book (as if there weren't enough C++ for Beginners material) it's no wonder Concepts never really were. Or should I say, it was a nice concept?

Having a standards committee is a double edged sword. While it is nice to have a diverse group of people studying every problem from every angle to discern any problems, it comes at a cost. That cost is that moving forward becomes difficult due to the amount of people that must be satisfied with every change.

These costs and benefits can be exemplified in the differences between OpenGL and DirectX. OpenGL is managed by a standards committee whereas DirectX can move at whatever speed Microsoft deems necessary. Guess which one of these is lagging behind the bleeding edge graphics technologies?

Quote:

---

Originally Posted by bithub

Guess which one of these is lagging behind the bleeding edge graphics technologies?

---

DirectX?

Geez, the committee is run by a number of blockheads. They argued for the feature for so many years and then dropped it? Morons!
Concepts was a really nice feature that I would have liked.
And what is the article spouting about otherwise? Namespaces bloated?
Why can't the committee just do one step at a time? Implement a small version of concepts, see how it goes and then evolve it.

And I'll take the above comment as sarcasm.

Concepts are a great idea of course, but I really think that the way they were planning to implement them was too complicated. Personally, I would have just incorporated ordinary templates into the scheme. Whenever the compiler encountered a concept it could simply attempt to compile the template associated with it, and if it failed then there is no match. For example:

Code:

---

template < typename T >
struct has_bar_function
{
        static void constraint( T& t )
        {
                t.bar( );       
        }
};

template < typename T >
requires has_bar_function< T >
void foo( T& t )
{       
        t.bar( );
}

template < typename T >
void foo( T& t )
{       
        // do something else with 't'
}

struct baz
{
        void bar( void )
        {        }
};

struct qux
{        };

int main( void )
{
        baz b;
        qux q;
        foo( b ); // meets has_bar_function< baz > requirement
        foo( q ); // doesn't - use some other foo function       
}

---

That way, the only change you've made to the language is to add the 'requires' keyword, plus you could use *any* template (std::vector, for instance!) to define the requirement.

Quote:

---

Originally Posted by MK27

DirectX?

---

Direct3D fails irl.

Elysia, I really don't think you are in any position to call the committee names. How closely have you followed the process? What do you know about the history of the proposal that lets you be a judge in the matter?

It's not true that there were no recent developments. For the last two years, the committee has tweaked, revised, and integrated concepts with the rest of the language. Integration, especially with the library, was a very complex task, and uncovered many weaknesses, both of concepts themselves and of other language features, such as rvalue references.
Kicking concepts out of C++0x was the admission that they underestimated the complexity of the task. Concepts are too complex - they were effectively designed by committee, and lacked a usable real-world implementation. This lack meant that too many practical issues were not immediately obvious, which explains why it took the committee so long to remove them - it wasn't until very recently that they realized just how much more work would have to go into concepts to make them work.

Quote:

---

Originally Posted by CornedBee

This lack meant that too many practical issues were not immediately obvious, which explains why it took the committee so long to remove them - it wasn't until very recently that they realized just how much more work would have to go into concepts to make them work.

---

This makes sense, naturally. But I can't find anywhere a description of what these issues where. I expect that information to be revealed soon, since I feel an explanation is required. Certainly some of the issues I will not understand. But I'd feel a lot better knowing it's not just politics or trifles.

I do not object to the Committee decision. Let that be clear. If it's not ready, it's not ready. Neither I am in favor of partial solutions that "grow in time" because there would be a serious risk of hitting a dead end and then the language would be left weakened with a feature that couldn't be removed neither it could be finished... only patched. Hey, I support the Committee decison!

But I do question the work that was done on this issue, CornedBee. Can't avoid it. The Joe Coder thread is three months old. It starts with a simple question that should have been answered 3 or 4 years ago. But during all that time, concepts where introduced into all the drafts and contrary to what you say, I can't see anywhere where concepts differed significantly since the 2006 paper. I'm left with the impression there has been hardly any work done on them to address the concerns that were raised during all these years.

They are different now. Oh yes, they are. One month before the meeting Stroustrup finally publishes a new concept on Concepts. Too late, don't you say? And all because someone asked "Will an average programmer want to use concepts?". Oh, please!

edit: edited the original post. Only realized now I was linking Artima's post to another topic altogether.

edit 2: Concerning the first paragraph of this post, here's the Stroustrup's detailed explanation, published yesterday. I cannot stop feeling that this wasn't a well planned project. Within my limited understanding, all this seems like somewhere along the development of this proposal, the authors lost focus of its objectives. Not only that, but at large ignored the debate until too late. Until 3 months before Frankfurt.

Quote:

---

Originally Posted by CornedBee

Elysia, I really don't think you are in any position to call the committee names. How closely have you followed the process? What do you know about the history of the proposal that lets you be a judge in the matter?

---

Maybe not. It's an opinion because from the little I have "seen" which is mostly what has been presented in the thread seems to tell the tale that they simply dropped it because it was too complex, or lacking or just because there was no real world example of it.

Now, if it is true that they simply didn't have time to make it work right, then I can understand, and then I would agree that it would need to be cut out and delayed. I will not forgive them if concepts do no see light of day. But I will forgive them if the concepts appear in a later standard.
Frankly, though, I'm disappointed. Too much discussion and too little real world experimentation with the feature is what it looks to me.

Quote:

---

Originally Posted by Elysia

Frankly, though, I'm disappointed. Too much discussion and too little real world experimentation with the feature is what it looks to me.

---

Indeed. I find it astonishing that 3 months before Frankfurt the head of the library team is still discussing whether Concepts are adequate for the average Joe. But I find it even more incredible the fact that such core concepts as implicit mapping are still being discussed. Is this a joke? What have they been doing? I don't pretend I know the inner workings of the C++ Standards Committee, but these type of things should have been agreed upon at most by the end of 2008. The last meeting of any standards body before implementation (which is what this meeting was) should be a near ad-hoc meeting meant to establish deadlines and gather final impressions and minor adjustments.

The funny bit is that I don't take sides on this matter. The only side I take is that of a generic agreement to the decision to not implement Concepts, given the situation. But there should be no patting on the back. This is a big failure and instead of painting it in pretty colors, or pointing fingers left right and center, I feel instead they should consider this everyone's failure. C++0x is a dissapointment in the way it was conducted.

Meanwhile, C++0x was to be taken literally. It will be either C++0xA, or maybe C++0xB.

Quote:

---

Originally Posted by Mario F.

But I'd feel a lot better knowing it's not just politics

---

Sadly, I have heard both Ahmadinejad and Medvedev are against strong typing and everything that goes with it, so you guys may just have to bare with for a while. :cool:

"Integration, especially with the library, was a very complex task, and uncovered many weaknesses, both of concepts themselves and of other language features, such as rvalue references."

O_o

Please don't tell me "r-value references" were dropped too!?

Soma

Quote:

---

Originally Posted by phantomotap

Please don't tell me "r-value references" were dropped too!?

---

No. Move semantics aren't dependent on Concepts. rvalue references stay. As do most of the other features in 2008 draft. Do not forget that this draft didn't include a Concepts library and many of the proposals that "depended" on it where so only for a matter of consistency, probably. Prior to the 2008 Draft they didn't use Concepts and were still perfectly functional proposals.

programming is stupid.

Quote:

---

These costs and benefits can be exemplified in the differences between OpenGL and DirectX. OpenGL is managed by a standards committee whereas DirectX can move at whatever speed Microsoft deems necessary. Guess which one of these is lagging behind the bleeding edge graphics technologies?

---

I wouldn't say Direct3D is ahead of nor behind OpenGL. They are both at about the same place. But at MS they have an entire dev team devoted to Direct3D so it is really not fair to compare the two. Besides Direct3D is just an interface to the HAL which means hardware manuf. come out with new ideas, hardware manuf. implement them on the card, D3D gurus write the interfaces in D3D, and driver gurus implement the interfaces. There a whole lot more people involved than just Microsoft when it comes to the advances in Direct3D.

The source of the advances is buried deep within the walls of NVidia and ATI.

Quote:

---

In general, Direct3D is designed to be a 3D hardware interface. The feature set of Direct3D is derived from the feature set of what hardware provides. OpenGL, on the other hand, is designed to be a 3D rendering system that may be hardware accelerated. These two APIs are fundamentally designed under two separate modes of thought. The fact that the two APIs have become so similar in functionality shows how well hardware is converging into user functionality[citation needed].

---

Comparison of OpenGL and Direct3D - Wikipedia, the free encyclopedia

Why is this thread turning into "OpenGL vs Direct3D"?

Anyway, I think concepts are a good idea, but not a great one. I understand that they dropped them. Seems like they have understood that they were making the language too complex. There are so many things that are added, and I doubt there will be a complete reference for C++0x - The current ones for "normal" C++ are thick enough.

I personally don't like the new function definition types nor the new typedef possibilities.

But I love static_assert and many others.

And I don't know who will implement all this

Quote:

---

Why is this thread turning into "OpenGL vs Direct3D"?

---

I should not have used that as an example. I forgot how easy it was to derail threads simply by mentioning those two words.

At any rate, I'm just looking forward to the "auto" keyword. Everything else is just unnecessary fluff :)

Quote:

---

Originally Posted by Brafil

Seems like they have understood that they were making the language too complex.

---

I have very personal opinions on that matter which probably aren't very popular. But I don't see syntax or semantics complexity as such a big problem. But hey, here it is...

C++ is already a complex language to learn and use. Certainly adding new features to the language while keeping a close eye on complexity is a good goal. But there's three aspects to Concepts that I think make the whole "will Joe Coder want to use Concepts" the wrong debate. The fact that this is at the core of the decision to abandon Concepts on C++0x, since even the implicit or explicit concept mapping discussion has its roots on that question, is very disheartening to me. It leaves a foul taste in my mouth that politics and frivolous debate was the real issue. Not Concepts. A feeling that Herb Sutter's recent blog post makes even stronger. Especially if you then compare that to Stroustrup article.

But the three aspects...

1. Can we tell exactly what adds more to complexity? Hard to follow syntax and semantics, or weak error diagnostics? It's my feeling it is the latter. A hard to follow syntax is invariably going to be learned at some point, the same goes for semantics. It's a matter of study. No different from so many other professional areas, from accounting to scientific fields. But hard to track bugs or hard to understand compiler reports is going to strain the coder a lot more. What we have now is a syntax that is somewhat easy to teach, semantics somewhat easy to learn, but the coder is left alone trying to understand template related errors messages. This is particularly damaging to library developers who suffer the most. One of Concepts primary aim was exactly to create the necessary groundwork that would help to considerably improve current template diagnostics. In my view, this alone makes Concepts a feature that reduces programming complexity already.

2. C++ is a multi-paradigm programming language. This has far more repercussions than just the admission we can use different tools for different jobs. It should also be the understanding that some jobs simply aren't as easy as others. In C++ certain paradigms are definitely harder to grasp than others. For a newcommer going from procedural programming to OOP is a big step. The language is made harder for them and it will take a long while until all the new concepts, semantics and syntax get buried in their brain. It is in my view acceptable that Generic Programming is accepted as being even harder. Of course, whenever there is a chance to simplify learning and usage one should take it. But this can't be the basis for deciding wether a feature is going to be implemented or not. Being that Concepts was primarily aimed at Library Developers, does it really makes sense to ask "will Joe Coder use Concepts"? Joe Coder will use concepts yes. One day, whe, he feels more comfortable with the language and decides to step into more complex areas of software development. Just like he did a couple of years ago when he decided it was time to go OOP and tackle all the incredible complexity of this new paradigm in C++. This has also a lot to do with the natural characteristic of C++ of being a modular programming language, which makes it easy to teach and learn. And it really surprises me the whole debate around complexity vs. simplicity. It's in my opinion a mistake to oversimplify or to aim for simplicity above all else. "Simple" is often harder or impossible to achieve... should the alternative be no feature at all?

3. Finally, there's the admission that conceptually C++ templates are irreprehensible, but the theoretic basis on which they were implemented in C++ is weak. I'm not sure I understand this argument very well. But it's a fact that it took me a long time to actually soak in the concept of Generic Programming to start taking advantage of it beyond simple function templating. However the concept of Concepts was immediately understood. It made a whole lot of sense to me. That... and I liked it because of that. It just seems, with Concepts, C++ Generic Programming would be made easier to teach and learn. Can I be biased by the fact I was already aware of Generic Programming concept and its advantages when I first started reading about Concepts? It's possible. I may be looking at Concepts as easier simply because I understand better now what generic programming is under C++. But inm my defense I'll say that I'm in fact a newcmmer to generic programming with no more than 1 year on my back and very little to show in terms of actual work. So I'd give this 3rd point also some consideration.

Quote:

---

Originally Posted by phantomotap

"Integration, especially with the library, was a very complex task, and uncovered many weaknesses, both of concepts themselves and of other language features, such as rvalue references."

O_o

Please don't tell me "r-value references" were dropped too!?

---

No.

But it was the interaction with concepts that pointed out that it's not safe, in general, to let rvalue references bind to lvalues. So they changed it.

It was in the course of concept integration that they discovered that throwing move constructors (and moving is closely tied with rvalue refs) are completely unsafe - as with throwing destructors, if you have one, you simply cannot write exception-safe code. Now they're discussing a "nothrow" annotation that is actually part of the type system.

Quote:

---

Originally Posted by Brafil

Why is this thread turning into "OpenGL vs Direct3D"?

Anyway, I think concepts are a good idea, but not a great one. I understand that they dropped them. Seems like they have understood that they were making the language too complex. There are so many things that are added, and I doubt there will be a complete reference for C++0x - The current ones for "normal" C++ are thick enough.

I personally don't like the new function definition types nor the new typedef possibilities.

But I love static_assert and many others.

And I don't know who will implement all this

---

I think you have a negative outlook.
C++ is supposed to be a general purpose programming language, combining multiple paradigms.
Now, templates are difficult to master. Should we remove them to make the language easier to learn? I think not. Expert programmers should not have to suffer because newbies might have a difficult time grasping all concepts.
Is there a single developer out there that knows the entire C# or Java Standard Library? Doubtful.
What I mean is that usually we strive to learn what it is we want to do and a language provides the facilities to do so. So you want to do OOP programming. Sure. Learn the OOP part.
So, you want to do Generic programming. Sure. Learn the generic part.

The new typedefs and the new function definition types enhances the parts that C++ specializes in. Making it easier and more powerful, even.
So I think it's a real shame they dropped Concepts, but I am very positive about every other added feature.

I don't blame. Many concepts are great:

constexpr,
rvalue references,
extern templates,
initializer lists,
auto variable,
decltype,
the new for-loops,
thread_local,
regexes,
Suffixes - a nice "toy" that can be both very fun and useful

The things I would reconsider:
nullptr - It's not very elegant IMO. But I don't know a better way of doing it.
using instead of typedef. I didn't really grasp that.

Just a question: Isn't it possible to add template typedefs?
Just another question: can you have mixed initalizer lists (std::initializer_list<int, char, double>)?

Quote:

---

Now, templates are difficult to master. Should we remove them to make the language easier to learn? I think not. Expert programmers should not have to suffer because newbies might have a difficult time grasping all concepts.

---

Never! Templates are a very important part of C++!

The only thing I didn't like was the added complexity for _compiler-writers_ and the possibility of misusing some concepts. Like always using the new function definitions - looks more like Pascal. The "C" way is one of the things I truly like about C/C++.

But the discussion was about concepts, right? Maybe they'll include them later.

Quote:

---

Originally Posted by Brafil

using instead of typedef. I didn't really grasp that.

---

You declare template typedefs the same way you declare namespace aliases.

Quote:

---

But the discussion was about concepts, right? Maybe they'll include them later.

---

Maybe. We'll see in the future.

Quote:

---

Originally Posted by Brafil

The things I would reconsider:
nullptr - It's not very elegant IMO. But I don't know a better way of doing it.

---

What do you think are the problems of nullptr? I've played around with it (and I've implemented it) and I find it very intuitive.

Quote:

---

using instead of typedef. I didn't really grasp that.

Just a question: Isn't it possible to add template typedefs?

---

The alias declarations with 'using' can do that, yeah. You can actually have a lot of fun with them. The reason we have 'using' instead of 'typedef' is, I think, mainly one of grammar. The way typedef works, I think it would be very hard to make template typedefs that don't look absolutely atrocious. In general, the new syntax is much nicer than the arcane C syntax.

Code:

---

using INT = int;
// Arcane:
typedef void (*WhyIsTheNameHere)(int);
// Logical:
using ThisIsGood = void (*)(int);

// Template:
template <typename T>
using SpecialVector = std::vector<T, SpecialAllocator<T>>;

// Fun:
template <bool MutablePointer>
struct MetaFunction {
  using type = std::string;
};
template <>
struct MetaFunction<true> {
  using type = std::vector<char>;
};
template <bool MutablePointer>
using StringType = typename MetaFunction<MutablePointer>::type;

StringType<false> this_is_a_std_string;
Stringtype<true> this_is_a_char_vector;

---

Quote:

---

Just another question: can you have mixed initalizer lists (std::initializer_list<int, char, double>)?

---

Initializer lists can be heterogenous, and the compiler will interpret the elements as constructor arguments and do overload resolution. However, std::initializer_list can only represent homogenous initializer lists.

Code:

---

class A {
  A(int, float, std::string);
};
class B {
  B(std::initializer_list<int>);
};

A a{1, 1, "hello"};
B b{1, 2, 3, 4, 5, 6, 7, 8, 9};

---

Quote:

---

Why is this thread turning into "OpenGL vs Direct3D"?

---

It's not.

I was hoping the new standard would be finalized soon because the longer it takes the longer we have to wait for it to appear in compilers. It does seem to me that, based on the article, there have been some significant missteps.

Yeah, but anyone should agree it's not easy to design all that. So we should rather have called it C++1x. Some do so.

How about that:

Code:

---

template <typename Type>
typedef Getter = const Type &(*)(void);

template <typename Type>
typedef Setter = void (*)(const Type &);

Getter<bool> IsActive;
Setter<bool> SetActive;

---

So, just typedef instead of using? With the new syntax? I think that would be nice.

Quote:

---

So, just typedef instead of using? With the new syntax? I think that would be nice.

---

As I said, it's a grammar problem. I know the internals of only one compiler, but I can tell that while it would be possible to modify it to parse this, it would lead to some very ugly code in the parser.
The using keyword doesn't have as much grammatical cruft attached.

Quote:

---

Originally Posted by Brafil

Yeah, but anyone should agree it's not easy to design all that. So we should rather have called it C++1x. Some do so.

---

I kinda agree. It would be far better if they incorporated less stuff in less timeframes so new standards can be released more often. It already takes a decade to figure out how to implement all this stuff since they meet so "often."

Quote:

---

Originally Posted by Elysia

I kinda agree. It would be far better if they incorporated less stuff in less timeframes so new standards can be released more often. It already takes a decade to figure out how to implement all this stuff since they meet so "often."

---

But then again, switching between languages often isn't good either.

Ok. I understand now. As far as I know, using is only used for copying data into namespaces. And in C++0x, also into classes, right?

Meh, it has two different purposes.
1) Import a specific type into the a namespace (ie use std::cout).
3) Create a type alias (ie template<typename T> using Vec = std::vector).

Quote:

---

Originally Posted by Elysia

Meh, it has two different purposes.
1) Import a specific type into the global namespace (ie use std::cout).

---

Into any namespace. You can do this:

Code:

---

namespace foo { void x(); }
namespace bar { using foo::x; }
void f() { bar::x(); }

---

This is quite often useful, e.g. many Boost libraries define most of their symbols in a library-specific namespace and lift a few important names into the boost namespace.

Quote:

---

2) Create a namespace alias (ie using l = boost::lambda).

---

No, you do that using namespace:

Code:

---

namespace ll = boost::lambda;
namespace fs = boost::filesystem;

---

Quote:

---

3) Create a type alias (ie template<typename T> using Vec = std::vector).

---

That one is new in C++0x.

There's more.
4) Make names from a base class visible in the derived class despite overloading:

Code:

---

struct Base {
  virtual void f(int);
  virtual void f(float);
};
struct Derived : public Base {
  virtual void f(int); // Override (int) version.
  using Base::f; // But let the compiler still find the (float) version.
};

---

5) Change access of inherited elements, especially inherited from private bases:

Code:

---

class Whatever : private std::vector<int> {
public:
  typedef std::vector<int>::iterator iterator;
  typedef std::vector<int>::const_iterator const_iterator;
  using std::vector<int>::begin;
  using std::vector<int>::end;
};

---

Re 2): Oh yes, my bad. I don't know what I was thinking...
And I forgot 1). I've seen it, of course.