Lambda the Ultimate

• Doug Gregor's proposal for polymorphic function object wrappers.
• Jaakko Järvi's proposal for tuple types.

It's been a while since I've done any C++. Can anyone clue me in?

A Proposal to add a Polymorphic Function Object Wrapper to the Standard Library

Proposal for adding tuple types into the standard library

1. Both features originate from the Boost library. It seems this library is becoming a sort of testing ground for future C++ functionality. I wonder if this will continue, and perhaps expand to include Loki as well.

2. I'm currently finishing Andrei Alexandrescu's book "Modern C++ Design" which refers to Jaakko Järvi's tuple types explicitly (and explains their design) and also provides an implementation of polymorphic function object extended to support currying. Both require quit a bit of C++ hacking to implement.

3. Yes, C++ is getting a functional bent, and is that surprising? It's, after all, the path to the future ;-) Anyway, this isn't really a new thing. Consider STL algorithms like for_each and bind1st.

I'm not sure what sort of clues you are looking for Ehud, but the purpose of these additions appears to be pretty straightforward: a tuple type makes it easier to create functions that return multiple values (of various types) without jumping through the hoop of creating a specialized class or struct. I do wonder how many C++ programmers will use it instead of simply using out parameters, especially as sequence unpacking does not appear to be supported. Or put another way, how many C++ programmers will indeed go the functional way.

With regard to polymorphic function object, they appear to server two purposes:

1. Give C++ the semblance of functions as first-class citizens (thus allowing a bit of higher-order programming).

2. Unify the numerous ways C++ provides for expressing a function reference (function pointers, member function pointers, and arbitrary function objects).

It is interesting that both these features, neither of which were presumably in Stroustrup's sights when he conceived, designed and implemented C++, where accomplished as pure library extensions, requiring no changes to the core C++ language.

There may be various technical reasons for this but to me it seems that the reason is the differences in character, attitude towards PL design, and managing a developer community between Larry Wall and Bjarne Stroustrop.

I guess I should really get this book, right? You seem to think it's a good read.

In the proposal, I see: int i; char c; double d; tie(i, c, d) = make_tuple(1, a , 5.5);

Are you refering to something else?

It is a good read, and I enjoyed it, but given this statement you also made:

It's been a while since I've done any C++.

I'm not sure I would recommend it to you. This book is very much hard-core C++ and may not be relevant for people working in other PLs. For example, there is a whole chapter detailing the intricacies of implementing a smart pointer class. Not much of an issue if you're working in Java, for example.

Another interesting point is that although this book is very hands-on (lots of code samples), there are very few compilers out there that can actually compile this code. In fact, there may only be one.

If you wish, when I finish the book and have a little spare time, I'll do a short review for LtU.

Yes, your sample is what I meant. I missed it skimming through the document. It's still much more verbose that what you would have done in Python:

i, c, d = make_tuple(1, a , 5.5);

This is really an amazing C++ phenomenon. Anyone who tries to exploit the language in serious ways needs a new compiler...

It's still much more verbose that what you would have done in Python:

In Haskell it's:

(i, c, d) = (1, a, 5.5)

In Ocaml you can even write:

i, c, d = 1, a, 5.5

i, c, d = (1, a , 5.5)

or...

i, c, d = 1, a, 5.5

There are some situations where the () are needed, but not always.

The new version of VC++ (Visual C++ .NET 2003), claimed to be 98% compliant, does have support for partial template specialization, and should compile Loki, but then again, I haven't tried it.

It's the sad truth that the C++ Standard has been way ahead of mainstream C++ compilers for years. This also may be a reason why the C++ Standard has evolved so slowly in recent times.

Beside the bummer of having features dangled before your face yet being unable to use them, another downside it that some features appear in the Standard that have turned out to be bad ideas or have serious side-effects. This is the result of lack of in-the-field testing, e.g. the export keyword.

On the bright-side MS is claiming that their upcoming release of VC++ will be 98% compliant with the Standard. Since VC++ is the de-facto standard for C++ programming on Windows, this is indeed very good news.

BTW, one reason for this is that there has not been such a significant pressure on compiler developers from the C++ community to become more Standard compliant. Yes, there are the vocal participants on comp.lang.c++.moderated, but for the most part, the C++ community (if it can even be called a community) has been silent. From my experience many C++ developers are simply unfamiliar with the more advanced (or at least newer) features, and are reluctant to use them.

Another reason is that building a fully compliant C++ compiler is very difficult. From the second part of the export article:

The export feature alone took more than three person-years to code and test (not including design); by comparison, implementing the entire Java language took the same three people only two person-years.

My response to this book (and I imagine many people around here might agree) was very much love/hate. The hacker in me loved the diabolical trickiness and the tireless drive to extract unplanned functionality from C++, but the engineer (and PL enthusiast) in me hated the diabolical trickiness and impenetrable idiom...

For example, I recall one case in the first couple of chapters where Alexandrescu writes a call to a function that is never defined, noting that this is OK because the "return value" is used only in a sizeof(), which is evaluated at compile-time, so really the compiler won't generate a call to said function (I may have gotten that slightly wrong, I don't have the book with me... that was the gist, though). More or less the whole book is full of stuff like that. At the end of the first few chapters, I wanted to giggle and gag at the same time, and my only coherent thought was, "Congratulations, C++ is the new Perl."

Certainly if I were forced to use C++, I'd be very glad for the tricks in the book (and in Loki, on a more day-to-day level), but honestly I'd much rather just choose a different language in the first place... I'd highly recommend the book, though, for entertainment value alone.

Consider a matrix library that allows users to manipulate matrices like regular values using operator overloading:

A = B + C;

There is no doubt that this makes it easier for the library's users. OTOH many C++ programmers don't know how to implement operator overloading, or fear it (indeed it was not included in Java because it was deemed "to complex"). So, C++ library developers need to understand operator overloading, but regular Joe developers may not.

The intricacies of templates are another example of this. Partial template specialization is incredibly important to the library developer. All the library user needs to know about is that he'll get the optimal implementation for his scenario.

One might claim that in an ideal PL there should be no difference between library developers and standard developers, that even powerful features should be easily accessible. While I definitely agree that many features could be made more accessible than they are in C++, I still believe that levels of expertise are inescapable in general purpose PLs.

Alexsanderscu wrote his book for the library developer (I believe this book is the result of his development of Loki). C++ is taken to its limit and then some. Some may see this as pure hackery, other as testament to the flexibility of C++.

And again, if the library writer uses hacks that make the library’s code more complex, but the end result is a library that is easier to use and more type-safe, is that a bad thing?

Some template trick are complex and require understanding intriacte details. Writing simple generic code, however, should be something any half decent programmer can do (even in C++).

I did not say operator overloading should be considered a dark art. All I said was that many C++ programmers don't know how to do operator overloading. And, if they do know about it, they consider it to be a complex feature that shouldn't be normally used. Still doesn't stop them from doing:

std::string a = "hello"; std::string b = " world"; std::string c = a + b;

And the sad fact is that many C++ programmers don't understand generics. Perhaps this is why Java still doesn't have generics. This is also why dynamic programming, where generics are a non-issue, is such a lure.

Hypothesis 2: The same goes for generics.

It is these language design decisions I want to explore.

Exactly my point.

Dan: It's not that I think people shouldn't do these things in C++. As I said, if I were using C++, I'd certainly be thrilled to have those tools, both conceptually and more concretely in the form of libraries built by Someone Else. I just think the ugliness of the tricks you have to do to get certain kinds of basically macro-like functionality (for example) is kind of a sad testament to the mismatch between the design of C++ and how (at least some) programmers want to use it.

I don't disagree with you at all about the levels of expertise. Look at Lisp, for example. Within a given project, certainly not everyone needs to know how to write macros, redefine the parser's behavior, add load-time eval hooks and so on. But some programmers do want to do those things, and their lives sure are a lot nicer in Lisp (one could argue) than in C++... That's all.

Java was designed to be "simple" not by driving simplicity to the core axioms, but by trimming pieces off here and there until the compiler writer had a handle on how to implement the language.

So while operator overloading is not per se a "dark art", to have included it in the original Java language would have blown wide open other holes in the complete definition and implementation.

Short cuts often aren't.

I believe firmly that C++ is a language for *experts* doing the most efficiency-critical kinds of applications, not for the average programmer doing average kinds of programs. This is why we have java and C#. If I don't need the fine-grained control that C++ offers for a particular project, I will use another language.

The problem is with reference vs. value semantics, and with handling assignments. These are two very specific language design issues. We mentioned both in the past.

The way C++ handles copy constructors (defualt and otherwise) is where the complexity begins.

As a former C++ expert, I find the thought of trying to regain my former intimacy with the language daunting, because I don't seem to be able to re-learn small pieces as I need them. I'm either a god-like library programmer or I'm not. Contrast that with Perl, where I have been able to explore one grody dark corner of expertise at a time, while remaining blissfully ignorant of all the many others.

Perhaps C++ development placed too much emphasis on ensuring that unused features wouldn't hurt performance, and not enough on ensuring that unused features wouldn't hurt programmers.

This is actually a very good example - a seemingly simple, or at least straightforward, feature with not so obvious implications:

1. Did you know that the reference feature was added to C++ because of operator overloading? I read this in Stroustrup's "The Design and Evolution of C++". After all, given the matrix sample in my previous post, had the arguments to the + operator been passed by value, it would have been way to inefficient. And writing:

C = &A + &B;

would have been to weird.

2. Some operators, e.g. ->, can be overloaded while others, e.g. . , cannot. The reasons for this are often far from obvious.

3. Some operators can be overloaded but shouldn't:

  A. The addressoff operator & can be overloaded, but this play havoc with STL.

  B. The binary logical operators when overloaded behave differently than the intrinsic operators because of C/C++ short-circuit logic evaluation.

4. The far from obvious Koenig Lookup was added to C++ because of the weird interactions between operator overloading and namespaces.

5. As Michael pointed out there is a distinction between the assignment operator and copy constructor, although both can use the = symbol.

6. Also as Michael mentioned, what should the assignment operator return: void? a reference? and const reference?

7. If a class implements += should/must it also implement + ? What about vies-versa? And if it implements + should/must it implement - ? And what about ++ and -- ? And if you do need to implement them all, why can't the compiler deduce them automatically (yes, I know the answer).

8. How do you differentiate between the definition of prefix ++ and postfix ++ (answer - using a dummy int argument)

9. Consider the following class definition:

class X {
...
operator int();
int operator()();
...
};

What is the difference between the two (this is from my old C++ Riddles page) ?

10. Why can't some overloaded operators be static while others can?

11. Overloaded operators can result in some not-so-obvious ambiguities.

And yet, it's quit obvious that if a class appropriatly implements operator overloading, things are easier for its users (see my std::string example).

Are these all really operators? Perhaps, the language design should be more careful aobut what is considered an operator and what isn't, so this qurestion wouldn't arise?

3. Some operators can be overloaded but shouldn't

Ditto.

The binary logical operators when overloaded behave differently than the intrinsic operators because of C/C++ short-circuit logic evaluation.

Let's compare this to Ada. In Ada "and" and "or" are operators and can be overloaded, "and then" and "or else", the short circut versions, are not overloadable operators. This is clear from the language stadnard, and the reason behind the decision should be clear to most programmers.

5. As Michael pointed out there is a distinction between the assignment operator and copy constructor, although both can use the = symbol.

Should assignment really be considered an operator, or is it really a statement? The complications from treating assignment as an operators are many and often quite subtle.

Again, in Ada for example, changing the meaning of assignment isn't done be overloading the operator symbol directly.

6. Also as Michael mentioned, what should the assignment operator return: void? a reference? and const reference?

See above.

7. If a class implements += should/must it also implement + ? What about vies-versa? And if it implements + should/must it implement - ? And what about ++ and -- ? And if you do need to implement them all, why can't the compiler deduce them automatically (yes, I know the answer).

Are all these operators really necessary and worth the complexity they add to the language?

In Ada the most similar issue would be handling inequality (/=) when equality (=) is overloaded. The rule is that if the overloaded equality function returns a Boolean value, inequality cannot be manually overloaded, and is automatically set to mean "not equal."

8. How do you differentiate between the definition of prefix ++ and postfix ++ (answer - using a dummy int argument)

Are these operators worth the confusion they cause? Not just here, but also where order of evaluation is considered.

I chose some specific issues, and tried to show that different design choices are possible. Some of them make overloading much simpler, in fact, mundane. Obviously, there are tradeoffs, and other things may become more complicated as a result.

The point is, language design is about deciding about many such details, and we should be able to identify the possible approaches, and analyze them individually and collectively.

Library designers should be more knowledgeable abour design techniques and have better design skills. Most of these skills should be easily trasferable between programming languages. At least languages based on the same paradigm and general approach (e.g., C++, Java, Ada, and C#).

Since this is LtU, I should perhaps be quick to add that there are several important techniques that are programming language dependent(e.g., Lisp macros). But these are more the excpetion than the rule.

For instance:

1. You have to support "chaining" assignment e.g. "a = b = c;". Therefore, when you overload assignment you MUST return a reference. If there were no chaining assignment then you could return void, and IMO the language would be superior. In other words, assignment should not return a value.

2. Supporting overloading of prefix and postfix ++ and -- is lame, as has been described. Frankly, I think having both forms of the operators is insanely stupid, since all it does is make code a tiny bit more concise, as well as less readable. I wish there were only one form (prefix is preferable, since then there would be no postfix operators) and I also wish ++ and -- didn't return values.

3. There shouldn't be any need for the "explicit" keyword. The only way to use a copy constructor would be by doing this:

Foo f(other_foo);

and not

Foo f = other_foo;

The latter would instead mean "create a new Foo using the default constructor and use the overloaded assignment operator to assign it the value of 'other_foo'". This is very inefficient, but it works fine with pointers:

Foo *f = some_function_returning_pointer_to_Foo();

The point is, there is no need for C++ to be quite as complex as it is (not to mention as it's going to be). Some of the complexity is justified, but much of it is just baggage. Maybe there's room for a new language that throws away the cruft and keeps the good stuff (and no, java and C# are not that language; they throw away too much).

I would rather spend my time learning broadly applicable esoterica than C++-specific esoterica. (Though I suppose `broadly applicable esoterica' is something of a contradiction in terms.)

Maybe there's room for a new language that throws away the cruft and keeps the good stuff

You can have garbage collection and explicit control over copying at the same time using some of the (experimental) languages founded on substructural logics like linear logic. Just because C++ lacks GC and doesn't know how to handle references and constants doesn't mean they are incompatible.

Because you can write code in C++ that would be much less efficient if written in other languages of a comparable abstraction level.

Is that the strongest reason for using C++ ?

I'm lost in admiration for the cleverness of compiler writers.
This byzantine language is transformed into efficient code! Think what they could achieve if they started out with something less compromised.

Not being that clever, there's more chance that the software will be efficient if I use a less-complicated language that helps me identify hot-spots and inefficient algorithms.

First, the -> operator is transitive! This is ostensibly in order to make it easier to create smart pointers. A smart pointer typically overrides its -> operator to return a pointer to the actual object. But the user usually wants -> to give them direct access to the object, not just a pointer to it. So C++ automatically calls operator -> as often as necessary, until it gets to a value that doesn't have a -> operator.

I'm not sure why references aren't a better solution to this problem. Maybe operator -> came before references?

Second, operators can be overloaded either within the class, or outside of it. For example, you can override the + operator within a class like this:

class Foo {
public:
    Foo operator +(const Foo &rhs);
}

Or you can override it outside of the class like this:

Foo operator +(const Foo &lhs, const Foo &rhs) {
   ...
}

The choice of whether to override in the class itself or not is almost completely a matter of style, until you decide that you want to be able to add objects of different types. For example:

Foo operator +(int i, const Foo &rhs) {
   ...
}

The above example must be declared outside the class, because the left-hand-side is an integer, and all binary operators declared inside a class take the class itself as the left-hand-side.

Sometimes you're forced to make the overloaded operator be outside of the class, but it needs to get access to the member variables of the class. In that case, you have two choices: you can declare the overloaded operator function to be a friend of the class, or if you're dealing with an associative binary operator, you can just swap the arguments (so that the class is on the left hand side), and delegate to the version which can be a member of the class.

There are even more subtleties that you have to consider when implicit conversions are thrown into the picture...

I think operator overloading in C++ is about halfway between language design and "normal" programming. This is what makes it scary to many programmers.

So with that said, while there are definite subtleties to modern C++ when the majority of its features are used, I'm basically glad that the features are there. On the other hand, the comment about the gradient between "ordinary" and "library" C++ code being incredibly steep is well-taken: I'm glad it's Alexandrescu and company doing the latter rather than me.

On the third hand, I haven't found it to be true that only EDG-based C++ compilers can compile Loki: current GCCs do, as does Codewarrior Pro 8.3. More recently, I understand that Visual C++ 7.1 does as well.

If you have the luxury of choosing a better language to accomplish your goals, by all means do so: I certainly do under such ideal conditions. But when handed a C++ project, I'll leverage available libraries for all they're worth, and that definitely includes Boost and Loki.

Sure, this is relevant for some of of issues we are discussing (e.g., do you really need i++ and ++i?). But not for all of them (e.g., binary methods and the class construct).

I think the problem is usually when you combine several otherwise attractive features, that don't play well with each other.

would C++ be a better language if it was not so heavily wed to the conceptual model of C? I think the answer is a big, resounding "YES"

Stoustrup was once asked if he regrets his choice to build C++ on top of C. His answer, as I recall, was that if C wasn't around he would have picked whichever other language was most popular at the time and build on top of it. Stoustrup's intention was to bring OOP (as he experienced it in Simula) to the masses, thus he was willing to pay the price. That is C++ is defined by its being built on top of an existing PL.

Let's compare this to Ada. In Ada "and" and "or" are operators and can be overloaded, "and then" and "or else", the short circuit versions, are not overloadable operators.

Alas, the lack of this distinction was inherited from C, as well as even worse stuff such as the variable declaration syntax (which Stoustrup considered changing to something like Java's but didn't).

Are all these operators really necessary and worth the complexity they add to the language? (referring to += et al)

A resounding yes. A + B returns a new object while A += B modifies A in place (a concept which is certainly familiar to LISP programmers). As a result += implementation is very different from + (sometimes + is implemented using +=). C++'s emphasis on performance means the programmer must tailor the implementation of each operator specifically.

Are these operators worth the confusion they cause? Not just here, but also where order of evaluation is considered.

It's true that in C operators ++ and -- were simply syntactic sugar for +=1 and -=1 respectively. In C++ they turned out to be a lot more useful. This is because they implement a generic increment and decrement methods for both numeric basic types (including pointers) and user-defined types that implement them, even when such type don't (and shouldn't) implement += and -= (esp. with a numeric argument). An example of this is iterators. Many STL algorithms are dependent on ++.

Supporting overloading of prefix and postfix ++ and -- is lame, as has been described.

The method used to differentiate between the overloading of prefix and postfix ++ and -- is indeed lame, or at least a hack, but again the distinction itself is useful. True, you can get by without postfix ++ and -- (which returns the previous value of its operand) but the ability to express this functionality in such a concise maner is IMO useful.

There shouldn't be any need for the "explicit" keyword.

From my experience the purpose of the explicit keyword is mainly to prevent inadvertent implicit type conversions. C++ type conversions, and especially the implicit kind is another topic which deserves a review, but that is beside the point.

I would rather spend my time learning broadly applicable esoterica than C++-specific esoterica.

Most C++ programmers get by without ever learning the C++-specific esoterica. Indeed much of this esoterica is prohibited by several companies style guides. OTOH C++ library developers can leverage this esoterica to create better, more usable and more efficient libraries. And since they get paid for this, its worth their time and effort (and I'm guessing several of them enjoy it).

The first thing you'd have to throw away is pointers/references and then add garbage collection - but then it wouldn't be C++ would it.

Indeed it would not. There are several third party GC libraries for C++, and of course their is C++.NET with its managed objects. But the whole point of C++ is the total control that you loose when you use GC. Just imagine real time software that must complete a specific operation in a specific number of cycles and then the GC kicks in ...

Some additional observations:

The main issue with operator overloading is, of course, design - that is knowing when to use them (and when not). For example, would you use the += or << operators to add members to a collection (I generally wouldn't which is why I dislike the use C# makes of += to connect delegates to event generators). Most C++ programmers don't use operator overloading because they don't want to but also because they don't need to. The exception to this rule, as Ehud correctly pointed out, is the assignment operator. Though the same syntax as general operator overloading is used, it's indeed a different kind of beast: 1. The compiler automatically generates an assignment operator for a user-defined class if the developer doesn't explicitly specify one. 2. The assignment operator, like constructors, isn't inherited. 3. While overloading the other operators is strictly optional, as I explained above, you often must overload the assignment operator in order to guarantee proper resource ownership (The Law of the Big Three). Unfortunately, properly implementing the assignment operator in C++ can be tricky because of self assignment, const issues, exception safety etc.

Finally there is an issue of performance in operator overloading, consider:

D = A + B + C;

The straightforward implementation would translate to the following sequence of operations:

temp = A + B;
D = temp + C;

That is two object creations, one object destruction and four content copies. Using template metaprogramming techniques its possible to provide an implementation that doesn't require the temporary object and thus results in only one object creation, no destruction and three copies. In fact I've written an article about this once.

And now back to your regularly scheduled LtU programming.

struct {int a; char b; bool c[10];}

template<int a,char b,bool c[10]> class c;

tuple<int,char,bool[10]>

void g(void) {int a; char b; bool c[10]; ..};

Spot the five completely different sets of grammar and semantics to represent the notion of "an integer, a character, and 10 booleans" in different contexts.

is there a c++ book that doesn't have such a chapter?!

C++, being multi-paradigmatic and sporting C roots, unavoidably allows this.

Still people stick with C++, and there a numerous reasons for this: gets the job done (better the devil you know), legacy software, supported on most every platform, direct access to OS services, connect to most any other PL, good development environments, lots and lots of libraries, frameworks and sample code, industry standard (nobody ever got fired for programming in C++), efficiency (or the perception of it), multi-paradigmatic (only as much OOP as you want).