I am making this post for those who don't know the differences between VB and C++ and what each has to offer (myself included ;D). Please no flames about VB sux or vise versa.

Overall what does VB bring that C++ doesn't and vise versa and what are each mainly used for, i.e. lots of games are made in c++ now a days...

Visual Basic is for rapid application development, and has some limitations compared to C++, which can do most anything you want it to.

C++ is designed to bring the benefits of OOP together with giving the client programmer precise, low-level control of the machine. If you ask your average programmer, it is *the* programming language. It isn't perfect by any means; it's easy to write insecure software, cryptic code, and can be slow for developing because it does not safeguard the programmer from stupid flaws.

VB is designed for fast development of GUI based prototypes. It's based on a proven beginner language, so its simple user interface and syntax are good for newbies (I disagree, but this is the common consensus). It has numerous disadvantages, such as reliance on ActiveX technologies, its large executable sizes and their slow execution speed, and its lack for contempory language features (most notable are OOP and exeception handling. VB's error handling sucks, and no one can deny that).

[quote author=St0rm.iD link=board=5;threadid=3609;start=0#msg29220 date=1068864339]
VB's error handling sucks, and no one can deny that[/quote]
VB.NET gets try...catch :P

I love VB but honestly theres somethings that you cant do in VB.net that you can in C++. Proof of such is the error i sometimes recieve that mocks me "You can not do this in Visual Basic".

such as.... pointers? :D

As much as I hate this thread, I'm going to post some stuff anyway. First of all, I like VB much, much, much better than C/C++. Personally, I haven't really come across anything that I "couldn't do" that I wanted to have done. Secondly, despite the fact that people are always complaining about the lacks of features that VB has, I rarely, if ever, see questions about how to accomplish. So either people just give up on the idea that VB can do what they want or they never run across these problems that VB can't solve. Either way, it can be done. I admit, there are certain things it's certainly not worth the effort to do in VB (inline assembly, for instance), but for the most part, people don't need anything lower level.

Ok, so let's address some of these issues that people frequently complain about.
1) Pointers

Yes, Visual Basic does have pointers. You can use the functions VarPtr(), StrPtr(), and ObjPtr() to return the address of a variable. VarPtr works on variables and arrays. For example, to return the address of the base of an array: ArrayBaseAddress = VarPtr( MyArray(0) ) StrPtr is different from VarPtr because strings in VB are pointers to pointers to strings, so if you use VarPtr on a string, the value you get back is the pointer to the actual contents. However, if you use StrPtr(SomeString), the value returned will be the address of the first character in the string. Lastly, we have ObjPtr, which should be pretty easy to figure out. It just returns the address of an object for whatever reason you might need. For functions, you use the AddressOf keyword. For instance, when subclassing and setting your own callback routine, you need to specify the address of the callback function. This is done by using AddressOf to return the function's location in memory.

2) Function Overloading

Visual Basic does not have any support for overloading functions, however, it can be done in a roundabout way. Observe:

[code]
Public Enum DataTypes
vbEmpty = 0
vbNull = 1
vbInteger = 2
vbLong = 3
vbSingle = 4
vbDouble = 5
vbCurrency = 6
vbDate = 7
vbString = 8
vbObject = 9
vbError = 10
vbBoolean = 11
vbVariant = 12
vbDataObject = 13
vbDecimal = 14
vbByte = 17
vbUserDefinedType = 36
vbArray = 8192
End Enum

Private Function AddToBuffer( Blah as ParamArray )
Select Case VarType(Blah(0)) 'Check the first parameter's data type
Case DataTypes.vbEmpty
Exit Function
Case DataTypes.vbString
PacketBuffer.InsertString Blah(1)
Case DataTypes.vbLong
PacketBuffer.InsertDWORD Blah(1)
End Select
End Function
[/code]

It's crude, but it might as well be an overloaded function.

3) Operator Overloading

Yeah, as far as I know, there's no way to do anything close to this in VB. Oh well.

4) Exception Handling

VB has excellent error handling in my opinion. You can not only create your own errors, but you can raise them whenever you like, be notified of what error it is, what line caused it, and even return control to the program after your code has adjusted. We all know about On Error Resume Next, which is essentially a catch-all that keeps your programs from crashing. Well, you can actually do:

[code]
Private Function MyFunction() as Whatever
FunctionStart:
On Error Goto ErrorHandler

MyVar = Mid(MyString, 500, 1) ' Assume 500 is past the end of the string.

MyVar = MyArray(387) ' Assume MyArray has less elements than that.
FixedArray:

' Custom Error
If MyVar <> WhatIWantItToEqual Then
Err.Raise 1000, ,"MyVar had the wrong value!"
End If
ResumeControl:

Exit Function

ErrorHandler:
Select Case Err.Number
Case 5: 'Invalid procedure call or argument, I think.
If Len(MyString) < 500 Then
MyString = Space(5000)
Goto FunctionStart
End If

Case 9: 'Array out of bounds, if I recall correctly.
MyVar = MyArray(UBound(MyArray))
Goto FixedArray

Case 1000: ' Our custom error.
MyVar = WhatIWantItToEqual
Goto ResumeControl

Case Else
Debug.Print "Oh no, an error of number " & Err.Number & " occured. This means that you caused a(n) " & Err.Description & " error to happen."
End Select
End Function
[/code]

Anyway, I'm not trying to say that VB is the greatest language for all things and that it should always be used, just that it can be a lot more powerful than people give it credit for.

Edit: I typed this all out by hand and not in the VB IDE, so if you find errors in the code, bite me.

So what you're saying is that you can do a lot of extra work, and have messy code, to implement something that other languages have by default?

And you missed my #1 problem: OOP. I hate not having inheritance/polymorphism/ other OOP features.

It's not that much more work than other languages and keeping code clean is left to the programmer. None of what I wrote was "dirty", as far as I can tell. If you don't like the Gotos, then call the function again with your fixed parameter. Oh, hard. If you don't like a massive select case, put it in a function and call other functions rather than having the code pile up. Those aren't even viable concerns.

VB has OOP through COM. Go acronyms. But anyway, you create a base class called an interface. From other class modules, you use the keyword Implements [WhateverYourPreviousClassWas], and like magic, you have access to its properties and methods in your derived class.

Those aren't pointers. Pointers are a syntax structure. And that function overloading is also a syntax construct; I don't want to have to write all of that.

I also think VB's error handling blows...period.

And, that isn't true OOP. Cup, I don't even think you know a semi-true OOP language.

Yeah, that's not OOP, that's just inheritance. It's missing the key features which I love using to keep my code organized and reusable. Did you know that, in Java, I can use my same Bot class to connect to IRC, Battle.net, or Botnet, and I can do the login and event-handling stuff in subclasses? It so clean and I can very easily add to it!

So, gogo OOP, boo VB for not having it.

[quote author=St0rm.iD link=board=5;threadid=3609;start=0#msg31751 date=1069884703]
Those aren't pointers. Pointers are a syntax structure. And that function overloading is also a syntax construct; I don't want to have to write all of that.

I also think VB's error handling blows...period.

And, that isn't true OOP. Cup, I don't even think you know a semi-true OOP language.
[/quote]

Actually, I'm pretty sure a pointer is a 32-bit data structure (on most computers) that provides the address of the data you're looking for. With respect to the function overloading, I don't see how Case vbString: <Code> Case vbLong: <Code> is any worse than:

[code]
ReturnType Whatever( char* Stuff)
{
return;
}

ReturnType Whatever( long Stuff )
{
return;
}
[/code]

I guess you're entitled to your opinion about the error handling, but I don't see how it's that awful.

And lastly, I can agree that it's not 'true' OOP, but it can have essentially the same functionality. If you want to bitch about polymorphism and inheritance, read the article. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvbdev00/html/vb00d20.asp

A pointer is a data structure if you want to look at it that way, as you correctly stated how most 32-bit machines use 32-bit pointers.

However, what Storm was pointing out is that pointers are used syntactically in a different manner:

[code]
// C code
int myarr[] = { 5, 10, 20, 50, 100 };
int *ptr = &myarr; // is this right? I'm not a C programmer....
int i;
for (i = 0; i < 5; i++)
printf("%d", *(myarr + (i * sizeof(int))); // now I'm really wondering if this is correct....
[/code]

However, with VB, IIRC, you don't actually use pointers - that is, there's no way to access the contents to which they point. You can marshal your data to point to strings or objects because other languages (enabled with COM) require this; however, aside maybe from function callbacks, you don't actually use pointers.

I like in C++ how when I make an error it will go specificly to the problem. However I may be wrong, but in my Visual Basic 6 when there is an error it will just say "compile error" or some shit and wont tell me what I did wrong in my code.

Myndfyre, what are you talking about?

[code]
Dim x as String
Dim y as Long

y = StrPtr(x)
[/code]

y is now the pointer to x, x has the contents of y. It's like y = &x in C++.

Mitosis: I think you've confused your compilers.

[quote author=CupHead link=board=5;threadid=3609;start=0#msg31832 date=1069891890]
Myndfyre, what are you talking about?

[code]
Dim x as String
Dim y as Long

y = StrPtr(x)
[/code]

y is now the pointer to x, x has the contents of y. It's like y = &x in C++.

Mitosis: I think you've confused your compilers.
[/quote]
Can you then do things like modify the contents of x through y like you can in C++, without having to resort to unwieldy calls to exported memcpy functions?

Not really, you have to use CopyMemory calls if you want to modify it. I think the best information regarding these pointers is here: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q199/8/24.asp&NoWebContent=1

[quote author=CupHead link=board=5;threadid=3609;start=15#msg31854 date=1069893229]
Not really
[/quote]

QED. VB < C/C++.

[quote author=CupHead link=board=5;threadid=3609;start=15#msg31854 date=1069893229]
Not really, you have to use CopyMemory calls if you want to modify it. I think the best information regarding these pointers is here: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q199/8/24.asp&NoWebContent=1
[/quote]
Then VB doesn't have true pointers as part of the language itself. Using a kludge with dll exports written in some other language doesn't make it a VB language feature.

[quote author=Skywing link=board=5;threadid=3609;start=15#msg31860 date=1069893695]
Then VB doesn't have true pointers as part of the language itself. Using a kludge with dll exports written in some other language doesn't make it a VB language feature.
[/quote]

Um... So nothing done in VB is a VB language feature because VB wasn't written in VB?

[quote author=Arta[vL] link=board=5;threadid=3609;start=15#msg31859 date=1069893683]
QED. VB < C/C++.
[/quote]

Jesus Christ, what is it with you people? I wasn't arguing that VB is better, just that most people don't know about these similar features and that VB isn't all that bad.

[quote author=CupHead link=board=5;threadid=3609;start=15#msg31880 date=1069894794]
[quote author=Skywing link=board=5;threadid=3609;start=15#msg31860 date=1069893695]
Then VB doesn't have true pointers as part of the language itself. Using a kludge with dll exports written in some other language doesn't make it a VB language feature.
[/quote]

Um... So nothing done in VB is a VB language feature because VB wasn't written in VB?
[/quote]
No. A "language feature" is something that is intrinsically provided by (or is integrated with) the compiler/interpreter/etc. If you have to explicitly callout to code written in some other language, it's not a language feature.

Even though everything in VB is a call to something written in a different language, if it's in the VB runtime, then it's a language feature because it's provided already? I think that's what you're saying?

Yeah Mitosis, VB will highlight the line and IIRC will tell you the error.

[quote author=CupHead link=board=5;threadid=3609;start=15#msg31890 date=1069896426]
Even though everything in VB is a call to something written in a different language, if it's in the VB runtime, then it's a language feature because it's provided already? I think that's what you're saying?
[/quote]

A pointer is not simply an integer (or long) containing the memory address of a variable. It is a vehicle that you can use to pass-by-reference, automatically look up the contents of memory at a certain address, and change that memory, all while using a single operator.

A pointer is simply an unsigned long containing the memory address of a variable. That's it, nothing more. How and what functions a compiler is able to apply to that pointer have nothing to do with the fact that the object is a pointer. The dereference operator is not a pointer. It cannot be called a pointer. The address-of operator is not a pointer either. Passing by reference is not a pointer. This "vehicle" you speak of is called a programming language, not a pointer.

[quote author=Skywing link=board=5;threadid=3609;start=15#msg31860 date=1069893695]
[quote author=CupHead link=board=5;threadid=3609;start=15#msg31854 date=1069893229]
Not really, you have to use CopyMemory calls if you want to modify it. I think the best information regarding these pointers is here: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q199/8/24.asp&NoWebContent=1
[/quote]
Then VB doesn't have true pointers as part of the language itself. Using a kludge with dll exports written in some other language doesn't make it a VB language feature.
[/quote]

This ^^ is exactly what I was talking about.

Pointer usage is NOT a language feature of VB as it is in C/++.

[quote author=Myndfyre link=board=5;threadid=3609;start=0#msg31809 date=1069889607]
However, with VB, IIRC, you don't actually use pointers - that is, there's no way to access the contents to which they point. You can marshal your data to point to strings or objects because other languages (enabled with COM) require this; however, aside maybe from function callbacks, you don't actually use pointers.
[/quote]

Actually, what you said was that you can't access the contents of a pointer, which is incorrect, because you can access the contents through the original variable. If you were talking about something else, you should have said so.

[quote author=j0k3r link=board=5;threadid=3609;start=15#msg31893 date=1069897924]
Yeah Mitosis, VB will highlight the line and IIRC will tell you the error.
[/quote]

Well then my compiler is screwed up then, when ever there is an error it does nothing.

I think you need to enable the error display in options somewhere (I'm speaking from VB6 I think... don't remember all too well). I remember having to enable something when I took the classes.

[quote author=CupHead link=board=5;threadid=3609;start=15#msg31901 date=1069900231]
A pointer is simply an unsigned long containing the memory address of a variable. That's it, nothing more. How and what functions a compiler is able to apply to that pointer have nothing to do with the fact that the object is a pointer. The dereference operator is not a pointer. It cannot be called a pointer. The address-of operator is not a pointer either. Passing by reference is not a pointer. This "vehicle" you speak of is called a programming language, not a pointer.
[/quote]

No, it isn't. It's a syntax construct.

It's my experience that any integer directing to data is a pointer.

For example, making Trainers in VB. I've heard people that are stupid say it isn't possible but it is - because of pointers. In order to make a name spoofer code in vb you have to be able to edit the data(name) the pointer is directing you to - is that not using a pointer?

I think you all need to go Here to see what I'm talking about.[code]15030963 8B0A83CEFF E8D86A0000
15037440 000000000000 81FA10330319
15037446 0000 7505
15037448 0000000000 BA53740315
1503744D 0000 8B0A
1503744F 000000 83CEFF
15037452 00 C3
#Your Spoofed name goes below in hex as the new data.
#Always end with a Null Character (Hex = 00)
# Currently Set For: "TechBot"
15037453 000000000000000 54656368426f7400[/code]The above is the code for a Starcraft 1.10 Name Spoofer in ASM - To convert this to Visual Basic you would inevitably have to edit the data the pointer is directing you to - which is very possible. There you used a pointer. Whether it is integrated in the language itself is irrelevant. Stfu, you used a pointer.

[quote author=Dyndrilliac link=board=5;threadid=3609;start=30#msg32017 date=1069948682]
For example, making Trainers in VB. I've heard people that are stupid say it isn't possible but it is - because of pointers.[/quote]

This is a largely irrelevant point. Except for HDLs, which I'm pretty sure VB can't do, all "trainer" type programs work by modifying the memory of another process, which requires calls to the OS. Manipulating pointers to somebody else's memory is not a feature of any of the languages under discussion. Even in C, you call WriteProcessMemory ().

Whether it is a feature or not is even more irrelevant, because I believe the argument was "You cannot use pointers in visualBasic" - which it has been proved several times you can.

[quote author=Dyndrilliac link=board=5;threadid=3609;start=30#msg32023 date=1069949182]
Whether it is a feature or not is even more irrelevant, because I believe the argument was "You cannot use pointers in visualBasic" - which it has been proved several times you can.
[/quote]
Um.. a number of the posts here have been about it being a language feature. Please read the thread.

[quote author=ObsidianWolf link=board=5;threadid=3609;start=0#msg31665 date=1069865693]
I love VB but honestly theres somethings that you cant do in VB.net that you can in C++. Proof of such is the error i sometimes recieve that mocks me "You can not do this in Visual Basic".
[/quote]

[quote author=Myndfyre link=board=5;threadid=3609;start=0#msg31669 date=1069866436]
such as.... pointers? :D
[/quote]

[quote author=St0rm.iD link=board=5;threadid=3609;start=0#msg31751 date=1069884703]
Those aren't pointers. Pointers are a syntax structure. And that function overloading is also a syntax construct; I don't want to have to write all of that.
[/quote]

Excuse me, but the original argument was that you cannot use pointers in Visual Basic. Please, read the thread.

[quote author=Dyndrilliac link=board=5;threadid=3609;start=30#msg32028 date=1069951150]
[quote author=ObsidianWolf link=board=5;threadid=3609;start=0#msg31665 date=1069865693]
I love VB but honestly theres somethings that you cant do in VB.net that you can in C++. Proof of such is the error i sometimes recieve that mocks me "You can not do this in Visual Basic".
[/quote]

[quote author=Myndfyre link=board=5;threadid=3609;start=0#msg31669 date=1069866436]
such as.... pointers? :D
[/quote]

[quote author=St0rm.iD link=board=5;threadid=3609;start=0#msg31751 date=1069884703]
Those aren't pointers. Pointers are a syntax structure. And that function overloading is also a syntax construct; I don't want to have to write all of that.
[/quote]

Excuse me, but the original argument was that you cannot use pointers in Visual Basic. Please, read the thread.
[/quote]
Actually, what people have been arguing about recently was pointers as a language feature. I'd consider this more relevant than something which hasn't been discussed so recently.

How do you create linked lists or trees in VB?

[quote author=Adron link=board=5;threadid=3609;start=30#msg32056 date=1069959818]
How do you create linked lists or trees in VB?
[/quote]
I think it can be done with class modules.

[quote author=CupHead link=board=5;threadid=3609;start=0#msg31698 date=1069873232]
4) Exception Handling

VB has excellent error handling in my opinion. You can not only create your own errors, but you can raise them whenever you like, be notified of what error it is, what line caused it, and even return control to the program after your code has adjusted. We all know about On Error Resume Next, which is essentially a catch-all that keeps your programs from crashing. Well, you can actually do:
[/quote]

I don't like VB's error handling at all for one big reason: Generic error handling is as far as I know impossible to implement without copy-pasting code. That is: If I want to handle every error that can possibly happen and do some kind of clean shutdown, I would have to write an On Error statement, a label and handler (or call to a generic handler) into nearly every event handler of every object. (i.e. command1_mousedown, command1_click, command1_mousemove, command1_ ... etc)

I have been able to find no way to create a generic exception handler that is global to the application.

What's worse, VB doesn't even let any errors happening in such functions pass on to a possibly attached debugger, or to the operating system. You get a stupid "Run-time error X: Bla bla bla" box with an OK button instead of invoking Dr.Watson to create a dump file that could be debugged.

[quote author=Yoni link=board=5;threadid=3609;start=30#msg32057 date=1069960162]
[quote author=Adron link=board=5;threadid=3609;start=30#msg32056 date=1069959818]
How do you create linked lists or trees in VB?
[/quote]
I think it can be done with class modules.
[/quote]

Ah yes, VB does have a type of pointers/references there. Whenever you use "Set x = something", you're really assigning a pointer. There's one thing to be aware of: Circular reference chains causing objects not to be deleted. I'm not sure how efficient it is either, should look at the compiled code to find out exactly how it does it some time.

There's no easy way to have a pointer to several elements though?

The closest thing VB has to pointers is references.

And, the point about trainers was bullshit. Pointers are not just saying "oh I can edit arbitrary memory locations". Please read the thread.