The topics I'll be addressing are rather varied, including a lot of information about C++11 and C++14, the importance of CPU caches for software performance, general advice on interface design, plus some reflections on thinking about and writing "Effective" books.
You'll find details on all my upcoming presentations at my Upcoming Talks page, e.g., exact dates, locations, and topics. I think all the presentations will be fun, but let me call out two in particular:
- If you're interested in material from Effective Modern C++, the most comprehensive seminar I'll be giving on that topic will take place on October 7-8 in London.
- A special attraction of C++ and Beyond in Stuttgart is looking like it might be a full-blown bar brawl between me and Herb Sutter. In recent weeks, he and I have been going back and forth about the wisdom (or lack thereof) of advising people to use pass-by-value in function interfaces. We've exchanged some posts on this topic in comments on my blog and in posts to a Microsoft C++ MVP mailing list, plus there have been some behind-the-scenes email messages, and at this point, having carefully weighed all the facts, it looks like the only thing we fully agree on is that the other person means well, but is terribly misguided. Herb's German may be better than mine (it definitely is), but when it comes to parameter-passing advice, that boy is going down!
Scott
7 comments:
Could you state the precise positions on parameter passing that you and Herb currently have? The discussion in the comments on this blog kind of died off without a clear conclusion.
@Anonymous: Herb and I are still hashing things out (often in conjunction with input from others), and even in the past few days things have changed. There is, as yet, no clear conclusion. I know that Herb is eager to make his position clear when he's comfortable that it's stable, but my understanding is that it's still in flux. The core question is under what conditions it makes sense to pass parameters by value when you know that they will be unconditionally copied. The most recent piece of information we're processing is the observation that not all copy operations are created equal. In particular, copy construction may be more expensive than copy assignment, but it can also be the other way around, and that affects the analysis when lvalue arguments are passed. The full set of implications of that observation is something I think we're both trying to come to grips with. There is, as yet, no clear conclusion. At least I don't think there is.
The two people who have had the most influence on how I do my job over the last 20 years do not agree on one of the most fundamental aspect of that job! That's more than a little bit scary...
I read the whole thread carefully and it seemed to me that Herb's position at the end was that the performance implications should not be part of this discussion, that the proper style would be to pass by value and that passing by && should be mostly limited to special member functions of library types (and very rare every-cycle-counts situations). Are you saying he changed his mind and is now considering pass-by-&& to be worth using more widely? I would love to see the latest discussions!
@Stéphane Lajoie: Well, we're all learning, right? I don't want to put words in Herb's mouth, but I think a key argument for the "pass by value" approach has been that "the cost is only one additional cheap move." So performance has always been a consideration. What's recently become clear to us (though it was clear to others a while ago) is that when you pass lvalues, you may replace a copy assignment with a copy construction, and for some types, that can lead to a significant increase in the cost of making the copy.
My feeling--and again I'm not speaking for Herb--is that Herb is growing less enamored of the idea of pass by value. If that's how it pans out, that would make me happy, because I've never been a big fan of pass by value, anyway. But we'll see what happens.
This article really helped me visualize the issue: http://blogs.microsoft.co.il/sasha/2014/08/21/c-sink-parameter-passing/
Thanks for visiting us!
Question about vector of auto lambdas was fatiguing me..
auto l = [](int i) { return i ; }
std::vector v;
Compiles? Yes!... Useful? No :D
@Paweł Różański: It looks like part of your code got eaten by Blogger (sorry). Can you try again, this time using the HTML encodings for angle brackets? Either that or explain more fully what you think is not useful?
You can also email me directly, if you like: smeyers@aristeia.com.
Post a Comment