Z
Zytan
Are they possible? I am passing in a large array of Bytes, thus I
don't want to use ByVal.
Zytan
don't want to use ByVal.
Zytan
Zytan said:Are they possible? I am passing in a large array of Bytes, thus I
don't want to use ByVal.
Zytan said:How can I pass in an array to a function/sub so that the entire array
is const and cannot be changed? Or should I be using C# instead for
such functionality?
This cannot be done, not in VB and not in C#. You'd have to pass a copy of
the array or a proxy object to the function.
This is one of those:
Patient: "Doctor! It hurts when I do this."
Doctor: "Well don't do that!"
questions.
If you don't want the passed in array changed in your function, then don't
change it in your function!
Zytan said:Please elaborate on "proxy object".
The reason "const" exists is to prevent me from making
mistakes. Even the smartest of us make mistakes. The compiler helps
us avoid pitfalls with concepts like "const" and encapsulation. They
force good programming. That's why good programmers use them. I
can't even begin to explain how astonished I am at your reply...
I am further astonished that VB offers no way to protect programmers
from being stupid with passing in arrays. And that even C# doesn't
have this. I am just amazed... the fact that all VB programmers out
there in VB land are programming without this protection... and now
your reply makes more sense to me. Because it's the only solution, it
is the only way you CAN think about it. Amazing. (that is... unless
the proxy objects that Herfried mentioned are a solution...?)
Stephany,
No, no, no! This is very, very bad way of thinking about it. My
program doesn't change the array inside of the function. Really. I'm
a good programmer. Trust me. But, the point is... I don't trust
myself. The reason "const" exists is to prevent me from making
mistakes. Even the smartest of us make mistakes. The compiler helps
us avoid pitfalls with concepts like "const" and encapsulation. They
force good programming. That's why good programmers use them. I
can't even begin to explain how astonished I am at your reply...
I am further astonished that VB offers no way to protect programmers
from being stupid with passing in arrays. And that even C# doesn't
have this. I am just amazed... the fact that all VB programmers out
there in VB land are programming without this protection... and now
your reply makes more sense to me. Because it's the only solution, it
is the only way you CAN think about it. Amazing. (that is... unless
the proxy objects that Herfried mentioned are a solution...?)
Zytan
Are they possible? I am passing in a large array of Bytes, thus I
don't want to use ByVal.
Zytan
Dim Names() As String = ...
Foo(..., New ArrayProxy(Of String())(Names)), ...)
Foo(..., New ArrayProxy(Of String)(Names)), ...)
Yes you're absolutely right - the best of us do make mistakes.
That is why we have robust debugging and testing techniques.
Yes.
Checking that some variable that shouldn't be modified hasn't been is the
most the most basic of those techniques.
Even in C++ const didn't guarantee much since the reference's
constness could be casted away.
I think it was left out of C# because
the cost versus benefit of it tipped toward the unfavorable
direction. Implementing const reference parameters would add a
substantial amount of complexity to the language.
The best way to guarantee that an object's state cannot be changed is
to make it immutable.
Another strategy would be to use an interface or proxy object.
Though, I don't think either could absolutely be enforced at compile
time. A proxy object would probably be the best of two.
Brian,
No. It guarantees a LOT. I use it regularly on large projects. It
helps enforce design issues where certain elements of my code just
should not be allowed to mess with certain data. It is extremely
important. Also, for all the elsewhere mentioned reasons in another
post of mine, such as catching bugs at compile time, make it
priceless. It just forces good programming. How can you beat that?
Yes, you can cast it away -- but not with 'normal' C++ code. Casting
away const is not allowed. You can get around it with fancy C++ code
to trick the compiler into accessing that memory, but it's really just
a high level way of writing assembly. So, yes, it's not 100% bullet
proof. But, that's not the point. The point is the immense gain you
get, from being forced to write good code, from using it.
Just because someone can pick a lock, it doesn't mean you should stop
locking your door. Now imagine a lock that forces the door to be
locked, and forces you to have the keys on you, every time you leave.
Anything that forces good habits is a good idea.
Really? I don't really know. It's just sad that it doesn't exist...
Ok. Something else for me to learn. Any places I can get started on
researching this? Any help is appreciated.
Thanks for the suggestion. This was mentioned above, and for
something where it is critical (i.e. it warrants the extra hassle
involved), it certainly could be used.
badly then I don't understand why you are not using that instead of bleating
on about something that just "ain't gonna happen".
Yes, you're right. I may have been a little overzealous on my point.
At the very least const adds metadata that would let the caller know
that the method claims to not modify the state of the parameter. It's
up to the developer of that method to comply with what's advertised in
the metadata.
That doesn't necessarily mean it won't be added in the future. But, I
suspect the chances are not good for C# and even worse for VB.
It's not a particularly clever concept or anything. All you do is
make sure the methods on a class have no side-effects to the object
from which they are called. The String data type is an example of an
immutable class.