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.

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.

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.

<snip>

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.

"-Lost" <maventheextrawords@techie.com> wrote in message >

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.