constant references

[Zytan]

Are they possible? I am passing in a large array of Bytes, thus I
don't want to use ByVal.

Zytan

[Branco Medeiros]

Re: constant references

Zytan wrote:

Are they possible? I am passing in a large array of Bytes, thus I
don't want to use ByVal.

When you pass an array by value, there's no copy of the array
contents, just of the array *variable*.

HTH.

Regards,

Branco,

[Zytan]

Re: constant references

Branco,

I had actually typed up a lengthy post asking about that, as well, and
Google Groups did something strange, and loaded a new page, erasing
the whole thing (one major flaw of web apps -- load a new page by
accident, and say goodbye to all your work), so I forgot about it, and
just asked the basic question.

I was going to ask if array variables are like C++ arrays (i.e. like
pointers), so that even if the 'pointer' is const, you can still
change what it points to (unless that is also const). All VB .NET
help files and tutorials never even touch upon these things. Very
annoying. It's like they think the programmer shouldn't be thinking
about these things...

Anyway... that leads to the question:

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?

Thanks for your reply,

Zytan

[Herfried K. Wagner [MVP]]

Re: constant references

"Zytan" <zytanlithium@y ahoo.comschrieb :

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Stephany Young]

Re: constant references

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" <zytanlithium@y ahoo.comwrote in message
news:1170370798 .443779.202060@ v33g2000cwv.goo glegroups.com.. .

Branco,
>
I had actually typed up a lengthy post asking about that, as well, and
Google Groups did something strange, and loaded a new page, erasing
the whole thing (one major flaw of web apps -- load a new page by
accident, and say goodbye to all your work), so I forgot about it, and
just asked the basic question.
>
I was going to ask if array variables are like C++ arrays (i.e. like
pointers), so that even if the 'pointer' is const, you can still
change what it points to (unless that is also const). All VB .NET
help files and tutorials never even touch upon these things. Very
annoying. It's like they think the programmer shouldn't be thinking
about these things...
>
Anyway... that leads to the question:
>
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?
>
Thanks for your reply,
>
Zytan
>

[Zytan]

Re: constant references

Herfried,

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.

I cannot *believe* this cannot be done. Wow... Ouch!

I know I can pass a copy (made with care) of the array, so that any
changes made within the function will not affect the original. But,
creating a copy of an array is a horrible thing to do when it needn't
be done... What terrible programming that would be, indeed. In my
case, I have an array of several MB in size.

Please elaborate on "proxy object".

Thanks for your reply,

Zytan

[Zytan]

Re: constant references

Stephany,

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!

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

[Herfried K. Wagner [MVP]]

Re: constant references

"Zytan" <zytanlithium@y ahoo.comschrieb :

>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.

>
Please elaborate on "proxy object".

\\\
Public Class ArrayProxy(Of T)
Private m_Array() As T

Public Sub New(ByVal Array() As T)
m_Array = Array
End Sub

Default Public ReadOnly Property Items(ByVal Index As Integer) As T
Get
Return m_Array(Index)
End Get
End Property
End Class
....
Dim Names() As String = ...
Foo(..., New ArrayProxy(Of String())(Names )), ...)
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Stephany Young]

Re: constant references

Yes you're absolutely right - the best of us do make mistakes.

That is why we have robust debugging and testing techniques.

Checking that some variable that shouldn't be modified hasn't been is the
most the most basic of those techniques.


"Zytan" <zytanlithium@y ahoo.comwrote in message
news:1170376597 .126681.37020@v 45g2000cwv.goog legroups.com...

Stephany,
>

>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!

>
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
>

[Cor Ligthert [MVP]]

Re: constant references

Zytan,

This discussion is already from the first beta versions. In my idea are you
right, but this seems to be a hobby from the main architect from the Net
languages. (And unchangable now of course)

Cor

"Zytan" <zytanlithium@y ahoo.comschreef in bericht
news:1170376597 .126681.37020@v 45g2000cwv.goog legroups.com...

Stephany,
>

>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!

>
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
>

[Branco Medeiros]

Re: constant references

Zytan wrote:
<snip>

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...?)

Unfortunatelly, there's no const propagation *in .Net*, as far as I
can't tell (I guess C++ programs that use const like this aren't CLS
compatible).

The only resort for the mindfull programmer is strong faith or relying
on the "AsReadOnly " that certain objects expose. But then,
unfortunately, the erroneous access will only be caught at run time,
not a compile time as it should be...

Sad, indeed...

Regards,

Branco.

[Brian Gideon]

Re: constant references

On Feb 1, 6:36 pm, "Zytan" <zytanlith...@y ahoo.comwrote:

Stephany,
>

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!

>
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

Zytan,

Even in C++ const didn't guarentee 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 guarentee 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

[lord.zoltar@gmail.com]

Re: constant references

On Feb 1, 3:24 pm, "Zytan" <zytanlith...@y ahoo.comwrote:

Are they possible? I am passing in a large array of Bytes, thus I
don't want to use ByVal.
>
Zytan

Have you tried using ByRef? Look up passing variables ByRef for
VB .NET.

[Zytan]

Re: constant references

Herfried,

Thanks proxy object code sample. (I just learned how the Default
keyword works... neat!)

Dim Names() As String = ...
Foo(..., New ArrayProxy(Of String())(Names )), ...)

I think you mean: Note the lack of () after "String". I couldn't get
it to compile your way.

Foo(..., New ArrayProxy(Of String)(Names)) , ...)

Ok... this solution is lacking in that the Foo function cannot discern
the length of the array. Ouch. Not only that, but to pass in the
length of the array to Foo, the caller can also not discern its length
for the same reason. You must use the length of the array that it was
constructed from (Names.Length, in this case). It's ugly. Also, all
of this mess just to do what "const" does in C++ <sigh It's just all
ugly... I can't help it, it's the truth.

But, thanks for your input, Herfried. It's nice to be able to
consider all possibilities.

Zytan

[Zytan]

Re: constant references

Stephany,

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.

No. Leaving such a simple, laborious task to the compiler is one of
the basic of those techniques.

No human can possibly read code like English, and look over a function
in a swift manner, and determine that the constant variables are
unchanging. What happens if one of them is passed to another
function? You have to either look at that function's code, and all
it's inner function calls, all the way down the stack / tree, and
then, if you haven't missed anything (and, since when is any human
perfect), you can determine that the code is correct. If you're
incorrect, hopefully you'll catch the bug during runtime development
and not after deployment, where it's 100 times more costly to fix than
during runtime development.

OR... you could use "const" -- 5 letters -- and let the compiler
notify you during COMPILE time which is 1/10th as costly as catching
it during beta testing. The compiler can go through all your code,
and determine at all levels that the variable is not being changed.
You can create "const" class functions to ensure the class data
members remain unchanged, and these are only allowed to be call other
functions that promise the same thing. All caught at compile time.

This is several ORDERS OF MAGNITUDE more robust than "human checking".

Besides, who has time to check code? Who does this? Even if you
*could* check all that code, and were as perfect as a machine, why
would you want to waste your time doing this? The time would be
better spend writing more robust code, letting the compiler check all
of that for you, removing any worries / intellectual barriers that you
may have about potential broken code.

Zytan