Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

C++ and Beyond 2012: Scott Meyers - Universal References in C++11

Download

Right click “Save as…”

Scott Meyers presents "Universal References in C++11". This was filmed at C++ and Beyond 2012. This is the full session in all of its splendor. Huge thanks to Scott for allowing C9 to provide this excellent C++11 content to the world.

From Scott's recently published article in the October 2012 edition of ACCU's Overload:

Given that rvalue references are declared using "&&", it seems reasonable to assume that the presence of "&&" in a type declaration indicates an rvalue reference. That is not the case:

Widget&& var1 = someWidget; // here, "&&" means rvalue reference

auto&& var2 = var1; // here, "&&" does not mean rvalue reference

template<typename T>

void f(std::vector<T>&& param); // here, "&&" means rvalue reference

template<typename T>

void f(T&& param); // here, "&&" does not mean rvalue reference

In this article, I describe the two meanings of "&&" in type declarations, explain how to tell them apart, and introduce new terminology that makes it possible to unambiguously communicate which meaning of "&&" is intended. Distinguishing the different meanings is important, because if you think "rvalue reference" whenever you see "&&" in a type declaration, you'll misread a lot of C++11 code.

Tune in. Scott's an incredible presenter and it's well worth your time to both read his article and watch his presentation on the subject. Great stuff!

Download slides

Tags:

Follow the Discussion

  • radiomanradioman

    jesus, t is now t'rex but it can be godzilla too...

  • I think the terminology "Universal Reference" should be standardized... Smiley

  • Wow. 

    I wish they add something like T# as an alias to DeducedT&& (aka universal ref). That's incredibely error prone!!!! 

     

    Hopefully only template library authors will get bald from this.

  • Looking forward immensely to watching this, enjoyed Scotts ACCU article.is there any chance Charles of publishing the titles and approximate 'airtimes' for subsequent C++ & Beyond 2012 talks? I'm keen to watch Andre's on performant code.

  • CharlesCharles Welcome Change

    @dot_tom: There are no specific dates to share. As I said in a previous post ( the last time you asked the same question Smiley ), it's more about timeframes (I have been instructed to release one post per month). Anyway... Here's what's coming in terms of specific pieces of content in no specific order...:

    Herb's sessions on C++11 Memory Model (two of them).
    Panel "Convincing your Boss (to use C++11 in production)".
    Herb's session on concurrency and parallelism.
    Andrei's session on Systematic Error Handling.
    Herb's session on the renewed meaning of __ and __ (you already know what one of the blanks is given the panel released last month....).

    C

  • Ben HansonBen Hanson

    The perfect topic for Scott to cover. And they say C++ is complex..!

    Looking forward to your book Scott.

  • Christian SemmlerChristian Semmler

    Thanks for publishing, can't wait for more :)

    Right after watching this I had to dive into some corners of my codebase and fix / improve stuff, thanks to this presentation.

  • MikeMike

    Please use internet standard video i.e. flash or html5. I'm not going to install Silverlight for a single video.

  • Justin Van HorneJustin Van Horne

    Mike, click "format" under the video and select HTML5.

  • CharlesCharles Welcome Change

    @Mike: Please actually look around the room before declaring the need for more chairs....

    Here, I'll help you.

    See the video player above? Great. Now, look to the right. See the links under Download? You can figure it out from here...

    Or, just click the format button to choose the format to play in the inline player.

    C

  • devcodexdevcodex SWGANH.com

    This video and the related ACCU article are both great and really have given me a lot to think of on this topic, it has clarified a number of issues and questions I've had working with && in my own code. Thanks Scott for giving the talk and allowing it to be shown on Channel 9 for those of us who couldn't be at the even and thanks to Charles for capturing it and getting it posted for us!

  • C64C64

    Thanks for sharing this video on C9.

    Scott seems clearly a master in C++: he knows the subject inside out. But to me these C++11 rvalue things seem very complicated.

    There are other C++11 features that help simplifying code, like using auto for iterators, or range based for loops, or lambdas (which play very well with STL and allow us to write simpler code instead of defining functors in contexts like remove_if(), etc.), but this rvalue argument is complex.

    It may be worth noting that some C++ programmers already find C++98 non-const lvalue reference confusing with their value syntax but pointer semantics (and in fact they prefer raw pointers T* to T&, like explained in Google's C++ Style Guide), but now with the addition of rvalues things got much more complicated.

    C++ code can already be complex, and it may be kind of scary to debug some complex C++ code with the addition of these universal references, rvalues and related rules (I sometimes think that these help [time 00:37:29] "Keeps people like me [Scott] in business" Smiley

    I'd like to watch some video or read some doc showing how rvalues can be used by the "practical" (non-language-lawyer) C++ programmer, or maybe rvalues are too much complex and remain in the domain of the language lawyers?

     

  • Ben HansonBen Hanson

    @C64:

    >Scott seems clearly a master in C++: he knows the subject inside out.
    >But to me this C++11 rvalue things seem very complicated.

    I must admit, every time I think I've got it I read something else which makes me feel like I've got to go back to square one! So far, I find that Scott's explanation is the clearest.

    >There are other C++11 features that help simplifying code,
    >like using auto for iterators, or range based for loops,
    >or lambdas (which play very well with STL and allow us to
    >write simpler code instead of defining functors in contexts
    >like remove_if(), etc.), but this rvalue argument is complex.

    Yes, no-one said rvalue references were easy.

    >It may be worth noting that some C++ programmers already find
    >C++98 non-const lvalue reference confusing with their value syntax

    There is no excuse for that. They should try harder.

    >but pointer semantics (and in fact they prefer raw pointers T* to T&,
    >like explained in Google's C++ Style Guide)

    Please don't quote the Google C++ Style Guide - it is totally boneheaded.

    >but now with the addition of rvalues things got much more complicated.

    Yes, things are definitely more complex!

    >C++ code can already be complex, and it may be kind of scary to
    >debug some complex C++ code with the addition of these
    >universal references, rvalues and related rules
    >(I sometimes think that these help [time 00:37:29]
    >"Keeps people like me [Scott] in business"

    Rvalue references do give you pause, I agree. I'm confident that things
    will get smoothed out over time however.

    >I'd like to watch some video or read some doc showing how rvalues
    >can be used by the "practical" (non-language-lawyer) C++ programmer,
    >or maybe rvalues are too much complex and remain in the
    >domain of the language lawyers?

    Hey, we are all language lawyers now! ;-) It is interesting to ponder where all of this will lead. As you point out, a lot of people thought C++98 was too complex already (but then the world is filled with lazy people :-D)

    In general, I view the attitude that every programming language "should be as easy as Visual Basic" as so much noise. It is clear that the future will likely only hold more complexity not less, and I find it ironic how much of modern computing is still stuck in the 1970s.

    There will always be a tension between appeasing beginners vs experts. The traditional line trotted out with the more complex C++ features is along the lines of "oh, don't worry about that, that's for library writers". There is resistance to that line these days - there seems to be a strong sense that C++ mustn't put beginners off by being over complex. This may well have it's roots in Bjarne's observation that C++ "had become too expert friendly" when he took up his lecturing position. We were all beginners once upon a time, so we should all therefore have sympathy with this view - however, this doesn't mean the future can be put on hold. Conversely, I would argue that it is advanced features and uncompromising performance that ultimately keeps C++ relevant.

  • C64C64

    @Ben Hanson:

    @C64:

    >but pointer semantics (and in fact they prefer raw pointers T* to T&,
    >like explained in Google's C++ Style Guide)

    Please don't quote the Google C++ Style Guide - it is totally boneheaded.

    While I don't agree with every point of that style guide, I respect that guide and I think great software was built using it (starting from the search engine used by billions of people worldwide).

    While with the help of Intellisense the reference parameters can be accepted, if you read plain source code I think having a form of syntax to specify at the call site that a parameter is going to be modified and a pointer is actually passed is a good point.

    >but now with the addition of rvalues things got much more complicated.

    Yes, things are definitely more complex!
    [...]
    Rvalue references do give you pause, I agree. I'm confident that things
    will get smoothed out over time however.

    I hope so Smiley

    In general, I view the attitude that every programming language "should be as easy as Visual Basic" as so much noise.

     

    I agree with you that we can't have super-easy programming languages; but I think that crossing some high-complexity line is not good.

    Keep in mind that code must be maintained, so its clarity is a very important point.

    For example, remaining in the domain of C++98/03, I think template metaprogramming kind of crossed an high-complexity line: writing, and especially maintaining and debugging template metaprogramming code is an highly complex (and error-prone) job,

    It is important to pay attention to not cross a "read-only/write-only complexity level". 

    [...] I would argue that it is advanced features and uncompromising performance that ultimately keeps C++ relevant.

    I think C++ gives very good performance and also offers good abstractions.

    But when, after benchmarking, we identify some hot spots and want to make the performance better, we can always use low-level pure C or even manually crafted assembly code in those particular cases.

     

  • Scott lost me almost as quickly as MSDN magazine does every time I try to read it. I have never seen && in c++ code.  I am not completely certain about rvalue and lvalue. The r and l stand for right and left side of the expression, right?   Other than that I am lost.

    Still do not understand why C++, with all the additions being throw at it, is retaining the #include header file thing. That is the aspect of the language that to me makes it difficult to use and structure your code files.

     

  • Ben HansonBen Hanson

    >While I don't agree with every point of that style guide,
    >I respect that guide and I think great software was built
    >using it (starting from the search engine used by billions
    >of people worldwide).

    I see this as a weak argument. After all, good products have been written in pure assembly. That doesn't mean we should all do it.

    >While with the help of Intellisense the reference parameters
    >can be accepted, if you read plain source code I think having
    >a form of syntax to specify at the call site that a parameter
    >is going to be modified and a pointer is actually passed
    >is a good point.

    This could easily degenerate into a rant about how not everyone uses vi and how it's the *21st century*, but seriously let's not even go there. I *do* see your point though.

    >I agree with you that we can't have super-easy
    >programming languages; but I think that crossing some
    >high-complexity line is not good.

    I agree that there surely is a threshold. Quite where it lies is debatable.

    >Keep in mind that code must be maintained, so its clarity
    >is a very important point.

    Sure, we've all maintained crappy code I'm sure.

    >For example, remaining in the domain of C++98/03,
    >I think template metaprogramming kind of crossed an
    >high-complexity line: writing, and especially
    >maintaining and debugging template metaprogramming
    >code is an highly complex (and error-prone) job

    I've not had the 'pleasure' of maintaining such code. I *have* however experienced maintaining 'pointer hell - C with classes' style code. In all fairness, I wouldn't want to maintain boost style MPL libraries!

    Any code can be hard to maintain if it's done badly. It's true that the more complex it is, the harder it can be, but that is surely true regardless of the techniques used. Obviously calculations done at compile time are that bit harder to debug, but then I've tried to debug opaque interfaces using QT and COM before and that can be just as unfathomable.

    >I think C++ gives very good performance and
    >also offers good abstractions.

    >But when, after benchmarking, we identify some hot spots
    >and want to make the performance better, we can always
    >use low-level pure C or even manually crafted assembly
    >code in those particular cases.

    And this is the best we can do in the 21st century? Your approach to C++ feels more and more like "C with classes". If that is the case, then we will simply have to agree to disagree.

  • Dr. Frank HeimesDrFGHde My relaxed face

    That talk really clarified a lot of things to me - thank you, Scott!

    I just wished the camera man hadn't swung the camera that much; but that was just a minor annoyance.

  • C64C64

    @Ben Hanson:


    >I agree with you that we can't have super-easy
    >programming languages; but I think that crossing some
    >high-complexity line is not good.

    I agree that there surely is a threshold. Quite where it lies is debatable.

    Yes, probably this is the key point Smiley

    >But when, after benchmarking, we identify some hot spots
    >and want to make the performance better, we can always
    >use low-level pure C or even manually crafted assembly
    >code in those particular cases.

    And this is the best we can do in the 21st century? Your approach to C++ feels more and more like "C with classes". If that is the case, then we will simply have to agree to disagree.

    I consider programming languages just as tools to solve problems, and if the assembly language is the best tool for the job in a particular case (e.g. top performance in some hot spot), I have nothing against it (and if in other cases the problem can be solved with Python, I can use it, etc.)

    As for my approach for C++, I like that we don't have to be language-lawyers to be productive with this language: we can choose a "safe" subset of it and use it. I don't know what you exactly mean with "C++ as C with classes"; I like using C++ classes, including the power of destructors, smart pointers (e.g. CComPtr is convenient to do COM programming), template for containers but not for template metaprogramming, etc.

    As I wrote in the beginning, there are convenient constructs in C++11, like auto, lambdas, etc. that can simplify the code. I think it's possible to use C++11 enjoying these convenient features and ignoring the more "obscure" parts.

  • CharlesCharles Welcome Change

    @C64: Did you watch the presentation? rvalue references - and universal references Smiley - are not "obscure" features of the language....

    You keep referring to features like auto or lambdas, but there's so much more to the language (like it has a memory model now....) and rvalue is a big deal.

    As Scott commented on the reddit/cpp thread ->

    "Rvalue references are a feature every professional C++ programmer is going to have to master. Even if you never use one in your code (highly unlikely, unless you don't write classes or don't care about efficiency), you'll still need to understand them in order to understand others' code. They are not a niche feature."

    C

  • The quality of information in this talk was almost at STL's level.  Impressive.

  • STLSTL

    SteveRichter> I have never seen && in c++ code.

    That's because it's new to C++11.

    > I am not completely certain about rvalue and lvalue. The r and l stand for right and left side of the expression, right?

    The lvalue/rvalue thing is indeed confusing at first (beginning with the fact that their names are terrible). http://blogs.msdn.com/b/vcblog/archive/2009/02/03/rvalue-references-c-0x-features-in-vc10-part-2.aspx was my original attempt at explaining this clearly, but WARNING - I wrote that a long time ago. While the stuff about what lvalues/rvalues are is still accurate, the rvalue references specification was changed several times before C++11 was finalized. So, the "rvalue references v1" described by my blog post are different from the v2 that was shipped in VC10, and the v3 that's specified by C++11.

    > Still do not understand why C++, with all the additions being throw at it, is retaining the #include header file thing.

    That's being worked on ("modules") for a future C++ Standard.

  • , STL wrote

     

    > Still do not understand why C++, with all the additions being throw at it, is retaining the #include header file thing.

    That's being worked on ("modules") for a future C++ Standard.

    I am really not a complainer, but I wish MSFT would just forge ahead and do modules on their own. From my recent experience with C++ it is very difficult to organize your code when you have to split things between .h and .cpp files. Esp when I bring my C# practices to a C++ project. Filters are not a substitute for C# folders.

    thanks for the explanations.

     

  • DmitryDmitry

    Great speech! Now everything seems simple and logical

  • VincentVincent

    The talk is great, and the concept of universal reference is a great one to understand better how things behave. It's kind of sad that the C++ committee solved perfect forwarding only when templates are used. If I have a class, say "Person", that I want to construct with "firstName", "middleName", "lastName" and "address", all as strings, I have to either write 16 constructors (since each variable could be either taken as an rvalue ref or a const lvalue ref) or a template function that takes any 4 arguments (all universal references as Scott Meyers would put it) but happens to compile only for strings (or at least only for things strings can be constructed from)...

    The committee probably looked at their own problems (make_shared, tuple, pair are all heavily templated) and changed the language to solve just that, it's kind of sad that I can't get perfect forwarding and universal references for my non templated code... After all, there is probably a lot more non template classes than there are template classes out there...

  • C64C64

    @Charles:Yes, I watched the presentation.

    If such a complex feature is going to be pervasive and is a must to be learned for C++ devs, I'm not sure that would be good for the language and its adoption.

    It used to be that in C++ we could pick features gradually, and be productive with the language without knowing every intricacy.

     

  • Ben HansonBen Hanson

    @C64:

    >If such a complex feature is going to be pervasive and
    >is a must to be learned for C++ devs, I'm not sure that
    >would be good for the language and its adoption.

    I await the reaction of industry with interest. It is true that anyone who thought that C++ was too complex already will hardly be thrilled with these new developments. But then that kind of person was probably unsuited to Modern C++ in the first place. There are solid reasons for introducing rvalue references into a 'by value' based language like C++. The complexity arises naturally out of those reasons. In the end, it's an entire way of thinking. If 'by reference' and garbage collection appeal more, there are other languages for that.

    >It used to be that in C++ we could pick features gradually,
    >and be productive with the language without knowing every intricacy.

    Do you find that policemen are getting younger too? ;-)

  • STLSTL

    Vincent> but happens to compile only for strings (or at least only for things strings can be constructed from)...

    Like const char *. In this case, perfect forwarding would be more efficient than (const string&), (string&&) overloads without a dedicated (const char *) overload.

    > it's kind of sad that I can't get perfect forwarding and universal references for my non templated code

    By definition, perfect forwarding takes arbitrary types and passes them along. Templates are how C++ works with arbitrary types.

  • CharlesCharles Welcome Change

    , C64 wrote

    @Charles:Yes, I watched the presentation.

    It used to be that in C++ we could pick features gradually, and be productive with the language without knowing every intricacy.

     

    Really? With C++, you're given very sharp knives to cut through computational complexity. As such, you need to learn how to use them wisely (and effectively). When has this not been the case for C++? Further, C++ is language that affords great efficiency and performance across the hardware spectrum and with high level modern programming abstractions. It doesn't provide these capabilities for free. Sometimes you need to really understand the tools you use to engineer software systems. C++11 certainly makes some things easier (so, the constructs you've mentioned already like auto, lambdas, and also automatic memory management via smart pointers, etc...).

    Scott did a great job in this presentation making things very clear.

    C

  • @Vincent: You have another option actually.  Write one constructor, taking all of your parameters by value, then move them where they need to be.  This may result in additional moves, but never additional copies (unless there is no move constructor, which is not the case for strings).

    Person(string f, string m, string l, string a)
        :firstName(move(f)),
         middleName(move(m)),
         lastName(move(l)),
         address(move(a))
    {}

  • IvanIvan

    For ppl confused with && STL has a great lecture series here on C9, in one of episodes he talks about use of RVR. Im kind of busy so I dont have time to pinpoint video now, but if you are interested I hope I provided you some help.

  • C64C64

    , Charles wrote

    [C64] It used to be that in C++ we could pick features gradually, and be productive with the language without knowing every intricacy.

    Really?

    Sure. Just an example: I use STL classes like std::vector and std::map, and I almost completely ignore template metaprogramming (things like std::enable_if, etc.). I don't know if inside STL implementation it is used, but as an STL client, I can just ignore it.

     

     

  • , C64 wrote

    *snip*

    Sure. Just an example: I use STL classes like std::vector and std::map, and I almost completely ignore template metaprogramming (things like std::enable_if, etc.). I don't know if inside STL implementation it is used, but as an STL client, I can just ignore it.

    You can ignore rvalue references as well, and your code will be as good as it was two years ago.  Better, infact.  Especially if you use the standard library.

    If you tend to write classes which just use default copy semantics, and rely on internal, well written members (from the standard library, for example) to copy themselves, then your classes will automatically have correct move semantics.  They will be, infact, better than they were before this feature existed, through no effort of your own.  This is, in my opinion, how almost all classes should be written anyway.

    If, however, you tend to write classes with specialized copy semantics, then your classes will be no worse than they were two years ago, and you can learn to use rvalue references at your own pace, when you feel like you want to supercharge your code.

  • , Charles wrote

    *snip*

    Really? With C++, you're given very sharp knives to cut through computational complexity. As such, you need to learn how to use them wisely (and effectively). When has this not been the case for C++? Further, C++ is language that affords great efficiency and performance across the hardware spectrum and with high level modern programming abstractions. ...

    See, I thought we simply needed a language to write efficient native code. Kind of like C with modern programming constructs like namespaces, classes, interfaces, extension methods, tuples, lambdas, collections, ...  To write large apps I will use C#.  For energy efficient, quick starting standalone apps give me a native language with a familiar syntax.

     

  • , SteveRichter wrote

    *snip*

    See, I thought we simply needed a language to write efficient native code. Kind of like C with modern programming constructs like namespaces, classes, interfaces, extension methods, tuples, lambdas, collections, ...  To write large apps I will use C#.  For energy efficient, quick starting standalone apps give me a native language with a familiar syntax.

    I think Charles may have gotten a little carried away. Watch Bjarne's presentation from Going Native 2012, "C++11 Style". He shows how strong abstractions can be built using C++11 that are clean and modern. Universal references, move semantics, etc don't generally come into play until you're ready to nitpick and really push the performance of your code. A fully conforming compiler will generate move constructor/assignment operator for you, so if your class is trivially movable, it will be. Watching this video, which in my opinion applies more to a library developer (or someone who wishes to more fully understand a library), then stating that the language is too complicated seems silly to me.


    You can watch a video on how the internals of a combustion motor work, but it still takes just two (or three) pedals and a steering wheel to drive. Not everyone needs to build a motor to commute to work.

  • CharlesCharles Welcome Change

    , bkuhns wrote

    *snip*

    I think Charles may have gotten a little carried away.

    Really? Me? Smiley

    Yes, you can use much of C++11 without understanding how any of it is implemented. This doesn't mean universal references are an obtuse topic. This is an advanced topic, but not so advanced that it should be ignored. After all, this move semantics stuff is also a part of C++11.....

    C

  • , bkuhns wrote

    *snip*

    Watch Bjarne's presentation from Going Native 2012, "C++11 Style". He shows how strong abstractions can be built using C++11 that are clean and modern.

     

    Well, I doubt I will find a satisfactory way to organize my C++ code because I have to code in both .h and .cpp files. I like the way my C# code is organized with each class in a .cs file and those files are in folders organized along namespace lines. I like being able to return Tuples from C# methods and adding extension methods. Granted these are my little tics, but it still makes a lot of sense to me that the native language used by MSFT should be as similar to C# as possible and focused on doing what you need a native language to do - run with low overhead.

  • STLSTL

    I'm confused, because C++ has tuples.  They were added in TR1 (VC9 SP1) and further refined during C++0x's development (VC10) until they reached their final form in C++11 (VC11, although we're still using faux variadics).

    It is true that ISO C++ doesn't have modules or extension methods, but it is awesome at tuples.

  • , STL wrote

    but it is awesome at tuples.

    neat. thanks!

     

  • VincentVincent

    STL> By definition, perfect forwarding takes arbitrary types and passes them along. Templates are how C++ works with arbitrary types.

    That's an odd definition of perfect forwarding, isnt it? I think the important thing about perfect forwarding is that the parameters are forwarded, not really that they are of arbitrary types...

    Let's pretend the language supported universal references for non templates. Say for example that we had &&& as a new reference type such that if you have a function

    void f(MyClass&&& t) { g(forward<MyClass>(t)); }

    the compiler compiles this as if the code were

    template <class T>
    typename enable_if<is_same<string, typename remove_reference<T>::type>::value, void>::type f(T&& t)
    { g(forward<T>(t)); }

    I would still call this perfect forwarding (I'm speaking about the original code where there is no arbitrary types deduction)

  • , Charles wrote

    This is an advanced topic, but not so advanced that it should be ignored. After all, this move semantics stuff is also a part of C++11.....

    I completely agree. I know personally a handful of developers who are using C++11 features, yet don't fully understand rvalue references yet, and especially not the concept of "universal references". They're still taking advantage of STL's move-supported containers, they're moving unique_ptrs around, etc. So although important, the material in this video isn't required learning in order to make use of C++11 (though it most certainly wouldn't hurt).

  • SteveRichter wrote

    Well, I doubt I will find a satisfactory way to organize my C++ code because I have to code in both .h and .cpp files. I like the way my C# code is organized with each class in a .cs file and those files are in folders organized along namespace lines.

    The cpp/h files issue was my biggest gripe when moving to a project in C++ at work. I've since gotten over it, and use an extension to Visual Studio which makes it incredibly easy to work with the two files. That said, header files themselves are a great way to glean the interface of an object (granted, modern IDE's do this for Java/C# with "outline" views anyway); so they're not all bad. As @STL has alluded to, the standards body is making headway toward modules which will ideally rid most of the headaches of dealing with header files. Headers aren't great, but they're certainly not a reason enough to ignore C++, IMO.

    I like being able to return Tuples from C# methods and adding extension methods.

    As STL pointed out, tuples are well supported in C++(11). As for extension methods, C++ isn't locked into the OOP paradigm like C#/Java, so it has something close (albeit syntactically distinct): non-member functions.

    http://pastebin.com/TE4BgKNi

    So, you can build non-member functions that act on an object, effectively "extending" it's behavioral methods. Bjarne actually suggests preferring non-members for any function that doesn't maintain the "invariance" of an object [1]. This is a bit of a programmer mindset issue, however, that I don't think will see a whole lot of adoption. One solution would be to borrow D's "Uniform Function Call Syntax" [2].

    it still makes a lot of sense to me that the native language used by MSFT should be as similar to C# as possible

    I disagree. C# and C++ are different languages for different purposes. If anything, it would be a better approach for MSFT to make a more concerted effort toward a native-only compilation option for C# built for WinRT.

     

    [1] http://www.artima.com/intv/goldilocks4.html

    [2] http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394

  • CyttorakCyttorak

    I would appreciate to have a link to download slides without need to login :(

  • CharlesCharles Welcome Change

    @Cyttorak: You don't have to sign in.

  • AndreyAndrey

    God save my mind!

  • passerbypasserby

    Great presentation! Scott is meticulous in all details as usual. Yet, I think he missed a use case saying that universal references (perfect forwarding) only occurs in deduceable context, and otherwise 'foo(T&&)' means rvalue reference. There is a stable idiom (AXE parser uses it everywhere), where this expression being used in a non-deduceable context actually means perfect forwarding, not an rvalue reference. Like this:

    template <class T>
    struct A
    {
    T t;
    A(T&& t) : t(std::forward<T>(t)) {}
    };
    template <class T>
    A<T> make(T&& t) { return A<T>(std::forward<T>(t)); }

    Here is a bigger example: http://ideone.com/WL4txa

  • Scott MeyersScott Meyers

    @passerby: I'd actually say that your example involves an rvalue reference where reference collapsing is taking place, but your point is certainly valid.

    My fundamental concern is that saying that "T&&" means rvalue reference makes code harder to understand, though of course it is technically accurate (as I hope I make clear in the talk). I increasingly think that the notion of universal references is useful only in the case of function templates and auto, and all the other cases are best handled by applying the reference-collapsing rules. The implementation of A's constructor looks very strange to me, but as long as the reader understands that it's completely normal for A to be instantiated with an lvalue reference, all is clear. I don't think that calling A::A's parameter a universal reference helps here. Instead, as I said, I think the best way to understand what's going on is to understand and apply the reference-collapsing rules in the context of a template whose parameter is itself provided by applying std::forward to a universal reference.

    Scott

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.