CppCon 2017: Nicolai Josuttis “The Nightmare of Move Semantics for Trivial Classes”

Поделиться
HTML-код
  • Опубликовано: 16 янв 2025

Комментарии • 144

  • @bobbymah2682
    @bobbymah2682 7 лет назад +65

    I can always count on Nicolai to present relatively new C++ constructs in a clear, concise, and idiomatic fashion

  • @ChronosSk
    @ChronosSk 3 года назад +30

    Well, I would argue for the pass-by-value-then-move option: It expresses the idea fairly simply, while giving the compiler everything it needs to optimize away the overhead. "Everything should be made as simple as possible, but not simpler."

  • @jplflyer
    @jplflyer 4 года назад +20

    This was truly frightening.

  • @canberksonmez3146
    @canberksonmez3146 6 лет назад +35

    That's a very good presentation after all. It summarizes many things regarding pass-by-value and pass-by-reference techniques, and clearly describes the mentioned problems. I like it.

    • @MirrorsEdgeGamer01
      @MirrorsEdgeGamer01 3 года назад +1

      Yes, at uni they told us to pass by reference; I now see how wrong they were.

    • @phusicus_404
      @phusicus_404 10 месяцев назад

      ​@@MirrorsEdgeGamer01Only if you don't need a copy in memory or the value mustn't change. Yeah.

  • @sprytnychomik
    @sprytnychomik 3 года назад +43

    Question: How many mallocs does X require.
    C++ programmer: Four! No, two! No, six! Wait... it depends.
    C programmer: How many do you want?

  • @pyajudeme9245
    @pyajudeme9245 Месяц назад

    0:30 "I should point out that I always write because I don't understand C++". This is actually one of the best quotes ever. If you want to learn something, teach it. That worked for me in Java, Python, German and Portuguese grammar. And the best thing: you get paid while you are learning :)

  • @martinkutny8026
    @martinkutny8026 7 лет назад +35

    The person from the audience at 48:43 pointed out the only intelligent solution in this whole presentation - make members public and use aggregate initialization. That will do the right thing and generate optimal code in all cases while saving you from the forwarding constructor insanity. I honestly don't understand the sarcastic reaction from the presenter.

    • @joshodom9046
      @joshodom9046 7 лет назад +16

      Because you lose encapsulation. Theoretically it should be fine, as long as nobody abuses the fact that your private members are public, but it's no longer enforceable by the compiler.
      Encapsulation might not matter in this particular class, but the chosen technique should work for complicated classes as well.

    • @martinkutny8026
      @martinkutny8026 7 лет назад +16

      It's a wrong example. Encapsulation brings no advantage here. But people might (and many will) get the wrong impression that this is universally the right thing to do
      and will emulate this in their code. If encapsulation is really what you need, you could use property-based or builder approach. You'll get the same result with respect to number of creates / copies / moves, but much better API design and readability.
      Language trickery such as this, are one of the prime reasons C++ gets the bad reputation of a super-complex language (which it really is). But your code does not have to be like that. Nothing wrong with this as an exercise and a conference is a good place to discuss things like this. But the presenter should not give off the impression, that this is the normal and recommended thing to do in day-to-day production code.

    • @joshodom9046
      @joshodom9046 7 лет назад +7

      For this specific class, I agree that encapsulation buys you nothing.
      Correct me if I'm wrong, but if you write a builder or setters, I believe you have to make the same decision as he showed with the constructor.
      I personally got the impression that he was just exploring nuances of the language, not recommending that you write all constructors with template madness, but I guess he could have mentioned it at least once. At the end of the talk, he did recommend the approach of pass-by-value with move construction.
      One thing I think he should have mentioned is that he's really talking about worst-case compiler guarantees, not about the actual performance of code compiled under optimized settings. I believe all shown constructors would be compiled to identical machine instructions, which further supports pass-by-value with move construction.
      I'm not a c++ expert, and I'm writing a chess engine in it (where performance is proportional to engine strength), so knowing techniques that will help the compiler create optimized machine code is what's really useful for me, moreso than worst case guarantees. Regardless, this talk did help me understand the language a bit better.

    • @martinkutny8026
      @martinkutny8026 6 лет назад +5

      With property-based builder you would have to write a copy setter and a move setter (or just one templated forwarding setter) for each member. That is some boilerplate code. But dealing with one member at a time, you will at least be spared from the combinatorial explosion of passing multiple / optional arguments and need no SFINAE hacks.
      You are right about the optimizations. Compilers nowadays can eliminate a lot of unnecessary copying. But such optimizations before C++17 were only at the discretion of compiler implementers. Whether a particular instance of a copy/move will be optimized out depends on the C++ standard level, the level of implementation of said standard in the compiler, compiler flags. I mean, good luck telling just by looking at the source code, whether a particular copy will be optimized out or not.
      If this presentation proved anything, it is that in C++ you can do object-oriented OR zero-overhead OR readable code. But you can pick only 2 out of 3. You need to choose what is more important in your context. I usualy prefer zero-overhead AND readable. But sometimes OO is required (e.g. by corporate coding style) and then I opt for OO AND readable at the cost of possibly some overhead.

  • @Victarus
    @Victarus 6 лет назад +34

    Some good information, but I fell like the "Haha, isn't C++ awful?" stuff is uncalled for when the example code is contrived in such a way to emphasize edge/expert cases. The solution at 13:25 (pass by value and use std::move) is simple, straightforward, and provides the optimal performance the talk is supposedly aiming at; everything else is just a tangent about argument forwarding (passing the `const char*` into `std::string` without creating a temporary), and non-explicit constructors with default arguments (the issues with `Cust c = ...;`). Since it's never presented as such though, it makes it look like this really straightforward thing (using move semantics to improve performance) is a huge mess because these other interface issues are being thrown on top of that.
    Worse still though, even those things thrown into the mix, the straightforward solution at 13:25 _still works perfectly_ for the example given: It creates a special case for the one-argument const char* constructor (which is self-inflicted by the issues above), but it works, is easy to read/write, and is super straightforward. Going into templates is just overkill for its own sake without even an acknowledgement that no, this is completely unnecessary, and requiring this sort of thing in a real-world environment _probably_ indicates something wrong with your design.

    • @spacechild2
      @spacechild2 5 лет назад +3

      In the summary at 52:06 he says that he would actually recommend pass by value + std::move because it's good enough and easy to reason about.

  • @27182818284590452354
    @27182818284590452354 7 лет назад +85

    "And the rest of you? Do you hate C++?" Well, after watching the horrible mess just before that, kinda.

    • @homomorphic
      @homomorphic 4 года назад +7

      It's not a terrible mess. It covers details that you simply can't control in other languages at all. Sometimes another languages implementation might do the right thing for a particular case and sometimes it might not, but in C++ you can always control it (if somewhat awkwardly). As Nicolai explains here, if you use value semantics with move, then you will match or exceed the performance of other languages 99% of the time and if you go to template instantiation control you can beat those other languages for the 1% of the time where it matters.
      So if you make your life complicated unnecessarily with C++ that's on you, because you don't have to.

    • @slyfox3333
      @slyfox3333 8 месяцев назад

      @@homomorphic Not even true. In rust its trivial to do this.

  • @tohopes
    @tohopes 7 лет назад +9

    Consider skipping to 17:00 if the earlier stuff seems too repetitive.

  • @grostig
    @grostig 7 лет назад +12

    Very humorous, enjoyed it.

  • @LordNezghul
    @LordNezghul 7 лет назад +8

    You cannot move your template constructors to other compilation unit, so you let everything visible by compiler so it can use optimizations. If compiler can see everything and use optimizations then just use pass-by-value. But if you want to move your constructors to other compilation unit and maybe even use pimpl idiom for ABI compatibility then for best performance you have to write multiple constructors.

  • @michal.gawron
    @michal.gawron 7 лет назад +18

    23:15 By compiler's vote, gcc and clang are right. ;-)

    • @michal.gawron
      @michal.gawron 7 лет назад

      DemonLordChaos By what? ;-)

    • @hansiraber
      @hansiraber 7 лет назад +1

      en.wikipedia.org/wiki/Myth_of_the_flat_Earth

  • @deltarambo6230
    @deltarambo6230 4 года назад +1

    There is a mistake in the slides at 46:10 that is the number of moves in the second version, which should be 7 moves instead of 5 moves. If you don't believe me, then go back to the slides at 15:45 and count the number of moves yourself.

  • @mcbernnard4303
    @mcbernnard4303 7 лет назад +9

    I hope C++20 will have a cool feature that a programmer can say hey compiler give me a lollipop.

  • @nileshkkulkarni
    @nileshkkulkarni 6 лет назад +5

    Mind blowing ..... wow..... mindddaaaaaa blooooowwwwwinnnnngggggggg......
    This is exactly what I was looking out for. I am so much thankful to you Nicolai. WOW!

  • @DavidRomigJr
    @DavidRomigJr Месяц назад

    I really enjoyed this presentation.

  • @hervealexanian2684
    @hervealexanian2684 5 лет назад +6

    I am such a nerd I had more fun watching this than most comedy routines

  • @NXTangl
    @NXTangl 5 лет назад +13

    When he said that the arrayness of the arguments didn't decay I went "Oh _god_."
    Because that means every length of string literal bloats the binary for no good reason. If there is any nontrivial action in your perfect forwarding constructor...

  • @SuperBorisl
    @SuperBorisl 4 года назад +3

    Great talk, thank you Nico!! May I ask is there any video of second part of move semantics by Nico on that conference? Anyone?? To be honest Nico was one of my favorite authors since ever.

    • @vesk4000
      @vesk4000 Год назад

      Yeah, I'd love to see that too

  • @xavierthomas1980
    @xavierthomas1980 7 лет назад +8

    9:00 Missing the ending double-quote for sting literal "nico"

  • @jankodedic3130
    @jankodedic3130 7 лет назад +6

    Why should initializing Cust (Base) with VIP (Derived) be valid? If VIP had any additional data members, wouldn't they be sliced? Shouldn't it just be: Derived is a Base, but Base isn't Derived??

    • @MSheepdog
      @MSheepdog 7 лет назад +3

      If you had a function taking is a Cust and only needing to look at it's members, then initialising one from VIP is fine. The only problem case would be if you tried to cast your Cust into a VIP since it wouldn't have those members.

  • @dirtbikersteve
    @dirtbikersteve 7 лет назад +2

    24:00 you have to use std::decay i think?

  • @mand7993
    @mand7993 6 лет назад

    Correct me if I'm wrong - it doesn't matter how you receive it, by const reference or by const pointer, the initialization first(f) and last(l) will create copy. So eventually we have 4 mallocs, not 2
    char* c = new char[5]{};
    c[0] = '1';
    c[1] = '2';
    c[2] = '3';
    c[3] = '4';
    std::string a(c); // copying
    delete c;
    std::cout

  • @samolisov
    @samolisov 2 года назад +1

    36:30 I cannot get why does VIP v2{v1} work when we used !std::is_same_v for SFINAE. VIP is not the same as Cust and we should face with the same problem with the copy constructor as before, shouldn't we?

  • @benoitrousseau4137
    @benoitrousseau4137 7 лет назад +7

    This talk was very interesting.

  • @teranyan
    @teranyan 3 года назад +5

    The reality is that C style string pointers simply don't belong in a modern software base written in C++. Just use std::string or make your own string class and always enforce that. You are basically fighting a needless battle of trying to account for all permutations of c++ strings and c strings when you don't need to do that in the first place.

    • @janisir4529
      @janisir4529 2 года назад

      const char * = fast

    • @ultradude5410
      @ultradude5410 2 года назад

      Yeah, but literals though
      Can’t get away

    • @zoltankurti
      @zoltankurti Год назад

      Gotta love including dozens of kloc code to get an expanding char array.

  • @ColorfirePluma
    @ColorfirePluma 6 лет назад +1

    On my machine, using MSVS 19.1030324, adding the line "using customer::customer" makes "VIP v{"Boss"};" fail to compile, citing ambiguous constructor.

    • @7xr1e20ln8
      @7xr1e20ln8 5 лет назад +2

      Of course. Boss is never a VIP. It's done the right thing.

  • @rabingajmer3293
    @rabingajmer3293 2 года назад

    Moving an aggregate class containing rvalue/lvalue references members as function parameters??

  • @Cromius771
    @Cromius771 4 года назад +2

    What if he added Cust(Cust& cust) = default; ?

  • @Ethanmoe
    @Ethanmoe Год назад

    Why not use string_view?

  • @ryannicholl8661
    @ryannicholl8661 5 лет назад +4

    Microsoft is correct here. It should be const char *& not const char *, because you make a non-universal reference i.e. a rvalue reference to a const char *&& (non-forwarding)

  • @manofacertainrage856
    @manofacertainrage856 6 лет назад +1

    The punchline for C++17 is at 41:03

  • @SuperToughnut
    @SuperToughnut 7 лет назад +26

    I was thinking about writing some c++ code again but this video depressed me. This kind of talk should never be necessary.
    C++ doesn't have to be challenging. However, in the process of trying to make it better, the governor's of c++ have made it more confusing.
    I want to write code to get work done. But because c++ has to carry the baggage of legacy c++ for backwards compatibility we all suffer.
    No one is going to rewrite legacy code and new code in the same project should probably follow the pattern of the legacy code (if it's written well).

    • @videogamer24385
      @videogamer24385 7 лет назад +11

      Except this kind of talk is kind of geared towards library writers and more "This is what's going on under the hood of the standard library". If you *really* need enable_if_t and other type trait helpers in regular application code to do relatively simple things, you probably are doing something wrong.

    • @SonicFan535
      @SonicFan535 6 лет назад +14

      The #1 takeaway of this talk for most people should be to just pass by value (and move into the members) in your constructors 99% of the time. It's easy to write and despite not being 100% "perfect" (a couple of unnecessary moves) it's still way better than the default solution you would get in any other language. You don't have to delve into the confusing parts of C++'s move semantics and enable_if as long as you're not trying to author some kind of extremely low-overhead library.

    • @X_Baron
      @X_Baron 6 лет назад

      His "customer" class example in the slides is misleading. Later on it becomes clear that he is talking about the Standard Library.

    • @bonbonpony
      @bonbonpony 6 лет назад +3

      Library writers? Really? So a simple Customer class is now a library thing and not client code?

    • @SonicFan535
      @SonicFan535 6 лет назад +6

      Bon Bon If the customer class doesn't need to construct with absolutely 0 overhead in every single use case, the simple thing to do in client code would be to just write the constructor in the one way that is almost always good enough: Cust( std::string first, std::string last = "", int id = 0 ): first( std::move( first ) ), last( std::move( last ) ), id( id ) {}

  • @DFsdf3443d
    @DFsdf3443d 6 лет назад

    14:46 but aren't the "Joe" and "Fix" literals copied in to the constructor arguments f and l before they are moved?
    So 2 mallocs when they are created and then 2 when they are copied and then 2 moves ?

    • @oktal3700
      @oktal3700 6 лет назад

      The constructor std::string::string(const char *) will obtain the length of the literal, call malloc() to allocate a buffer at least as big as that, and copy the characters into that buffer. So it mallocs once per string argument.

  • @MatkatMusic
    @MatkatMusic 6 лет назад +2

    before watching this, I watched Herb Sutter's talk "Back To Basics: Essentials of Modern C++ Style" from CppCon 2014, where he explains how to choose the right solution for a constructor that involves std::string. ruclips.net/video/xnqTKD8uD64/видео.html is herb's talk.

  • @homomorphic
    @homomorphic 4 года назад +7

    Any good engineer will trade off clarity and simplicity against performance. There may be times when performance supercedes clarity and simplicity, but in practice, that's not very often. the language must allow for the latter case, but the programmer is responsible to make the trade-off appropriately for the use case.
    I enjoyed this talk.

    • @gzozulin
      @gzozulin 2 года назад +2

      C Programming Language = clarity and simplicity AND performance

  • @LemonChieff
    @LemonChieff 5 лет назад +4

    I'd use pass by value and move (which should really be implicit and guaranteed where it is possible and efficient [ie: for common cases such as in constructors]) and avoid defaulted arguments.
    In fact google strictly forbids it. I think efficient code should be idiomatic and simple.
    If it's not then it's a bug in the language. And I'm not coding around a language, it's too painful.

  • @justinlink1616
    @justinlink1616 Год назад

    A good number of the problems observed here are also avoided if default parameters are not used. (And of course I now see that that is mentioned at the end.)

  • @rajaravivarmar
    @rajaravivarmar 6 лет назад +5

    This is depressing. All I could say is, make it a standard to guarantee that the compiler will construct it in place if it an object is constructed out of a temporary.

  • @tamikanomara1687
    @tamikanomara1687 6 лет назад +4

    There must be words about code bloat, instructions cache and inlining... Did I miss it?

  • @a_ij6269
    @a_ij6269 6 лет назад +5

    a) why do you have to support any possible string representation in the first place?
    b) why not use method overloading for the 1 argument case? instead of sfinae + default args
    c) if you have to support all cases why not use a builder pattern.
    i don't see the point. the stuff i have to do in java is much worse

    • @gumo77
      @gumo77 4 года назад +2

      b) Exactly. Default arguments are a C legacy, and they don't belong to OO code. If you want to call the constructor with 3 different signatures, you just specify 3 different constructors. And your problems suddenly go away.

  • @harshtiwari9588
    @harshtiwari9588 6 лет назад +2

    I like this person! He is a good narrator.

  • @super_cyb0rg226
    @super_cyb0rg226 6 лет назад +3

    I had this on as white noise while at work. Wasn't really paying attention. Then I looked over when the video hit 12:30, and I nearly threw up at my desk. That is disgusting...

  • @DarkLevis
    @DarkLevis 7 лет назад

    How come creating a string cause a malloc?

    • @arthur.passos
      @arthur.passos 6 лет назад +15

      oh boy...

    • @StanleyPinchak
      @StanleyPinchak 5 лет назад +7

      A string might be the concatenation of other strings, or may take input from the user, a file or network I/O. How can you know the length at compile time of all possible contents for a string. Since you can not, the string class must be able to dynamically allocate storage from the heap or other memory pool.

  • @raidenluikang5532
    @raidenluikang5532 Год назад +1

    Just use struct Cust{ std::string first, second; int id; }; without constructor, and initialize it as { "Joe", "Fix", 42 } :)

  • @HtS643KyS6555GxQ3edA
    @HtS643KyS6555GxQ3edA 4 года назад

    I love that C++ std library book.

  • @NXTangl
    @NXTangl 5 лет назад +6

    Why were the first four minutes of a C++ talk a long argument for Rust?

    • @askeladden450
      @askeladden450 2 года назад

      I'm not experienced in rust at all, but how does rust solve this issue?

    • @NXTangl
      @NXTangl Год назад

      ​@@askeladden450 a bit late but: in Rust the issue simply would not arise. Everything moves, so you would simply take the strings by value, and if you don't want to transfer ownership you would simply call `s.clone()` (which actually implicitly calls `Clone::clone(&s)` via Rust's trait-based overloading.)

  • @TheD4T4
    @TheD4T4 7 лет назад +1

    strlen overheat for constant literals with known size wasn't covered. Also, as pointed out somewhere in comments, you get only weak exception guaranties, but can achieve strong without runtime overheat

  • @Spiderboydk
    @Spiderboydk 3 года назад +2

    This is a good example of why I switched from C++ to C. Less effort on language BS means more effort on real problem solving. :-)

    • @godDIEmanLIVE
      @godDIEmanLIVE 2 года назад +1

      Problem with that argument is, you can just write what you would write in C in C++. From a purely technical stand point, C as a language is completely obsolete.

  • @boltactionpiano7365
    @boltactionpiano7365 4 года назад +2

    Constructor(string& value)

  • @leshommesdupilly
    @leshommesdupilly 2 года назад +1

    Omg ! I get it !
    I just don’t have to care about having too much mallocs !

    • @leshommesdupilly
      @leshommesdupilly 2 года назад

      Just have to upgrade my cpu to don’t care anymore !

    • @panjak323
      @panjak323 Год назад

      Imagine doing this with very large array eg 4k image with 32MB of data. Just for creating a object you have to allocate and deallocate 128MB of memory. Now imagine having multiple images.

  • @masheroz
    @masheroz 2 года назад

    The second version is the best. It is the simplest that doesn't require extravagant code. Any move from this to the templated code would need to be backed up by performance testing.

  • @HowtodoSys
    @HowtodoSys 6 лет назад +1

    Please how much it cost your book about templates

  • @OLEGUBAN
    @OLEGUBAN 7 лет назад +3

    Why not just use "Cust(std::string f, std::string l, int i) : first(f), last(l), id(i) {}" and let the compiler figure out that it's ok to move rather than copy both arguments in this particular case? The simple task of passing a couple strings to a constructor must be simple. The "std::move()" solution looks like a winner when contrasted to the horrible "enable_if" / "requires" solution, but both solutions are equally horrible when compared to "first(f), last(l)".

    • @Aidiakapi
      @Aidiakapi 7 лет назад +1

      Oleg Gubanov He covers that in the video. It's on the slide "passing by value".

    • @MSheepdog
      @MSheepdog 7 лет назад +1

      " and let the compiler figure out that it's ok to move rather than copy both arguments in this particular case"
      The problem is the compiler might not figure that out, especially if you're running in a debug build which you don't want to be slow just because you were too lazy to write the moves yourself.

    • @OLEGUBAN
      @OLEGUBAN 7 лет назад +2

      It's not that I'm lazy. Consider students and majority of developers. They have to be taught the accidental complexity of `std::move` (including the fact that it does not actually move anything) and r-value references - all just to pass a couple of strings to a constructor without unnecessary performance loss. Compiler seems to be the only place where that accidental complexity can be dealt with, letting the developer focus on the essential complexity of the task at hand.

    • @agudo2007
      @agudo2007 7 лет назад

      Mr. Oleg Gubanov: the compiler can not transform the copy constructions in the source code to moves. The copy constructions have a potential side effect of allocations. Getting maximum performance is tricky, what I see some comments here miss is that C++ is just about the only language that lets you try for maximum performance. If you don’t like the complications of maximum performance, then use C++ in a more straight forward way

    • @Aidiakapi
      @Aidiakapi 7 лет назад +2

      agudo2007 To be completely fair here, the standard *does* permit the compiler to omit the copies or turn them into moves in certain cases. (Notably for return values.)
      This is one of the few (if not only) optimization which is allowed to change the behavior of the program. One compiler might opt for a copy, whereas another might move or do nothing at all.

  • @IllumTheMessage
    @IllumTheMessage 7 лет назад +1

    Good stuff.

  • @carlschumann
    @carlschumann 3 года назад

    And the winner is Java? 🧐

  • @sixjac
    @sixjac 5 лет назад +1

    Don't make C++ 20 full stop and get rid of C++17, you are fucking up the language, it is MEANT to be complicated! You are changing too much shit.

  • @YourCRTube
    @YourCRTube 7 лет назад +2

    A practical solution is to use ref-counted strings, either immutable or copy-on-write and pass by const reference. Strings are too small and too widely used to micro mange their creation and destruction manually, but too expensive to copy to be used by value and not to care.

  • @finn2001
    @finn2001 3 года назад

    I used c++ 1998-1999, looks like am better staying Java.

  • @KilgoreTroutAsf
    @KilgoreTroutAsf 5 лет назад +10

    Great job!
    I hate C++ now.

  • @halbesbyte
    @halbesbyte 7 лет назад +1

    Why not just use Cust(std::string f, std::string l, int i) : first(std::move(f)), last(std::move(l)), id(i) {} ?
    Arguments are passed by value, which means they are moved if rvalues references are passed: else copied.

    • @OLEGUBAN
      @OLEGUBAN 7 лет назад +9

      This is exactly what the author recommends to use when he summarizes his talk

    • @XiremaXesirin
      @XiremaXesirin 7 лет назад +6

      He proposed exactly that solution about a third of the way into the lecture. He also brought up some potential issues with that approach. Maybe watch the whole video before you leave comments?

    • @halbesbyte
      @halbesbyte 7 лет назад +3

      Well I didn't bother to watch the video to the end (I was about 1/3 in and still no mentioning of pass by value). A 60 min video about a point that can be told in less than 5 Minutes. It's disgusting to pull in meta-template programming or these duplicate overloaded constructors in this simple case. The simple solution is so straight forward, there is no point in introducing all these complicated and flawed variants.

    • @JoahW
      @JoahW 7 лет назад +3

      It does result in potentially more moves than the crazy template version, though the optimizer will likely remove them (and the difference will probably be negligible in vast majority of use cases even with optimizations disabled.)
      A lot of these lectures are far more engaging at 1.5x or even 2x speed, by the way.

    • @MSheepdog
      @MSheepdog 7 лет назад +2

      That solution still isn't perfect, the crazy template stuff cut down on a couple of moves, and plain old struct initialisation with no constructors would also be faster, but would then run into issues with derived classes and such.
      I think the whole point of the talk was that with c++ it's really hard to get perfect performance with simple enough use cases.

  • @Stierguy1
    @Stierguy1 5 лет назад +2

    This should be basic for c++ programmers. The lesson is "don't make poor choices about what value category and how qualified my function's arguments are". There are way more wrong ways to do something than right ways. Other programming languages say "malloc, shmalloc". It's not hard to be better than that.

  • @nooan79
    @nooan79 2 года назад

    What a mess. The use of an std::string is an implementation detail of Cust and it should not be exposed in the constructor(s). Instead, the constructor should accept as argument a generic string type (e.g. string_view) and then store internally (to a std::string/a buffer/something else). Yes that implies a copy (but not necessarily a heap allocation). If copies affect performance negatively, which should only happen with exceptionally long strings or with many, many constructions of Cust in loops, then rethink the architecture.

  • @ginobean737
    @ginobean737 5 лет назад +1

    I don't know if I'm misunderstanding something, but when you pass in a 'const char *' to initialize a std::string, the std::string does NOT take ownership of that 'const char *'. It copies it.
    Also, the literal const char * is NOT created on the heap. So, if you see "Joe", it's NOT being created on the heap.
    Given that these two INACCURACIES occurred within the first 15 minutes of the video, I stopped watching this video..

    • @CppCon
      @CppCon  5 лет назад +2

      Gino Lee, you are misunderstanding. The two statements that you make are correct, but Nico never says otherwise.

  • @bapluda
    @bapluda 3 года назад +7

    "requires"? So C++ syntax is becoming C#. I think I am going back to plain C thank you. Yep plain C struct with all the fields public is more productive in a team because everybody understands it.

    • @phusicus_404
      @phusicus_404 10 месяцев назад +1

      Concepts are brilliant, you just don't want to learn new

  • @lenkite
    @lenkite 5 лет назад

    Umm.. either use C++ 17 string_view or std::move in the construction initialisation. Not even sure why the last horrible template solution got discussed. I think Nicolai missed having coffee.

    • @seditt5146
      @seditt5146 5 лет назад +3

      You don't know why he generated and example to show you problems that exist in the language?

  • @weirdconstructor2165
    @weirdconstructor2165 Месяц назад

    C++ is a lost cause 😢

  • @sarfok.frimpong8545
    @sarfok.frimpong8545 6 лет назад +2

    Please if you comment that c++ is ridiculous ,hard or what ever then you've not come to think of type of programmer you are and what you are really doing in programming field. And remember this tutorial is not for beginners.

  • @panjak323
    @panjak323 Год назад +1

    Still better than rust.

  • @Runoratsu
    @Runoratsu 7 лет назад +1

    Hmm. The talk is interesting, but as soon as he tries to talk more loudly, Mr. Josuttis' voice becomes so shrill and grating it's hard to concentrate on what he actually says. =/

  • @4otko999
    @4otko999 4 года назад +3

    perfect is the worst enemy of good. the correct answer is to ignore all this bs, pass by reference and enable optimizations

    • @ХузинТимур
      @ХузинТимур 3 года назад +4

      And you are wrong because compiler can't optimize copies in most cases.
      Actually best option is to pass by value and move-initialize fields because this more easy to optimize.

  • @aydinhoe6355
    @aydinhoe6355 6 лет назад +3

    :)))))))
    really the nightmare
    nightmare of c++
    .
    .
    .

  • @countbrappcula
    @countbrappcula Год назад

    Rust

    • @Phantom-lr6cs
      @Phantom-lr6cs 8 месяцев назад

      &'static str
      &'static
      _
      tons of moronic amprsands and tons of single quotes lol
      thank you rust-Fanboy
      rust is as ugly as it can be XD