I disagree that VB cannot be used to program a media player or preload game levels,
...
And, as you said, there's nothing stopping VB from using the CreateThread API from the Kernel32 library to create a new thread.
Threading isnt nessecary for those things yes. But it simplifies things (well..it does) and allows much easier handling of the programs time loop (Can rely on a more constant proportion of cpu time).
A media player wouldnt have to pre-load a whole song (or if it would it'd keep it uncompressed : lol i remmember one day i decided to try loading all of Master Of Puppets...took up 80 megs of ram somehow): Load a few chunks, and while decompressing them, play the ones already decompressed..when finished, free, by which time now-decompressed ones can be played back. Obviously nessecary when dealing with movies: Of course your right it doesnt need threading, but then the gui thread and loading thread would be combined: a gui thread, altered in its time by user actions, interrupted, and forced to set a timer so the loading of some kb's of media can be called from the windows callback proc every x millisecs. I say leave it open and free to do what it does, and let another thread handle media in the desired time chunks.
You can overload variables in VB6, but I've never had the need to (I don't quite understand why you would want the same variable to act as a floating point integer one frame and a fixed point integer the next. Couldn't this lead to nasty game-stopping errors if the variable was expected to be one type but turned out to be another?).
Yeah. Its usually for the kind of efficiency in storage (swapping from using on to the other) that the compiler would end up doing better than the programmer if he wrote normally anyway. In C/C++ a union would allow that, or referencing a cast of a *( void* ) .
Functions on the other hand can be usefull, eg make a parent object with a virtual update(), a virtual render(), and make each of the child objects implement their own update() and render(). When they do so, they can do their own specific things, then call the bases update(), or, the base can call their update eg: this->update(), will call the 'youngest' childs update. Also, with arrays of function pointers, or something similar, something like:switch(val){case a:doA(argu);break;case b:doB(argu);break;....doZ(argu); } can be far faster and easily read as ( do[val] )( argu );
Poll
28 (28.6%)
Author
Topic: Languages? (Read 25980 times)