FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #7a: Minimizing Compile-Time Dependencies, Part 1 by Mark You can get rid of all of them if you parameterise the entire class. Read More » Comment on GotW #7a: Minimizing Compile-Time Dependencies, Part 1 by Johannes Schaub (litb) There’s another detail for class “C”. Since “A” has virtual functions, and we don’t know which, we must assume that “A::g( B )” might be virtual. If so, for the worstcase scenario we need to include “C” because the return type in the overridden function might differ from “C&” (if C is a derived class of it, covariance). Read More » Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by Chris Vine I doubt the ‘auto x = type{ init };’ style, in place of the standard ‘type x{init};’, is going to catch on. This is because, as noted, it cannot be used with types which are neither copyable nor movable, so it cannot be used universally. I discount the fact that (to me) it looks plain odd, because that can pass with usage and familiarity. The standard C++ library tries hard to make as many aggregate types as are reasonable movable, but in user code I commonly come across, and write, there are often types which are neither copyable nor movable. There are a number of reasons for this: two types may be closely coupled as part of a single implementation, so objects of those types may hold references to each other. Trying to track which object happens to own some movable resource in such cases is often far more trouble (and introduces more inefficiency) than it is worth. Efficient movability also implies constructing the internal implementation data of aggregates on free store so the data can easily be moved by swapping pointers. However where efficiency is at a premium for objects likely to be constructed on the stack and unlikely to be moved, constructing things like arrays with known sizes at compile time may be desirable, and member arrays of aggregates (or std::array objects) can only be copied in linear time and not moved. In those cases you may want to prohibit copying/moving entirely. Users who in a particular case want to move and are willing to take the hit of allocation can call make_unique() for the unmovable type in user code where they really want to. Lastly of course, prohibiting moving and copying may be necessary to enforce the thread-safe use of some objects at reasonable cost. And some objects cannot semantically properly support moving (the article mentions locks, but there are many others). Read More » Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by J Guy Davidson Excellent arguments. However, unless I don’t understand std::function or these chaps http://en.cppreference.com/w/cpp/utility/functional/function have got it wrong, there’s a misspelling in the last line of your third code block in section 6. auto f = function<int()>{ &func }; // ok should be auto f = function<void(int)>{ &func }; // ok Read More » Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by Herb Sutter @J Guy Davidson: Actually, I also noticed that the example isn’t really relevant because it has nothing to do with auto — taking the address of an overloaded function and storing it directly in function is problematic with or without the auto style syntax, so I've removed the example. Read More » Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by Bartosz Bielecki @ned I believe the non-searchability isn’t that bad if you consider that at least the interfaces of the classes/functions will have to explicitly state the type. Because of that I am not a big fan of the auto-deduced type of non-template functions. Also if you use the “auto f = Foo{ sth. }” you will still be able to find the usages of your class in your codebase. Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe