| ||||
| Comment on GotW #91: Smart Pointer Parameters by Herb Sutter
@Tom: I have a talk at Build toward the end of this month where I’ll answer that in detail. Stay tuned. Read More » Comment on GotW #89 Solution: Smart Pointers by Herb Sutter
@Marco: Yes, that’s the kind of case the internal synchronization on the refcount is needed for — the user is allowed to do concurrent operations where not all are const on different objects, just not on the same object. The same case arises with polygon::area when two threads do const operations but might modify mutable state. Read More »Comment on GotW #91: Smart Pointer Parameters by Lelala
Even if i’m away a few years of C++ hardcore programming, i’d guess the first one (#1) has implications due fact that it’s a template, thus you do not now (first) how many cocmplex stuff is created in the templated class’ constructor, second because its a parameter-by-value, resulting in bad stuff in the C++ universe, depending on deep/flat copy of the object? Comment on GotW #1 Solution: Variable Initialization – or Is It? by Laurent L.
Herb, I looked a bit into N3651 (variable templates, revision 1) and something shocked me when I read the first example – template definition of the pi constant. The first thing I thought about was “Hey! This must be an old paper, they’re not using {}-initialization.” But then, I thought again, and saw that it was on purpose. And I thought about this a little more, and exclaimed “Hey! For any type T, the single-parametered syntax T(x) now uniformly means something different than it used to, doesn’t it?” Since you’re saying that {} should be preferred in nearly all cases, I think C++11 now has two syntaxes for two different concepts: Am I wrong? Any thoughts? Read More »Comment on GotW #1 Solution: Variable Initialization – or Is It? by Herb Sutter
@Laurent: Consider T{x} — that’s the same as T(x) except that the former doesn’t allow narrowing and does prefer initializer_lists if any, so T(x) and T{x} are both semantically a function-style cast to T, if x is not of type T or derived from T. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by mttpd
Regarding the following in the last guideline: “Don't use a const shared_ptr& parameter; use widget* instead.” BTW, is there a way to enable inline code formatting, e.g., using backticks ` ` like on StackOverflow? Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Lars Viklund
The assumption in (2) that the caller will not destroy their shared_ptr that’s passed by reference does not always hold. It’s trivial that from the leaf function invoke something that indirectly changes the state of the calling function, not uncommon when there’s callbacks and notifications involved. I would augment the advise to only recommend references to shared_ptr if you’re properly sure that they are valid for the duration of the call. Read More »Comment on GotW #92: Auto Variables, Part 1 by Jason S. Moore
‘C++ auto and decltype Explained’ by Thomas Becker: Comment on GotW #91 Solution: Smart Pointer Parameters by zahirtezcan (@zahirtezcan)
For using “widget*” instead of “const shared_ptr&” guideline, what about constructors taking a shared_ptr? Is it supposed to use shared_ptr by value and move the incoming parameter to the member? Or take as a modifiable reference and make copy out of it? struct SomeStruct SomeStruct(const shared_ptr& in): memberPtr(in){}// <– this one? Comment on GotW #92: Auto Variables, Part 1 by Sky
Okay… here are my guesses: 1. auto? 2. auto declares a variable on the stack of type that is deduced by the compiler. 3. 4: Now to see if I’m right… Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by David Oster
Section 1 of this says that incrementing the reference count of a shared_ptr can be optimized to a single read-modify-write without guards, while a decrement must have guards. I’d love to see a link to an explanation of this statement. I thought that if one writer needs a synchronization primitive then all writers needed that primitive. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by zahirtezcan (@zahirtezcan)
I failed to use segments… Read More »Comment on GotW #92: Auto Variables, Part 1 by j
1. Type deduction, it’s been around since templates only now can it be use intuitively. Read More »Comment on GotW #92: Auto Variables, Part 1 by Nils (@NightLifeLover)
Humm the first question seems interesting, but where should I know from. My guess: concepts, since templates do not seem to “fit-in” with static type checking. Or maybe also lambdas if you go back to lambda calculus.. Read More »Comment on GotW #92: Auto Variables, Part 1 by Ralph Tandetzky
1. I believe I heard Bjarne Stroustroup say that the idea of making auto do type inferrence was around back in the late 80s or early 90s, but that AT&T didn’t like it, since it would be too radical. 2. auto finds the type of an expression and removes top-level const, volatile and references. 3. int val = 0; auto a = val; auto& b = val; const auto c = val; const auto& d = val; int& ir = val; auto e = ir; Up to here you can replace auto with int and get the correct types. int* ip = &val; auto f = ip; In this case auto is inferred as int*. const int ci = val; auto g = ci; const int& cir = val; auto h = cir; Again constness and the references will simply be removed and int remains. const int* cip = &val; auto i = cip; Now this will be infered to const int *, since it’s a pointer to a constant int and not a constant pointer to a mutable int. The const is not on the top level and hence will remain. int* const ipc = &val; auto j = ipc; The j variable will be int*. const int* const cipc = &val; auto k = cipc; Again this will be a const int *. 4. int val = 0; auto a { val }; auto b = { val }; This one I’m not 100% sure about, but I believe that a will be an int and b will be an std::initializer_list. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Bret Kuhns
Are non-owning raw pointers really such a worth-while idea in C++14? What are they good for anymore in “modern” code? If I want to observe something that can optionally be null, wouldn’t std::optional be a better candidate than Widget*? Additionally, in the real world, not all code is necessarily modern. So although all raw pointers should be only observing in modern code, legacy code still uses them to mean something else. Now you have to ask yourself: is this function that wants a Widget* modern, or is it still living by old implicit ownership semantics with raw pointers? If the function is living by modern guidelines, it’s not doing a good job of telling you that in its signature. Using std::optional eliminates this ambiguity. Read More »Comment on GotW #92: Auto Variables, Part 1 by innochenti
4: Comment on GotW #92: Auto Variables, Part 1 by Alex Sinyakov
3. Comment on GotW #91 Solution: Smart Pointer Parameters by bkuhns
The template parameters were edited out of my comment above. Should say std::optional<Widget&> every time I say “std::optional”. Herb, pretty please, find a way to support markdown in comments on your blog! Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by zenmumbler
That’ll teach me from not refreshing the page before I post a comment. Good thing I’m not the only one thinking happy thoughts about optional. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Arthur Langereis
Also, given that we’re talking C++14 here: when you indicate that widget* should be used for optional objects, why not advise to use Comment on GotW #92: Auto Variables, Part 1 by nosenseetal
auto is the oldest feature… Herb said something like “they” made bjarne take it out. :D Read More »Comment on GotW #92: Auto Variables, Part 1 by Andy Prowl
Nice one. It would be interesting to discuss also decltype(auto), which will be available in C++14 Read More » | ||||
| ||||
Wednesday, June 5, 2013
FeedaMail: Comments for Sutter’s Mill
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment