sandberg@anasazi.com (Mike Sandberg) writes:

>I am interested in an standards that you may have put together for
>using Hungarian Notation in your C++ environment.  I have reviewed
>material put toghether by Microsoft, but would also like to see
>how others are approaching this.

C++'s type-safe linkage elminates most of benefit of the use of
Hungarian notation, at least in it's full-blown form. Some naming
conventions are still useful, eg. writing type names in Mixed_Case and
variable names in lower_case, but there's not much point in going the
whole hog and encoding the types of variables in the names - the
compiler does this name mangling for you, automatically.

People sometimes mangle member names with some special prefix,
but I think that using "this->" is better.

--
Fergus Henderson                     This .signature virus might be
fjh@munta.cs.mu.OZ.AU                getting old, but you still can't
                                     consistently believe it unless you
Linux: Choice of a GNU Generation    copy it to your own .signature file!

In article <9318217.21933@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
|C++'s type-safe linkage elminates most of benefit of the use of
|Hungarian notation, at least in it's full-blown form. Some naming
|conventions are still useful, eg. writing type names in Mixed_Case and
|variable names in lower_case, but there's not much point in going the
|whole hog and encoding the types of variables in the names - the
|compiler does this name mangling for you, automatically.

I partially agree.  The compiler mangles some names for you --
particularly function names, and with typesafe function calls
there is not much call for hungarianizing the function names.
Variable names are not typically mangled by the compiler, and
it remains useful to consider hungarian for such.  Then you
arrive at a situation where the function + its typesafe hungarian
parms give you all the information that the old style of hungarian
gave you, gives it to you more conveniently, and with equal or better
safety.

Note that with the better encapsulation and abstraction that C++
provides, there is no good excuse to get into the old C situation
where you have a lot of stacked hungarian prefixes on variables.
Such is a clear indication you need to abstract out some levels.
What you are left with, then, are mainly simple variable names such as
"pFoo" meaning "pointer to a Foo" -- which is hardly a controversial
naming scheme! Or maybe god forbid a "pFooT" meaning "temporary pointer
to a Foo".  Most OOP and/or C++ programmers already have similar
naming conventions that they individually use.  The advantage of
hungarian is simply that it already has a margin of acceptance among
a variety of programmers at different companies and projects, thus
one is not trying to promulgate yet another incompatible personal
"standard".

|People sometimes mangle member names with some special prefix,
|but I think that using "this->" is better.

Agreed, but in practice its hard to enforce programmers writing the
"this->" since they can leave it off and the compiler accepts it
anyway.  If you stick those gross prefixes on members, then the
programmers have no choice except to use them.  And software testers
insist they need some help in figuring out which variables are members.
Further, sticking those gross prefixes on members forms an encouragement
to turn around immediately and write proper member functions encapsulating
access to those members, so there is no excuse why the class writer
needs to use those member variable prefixes more than a couple times
anyway.

Interested people can refer to the MFC classes source code shipped
with C7 and VC++, which use this simplified version of C++ hungarian.

I am interested in an standards that you may have put together for
using Hungarian Notation in your C++ environment.  I have reviewed
material put toghether by Microsoft, but would also like to see
how others are approaching this.

Michael Sandberg
Anasazi, Inc.
7500 N. Dreamy Draw Drive, Suite 120
Phoenix, AZ  85020

(602) 861-7608