My professor said NEVER pass by reference. Your opinions please?

[-Lost]

My professor said NEVER pass by reference. Your opinions please?

I am not quite sure about this thing he said, so I came here for your
advice, opinions, or whatever.

Everything I was told was that reusing memory and/or objects is more
efficient than creating numerous copies of your data (which is what I
thought passing by value did). So can you offer your insight on
this, and on what he said below? Thank you!

"So my take on reference and value is this:

Rule 1)
Never pass by reference unless you have a specific reason to do so

The only real reason to ever do this is when you need to get back
more than 1 value from a function. Keep in mind that by definition,
functions can return AT MOST, one value. So if you need two things
coming out, then pass those variables by reference and make sure the
method is a void method (it just keeps things simpler in my opinion).

Now, why is it bad to pass by reference? Because you're giving
another method direct access to your memory, which is a bit scary.
Think of it, now that method can make any changes it wants to my
variable. Also keep in mind that many times one programmer will write
one method and another will call on it.

I don't know, it's just a bit worrisome at times, that's all."

Thanks again for your time.

 

[Jon Skeet [C# MVP]]

My professor said NEVER pass by reference. Your opinions please?

I think he didn't say that you should never pass by reference. I think
he said you should never pass by reference unless you have a specific
reason to - at least according to the quote below. Those are two very
different rules.

I am not quite sure about this thing he said, so I came here for your
advice, opinions, or whatever.

Everything I was told was that reusing memory and/or objects is more
efficient than creating numerous copies of your data (which is what I
thought passing by value did).

You need to be clear about what "pass by value" means when it comes to
reference types:

http://pobox.com/~skeet/csharp/parameters.html

Jon

 

[-Lost]

I think he didn't say that you should never pass by reference. I
think he said you should never pass by reference unless you have a
specific reason to - at least according to the quote below. Those
are two very different rules.

You're right, sorry about that. In our seminar he said "never pass
by reference, it's easier that way and also more feasible to use pass
by value." An exact quote again from the log.

The quote I provided previously came from our discussion boards.

You need to be clear about what "pass by value" means when it
comes to reference types:

http://pobox.com/~skeet/csharp/parameters.html

That is funny -- I used that exact (yoda) URL in my discussion post
(we had to try to summarize pass by value and pass by reference). I
honestly don't grasp every bit of it (partly because I've never read
anything on structs except they are "dumb classes."), so I need to
reread it again (and probably again).

I'm also planning on ordering your book. I'm not too confident in
this book from Thomson Learning -- since I'm on chapter 8 and I'm not
even sure of some of the simple mechanics yet.

I am disabled, and never explain things clearly... but I'd like to
direct you to the book to see for yourself (the reviews pretty much
say at it all).

[URL: http://www.amazon.com/Microsoft-Visual-NET-Programming-
Analysis/dp/0619159979/ref=pd_bbs_sr_3/002-3986664-1542422?ie=UTF8
&s=books&qid=1203352280&sr=8-3 ]

# ISBN-10: 0619159979
# ISBN-13: 978-0619159979

Thanks, Jon, I'll read that article of yours again.

 

[Jon Skeet [C# MVP]]

You're right, sorry about that. In our seminar he said "never pass
by reference, it's easier that way and also more feasible to use pass
by value." An exact quote again from the log.

The quote I provided previously came from our discussion boards.

Right. I wouldn't put it quite as strongly as that. I'd say it's worth
avoiding passing things by reference unless it makes things
significantly better/easier. Sometimes it's handy though. In particular
"out" is like "ref" and things like int.TryParse use out parameters in
a sensible manner.

That is funny -- I used that exact (yoda) URL in my discussion post
(we had to try to summarize pass by value and pass by reference).


I honestly don't grasp every bit of it (partly because I've never read
anything on structs except they are "dumb classes."), so I need to
reread it again (and probably again).

Ick - structs certainly aren't "dumb classes". They can be just as
sophisticated as classes, it's just that they're value types instead of
reference types. They can still have methods, properties etc.

A couple of other pages which might help:

http://pobox.com/~skeet/csharp/references.html
http://pobox.com/~skeet/csharp/memory.html

I'm also planning on ordering your book. I'm not too confident in
this book from Thomson Learning -- since I'm on chapter 8 and I'm not
even sure of some of the simple mechanics yet.

I am disabled, and never explain things clearly... but I'd like to
direct you to the book to see for yourself (the reviews pretty much
say at it all).

Yes, they're pretty damning reviews... can't say I've read it myself
though, so wouldn't like to pass judgement too much without seeing the
real thing.

 

[Steve Richter]

My professor said NEVER pass by reference.  Your opinions please?

how would passing by reference be avoided in c# since reference types
are so much a part of the language? Is the teacher referring to a non
GC language like C++?

 

[Ben Voigt [C++ MVP]]

You're right, sorry about that. In our seminar he said "never pass
by reference, it's easier that way and also more feasible to use pass
by value." An exact quote again from the log.

So your professor may be an idiot. There are more than a few of those
teaching comp sci courses, who majored in comp sci b/c they heard that's
where the money is, then got exposed for uninterested and incompetent during
the interview process, and ended up teaching.

Or else he thinks all his students are idiots, he knows perfectly well what
pass-by-reference is good for but doesn't think you'd understand.

Or maybe he's a bad lecturer, he knows the answer, knows you could learn it,
but doesn't know how to explain it.

In any case you're in for a worthless semester.

You'll do yourself a favor in the future by picking your courses based on
the professor teaching, not the subject matter (or worse yet, the title).

 

[Ben Voigt [C++ MVP]]

Now, why is it bad to pass by reference? Because you're giving

another method direct access to your memory, which is a bit scary.
Think of it, now that method can make any changes it wants to my
variable. Also keep in mind that many times one programmer will write
one method and another will call on it.

I don't know, it's just a bit worrisome at times, that's all."

Give him a link to material on API design and contracts.

But in C# (and .NET in general), the assertion just isn't true.

The other method can only change your data in ways that are
(1) typesafe
(2) obey visibility rules

 

[Jon Skeet [C# MVP]]

how would passing by reference be avoided in c# since reference types
are so much a part of the language? Is the teacher referring to a non
GC language like C++?

"Passing by reference" isn't the same as "passing a reference by
value".

See http://pobox.com/~skeet/csharp/parameters.html

 

[-Lost]

So your professor may be an idiot. There are more than a few of
those teaching comp sci courses, who majored in comp sci b/c they
heard that's where the money is, then got exposed for uninterested
and incompetent during the interview process, and ended up
teaching.

Hehe. Honestly, I've been talking about the fact I think he may be
an idiot for some time now. But being a n00b programmer, I keep
giving him the benefit of the doubt.

Or else he thinks all his students are idiots, he knows perfectly
well what pass-by-reference is good for but doesn't think you'd
understand.

All he would say on the matter (on several different occasions) was
that references were only good for when you needed to return more
than one value -- that is where I am at now -- I asked him to explain
that, and he's not responded yet.

Or maybe he's a bad lecturer, he knows the answer, knows you could
learn it, but doesn't know how to explain it.

I'll go with bad lecturer. He also told us in class that we should
avoid arrays, loops, and object-oriented programming for now until we
get the hang of C#.

In any case you're in for a worthless semester.

I've become accustomed to that over the last several years. Not that
I like it, just that it's probably going to happen.

You'll do yourself a favor in the future by picking your courses
based on the professor teaching, not the subject matter (or worse
yet, the title).

It's an online college, and that just isn't possible. Even if it
were I've nothing to base it on. For example, the current professor
has a Bachelor's in Physics and a Master's in Applied Math -- I'd be
fairly OK choosing that person as a professor. But like you said,
some weren't cut out to be in the profession so they resort to
teaching.

ALSO... he told us that he taught himself C# and VB from the MSDN.
Not indicative of incompetence I suppose -- then again, it depends on
the person reading the material.

Thanks for the feedback.

 

[-Lost]

Give him a link to material on API design and contracts.

I don't know of any offhand, but I probably wouldn't anyway.

The bastard already gives me long lectures about how I need to slow
down since this is a beginner course.

YET... has also said that he's sorry he cannot be of more help (when
I ask him questions) because I should have had 3 programming classes
prior to this one to teach me intermediate and advanced topics in
abstract programming.

Anyway, point is, I'd like to get him teaching, not running his
useless mouth more. : )

But in C# (and .NET in general), the assertion just isn't true.

The other method can only change your data in ways that are
(1) typesafe
(2) obey visibility rules

What is "the other method" in this context? Sorry if I missed the
apparent.

 

[Alun Harford]

My professor said NEVER pass by reference. Your opinions please?

I am not quite sure about this thing he said, so I came here for your
advice, opinions, or whatever.

Everything I was told was that reusing memory and/or objects is more
efficient than creating numerous copies of your data (which is what I
thought passing by value did). So can you offer your insight on
this, and on what he said below? Thank you!

"So my take on reference and value is this:

Rule 1)
Never pass by reference unless you have a specific reason to do so

The only real reason to ever do this is when you need to get back
more than 1 value from a function. Keep in mind that by definition,
functions can return AT MOST, one value.

<theory type="mostly harmless">

Eugh. While this is technically correct, a more useful statement would be:

Functions return exactly one value.

</theory>

Alun Harford

 

[Lasse Vågsæther Karlsen]

Response to "Jon Skeet [C# MVP]" <[email protected]>:

On Feb 18, 3:50 pm, "-Lost" <[email protected]>
wrote:
My professor said NEVER pass by reference. Your opinions
please?
I think he didn't say that you should never pass by reference. I
think he said you should never pass by reference unless you have
a specific reason to - at least according to the quote below.
Those are two very different rules.
You're right, sorry about that. In our seminar he said "never
pass by reference, it's easier that way and also more feasible to
use pass by value." An exact quote again from the log.

So your professor may be an idiot. There are more than a few of
those teaching comp sci courses, who majored in comp sci b/c they
heard that's where the money is, then got exposed for uninterested
and incompetent during the interview process, and ended up
teaching.

Hehe. Honestly, I've been talking about the fact I think he may be
an idiot for some time now. But being a n00b programmer, I keep
giving him the benefit of the doubt.

The distinction between an idiot and a genius is sometimes an odd one.
Not that I consider myself a genius, but I have managed to lose several
TV shows simply because I didn't understand how to program my VCR, back
when I had that type of unit, even when I read the manual (yes, I'm that
kind of person!). I was certainly an idiot when it came to the VCR, but
I think I can hold my own when it comes to programming. Your professor
probably has his fields where he shines.

Most likely programming isn't one of them. It doesn't sound like it anyway.

Which may be a valid reason for not going into the details, but there is
a long way from a fact to a reason for not telling. In such teaching
scenarios I've always had more luck with telling them shortly that there
are reasons, but that these will become apparent when they have more
experience.

All he would say on the matter (on several different occasions) was
that references were only good for when you needed to return more
than one value -- that is where I am at now -- I asked him to explain
that, and he's not responded yet.

This sounds more like an opinion, which he's entitled to, instead of a
fact. I think the important thing here is that you're questioning his
advice and reasons.

I'll go with bad lecturer. He also told us in class that we should
avoid arrays, loops, and object-oriented programming for now until we
get the hang of C#.

Well, nonwithstanding that particular advice, you *are* best adviced to
learn one thing in programming before you start mixing in another thing.
Programming is a lot about combining lots of little things and if you
can't tell them apart or use them effective on their own, chances are
you'll have a hard time getting to grips with more complex programming
tasks. I am not commenting on your skills right now as I have no idea
what you're capable of, but small steps

On the other hand, C# *is* an object oriented programming language,
since *everything* is an object, so I don't really see how you can avoid
that, unless he means you should avoid trying to declare your own
classes for now and learn about the various parts of OOP, like
polymorphism, encapsulation, inheritance, etc.

ALSO... he told us that he taught himself C# and VB from the MSDN.
Not indicative of incompetence I suppose -- then again, it depends on
the person reading the material.

Commenting on general principles here.

Unless you have a practical background in programming I don't think you
can teach good principles in the matter either. Programming isn't quite
like math where you can usually end up with one answer and the way to
get there from the problem is fairly staked out by the theory. In
programming there are an infinite ways to get to a possible solution,
but not that many that are considered good and fewer still that are
considered above the rest.

Programming is more a creative profession than a theoretical one, albeit
one grounded in solid theory. However, creativity comes with
possibilities, and possibilities comes with experience.

Hope you get some value out of your class.

And never take "it just is so" as an answere. There's always a reason.
Even if that reason is "because I say so".

Now, for your particular question, the given answer about returning more
than one thing is one reason for using reference parameters. Another
could be that instead of making a duplicate of an expensive (meaning:
large) value type on the stack when passing it to a method, you pass it
as a constant reference to it to the method, which means you simply pass
a pointer, which is cheap. Granted, this can't be done in C# since const
pointers/references isn't really supported (perhaps they're supported by
the runtime, don't know really), but that's also a common reason for
using reference parameters.

 

[Arne Vajhøj]

My professor said NEVER pass by reference. Your opinions please?

I am not quite sure about this thing he said, so I came here for your
advice, opinions, or whatever.

Everything I was told was that reusing memory and/or objects is more
efficient than creating numerous copies of your data (which is what I
thought passing by value did). So can you offer your insight on
this, and on what he said below? Thank you!

"So my take on reference and value is this:

Rule 1)
Never pass by reference unless you have a specific reason to do so

The only real reason to ever do this is when you need to get back
more than 1 value from a function. Keep in mind that by definition,
functions can return AT MOST, one value. So if you need two things
coming out, then pass those variables by reference and make sure the
method is a void method (it just keeps things simpler in my opinion).

Now, why is it bad to pass by reference? Because you're giving
another method direct access to your memory, which is a bit scary.
Think of it, now that method can make any changes it wants to my
variable. Also keep in mind that many times one programmer will write
one method and another will call on it.

I don't know, it's just a bit worrisome at times, that's all."

I don't think the reason for it usually being a bad idea
is "direct access to your memory" (that sounds as a C/C++
argument not as a C# argument).

The reason for it usually being a bad idea is in my
opinion that the code is much harder to read.

Arne

 

[Scott Roberts]

All he would say on the matter (on several different occasions) was
that references were only good for when you needed to return more
than one value -- that is where I am at now -- I asked him to explain
that, and he's not responded yet.

Sorry, but I'm a little confused. Under what other circumstances are you
wanting to use pass-by-reference?

If your only reason for using pass-by-reference is for memory optimization,
then I think your instructor is probably right. You would need to be passing
pretty large values a significant number of times to see a performance
penalty using pass-by-value.

I will also say that your professor's "rule" is much more applicable when
pass-by-reference doesn't require any additional code in the method call.
This is a readability nightmare. C# has alleviated that problem (somewhat)
by by requiring the "ref" keyword when the method is called. It can still
represent a problem to the caller, though, if all parameters are "ref" all
of the time, as now the calling code has no idea whether a parameter will
really change, and if so, under what circumstance, or if it is simply an
optimization technique. Imagine that the calling code creates a temp
variable to pass into your function because it doesn't want its original
variable modified. Now you've not only completely negated any performance
gain, but you've caused the caller to obfuscate their code.

So yeah, "never" is a pretty strong word, but I'd say it's relatively rare
that you would want to pass by reference in any circumstance other than you
are intentionally modifying the parameter value.

 

[jehugaleahsa]

My professor said NEVER pass by reference.  Your opinions please?

I am not quite sure about this thing he said, so I came here for your
advice, opinions, or whatever.

Everything I was told was that reusing memory and/or objects is more
efficient than creating numerous copies of your data (which is what I
thought passing by value did).  So can you offer your insight on
this, and on what he said below?  Thank you!

"So my take on reference and value is this:

Rule 1)
Never pass by reference unless you have a specific reason to do so

The only real reason to ever do this is when you need to get back
more than 1 value from a function. Keep in mind that by definition,
functions can return AT MOST, one value. So if you need two things
coming out, then pass those variables by reference and make sure the
method is a void method (it just keeps things simpler in my opinion).

Now, why is it bad to pass by reference? Because you're giving
another method direct access to your memory, which is a bit scary.
Think of it, now that method can make any changes it wants to my
variable. Also keep in mind that many times one programmer will write
one method and another will call on it.

I don't know, it's just a bit worrisome at times, that's all."

Thanks again for your time.

As with everything else in life, simplifying anything to something
expressible as a 'yes' or 'no' or 'good' or 'bad' is going to make you
sound like an idiot to someone out there. He probably had good
intentions, to tell everyone to not get careless with references, and
reduce them to as few as possible.

On the other hand, references have their place, and C#'s "contractual
agreement" of ref in the caller and callee is all the more proof. I
think all the TryParse methods are a good example where returning and
ref/out all in one make perfect sense.

My final point is that in C#, by-reference has a slightly different
meaning than it does in C or C++. In C#, ref for a value types is like
a reference or pointer in C++. ref for reference types is like a
pointer pointer or a pointer reference. It is very rare that you
really want to have your reference point to a different memory
location. But when you do, the ability is there, and you're professor
will be happy about that.