Add in appendix a notebook explaining briefly std::string_view
Also add in types the initialization of std::string from string litterals.
As usual any feedback from any of you @steff, @vrouvrea or @vicente.mataix is welcome!
Merge request reports
Activity
added New notebook label
- 7-Appendix/StringView.ipynb 0 → 100644
67 "\n", 68 "\n", 69 "std::string hello(\"Hello world from std::string!\");\n", 70 "\n", 71 "print_with_const_ref(hello);\n", 72 "print_with_const_ref(\"Hello world!\");" 73 ] 74 }, 75 { 76 "cell_type": "markdown", 77 "id": "4df1c364-df85-4a4d-a0d3-43218189354d", 78 "metadata": {}, 79 "source": [ 80 "So what did we gain exactly in the bargain?\n", 81 "\n", 82 "If you remember the discussion about *l-values* and *r-values* in the [notebook about move semantics](../5-UsefulConceptsAndSTL/5-MoveSemantics.ipynb), the construct used prior to C++ 17 doesn't necessarily make much sense: in our second call the argument `Hello world!` is clearly a r-value whereas a l-value would be expected given the prototype!" 
For me, appendix are additional content that may be perused after the formation is done; the point is to provide insight on some topics we didn't manage to squeeze into the formation. That's the reason I give the link in "types" notebook but don't recommend reading it at once.
I am willing to present this differently if you feel it's not clear enough of course.
-
I'm completely ok with adding this type of information, but it probably needs explaining much more than I did how the
std::stringworks (I mentioned\0only for C strings).We could probably fill an entire notebook with more about
std::string(for instance insist not to inherit from it for a custom class...)...If it's ok for you, I would like to close and integrate this MR and postpone such an addition to a later MR (if you think it is relevant we can open an issue).
mentioned in issue #15 (closed)