I''m just using the MSVC built in STL. The doco is pretty crappy. Went out and bought "STL programming from the ground up" yesterday and already understand the concept behind all the bits. "Things that hold data" "things that manipulate data" and all the formats are standardized. Nice design, I''ve had glimmers of this thoery for a while as a VB COM programmer I''d never have developed the idea this far though.

What really made me pat attention was one poster who said that large portions of STL are in assembler. Previously I was under the impression that STL was going to be god awfully slow due to the kind of abstraction and inheritance that would be require to make this kind of thing work. Initially I thought that this was anoother one of the corperate reusablity over efficiency things.

I also like the performance guarantee''s. Not knowing the implemetation that was used behind certain feature used to make me distrustful of it''s speed. (how do I know that iterating through a vector isn''t just as slow as an linked list for example?).

Now I''m happily learning away

gimp

quote:Original post by gimp

I''m just using the MSVC built in STL. The doco is pretty crappy. Went out and bought "STL programming from the ground up" yesterday and already understand the concept behind all the bits. "Things that hold data" "things that manipulate data" and all the formats are standardized. Nice design, I''ve had glimmers of this thoery for a while as a VB COM programmer I''d never have developed the idea this far though.

What really made me pat attention was one poster who said that large portions of STL are in assembler. Previously I was under the impression that STL was going to be god awfully slow due to the kind of abstraction and inheritance that would be require to make this kind of thing work. Initially I thought that this was anoother one of the corperate reusablity over efficiency things.

I also like the performance guarantee''s. Not knowing the implemetation that was used behind certain feature used to make me distrustful of it''s speed. (how do I know that iterating through a vector isn''t just as slow as an linked list for example?).

Now I''m happily learning away

gimp

Do tell, what bought you back from the darkside? (VB to C++?)
In my experience with VB.... speed simply could not be a concern... It was given that is was going to be slow. For an excel add-in that I made I eneded up writting most of the code in a .dll & linking to it in vba (boy was that a painful learning experience) - ''Course you said COM...

VB:
I did a security administration and mannaged remote execution system. I needed something that would perform an authenticated connection from a webserver where the commands were submitted for execution to a normal member server. I went with a html front end using asp, data stored in a sql database, the impersonation\security was carried out by a vb com object running in the contect of a netwoek wide administrator in an MTS package. A vb DCOM object on each machine would authenticate the call and excute the command \ return the output.

I essentially put it together over about 3 weeks with most of my time spent making the html netscape, ie3 amd ie4 friendly.

For things like this where as you said speed isn''t an issue VB + COM iss brilliant, in fact there ar only 2 things I use VB for now, COM and SQL. I''d even give a GUI a shot in VC.

What brought me back?
Events:
-gimp tries to use a few win32api''s and has to use some stupid memcpy thing... whatever the hell that is...
-gimp writes a MIME encoder for an SMTP COM component (so the system above can mail error to the developer(me)). The encoder take 1 min to encode 1 meg, a friend code a c++ one to do it in under a second)
-gimp starts writing a file parser to get all the textures used in a quake stype map file and copy them for another directory to help the release process for a mod he''s working on. sending everyone a msvbvm50.dll sound like a bad idea.
-gimp realises that all those unix boffin actually have a use after all teach me C! (On company time to boot!)
-gimp is tutored on C, gets the app running, the app executes at blistering speeds...gimp drools 5mb copied with getc() and putc() in one second. Not even using memory mapping...
-gimp get shits with is mod team for being so slow and finds gamedev, reads a cool tutorial on Cubic splines and gets pumped about writing a MP game
-gimp likes Battlezone and thinks something along similar lies would be a good goal (for a person who has only ever written a single file parser)
-gimp finds wildtanget engine to handle the outdoors terrain, grabs a copy of "Tricks of the game programming guru''s" and "Learn C++ in 21 days"[this was easter]


So there is the who story of how I went from a VB professional to a C++ minor league player. I''m currently reading 3 books, "Efficient C++", "Data structures and algorithms"(some uni book) and "STL from the ground up"(Herbert Schildt).

3 months ago I was a games don''t need OO and C is faster person, now my code bank is getting so large that I need pictures and classes to mentally keep track of everything.

The major factor was:
-VB could never used used to run games(well good ones anyway)
-VB makes it hard to call WIN32 API''s
-VB could never be ported to linux
-VB makes easy things easier and hard things harder.

Once I got used to using character arrays rather than string I was fine.

gimp