pointer better than the variable?

[Steve Russell]

Suppose I have

CAdjective adj(CNoun noun){}.

Is there any reason why I would prefer

CAdjective adj(CNoun* noun){}?

[David Lowndes]

Steve,

The first would involve making a copy of the object - which may incur
quite a bit of extra time (depends on your CNoun).

You'd pass a non-const pointer if you want the constructor to modify
the object.

If you don't need to modify the noun variable you'd probably want to
pass it as a pointer or reference like this:

CAdjective( const CNoun* noun )

or like this:

CAdjective( const CNoun & noun)

const informs the compiler that the method shouldn't modify the
object.

Passing by reference in this situation means that:

1. You *must* pass a noun object, since there's no such thing as a
NULL reference.

2. The code in the constructor uses noun.whatever rather than
noun->whatever.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[Rob]

Actually, the optimal declaration would be:

CAdjective adj(CNoun& noun){}

The reason being that using a reference would not invoke the copy
constructor. Also, passing an object on the stack is not always ideal
depending on the size of the object.

Rob

"Steve Russell" <srus...@innernet.net> wrote in message
news:4e3c01c2bb33$70465960$89f82ecf@TK2MSFTNGXA01...

[Jay Nabonne]

Perhaps even:

CAdjective adj(const CNoun& noun){}

depending on the semantics.

Jay

"Rob" <r...@dptechnology.com> wrote in message
news:#dN13izuCHA.2380@TK2MSFTNGP11...

[Ivan Lalis]

It can be expensive to call CNoun's copy-constructor. BTW you may also use
someting like:

CAdjective adj(const CNoun& noun){}

Ivan

"Steve Russell" <srus...@innernet.net> schrieb im Newsbeitrag
news:4e3c01c2bb33$70465960$89f82ecf@TK2MSFTNGXA01...

[Rob]

Agreed.

If this is an "in" parameter only, then the const modifier would be ideal.

Rob

"Jay Nabonne" <j...@rightagain.com> wrote in message
news:OAi5npzuCHA.2380@TK2MSFTNGP12...

[Steve Russell]

Thank you very much, everyone.

>.
>

[Doug Harrison [MVP]]

Steve Russell wrote:

The traditional reasons date back to C and include:

1. Avoid copying large objects, as C supports only pass by value.
2. Because C supports pass by value only, a function must use pointer
parameters if it wants modify the caller's data.
3. To allow passing NULL for optional parameters.

C++ supports pass by reference, so IMO, (1) and (2) aren't compelling
reasons in C++, though people will tell you that having to say:

adj(&x)

is a valuable indicator that adj may modify x. I thought the same thing the
first six months I used C++, but then I became more and more aware that I
don't regularly perform the superficial scanning of source code which this
helps to enable, and even if I did, it's not that valuable anyway. Consider
that adj might take a const X*, and that x is often already a pointer, in
which case, adj is called as:

adj(x)

No call-site clue there that *x may be modified, and that's often what you
need to know. The bottom line is that to understand what this code does, you
must know the type of x and how adj is defined and what adj does. Other C++
reasons to use pointer or reference parameters include:

4. Enable passing of non-copyable objects.
5. Avoid slicing and preserve polymorphism of the object.
6. Enable transfer of ownership of a dynamically allocated object. (If you
avoid (1) and (2), this becomes a major reason to use a pointer parameter;
at least, it's something that comes to mind when I see pointer parameters in
C++ code.)

If reasons (3) and (6) didn't apply to your C++ parameter, I would use:

CAdjective adj(CNoun& noun);

Or if adj wasn't to modify noun:

CAdjective adj(const CNoun& noun);

Of course, you must use pointer parameters to provide an interface for array
arguments, because they undergo the array to pointer conversion in the
context of being a function argument, which produces a pointer to their
first element. There, you really don't have much choice.

--
Doug Harrison
Microsoft MVP - Visual C++

[Rob]

Doug,

I just thought I'd comment on your mention of superficial scanning of code
to determine the nature of a parameter. When scanning someone else's code
or even revisiting my own code I find that using hungarian notation is very
helpful. As you said, having to look up the declaration of a variable can
often be tedious when scanning large amounts code, especially when someone
has a habit of declaring variables far from where they are actually used.

In the specific case you mention, I always use an indicator to show that a
variable is of type pointer such as pnCount or lpSomeData.

I realize that this is a matter of discipline and can't be assumed when
scanning someone else's code but I find it especially useful when revisiting
my own code.

Another useful habit is to always declare variables as close to their use as
possible.

Rob

"Doug Harrison [MVP]" <d...@mvps.org> wrote in message
news:51f62v4dlu331dlua...@4ax.com...

[Joseph M. Newcomer]

I have found Hungarian notation to have distinct negative value, primarily because either
the coder did not understand how to use it, and used it incorrectly, or program evolution
changed the meanings but the variables were not changed to correspond. I still feel this
is one of the worst ideas to have hit programming in my career, which spans nearly 40
years.

As far as declaring variables "far" from where they are used, I find this is usually not a
problem. First, any decent browser (including the one in Visual Studio) makes locating
these trivial, so we are not talking about paging through thousands of pieces of paper to
find them. Grep-like tools work great, too. So I don't buy that argument. Second, why are
variables declared "far" from where they are used? Either they should be member variables
of the class (and hence easily located) or local variables (and hence easily located). A
tendency of programmers to keep reusing a variable just to avoid doing a second
declaration exacerbates the problem. In a well-constructed program, there is no such
concept (for example, global variables are held at a minimum, and easily found because the
program is designed to make them easily findable). Far too many programmers do not
understand that a program is not a random collection of variables tossed together. There
is a structure, the same as a building. A building is not a random stack of bricks and
metal. But many programs come closer to resembling trash heaps, and it is not surprising
that finding something requires digging through a lot of unpleasant trash.

Since a variable is obvious from its use, adding type information rarely contributes
anything meaningful that is not already deducible from how it is used.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm

[Doug Harrison [MVP]]

Rob wrote:

>Doug,
>
>I just thought I'd comment on your mention of superficial scanning of code
>to determine the nature of a parameter. When scanning someone else's code
>or even revisiting my own code I find that using hungarian notation is very
>helpful. As you said, having to look up the declaration of a variable can
>often be tedious when scanning large amounts code, especially when someone
>has a habit of declaring variables far from where they are actually used.
>
>In the specific case you mention, I always use an indicator to show that a
>variable is of type pointer such as pnCount or lpSomeData.

I don't see anything wrong with using the "p" prefix for pointers, but when
I use it, it's mainly to create something like a separate "namespace" for
the variable names. The "lp" prefix is just an historical artifact from the
16 bit days.

>I realize that this is a matter of discipline and can't be assumed when
>scanning someone else's code but I find it especially useful when revisiting
>my own code.

Many people consider Hungarian notation harmful, as it's nothing more than
what I call a "code comment". Like a real comment, it's something that isn't
checked by the compiler, and it often starts out wrong or evolves to being
wrong over time. I'll give you another code comment example. People often
say they like the NULL macro, because it indicates they're working with
pointers. Well, I can't tell you how many times I've seen stuff like the
following:

// x is an array of char or int.
x[n] = NULL;

C++ requires that NULL be an integral constant which evaluates to zero, and
as such, it's not a pointer type at all. It's just a code comment, and
someone reading the above without regard to its real meaning would think x
is an array of pointers. My approach is to know what x is, and then I can
follow its use and reason about it correctly, without guessing.

>Another useful habit is to always declare variables as close to their use as
>possible.

That's what always gets me when I try to write C these days - you can't do
it!

[Joseph M. Newcomer]

On Mon, 13 Jan 2003 19:54:38 -0600, "Doug Harrison [MVP]" <d...@mvps.org> wrote:

>That's what always gets me when I try to write C these days - you can't do
>it!

I found myself, over a decade ago, writing C code of the form

void function(...args here...)
{
.. stuff
{
int i;
for(i = 0; i < n; i++)
...loop here
}
...more stuff
{
int i;
for(i = 0; i < n; i++)
....
}

....etc.

Just so I could get the declarations near the use. So when I started using C++, using
declarations in the C++ style came naturally.
joe

[Tim Holst Petersen]

Hungarian notation is just fine, as are other naming conventions. The
important thing is to have a coding standard which is adhered to by
everyone.

I see nothing wrong in using bXXX for a boolean variable or to point out
that an integer is unsigned by using uiXXX. The same goes for pXXX and rXXX
for pointers and references. (a.s.o.)

If everyone uses it, it CAN be a help. The world is not perfect though. In
the 6 or so companies in which I've jobbed people used hungarian notation to
perhaps a 90% extend. Those who did not, were running against the wind, as
were we when trying to decipher their code.

Some people actually DO access their member variables directly instead of
using Get/Set methods. In this case is invaluable using the m_xxXXX
notation. There is nothing more irritating than to discover (after half an
hour of scratching your head) that a seemingly local variable is actually
being changed in another method. It should not be necessary to investigate
this if a variable is declared locally. It isn't necessary, if members are
declared with the "m_" notation.

The important thing is to use the SAME naming convention and the same use of
braces, tabs and spaces, comments etc. Especially if you outsource parts of
your projects. Fact is that most people actually use and understand the
hungarian notation and in an outsource situation they must be able to expect
some unity in the coding style we deliver.

Tim Holst Petersen.

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:jlo62v069vjgki6h8...@4ax.com...

[Joseph M. Newcomer]

bXXXX is redundant if you see
XXXXX = TRUE;
XXXXX = FALSE;
if(XXXXX)
it is pretty obvious that it is a Boolean value. Knowing an integer is unsigned is trivial
to deduce by looking at the declaration; putting redundant information in contributes very
little.

The point is that very few people seem to use it right. Certainly the code that crosses my
desk is so abysmal that I usually rip out the Hungarian notation (I certainly rip it out
if it is used wrong!)

There are only two major languages where type was encoded in the identifier name: FORTRAN
and BASIC. Both of them abandoned it because it was a stupid idea.

Funny thing is, I have very little trouble deciphering code that is not written with
Hungarian notation. It is such a non-problem that I find it hard to understand why anyone
ever thought it was (remember, Hungarian notation predates decent type management in C and
therefore represents a solution to an obsolete technological problem). In an era of modern
compilers and browsers, it is the buggy whip of technology.

For some reason, I have never been intimidated by being handled 100K lines of source I've
never seen and been told "fix a bug ..." or "add a feature...". Since I spent 30 years
doing this before Hungarian Notation existed, it never occurred to me that any of this
presented a problem. Yet it seems Hungarian Notation is solving a nonexistent problem and
does so by introducing a technique that is MORE error-prone, because it fools the reader
into believing the name conveys information. When it conveys erroneous information, there
is great harm; and the information it conveys is redundant with the declaration, and
therefore serves no useful purpose.
joe

[Steve Russell]

In regard to naming variables, I have often wondered
(being fairly new to windows programming), if using
longer, more descriptive names can have slow the program
down and if that is why I see so many "abbreviated"
variable names when I study code.

>.
>

[Joseph M. Newcomer]

How could a "long" name "slow the program down"? The concept is without meaning. It is of
the form of "can a green car get more miles per gallon than an identical model painted
red?"

We use short names because they are easy to type. People drive green cars when they like
green cars.
joe

[Steve Russell]

This is where I am lacking in my understanding of how a
variable name occupies space. Can you help me out?

Does variable ThisIsALongVariableName read exactly as
quickly as variable TILVN?

>.
>

[Tim Slattery]

"Steve Russell" <srus...@innernet.net> wrote:

>This is where I am lacking in my understanding of how a
>variable name occupies space. Can you help me out?

A variable name does *not* occupy space. Once the program is compiled,
the name doesn't exist. The compiled code refers to the variable by
using an address. An extremely long name might have a small effect on
compilation time, but will make absolutely no difference in the
executable module.

--
Tim Slattery
MS MVP(DTS)
Slatt...@bls.gov

[Rob]

Joseph,

You obviously have some issues. My original posting was not inflamatory.

I've been programming for 20 years myself and I'm versed in many different
programming languages. You apparently haven't worked on a project that was
so large that the project manager in Visual C++ was non-operational. Left
without the wizards and nice GUI hints, hungarian notation (as Tim stated),
if applied properly is very helpful.

Regarding declaring variables as close to where they are used, that is very
helpful when you're dealing with very long formulas. I'm not sure what kind
of programming you've been doing for the last 40 years, but apparently you
haven't worked on any large projects.

Rob

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message

news:led72vslquvoe3a5j...@4ax.com...

[Ajay Kalra]

> My original posting was not inflamatory.

To comment politely, most of your posts are inflamatory. And neeedless to
say, you do not know Joe or his experience.

--
Ajay Kalra [MVP - VC++]
ajay...@yahoo.com

"Rob" <r...@dptechnology.com> wrote in message

news:u#cR47$uCHA.2668@TK2MSFTNGP12...

[Rob]

Doug,

You're obviously entitled to your opinion as I am entitled to my opinion.
Whatever makes your life easier is the point here. As you have pointed out,
hungarian notation is something like a comment. And just like a comment
it's useful if the comment is maintained. And like a comment it's
misleading when it's not updated. But it's the responsibility of the
programmer(s) to have the discipline to do so.

Using your argument you might say that comments are completely useless.
That I hope sounds as rediculous to you as it does to me. If not, I hope I
never have to decipher any of your code.

Don't get me wrong I don't rely on comments or notations such as hungarian
notation. I've had to decipher whole programs written in 65816 assembler
with symbols and comments in japanese. I'm very good at deciphering code,
but I still maintain that hungarian notation is useful when applied
properly.

Rob

"Doug Harrison [MVP]" <d...@mvps.org> wrote in message

news:rcr62vcfol64q8ajo...@4ax.com...

[Rob]

Ajay,

If you belive so then please point out the statement I made that was
inflamatory?

Rob

"Ajay Kalra" <ajay...@yahoo.com> wrote in message
news:OR$1fCAvCHA.2680@TK2MSFTNGP09...

[Doug Harrison [MVP]]

Rob wrote:

>Doug,
>
>You're obviously entitled to your opinion as I am entitled to my opinion.

I sure hope so! :)

>Whatever makes your life easier is the point here. As you have pointed out,
>hungarian notation is something like a comment. And just like a comment
>it's useful if the comment is maintained. And like a comment it's
>misleading when it's not updated. But it's the responsibility of the
>programmer(s) to have the discipline to do so.
>
>Using your argument you might say that comments are completely useless.

No, I wouldn't say that.

>That I hope sounds as rediculous to you as it does to me. If not, I hope I
>never have to decipher any of your code.
>
>Don't get me wrong I don't rely on comments or notations such as hungarian
>notation. I've had to decipher whole programs written in 65816 assembler
>with symbols and comments in japanese. I'm very good at deciphering code,
>but I still maintain that hungarian notation is useful when applied
>properly.

I'm glad you find it useful, and I'm not impugning your skills. I don't have
any more to add beyond what I've written in my previous two messages.

[Joseph M. Newcomer]

Variable names do not occupy space at all, except in the debug tables, where the size is
irrelevant anyway (this is the .pdb file). They do not exist in the compiled code.
joe

[Joseph M. Newcomer]

To be honest, I didn't see anything inflammatory...
joe

[Johan Rosengren]

"Rob" <r...@dptechnology.com> wrote in message

news:uQU8LFAvCHA.1656@TK2MSFTNGP09...

<snip>

>
> Don't get me wrong I don't rely on comments or notations such as hungarian
> notation. I've had to decipher whole programs written in 65816 assembler
> with symbols and comments in japanese. I'm very good at deciphering code,
> but I still maintain that hungarian notation is useful when applied
> properly.
>

I would to some degree agree with this, with the very important qualifier
"when applied properly". In practice, however, I've been bitten so often by
improper or overzealous use, I have started to hate notation conveying
semantic information - including stuff like prefixing class members with
"m_", "f" and so on :-( Nowadays, I'm happy if the coding style is just
homogenous across projects...

Johan Rosengren
Abstrakt Mekanik AB

> Rob
>
<snip>

[Rob]

> On Tue, 14 Jan 2003 02:11:20 -0500, Joseph M. Newcomer
<newc...@flounder.com> wrote:
>
> >bXXXX is redundant if you see
> > XXXXX = TRUE;
> > XXXXX = FALSE;
> > if(XXXXX)
> >it is pretty obvious that it is a Boolean value. Knowing an integer is
unsigned is trivial
> >to deduce by looking at the declaration; putting redundant information in
contributes very
> >little.
> >
> >The point is that very few people seem to use it right. Certainly the
code that crosses my
> >desk is so abysmal that I usually rip out the Hungarian notation (I
certainly rip it out
> >if it is used wrong!)
> >
> >There are only two major languages where type was encoded in the
identifier name: FORTRAN
> >and BASIC. Both of them abandoned it because it was a stupid idea.

Actually that's not true. Maybe there are some versions of BASIC that no
longer use special syntax in the symbol to indicate their type but the most
widely used version of BASIC today (Visual Basic) still supports this
feature.