Tuesday, June 4, 2013

FeedaMail: Comments for Sutter’s Mill

feedamail.com Comments for Sutter's Mill

Comment on GotW #90 Solution: Factories by Herb Sutter

@Marcel: Yes.

@Vincent: Null can be different from empty because empty may be a valid value. A classic example is a nullable string, where an empty string “” is different from no string… for C-style strings, it’s the difference between

strlen(s) == 0   // a.k.a. !strlen(s)

and

s == nullptr     // a.k.a. !s

Read More »

Comment on GotW #90 Solution: Factories by Vincent Jacquet

I understand the difference between empty and null. I am just wondering, in the context of factories, when returning a verctor of things, what is the benefit of returning a null value. How is it a better solution that returning an empty vector? Also, as currently implemented, it looks like your example 4(c) always returns a valid vector, that can be empty but not null.

I have mitigated feelings about optional. I find that sometimes it is an easy solution but not a good solution. I would be very interrested in a post discussing when to use it and when to not use it.

Read More »

Comment on GotW #89 Solution: Smart Pointers by Marco

@Herb: Thank you very much for your explanations. I’m still not sure we are talking about the same thing.

class A
{ public:
int GetValue() const;
};

There cannot be any writers, so that is no concern here and would have to be handled externaly, anyway. But what if two threads do the following at exactly the same time:

shared_ptr sp1(make_shared()); // shared ptr in T1.
weak_ptr
wA(sp1); // weak ptr in T2.

T1: sp1 = nullptr;
T2: shared_ptr
sp2(wA.lock());

So, both threads keep a smart pointer to the same data element, one shared and one weak. At the moment T1 releases its reference T2 tries to get a new reference. This means that T1 is changing the strong refs counter at the very moment T2 is changing it as well. Do the reference counters have a barrier that guarantees thread safety in this context?

I’m looking forward to the GotW on thread safety. Thanks again!

Read More »

Comment on GotW #90 Solution: Factories by Motti Lanzkron

The advantage of having a wrapper unonwned_ptr template type is purely for self documentation. When I see T* I have to ask myself whether the person who wrote this thought about ownership and decided that a raw pointer is the correct way to go or whether (for some code bases the more probable reason) the original author was just lazy/incompetent (often the original author is myself but that doesn’t rule out incompetence…).

After looking though the code I came to the conclusion that a raw pointer is the correct choice but tomorrow someone else will see the same code and wonder the same thing and have to duplicate the work of understanding the correct semantics for this pointer. It’s akin to why it’s better to use reinterpret_cast than a C style cast.

Read More »

Comment on GotW #91: Smart Pointer Parameters by Tom

Sorry for off topic.
But what about VS 2013 and C++11 support?
Does this mean that Nov. CTP C++ compiler is now part of VS 2013 and thre will be no update for VS 2012 ?
*dreaming* Or will VS 2013 finally get full C++11 support ?

Read More »

Comment on GotW #90 Solution: Factories by Sebastian

Doesn’t the answer to #2 forego the recommended smart pointer construction through std::make_shared?

Read More »

Comment on GotW #90 Solution: Factories by Herb Sutter

@Sebastian: make_shared should be used by default when you know you’re constructing an object that will be owned by shared_ptrs. The factory doesn’t know that and so returns a unique_ptr (presumably using make_unique), which the caller can then move into a shared_ptr if that’s how he wants to manage the memory.

Read More »

Comment on GotW #90 Solution: Factories by Herb Sutter

@Vincent: That’s reasonable, I’ve added a path to the example to demonstrate returning “nothing” too so people can see what that looks like. Thanks for the suggestion.

Read More »

Comment on GotW #89 Solution: Smart Pointers by nosenseetal

@herb tnx for the A,
now when you explain it is doh. :D
like Scott says shared prt is actually ptr_to_shared :D

Read More »
 
Delievered to you by Feedamail.
Unsubscribe

No comments:

Post a Comment