Geometry Boost List: [ggl] Reviewing GGL against Boost requirements

Subject: [ggl] Reviewing GGL against Boost requirements
From: Mateusz Loskot (mateusz)
Date: 2009-04-20 10:01:11

Bruno Lalande wrote:
>>> namespace a {
>>>
>>> class T
>>> {
>>> public:
>>>    void foo();
>>> protected:
>>>    void bar();
>>> private:
>>>    std::size_t count_;
>>> };
>>>
>>> } // namespace a
> 
> Yep that's what I meant about namespaces. With the convention to
> always have the ending comment, sounds important to me precisely
> because of the lack of indentation.

Also, sometimes it may be helpful to put

}; // class T
or
}; // struct T

comment if a file consists of number of classes and class
definitions are long.

>> - I prefer a struct above a class because, especially in templates, many is
>> public, often there is no protected / private at all
> 
> Even if a struct and a class are technically the same, there's a
> strong "emotional" difference between them in the head of most
> programmers. "class" is often used for classes meant to produce actual
> objects, which have methods and an active role in the runtime
> functioning of the program. "struct" is rather used either for POD
> structures, or for classes used at compile-time like metafunctions,
> tags, traits, etc... So if the code above was mine I guess I'd choose
> "class", but I'm open to use "struct" if you really prefer.

Same here.

>> - I've always used the m_ prefix for member variables, don't know where it
>> comes from. Find them much more readable. The boost sample header gives no
>> prefix/suffix at all. However, the m_ prefix is used in some (not many)
>> boost libraries as well (e.g. math/tools/remez). So here I prefer to keep
>> them, at least in this refactoring round
>> - In case of a template, I prefer the "typename" above the "class" (unless,
>> of course, if it is required as in template template parameters)
> 
> No strong opinion about that so it's ok for me. About "typename", even
> though I often use "class" just by convenience (it's shorter ;-)), I
> think you're right with "typename" because historically, the fact that
> "class" can be used that way is an accident.

Same here with inclination toward typename :-)

Best regards
-- 
Mateusz Loskot, http://mateusz.loskot.net