DJ Delorie <d...@redhat.com> 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. > * Namespaces > > In general, I don't like namespaces, unless you're defining a package. > Class names create their own name spaces, globals should be global, etc. > Saying "everything should be in a namespace" is IMHO an inappropriate > restriction. Indicate where namespaces are appropriate, leave it at > that. The proposal doesn't say that everything should be in a namespace; it says that namespaces are permitted. I continue to think that is appropriate. I agree that globals should be global. However, GCC is a big package which can be naturally divided into modules. For example, GIMPLE code should not normally call RTL functions. Putting the RTL functions in a namespace would make it clear when something is reaching across a module boundary. Of course there are other ways to do this as well, but my point is that "global is global" is not necessary a well-defined concept in a big program. Some names are global to parts of the program but not to others. > * 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. > * When a method refers to a non-static data member, it should always > qualify the reference with this->. > > I'm very opposed to this. To me, it makes the code less readable > because it lets the author write code that's hard to understand at a > larger scope. I would forbid explicit references to "this" except to > pass it unadorned as a parameter to some other function. If it's not > clear where method call data comes from, write clearer code! > > If you're implementing a class, it should be clear you're implementing a > class, and implied that data/methods come from the class unless > specified otherwise (which you'd have to do anyway, like foo->reg_p()). > If it's not clear, you've not properly encapsulated the class and you > need to redesign it so it *is* properly contained and easy to > understand. > > If you're not implementing a class, you'd never use "this" anyway. > > DJ never refers to himself in the third person, I don't see why his code > should. 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. The biggest need for this-> is when calling methods in the current class if the current class happens to be in a template. The C++ template namespace lookup rules are confusing. 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. > * use of existing templates, e.g., from the standard library, is fine > > I'd prefer avoiding pulling in STL stuff at first. I find STL to be > quite a "culture shock" relative to C. When used I'd limit it to one > STL object at a time - avoid containers of lists of vectors of strings, > etc. As noted earlier I think we do want to use some STL classes. > * 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. > * 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. Ian
