FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #6b Solution: Const-Correctness, Part 2 by Tony Van Eerd @Felipe – some people (ie John Lakos) would say you are talking about about the *salient attributes* of the object. *You* (class author) decide which aspects of an object are salient and which aren’t. This is typically the observable properties, but not always – eg capacity() is observable for vectors, but it is not considered part of its ‘value’ and thus not part of its equality operator. You are definitely on the right track – mutable things are typically implementation details and typically not part of the object’s _value_, and thus not part of its equality operator. I think calling GetArea() inside equality is fine, particularly if the implementor thinks (measures!) that’s a good trade-off. Read More » Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by Jon I didn’t quite follow why “auto e = employee{empid};” is better than “employee e{empid};”. It’s more typing which is a (tiny) negative. Is it just for consistency with other declarations? Read More » Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by Что бы такое посмотреть, что бы такое почитать? III | System Development […] О пользе ключевого слова auto и робких аргументах против него; […] Read More » Comment on GotW #7a: Minimizing Compile-Time Dependencies, Part 1 by Что бы такое посмотреть, что бы такое почитать? III | System Development […] Квест на тему минимизации времени сборки; […] Read More » Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by Mark Garcia With all the issues about the readability of the type of an “autoed” variable, we must see that what is more important is not the variable itself, but instead its initializer. Consider this somehow innocuous piece of code auto result = make_something(); result.do_something(); send_something(result); Long story short, by using auto, we are emphasizing the initializer, as the initializer is the one who gives the actual type of its result. By emphasizing the initializer, we are emphasizing the operation(s) involved in the initializer. In the above code, make_something() is actually the one who is more important. It is a clear statement that “we are making something, then return some result”. But this is just for the functional programming part… Now you may (and you will) argue “Hey! We are now in an OOP world! result there would almost always be an instance of some class. make_something() wouldn’t matter if doesn’t clearly know what we can do with result.” “what we can do” “can” What should you do? “Where do you want to go today?” not “Where can I go today?”. “What operations should I do?” not “What operations can I do?”. A good thing with OOP is that we are encapsulating data with operations. The operations that we do is what matters. But what matters most is what operations we _should_ do. (You may see that it’s analogous to test-driven development.) With the line result.do_something();, we are not focusing on what result is (i.e. what’s its exact type), but instead, we focus more on the operation. Sometimes we think it the wrong way with OOP. With its syntax we often we read that line as “result, do_something()” (emphasis on the object) where instead it should be “do_something() with result” (emphasis on the operation). Now you are seeing some reasoning template library authors usually have. These are the properties of templates, of generic code. And now, we can enjoy it in non-template, “daily” code. My own sentiment with auto is a very positive one. As said, it brings much generic code goodies without writing inside a template at all. Most importantly, it makes your code emphasize more on the operations, something we’ve been taking for granted for the past few years. Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe