RE: Some issues with the codebase

[Chad Yates]

(snip)
> I don't quite agree with using only a trailing underscore. Invariably
> you're going to make a typo somewhere, and leave out an underscore,
> which could be pretty disastrous if you start calling your parameters
> in your constructors and "set" methods the same as the members, without
> the underscore.
>
> CppUnit seems to call all their member variables "m_<membername>". I
> haven't decided if this convention is optimal, or whether it qualifies
> as some kind of quasi-Hungarian notation (Very, Very Evil(TM)), but I
> think it's better than the trailing underscore convention.
>
> I'd be interested to hear what other people suggest in this regard.

m_ very bad, unless your writing straight c and need a way to "simulate" a
class.  but in c++ it is obvious what it is when using the class.

MyClass a

a.getMyValue(); obviously a method due to the . and the ()
a.myValue; is a member, it can't be any other way (that I know of anyway)
a.m_myValue;  confusing to read.

MyClass mc_a;
mc_a.m_uMyValue; Even more confusing! (languages should have arbitrary
                 languages encoded, differently by everyone, where it
                 can be avoided.

the above was a MyClass (mc) access to a member variable (m_) that happens
to be an unsigned datatype (u) called MyValue.  what a mess! just look at
windows code.

eventually we will all be using more structured development environments and
hungarian notation and these bastarizagions ;) of the language will not have
*any* purpose but confusion, as the environment will tell you the type your
dealing with at a moments notice.

Mind you if it's an iternal function, it doesn't matter as much to me,
although I still like the same consistency if given a choice.

(snip)
> However, I don't think you've really addressed my issues with company
> names in namespaces. What if a new company, say ACME Inc., takes an
> active interest in developing Common C++ and contributes much code.
> Are we then going to split stuff up into "ost" and "acme" namespaces?
> I think not.
(snip)

yip, that could be a political/control/recognition issue.

(snip)

Did I say, I love the potential that common c++ has, hence the reason I've
started developing with it and contributing to it, and trying to think about
getting it more exposure and polish.

Thanks for starting such a sweet project!

,Chad