Hungarian notation
Arun Sharma
Is anyone aware of a tool that removes the Hungarian notation from a
C/C++ program ?
I'm looking for something that'll convert something like:
WinAppSetGlobalVar to win_app_set_global_var
The world would be a much more beautiful place with it I think.
-Arun
--
Arun Sharma
Remove the _no_spam from the header to send me E-mail.
Scott Nemeth
Arun Sharma <asharma...@sco.com> wrote in article
<te912oe...@grandteton.cs.uiuc.edu>...
?WhyDoYouWantToGetRidOfTheHungarianNotation.
!ItsTheBestThingSinceSlicedBread.
catch_ya_later
smNemeth
sz = NULL terminated string
sm = String with a memory leak.
Eugene A. Pallat
Arun Sharma <asharma...@sco.com> wrote in article
<te912oe...@grandteton.cs.uiuc.edu>...
>
> Is anyone aware of a tool that removes the Hungarian notation from a
> C/C++ program ?
>
> I'm looking for something that'll convert something like:
>
> WinAppSetGlobalVar to win_app_set_global_var
>
> The world would be a much more beautiful place with it I think.
>
> -Arun
>
> --
> Arun Sharma
> Remove the _no_spam from the header to send me E-mail.
What's the problem? It's a trivial excersise to write a short C program to
do it.
Remove the '.' from orion.data for sending email to me.
Orion Data Systems
Solicitations to me must be pre-approved in writing
by me after soliciitor pays $1,000 US per incident.
Solicitations sent to me are proof you accept this
notice and will send a certified check forthwith.
Glynne Casteel
In <te912oe...@grandteton.cs.uiuc.edu> Arun Sharma
<asharma...@sco.com> writes:
>
>
>Is anyone aware of a tool that removes the Hungarian notation from a
>C/C++ program ?
>
>I'm looking for something that'll convert something like:
>
>WinAppSetGlobalVar to win_app_set_global_var
>
>The world would be a much more beautiful place with it I think.
Your replacement text is no more (or less) Hungarian than the
original....you have just replaced uppercase letters with an
underscore+lowercase combination.
Hungarian notation is where you prepend the variable name with some
sort of type information/abbreviation.
John Winters
In article <01bc4755$b5c1f1f0$10d4dece@apollo>,
Scott Nemeth <watc...@inetnebr.com> wrote:
>
>
>Arun Sharma <asharma...@sco.com> wrote in article
><te912oe...@grandteton.cs.uiuc.edu>...
>>
>> C/C++ program ?
>>
>> I'm looking for something that'll convert something like:
>>
>> WinAppSetGlobalVar to win_app_set_global_var
>>
>> The world would be a much more beautiful place with it I think.
>>
>>
>> --
>> Arun Sharma
>> Remove the _no_spam from the header to send me E-mail.
>>
>
>!ItsTheBestThingSinceSlicedBread.
^
Please note the negation symbol above.
John
--
John Winters. Wallingford, Oxon, England.
1997/04/12 Today I bought a new PC and deleted W95 from it. When reading
figures about how many copies of Windows there are in use, please subtract 5.
Why can't I buy a new PC without paying Microsoft tax?
Arun Sharma
On 12 Apr 1997 09:44:51 -0500, Arun Sharma wrote:
Arun> Is anyone aware of a tool that removes the Hungarian
Arun> notation from a C/C++ program ?
Arun> I'm looking for something that'll convert something
Arun> like:
Arun> WinAppSetGlobalVar to win_app_set_global_var
Arun> The world would be a much more beautiful place with it I
Arun> think.
Okay, an afternoon and a few cups of coffee later, the following piece
of Python code was born. It's a bit slow, but somebody can
probably fix it or rewrite it in <your favorite programming language
here>.
If the strict definition of the Hungarian notation is prefixing the
type to the variable name (which I also detest), you can fix it with a
simple query-replace.
Hope you find it useful. To find out more about Python, visit
www.python.org.
-Arun
--
Arun Sharma
--> Please delete the spam protection if you want to send mail.
---><---
#!/usr/bin/python
# The purpose of this program is to convert a C program written in
# Hungarian notation to "normal" C notation.
#
# Usage: hungarian [filename] [forbid_prefix]
#
# If filename is not given, uses stdin.
# If forbid prefix is given, anything starting with that prefix, will
# not be changed. For example
#
# hungarian foo.c Win > bar.c
#
# will "fix" all Hungarians, except those, starting with Win.
#
# Leaves comments alone, but fixes strings.
import sys
from string import *
from regsub import *
from regexp import *
comment_start = compile("\/\*")
comment_end = compile("\*\/")
# Convert the Hungarian notation to the American notation
def American(word):
global forbid_prefix
# if no mixed case, return the same word
if (upper(word) == word) or in_comment or match(forbid_prefix, word):
return word
# Scan the word, lowercasing it, with an underscore addition,
# whenever there is a case change.
index = 0
new_word = ''
for index in range(0, len(word)):
if not index:
change = 0
else:
last = word[index-1:index+1]
change = not ((last == upper(last)) or (last == lower(last)))
if change and (new_word[-2:-1] != '_') and len(new_word) > 1:
new_word = new_word + '_' + lower(word[index])
else:
new_word = new_word + lower(word[index])
index = index + 1
return new_word
def parse_comments(word):
global in_comment
if (comment_start.match(word)):
in_comment = 1
if (comment_end.match(word)):
in_comment = 0
return 0
def fix_line(str, pat='[^a-zA-Z0-9_]+'):
import string
words = splitx(str, pat)
for i in range(0, len(words), 2):
words[i] = American(words[i])
(i+1 < len(words)) and parse_comments(words[i+1])
return string.joinfields(words, "")
# main program
in_comment = 0
if (len(sys.argv) > 1):
file = open(sys.argv[1])
else:
file = sys.stdin
if (len(sys.argv) > 2):
forbid_prefix = sys.argv[2] + ".*"
else:
# A " .*" doesn't match anything in a word.
forbid_prefix = " "
while 1:
line = file.readline()
if not line:
break
line = fix_line(line)
sys.stdout.write(line)
Bob Stout
On 12 Apr 1997, Arun Sharma wrote:
> Is anyone aware of a tool that removes the Hungarian notation from a
> C/C++ program ?
>
> I'm looking for something that'll convert something like:
>
> WinAppSetGlobalVar to win_app_set_global_var
>
> The world would be a much more beautiful place with it I think.
First of all, you should learn what Hungarian notation is before
criticizing it. You can read up on it in SNIPPETS - see HUNGNOTE.TXT.
Then you'll see that neither of your exmaples above is Hungarian notation
but rather only mixed-case vs. lower-case-with underscores. This is a
trivial difference, BTW, except that using the underscores requires 4
extra keystrokes that aren't required with the mixed-case name (hint: the
shift key is required for both).
Once you've expanded your educational frontiers a little, then and only
then can you feel free to rant about *real* Hungarian notation which I
agree is really ugly and annoying.
-------------------------------------------------------------
MicroFirm: Down to the C in chips...
FidoNet 1:106/2000.6
Internet r...@snippets.org
Home of SNIPPETS - Current release:
ftp://snippets.org/pub/snippets/snip9611.zip & snip9611.taz (.tar.Z)
http://www.snippets.org/
juge.com:/c/snip9611.lzh
PDN nodes (SNIP9611.RAR) and SimTel mirror sites
Dmitry Tkach
Eugene A. Pallat wrote:
>
> Arun Sharma <asharma...@sco.com> wrote in article
> <te912oe...@grandteton.cs.uiuc.edu>...
> >
> > C/C++ program ?
> >
> > I'm looking for something that'll convert something like:
> >
> > WinAppSetGlobalVar to win_app_set_global_var
> >
> > The world would be a much more beautiful place with it I think.
> >
> >
> > --
> > Arun Sharma
> > Remove the _no_spam from the header to send me E-mail.
>
> do it.
Not really... You would have to avoid convertion of macros, typedefs,
reserver words, you should be able to skip comments etc.
It's not really too hard, but I would not say it's a "trivial" problem -
you would have to write a simple parser to do the job correctly...
R!ch
On 12 Apr 1997, Arun Sharma wrote:
> Is anyone aware of a tool that removes the Hungarian notation from a
> C/C++ program ?
vi? sed?
> I'm looking for something that'll convert something like:
>
> WinAppSetGlobalVar to win_app_set_global_var
>
> The world would be a much more beautiful place with it I think.
Couldn't agree more!
--
R!ch
If it ain't analogue, it ain't music.
#include <disclaimer.h> \\|// - ?
(o o)
/==================================oOOo=(_)=oOOo========\
| Richard Teer richar...@uk.sun.com |
| Sun Service Contractor |
| Voice: +44 (0)1276 691974 |
| .oooO |
| ( ) Oooo. |
\===================================\ (==( )==========/
\_) ) /
(_/
Si Ja
Arun Sharma wrote:
>
> Is anyone aware of a tool that removes the Hungarian notation from a
> C/C++ program ?
>
>
> WinAppSetGlobalVar to win_app_set_global_var
>
> The world would be a much more beautiful place with it I think.
>
Nope. I think you're going to tread on religious ground with this one.
Hopefully, you're not in the windows world, since all the APIs use this
mixed case scenario, and it'd be hard to differentiate.
good candidate for lex-yacc, though.
good luck!
js
danu...@antispam.halcyon.com
On Mon, 14 Apr 1997 17:40:59 -0400, Si Ja <si...@cyberus.ca> wrote:
>
>Nope. I think you're going to tread on religious ground with this one.
>Hopefully, you're not in the windows world, since all the APIs use this
>mixed case scenario, and it'd be hard to differentiate.
Not to mention that what is talking about is NOT Hungarian Notation in
the first place.
Joe Pannon
----------
REMINDER: Please correct my e-mail address in any personal reply by
removing the "antiSPAM." part from it. I have altered the address
in the hope of defeating address grabbing SPAM software. Thanks, JP
Stephan Wilms
R!ch wrote:
>
> On 12 Apr 1997, Arun Sharma wrote:
>
> > Is anyone aware of a tool that removes the Hungarian notation from a
> > C/C++ program ?
>
>
> > I'm looking for something that'll convert something like:
> >
> > WinAppSetGlobalVar to win_app_set_global_var
> >
> > The world would be a much more beautiful place with it I think.
>
Are both of you really shure, that you know, what you are talking about
?
The identifier "WinAppSetGlobalVar" is NOT related to what is loosely
known as the hungarian notation.
This is an example of hungarian notation in all it's beauty:
char *apszNames[10];
Note all those lowercase letters at the beginning of the identifier.
Stephan
R!ch
On Tue, 15 Apr 1997, Stephan Wilms wrote:
> Are both of you really shure, that you know, what you are talking about
> ?
> The identifier "WinAppSetGlobalVar" is NOT related to what is loosely
> known as the hungarian notation.
Agreed, we put the wrong lable on what we were describing, but IMHO,
mixed case identifiers are horrible. Hungarian Notation is *also*
horrible. No flame intended, but anyone who needs to embed the type
of a variable in its name needs to either learn to program, or pick
better names!
Craig Franck
R!ch <rich...@uk.sun.com> wrote:
>On Tue, 15 Apr 1997, Stephan Wilms wrote:
>
>> Are both of you really shure, that you know, what you are talking about
>> ?
>> The identifier "WinAppSetGlobalVar" is NOT related to what is loosely
>> known as the hungarian notation.
>
>Agreed, we put the wrong lable on what we were describing, but IMHO,
>mixed case identifiers are horrible.
This is generally known as Pascal style naming convention. I happen
to like it. It is mostly a matter of aesthetics.
>Hungarian Notation is *also*
>horrible. No flame intended, but anyone who needs to embed the type
>of a variable in its name needs to either learn to program, or pick
>better names!
I haven't heard such a well reasoned argument against something since
the last time I tuned into the Rush Limbaugh show!
>#include <disclaimer.h> \\|// - ?
> (o o)
> /==================================oOOo=(_)=oOOo========\
> | Richard Teer richar...@uk.sun.com |
> | Sun Service Contractor |
> | Voice: +44 (0)1276 691974 |
> | .oooO |
> | ( ) Oooo. |
> \===================================\ (==( )==========/
> \_) ) /
> (_/
Do you think I could get a government grant to study ASCII art?
--
Craig
clfr...@worldnet.att.net
Manchester, NH
Man is the only animal for whom his own existence is
a problem which he has to solve. -- Erich Fromm
Greg Comeau
In article <5j0lgu$6...@mtinsc04.worldnet.att.net> Craig Franck <clfr...@worldnet.att.net> writes:
>R!ch <rich...@uk.sun.com> wrote:
>>anyone who needs to embed the type
>>of a variable in its name needs to either learn to program, or pick
>>better names!
>
>I haven't heard such a well reasoned argument against something since
>the last time I tuned into the Rush Limbaugh show!
I don't see a smiley so cannot tell if you agree or disagree with him.
Surely you agree that most names do not need to be concerned about
their types literally in their names.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
Here:com...@comeaucomputing.com / BIX:comeau or com...@bix.com / CIS:72331,3421
Ron Forrester
>I don't see a smiley so cannot tell if you agree or disagree with him.
>Surely you agree that most names do not need to be concerned about
>their types literally in their names.
It depends on the language, or more specifically the data types one is
using.
In C/C++, arrays of char are used for all kinds of weird things, not just
strings, or buffers, or whatnot. So yes, in that case hungarian notation
is very useful -- if you are stuck with code making use of such things.
Now, if you are using a type name which has a specific purpose, and
a well understood and limited context, then naming the variable
appropriately is more than enough, for instance:
CString emloyeeName;
Everything has its place, and a place for everything...
Ron Forrester
Erik Funkenbusch
Greg Comeau wrote in article <5j0opf$b...@panix.com>...
>In article <5j0lgu$6...@mtinsc04.worldnet.att.net> Craig Franck
<clfr...@worldnet.att.net> writes:
>>R!ch <rich...@uk.sun.com> wrote:
>>>anyone who needs to embed the type
>>>of a variable in its name needs to either learn to program, or pick
>>>better names!
>>
>>I haven't heard such a well reasoned argument against something since
>>the last time I tuned into the Rush Limbaugh show!
>
>Surely you agree that most names do not need to be concerned about
>their types literally in their names.
Greg, I know you have a lot of experience in C++, but speaking as someone
that has had to endure other peoples naming conventions in programs that I
had to maintain I can say that *ANY* standard naming convention is a
blessing.
If someone names a variable paycheck, what is it? Is it a paycheck object,
is it the amount a person is paid? Is it the check number? Having to
search the code to find this is at best an annoyance, at worst a major
headache.
Perhaps you deal in perfectly written code that's been maintained by one
person, most of the world doesn't, and as such hungarian as a psuedo
standard (even if it's a variation on it) is better than having to manually
xref every variable. Sure, I might be able to guess what a variable might
be... but it's not always so. Especially in light of some of the code i've
seen where the type of a variable has been changed 5 times throughout the
years but retains the same name.
putting that type information in the name is an extra "push" on these
developers to keep their names in sync with their types (though of course
people still change types without changing names, I find it happens a lot
less often with hungarian being used).
I am by no means appologizing or condoning poor coding practices, but the
facts are that it's out there and you have to figure out some way to deal
with it.
Mark Wilden
Craig Franck <clfr...@worldnet.att.net> wrote in article
<5j0lgu$6...@mtinsc04.worldnet.att.net>...> >horrible. No flame intended, but anyone who needs to embed the type
> >of a variable in its name needs to either learn to program, or pick
> >better names!
>
> I haven't heard such a well reasoned argument against something since
> the last time I tuned into the Rush Limbaugh show!
In "Code Complete," Steve McConnell says that embedding the type in the
name is not "true" Hungarian. What was meant was to use standardized
prefixes for ways of using variables, such as "a" for array and "c" for
count.
Craig Franck
com...@panix.com (Greg Comeau) wrote:
>In article <5j0lgu$6...@mtinsc04.worldnet.att.net> Craig Franck <clfr...@worldnet.att.net> writes:
>>R!ch <rich...@uk.sun.com> wrote:
>>>of a variable in its name needs to either learn to program, or pick
>>>better names!
>>
>>I haven't heard such a well reasoned argument against something since
>>the last time I tuned into the Rush Limbaugh show!
>
Well, I was foolish to expect that everyone who reads this article
knows just who that person is, let alone what my feelings about
him are. If person does X they need to "learn to program"? The person
who came up with the hungarian programming convention knows how to
program. There is a very precise type system associated with it that
a good deal of thought was put into. You may not agree with it, but
it deserves more than a casual dismissal.
>Surely you agree that most names do not need to be concerned about
>their types literally in their names.
You can make a good argument either way. I would say that the most
important thing to know about a name is what class of object it
refers to. Anyway, I have seen people who bash Windows programming
conventions use p for a pointer and pp for a pointer to a pointer.
So, it has its uses even if hungarian is going way overboard with
a good thing.
Andrew Gierth
If you wish to continue a debate on a religious issue, then please narrow
your followups. I'd suggest avoiding the c.l.c - c.l.c++ crosspost, and
keeping out of comp.unix.programmer entirely.
--
Andrew.
comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
Mark Wilden
>
> I would say that the most
> important thing to know about a name is what class of object it
> refers to.
I don't know about that.
For one thing, it's perfectly acceptable to work with a pointer to a base
class without knowing that it really points to a derived class object.
For another, if a totally unrelated class pointer is used incorrectly, the
compiler will tell you. It often seems to me that embedding type
information in identifiers (which, as I've said, was not the intent of
Hungarian) is a way to perform precompilation type checking, which seems
unnecessary.
Brett J. Stonier
Greg Comeau wrote:
> Surely you agree that most names do not need to be concerned about
> their types literally in their names.
Out of curiosity, how do you distinguish, in a language like C/C++, the
difference between an integer, a long, a double, or a float? There are
times when this is quite important. I think that Hungarian-like
notation can be of use in situations like this.
John Nagle
"Brett J. Stonier" <bre...@brightwood.com> writes:
>Greg Comeau wrote:
>> Surely you agree that most names do not need to be concerned about
>> their types literally in their names.
>Out of curiosity, how do you distinguish, in a language like C/C++, the
>difference between an integer, a long, a double, or a float? There are
>times when this is quite important. I think that Hungarian-like
>notation can be of use in situations like this.
That's why C++ has type checking.
It's a weakness of C++ programming environments that you rarely
see a browser that displays the definition of a variable while you're
looking at code that uses it. Debuggers do better at this,
but they have the output of the compiler to work with. C++ is hard enough
to parse that few browsers really parse it; parsing is ambiguous
unless you process the include files, which is expensive.
John Nagle
Nick Leaton
Brett J. Stonier wrote:
>
> Greg Comeau wrote:
> > Surely you agree that most names do not need to be concerned about
> > their types literally in their names.
>
> Out of curiosity, how do you distinguish, in a language like C/C++, the
> difference between an integer, a long, a double, or a float? There are
> times when this is quite important. I think that Hungarian-like
> notation can be of use in situations like this.
>
OK, so give us an example
--
Nick
David Thornley
In article <3354EC...@brightwood.com>,
Brett J. Stonier <bre...@brightwood.com> wrote:
>Greg Comeau wrote:
>> Surely you agree that most names do not need to be concerned about
>> their types literally in their names.
>
>Out of curiosity, how do you distinguish, in a language like C/C++, the
>difference between an integer, a long, a double, or a float? There are
>times when this is quite important. I think that Hungarian-like
>notation can be of use in situations like this.
>
bar" or something like that. If it is too far away from the reference
to be convenient, the code's got more readability problems than
just finding types.
I have no tremendous objection to little prefixes that give some
clue as to what the variable is, in some sense, but encoding basic
type is utterly pointless.
David Thornley
Kaz Kylheku
In article <33542...@usamrid.isd.net>,
Erik Funkenbusch <chu...@isd.net> wrote:
>If someone names a variable paycheck, what is it? Is it a paycheck object,
>is it the amount a person is paid? Is it the check number? Having to
>search the code to find this is at best an annoyance, at worst a major
>headache.
So get an editor that can jump to the declaration of a name. I have one; it's
called vim.
So what if it was called ``paycheckObj''? Are you going to trust the _name_
to reveal to you the type? You still have to check the declaration.
>Perhaps you deal in perfectly written code that's been maintained by one
>person, most of the world doesn't, and as such hungarian as a psuedo
>standard (even if it's a variation on it) is better than having to manually
>xref every variable. Sure, I might be able to guess what a variable might
>be... but it's not always so. Especially in light of some of the code i've
>seen where the type of a variable has been changed 5 times throughout the
>years but retains the same name.
And so it should. The type of the variable is an implementation issue. Why
allow implementation issues to creep into your naming scheme? If you have
a set of abstract operations that are always used to work with the paycheck
object, then changing its representation should be possible without changing
the client code.
>putting that type information in the name is an extra "push" on these
>developers to keep their names in sync with their types (though of course
>people still change types without changing names, I find it happens a lot
>less often with hungarian being used).
Less often? So what you are saying is that _sometimes_ hungarian notation
users change the type without changing the name. Way to go!
Thus, in other words, you still have to ``cross reference'' to be certain you
know the variable's type. On top of all that, you have to deal with horrible
identifiers that look like ascii-encoded results from a one-way hashing
function.
>I am by no means appologizing or condoning poor coding practices, but the
>facts are that it's out there and you have to figure out some way to deal
>with it.
Right. With Hungarian Notation, you have just figured out one more way
to _cause_ poor coding practices.
Incidentally, the naming of important abstractions in a software project is not
a ``coding practice''. Many of the names may be decided upon even before any
code is written. I would restrict hungarian notation (or something similar) to
the naming of trivial local variables. E.g. a pointer name might
start with the letter 'p'.
Brett J. Stonier
Nick Leaton wrote:
> OK, so give us an example
Alot of the C++ code I deal with interfaces with an Oracle7 database,
using the OCI libraries. A typical OCI call looks like:
nResult = odefin(&gCur, 2, (char *)&gCurrentBoard.nNumOfUtter,
sizeof(int), OCI_DT_INT, -1, (short *)0, (char *)0, 0, 0, (short *)0,
(short *)0);
This one binds in a variable as a receive buffer from a SQL statement.
The type needs to be known in order to pass the proper constant (in this
case, OCI_DT_INT) to the function. Pass the wrong type constant and all
sorts of memory problems will appear.
Then, in less proprietary circumstances, a calculation:
fPLCBoardWidth = atoi(gszPLCWidth) / 1000;
If I were writing or debugging this line of code, I'd want to know what
type fPLCBoardWidth was. If it were an int, for example, the decimal
points would get lost.
It is surprising to me that so many people are standing by the blanket
statement that "Hungarian Notation is NEVER appropriate!" All I am
saying is that there are times when I've found it helpful. It may not
be useful in all situations and environments, but I have found it so in
some.
David Mikesell
Bill Kilgore wrote:
> OK, so I read the monograph, but it doesn't answere the burning
> question -- Why is it called "Hungarian"?? (Polish++?)
>
Invented by Charles Simonyi (sp?), an native of Hungary.
Wrote a book called the Hungarian Revolution...
--
Dave Mikesell
dmik...@ee.net
http://users1.ee.net/dmikesell
Brett J. Stonier
David Thornley wrote:
> I don't know about you, but I look for a line like "int foo" or "float
> bar" or something like that. If it is too far away from the reference
> to be convenient, the code's got more readability problems than
> just finding types.
So, if your code has readability problems, you might as well abandon all
attempts at order altogether? If you've ever done any maintenance
programming, I'm sure you can appreciate that you have no control over
the preceeding programmer's ability and desire to make things readable.
At these times, if at least a Hungarian-like notation is used, its been
of benefit to me. Patronization aside, "int foo" would be a good clue,
if it weren't buried among dozens of other globals and constants in a .h
file somewhere.
Erik Funkenbusch
Kaz Kylheku wrote in article <5j32sd$j...@bcrkh13.bnr.ca>...
>In article <33542...@usamrid.isd.net>,
>Erik Funkenbusch <chu...@isd.net> wrote:
>>If someone names a variable paycheck, what is it? Is it a paycheck
object,
>>is it the amount a person is paid? Is it the check number? Having to
>>search the code to find this is at best an annoyance, at worst a major
>>headache.
>
>So get an editor that can jump to the declaration of a name. I have one;
it's
>called vim.
I happen to like my editor for most purposes. Besides this issue,
constantly jumping around breaks concentration, and is generally annoying.
Tools are *NOT* a substitute for naming conventions. Everyone doesn't use
the same tools, and those tools are not universally available across all
platforms. It's just a bad idea to rely on a tool to make you productive
unless that's the only environment the code will *EVER* be used in (and is
that really likely?)
>So what if it was called ``paycheckObj''? Are you going to trust the
_name_
>to reveal to you the type? You still have to check the declaration.
Yes, I'm going to trust the name. If the name is wrong, it will give an
error. The point is, I have a reasonable idea of exactly the type of
object from just looking at it. If it's wrong, it will likely give a
warning or error. If the case of names not maching their types is rare
then you gain a *LOT* of productivity by using this method.
>>Perhaps you deal in perfectly written code that's been maintained by one
>>person, most of the world doesn't, and as such hungarian as a psuedo
>>standard (even if it's a variation on it) is better than having to
manually
>>xref every variable. Sure, I might be able to guess what a variable
might
>>be... but it's not always so. Especially in light of some of the code
i've
>>seen where the type of a variable has been changed 5 times throughout
the
>>years but retains the same name.
>
>And so it should. The type of the variable is an implementation issue.
Why
>allow implementation issues to creep into your naming scheme? If you
have
>a set of abstract operations that are always used to work with the
paycheck
>object, then changing its representation should be possible without
changing
>the client code.
"implementation issue" is a great word for properly designed code. Fact
is, there's a *LOT* of code out there that forces the implementation into
the interface. Rather than rewrite all this code, it's often easier to
simply change the names to reflect their types (you can even write a script
to do this, though you have to be careful about scoping rules) and make the
best of what you've got. In the business world, this is called legacy
code, and there's already been billions invested in it, companies don't
want to invest billions more to rewrite it.
Besides, the code that works with paycheck might not be c++, it could be
c.
>>putting that type information in the name is an extra "push" on these
>>developers to keep their names in sync with their types (though of
course
>>people still change types without changing names, I find it happens a
lot
>>less often with hungarian being used).
>
>Less often? So what you are saying is that _sometimes_ hungarian notation
>users change the type without changing the name. Way to go!
Sure, but it's much easier to fix the few instances where this happens than
to have to constantly wade through tons of warning messages because you
used an object as a pointer, or truncated the precision of a double. Or
worse yet, how about automatic conversion doing something you hadn't
planned on.
Sure, it's gonna happen anyways in poorly written code, but if there is
*SOME* kind of standard naming conventions, you at least have a things to
make your life easier most of the time.
>Thus, in other words, you still have to ``cross reference'' to be certain
you
>know the variable's type. On top of all that, you have to deal with
horrible
>identifiers that look like ascii-encoded results from a one-way hashing
>function.
As an example, I found some code where the author hadn't been very thorough
about const correctness. At one point, he used this class as a pointer to
character string, mistaking it for a char *. The compiler didn't warn him
about the problem, and it seemed to work.. for a while. When this mistaken
char * was returned from a function there was no way to know that it wasn't
really a char * at all. Proper naming conventions would have made this
problem easy to spot, and may have prevented it from even happening in the
first place.
Instead, it took a sr programmer 3 days to track down the problem (it
wasn't breaking the function that was the culprit, it was breaking
something else randomly). That's 3 days of unproductive work from a highly
paid developer that might never have happened if type notation was used.
hell, it doesn't even have to be complete, something like using sName to
signify a string object versus szName to signify a zero terminated string.
Additionally, warts such as the m_ virtually eliminate scoping problems if
you don't use globals (or use them sparingly).
>>I am by no means appologizing or condoning poor coding practices, but
the
>>facts are that it's out there and you have to figure out some way to
deal
>>with it.
>
>Right. With Hungarian Notation, you have just figured out one more way
>to _cause_ poor coding practices.
And how is that? Hungarian doesn't preclude good programming practices,
nor does it promote poor ones. It's simply a way to manage legacy code.
By writing your code today with hungarian, you help the green recruit next
year who's maintaining your program from making stupid mistakes.
>Incidentally, the naming of important abstractions in a software project
is not
>a ``coding practice''. Many of the names may be decided upon even before
any
>code is written. I would restrict hungarian notation (or something
similar) to
>the naming of trivial local variables. E.g. a pointer name might
>start with the letter 'p'.
That might be fine if you are designing a program from scratch. The *VAST*
majority of programming work is legacy though, and you're not allowed to
re-design it.
Out of curiosity, what *WOULD* you call naming conventions if not a 'coding
practice'? If you mean to imply that interface and property names are
typically chosen during the analysis and design phases of properly created
software, you're right. OOA&D is still relatively new in terms of accepted
practice though, and isn't usually applied to legacy code.
Remember, I'm not talking about the Microsofts, Borland's, IBM's, or
Lotus's here. I'm talking about The small company down the street with
100,000 lines of legacy dos code written by dozens of different contractors
over the last 15 years, and they want it moved to windows for a minimal
price.
Bob Stout
On Wed, 16 Apr 1997, Bill Kilgore wrote:
> OK, so I read the monograph, but it doesn't answere the burning
> question -- Why is it called "Hungarian"?? (Polish++?)
Because it was written by Charles Simonyi - a Microsoft employee of
Hungarian extraction. If it had been Charles Simonski, then it might have
been called Polish notation. <g,d&r>
Bill Kilgore
Bob Stout wrote:
>
> First of all, you should learn what Hungarian notation is before
> criticizing it. You can read up on it in SNIPPETS - see HUNGNOTE.TXT.
> Then you'll see that neither of your exmaples above is Hungarian notation
> but rather only mixed-case vs. lower-case-with underscores. This is a
> trivial difference, BTW, except that using the underscores requires 4
> extra keystrokes that aren't required with the mixed-case name (hint: the
> shift key is required for both).
>
> Once you've expanded your educational frontiers a little, then and only
> then can you feel free to rant about *real* Hungarian notation which I
> agree is really ugly and annoying.
OK, so I read the monograph, but it doesn't answere the burning
question -- Why is it called "Hungarian"?? (Polish++?)
--
( To email me, remove ".killspam" from my address. )
Darin Johnson
>It is surprising to me that so many people are standing by the blanket
>statement that "Hungarian Notation is NEVER appropriate!" All I am
>saying is that there are times when I've found it helpful. It may not
>be useful in all situations and environments, but I have found it so in
>some.
Maybe because so many people have NEVER found it useful. It's a leap
to say it's never appropriate, but it's not that surprising. Even
when it is useful, it's such a rare occurence that it doesn't appear
to justify the extra time and effort (in writing *and* reading). Why
not get rid of type declarations altogether, and just have the
compiler determine type from variable name? Back to the early Fortran
days then. Most people never run across such a mismatch error that
Hungarian catches that a compiler does not catch.
Contrast to what's being heard on the other side, "Hungarian notation
is ALWAYS appropriate". I haven't run across anyone who says it might
or might not be appropriate, and you should decide for yourself.
Note that there's a strong correlation between Hungarian notation
users (real hungarian notation, not uppercase versus underscore)
programming Windows or OS/2 and non-Hungarian users using other
systems. From this, one might unscientifically conclude that
programmers like what they learned under (although people use whatever
style their boss dictates). Or perhaps, Windows programmers run into
those odd bugs that Hungarian catches more often? I do find it
absolutely mind boggling that some Windows programmer with 5 years
total experience feels nothing wrong with telling some 50 year old
UNIX veteran how to do software engineering. I'm pretty sure these
veterans have run into all the same bugs, and all the same software
engineering snags that the rookies have.
>nResult = odefin(&gCur, 2, (char *)&gCurrentBoard.nNumOfUtter,
>sizeof(int), OCI_DT_INT, -1, (short *)0, (char *)0, 0, 0, (short *)0,
>(short *)0);
Ok, how then could "NumOfUtter" be anything but a number? Who has
ever gotten confused with it? Personally, "g" for global is fine, but
that's because it's so damned ugly that one is tempted to reduce the
number of globals :-) "gCur", oops, someone forgot the type prefix
here; not very politically correct, is it?
>fPLCBoardWidth = atoi(gszPLCWidth) / 1000;
This seems to be taken quite out of context. Is this a random
statement stuck in unrelated code? If so, stick in a comment to
clarify things! If this isn't unrelated code, I'm pretty sure
something *nearby* will say something about the types. Maybe someone
just assigned to fPLCBoardHeight; maybe the maintainer is supposed to
know that these are floating point numbers. And if the arg to atoi()
isn't a string, the programmer deserves what they get (and as has been
argued many times, the "z" is mostly redundant; when you have a string
without the "z", then this is the *exceptional* case, and prefixes are
deserved).
Heck, let's pull along all the type, class, module, and other
information, and we can have the language support it:
float::drawing::board::width = atoi(string::local::width)....
Trouble is, that's extra typing, and the *important* stuff is
obscured. What's important is the variable root name; I've seen HN
code where prefixes were long than the rest of the variable, gack.
And if you're doing C++, the type is dynamic, yet you can't change the
name dynamically...
--
Darin Johnson
da...@usa.net.delete_me
Aaron Gross
"Brett J. Stonier" <bre...@brightwood.com> writes:
>
> Greg Comeau wrote:
> > Surely you agree that most names do not need to be concerned about
> > their types literally in their names.
>
> Out of curiosity, how do you distinguish, in a language like C/C++, the
> difference between an integer, a long, a double, or a float? There are
> times when this is quite important. I think that Hungarian-like
> notation can be of use in situations like this.
By looking at the variable declaration. If it's not extremely fast and
easy to find, your function's too long. (OK, this is for C; in C++, I
guess you have to look at the class declaration. I assume you'd have
this handy in your editing session, class browser, or whatever.)
> Brett S.
> http://www.mtjeff.com/~calvin/devhbook
Aaron
Boyd Roberts
In article <Pine.LNX.3.91.970416...@weck.brokersys.com>, Bob Stout <r...@snippets.org> writes:
>
>Because it was written by Charles Simonyi - a Microsoft employee of
>Hungarian extraction.
Yes, it's that basket case Simonyi complete with his 'Meta-Programmer' doctrine.
Hungarian notation just adds extra clutter to each declaration and use. In
a small language like C it is usually obvious from the context what type the
variable is. If you need other aids it would imply that there are too many
variables in the current scope -- bad design.
--
Boyd Roberts <bo...@france3.fr> N 31 447109 5411310
``Not only is UNIX dead, it's starting to smell really bad.'' -- rob
Nick Leaton
Brett J. Stonier wrote:
>
> Nick Leaton wrote:
> > OK, so give us an example
>
> Alot of the C++ code I deal with interfaces with an Oracle7 database,
> using the OCI libraries. A typical OCI call looks like:
>
> sizeof(int), OCI_DT_INT, -1, (short *)0, (char *)0, 0, 0, (short *)0,
> (short *)0);
>
> The type needs to be known in order to pass the proper constant (in this
> case, OCI_DT_INT) to the function. Pass the wrong type constant and all
> sorts of memory problems will appear.
>
> Then, in less proprietary circumstances, a calculation:
>
>
> type fPLCBoardWidth was. If it were an int, for example, the decimal
> points would get lost.
>
> statement that "Hungarian Notation is NEVER appropriate!" All I am
> saying is that there are times when I've found it helpful. It may not
> be useful in all situations and environments, but I have found it so in
> some.
OK so you are writting code that is handling base types, and you want to
have something like integer_parameter float_parameter. That is ok. What
I really find wrong with Hungarian is that you are defining the type of
the variable every time you use it. Change the type and you have a big
edit renaming the variable. Now, if you have a good browser, you don't
worry, you just click to get the declaration.
--
Nick
Daniel P Hudson
"Brett J. Stonier" <bre...@brightwood.com> wrote:
>Greg Comeau wrote:
>> Surely you agree that most names do not need to be concerned about
>> their types literally in their names.
>Out of curiosity, how do you distinguish, in a language like C/C++, the
>difference between an integer, a long, a double, or a float? There are
>times when this is quite important. I think that Hungarian-like
>notation can be of use in situations like this.
Brett, this is a personal opinion, just as most style related issues are.
Some people find
top:
++a;
if (a < 20) goto top;
harder to read than
do
{
++a;
} while ( a < 20);
and some people feel that iCount should just be count
and if you forget the type then you scroll back until
you find the decleration or in most modern IDE's use
the search facility. Deal with it, is all I can say.
Usually your style is completely irrelevant to the style
your boss wants you to use anyway.
Kaz Kylheku
In article <Pine.LNX.3.91.970416...@weck.brokersys.com>,
>> question -- Why is it called "Hungarian"?? (Polish++?)
>
I knew there had to be something more deeply sinister behind such rubbish. :))
Kaz Kylheku
In article <3355a...@usamrid.isd.net>,
Erik Funkenbusch <chu...@isd.net> wrote:
> Kaz Kylheku wrote in article <5j32sd$j...@bcrkh13.bnr.ca>...
>>In article <33542...@usamrid.isd.net>,
>>Erik Funkenbusch <chu...@isd.net> wrote:
>>>If someone names a variable paycheck, what is it? Is it a paycheck
>object,
>>>is it the amount a person is paid? Is it the check number? Having to
>>>search the code to find this is at best an annoyance, at worst a major
>>>headache.
>>
>>So get an editor that can jump to the declaration of a name. I have one;
>it's
>>called vim.
>
>I happen to like my editor for most purposes. Besides this issue,
>constantly jumping around breaks concentration, and is generally annoying.
>
>Tools are *NOT* a substitute for naming conventions. Everyone doesn't use
>the same tools, and those tools are not universally available across all
>platforms. It's just a bad idea to rely on a tool to make you productive
>unless that's the only environment the code will *EVER* be used in (and is
>that really likely?)
>
>>So what if it was called ``paycheckObj''? Are you going to trust the
>_name_
>>to reveal to you the type? You still have to check the declaration.
>
>Yes, I'm going to trust the name. If the name is wrong, it will give an
>error. The point is, I have a reasonable idea of exactly the type of
This is true regardless of how you name it, though. So your point is basically
that if the name is correct, you know what operations you can apply to the
object without having to lookup the declaration. Fair enough, but with good
editing tools, you can get the same thing without name mangling. For example,
with the Vim editor I can use a tags file to ``hypersurf'' for global symbols.
For local symbols, it suffices that it has the '*' and '#' commands. When
you type # when the cursor is over an identifier, it will jump to the previous
occurence. When you type * it will jump to the next occurence. Since I
tend to write small functions, this is good enough. But like you said,
this is talking about new development rather than legacy code. In legacy
code you find things like 700 line functions with dozens of local variables.
>object from just looking at it. If it's wrong, it will likely give a
>warning or error. If the case of names not maching their types is rare
>then you gain a *LOT* of productivity by using this method.
I get a lot more productivity by using names that aren't cluttered with
suffixes and prefixes that make them hard to type. And I can just put the
cursor over ``paycheck'', hit a little key and jump right to the declaration.
Hit another key and jump back. Besides, if you have to do a lot of such
jumping, perhaps you are either depending too much on global variables or are
making yoru functions too damn long so that they span many screen lengths.
That's poor coding practice, indicating that the programmer needs to know how
to factor code blocks into subfunctions.
>"implementation issue" is a great word for properly designed code. Fact
>is, there's a *LOT* of code out there that forces the implementation into
>the interface. Rather than rewrite all this code, it's often easier to
>simply change the names to reflect their types (you can even write a script
>to do this, though you have to be careful about scoping rules) and make the
>best of what you've got. In the business world, this is called legacy
>code, and there's already been billions invested in it, companies don't
>want to invest billions more to rewrite it.
I'd be happy to admit that HN should be relegated to legacy code maintenance,
and never used in new projects.
>That might be fine if you are designing a program from scratch. The *VAST*
>majority of programming work is legacy though, and you're not allowed to
>re-design it.
Okie.
>Out of curiosity, what *WOULD* you call naming conventions if not a 'coding
>practice'? If you mean to imply that interface and property names are
It depends whether we are talking about naming conventions for temporary
local variables that are used in the implementations behind the abstractions,
or whether we are talking about the naming of fundamental abstractions used
in the whole program.
It's a mere coding practice when you call some insignificant integral loop
variable is called 'i' or a character pointer called 'p'.
David Hanley
Erik Funkenbusch wrote:
>
> If someone names a variable paycheck, what is it? Is it a paycheck object,
> is it the amount a person is paid? Is it the check number? Having to
> search the code to find this is at best an annoyance, at worst a major
> headache.
>
> person, most of the world doesn't, and as such hungarian as a psuedo
> standard (even if it's a variation on it) is better than having to manually
> xref every variable.
I couldn't disagree more. If you see :
paycheck = paycheck * 1.10;
Why do you care if it's a integer, float, object, or whatever? What's
the point of abstraction or object-orientedness?
> putting that type information in the name is an extra "push" on these
> developers to keep their names in sync with their types (though of course
> people still change types without changing names, I find it happens a lot
> less often with hungarian being used).
That's only an issue if you expect the name of a variable to describe
the type.
dave
Kaz Kylheku
In article <335545...@brightwood.com>,
>> OK, so give us an example
>
>Alot of the C++ code I deal with interfaces with an Oracle7 database,
>using the OCI libraries. A typical OCI call looks like:
>
>nResult = odefin(&gCur, 2, (char *)&gCurrentBoard.nNumOfUtter,
>sizeof(int), OCI_DT_INT, -1, (short *)0, (char *)0, 0, 0, (short *)0,
>(short *)0);
I still have no clue what types the objects are. Show the declarations,
then perhaps the notation might make sense.
>This one binds in a variable as a receive buffer from a SQL statement.
>The type needs to be known in order to pass the proper constant (in this
>case, OCI_DT_INT) to the function. Pass the wrong type constant and all
>sorts of memory problems will appear.
>
>Then, in less proprietary circumstances, a calculation:
>
>fPLCBoardWidth = atoi(gszPLCWidth) / 1000;
I don't know any type in C that starts with a 'g'. I take it that the 'sz'
stands for zero terminated string to contrast the variable against all those
other kinds of string representations that are frequently used in C.
By the way, does the 'f' in fPLCBoardWidth (boy that's hard to type) imply that
it's a floating point type? If so, don't you want the division to be done in
floating point? (Maybe you do, it's out of context).
>If I were writing or debugging this line of code, I'd want to know what
>type fPLCBoardWidth was. If it were an int, for example, the decimal
>points would get lost.
The ``decimal points'' are getting lost, because you divided an integer by an
integer.
Needless to say, you aren't making a very good recommendation for this obscure
notation. Perhaps you are naively expecting the 'f' to cause the operands on
the right hand side to be coerced to float.
>It is surprising to me that so many people are standing by the blanket
>statement that "Hungarian Notation is NEVER appropriate!" All I am
I stand by it. It's for fools, not for programmers.
>saying is that there are times when I've found it helpful. It may not
It may be helpful to you initially, but I think you owe it to the maintainers
to write a tool which will convert the names to something sensible.
jawalker dp beckman com
On 17 Apr 1997 02:12:27 GMT, afn0...@freenet2.afn.org (Daniel P
Hudson) wrote:
[reply [&<]'ed]
>>Out of curiosity, how do you distinguish, in a language like C/C++, the
>>difference between an integer, a long, a double, or a float? There are
>>times when this is quite important. I think that Hungarian-like
>>notation can be of use in situations like this.
>
[&<]
In many cases if your app is that dependant on knowing that a variable
is an int &tc, your design is probably broken. Hungarian won't help
you.
Brett J. Stonier
Darin Johnson wrote:
> Maybe because so many people have NEVER found it useful.
There seems to be alot of people in this thread who *have* found it
useful. Hence, the thread's proliferation.
> Contrast to what's being heard on the other side, "Hungarian notation
> is ALWAYS appropriate". I haven't run across anyone who says it might
> or might not be appropriate, and you should decide for yourself.
Actually, that's been my take on things all along. My original question
was an honest one, in which I was trying to understand the reasoning
behind the statement that HN serves no purpose, so that I might benefit
from this wisdom. Somehow I ended up on the pro-HN side of the
argument, but that is not what I intended.
> Ok, how then could "NumOfUtter" be anything but a number? Who has
> ever gotten confused with it? Personally, "g" for global is fine, but
> that's because it's so damned ugly that one is tempted to reduce the
> number of globals :-) "gCur", oops, someone forgot the type prefix
> here; not very politically correct, is it?
It could easily be a long, in which case the function call would be
binding in the wrong length of variable. But, perhaps this is a special
case situation.
> >fPLCBoardWidth = atoi(gszPLCWidth) / 1000;
>
> This seems to be taken quite out of context. Is this a random
> statement stuck in unrelated code? If so, stick in a comment to
> clarify things! If this isn't unrelated code, I'm pretty sure
> something *nearby* will say something about the types. Maybe someone
> just assigned to fPLCBoardHeight; maybe the maintainer is supposed to
> know that these are floating point numbers. And if the arg to atoi()
> isn't a string, the programmer deserves what they get (and as has been
> argued many times, the "z" is mostly redundant; when you have a string
> without the "z", then this is the *exceptional* case, and prefixes are
> deserved).
Yes, this was a bad example. And I don't have the time right now to
spend coming with better ones. Remember that I'm not necessarily trying
to argue the pro-HN side of things -- I'm just trying to understand both
sides.
The pro-HN argument seems to be that Good Programming eliminates the
need for notation, since datatypes are obvious. That since obscure
global variables buried in .h files or large functions are bad
programming, they do not justify the notation. Perhaps this is correct
-- from a development team management standpoint, it may be more
important to emphasize good programming than to enforce a standard
notation.
However, this sort of programming (numerous globals, large functions,
non-cohesive sections of code, etc.) has been the reality of the code
which I've inherited from other programmers. Add to this that my
development environments have had no nifty declaration lookup feature,
and the presence of HN has been of benefit to me in these times. This
is why I've always had the impression that it is a good thing, and is
why I asked my original question.
Mark Wilden
Boyd Roberts <bo...@france3.fr> wrote in article
<5j4otc$chq$1...@route1.mdrf.france3.fr>...
>
> Yes, it's that basket case Simonyi complete with his 'Meta-Programmer'
doctrine.
>
> Hungarian notation just adds extra clutter to each declaration and use.
In
> a small language like C it is usually obvious from the context what type
the
> variable is. If you need other aids it would imply that there are too
many
> variables in the current scope -- bad design.
I'll just say it again, in case the point was lost the first time: Simonyi
did _not_ advocate embedding type information in variable names.
danu...@antispam.halcyon.com
On 17 Apr 1997 09:01:32 GMT, Boyd Roberts <bo...@france3.fr> wrote:
>
>Yes, it's that basket case Simonyi complete with his 'Meta-Programmer'
>doctrine.
Interesting. And what's your claim to fame, being so self-assured and
all?
Joe Pannon
----------
REMINDER: Please correct my e-mail address in any personal reply by
removing the "antiSPAM." part from it. I have altered the address
in the hope of defeating address grabbing SPAM software. Thanks, JP
Greg Comeau
FYI, I have posted a number of responses to the Hungarian notation thread
to comp.lang.c and compl.lang.c++, and not to this NG.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
Here:com...@comeaucomputing.com / BIX:comeau or com...@bix.com / CIS:72331,3421
Darin Johnson
>It could easily be a long, in which case the function call would be
>binding in the wrong length of variable. But, perhaps this is a special
>case situation.
Um, this isn't assembler; the compiler knows how to convert types and
give warning. If I pass a long to something expecting a short, I get
an error, if I pass a short to something expecting a long, it gets
converted. But it doesn't help knowing which it is, because you don't
know what the function takes without looking at its definition (I
think knowing the types that a function takes is MUCH more useful than
having a type prefix on a variable; note how Smalltalk does it).
I think most of my objection to HN is that it's treated as a simple
solution to a complex problem (a quick fix ala midnight basketball or
boot camp prison). It only catches an extremely rare set of problems,
yet is the most prominent code feature in programs that use it.
Novice programmers are tempted to think they're safe and practicing
good software engineering.
For strongly typed languages, HN is redudndant nearly all the time; it
may have been a lot more useful when Microsoft standardized on it when
pre-ANSI C was used and they had an overabundance of type mixing. But
Microsoft is a poor example, as almost all the code I've seen from
them is atrocious, yet HN is used religiously. This exacerbates the
problems, because novices often (I hear them bragging) copy their
style from Microsoft and then think the're writing good code.
As for myself, I have never seen a piece of code that used HN that was
also well written. I'm not saying they don't exist, but the evidence
is lacking from my end (and I'm not going to blindly trust the advice
of someone from the net, especially a pro-Microsoft someone).
And along the lines of software engineering; where are the academic or
research papers that show anything at all about HN? Has any study
been done on it, or is it just another "it works for me, so it must
work for you too" method?
>Yes, this was a bad example. And I don't have the time right now to
>spend coming with better ones. Remember that I'm not necessarily trying
>to argue the pro-HN side of things -- I'm just trying to understand both
>sides.
Ok, both sides (badly stereotyping both)
Pro: It makes my code more readable, and catches many bugs that would
not be found otherwise. Microsoft invented it, and Microsoft is
successful, so I'll copy it. It's self evident just from looking at
it how good it is.
Con: It messes up the code and makes it unreadable; and it conflicts
with the standard naming style I've used and developed for twenty
years. If it does catch mistakes for you, then you need a better
compiler. I never make those mistakes anyway. It's self evident that
you're just using it blindly.
OK, not sterotyping so much now...
Pro: It really takes little effort, and catches bugs.
Con: It is tedious to use, makes the code unreadable, and doesn't
catch more bugs.
>Perhaps this is correct
>-- from a development team management standpoint, it may be more
>important to emphasize good programming than to enforce a standard
>notation.
Standard notations have been dictated and argued about since
programming languages were invented; literally. HN is just the latest
in a long string, there's no reason to assume it's better or more
profound. I think this is what irks the veterans so much, they've
seen these come and go, and don't need to hear another "this time,
this is the answer".
--
Darin Johnson
da...@usa.net.delete_me
Joseph M. O'Leary
jawalker @ ccgate dp beckman com wrote in article
<33564a73...@134.217.241.216>...
Sometimes it's the operating system that is dependent on the type of
variable. If I am writing a Win32 Program and I call, say the Win32
function ::GetWindowRgn(), I know that my return value (a code) has to be
an int. Period. I have no control over this and cannot redesign around
it. Microsoft writes the API, not me.
Even if I attempt to wrap this up in a class (like MFC's CWnd class), I
still have to deal with this type in my class function that wraps this
functionality. I need to know an exact type so it makes sense to say.
...
int iCode = ::GetWindowRgn(hWnd, hRgn);
...
In cases such as this, Hungarian helps.
Joe'
Phil Edwards
Right, it's a holy war now... followups directed appropriately.
Erik Funkenbusch <chu...@isd.net> wrote:
[snip]
+ As an example, I found some code where the author hadn't been very thorough
+ about const correctness. At one point, he used this class as a pointer to
+ character string, mistaking it for a char *.
+ The compiler didn't warn him about the problem,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ and it seemed to work.. for a while. When this mistaken
+ char * was returned from a function there was no way to know that it wasn't
+ really a char * at all. Proper naming conventions would have made this
+ problem easy to spot, and may have prevented it from even happening in the
+ first place.
A decent compiler would have "prevented it from even happening in the first
place". I refuse to change readable names into alphabet soup because my
compiler might be a piece of crap. Investing in a compiler may cost more
money than what the senior developer was paid during those three days to fix
it, but it will pay off in the long run.
+ hell, it doesn't even have to be complete, something like using sName to
+ signify a string object versus szName to signify a zero terminated string.
[snip]
+ Hungarian doesn't preclude good programming practices,
+ nor does it promote poor ones. It's simply a way to manage legacy code.
+ By writing your code today with hungarian, you help the green recruit next
+ year who's maintaining your program from making stupid mistakes.
Odd. By writing my code with COMMENTS, I do the same thing, AND produce
readable variable and function names.
/dev/phil
Boyd Roberts
In article <5j6stu$3lc$1...@halcyon.com>, danu...@antiSPAM.halcyon.com >
>Interesting. And what's your claim to fame, being so self-assured and
>all?
My claim to fame? I believe it's being so self-assured and all.
R!ch
On Thu, 17 Apr 1997, Brett J. Stonier wrote:
> The pro-HN argument seems to be that Good Programming eliminates the
> need for notation, since datatypes are obvious. That since obscure
> global variables buried in .h files or large functions are bad
> programming, they do not justify the notation. Perhaps this is correct
> -- from a development team management standpoint, it may be more
> important to emphasize good programming than to enforce a standard
> notation.
I think you ment to say "The anti-HN argument...".
--
R!ch
If it ain't analogue, it ain't music.
#include <disclaimer.h> \\|// - ?
(o o)
/==================================oOOo=(_)=oOOo========\
| Richard Teer richar...@uk.sun.com |
| Sun Service Contractor |
| Voice: +44 (0)1276 691974 |
| .oooO |
| ( ) Oooo. |
\===================================\ (==( )==========/
\_) ) /
(_/
Erik Funkenbusch
Boyd Roberts wrote in article <5j4otc$chq$1...@route1.mdrf.france3.fr>...
>In article <Pine.LNX.3.91.970416...@weck.brokersys.com>,
Bob Stout <r...@snippets.org> writes:
>>
>>Because it was written by Charles Simonyi - a Microsoft employee of
>
>Yes, it's that basket case Simonyi complete with his 'Meta-Programmer'
doctrine.
>
In
>a small language like C it is usually obvious from the context what type
the
>variable is. If you need other aids it would imply that there are too
many
>variables in the current scope -- bad design.
I keep hearing this, and it's a valid point.
The problem is, there are far more dysfunctional software houses out there
than functional ones. Being a contractor and often having to go into a new
company and work with existing software means I have no control over how
well the code was designed. It means that I have to figure out a way to
make this code maintainable without rewriting it (clients seldom will pay
for a complete rewrite of code that works now, and just needs a "little
tweaking"). If this is a one-time shot, i'll probably ignore naming
conventions and use whatever they are using to keep it consistent. If this
is a long term thing, then it's a totally different story.
I've also worked in houses where it was impossible to enforce "good
designs". Management is the primary problem. They refuse to enforce
design standards, code reviews, or other disciplines. All they care about
is that the software get's written in time to meet their unrealistic
timelines. formal process get's in the way of delivering software that
sortof works.
It's just not reality in most cases to say "good design will eleviate this"
because it's impossible to enforce good design. I think hungarian is a
great "lesser of two evils" for these situations.
Brett J. Stonier
Darin Johnson wrote:
> Um, this isn't assembler; the compiler knows how to convert types and
> give warning. If I pass a long to something expecting a short, I get
> an error, if I pass a short to something expecting a long, it gets
> converted.
Again, this was probably not the best example, as it was a special
case. In this situation (an Oracle OCI library call,) the variable
you're binding into a SQL statement is passed by sending the address of
the variable type casted to a char *. Then, based upon the constant
sent in another parameter, the function knows the type of the variable
you are binding in.
> Ok, both sides (badly stereotyping both)
>
> Pro: It makes my code more readable, and catches many bugs that would
> not be found otherwise. Microsoft invented it, and Microsoft is
> successful, so I'll copy it. It's self evident just from looking at
> it how good it is.
>
> Con: It messes up the code and makes it unreadable; and it conflicts
> with the standard naming style I've used and developed for twenty
> years. If it does catch mistakes for you, then you need a better
> compiler. I never make those mistakes anyway. It's self evident that
> you're just using it blindly.
>
> OK, not sterotyping so much now...
>
> Pro: It really takes little effort, and catches bugs.
>
> Con: It is tedious to use, makes the code unreadable, and doesn't
> catch more bugs.
This is what I was searching for all along. Thx for your thoughtful
reply.
Brett J. Stonier
R!ch wrote:
> I think you ment to say "The anti-HN argument...".
Yes, I did. Thanks for catching that.
danu...@antispam.halcyon.com
On 18 Apr 1997 09:15:23 GMT, Boyd Roberts <bo...@france3.fr> wrote:
>In article <5j6stu$3lc$1...@halcyon.com>, danu...@antiSPAM.halcyon.com >
>>Interesting. And what's your claim to fame, being so self-assured and
>>all?
>
>My claim to fame? I believe it's being so self-assured and all.
So I figured.
Darin Johnson
In article <01bc4b52$b9954420$550228ce@default>, Mark Wilden wrote:
>I'll just say it again, in case the point was lost the first time: Simonyi
>did _not_ advocate embedding type information in variable names.
True. Very ironic actually. Microsoft didn't fully understand what
Simonyi was doing, but used and advocated their variant of it.
Nowdays, novices don't fully understand HN, but use it and advocate it
anyway.
Never think you understand something you don't, it historically leads
to many problems. For instance, Microsoft looks at what Simonyi does,
distills it down, and concludes that his notation is key to his
programs' quality. But Simonyi undoubtedly had a full complete
programming methodology, most of which was probably ignored by the
people looking for a magic bullet to fix software quaility problems.
There is no magic bullet; and unfortunately, I see too many HN
advocates that imply this.
More examples along these lines, fictitious, but similar things have
really happened: Person feels lousy and all diets are failing; finally
decides to get serious, and eats less, excercises more, and spends
lots of money on acupuncture; then tells people "boy, that acupuncture
really made me finally lose weight and get energy". 80's managers see
Japanese companies doing well, notice that Japanese have a different
diet than Americans, and appoint a task force to determine the optimum
diet so their workers will do more work.
Microsoft doesn't understand software engineering or good programming
practices. It hires bright people, but also screens out people that
could provide new insights with its interviewing practices (even
applicants with PhDs have to take trivia tests there, and the
interviewers generally don't understand that a test question can have
more than one right answer, etc). So they end up with bright people
that think the same way, when what they need are bright people willing
to tell them what they're doing wrong and how they might improve.
(there are exceptions, some of the MS departments are better than
others)
--
Darin Johnson
da...@usa.net.delete_me
Fernando Ortiz
jawalker @ ccgate dp beckman com wrote in article
<33564a73...@134.217.241.216>...
> On 17 Apr 1997 02:12:27 GMT, afn0...@freenet2.afn.org (Daniel P
> Hudson) wrote:
> [reply [&<]'ed]
> >"Brett J. Stonier" <bre...@brightwood.com> wrote:
> >
>
> >>Out of curiosity, how do you distinguish, in a language like C/C++, the
> >>difference between an integer, a long, a double, or a float? There are
> >>times when this is quite important. I think that Hungarian-like
> >>notation can be of use in situations like this.
> >
> [&<]
> In many cases if your app is that dependant on knowing that a variable
> is an int &tc, your design is probably broken. Hungarian won't help
> you.
>
I keep hearing this argument..."if your app is dependant on knowing the
type you're working on..." etc etc etc. I want to know when its *not*
important to know this! I guess if you write silly little utilities all
day that never need to count higher than 10 or 20, then it doesn't matter
to know. But if you need to go above 32000, 16 million, below 0, then you
had better know!
Fernando Ortiz
Erik Funkenbusch <chu...@isd.net> wrote in article
> It's just not reality in most cases to say "good design will eleviate
this"
> because it's impossible to enforce good design. I think hungarian is a
> great "lesser of two evils" for these situations.
This is what it all comes down to. For those of us in the "real" world,
hungarian notation is very useful because it makes code easier to maintain.
Most pre-written code will *not* get rewritten. And the reason most
designs LOOK bad is because hindsight is 20/20. I've been involved in
several long term projects that were eventually rewritten. They were well
designed software at first, but later, market realities can take software
in different directions that make it difficult to maintain...so it gets
rewritten because the original design no longer fits where the software is
headed.
Some developers hate hungarian notation. But without it, their job would
be a lot more difficult. Hungarian notation solved a lot more problems
than it created.
Fernando
Fernando Ortiz
Kaz Kylheku <k...@vision.crest.nt.com> wrote in article
<5j5h7k$8...@bcrkh13.bnr.ca>...
> In article <335545...@brightwood.com>,
> Brett J. Stonier <bre...@brightwood.com> wrote:
> >Nick Leaton wrote:
> >> OK, so give us an example
> >nResult = odefin(&gCur, 2, (char *)&gCurrentBoard.nNumOfUtter,
> >sizeof(int), OCI_DT_INT, -1, (short *)0, (char *)0, 0, 0, (short *)0,
> >(short *)0);
>
> I still have no clue what types the objects are. Show the declarations,
> then perhaps the notation might make sense.
>
You just gave an example why hungarian is useful...i'm looking at the code
and I make sense of it. You're saying "show the
declarations...then...might make sense".
> I don't know any type in C that starts with a 'g'. I take it that the
'sz'
> stands for zero terminated string to contrast the variable against all
those
> other kinds of string representations that are frequently used in C.
You seem to be criticizing hungarian (or hungarian-like notation) without
even knowing it. g means global variable (ie, defined outside the
function) and hungarian does *not* always start with the first letter of
the type.
> >It is surprising to me that so many people are standing by the blanket
> >statement that "Hungarian Notation is NEVER appropriate!" All I am
>
> I stand by it. It's for fools, not for programmers.
You sound like the fool here...you're criticizing something without knowing
anything about it or how its used. Ever hear the saying "keep your mouth
shut and be thought a fool or open it and remove all doubt"? Applies well
here.
Fernando
a-...@signature.below.d
In article <335558EF...@ee.net>, David Mikesell <dmik...@ee.net> wrote:
>Bill Kilgore wrote:
>
>> OK, so I read the monograph, but it doesn't answere the burning
>> question -- Why is it called "Hungarian"?? (Polish++?)
>>
>
>Wrote a book called the Hungarian Revolution...
The system of prefixing variable names existed long before M$ even existed. It
was not invented at Microsoft.
John
------------------------------------------------
Big Brother is watching and keeping track of what
you post. I have removed my personal information
from the header and moved it here.
EMail Address:
|miano @ |
|worldnet . |
| att . net |
Full Name:
------------
-John?Miano-
------------
Craig Franck
a-...@signature.below.d wrote:
>In article <335558EF...@ee.net>, David Mikesell <dmik...@ee.net> wrote:
>>Bill Kilgore wrote:
>>
>>> OK, so I read the monograph, but it doesn't answere the burning
>>> question -- Why is it called "Hungarian"?? (Polish++?)
>>>
>>
>> Invented by Charles Simonyi (sp?), an native of Hungary.
>>Wrote a book called the Hungarian Revolution...
>
>The system of prefixing variable names existed long before M$ even existed. It
>was not invented at Microsoft.
No one is saying it was. They are saying Hungarian notation was
invented by Mr. Simonyi and he works(ed) for Microsoft. (Hungarian
notation is a lot more sophisticated then "slapping on a prefix
here and there".) :-)
>John
>
>------------------------------------------------
>Big Brother is watching and keeping track of what
>you post. I have removed my personal information
>from the header and moved it here.
>
>EMail Address:
>|miano @ |
>|worldnet . |
>| att . net |
>
>Full Name:
>------------
>-John?Miano-
>------------
That just slows 'em down...
--
Craig
clfr...@worldnet.att.net
Manchester, NH
"We are going to build that bridge to the 21st century -- yadda,
yadda, yadda" (Bill Clinton). "I would never buy a used car from
Richard Nixon -- unless he was drunk" (Hunter S. Thompson).
a-...@signature.below.d
In article <5jbmhp$2...@mtinsc05.worldnet.att.net>, Craig Franck <clfr...@worldnet.att.net> wrote:
> (Hungarian
>notation is a lot more sophisticated then "slapping on a prefix
>here and there".) :-)
That was supposed to be funny, wasn't it?
Jeffrey C. Dege
On Wed, 16 Apr 1997 23:51:49 -0500, Bob Stout <r...@snippets.org> wrote:
>On Wed, 16 Apr 1997, Bill Kilgore wrote:
>
>> OK, so I read the monograph, but it doesn't answere the burning
>> question -- Why is it called "Hungarian"?? (Polish++?)
>
>been called Polish notation. <g,d&r>
When Jan Lukasiewicz invented prefix notation, it _was_ called
Polish Notation. Of course, it turns out that postfix is more
useful than prefix, and we ended up with RPN.
--
Politician, n.:
An eel in the fundamental mud upon which the superstructure of
organized society is reared. When he wriggles, he mistakes the
agitation of his tail for the trembling of the edifice. As compared
with the statesman, he suffers the disadvantage of being alive.
-- Ambrose Bierce, "The Devil's Dictionary"
Craig Franck
a-...@signature.below.d wrote:
>In article <5jbmhp$2...@mtinsc05.worldnet.att.net>, Craig Franck <clfr...@worldnet.att.net> wrote:
>> (Hungarian
>>notation is a lot more sophisticated then "slapping on a prefix
>>here and there".) :-)
>
>That was supposed to be funny, wasn't it?
Hence the emoticon.
Eugene A. Pallat
So why do you feel that fPLCBoardWidth is easier to read than
f_PLC_Board_Width? You want Hungarian, fine, but why obfuscate the
variable name by jamming all the parts together? That's the only reason I
object to the current form of HN.
Remove the '-' from orion-data for sending email to me.
Orion Data Systems
Solicitations to me must be pre-approved in writing
by me after soliciitor pays $1,000 US per incident.
Solicitations sent to me are proof you accept this
notice and will send a certified check forthwith.
Nick Leaton <nic...@calfp.co.uk> wrote in article
<3355FE...@calfp.co.uk>...
> Brett J. Stonier wrote:
> >
> > Nick Leaton wrote:
> > > OK, so give us an example
> >
> > Alot of the C++ code I deal with interfaces with an Oracle7 database,
> > using the OCI libraries. A typical OCI call looks like:
> >
> > nResult = odefin(&gCur, 2, (char *)&gCurrentBoard.nNumOfUtter,
> > sizeof(int), OCI_DT_INT, -1, (short *)0, (char *)0, 0, 0, (short *)0,
> > (short *)0);
> >
> > This one binds in a variable as a receive buffer from a SQL statement.
> > The type needs to be known in order to pass the proper constant (in
this
> > case, OCI_DT_INT) to the function. Pass the wrong type constant and
all
> > sorts of memory problems will appear.
> >
> > Then, in less proprietary circumstances, a calculation:
> >
> > fPLCBoardWidth = atoi(gszPLCWidth) / 1000;
> >
> > If I were writing or debugging this line of code, I'd want to know what
> > type fPLCBoardWidth was. If it were an int, for example, the decimal
> > points would get lost.
> >
> > It is surprising to me that so many people are standing by the blanket
> > statement that "Hungarian Notation is NEVER appropriate!" All I am
> > saying is that there are times when I've found it helpful. It may not
> > be useful in all situations and environments, but I have found it so in
> > some.
>
> OK so you are writting code that is handling base types, and you want to
> have something like integer_parameter float_parameter. That is ok. What
> I really find wrong with Hungarian is that you are defining the type of
> the variable every time you use it. Change the type and you have a big
> edit renaming the variable. Now, if you have a good browser, you don't
> worry, you just click to get the declaration.
>
> --
>
> Nick
Eugene A. Pallat
> In article <33542...@usamrid.isd.net>,
> Erik Funkenbusch <chu...@isd.net> wrote:
> >If someone names a variable paycheck, what is it? Is it a paycheck
object,
> >is it the amount a person is paid? Is it the check number? Having to
> >search the code to find this is at best an annoyance, at worst a major
> >headache.
big snip
Cheer up. At least the variable "paycheck" had Some correlation to its
usage. I did work for one group 15 years ago where one of the supervisors
used variable names like queen, cow, dog, putt, ad nauseum. And these were
important variables in the programs.
No matter what form of notation is used, an incompetent turkey will always
find ways to mess it up.
Mark Wilden
a-...@signature.below.d wrote in article
<5jblu3$i...@mtinsc03.worldnet.att.net>...
>
> The system of prefixing variable names existed long before M$ even
existed. It
> was not invented at Microsoft.
Interesting. Do you have any more information?
Shawn Pringle
On Thu, 17 Apr 1997, Nick Leaton wrote:
> Brett J. Stonier wrote:
> >
> > Nick Leaton wrote:
> > > OK, so give us an example
> >
> > Alot of the C++ code I deal with interfaces with an Oracle7 database,
> > using the OCI libraries. A typical OCI call looks like:
> >
> > nResult = odefin(&gCur, 2, (char *)&gCurrentBoard.nNumOfUtter,
> > sizeof(int), OCI_DT_INT, -1, (short *)0, (char *)0, 0, 0, (short *)0,
> > (short *)0);
> >
> > This one binds in a variable as a receive buffer from a SQL statement.
> > The type needs to be known in order to pass the proper constant (in this
> > case, OCI_DT_INT) to the function. Pass the wrong type constant and all
> > sorts of memory problems will appear.
This is C code, C stands for clunky.
main() {int c; printf("%d",c); /* type specified twice */ }
To use this function in a more flexible way, your compiler has a you can
code.
inline typeof(OCI_DT_INT)& oracle_type_of(int /* missing parmeter */) {
return OCI_DT_INT;
}
Then recode the troubled line like this:
nResult = odefin(&gCur, 2, (char *)&gCurrentBoard.nNumOfUtter,
sizeof(gCur), oracle_type_of(gCur), -1, (short *)0, (char *)0, 0, 0,
(short *)0,
(short *)0);
If you change the type of gCur to float or something then you get an
error of oracle_type_of(float) not defined. Then you fix the problem.
An even better solution is to write an inline odefin function that
takes an int * as a pointer in the first argument. And then either
hardcoding the sizeof and oracle_type_of, or using assertion code
to ensure consistency.
Boris Beizer
-
Mark Wilden <Ma...@mWilden.com> wrote in article
<01bc4da2$c433c8a0$340228ce@default>...
In my book, The Architecture and Engineering of Digital Computer
Complexes, Volume !, pages 227-230 I provided a complete
specification for names, labels, etc. based on using prefixes that
followed a convention. This was published in 1971. While I
believe that this was the first instance of publication of a system
for conventionized label prefixes in a book, I do not claim credit
for the idea because it had been in use by many programmers as far
back as 1959 that I know of. Although I came to the idea myself
independently, it was hardly a unique "discovery." It is the
obvious thing to do when dealing with (for the time) big programs.
If the idea had any father, it was probably a consequence of the
fact that early FORTRAN compilers required that all integer
variables begin with the letters I, J, or K. Other early FORTRAN
compilers enforced additional conventional rules for variable
naming. It was not a great intellectual step from there, having
seen the advantages of using conventionalized name prefixes (ease
of scanning, simplified debugging, etc.) to extend the idea even
further and to make all name prefixes fully conventionalized.
Having lurked on this (at times, silly) thread, I have wondered if
my book had anything to do with the "Hungarian" connection. The
putative inventor (Simonyi?) is Hungarian. My books were pirated
by a Soviet Union publisher about 1972, illegally translated in to
Russian and other languages, and widely distributed throughout the
Communist Bloc. It was very popular there because the 900 pages of
these two volumes contained more up-to-date information on
real-time system architecture, hardware, and software, than any
other single source available at the time. Anyone involved in
system programming in the Communist Bloc would have been familiar
with my books. This pirated edition was a best-seller there. I
have no idea of how many copies were sold, but it was orders of
magnitude greater than the legal English language sales. I was at
the time far better known in the Communist Bloc than in the West --
to the point that many programmers there assumed that I was Russian
because of my name (Boris). Perhaps Mr. Simonyi might enlighten us
as to whether or not he picked up the idea from my books (pirated
edition), or like so many intelligent programmers have so many
times in the past (and probably in the future) invented this
independently.
Boris Beizer
-------------------------------------
Boris Beizer Ph.D. Seminars and Consulting
1232 Glenbrook Road on Software Testing and
Huntingdon Valley, PA 19006 and Quality Assurance
TEL: 215-572-5580
FAX: 215-886-0144
Email direct: bbe...@sprintmail.com
Email (Forwarded): bbe...@acm.org, bbe...@bigfoot.com
------------------------------------------
Derek Clarke
"Eugene A. Pallat" <eapa...@orion-data.com> wrote:
<snip>
>Cheer up. At least the variable "paycheck" had Some correlation to its
>usage. I did work for one group 15 years ago where one of the supervisors
>used variable names like queen, cow, dog, putt, ad nauseum. And these were
>important variables in the programs.
across a similar time in the past that had country names for labels.
Yep, 'GOTO' ARGENTINA;
danu...@antispam.halcyon.com
On 22 Apr 1997 13:22:18 GMT, Boris Beizer <bbe...@sprintmail.com> wrote:
>
> Having lurked on this (at times, silly) thread, I have wondered if
>my book had anything to do with the "Hungarian" connection. The
>putative inventor (Simonyi?) is Hungarian. My books were pirated
>by a Soviet Union publisher about 1972, illegally translated in to
>Russian and other languages, and widely distributed throughout the
>Communist Bloc. It was very popular there because the 900 pages of
>these two volumes contained more up-to-date information on
>real-time system architecture, hardware, and software, than any
>other single source available at the time. Anyone involved in
>system programming in the Communist Bloc would have been familiar
>with my books. This pirated edition was a best-seller there. I
I wouldn't be surprised if guys like Simonyi had read your book in
Hungary. But to be fair, he did not call "his" notation Hungarian.
Others did after seeing his coding style that seemed "different" to
most of them. Then the name stuck.
This would not be the first time that not the original inventor of
something gets credited with an idea but somebody else who effectively
introduced it into practice.
I also agree with you that the notation is a fairly trivial idea and
many people could have come up with it independently. On the other
hand, there is something about Hungarian thinking patterns that makes
such notation probably more appealing to Hungarians than others.
Just consider the fact that Hungarians write their last name first and
first name last, or that they date things by the year-month-day order;
exactly the way we want computers do it for sorting. ;-)
John E. Davis
I do a *lot* of programming and I have written several large programs.
In addition, I do quite a bit of porting and look at the source code
of others all the time. Based on my experience, I can say that the
important notation is NOT a notation that expresses the type of a
variable (Hungarian). Rather it is a notation that expresses the
_importance_ or scope of a variable. Unfortunately, I have not seen
anyone else utilize such a notation.
Why is this important? Basically computer code consists of algorithms.
Algorithms that consist of nothing but local variables can usually be
changed without affecting the code. Algorithms that consist of global
variables cannot be changed so much because a global variable has a
larger scope and its influence can be felt outside the function.
See below for an example.
Of course variable type is also important. However, it is usually obvious
what a variables type is from the context, e.g., i = 1; s = "string";
Roughly speaking, C supports 3 types of variables: true global variables,
static global variables, and local variables. A true global variable is one
that may be referenced by multiple C files. A static one is local to a
single file. The naming scheme must distinguish these types of variables.
The scheme I prefer is the following:
1. A global variable, either static or non-static, must be capitalized,
e.g., This_Is_A_Global_Variable.
2. A local variable must be in lower case, e.g., local_variable.
3. All true global variable must be distinguished from static ones by
prefixing the name. For example, the code for the news reader
that I am using (slrn) has all non-static global variables
prefixed with `Slrn_'.
Now, the same applies to functions of which there are two types: true
global and static. Since it is immediately obvious what is a function
and what is not, function names should be expressed in lower case.
True global ones should be prefixed. Finally MACROS should be
expressed in UPPERCASE.
So, we have the following types of declarations:
int Slrn_True_Global_Variable;
static int Static_Variable;
void slrn_true_global_function (void);
static void static_function (void);
Now consider some arbitrary code fragment:
if (Slrn_Article_Lines == NULL)
Slrn_Article_Lines = l;
else
{
l->next = Current_Line->next;
l->prev = Current_Line;
Current_Line->next = l;
if (l->next != NULL) l->next->prev = l;
}
Current_Line = l;
From the above naming scheme, it is immediately obvious that:
l is a local variable
Slrn_Article_Lines is a true global variable
Current_Line is a static global variable
This means that one should be careful with the line:
Slrn_Article_Lines = l;
because it has global consequences-- it affects code in other files.
The line
Current_Line = l;
is important but its effects are localized to the current file.
--John
Boyd Roberts
In article <5jioen$9...@gcsin3.geccs.gecm.com>, Derek Clarke <derek....@gecm.com> writes:
>Yep, 'GOTO' ARGENTINA;
And who can forget vi's forbid() macro's:
goto fonfon;
Jan de Visser
What I have been missing in the discussion on HN up to now is the usage
of HN in "typeless" languages (XBase). In such a language, the use of HN
can serve as a poor man's typechecking, preventing you from (e.g.)
adding an integer to a string and endig up with unwanted results...
JdV!!
John E. Davis wrote:
>
> I do a *lot* of programming and I have written several large programs.
> In addition, I do quite a bit of porting and look at the source code
> of others all the time. Based on my experience, I can say that the
> important notation is NOT a notation that expresses the type of a
> variable (Hungarian). Rather it is a notation that expresses the
> _importance_ or scope of a variable. Unfortunately, I have not seen
> anyone else utilize such a notation.
>
========================================================================
Jan de Visser etm...@etm.ericsson.se
ETM/OPP TMOS Technical support jan.de...@nlbdafsc.origin.nl
tel. +31 161 242650
<enter any 12 digit prime to continue>
========================================================================
Ian MacArthur
If anybody cares,
I (vaugely) recall reading an article, that
contained an interview with someone or other from M$, who was
of Hungarian extraction, and who drew a parallel between
"prefixing onto names" and the Hungarian habit of giving
family names before personal names, rather than the more common
Euro influenced "name,family" (i.e. Smith John rather than
John Smith.)
Also common on Bajor, I believe, for any Trekkers present.
Anyway, he alleged that it was on this basis that it became
known as Hungarian notation. I told this story to a Trekker here
and ever since he has (persistently) reffered to it as Bajoran
notation. So I wish I hadn't mentioned it, really.
As for who, where, when, etc.. I've no idea, it was years ago.
--
Ian MacArthur
Opinions expressed here are (probably) my own.
They were when I typed them.
They are not necessarily the company or anyone else's.
Derek Clarke
da...@space.mit.edu (John E. Davis) wrote:
>I do a *lot* of programming and I have written several large programs.
>In addition, I do quite a bit of porting and look at the source code
>of others all the time. Based on my experience, I can say that the
>important notation is NOT a notation that expresses the type of a
>variable (Hungarian). Rather it is a notation that expresses the
>_importance_ or scope of a variable. Unfortunately, I have not seen
>anyone else utilize such a notation.
<big snip>
At the risk of starting another style war, I'd just point out that a
stylistic convention for distinguishing global variables is not required
if you don't _use_ any!
Darin Johnson
In article <slrn5lppj6...@mygir.davis.net>, John E. Davis wrote:
>Rather it is a notation that expresses the
>_importance_ or scope of a variable. Unfortunately, I have not seen
>anyone else utilize such a notation.
Actually, the convention of always capitalizing globals and keeping
locals lowercase is very common (in UNIX anyway). Although I haven't
seen much distinction between static/extern globals.
I do see sense also in trying to distinguish between locals, object
variables, and globals. (instance versus class variables needn't be
distinguished most of the time though, imho) Although it still should
be a choice of the individual or group.
--
Darin Johnson
da...@usa.net.delete_me
Bill House
Jan de Visser <etm...@etm.ericsson.se> wrote in article
<335E9F...@etm.ericsson.se>...
> What I have been missing in the discussion on HN up to now is the usage
> of HN in "typeless" languages (XBase). In such a language, the use of HN
> can serve as a poor man's typechecking, preventing you from (e.g.)
> adding an integer to a string and endig up with unwanted results...
>
> JdV!!
>
In Xbase, that's exactly the case. In fact, due to the semantics of "PRIVATE" variables
in Xbase, you definitely want to include both type and scope prefixes in Xbase. In the
older FoxPro dialect of Xbase, you could say
PRIVATE ALL LIKE l*
at the top of each procedure. This would effectively eliminate the possibility of
inadvertent collisions with same-named variables declared further up the call tree.
Of course, in today's gentler times, you can simply declare Xbase variables LOCAL and
be done with it. Now, I omit the scope prefix for LOCAL variables and use LOCALs in all
cases, except (rarely) where a file-scoped (or global) variable is actually needed.
The nice thing about this is that my approach to variable scope prefixing can now be
fairly consistent across Xbase, C/C++, Basic and Lisp (which about covers it for my
typical workday).
Bill House
--
http://www.dazsi.com
Note: my e-mail address has been altered to
confuse the enemy. The views I express are
mine alone (unless you agree with me).
B.S.A. Cowgill
Jan de Visser wrote:
>
> What I have been missing in the discussion on HN up to now is the usage
> of HN in "typeless" languages (XBase). In such a language, the use of HN
> can serve as a poor man's typechecking, preventing you from (e.g.)
> adding an integer to a string and endig up with unwanted results...
>
> JdV!!
>
> >
> > I do a *lot* of programming and I have written several large programs.
> > In addition, I do quite a bit of porting and look at the source code
> > of others all the time. Based on my experience, I can say that the
> > important notation is NOT a notation that expresses the type of a
> > _importance_ or scope of a variable. Unfortunately, I have not seen
> > anyone else utilize such a notation.
Here's the section from "My Hungarian Notation Specification"
Prefix Meaning
g GLOBAL DATA. The var. can be accessed from any module
in
the program.
fs SCOPE OF DATA LIMITED TO THE FILE. The var. can be
accessed from within any function in the current file.
Use
an underbar if the data type starts with an s.
cm,pv,pr SCOPE OF DATA LIMITED TO THE CLASS. The var. is a
member
of a C++ class. Thus an instruction like csnPos = nPos
tells you that you're storing Pos in the class data
structure.
cm,cf PUBLIC CLASS MEMBER. The var. is a public member of a
C++
class.
pv,pvcm PRIVATE CLASS MEMBER. The var. is a private member of a
C++
class.
pr,prcm PROTECTED CLASS MEMBER. The var. is a protected member
of
a C++ class.
s STATIC CLASS DATA. The var. is a static function or
data
member of a class
> >
> ========================================================================
> Jan de Visser etm...@etm.ericsson.se
> ETM/OPP TMOS Technical support jan.de...@nlbdafsc.origin.nl
> tel. +31 161 242650
> <enter any 12 digit prime to continue>
> =====================================================================
................................................................
If you want to e-mail me, remove the x's from my e-mail address.
They have been added to prevent automatic junk mail.
R!ch
On 23 Apr 1997, Derek Clarke wrote:
> At the risk of starting another style war, I'd just point out that a
> stylistic convention for distinguishing global variables is not required
> if you don't _use_ any!
Agreed, use of globals should be kept to a minimum, but sometimes their
use is unavoidable (eg signal handlers).
--
R!ch
If it ain't analogue, it ain't music.
#include <disclaimer.h> \\|// - ?
(o o)
/==================================oOOo=(_)=oOOo========\
| Richard Teer richar...@uk.sun.com |
| Sun Service Contractor |
| Voice: +44 (0)1276 691974 |
| .oooO |
| ( ) Oooo. |
\===================================\ (==( )==========/
\_) ) /
(_/
Stephan Wilms
R!ch wrote:
>
> On 23 Apr 1997, Derek Clarke wrote:
>
> > At the risk of starting another style war, I'd just point out that a
> > stylistic convention for distinguishing global variables is not required
> > if you don't _use_ any!
>
> Agreed, use of globals should be kept to a minimum, but sometimes their
> use is unavoidable (eg signal handlers).
Also the runtime-library keeps and uses several globals.
I prefer to use static globals in my files to create encapsulated
modules
with a well defined interface. These modules store their internal status
in static globals.
Eg. for linked lists I create a module which keeps all existing linked
lists (and other status) in a static global and you have functions like
"CreateNewList", "DestroyList", "AddToList", "RemoveFromList",
"FindInList", etc.
Stephan
(self appointed member of the campaign against grumpiness in c.l.c)
Tom
Dont try using them in java...they dont exist.
R!ch wrote:
>
> On 23 Apr 1997, Derek Clarke wrote:
>
> > At the risk of starting another style war, I'd just point out that a
> > stylistic convention for distinguishing global variables is not required
> > if you don't _use_ any!
>
> Agreed, use of globals should be kept to a minimum, but sometimes their
> use is unavoidable (eg signal handlers).
>
Jay Martin
Matt Austern <aus...@isolde.mti.sgi.com> writes:
>Derek Clarke <derek....@gecm.com> writes:
>> At the risk of starting another style war, I'd just point out that a
>> stylistic convention for distinguishing global variables is not required
>> if you don't _use_ any!
>Both the standard C library and the standard C++ library use globals
>for I/O. (The C library uses stdout, for example, and the C++ library
>uses cout.)
>I can imagine a couple of ways to design the C++ library so as to
>avoid globals, but I'm not at all sure that any of them would really
>be an improvement.
I think I am going to be sick. "printf" uses globals for standard output, thus
globals are good for applications? Isn't "printf" or any operating system
environment related stuff a special case?
Matt Austern
Bob Goudreau
Ian MacArthur (Ian.Ma...@GecM.com) wrote:
: I (vaugely) recall reading an article, that
: contained an interview with someone or other from M$, who was
: of Hungarian extraction, and who drew a parallel between
: "prefixing onto names" and the Hungarian habit of giving
: family names before personal names, rather than the more common
: Euro influenced "name,family" (i.e. Smith John rather than
: John Smith.)
: Also common on Bajor, I believe, for any Trekkers present.
: Anyway, he alleged that it was on this basis that it became
: known as Hungarian notation. I told this story to a Trekker here
: and ever since he has (persistently) reffered to it as Bajoran
: notation. So I wish I hadn't mentioned it, really.
This seems a bit odd as a moniker for the practice of putting the
family name before the given name, given that there are only a few
million Hungarians in the world (and exactly zero Bajorans!), while
there are over a billion Chinese who have used this convention for
ages (not to mention Japanese, Koreans, Malaysians, etc.). It would
thus make far more sense to refer to this practice as "Chinese".
----------------------------------------------------------------------
Bob Goudreau Data General Corporation
goud...@dg-rtp.dg.com 62 Alexander Drive
+1 919 248 6231 Research Triangle Park, NC 27709, USA
Raistlin
Bob Goudreau <goud...@dg-rtp.dg.com> wrote in article
<5jqo67$i...@dg-rtp.dg.com>...
> Ian MacArthur (Ian.Ma...@GecM.com) wrote:
>
> : I (vaugely) recall reading an article, that
> : contained an interview with someone or other from M$, who was
> : of Hungarian extraction,
The person interviewed was Charles Simonyi - who worked for for Microsoft
and was Hungarian
> : "prefixing onto names" and the Hungarian habit of giving
> : family names before personal names, rather than the more common
> : Euro influenced "name,family" (i.e. Smith John rather than
> : John Smith.) > : Anyway, he alleged that it was on this basis that it
became
> : known as Hungarian notation.
It became Known as Hungarian because everyone who looked at his code
thought it had a strange appearance - as if it was written in Hungarian.
> This seems a bit odd as a moniker for the practice of putting the
> family name before the given name, given that there are only a few
> million Hungarians in the world (and exactly zero Bajorans!), while
> there are over a billion Chinese who have used this convention for
> ages (not to mention Japanese, Koreans, Malaysians, etc.). It would
> thus make far more sense to refer to this practice as "Chinese".
Charles Simonyi was neither Chinese or Bajoran so the humor would not have
been very funny I suppose
Raistlin
Jeffrey C. Dege
On 26 Apr 1997 01:43:09 GMT, John E. Davis <da...@space.mit.edu> wrote:
>On 23 Apr 1997 17:10:44 GMT, Derek Clarke <derek....@gecm.com>
>wrote:
>>At the risk of starting another style war, I'd just point out that a
>>stylistic convention for distinguishing global variables is not required
>>if you don't _use_ any!
>
>example, I do not see how it is possible to write a library without
>using a global variable unless *all* (except one-- see below) the
>library functions look like:
class LibraryState
{
public:
static LibraryState *getState() const { return theState; }
static void setState(const IniObject &ini)
{
if (!theState)
theState = new LibraryState(ini);
}
private:
LibraryState(const IniObject &ini) {...}
static LibraryState *theState;
};
LibraryState *LibraryState::theState = NULL;
> void lib_function (Lib_State_Info *info, ...)
> {
> if (info == NULL) lib_exit_error (info, "Library not initialized.");
> .
> .
> }
void lib_function (Lib_State_Info *info, ...)
{
const LibraryState *theState = LibraryState::getState();
if (theSTate == NULL) lib_exit_error (info, "Library not initialized.");
.
.
}
>Here Lib_State_Info is (possible large) structure that contains all
>the information that would normally be contained in global variables.
Some programs need singleton globally accessible state information.
Global variables are a solution that is fast and easy in the sort
term, but which can be enormously expensive in the long run.
The pass around an arbitrary structure method you advocate also has
its disadvantages. Mainly, in that you are requiring the programmer
to do something correctly that you thave no way of ensuring.
In an OOPL, I'd use a singleton class to replace globals. This packages
them nicely out of the way.
In plain C, I'd _still_ not use globals, and I'd probably also not require
passing around initiallization structures, either.
Have you considered:
/********/
/* lib_header.h */
bool lib_setStateInfo(...);
/********/
/* file: lib_globals.h */
struct Lib_State_Info
{
...
};
const Lib_State_Info *lib_dont_step_on_other_folks_namespace_getStateInfo();
/********/
/* file: lib_globals.c */
#include "lib_globals.h"
static struct Lib_State_Info theInfo;
bool lib_setStateInfo(...)
{
theInfo.whatever = ...;
...
return true;
}
const Lib_State_Info *lib_dont_step_on_other_folks_namespace_getStateInfo()
{
return &theInfo;
}
/********/
/* file: lib_implementation.c */
int lib_function()
{
const Lib_State_Info *stateInfo() =
lib_dont_step_on_other_folks_namespace_getStateInfo();
...
}
--
We can found no scientific discipline, nor a healthy profession on the
technical mistakes of the Department of Defense and IBM.
-- Edsger Dijkstra
Jeffrey C. Dege
John E. Davis
On 23 Apr 1997 17:10:44 GMT, Derek Clarke <derek....@gecm.com>
wrote:
>At the risk of starting another style war, I'd just point out that a
>stylistic convention for distinguishing global variables is not required
>if you don't _use_ any!
I think that only trivial programs are written without globals. For
example, I do not see how it is possible to write a library without
using a global variable unless *all* (except one-- see below) the
library functions look like:
void lib_function (Lib_State_Info *info, ...)
{
if (info == NULL) lib_exit_error (info, "Library not initialized.");
.
.
}
where the first parameter is the result of an initialization routine:
Lib_State_Info *lib_init (...)
{
Lib_State_Info *info;
.
.
return info;
}
Here Lib_State_Info is (possible large) structure that contains all
the information that would normally be contained in global variables.
This forces the application (your program) using the library to pass
the pointer to the state info structure to all the routines of the
library. This also means that all the application routines that use
the library must also have the pointer passed to it to avoid a global
variable. Then you may as well have all the application routines take
the Lib_State_Info pointer because you may decide at some point that
it is better for some function 'x' to call the library. Otherwise,
maintaining the application would be a nightmare.
--John
John E. Davis
Martin ELLISON
> In an OOPL, I'd use a singleton class to replace globals. This packages
> them nicely out of the way.
A singleton class (using the Singleton pattern of Gamma et al) *is* a
global variable.
---------------------------------------------------
Martin Ellison mailto:mar...@mpce.mq.edu.au
http://www.jrcase.mq.edu.au/~martin/
Jeffrey C. Dege
On Sun, 27 Apr 1997 12:45:05 +1000, Martin ELLISON <mar...@mpce.mq.edu.au> wrote:
>Jeffrey C. Dege wrote:
>>
>> On 26 Apr 1997 01:43:09 GMT, John E. Davis <da...@space.mit.edu> wrote:
>
>> In an OOPL, I'd use a singleton class to replace globals. This packages
>> them nicely out of the way.
>
>A singleton class (using the Singleton pattern of Gamma et al) *is* a
>global variable.
Well, to say yes or no to that, we have to agree on exactly which
characteristics of a global variable we are talking about.
Certainly, when we use the singleton patterm there is exactly one
object, and we can access it from anywhere. In this it is similar
to a global variable.
On the other hand, the object itself is usually declared as a private
static member of the class, and any references to it are in the usual
local scope, i.e.:
{
Singleton *theSingleton = Singleton::getSingleton();
...
}
In these aspects, singletons are quite _unlike_ global variables,
in that they don't become a part of the variable namespace. And
since, IMO, the most significant drawbacks of global variables are
the difficulty in distinguishing between globals and locals, and in
identifying where globals are being modified. Given that singleton
objects solve both of these problems, I can't consider them as
equivalent to globals in any respect that matters.
--
When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
John E. Davis
On 26 Apr 1997 04:33:06 GMT, Jeffrey C. Dege <jd...@jdege.visi.com>
wrote:
>/* file: lib_globals.c */
>#include "lib_globals.h"
>
>static struct Lib_State_Info theInfo;
>
>bool lib_setStateInfo(...)
>{
> theInfo.whatever = ...;
> ...
You have used a global here (although static). If your library
consists of multiple C files then your `theInfo' variable must be made
global.
The only reason I see for avoiding globals is to ensure re-entrant,
thread-safe code. The above is not thread-safe. If you are not
worried about multi-threaded applications then I think that globals
are fine.
--John
Jeffrey C. Dege
On 27 Apr 1997 09:47:39 GMT, John E. Davis <da...@space.mit.edu> wrote:
>On 26 Apr 1997 04:33:06 GMT, Jeffrey C. Dege <jd...@jdege.visi.com>
>wrote:
>>/* file: lib_globals.c */
>>#include "lib_globals.h"
>>
>>static struct Lib_State_Info theInfo;
>>
>>bool lib_setStateInfo(...)
>>{
>> theInfo.whatever = ...;
>> ...
>
>You have used a global here (although static). If your library
>consists of multiple C files then your `theInfo' variable must be made
>global.
First, a file-scoped static variable is _not_ global. True, it is allocated
and initialized like a global, but it does not have global visibility.
And if my library consists of multiple C files, the `theInfo' variable
does _not_ have to be global, if I provide functions to provide
references to it. The result is pretty much the same as in using
singleton objects in C++.
>The only reason I see for avoiding globals is to ensure re-entrant,
>thread-safe code. The above is not thread-safe. If you are not
>worried about multi-threaded applications then I think that globals
>are fine.
In order to access shared variables safely in multi-threaded applications
is to provide some sort of synchronization mechanism. If you allow
direct access to your global variables you have to do that correctly
at each and every access, which _won't_ happen. If you restrict
access to your ``global'' variables to a defined set of functions,
whether via using C functions to access file-scoped static data,
or using a singeloton class in C++, you have a single place to
put the synchronization code to ensure that it is always done
correctly.
In any case, the biggest problem with globals isn't reentrancy, it's
the interdependency of the code that accesses it. No code that
accesses global variables can be re-used without those global
variables, and the state of a global variable cannot be determined
without examining every access to it. The result is modules that
should be independent end up depending upon each other in ways
that simply can't be documented.
Singleton objects provide a clear interface to the ``global'' data,
and they break the dependency cycle. Instead of module A depending
upon module B and module B depending upon module A, via unspecified
access to common global variables, you have module A depending upon
the singleton and module B depending upon the singleton, where the
access to the singleton is clearly defined in the class definition.
The plain-C pseudo-singleton via file-scoped statics and access functions
gives you the same advantages, though the interface isn't as clearly
specified.
Either provides a greater possibibility for reuse and is _much_ easier
to maintain in the long run.
--
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" ("I found it!") but rather "hmm....that's
funny..." -- Isaac Asimov
John Nagle
da...@space.mit.edu (John E. Davis) writes:
>On 23 Apr 1997 17:10:44 GMT, Derek Clarke <derek....@gecm.com>
>wrote:
>>At the risk of starting another style war, I'd just point out that a
>>stylistic convention for distinguishing global variables is not required
>>if you don't _use_ any!
>I think that only trivial programs are written without globals. For
>example, I do not see how it is possible to write a library without
>using a global variable unless *all* (except one-- see below) the
>library functions look like:
That's what C++ is for.
John Nagle
Jason I. Hong
Jeffrey C. Dege (jd...@jdege.visi.com) wrote:
: First, a file-scoped static variable is _not_ global. True, it is allocated
: and initialized like a global, but it does not have global visibility.
One of my professors referred to variables with this kind of scope as
_non-local_ .
So, for visibility purposes, there seem to be three kinds of variables:
o local - visible only to the current method
o non-local - visible only to the current Abstract Data Type
(unit, object, package, etc).
o global - visible to everything
There seems to be many kinds of non-local variables too. For example, in
Java, you could have a non-local instance variable, and a non-local variable
accessible to everything in that package.
Am I missing any other kinds of scoping visibility?
--
Jason I. Hong | The limits of my language are the limits of my world
ho...@cc.gatech.edu |
Instructor CS1502:Java! | -- Ludwig Wittgenstein
David Williams
In article <slrn5m1q5...@mygir.davis.net>, "John E. Davis"
<da...@space.mit.edu> writes
>
>On 23 Apr 1997 17:10:44 GMT, Derek Clarke <derek....@gecm.com>
>wrote:
>>At the risk of starting another style war, I'd just point out that a
>>stylistic convention for distinguishing global variables is not required
>>if you don't _use_ any!
>
>I think that only trivial programs are written without globals. For
What about module level variables i.e. declared at start of a module
and only accessable within that module.
Or static variables with automatic initialisation.
int c(int x)
{
static i=3;
return (x*i)
}
??
--
David Williams
Lawrence Kirby
In article <rORbIEAU...@smooth1.demon.co.uk>
d...@smooth1.demon.co.uk "David Williams" writes:
...
> Or static variables with automatic initialisation.
>
> int c(int x)
> {
> static i=3;
>
> return (x*i)
> }
i here is a static variable with block scope. In C It is initialised like
all other static variables once at program startup.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Bruce Bigby
John Nagle wrote:
>
> da...@space.mit.edu (John E. Davis) writes:
> >On 23 Apr 1997 17:10:44 GMT, Derek Clarke <derek....@gecm.com>
> >wrote:
> >>At the risk of starting another style war, I'd just point out that a
> >>stylistic convention for distinguishing global variables is not required
> >>if you don't _use_ any!
>
> >I think that only trivial programs are written without globals. For
> >using a global variable unless *all* (except one-- see below) the
> >library functions look like:
>
> That's what C++ is for.
>
> John Nagle
in C that you can do in C++. I've done it--polymorphism/virtual
functions, single inheritance, exception handling, which even handles OS
signals, and even a few that C++ does not handle--virtual constructors,
Smalltalk-like virtual super message/method, and something, which I'm
working on, thread-safe exception-handling--all in plain old C! The
only thing that is difficult to manage is multiple inheritance, but
that's doable, but not worth the pain.
The C++ compiler can handle multiple inheritance better, since it knows
a lot about the structure of classes and can invoke the correct method
on the correct part of multiply inherited class. I prefer Java
interfaces better. It keeps the inheritance mechansim simple, but
enables an object to behave in more specialized ways.
The other advantage of C++ is that the compiler creates all of the
virtual function tables, while, in C, one has to do it by hand.
However, doing it by hand enabled me to discover how to support the
super method of Smalltalk. Unlike C++, which does not build a VFT for
abstract classes that persists independently, like concrete classes, I
created a VFT for every abstract class. This enables me to define a
virtual method like the following:
static
Object
ClassMethod(MessageID msgID, Object self)
{
Object (*SuperMethod)(MessageID, Object) = Super(self, msgID);
// Do some specialized function, and, then, call the superclass's
// method without knowing what kind of object self is.
printf("Executing the virtual method of an object of class %s\n",
GetClassNameMessage(self));
return(SuperMethod(msgID, self)); // Also do execute method of
// superclass
}
Before you start saying that C++ can do this, it can, but in a limited
way. In C++, you have to know the real class of an object, and then its
superclass in order to do this. Many times, you can't know this
information, and, even when you do, your code will become ugly, trying
to handle every case in a class hierarchy:
if class A,
then invoke B::Method
else if class B
then invoke C::Method
else if class C
then invoke D::Method
.
.
.
endif
Pretty ugly, huh?
This level of genericity is not possible in C++. I don't know why. It
is easy to add to the language. All you have to do is ensure that
abstract classes have a separate VFT, even though you never instantiate
an object from them.
Virtual constructors are not possible in C++ because of its strict
naming conventions for constructors. I had no such restrictions. This
enables a class to inherit certain construtors from a base class, such
as a class which defines a constructor that creates a new collection and
intializes it with a list of values. For example,
static
Object
NewWith(MessageID msgID, ClassID classID, Object aCollection)
{
Object self = New(classID);
AddAll(self, aCollection);
return(self);
}
This method could exist in a general Collection class, and all
descendents would inherit this NewWith method. The only thing that
would be required would be that all subclasses of Collection would have
to define the "New" method, which the NewWith method uses. The class
would also have to define or inherit the AddAll method. The default
definition of AddAll would most likely exist in the Collection class,
also. You can't inherit virtual constructors in C++.
--
Bruce W. Bigby