Technically speaking, they're entirely different worlds.
Coding wiser they have similar syntax but couldn't be further apart if they tried.
Visual Basic upto 6 (98) is interpreted, this is very much like DB Standard/Enhanced. In the way that code is converted realtime using a runtime library/exe, although VB is capable of making DLLs; it's only export capability is COM which is only really reuseable in VB or Object-based Applications. C++/C#/VB/J#/IE/Python(albeit hard as hell to include in the first place)/PureBASIC
Visual Basic .Net/7.x however uses runtime compiled code, so it takes a little longer to start but will adapt to any system; however, it still *REQUIRES* runtimes in order to work, .Net Framework and Common Control DLLS which both weigh in at a hefty 45MB total.
Dark Basic Professional also uses 'compiled' code but basically uses framework + runtime libraries for everything else.
This actually puts DBP in a very hard place in which to say 'it belongs in the compiled/interpreted/binary framework/etc...' catagories. Because it is a bit of everything and a bit of nothing.
However provided they both do thier job, i don't care what libraries are in the background to achieve it or why it's achieving it (not programming in it anyways).
So it more comes down to the technical language abilities.
VB6 & DB are worlds apart in terms of language, mainly because DB is procedural and VB is object orientated.
So whereas in DB you directly tell the application what functions come where, in VB you basically tell it what information it needs and it figures out the presidence of that stuff in the background, the higher the number of requried calls the higher in the presidence chain it goes.
This also extend to the language. In DB you work primarily with a single object at any given time...
Variable / Function / Array; all within basically a single object point.
Visual Basic you work primarily to object attached variables / functions and arrays.
This means rather than code like;
dim MaxPlayers(0) : MaxPlayers(0) = 4
dim playerposition#(MaxPlayers(0),3)
dim playerhit(MaxPlayers(0),1)
dim playerhealth(MaxPlayers(0),1)
do
UpdatePlayer( playerposition#(1,1), playerposition#(1,2), playerpsotion(1,3) )
`etc..
loop
you would write something like
#define MaxPlayers = 4
typedef Player
position as xyz
hit as bool
health as integer
UpdatePosition( Player.x, Player.y, Player.z )
end
dim PlayerInfo( MaxPlayers ) as Player
MAIN:
PlayerInfo( Plyr1 ).UpdatePosition( )
END
niether code is correct, more so the VB as i don't think you can actually do that without a structure class, but still i think you get the idea between the coding types.
DBP does get basic objects, but compared to VB.Net this is extremely tame;
type MyType
a as integer
b as float
endtype
Value as MyType
Value.a = InputA
Value.b = InputB
compared to
typedef MyType
a.integer()
b.float()
end
Value.MyType( inputA, inputB )
again i don't think the VB is quite right as i've not used it, but i think it conveys the different in how it all works.
VC++ .Net isn't Managed C++ you can choose how you program, if anything C# is actually managed C++. (or mangled C++ if you ask me)
Quote: "True CR, but nobody refers to VB.NET as VB 7.0 unless they're deliberately trying to mess with someone or they are clueless. In this case, I'll put my money on a fool that wouldn't know a Direct3d surface if you smacked him with it."
i refer to all .net as 7.0, just like i refer to all of visual studio 98 as 6.0 / version numbers you know exactly what your dealing with.
That and there are now 2 versions of .Net, 7.0 and 7.1 .. which are not compatible with each other + 8.0 is due out sometime in 2005 which confusingly enough is also called .Net;
