I started learning VB a while ago and I heard in many forums how learning VB is worthless and C++ is ten times better. That's why I figure imma probably take a beginner C++ class in some college and then take the advanced C++ classes. Hopefully the ppl here know what they're talking bout.

That's true depending on what you plan to do with programming, both as to what you want to make, and if you plan to take programming to a career level.

As for programming "stuff" you can keep some of these things in mind.
These is for Visual Basic +'s
- fast GUI application development
- overall faster to develop an application, and easier
- good for development where you need a good functioning application in a day or two which is user friendly

These are +'s for C/C++:
- flexibility
- more APIs to work with (e.g. winsock, win32 api, etc.)
- generally faster and more efficient executables
- full support of object oriented programming and use of pointers
- top software/game development language (this may not be completely accurate)
- people are constantly writing new libraries for C++ to make it easier for you (this may be true for VB)
- supported on different platforms providing you recompile the source code for that platform (you can't compile on windows and use on linux, you would have to compile on linux and then use it on linux)
- blunt, but more than likely true: best language to learn for multi-purpose use

I hope that helps you decide on that subject, and as for taking it to the career level:
There are simply too many VB6 programmers out there looking for jobs. Wages are starting to go down for them, and there is now little demand for them because they are so plentiful right now. So with this information alone, you can pretty much bet that VB6 isn't going to be the language to learn for a career path. However, you may consider VB.Net, and if you can program how .Net was intended for people to program, you can certainly bag yourself a job.
Good, expert and experienced C++ programmers are always what companies want to have, so if you can acquire these skills, and have knowledge of things like Visual C++, C#, Visual C++.Net, etc. you will definetly have a high paying job.

Anyways, I hope this helps. Some of this information may not be completely accurate, but for the most part it's just factual.

Some corrections:

[quote author=Mephisto link=board=30;threadid=5586;start=0#msg47420 date=1078414134]
As for programming "stuff" you can keep some of these things in mind.
These is for Visual Basic +'s
- fast GUI application development
- overall faster to develop an application, and easier
- good for development where you need a good functioning application in a day or two which is user friendly

These are +'s for C/C++:
- flexibility
- more APIs to work with (e.g. winsock, win32 api, etc.)
- generally faster and more efficient executables
- full support of object oriented programming and use of pointers
- top software/game development language (this may not be completely accurate)
- people are constantly writing new libraries for C++ to make it easier for you (this may be true for VB)
- supported on different platforms providing you recompile the source code for that platform (you can't compile on windows and use on linux, you would have to compile on linux and then use it on linux)
- blunt, but more than likely true: best language to learn for multi-purpose use[/quote]

VB can call most Windows functions, if you prototype them yourself (though you really should be able to just #include an appropriate header, as you can in C!). VB applications tend to run slower, build to be bigger, and require certain runtime files that are not installed on all computers by default.

The usability of a given library for VB depends on whether it was compiled to use _stdcall or not (you'll learn this term once you deal with C/C++ for a while). For reasons I've never encountered, VB does not support calling things which do not use this horribly inferior calling convention. C code can call _fastcall, _stdcall, or _cdecl functions with no particular effort beyond marking the calling convenion of the function in its prototype.

Regarding portability: although it is correct that you can compile C code on non-Win32 platforms in theory, most applications oriented towards performance will make substantial use of platform-specific calls. You just can't get top performance on Windows using the Microsoft implementation of the CRT; you'll have to use Windows API calls directly. However, doing so makes the application Windows-specific. Conversely, there are certain features of libc that Microsoft completely failed to implement (afaik), such as the ability to select(2) on non-socket file descriptors. Unix code which depends upon this (or upon the mostly-standard-except-for-Microsoft behavior that select(2) can be used for subsecond sleeps) will fail when moved to Windows.

[quote author=Kp link=board=30;threadid=5586;start=0#msg47461 date=1078432904]
VB applications tend to run slower, build to be bigger, and require certain runtime files that are not installed on all computers by default.
[/quote]

Note: C++ applications typicall require certain runtime files that are also not installed on all computers by default. You can reconfigure your project settings to link C++ applications statically, but it's not the default, and it mostly makes them very much larger.

Really? Which DLL(s)? Aside from some problems running things Skywing built to VS7, I've never had a C-based program fail on me for lack of DLLs (nor have I ever heard of such occuring, aside from this thread).

What kp said is completely right. Another thing you should think about is Java, though:

*cons*
-It builds to larger files which run slower
-Some features are missing

*pros*
- Code ends up A LOT cleaner (compared to using the STL)
- TONS of built-in functionality
- Complete cross-platform (dont' have to recompile for different platforms)
- Full (superior) use of object oriented programming, and automatic pointers (all objects are pointers).

[quote author=Kp link=board=30;threadid=5586;start=0#msg47520 date=1078445922]
Really? Which DLL(s)? Aside from some problems running things Skywing built to VS7, I've never had a C-based program fail on me for lack of DLLs (nor have I ever heard of such occuring, aside from this thread).
[/quote]

I don't remember exactly now, but I'm pretty sure msvcrt40.dll (run-time for msvc4) wasn't in all the old Windows versions, perhaps not in win95 original. The std c++ libraries for msvc5 definitely wasn't in whatever OS I used back then, which might've been NT4. And they obviously won't have the vs7 run-time libraries either.

[quote author=iago link=board=30;threadid=5586;start=0#msg47531 date=1078447579]
What kp said is completely right. Another thing you should think about is Java, though:

*cons*
-It builds to larger files which run slower
-Some features are missing

*pros*
- Code ends up A LOT cleaner (compared to using the STL)
- TONS of built-in functionality
- Complete cross-platform (dont' have to recompile for different platforms)
- Full (superior) use of object oriented programming, and automatic pointers (all objects are pointers).
[/quote]

Java doesn't support pointers much more than VB does, at least from the research I have done. Java uses reference arithmetic when dealing with such things like arrays, as where C++ uses pointer arithmetic. Additionally, I believe Java is interpreted, causing for slower performance of the program, correct? I'm not too sure if you can comepile a program in Java on Windows and then run that same program in Linux. Also, I wouldn't really call Java superior in object oriented programming. It doesn't even support multiple inheritence, or operator overloading (not necessarily an OOP concept).

[quote]
Java doesn't support pointers much more than VB does, at least from the research I have done.[/quote]
True
[quote]
Java uses reference arithmetic when dealing with such things like arrays, as where C++ uses pointer arithmetic.
[/quote]
Dunno.
[quote]
Additionally, I believe Java is interpreted, causing for slower performance of the program, correct?
[/quote]
Bytecode with a JIT, and it's pretty fast these days.
[quote]
I'm not too sure if you can comepile a program in Java on Windows and then run that same program in Linux.[/quote]
Um...duh?
[quote]
Also, I wouldn't really call Java superior in object oriented programming. It doesn't even support multiple inheritence, or operator overloading (not necessarily an OOP concept).
[/quote]
I think java is far superior than C++. C++ had to deal with backwards compatibility to C, while Java didn't. Thus, I like Java's take on OOP much better. The lack of operator overloading sucks (some would call it "clean"). I don't really miss multiple inheritance, since you can implement multiple interfaces.

I've never had any problems with C++'s object oriented approach. Additionally, those of my friends who have programmed in Java havn't really been able to do anything with object oriented concepts in Java that couldn't be done in C++ just as well.

[quote author=Mephisto link=board=30;threadid=5586;start=0#msg47569 date=1078456662]
I've never had any problems with C++'s object oriented approach. Additionally, those of my friends who have programmed in Java havn't really been able to do anything with object oriented concepts in Java that couldn't be done in C++ just as well.
[/quote]

One major thing that makes Java's better: Object. Having an all-encompassing superclass is the best idea I've ever seen.

Still...What advantages does that provide over C++ in the respect that you may beable to do more in Java with its OOP approach than in C++?

Edit: Maybe this should become a C++ vs Java forum?

[quote author=iago link=board=30;threadid=5586;start=0#msg47633 date=1078490561]
One major thing that makes Java's better: Object. Having an all-encompassing superclass is the best idea I've ever seen.
[/quote]

Why is this so good? It doesn't seem like such a good idea to me.

It means that you have a generic superclass that you can use for, for instance, a Vector.

So a Vector object can take a list of Objects, which can be *any class*, and store them all the same way. And if you know which class they come from, you can cast it back.

A default Vector can also be displayed because Object implements toString(). So if you have a Vector of, say, users, you can easiy display all the users in the list with a call to "Vector.toString()".

Take a program that uses Templates, and a program that uses Objects (they, in effect, do the same thing). See which one is cleaner, more understandable, and just plain prettier :)

[quote author=iago link=board=30;threadid=5586;start=0#msg47691 date=1078507726]
So a Vector object can take a list of Objects, which can be *any class*, and store them all the same way. And if you know which class they come from, you can cast it back.
[/quote]

That doesn't make sense though. When would you ever want to have a list of items of random types? I can't think of a reason you would.

I can think of plenty good reasons to produce a list of objects that have something in common, but then you'd design your class hierarchy so that they have a common base class abstracting the common functionality.

It sounds like it might be useful for quick hacks, but not for programming if you have a design you're following. A bit like having a list of void* in C++, allowing you to store anything you like, but you still have to cast it back to the right type for it to be useful.

Storing every single variable as an object (kind of like how VB does with variants?), would presumably need at least a vtable pointer for each object, and seems like it would cost a *lot* of memory.

Storing Object relies on polymorphism. Everything in the table is still its own object, but are stored as a superclass.

Generally, while programming anything real, anything in the list will be the same type of object, or a subclass of the same object (ie, cars/trucks/planes -> Vehicle). One way to do this is to subclass Vector and redefine the constructor/add/remove methods, but that's ewwy. It's easiest to just have a command saying what goes in, and if anything else is put in a ClassCastException is throws when it tries to read it.

And void* isn't the greatest for storing types, like, for instance, a std::string. Treating objects as pointers in C++ gets messy, especially when they rely on operator overriding and other things.

At first, I didn't like Object either, but since I've been using it I've found it a lot nicer than templates. If I had a sample handy, I'd post it. Maybe I'll look for one tonight :)

Yes, an example would be nice. Show how you make a vector that can reference all your vehicles. I'll start by showing how to do it in C++:

[code]
typedef vector<Vehicle*> VehicleVector;

VehicleVector myvehicles;
[/code]

Well, not including the imports, I would do this:

Vector v = new Vector();

If you really wanted to be anal about it, you would have to do a wrapper, like

[code]public class VehicleVector
{
public VehicleVector( super(); }
public void add(Object o)
{
if(o instanceof Vehicle == false)
blowup;
super.add(o);
}
}[/code]

But, like I said, that's just a headache, the reason Object is there is to generically store everything.

How about a hashtable/hashmap, though? Here is the Java implementation:

[code]Hashtable h = new Hashtable();
h.put("key1", "number1");
h.put("key2", someObject);
String a = (String)h.get("key1");
MyObject b = (MyObject) h.get("key2");[/code]

Note that if the programmer blows the object types, he will get a run-time exception.


The other major difference I've found is in documentation. I tried to use a std::StringBuffer (or whatever the name is) in c++ and got so many cryptic erros I went back to sprintf(). For java. I would just go to java.sun.com and look up the error, but generally the error itself will be clear enough to understand.

I think having a common base class + templates would be ideal.

Wait, that's Java 1.5

[quote author=St0rm.iD link=board=30;threadid=5586;start=15#msg47745 date=1078520599]I think having a common base class + templates would be ideal.[/quote]

As Adron remarked, I still don't see any place in real code where you actually benefit from having a universal base class, as opposed to deriving all the objects in the list from some custom base class. Perhaps you could provide an example, since iago hasn't?

iago: the only advantage I can see to your sample code over equivalent C++ code using a void* type is that the program will automatically crash itself with a ClassCastException if you screw up. This does not seem helpful to me. :P

[quote author=iago link=board=30;threadid=5586;start=15#msg47731 date=1078518686]
How about a hashtable/hashmap, though? Here is the Java implementation:

[code]Hashtable h = new Hashtable();
h.put("key1", "number1");
h.put("key2", someObject);
String a = (String)h.get("key1");
MyObject b = (MyObject) h.get("key2");[/code]

Note that if the programmer blows the object types, he will get a run-time exception.


The other major difference I've found is in documentation. I tried to use a std::StringBuffer (or whatever the name is) in c++ and got so many cryptic erros I went back to sprintf(). For java. I would just go to java.sun.com and look up the error, but generally the error itself will be clear enough to understand.
[/quote]std::stringstream? You can find decent STL references if you look around: http://www.sgi.com/tech/stl/
Yes, the errors are slightly cryptic at first, but it usually tells you exactly what is wrong on the first line. For instance, VC7 will spit out ~10 lines of error message if you use an ::iterator instead of a ::const_iterator. They tell you exactly what went wrong, most of the crap it spits out can be ignored. If it's that much of a problem use something like STLfilt: http://www.bdsoft.com/tools/stlfilt.html to "decrypt" errors. The STL can be extremely ugly to work with; you need to be very judicious with typedefs.

[quote author=Kp link=board=30;threadid=5586;start=15#msg47768 date=1078523727]
iago: the only advantage I can see to your sample code over equivalent C++ code using a void* type is that the program will automatically crash itself with a ClassCastException if you screw up. This does not seem helpful to me. :P
[/quote]

Technically, it can also be caught and handled.

It sounds a bit like enabling RTTI in C++... What you're missing then is the ability to add an object such as an "int" and then later get type information for it. But I don't think that makes sense anyway because of the size of an int and the size of type information. And if you *really* want it, you can implement your own class "CInt", overloading the +, -, etc operators.

[quote author=Adron link=board=30;threadid=5586;start=15#msg47892 date=1078574251]
It sounds a bit like enabling RTTI in C++... What you're missing then is the ability to add an object such as an "int" and then later get type information for it. But I don't think that makes sense anyway because of the size of an int and the size of type information. And if you *really* want it, you can implement your own class "CInt", overloading the +, -, etc operators.
[/quote]

You can get the type in Java with the .getClass() method. You can also create a new instance of the object by calling .getClass().newInstance() or something along those lines.

[quote author=iago link=board=30;threadid=5586;start=0#msg47531 date=1078447579]
What kp said is completely right. Another thing you should think about is Java, though:

*cons*
-It builds to larger files which run slower
-Some features are missing

*pros*
- Code ends up A LOT cleaner (compared to using the STL)
- TONS of built-in functionality
- Complete cross-platform (dont' have to recompile for different platforms)
- Full (superior) use of object oriented programming, and automatic pointers (all objects are pointers).
[/quote]
Having used Java and C++ with STL, I don't see how Java is so much cleaner looking than C++ code using STL. In fact, I think code using STL looks much better, because you have to make lots of (unsafe) casts everywhere when using Java because instead of using something like templates, all the default Java containers use a class which is a base class of all other classes.

[quote author=Kp link=board=30;threadid=5586;start=15#msg47768 date=1078523727]
[quote author=St0rm.iD link=board=30;threadid=5586;start=15#msg47745 date=1078520599]I think having a common base class + templates would be ideal.[/quote]

As Adron remarked, I still don't see any place in real code where you actually benefit from having a universal base class, as opposed to deriving all the objects in the list from some custom base class. Perhaps you could provide an example, since iago hasn't?

iago: the only advantage I can see to your sample code over equivalent C++ code using a void* type is that the program will automatically crash itself with a ClassCastException if you screw up. This does not seem helpful to me. :P
[/quote]

.toString()

[quote author=St0rm.iD link=board=30;threadid=5586;start=15#msg48771 date=1078951449].toString()[/quote]

toString returns essentially useless data from Object; therefore, any variable on which you would want to use toString is already known to have overridden it to behave in a useful fashion. Thus, you know something about the type of the variable -- a universal base class is therefore not required.