[Beach_Coder]

As I teach myself programming, it seems every day I learn something new. Every day it also seems that I learn of something I don't know. I'll spend hours reading and experimenting. It is not uncommon for me to walk away more confused than I was hours earlier leaving my question unanswered until some indefinite point in the future. My confusion du jour however has left me paralyzed; I've got to get this down if I can:

There are several pieces I've come across that explain VB is not VB.Net and that .Net is preferred. AdamSpeight2008 (in a piece I can find the link to at the moment Mentor Edit:This One ) suggested cutting the VisualBasic resource loose from a solution as a way to check for VB only code and (I think) then eradicate it. It makes sense to me. If I'm programming using Visual Basic Express 2010, I should still use .Net over VB because it's more efficient to program for the framework rather than the language. I think this is so because it will make it run faster and it will get along nicer with any other .Net application it has to talk to. I am clearly cloudy on this.

Strings:
I'm in the middle of a little thing I'm working on decided to take the test. I unchecked visualbasic and cut it loose. No sweat, except that I had fifty lines of code with the ugly crooked lines telling me there's no such thing as strings.anything. No other issues. Just the strings. Pretty good I thought, I'll just use the .Net equivalent to do the same stuff. Someday I'll figure out what that is.

Numbers:
I want my stuff to be perfect: fast, concise, sound, efficient, elegant all this stuff. To this end, in the project I am working on I decided I absolutely needed to know the best way to store a number. The user enters it and it is first captured in a string. I then thought, "okay what now?" Well, Microsoft tells me that in Visual Basic the numerical data type that is processed with the greatest efficiency is the Integer. Perfect. Unless the number at hand is too large, I can use Integer and know I am satisfying my desire to code perfectly. But in the next instant I found myself paralyzed yet again. Integer is of course a VisualBasic type. The .Net equivalent is Int32, which is not as fast as using Integer. Or is it? Did the Microsoft guy who wrote the statement "Arithmetic operations are faster with integral types than with other data types. They are fastest with the Integer and UInteger types in Visual Basic" (see Numeric Data Types ) really mean that or did he mean "They are fastest with the Integer and UInteger types (or their .Net equivalent) ..?"

Further,
I read in another spot that if any values are going to be passed to a COM component, that where possible Short should be used instead of Integer because life is different outside the .Net framework (I don't recall the explanation with any more accuracy than that I'm afraid).

So, if I am in pursuit of storing any given number (let's say 32000) in the perfect data type, is it Integer, Int32, Short or Int16?
Or am I spinning my wheels for nothing over an instance whereby for all practical purposes the subtle (and not so subtle) differences are irrelevant unless I am developing a complex application? I really don't think this would be the case, coding isn't horseshoes whether it's Hello World or the new engine for the WOPR. If these 4 possibilities were all the same, there wouldn't be four of them.
Perhaps it is a case where each has its pros and cons and it's up to me to evaluate them and make a decision?

Any informed guidance on this matter will be much appreciated. And any other commentary will be much enjoyed.

This post has been edited by AdamSpeight2008: 17 November 2011 - 02:00 PM

[modi123_1]

I'm confused on what part of that should be responded to. One would use the .NET framework over VB6 (and earlier) because VB6 is no longer actively maintained my Microsoft. Sure there's a ton of VB6 apps to maintain, but most are slowly being ported over to .NET. If anything that would be the critical reason to learn one over the other - lest we throw up our hands and go back to first-gen languages and fore sake all this third gen fun.

[Beach_Coder]

I'll give being specific a go:

1) Is it correct that if I unload the VisualBasic namespace, I lose access to all VB6 code and nothing but VB6 code?

2) When I do unload the VisualBasic namespace, and I go to declare a variable as an Integer, I still have Integer available to me as well as Int32. Why is this?

3) If I am using Visual Basic Express 2010, and the documentation says that in Visual Basic Integer is the most efficient numerical datatype, should I still use Int32 (the common language runtime equivalent) rather than Integer? (Subject perhaps to the answer to question number 1).

4) If the number I intend to store in my variable declared as one type of integer or another is below 32,700 something (whatever the limit for short integers is), should I choose the more efficient data type of Integer or Int32 and deal with whatever problems I might have later if I need to interface with a COM object, or should I store the number is a variable of the Short data type even though it is less efficient than Integer so I don't have a problem if and when the application needs to pass the value to a COM object?

[modi123_1]

Quote

1) Is it correct that if I unload the VisualBasic namespace, I lose access to all VB6 code and nothing but VB6 code?

I don't know what you mean by "unload the VB namespace". Are you talking about dropping off a reference? The VB.NET-ness is sort of baked into project itself.

Quote

2) When I do unload the VisualBasic namespace, and I go to declare a variable as an Integer, I still have Integer available to me as well as Int32. Why is this?

That depends on your answer above, but the basics of the VB.NET are still present in a project you created taht is VB flavored.

Quote

3) If I am using Visual Basic Express 2010, and the documentation says that in Visual Basic Integer is the most efficient numerical datatype, should I still use Int32 (the common language runtime equivalent) rather than Integer? (Subject perhaps to the answer to question number 1).

Integer is int32.

Quote

4) If the number I intend to store in my variable declared as one type of integer or another is below 32,700 something (whatever the limit for short integers is), should I choose the more efficient data type of Integer or Int32 and deal with whatever problems I might have later if I need to interface with a COM object, or should I store the number is a variable of the Short data type even though it is less efficient than Integer so I don't have a problem if and when the application needs to pass the value to a COM object?

I think you may be getting too hung up on micro efficiency in a managed framework setting. If you know you will be interfacing with a COM object and will need an integer/int32 then I would keep it that for the duration. If if it is just a possibility that you may interface I would use the integer/int32. It's been a while since I had a solid reason for using smallint/int16... let alone the issue if you are using a 32bit machine vs a 64 bit.. so a long would be better in the latter case.

[Beach_Coder]

Indeed perhaps mountain out of a molehill, though micro efficiency is a little more gracious.

Yes, I meant dropping off the reference.

One final question (I hope): If Integer is Int32, then why do I have both available to me (even after severing the visualbasic reference)?

[modi123_1]

Quote

Yes, I meant dropping off the reference.

What reference are you talking about? If you create a VB.NEt project you can't make it not VB-orientated... you can't strip it down and then try and re-purpose it as some c# orientated thing.

Quote

One final question (I hope): If Integer is Int32, then why do I have both available to me (even after severing the visualbasic reference)?

You have both because both are available in the framework...

[lordofduct]

Beach_Coder, on 17 November 2011 - 07:32 PM, said:

I'll give being specific a go:

1) Is it correct that if I unload the VisualBasic namespace, I lose access to all VB6 code and nothing but VB6 code?

Ok, you're getting jumbled by all the different things called 'VB'... understandable because there are many.

VB6 and under - this is the old Microsoft VB that VB.Net is designed to look like as a language. It is old, outdated, and not supported well in latest versions of Windows. This is the 'VB' that everyone says to avoid like the plague if you want to be modern.

VB.Net - this is the language compatible with the .Net framework that looks similar to the old VB in that its dialect is very 'Basic' like (see 'BASIC Programming Language' for the look and feel of BASIC derived languages)

VisualBasic namespace - this is just a collection of functions and classes created for use with VB.Net that uncover several functions that look and act like several common functions (note the Strings class) that people coming from VB6 are used to using. I personally don't use them because I came to VB.Net from C#, but there is nothing inherently wrong with them, and you may find them very useful. They aren't going to give you any performance hit that will be noticeable... though some community members may bash its use due to a negative stigma the 'VB' name has (mostly drawn from this very confusion you are having).

Quote

2) When I do unload the VisualBasic namespace, and I go to declare a variable as an Integer, I still have Integer available to me as well as Int32. Why is this?

Integer is unrelated to the VisualBasic namespace, and is related to the VB.Net language. It's just an alias for 'Int32', they are ONE AND THE SAME. C# has aliases as well, Int32 is aliased as 'int' in C#. The VB.Net compiler, when compiling, interpets 'Integer' as 'Int32'. It is not faster or slower to use 'Integer' vs 'Int32'.

Integer is the fast arithmetic number type, but it doesn't meet all the needs you may need. Double, Single/Float, Decimal, etc all have very important roles when it comes to requirements for very large numbers, fractional numbers, or base 10 accuracy (for money calculations for instance). Just because Integer may calculate faster, integer isn't useful for say wanting to calculate (7 / 2) because it will result in '3' and not '3.5'.

Quote

3) If I am using Visual Basic Express 2010, and the documentation says that in Visual Basic Integer is the most efficient numerical datatype, should I still use Int32 (the common language runtime equivalent) rather than Integer? (Subject perhaps to the answer to question number 1).

Answered in 2

Quote

4) If the number I intend to store in my variable declared as one type of integer or another is below 32,700 something (whatever the limit for short integers is), should I choose the more efficient data type of Integer or Int32 and deal with whatever problems I might have later if I need to interface with a COM object, or should I store the number is a variable of the Short data type even though it is less efficient than Integer so I don't have a problem if and when the application needs to pass the value to a COM object?

You are way over thinking numeric types. I'll quote Knuth for this one:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"



It isn't 1978 anymore, you aren't running on a 1 mhz 8-bit processor where every cycle matters. We have multi-core, hyper-threaded, 3ghz processors that can perform millions of arithmetic operations every second. You're not creating a number crunching super software, use the numeric type that FITS YOUR NEEDS, not the one that might save that 1 extra cycle that you'll never see.

This post has been edited by lordofduct: 17 November 2011 - 01:29 PM

[AdamSpeight2008]

Integer changes size depending of the underlying OS.
32bit OS, it's 32bits wide. On a 64 bit OS, it's 64 bits. Where as in VB6 it was only 16 bits.

Int32 is 32 bits wide, no matter the OS.


My view is more about the different methodologies (or way of think about solutions) that vb6 coder use, more about button clicks, forms, controls, procedural coding and tends to be needlessly cryptic. (GUI first, Code second).

.net coders tend to think more in terms of object (class and structures) and using libraries. (Code First, GUI Second)

[Beach_Coder]

Thank you! Now I get it.

Indeed I code first, gui last. Working on the gui became such a distraction for me I starting doing console applications only. When it works perfectly well (rather, if I ever get one to work perfectly well), then it's time to contemplate the gui.


Footnote: I'm not that old. I didn't write my first program until 1982.
Another footnote: It was as recent as 1996 that I had spreadsheets in Excel so darn big that when I hit F9 to calculate it would be 45 minutes before saw anything but an hourglass on a blank screen.
Final footnote: My 4 year old 2 GHZ Intel dual core processor has similar moments more and more lately. Once I installed SP3 on XP Pro it was like having to run around dragging a sack of potatoes.

[raziel_]

Beach_Coder, on 17 November 2011 - 09:32 PM, said:

1) Is it correct that if I unload the VisualBasic namespace, I lose access to all VB6 code and nothing but VB6 code?

perhaps a late response but yes if you remove the visual basic namespace then you cant use some of the functions that vb6 have for example a pure vb6 code in vb.net:

    Function Random(ByVal Lowerbound As Integer, ByVal Upperbound As Integer) As Integer
        Randomize()
        Random = Int(Rnd() * Upperbound) + Lowerbound
    End Function
    Friend Function GenerateTempPassword(ByVal PWLength As Integer) As String
        Dim i As Integer
        Dim worker As String = ""
        For i = 1 To PWLength
            worker = worker & Chr(33 + Int(Random(0, 93)))
        Next
        GenerateTempPassword = worker
    End Function

if you go and remove the namespace you will get this errors:

[Beach_Coder]

raziel_, on 28 November 2011 - 11:50 AM, said:

Beach_Coder, on 17 November 2011 - 09:32 PM, said:

1) Is it correct that if I unload the VisualBasic namespace, I lose access to all VB6 code and nothing but VB6 code?

perhaps a late response but yes if you remove the visual basic namespace then you cant use some of the functions that vb6 have ...

Not so late that I didn't eventually realize it was here, thank you.

To clarify:
1) If I remove the vb namespace there are vb6 functions I can still use?

2) The vb namespace is not entirely comprised of vb6 functions?

[raziel_]

1) yes you can still use some of the old functions like CDbl() method
2) its mostly the old methods that vb6 have like Instr() etc like mentioned above but some of them can be used outside the namespace like CDbl() (mostly the old conversion methods)

[lordofduct]

Here is what is in the visualbasic namespace:

http://msdn.microsof...isualbasic.aspx

[Beach_Coder]

lordofduct, on 05 December 2011 - 02:04 PM, said:

Here is what is in the visualbasic namespace:

http://msdn.microsof...isualbasic.aspx

Ah, this leads me to another (perhaps better) question. This link to the Visual Basic Namespace detail is under the .Net 4 Framework Class Library. Can any conclusion be drawn from this relative to cessation of support for VB6 code? That is, if and when VB6 code stops being supported in .Net (which I think means at some point there will be a .Net Framework that doesn't include any VB6 commands) and code I have that includes some VB6 code stops working, are the methods and properties in the .Net 4 Visual Basic Namespace any safer to use than those in previous .Net frameworks?

I am also wondering why there isn't a "modern" Visual Basic namespace separate from a VB6 namespace.

[modi123_1]

Quote

Ah, this leads me to another (perhaps better) question. This link to the Visual Basic Namespace detail is under the .Net 4 Framework Class Library. Can any conclusion be drawn from this relative to cessation of support for VB6 code?

It looks like Windows 8.

[quote]“So, the VB 6 runtime will continue to be shipped with Windows 7 and Windows Server 2008 R2, exactly the same way it was with Windows Vista and Windows 2008 Server. Beyond that, there [are] no plans to ship or support the VB6 runtime on future Operating Systems,” concluded Michael Epprecht from Microsoft Switzerland.[quote]
http://news.softpedi...-8-105474.shtml

https://blogs.techne...-6-0&GroupKeys=

http://msdn.microsof...studio/ms788708

Quote

That is, if and when VB6 code stops being supported in .Net (which I think means at some point there will be a .Net Framework that doesn't include any VB6 commands) and code I have that includes some VB6 code stops working, are the methods and properties in the .Net 4 Visual Basic Namespace any safer to use than those in previous .Net frameworks?

Safer in what sense?

Quote

I am also wondering why there isn't a "modern" Visual Basic namespace separate from a VB6 namespace.

From what I understand "old VB6" calls are just wrapped calls to .NET operators. I haven't had time to go through the 4.0 .NET source code to check each one out, but that makes sense.

A good write up on it.
http://arcware.net/vb6-in-vb-net/