On 1 June 2010 22:13, Ian Lance Taylor wrote: > DJ Delorie writes: > >> My suggestions: >> >> * When it is appropriate to use a child class with virtual functions, >> the virtual functions should all be declared as protected in the >> parent class. >> >> At first reading, I thought you meant "all virtual functions should be >> protected", but I think you meant "if a child ADDS a virtual function >> that the parent doesn't have, ...", but in that case I don't see why the >> parent needs a declaration at all. This should be clarified. > > I did mean that all virtual functions should be protected. I tried to > clarify the wiki page.
If a reference helps, this is sometimes referred to as the Non-Virtual Interface or NVI idiom: http://www.gotw.ca/publications/mill18.htm (I've also heard it called, IIRC, the Non-Useful Interface idiom, but nevermind!) >> * All data members should be private. >> * All data members should have names which end with an underscore. >> >> This makes all structures illegal. I'd remove the first "All" and >> replace the second with "Private": > > This text only refers to classes. As the convention says in the > following major bullet, structs are handled as they are today. Nothing in C++ prevents a "struct" from having member functions, constructors, base classes, virtual functions, private members etc. If the intention is to impose a distinction between structs and classes, based on which keyword is used to define the type, the convention should say so. (FWIW, I think that's a reasonable convention for a codebase that originated as pure C.) > Our current code always uses the equivalent of an explicit this > pointer, except that it is called something else. Therefore I would > argue that this is not new. I don't see why using an explicit this-> > makes code harder to understand in a larger scope; the explicit this-> > makes it very clear where data is coming from. If data members have a trailing underscore then isn't it already explicit where an unqualified name comes from? foo_ must refer to this->foo_, while p->foo_ obviously refers to p's foo_. > The biggest need for this-> is when calling methods in the current > class if the current class happens to be in a template. The 'this->' is needed when the current class and base class are both templates and the name is declared in the base class, and not if it's declared in the current class. That is not likely to happen in a hurry while the convention is to not define any templates. > The C++ template namespace lookup rules are confusing. If I understand the problem you're referring to, namespaces are not involved. Only base classes whose complete type depends on a template parameter. Just to try and avoid further confusion! > The explicit this-> > makes them clear. While it's true that most code is not in a > template, it's possible that a template will be added later. > > I'm not going to fight to the death on this one, and I would be > interested in hearing other opinions. I've been using explicit this-> > in my own C++ code for many years, and I find that it clarifies rather > than confuses. There are cases where "this->" can't be used (e.g. referring to a type defined in a dependent base, there's an example on p138 in C++ Templates by Vandevoorde and Josuttis) so it might not be appropriate to require it always, even when it's not needed. >> * Local variables should be declared where they're first used, if their >> use is contiguous and localized. If they're ubiquitous (like a return >> value temporary) or reused later (like "i" for for-loop iterators), >> declare them at the beginning of the function. > > Thanks, I added text along these lines. C++ for-loop scoping means there is no need to reuse the loop variable unless you explicitly want to preserve the same value across loops. Is the intention to avoid relying on C++ for-loop scoping? If so, that should be stated. >> * Use C-style comments for multi-line comments, and C++-style comments >> for single-line comments. > > I'm not sure i agree with this, because I don't see anything wrong > with multi-line C++-style comments. Me neither, but I work in C++ every day, so I'm obviously not a good judge of what others will be comfortable with.
