FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on GotW #7b: Minimizing Compile-Time Dependencies, Part 2 by thokra Little correction, it’s supposed to be std::shared_ptr d_; – for the same reason it’s used as the template parameter for the list. Although the intent of the author obviously wasn’t to allow sharing of d_, IMHO it’s not important. D is completely internal (i.e. neither part of a public interface, nor accessible via friends) and except for slightly increased memory usage and the indirection, it solves the problem of wanting to get rid of the include. Again, including d.h might not be a problem in the first place … Read More » Comment on GotW #7b: Minimizing Compile-Time Dependencies, Part 2 by thokra I’d go as far as saying that using a PIMPL simply to be able to throw out some includes is kind of a premature optimization. Get hard numbers in terms of compile times and really compare two implementations (with and w/o the PIMPLs) – if you get a significant speedup you can go ahead and find a way to deal with the run-time/maintenance caveats already mentioned by Alf. Also, the indentation of the “public” access specifier is a little off. ;) I’m not sure if this was mentioned in [More] Exc. C++ or an older GotW, but one purpose of a PIMPL (or whatever you wanna call it) tends to be overlooked in favor of this uncertain compile-time advantage: helping binary compatibility. Still, employing a PIMPL for that purpose is a completely different design choice than using the PIMPL merely to reduce compile-time dependencies – and using it just because you get both “treats” at the same time simply isn’t the way to go … Also, for D d_; there is absolutely no reason why this cannot be declared as std::unique_ptr<D> d_; Also, for the purpose of reducing dependencies, why wouldn’t a std::list of std::shared_ptr (since std::unique_ptr tends to be a pain when it comes to incomplete types, i.e. default-deleter … ) not be a viable alternative? Yes, we get an additional indirection on access (just like when using a PIMPL) but unless binary compat. matters, it’s IMHO much easier to read, understand and maintain than a private class. and boilerplate delegation code. Read More » Comment on My //build/ talk on Friday @ noon PDT (webcast) by 万年筆 カートリッジ 正規代理店 Read More » Comment on GotW #7a Solution: Minimizing Compile-Time Dependencies, Part 1 by BC I have a trick to avoid both #include and forward declaration for the operator <<, but I am not sure whether it is good thing to do. Could you give some opinion? template<class OS> OS& operator<< (OS& os, const X& x) { return ( os << x.to_string() ); } By letting the compiler deduce the output stream type, both #include and forward declaration are avoided, and the operator is now more generic. I am not sure whether it is a good practice but it works for me anyway. Read More » Comment on GotW #7a Solution: Minimizing Compile-Time Dependencies, Part 1 by thokra BC: From where did X suddenly get a member function to_string()? Also, you cannot get completely rid of everything. At the very minimum you need the forward decl to let the compiler know that there actually is a type std::ostream – which is just a typedef: typedef basic_ostream<char> ostream; The problem is the virtual function X::print( std::ostream& ). If you could make a template member function out of that, it’d be fine – but you can’t because it’s virtual. Merely throwing the virtual function out is a crude design alteration and if there are classes that inhereit from x and override it, you’ll have completely unwanted side-effects. It’s not the case that base classes of X declare the virtual function, because would have already been included in A.h. If it compiles anyway, it’s likely because the symbol is pulled from somewhere else – or because you simply thew out X::print( std::ostream& ). Also, if you have a function that spits out a string representation of the class, why would you need a overload for operator<< ? You can feed the string to any ostream already. Read More » Comment on GotW #7b: Minimizing Compile-Time Dependencies, Part 2 by Alf P. Steinbach I found some web references for the source concatenation technique (which addresses the archaic tool problem): * http://en.wikipedia.org/wiki/Single_Compilation_Unit * http://gamesfromwithin.com/physical-structure-and-c-part-2-build-times Now I see people downvoting comments here. A downvote is an anonymous social argument, which only makes sense in a social community such as SO (e.g., I very much doubt that Herb will be influenced by the votes: the voting functionality just an artifact of the WordPress blogging system). Please, in order to express disagreement or opinion or perceived fact,, write it up as a comment so that readers can know or guess what it’s about. Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe