Regarding the m_ for member,
I agree that for private/protected variables an indicator is a good idea.
Regular members are always accessed by reference outside the object, so
it seems obvious that it is a member:
cache_read_vio->nbytes
is a member and it doesn't help (me) to have it be:
cache_read_vio->m_nbytes
Likewise, within a member function for the containing class I tend to think
of my own data members as local variables for a dynamic scope over
the collection of member functions. This is particularly true in an
event driven model where often the members are acting as local variables
for a co-routine formed by the activations of the Continuation. In that
case having them m_ seems to emphasize their heap load-store nature
rather than the dynamic execution state nature. One of the problems that
some people have with event driven programming is trying to get their
head around what to do with what they had previously considered to be
dynamic execution state, and it seems like it would not be helpful to those
folks to emphasize that these are really data members of heap bound objects.
john
