gotw

C++11 type deduction vs const char *

由 Deadly 提交于 2019-12-23 07:46:10
问题 In GotW 94, Herb Sutter draws a distinction between the "classic C++" declaration const char* s = "Hello"; and the "modern" style auto s = "Hello"; He tells us that there's a "subtle difference in the type of s , where the auto style is more correct". [Edited to add: comments suggest that this might not be a fair representation of what Sutter actually meant; see discussion below.] But... what's the difference? I was under the impression that a const char * is the correct way to refer to a

How to fix this typical exception unsafe code?

由 。_饼干妹妹 提交于 2019-12-08 08:47:15
问题 According to GOTW #56, there is a potential classic memory leak and exception safety issues in the following code: // In some header file: void f( T1*, T2* ); // In some implementation file: f( new T1, new T2 ); The reason is that when we new T1 , or new T2 , there might be exceptions thrown from the classes' constructors. Meanwhile, according to the explanation: Brief recap: An expression like "new T1" is called, simply enough, a new-expression. Recall what a new-expression really does (I'll

How can I implement “op” in terms of “op=” in a CRTP base class?

由 百般思念 提交于 2019-12-08 03:17:12
问题 Herb Sutter's Guru of the Week #4, "Class Mechanics", teaches that the "a op b" form of an overloaded operator should be implemented in terms of the "a op= b" form (see point #4 in the solutions). As an example, he shows how do to this for the + operator: T& T::operator+=( const T& other ) { //... return *this; } T operator+( T a, const T& b ) { a += b; return a; } He points out that first parameter in operator+ is intentionally being passed by value, so that it can be moved if the caller

Use cases for final classes

由 谁说我不能喝 提交于 2019-11-27 17:17:34
问题 I was reading comments on Herb Sutter's Guru of the Week redux about virtual functions, and finally saw him mentioning this: [...] “uses of final are rarer” – well, they sort of are. I don’t know of many, and during standardization Bjarne repeatedly asked for examples of problems it solved and patterns where it should be used, and I don’t recall any major ones that stood out. The only one I know of offhand is that if you’re defining a library module (which isn’t a Standard concept yet) then

Does the GotW #101 “solution” actually solve anything?

由 白昼怎懂夜的黑 提交于 2019-11-26 18:58:22
First read Herb's Sutters GotW posts concerning pimpl in C++11: GotW #100: Compilation Firewalls (Difficulty: 6/10) GotW #101: Compilation Firewalls, Part 2 (Difficulty: 8/10) I'm having some trouble understanding the solution proposed in GotW #101. As far as I can understand, all the problems laboriously solved in GotW #100 are back with a vengeance: The pimpl members are out-of-line templates, and the definitions are not visible at the point of use (in class widget 's class definition and implicitly generated special member functions of widget ). There aren't any explicit instantiations

Does the GotW #101 “solution” actually solve anything?

由 青春壹個敷衍的年華 提交于 2019-11-26 06:43:23
问题 First read Herb\'s Sutters GotW posts concerning pimpl in C++11: GotW #100: Compilation Firewalls (Difficulty: 6/10) GotW #101: Compilation Firewalls, Part 2 (Difficulty: 8/10) I\'m having some trouble understanding the solution proposed in GotW #101. As far as I can understand, all the problems laboriously solved in GotW #100 are back with a vengeance: The pimpl members are out-of-line templates, and the definitions are not visible at the point of use (in class widget \'s class definition

C++'s most vexing parse again [duplicate]

由 好久不见. 提交于 2019-11-26 00:55:19
问题 This question already has an answer here: A confusing detail about the Most Vexing Parse 4 answers Taken directly from http://herbsutter.com/2013/05/09/gotw-1-solution/ While widget w(); is clear for me, I have no idea how can the below code be a function declaration? // same problem (gadget and doodad are types) // widget w( gadget(), doodad() ); // pitfall: not a variable declaration How is this possible? 回答1: In a function declaration, arguments of type array decay into pointers to the

C++'s most vexing parse again [duplicate]

由 半腔热情 提交于 2019-11-25 19:37:27
This question already has an answer here: A confusing detail about the Most Vexing Parse 4 answers Taken directly from http://herbsutter.com/2013/05/09/gotw-1-solution/ While widget w(); is clear for me, I have no idea how can the below code be a function declaration? // same problem (gadget and doodad are types) // widget w( gadget(), doodad() ); // pitfall: not a variable declaration How is this possible? In a function declaration, arguments of type array decay into pointers to the first element, arguments of type function decay into a function pointer, so the signature would be: widget w(
订阅 gotw