is there an advantage (vb.net vs c#)

[PlausiblyDamp]

If you are working with classes then you are only passing references to the in memory structures anyway, only value type objects (Structures) will cause copies to be created.

Although pointer manipulation can be faster you need to weigh up 'how much faster' against 'effort to get it right'. Using pointers may be quicker than a foreach loop over an array or collection - but unless profiling indicated this was a bottleneck and causing appreciable problems I would stick with the foreach loop every time.

Also you need to be careful of getting too clever when doing optimisations at the ASM level under windows as you may not see the overall effect of the tweaks you are doing; for example: although forcing a pointer into a register can give better performance - you are potentially hurting the performance of other aspects of your app / system. (IIRC most C/C++ compilers treat the register keyword more as a hint than a command anyway.)

Although the .Net JIT is still in it's infancy it does do some optimisations and it's ability to do so will improve with time - certain issues in the 1.x version have been / are being addressed in the 2.x version.

Edited March 1, 2005 by PlausiblyDamp

[coldfusion244]

Isn't any index in the Array of Int's found by: ArrayAddress + IntexPos*4? Is this math avoided when directly using Pointers? I don't quite see how things go faster...

 

Yes that is true Mike, let me give a different example that may help more. You have created a structure that is called house. It has doors, windows, floor plans, actions (find how much voltage,current, which way doors swing, the family that lives in it, etc etc; all the small details, like a actual family and house would have) and you were doing opertaion on them with a function that had a prototype of such:

 

house* hCorrectHouse CompareHouses(house* hHouse1, house* hHouse2);

 

It basically says I am a function that returns a pointer to an object of type house and I take a pointer to a house object in memory for hHouse1 and the same for hHouse2. Since the house class is a huge object that encapsulates much data it may take up to 1 MB per house of memory. Now, since you are passing a pointer to that location in memory, there is no need to move that data into the function when calling. So you are really only sending 2 small 32bit numbers to the funciton instead of 2 of these huge 1 meg objects. Since the function returns a pointer to the compared houses, the function only returns a 32bit number in the form of a pointer to the correctly compared house, rather than transferring the 1 meg object. This not only makes it faster by traversing less data, it also let's you control memory allocation. So, if I compared the houses and decided the one that is incorrect to free up space, I can set it to null and delete the pointer. BAM memory allocated back to the system; no waiting for the GC.

 

As for unsigned data types, I did say that yes, using the extra bit for a wider (positive only) number range is a benefit. But it also can enhance the performance of the program by not bogging it down with larger data types that aren't needed. Why use a 16-bit integer when and unsigned 8-bit will do? It also is nice when you are doing [this is from hardware programming more than software] bit manipulation and you don't want the carry flag to be set when you rotate right or rotate left... again more lower level than you should really be doing in VB.

Edited March 1, 2005 by coldfusion244

[snarfblam]

I vote that this topic be locked before this goes on for too much longer

[Tygur]

eh? I thought it was a pretty intelligent discussion so far, with quite a lot of info about the differences between VB.NET and C# being passed around.

[Mike_R]

Yeah, I agree... this kind of thread is always at grave risk of going down in flames (litterally), but I think we're doing pretty ok. :)

[Mike_R]

I'm a little lost. Putting this code in a form results in an extra TextBox being added to it. But unless I misread your post, you seem to be saying it's not supposed to work. Giving a variable the same name as a class doesn't limit anything, as far as I can tell. You just can't declare both the variable and the class at the same level.

Protected Overrides Sub OnLoad(ByVal e As EventArgs)
   Dim TB As TextBox
   CreateTextBox(TB)
   Controls.Add(TB)
   MyBase.OnLoad(e)
End Sub
Sub CreateTextBox(ByRef TextBox As TextBox)
  TextBox = New TextBox()
End Sub

I'm sorry Tygur, I really confused the issue on that one... I was actually trying to support the arguement you just gave (that this is fine in VB), but I blew it when I got carried away with a caveat.

 

I was replying to this:

Declaring variables (esp. parameters) like A a; is a very common and standard thing to do.

I was trying to say that this is fine in VB as well. I had thought that variable-procedure pairings of the same name were a no-no (but I guess I was wrong about that?), but as for variable-type pairings that's another matter and even VB can handle that fine. My example was:

Sub MySub(textBox As TextBox)
  ' ...
End Sub

And my point is that this works. :) Your example takes it further, showing that it's fine. I've even used this myself, but I've started moving away from this as I sometimes get confused by the IntelliSense.

 

What happens is that I type something like:

TextBox.

and expect to see IntelliSense listing only Static members, but instead I see Instance members as well and I'm all confused. What happened? Well, VB is not case sensitive, so even though I wrote "TextBox" and therefore was intending to access the Type TextBox (and therefore only see Static Members), I was actually getting a reference to the 'textBox' object (since 'textBox' is the more local, and therfore the shadowing definition) and was therefore given a listing of Static and Instance members.

 

This is not a *huge* deal, but I find myself occussionally confused by this so I've started moving away from this... I now use "txtBox" instead:

Sub MySub(txtBox As TextBox)

-- Mike.

Edited March 2, 2005 by Mike_R

[Mike_R]

Plausibly, thanks for that advice. I'm a VB-guy and that ain't never gunna change. Even if I switch over to C#, which I may do when VS2k5 comes out, I don't see myself ever getting into direct-pointer operations.

 

But it is neat to think about...

 

Yes that is true Mike' date=' let me give a different example that may help more. You have created a structure that is called house. It has doors, windows, floor plans, actions...[/quote'] Ok, thank you Sean, that's a great example. This gets even more interesting when boxing is considered I think... I sort of wonder how this all works.

 

For example, your Structure you describe is massive at 1MB. The truth is that Structures that large (I believe the size cut-off is 85kb? I'm not sure about that) are automatically put on the heap anyway and would never be "moved" directly into a Function. It would be boxed however (in order to get it on the Heap) so I'm not so sure about the difference between a standard Object Reference pointer here and a "direct C# pointer" (what's the correct term for that anyway?).

 

But I do get it! Certainly for structures "under the wire" at 85kb or below (if that is the correct figure), then you'd avoid ByVal copying in... But then again, the Procedure could use ByRef for it's Parameter declaration and effectively turn this into a pointer situation again. Right?

 

I'm guessing though that these sorts of "layman pointer approaches" may wind up in double-dereference (i.e., "handle") situations, whereas C# direct-pointers might be single-dereference?

 

Also, there must be some sort of "locking" mechanism, right, when a C# pointer is working on data, esp. data on the Heap? I wouldn't think that these Pointers are *strong pointers* by default, are they?

 

Sorry about all these noobie-pointer Q's... Feel free to stop responding to this gibberish at any point! :)

[coldfusion244]

Unfortunately Mike, I can't answer your last questions as I don't quite understand how C# handles the pointers. I was using basic pointer operation from C++... C# and VB do put their information on the heap as you stated so it's not a huge deal and doesn't require the efforts of a pointer and can be passed ByRef. If anyone can answer that, I'm interested as well.

[IngisKahn]

In order to set a pointer to an object on the heap you need to used a fixed() block. This sets a flag on the object telling the GC not to move the object around in memory when it performs a collection.

[Mike_R]

In order to set a pointer to an object on the heap you need to used a fixed() block. This sets a flag on the object telling the GC not to move the object around in memory when it performs a collection.

Ok, thanks Ingis, I figured that there had to be something like that...

 

Ok! Despite all my whining in Post #16, I'm going to convert all my low-level libraries to C#. I'm going to leave my higher-level libraries dealing with VBA stuff as VB.Net, but I'll convert the lower stuff.

 

This will be a lot of work, but probably a great way to learn the language as well... God help me, this might take forever, LOL. :)

[Nerseus]

If mookie is still around, I'd STRONGLY suggest sticking with VB.NET. I'd concentrate more on learning good programming habbits (OO programming, using patterns, refactoring code, effective comments, etc.), the .NET framework, etc. See the summary below if you want to skip this post

 

When you're starting out programming there's a strong desire to learn other languages. Many VB 6 programmers had "C++ envy", but stuck with VB. Many VB.NET programmers feel a "C# envy" and may tinker with C#. In all honesty, stick with what you know.

 

Keep this thought in mind whenever you feel the urge to drop one language and switch: are you switching because your current language lacks something you use a LOT, or are you switching for some other reason? Bad reasons to switch:

* The other language has one cool feature which you might use, but probably not (ie, pointers in C++)

* The other language makes it easier to do some things (A robust Switch in VB.NET looks nice, but you may not use it but once in a blue moon)

* The other language has better IDE support (VB.NET has better support for adding event handlers - from the code window). If you do this a LOT, maybe a reason to switch.

 

Summary:

I think a C# programmer can come up with reasons to choose C#, VB.NET can come up with a list of reasons to choose VB.NET, and C++ programmers can come up with a list of reasons to choose C++.

 

An experienced programmer knows not to ask what language is "best" or "right". A "newbie" programmer should probably stick with what they know and ignore the "feature envy" of other languages.

 

-ner