[Corelinux-public] Feedback

[Frank V. C. <fr...@co...>]

Here is another one I received direct and felt a group discussion was a
better idea. (My comments are noted by the /* */
------------------------------------------------------------------------------------

Frank,

4.1 Abuse of Member Data
Classes should access their own member data via accessor and modifier
functions, just like clients. If a class provides overloadable modifier
functions, but does not use them internally, then descendant
implementations
may no work correctly. 

<sp> ...may not work correctly.

-- Will correct

What about the function call overhead incurred by accessing readily
available data by calling accessor and mutator functions by other member
functions?

-- As class library objects many (if not all) methods will be virtual.
If we don't know to what extent a derivation has overloaded a accessor
or -- mutator then we run the risk of getting unexpected behavior. For
concrete classes that don't override then this is not as much as a
problem.


Sections 6.5 and 6.6 are marked as dated.  How does this affect the
standards?  Does this mean that namespaces and RTTI are acceptable, or
is
this an item for discussion?  Are these really analysis and design
issues?
Should namespaces and RTTI be included in the standards documents if for
no
other reason than to extend the shelf life of the standard?

/*
This should be clarified. Yes, namespaces and RTTI are acceptable in my
opinion.
*/

6.11 Portability
Standard: Native C++ data types shall not be used. Use the Types.hpp. 

/*
This applies to built-in types (int, long, double, etc).
*/

Standard: Native C++ classes ( streams, stl, string ) should be used but
it
is recommended that we at least wrap 
them. For example: 
class EXPORT String : public string 

If one of the goals of the project is to make C++ on Linux more
accessible,
and attractive through the development of coding standards, doesn't this
present a barrier to entry by increasing the learning curve?

What about developers, who are new to the Linux operating system, but
are
familiar with C++, and the implementation of the Standard C++ Library? 
Does
that mean their code is not to standards because they directly 
reference the Standard C++ Library classes?  Do you intend to wrap every
class from the Standard Library?

I don't believe that either of these contribute to clarity, and should
be
made guidelines if they are included at all. 

/*
There are a couple of points here:
1. If a developer wants to use std:: classes direct, that is fine
2. In the String example the direction is clearly to allow the use of a
string abstraction
but the standard implementation doesn't help with the real world issues
such as UCS2 and UCS4.

I agree to the guideline disposition. I believe that our analysis of the
requirements (which are still coming) will show that the treatments we
-- need to apply to otherwise standard constructs will be for the
logical extensions.
*/

8. Tools and Methodologies
I agree that UML should be used as the standard for analysis and design.