FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #94 Solution: AAA Style (Almost Always Auto) by Herb Sutter GotW94: AAA Style (Almost Always Auto) | musingstudio […] Sutter’s Guru of the Week article on Almost Always Auto is a tour de force covering everything you always wanted to know about […] Read More » Comment on GotW #7a: Minimizing Compile-Time Dependencies, Part 1 by Herb Sutter @Gennaro: Yes, I’ll add a note to be clear it’s okay to replace #include with a forward declaration. All: Remember to use for code blocks, or escape those pesky characters using “& l t ;” and “& g t ;”. Sorry, it’s a WordPress thing. Read More » Comment on GotW #7a Solution: Minimizing Compile-Time Dependencies, Part 1 by thokra I’m aware that this isn’t the topic of this GotW, but one minor detail: shouldn’t X(const C&) be declared explicit, since there is no obvious indication that, by design, C should be implicitly convertible to X? Doesn’t that go against the general coding guideline in C++ Coding Standards (Item 40)? More in regards to coding conventions, is there any reason why clist doesn’t have a trailing underscore? Read More » Comment on GotW #7b: Minimizing Compile-Time Dependencies, Part 2 by Arne Mertz 1) private means nothing except methods (static or non-static) of the class itself, and befriended functions may access the member. befriended functions include free functions declared as friends, as well as methods of classes declared as friends. 2) changing *any* member, including private members, might cause a change in the memory layout of a class, or in the vtable, function overload resolution and a number of other things that affect compilation of nonfriends, thereore any entity using the class has to be recompiled. 3) b.h, c.h and d.h can be gotten rid of by using the pimpl idiom: declare a struct in the header and let the only data member be a pointer to that struct. move all implementation details (private data members and privatly inherited classes) to the impl-struct. Define that struct in the .cpp. The logic of the class’ methods can either stay in the class’ implementation (pure data pimpl) or be forwarded completely to the pimpl (handle body idiom) or a mixture of both Read More » Comment on GotW #7b: Minimizing Compile-Time Dependencies, Part 2 by John Humphrey The “class E” declaration appears to have gone missing. Read More » Comment on GotW #7b: Minimizing Compile-Time Dependencies, Part 2 by thefatredguy Here’s my take on it : 1. When a member (either data or function) is declared as private, only member and friend functions of that class have access to it. 2. Because of the #include model. Even though the private part of the class definition is not accessible to clients, its still visible to anyone including the header (basically the implementation details of the class end up leaking into client code). 3. We move the implementation details out of the class interface (the PIMPL idiom – I first saw this in Exceptional C++, a few years ago) : // x.h: sans gratuitous headers // #include <iosfwd> #include <memory> // for shared/unique_ptr // None of A, B, C, or D are templates. // Only A and C have virtual functions. #include "a.h" // class A #include "b.h" // class B class X : public A, private B { public: X( const C& ); virtual ~X(); B f( int, char* ); C f( int, C ); C& g( B ); E h( E ); virtual std::ostream& print( std::ostream& ) const; // might also have to either define or delete copy constructor, // assign operator and move constructor private : struct implementation_details; std::unique_ptr<implementation_details> impl_; }; std::ostream& operator<<( std::ostream& os, const X& x ) { return x.print(os); } In the implementation file : #include <list> #include <iostream> #include <ostream> #include "c.h" #include "d.h" struct X::implementation_details { std::list<C> clist; D d_; }; X::X(const C&) : A(), B(), impl_(new implementation_details()) {} X::~X() {} Its not without any drawbacks though. There’s an extra allocation for each object of class X and, from the performace point of view, another level of indirection. Read More » Comment on GotW #7b: Minimizing Compile-Time Dependencies, Part 2 by Alf P. Steinbach As John Humphrey noted the "class E" declaration appears to have gone missing. Also, there’s still no include guard or #pragma once . Also, the operator<< is still not declared inline . The above are coding errors, ungood in example code (not to mention production code).. And with this new part II question (I’m happy that I didn’t overlook anything for part I) this GOTW is no longer about fixing things. It is now about introducing inefficiences (for PIMPL) and/or a maintainance nightmare (for duplication) alleviate symptoms of ungoodness, which IMHO is misguided. The ungoodness: ungood physical packaging of the code (distribution of code in files), and ungood tools (archaic compiler technology, e.g. with Visual C++ and g++). The physical packaging is too course grained and/or the software design does not properly support physical packaging, iif the headers drag in enough stuff to make a successful build too slow. The tools, well we can’t do much about them, but a reasonable modern approach would be for a compiler to by default compile several C++ translation units in one go, checking each header (except for [assert.h]) only once, Also, for a compiler to not waste time on storing context info in order to be able to continue after error with an avalanche of misleading and outright incorrect messages. nstead, as (IIRC) Turbo C++ did, it should stop at first error, and be taking advantage of that so that it’s fast about it. The archaic tool problem here is so much a pain in the a[censored][censored] that people have, seriously!, proposed to merge all headers and source code into one big file before compiling. They have even described this approach as an “idiom’, which presumably means that in some shops or projects it’s regularly used, and it has a name, which alas I can’t recall ATM. Given that the tools should better be fixed, so that people don’t have to do hazardious things like that! Introducting inefficiences and/or maintainance problems, as this part II of the GOTW is about, is of course an alternative to just suffering build times and/or doing the risky source concatenation thing, but employing these part II techniques negates much of the purpose of using C++ in the first place… Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe