VB.NET and pointers

[Guest]

VB.NET (v2003) does not support pointers, right? Assuming that this is true, are there any plans to support pointers in the future? Forgive my ignorance, but if C# supports pointers and C# and VB.NET get compiled into the same code, then I don't understand why VB.NET can't support pointers

Thanks for any info
Lance

 

[Tom Shelton]

VB.NET (v2003) does not support pointers, right? Assuming that this is true, are there any plans to support pointers in the future? Forgive my ignorance, but if C# supports pointers and C# and VB.NET get compiled into the same code, then I don't understand why VB.NET can't support pointers.

Thanks for any info.
Lance

I'm assuming by pointers, you mean direct memory addressing - like you
can do in C# in unsafe code sections. Well, it is not a matter of can't
support it. VB.NET could in fact support it if the designers saw fit to
include it - but I don't think that will happen. I think a lot of it
has to do with the fact that VB.NET has it's roots in BASIC, and
pointer manipulation is not someone usually associates with BASIC

Pointers are not a magic solution. In my 9 to 5, I'm a C# coder - and I
can tell you that I have never used an unsafe code block yet in
production code. I have used them for my own pet project (a C# wrapper
for the Linux curses library using Mono) - but even then I try to keep
them to the minimum. When you start messing around with raw pointers,
you remove a lot of the benifits of a managed environment - namely
automatic memory management and code safety.

Look, if you need pointers - you can always write that bit of code in C#
and then call it from VB.NET. Think of it as a good excuse to learn
both languages (it's my personal oppinion that it is a good idea to
learn both well anyway).

 

[Guest]

First off, thank you very much for your response. The rest of this is directed mostly towards the designers of VB.NET

I'm assuming by pointers, you mean direct memory addressin
Yes

VB.NET could in fact support it if the designers saw fit to include i

The most recent issue of MSDN magazine demonstrated the importance of pointers in scientific computing scenarios (March 2004, pg. 64). I don't understand how the "designers" can't foresee the possibility that people who use VB.NET will encounter those scenarios

I think a lot of it has to do with the fact that VB.NET has it's roots in BASIC, and pointer manipulation is not someone usually associates with BASIC

Thankfully, a lot of VB.NET is not what I would usually associate with BASIC. That's why I'm using VB.NET rather than BASIC

When you start messing around with raw pointers, you remove a lot of the benefits of a managed environment - namely automatic memory management and code safety

Yes, I know, pointers can result in undesirable results if used improperly. But, in some rare situations there are no attractive alternatives to using pointers. Also, there are countless ways for a programmer to get into trouble. For example, what about threads? These can cause all kinds of problems. So, shouldn't the "designers" have reserved multithreading for C# as well

Look, if you need pointers - you can always write that bit of code in C# and then call it from VB.NE

That seems to be everybody's recommendation, that is, right after they warn you about the terrible dangers about using pointers. So, are pointers in C# somehow safer than they would be in VB.NET? If not, then wouldn't it be safer to allow me to use pointers in the language that I'm most knowledgeable? I guess I don't follow the logic of "pointers are dangerous so go use them in a language that you're not comfortable with". In my experience, the times when there would be an advantage to using pointers tend to be the times when I'm doing something complex, which is the worst time to go and use an unfamiliar language

I guess it is pretty obvious that I'd like to see pointers in VB.NET. I just don't think that excluding pointers because some language back in the vacuum-tube-days didn't support them is very convincing. Let’s face it, we all know that there are times when pointers are the best option. How about this, if pointers are so dangerous then put them in a new namespace called something like System.SmaryPants. Or, how about Microsoft.VisualBasic.CSharpWantToBe? That way it would be obvious that only the truly gifted should use them

Lance

 

[Gary Chang]

Hi

Thanks for posting in the community.

Currently I am looking for somebody to look this issue. We will reply you
as soon as possible.
If you have any more concerns on it, please feel free to post here.


Thanks!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

 

[Armin Zingler]

Yes, I know, pointers can result in undesirable results if used
improperly. But, in some rare situations there are no attractive
alternatives to using pointers. Also, there are countless ways for a
programmer to get into trouble. For example, what about threads?
These can cause all kinds of problems. So, shouldn't the "designers"
have reserved multithreading for C# as well?

IMO, the introduction of pointers would have broken one main benefit of the
managed environment: type safety and managed execution. Threads don't brake
this. They "only" might cause "logical" problems. Pointers can create
"damage" at a much lower level.

That seems to be everybody's recommendation, that is, right after
they warn you about the terrible dangers about using pointers. So,
are pointers in C# somehow safer than they would be in VB.NET? If
not, then wouldn't it be safer to allow me to use pointers in the
language that I'm most knowledgeable? I guess I don't follow the
logic of "pointers are dangerous so go use them in a language that
you're not comfortable with". In my experience, the times when there
would be an advantage to using pointers tend to be the times when I'm
doing something complex, which is the worst time to go and use an
unfamiliar language.

I think, the design question was: Do we really need pointers in VB.NET?
Answer: No, we didn't have them in previous versions and they could lead to
problems actually to be avoided in the new managed world. Same question for
C#: Yes, we need pointers. There are drawbacks but it would have been much
worse to scare off all the C++ people.

Some design decisions are based on the previous versions - why make two
languages otherwise?

I guess it is pretty obvious that I'd like to see pointers in VB.NET.
I just don't think that excluding pointers because some language
back in the vacuum-tube-days didn't support them is very convincing.
Letâ?Ts face it, we all know that there are times when pointers are
the best option. How about this, if pointers are so dangerous then
put them in a new namespace called something like System.SmaryPants.
Or, how about Microsoft.VisualBasic.CSharpWantToBe? That way it
would be obvious that only the truly gifted should use them.

Despite I personally would need pointers only in, well, let's say 0 -
0.0000001% of my code, I see that they are useful and I won't have a problem
if unsafe blocks will be introduced in future versions.

 

[Herfried K. Wagner [MVP]]

VB.NET (v2003) does not support pointers, right? Assuming that this
is true, are there any plans to support pointers in the future? Forgive
my ignorance, but if C# supports pointers and C# and VB.NET get compiled
into the same code, then I don't understand why VB.NET can't support
pointers.

Short answer: I don't think that there are any plans to include unsafe
features into the VB.NET programming language. Visual Basic always used
to be a high-level programming language, pointers simply wouldn't fit
into that concept.

Pointers as known from C and unsafe C# can cause serious bugs in the
application if not used properly (programmers are not "Gods", they make
mistakes), for example, they can break type safety.

 

[Jay B. Harlow [MVP - Outlook]]

Lance,
In addition to the other comments. My understanding that is the target
audience for VB.NET (Rapid Application Development) would not be very likely
to need pointers, hence VB.NET does not (will not) include pointers.

While the target audience of C# (Framework Developers) has unsafe code &
pointers, as they are useful in Frameworks, such as the MSDN article you
mention.

Yes! you can use VB.NET for frameworks & you can use C# for RAD, that's not
the point of the above statements...

Unfortunately I do not have specific links to specific articles on where I
came to this conclusion...

Also remember, the MS programmers who create C# & VB.NET have a list of
features to include in the next release. They review this list comparing it
to the perceived needs of their respective "target audience" and prioritize
this list...

Personally unsafe code would be a "nice to have" in less then 1% of what I
do, I suspect for the majority of other VB.NET developers its an even lower
percentage. So for me its more important that MS gets Generics & Operator
Overloading to work rather then having unsafe code & pointers, after all I
can drop into C# for that code. On the same token some of the other items
(New & Improved types in the Microsoft.VisualBasic namespace) in Whidbey I
may not have a big need for, but I see significant value for the majority of
other VB.NET & RAD developers...

You could always submit a request via MS Wish.
http://register.microsoft.com/mswish/suggestion.asp

Hope this helps
Jay

VB.NET (v2003) does not support pointers, right? Assuming that this is

true, are there any plans to support pointers in the future? Forgive my
ignorance, but if C# supports pointers and C# and VB.NET get compiled into
the same code, then I don't understand why VB.NET can't support pointers.

 

[Mark Jerde]

That seems to be everybody's recommendation, that is, right after
they warn you about the terrible dangers about using pointers. So,
are pointers in C# somehow safer than they would be in VB.NET? If
not, then wouldn't it be safer to allow me to use pointers in the
language that I'm most knowledgeable? I guess I don't follow the
logic of "pointers are dangerous so go use them in a language that
you're not comfortable with". In my experience, the times when there
would be an advantage to using pointers tend to be the times when I'm
doing something complex, which is the worst time to go and use an
unfamiliar language.

Hehehe... Careful, you're making sense to me. ;-)

-- Mark

 

[Cor]

Hi Lance,

I agree with you that this is the only part VB.net misses to be a real great
language.

I have also often seen in this newsgroup that the wish of people now is
limited to the possibilities of the language.

On the other hand it should in my opinion not has to be something as an
addition on managed code.

To make very small functions for very special purposes.

Just my 2 Eurocents


Cor

 

[Rob Teixeira [MVP]]

VB does in fact support pointers. References to objects and ByRef parameters
are addresses. However, what you are looking for is direct manipulation of
addresses or the contents of a specific address. VB does support this, but
not in a way that is embedded in the language. The IntPtr type (which is
accessable from VB) represents a platform-specific integer value, used for
(among other things) holding addresses. You can use several utilities in the
System.Runtime.Interop namespace to retrieve the address and modify the
contents located at an address contained in an IntPtr.

However, to counter some of the arguments made about VB's roots in BASIC
being the reason for a lack of direct pointer support, let's remember that
BASIC did indeed have PEEK and POKE. I for one would like to see unsafe code
blocks in VB. I've only written two production C# programs since 2001 that
use unsafe code, but they really did help. The percentage of times a feature
is used doesn't seem like a good criteria - i'd rather measure the
usefullness, even if it's only required in a small percentage of situations.
After all, VB is getting (for example) operator overloads in the next
version (and VERY good support for them too!). You can make the same
arguments about operator overloads only being necessary in a small number of
cases, but when you need them, it's not easy to "work around" the lack of
support for them. What I like most about VB.NET over VB6 is that unlike VB6,
most of my VB.NET code is "hack-free" - I didn't have to do something
unintuitive or unsupported to "get around" some limitation. I would like to
see the last of that "hack" stuff go away by having real unsafe code blocks
supported by the language - after all, if I use the Marshal class, I can
already write the very same unsafe code with the same risks and side-effects
(but not get 100% of the performance benefit). It's also incredibly useful
when dealing with unmanaged code (which isn't going away anytime soon).

As for the RAD-vs. Framework argument... I always thought there was a
certain amount of ... well, BS in that argument. C# was an attempt to make a
RAD C language (as stated directly by MS in 2000-2001). However, now that
there are two primary languages in .NET, there are a lot of programmers that
are grasping for the answer to "which one should i use? what makes them
different?". Seems like some people have taken a stab at trying to "invent"
a reason for chosing one vs the other by artificially creating this RAD vs.
Framework argument. The truth is much simpler - people who love Java and
C(++) want to continue using a familiar curly-bracket consise language.
People who love VB tend to hate the syntax structure of C, and prefer to use
something familiar as well. That is the WHOLE POINT of having a CLI in the
first place - a common language infrastructre that supports the same
operations for multiple syntax sets. Unlike Java, MS set out to create an
environment where the programmer wasn't forced into one new language in
order to use the massive .NET framework and runtime features. The programmer
could use a language he/she was familiar with and be productive from the
very start without a massive learning curve. The real differenciating
principle should be "a matter of choice". In whidbey (the next version of
VS), the differences between the two languages gets extremely small. C#
still doesn't support non-indexer properties with parameters, and VB.NET
still doesn't support unsafe code blocks - but minutia aside, that's about
it. In addition, most of VB.NET's RAD features aren't all exactly syntax
(language) related - they are mostly support from an extremely large and
useful runtime library and IDE tools. C# could get a similarly-huge runtime
and better IDE tools and that would make it more RAD - and this has nothing
to do with the language itself. I can't tell you how many times people go to
the various C# groups and say "there's this function in VB, what's the C#
equivalent?" and the answer is "go build it yourself" or "reference the VB
runtime library". That is a matter of runtime library support, not language.
With Option Strict On, this argument makes very little sense, as the
structure, strict type-safety, and need for good design are about identical.

-Rob Teixeira [MVP]

VB.NET (v2003) does not support pointers, right? Assuming that this is

true, are there any plans to support pointers in the future? Forgive my
ignorance, but if C# supports pointers and C# and VB.NET get compiled into
the same code, then I don't understand why VB.NET can't support pointers.

 

[Guest]

The percentage of times a feature is used doesn't seem like a good criteria - i'd rather measure the usefullnes

Very well said, as was the rest of your argument. I sure hope that the MS team is listening

Thanks for you comments
Lance

 

[Peter Huang]

Hi Lance,

Thanks for posting in the community.

First of all, I would like to confirm my understanding of your issue.
From your description, I understand that you hope that the VB.NET will
support point as C# does.
Have I fully understood you? If there is anything I misunderstood, please
feel free to let me know.

I have reported your concern, and I will get back here with new information
ASAP.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Peter Huang]

Hi Lance,

Thanks for posting in the community.

Based on my researching, I think you are right in assuming that VB.NET
could potentially support unsafe code blocks. For now, VB language team
decided not to add this functionality to VB.NET at this time, it may (or
may not) be added in the future.

Your intiuative thought would be that functionalities available to C#
programmers would also be available to VB.NET programmers since both are
compiled to MSIL. However, this is not the case. Unsafe code blocks were
left out of the VB.NET language because of the target audience. It was
determined that the typical VB developer does not need to run unsafe code
or wouldn't benefit/use it enough to add it to the language. If the need
exists for the VB.NET developer to run unsafe code they can either leverage
C#, managed C++, or can use PInvoke to call into unsafe code. This does
not mean to say that it will not be added in the future (it is currently
not in whidbey).

If you have any concern on this issue, please post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Thanks for taking the time to look into this for me. I appreciate the feedback (even though it wasn't what I wanted to hear).