TGE 1.4 and the STL

#1 Did you mean to post this in the T2D forums?

#2 I did. Sooner or later the merge to the 1.4 code base will happen...

#3 Michael, using stl_fix is still the way to go, IIRC.

#4 Ok, thanks. Sorry to hear that. I guess I'll have to keep poorly reimplementing STL-containers ;-)

#5 Torque already has vector and list templates. Look in core/tVector.h and core/llist.h. Also, I hacked a simple hash table together just before 1.4 shipped so it was too late to get it into 1.4, but it's in Mantis so will end up in the next version of TGE. If you're impatient you can get it here. TGE also provides SimGroup and SimSet for script accessible groups of SimObjects. Most of the useful objects in TGE derive from SimObject, and pretty much every useful object you write for TGE will be the same. These have all been in TGE since day 1.

So, in short, TGE already has pretty much all the containers you need. There is not a lot of point in using the STL with TGE unless you're interfacing with an already existing library that uses STL. There is also no need to reimplement STL containers except for some very isolated cases, and even then restructuring your code could remove at least some of those isolated cases.

#6 Thanks Tom.

It's mostly the std::string I miss, and the std::map, and the std::priority_queue a little.
I recently had problems with the Torque vector class when using it as a stack of pointers. It would always null the pointers I pushed back. I don't trust it very much anymore. And I cannot store objects in it, that need destruction.
And I use SimSets quite often.

But it's mostly the strings I miss.

#7 The aforementioned hash table fills some of the gaps with map. It doesnt try to replace map though, more like a half way point. A priority queue would take 5 minutes (on a slow day) to write based on llist. If you're doing enough string processing in C++ for std::string to be at all helpful, then you're writing code that should probably be done in script instead. I dont know why you're having problems with vector, its never caused me any pain. Then again, i havent tried to use it as a stack. If you need to store objects that need destruction, it wouldnt take that long to create a subclass of Vector that does support it. Alternatively, you can just store pointers and delete them when you remove them.

As an aside, if you're using 1.4 you should look at StringBuffer. It was created to make dealing with Unicode strings less painful, and may do some of the things you miss from std:string.

T.

#8 Michael,

Also, did you try using "VectorPtr<>" and "SimObjectPtr<>"; I've always found these very reliable and fast.

- Melv.

#9 Thanks for the hash table. Will try it. (How does it handle collisions?)

Quote:
It doesnt try to replace map though, more like a half way point. A priority queue would take 5 minutes (on a slow day) to write based on llist.

I already have my own replacements for map and pqueue. But my pqueue is not nearly as fast as std::priority_queue although I use a binary heap in an array. The map replacement only works for const char* keys, insertion is a bit slower and lookup is 100% faster in my tests.

Quote:
If you're doing enough string processing in C++ for std::string to be at all helpful, then you're writing code that should probably be done in script instead.

I don't think so. I would prefer std::string because they are cleaner than C-strings. And I prefer C++ over TorqueScript for the same reason. Script gets messy so fast and especially for the core functionality of my game I don't want to use script. However, this is just me.
The problem too is, I already had quite a bit of working code that was using the STL.

But nevermind. As said above, I already have replacements. It would have been nice to have STL support but I can live without it.

#10 @Melv:

Yes, I was using VectorPtr after Vector didn't work. I don't have the crashing code anymore, but it was something like:

void ObjectCache::freeObject(T* inObject)
{
   Con::printf("freed object: %p", inObject); // <-- This printed something like 00A4FF04
   mFreeStack.push_back(inObject);
   Con::printf("freed object 2: %p", mFreeStack.back()); // <-- This printed 00000000
}

I thought it had to do something with returning a reference to a pointer which never worked when I tried to do it. I then just made my own class PointerStack and it worked.

#11 Sorry for interrupting this thread, but what exactly is the problem with using the C++ Standard Library with TGE/T2D?

#12 Torque's Memory Manager redefines the global operator new. This prevents any STL headers from getting compiled.

EDIT: I am using the hash table now in my project. Thanks Tom! It seems to work fine. (Which means the program doesn't crash and I don't lose any items. I have not made any tests on performance).

#13 I havent tested performance either, mainly because i havent needed it for anything all that critical. It's based on some ancient code that has been in TGE for years but wasnt used, so there may be issues yet to be found. I've already fixed a couple of bugs in it, so as long as you're using the tSparseArray.h from the .zip and not the original TGE then there shouldnt be any issues.

Re: collisions question that I forgot to answer: SimpleHashTable just derives from SparseArray and adds the neccessary code to generate the hashes, so SparseArray deals with the collisions. It's called Simple for a reason, unfortunately ;-) I am starting to lose the ability to do without iterators for the hash table so I might add those at some point, but if someone beats me to it then please post the code.

T.

#14

Quote:Torque's Memory Manager redefines the global operator new. This prevents any STL headers from getting compiled.

That can't be all. I've used memory testing software that overloads new globally, and I haven't had a problem with STL. Granted, I only used Microsoft's Standard Library implementation, so I don't know how GCC or other things would react.

#15 Addendum: if the memory manager is the problem, what about this "TORQUE_DISABLE_MEMORY_MANAGER" flag that Michael was talking about? Does that work?

#16 Here is some info and the STL problem:

www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=7480
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6190

#17 Problem with Torques tVector implementation is that it won't work with dynamic types. std::vector does compile time evaluations of types to see if it can use a faster memcpy/memmov or if it needs to use the assignment operator. Probably fine for most cases but it leaves a dangerous situation wide open.