| ||||
| Comment on GotW #91 Solution: Smart Pointer Parameters by Francis Rammeloo
Concerning case e: void f( shared_ptr<widget> w); The receiver will likely store the copy in a container. Will this incur the cost of a second copy? Read More » Comment on GotW #91 Solution: Smart Pointer Parameters by Róbert Dávid
BTW, it’s better if the function in 3(a) is a pointer constant, not (just) a pointer-to-constant: f(widget * const); Doesn’t matter too much (as it’s just a matter of a copy to get a modifiable pointer), but it does document that the function will inspect only the pointed object, and won’t do tricky traversals. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Róbert Dávid
@Francis Rammeloo: If he moves w into the container, then no.. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Róbert Dávid
@Bret Kuhns: Raw pointers in modern C++ are not good (read: should not be used) for anything else than that! The problem with optional that it owns the object. The exact idea behind point 3a/b is that the function does not try to manage the lifetime. There you need to have a non-owning reference: You can have reference semantics, use &, or if it can be nullable, use a raw pointer. Read More »Comment on GotW #92: Auto Variables, Part 1 by Róbert Dávid
1, I would dig around at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/ to check what was the first proposal after the 03 standard :) Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Bret Kuhns
@ Róbert Dávid, std::optional<Widget&> would “own” the reference, not the `Widget` being referenced to. I already use boost::optional<Widget&> in code to express “non-owning observing reference”. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Herb Sutter
@mttpd: Maybe I should allude to this, thanks: Because const shared_ptr& and widget* have the same (nullable) semantics. If you're being tempted to pass const shared&, widget* doesn't lose information, whereas switching to widget& can lose information. Sure, use a & if it can't be null. And re code: All I know of is for code blocks. @David: Normally you're right to be very suspicious about claims of no barriers/synchronization. In this case, the key is that because we can guarantee that no action is never taken by another thread because of a refcount increment, it is not really a "publish" operation, so one can apply subtle reasoning and prove that the increment can be memory_order_relaxed; but it's exceedingly subtle and most experts shouldn't even try to venture into waters like these. I explain this example toward the end of my "atomic Weapons, Part 2" talk. See pages 50-52 of the slides at http://sdrv.ms/NxDB6u . The talk video is at http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-2-of-2 . @zahirtezcan, Francis: Once you've copied the shared_ptr, If you want to move the shared_ptr onward, that's fine, just std::move it. Constructors aren't special, this applies to any function. I should mention this to avoid confusion; added, thanks. @Bret: Alas, std::optional isn't standard; see that part of Andrzej's paper at http://isocpp.org/files/papers/N3672.html#optional_ref . I asked Andrzej about it a few days ago and that part wasn't accepted for C++14 and isn't likely to be. There is a workaround: std::optional<reference_wrapper>. IMO it's less clear, less efficient, and more verbose than plain widget*. @Bret,Arthur: Yes, I intend to eventually write a GotW on parameter passing. Probably not for a couple of months though, if I do get to it. And I may not. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Bret Kuhns
@Herb, Well that’s unfortunate; I assumed std::optional would work like boost’s (plus move semantics). I can see the point that reference types represent a somewhat awkward subset of std::optional T. Also, I assume your own comment got mangled when you said “std::optional isn’t standrad” ;-) Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Leszek Swirski
For mutable parameters, I like to use my tiny inout header[1], which provides out and inout parameters in the same style as C#’s out[2] and ref[3]. That way the mutability is visible at the call site, there are no raw pointers in user code, and there is no question as to whether the referenced variable needs to be initialised or not (because it only has to be initialised for an inout variable). [1] https://gist.github.com/LeszekSwirski/3028820 Comment on GotW #92: Auto Variables, Part 1 by Brian M
What is the oldest feature, by topic guess its auto, and probably the best and most welcomed feature ever after =. @Ralph think you are right about Bjarne Stroustroup. It’s always been the ‘missing’ elephant in the room for c++ compared to other languages, and c++ is the language that can really make best use of it. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Brian M
What worries me here is the number of ways and opinions going on – with real world coders I just wonder what would be used in the average non-guru shop or guru populated shop for that matter! The use of the raw pointer does have its simplicity in this case and the only really good argument against it is in a sink function, even then a suitable name such as ProcessAndDelete might suffice. If a coder can’t pick up on that, then we are probably doomed anyway! Beginning to think we are now in no-mans land with c++, it’s getting way too complicated, after all its only a tool to achieve an end. Maybe we need a more intelligent compiler that can make a lot of these ‘guru’ decisions for the average coder. It should not beyond the ability of a compiler to have a autoptr mk2 that is compiled into the most efficient type for the job. Be like having Herb or Meyers standing behind you :) Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by mttpd
@Herb: fair enough. I can see you’re using WordPress, how about adding WP-Markdown to enable MarkDown (also mentioned by Bret, it’s what’s used on GitHub, Reddit, StackOverflow, and many others — and supports the backticks syntax for the inline code formatting): http://wordpress.org/plugins/wp-markdown/ // Here’s the relevant feature: http://daringfireball.net/projects/markdown/syntax#code Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Herb Sutter
@mttpd: I’m using WordPress.com, not a WP.org installation. In return for much less admin hassle, it’s more restrictive — I can’t install packages, only use what they give me. I’ll poke around and see if there’s something available though. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Herb Sutter
@BrianM: But the Guidelines are simple — don’t pass by smart pointer unless you want to use/modify the smart pointer itself (like any object). The main thing is that pass by value/*/& are all still good and should still be used primarily. It’s just that we now have a couple of idioms for expressing ownership transfer in function signatures, notably passing a unique_ptr by value means “sink” and passing a shared_ptr by value means “gonna share ownership.” That’s pretty much it. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Bret Kuhns
@Herb, since reference types for `std::optional` was not approved, it makes it all the more unfortunate that N3514 “A Proposal for the World's Dumbest Smart Pointer” didn’t make it either. A `std::exempt_ptr` would be an obvious answer to explicitly express non-owning pointer semantics. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Jon
@Herb: “If the local scope is not the final destination, just std::move the shared_ptr onward to wherever it needs to go.” Why is this better than passing by const shared_ptr& through a chain of functions until we’re ready for the final destination? What if the callee will make a decision about whether to share ownership or not? If it decides not to, then we’ve copied for no reason. Also I noted that you said “always pass them by reference to const, and very occasionally maybe because you know what you called might modify the thing you got a reference from, maybe then you might pass by value” (http://stackoverflow.com/a/8844924/297451). Can I confirm that your opinion has changed since then? Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Jon
@Leszek Swirski: Have you considered submitting your header to boost? Having mutability visible at the call site is useful. Comment on GotW #91 Solution: Smart Pointer Parameters by jlehrer
Re: "A Proposal for the World's Dumbest Smart Pointer" I’ve always wished the C++ language supported a simpler alternative syntax for pointers: pointer<int> <--> int* pointer<const int> <--> const int * const pointer<int> <--> int * const const pointer<const int> <--> const int * const this would make teaching pointer syntax to new developers much easier. Obviously, we can add this as a language feature using template <typename T> struct pointer { typedef T* type; }; pointer<int>::type But this is not the same as a language feature. For example, the compiler would not be able to compile the following code due to the templated function parameter: template <typename T> void func(typename pointer<T>::type); int x; func(&x); //fails to compileRead More » Comment on GotW #92: Auto Variables, Part 1 by Jeffrey Bosboom
auto comes from B, so it’s old in that way too. Read More »Comment on GotW #92: Auto Variables, Part 1 by David H. Braun
I’m thrilled having the new “auto” semantic, which is wonderful when a type specification is verbose and complex, and essential when the type is ineffable. However, one thing that is illustrated here is that, except for ineffable types, there is always *some* trade-off being made. In many cases the trade-off is so overwhelmingly positive that the negatives are negligible, however real. The negatives are rooted in loss of visibility of type information. The examples in problem #3 illustrate the need for clear understanding of typing rules to retrieve information that auto makes less apparent. The more simple the type specification (e.g. a built-in or an ordinary class) the less is gained by using auto and the greater the proportionate significance of diminishment of type visibility. A chained use of auto reduces type visibility even more, necessitating a bit of detective work just to figure out what *it* is one is looking at, and consequently what one can do with “it”. If, as has been advocated, auto should be used pervasively, doesn’t this make *some* code less comprehensible and give unnecessary work to the reader? Isn’t there a cumulative cognitive drain imposed by pervasive “type indirection”? Read More »Comment on GotW #92: Auto Variables, Part 1 by jlehrer
@DavidBraun, a good IDE should be able to tell you the type of the auto-declared variable, reducing the reader’s unnecessary work. Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Herb Sutter
@Jon: This is better in the case where you do get an rvalue, and the default guidance to “pass by value then move as needed” doesn’t apply just to smart pointers but to any type that’s cheaper to move than copy. And yes, my opinion has changed. Basically that came from paranoia about a different optimization that doesn’t apply to standard C++ code (something we encountered designing C++/CX that can apply to the underlying implementation of refcounted ^’s but I now realize doesn’t apply to shared_ptrs in normal C++ code). Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by decourse
As I noted in a comment on the question, there is another use for (d). Some functions may choose to either take or not take ownership of an object by criteria to be decided at run-time, perhaps by inspecting the object itself. Think of a “chain of responsibility” pattern, for example. Read More »Comment on GotW #89 Solution: Smart Pointers by Herb Sutter GotW89: Smart Pointers | musingstudio
[…] Sutter’s GotW89 Smart Pointers post includes good reasons to use make_shared/make_unique instead of naked new. Avoiding memory […] Read More »Comment on GotW #92: Auto Variables, Part 1 by GonzaloBG
I think about auto in the same way as I think about TAD, decltype on the other hand… Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Leszek Swirski
@Jon: I have considered it, but a similar proposal was rejected in 2003, because (as I understand it), even people who liked the syntax didn’t like the fact that this was essentially optional, rather than a language change (cf. Ada, C#). The argument was that for f(out(x),y) you technically still don’t know if y is mutable or not, because the evil library writer could still be using normal references. http://lists.boost.org/Archives/boost/2003/04/47180.php Read More »Comment on GotW #91 Solution: Smart Pointer Parameters by Kamil Rojewski
I have a question about example (c). Wouldn’t it be better to use rvalue ref to unique_ptr instead of pass-by-value? It still requires to pass an explicit unique_ptr, but it shows an expcilit move is done, instead of implicit by passing to the parmateter value. Read More »Comment on GotW #6b Solution: Const-Correctness, Part 2 by Mathias Stearn
Wouldn’t the move operations need to set other.area to -1 since a cached area would no longer apply to the now-empty points vector? Read More »Comment on GotW #1 Solution: Variable Initialization – or Is It? by dengos (@Cheng_Wer)
@Seungbum Woo @Herb Sutter main()
2 gdb a.out turn out that, after execution of #2, the f object in memory look like this: (gdb) p f but still can’t figure out why the segmentation fault. Read More »Comment on GotW #6b Solution: Const-Correctness, Part 2 by Herb Sutter
@Mathias: Excellent point, fixed. Thanks. Read More »Comment on C++ and Beyond: My material for December, and early-bird registration (through June 9) by Alex
@Herb, thank you for your reply, but there is a bit of a difference between snarky remarks and delivered features. I am very concerned about the standard support in VS2012 because I invested a lot of efforts to persuade my company to purchase VS2012 (for more than 50 developers), based on my interpretation of your promise — that VS2012 will get full C++11 compatibility via free updates (and I am sure that I was not the only person to interpret it this way). Now, I see Brian Harry announcing VS2013 (http://blogs.msdn.com/b/bharry/archive/2013/06/03/visual-studio-2013.aspx) and, given my previous experience with MS, I suspect that you (plural) will prefer pushing users to buy the new version rather than putting out free upgrades to the older one. Profits always trump “the right thing to do”. Should this happen, I am fairly convinced that the following will happen: I have no intention of “scissors headlocking” you or anything but I do believe that you have the moral obligation to answer the following: Best regards, Comment on GotW #91 Solution: Smart Pointer Parameters by Brian Fiete
Re: #2 (correctness) – even without changing the state of the calling function, passing a shared_ptr by reference can be hazardous if the function is able to remove the shared_ptr reference that was passed to it. A trivial case is below (results in a crash), but one can easily imagine a less trivial case — say, if the function were to run some validation on the data passed to it which could result in a new instantiation of that data… struct IntArrayContainer { shared_ptr<vector<int>> mIntArray; }; IntArrayContainer* gIntArrayContainer; int GetFirstValueFrom(shared_ptr<vector<int>>& intArray) { delete gIntArrayContainer; return (*intArray)[0]; } void main() { gIntArrayContainer = new IntArrayContainer(); gIntArrayContainer->mIntArray = shared_ptr<vector<int>>(new vector<int>(1, 1)); printf("First: %d\n", GetFirstValueFrom(gIntArrayContainer->mIntArray)); } Read More » | ||||
| ||||
Thursday, June 6, 2013
FeedaMail: Comments for Sutter’s Mill
Subscribe to:
Comments (Atom)