RE and the STL
by Tom Bampton · in General Game Discussion · 06/12/2003 (8:26 am) · 17 replies
Hiya,
OK, I know the RE is meant for beginners, and the STL isnt exactly beginner friendly, so this probably won't effect most people, but here goes anyway.
If you compile in Debug mode, the overloaded new operator in debug_mem.h causes problems with Visual C++ 6's STL implementation (and maybe others, but I havent checked). Specifically, you get errors like:
c:\program files\microsoft visual studio\vc98\include\xlocale(218) : error C2660: 'new[]' : function does not take 1 parameters
The "proper" way to fix it would be to add another overloaded new operator to handle the way the STL wants it, however I'm lazy so I fixed it like this:
At the top of debug_mem.h add:
#ifndef RE_NO_NEW_OVERLOAD
and at the bottom add:
#endif // RE_NO_NEW_OVERLOAD
(I actually put them in a more sensible place, but it's easier to explain this way)
Then, in debug builds where you don't want the overloaded new/delete stuff, you just define RE_NO_NEW_OVERLOAD in your project settings and all is fine and dandy. Of course, when you do this, you wont get memory tracking, which for some people could be a problem, but then I guess those people wouldn't be using the STL anyway ;-)
This was somewhat of a pain to track down and I didnt look into it fully, so it may be I'm just being stupid. But hey, this works for me, and it might save some people some time.
Tom.
OK, I know the RE is meant for beginners, and the STL isnt exactly beginner friendly, so this probably won't effect most people, but here goes anyway.
If you compile in Debug mode, the overloaded new operator in debug_mem.h causes problems with Visual C++ 6's STL implementation (and maybe others, but I havent checked). Specifically, you get errors like:
c:\program files\microsoft visual studio\vc98\include\xlocale(218) : error C2660: 'new[]' : function does not take 1 parameters
The "proper" way to fix it would be to add another overloaded new operator to handle the way the STL wants it, however I'm lazy so I fixed it like this:
At the top of debug_mem.h add:
#ifndef RE_NO_NEW_OVERLOAD
and at the bottom add:
#endif // RE_NO_NEW_OVERLOAD
(I actually put them in a more sensible place, but it's easier to explain this way)
Then, in debug builds where you don't want the overloaded new/delete stuff, you just define RE_NO_NEW_OVERLOAD in your project settings and all is fine and dandy. Of course, when you do this, you wont get memory tracking, which for some people could be a problem, but then I guess those people wouldn't be using the STL anyway ;-)
This was somewhat of a pain to track down and I didnt look into it fully, so it may be I'm just being stupid. But hey, this works for me, and it might save some people some time.
Tom.
#2
I wanted to use STL for the invaders game that Crhis ripped off (snicker), instead I went with Array().
-Ron
06/12/2003 (8:50 am)
RE has a built in Array() which is very similar in respects to vector etc.. might want to give that a look see...I wanted to use STL for the invaders game that Crhis ripped off (snicker), instead I went with Array().
-Ron
#3
Not an option, unfortunately :) My backend library (which has all manner of useful things like compression, etc) which I need for what I intend to use RE for, happens to use the STL. I can't use RE code in that (it's used for other things, not all closed source). I'm just too lazy to write a vector template.
I have it all working with the memory tracker modifications I mentioned above, so I'm not too worried about it. It's one of those "do before we go gold" things that never gets done ;-)
T.
06/12/2003 (2:23 pm)
Ron,Not an option, unfortunately :) My backend library (which has all manner of useful things like compression, etc) which I need for what I intend to use RE for, happens to use the STL. I can't use RE code in that (it's used for other things, not all closed source). I'm just too lazy to write a vector template.
I have it all working with the memory tracker modifications I mentioned above, so I'm not too worried about it. It's one of those "do before we go gold" things that never gets done ;-)
T.
#4
Good catch, I don't use STL as I've heard it can cause problems porting, though not sure why?
I'll add this fix to the debug modules in the next build.
Thanks
Chris
06/13/2003 (10:18 am)
Tom,Good catch, I don't use STL as I've heard it can cause problems porting, though not sure why?
I'll add this fix to the debug modules in the next build.
Thanks
Chris
#5
No probs. Regarding porting, the library I mentioned runs on Windows, BSD and Solaris (and more then likely many oher Unix like OSs). The parts of the STL that uses works fine. If I remember right, I only use vector, map and the iterators that go along with it.
I'm sure there are some places that cause problems, but I've not come across them yet.
While you're here, to save another thread, are you interested in patches to RE ? I'm not entirely sure yet what I'm going to be changing (since I havent gotten through figuring out exactly what is there and what needs doing yet), but I'm sure something useful to people other then me will come out of our projects.
T.
06/13/2003 (5:36 pm)
Chris,No probs. Regarding porting, the library I mentioned runs on Windows, BSD and Solaris (and more then likely many oher Unix like OSs). The parts of the STL that uses works fine. If I remember right, I only use vector, map and the iterators that go along with it.
I'm sure there are some places that cause problems, but I've not come across them yet.
While you're here, to save another thread, are you interested in patches to RE ? I'm not entirely sure yet what I'm going to be changing (since I havent gotten through figuring out exactly what is there and what needs doing yet), but I'm sure something useful to people other then me will come out of our projects.
T.
#6
--KallDrexx
06/13/2003 (6:13 pm)
I've used STL on linux and i'm sure it works on mac so i'm not quite sure about the porting thing.--KallDrexx
#7
Most of the STL issues are side-effects rather than core STL issues. For example, many STL implementations implement their own new/delete operators so if you also do so in the wrong manner or order, things blow up.
I ran into a similar issue when I was playing around and all I had to do was switch the order of includes and everything was better. Still the less fiddling you have to do to get things to compile, the better.
Stay Casual,
Ken
06/13/2003 (8:15 pm)
G'day!Most of the STL issues are side-effects rather than core STL issues. For example, many STL implementations implement their own new/delete operators so if you also do so in the wrong manner or order, things blow up.
I ran into a similar issue when I was playing around and all I had to do was switch the order of includes and everything was better. Still the less fiddling you have to do to get things to compile, the better.
Stay Casual,
Ken
#8
I think Ken is probably right about the STL making headers order matter... and thus complicating a port. They ARE supposed to be "Standard". I well known programmer who has helped port several GG products to Mac, was the one who told me to avoid using STL to make porting easier.
Anyhow, you should attend our IRC Chat this Sunday at 4PM Pacific time.
Chris
06/14/2003 (1:25 pm)
Tom,I think Ken is probably right about the STL making headers order matter... and thus complicating a port. They ARE supposed to be "Standard". I well known programmer who has helped port several GG products to Mac, was the one who told me to avoid using STL to make porting easier.
Anyhow, you should attend our IRC Chat this Sunday at 4PM Pacific time.
Chris
#9
I hate having to use home-rolled solutions which work ALMOST the same as STL, mainly because theyre probably less useful and undocumented.
I'd say fix the problem with STL compiles and lets stick STLPort support in, but then it aint my call :)
What should happen is that you have an include file which undefs the other STL new/delete and defines the new and delete of the REAL stl :)
Wonder what the mac issues are?
Weird that they were having issues porting stuff from GG to the mac, given that torque doesnt actually USE the stl :)
Phil.
06/14/2003 (1:40 pm)
We use STLPort on all our stuff at work, to be honest I'd not bother with any other STL lib, but STLPort actually works pretty well.I hate having to use home-rolled solutions which work ALMOST the same as STL, mainly because theyre probably less useful and undocumented.
I'd say fix the problem with STL compiles and lets stick STLPort support in, but then it aint my call :)
What should happen is that you have an include file which undefs the other STL new/delete and defines the new and delete of the REAL stl :)
Wonder what the mac issues are?
Weird that they were having issues porting stuff from GG to the mac, given that torque doesnt actually USE the stl :)
Phil.
#10
The programmer was discussing porting RE with me, but had worked on porting some other stuff for GG. I have no idea if TGE had any issues regarding any of this.
Chris
06/14/2003 (1:58 pm)
Phil,The programmer was discussing porting RE with me, but had worked on porting some other stuff for GG. I have no idea if TGE had any issues regarding any of this.
Chris
#11
The RE doesnt really need to use STL, but games using it should be able to work with the STL if the programmer wants to use it.
If it's down to the individual teams to choose whether to use STL or not, those that choose to do so can also choose the implementation. I think that anybody who is choosing to use the STL, will know enough about it to know the portability issues. Useful though the STL may be, it's not particularly beginner friendly (IMHO, anyway).
I did try rearranging headers (thought I had posted a reply to Ken, but guess I forgot to) but it didnt make any difference to the problem I was having with the debug allocators. I could probably of rearranged some more, but then I couldnt of used my lib in RE itself (needed to support some custom image formats and some other small things).
Perhaps all RE needs is a define (undef'd by default) I_WANT_TO_USE_THE_STL_AND_I_KNOW_WHAT_IM_DOING that disables anything that messes it up.
Sorry I couldnt make the RE chat, was working all sunday and fell asleep when I got home.
T.
06/16/2003 (2:15 am)
Chris,The RE doesnt really need to use STL, but games using it should be able to work with the STL if the programmer wants to use it.
If it's down to the individual teams to choose whether to use STL or not, those that choose to do so can also choose the implementation. I think that anybody who is choosing to use the STL, will know enough about it to know the portability issues. Useful though the STL may be, it's not particularly beginner friendly (IMHO, anyway).
I did try rearranging headers (thought I had posted a reply to Ken, but guess I forgot to) but it didnt make any difference to the problem I was having with the debug allocators. I could probably of rearranged some more, but then I couldnt of used my lib in RE itself (needed to support some custom image formats and some other small things).
Perhaps all RE needs is a define (undef'd by default) I_WANT_TO_USE_THE_STL_AND_I_KNOW_WHAT_IM_DOING that disables anything that messes it up.
Sorry I couldnt make the RE chat, was working all sunday and fell asleep when I got home.
T.
#12
Other situtations (such as Tom's) can be handled by the individual team, where they can add STL support (with help from Chris et'al if needed) for their project and not cloud RE's mission statement.
-Ron
06/16/2003 (3:59 am)
My take is that the RE is supposed to be a novice engine, most if not all novice's do not have a clue about STL. I feel that the Array template that RE already has is powerful enough (for the novice) to handle most Vector type things.Other situtations (such as Tom's) can be handled by the individual team, where they can add STL support (with help from Chris et'al if needed) for their project and not cloud RE's mission statement.
-Ron
#13
I agree that is a team wants to use STL RE should not prevent them from doing so. Is the new and delete the only thing you've found that messes up the use of STL?
I added the RE_NO_NEW_OVER define, which seems like a great suggestion. Have you caught other places?
Chris
06/16/2003 (8:42 am)
Tom,I agree that is a team wants to use STL RE should not prevent them from doing so. Is the new and delete the only thing you've found that messes up the use of STL?
I added the RE_NO_NEW_OVER define, which seems like a great suggestion. Have you caught other places?
Chris
#14
As far as I have found so far, that's the only issue. If I find issues elsewhere I'll let you know.
Things are integrating nicely now with that modification. I finally got RE to load other image formats other then BMP (using a custom format at the moment, but I will extend RE to support PNG, JPG, etc later on), but that was unrelated to STL, and am just triumphant cus it was a bit of a pain to get to work ;-)
T.
06/16/2003 (4:05 pm)
Chris,As far as I have found so far, that's the only issue. If I find issues elsewhere I'll let you know.
Things are integrating nicely now with that modification. I finally got RE to load other image formats other then BMP (using a custom format at the moment, but I will extend RE to support PNG, JPG, etc later on), but that was unrelated to STL, and am just triumphant cus it was a bit of a pain to get to work ;-)
T.
#15
The newest build, which is almost ready integrates the Corona library. This supports most image formats.
I can get you a beta of this build right now so you won't have to do any extra work.
just drop me a line... chrismcole@yahoo.com
06/16/2003 (7:14 pm)
Tom,The newest build, which is almost ready integrates the Corona library. This supports most image formats.
I can get you a beta of this build right now so you won't have to do any extra work.
just drop me a line... chrismcole@yahoo.com
#16
Either way, it is all good in the end :)
Rock on RE!!
-Ron
06/16/2003 (7:24 pm)
welp, looks I went left and Chris went right :) Tried to (in a way) predict the Novice nature of RE with respects to STL.Either way, it is all good in the end :)
Rock on RE!!
-Ron
#17
Email sent.
Ron,
Hehe, everybody has different ideas for where things should go. But yeh, you're right, it is all good in the end :)
T.
06/17/2003 (5:44 am)
Chris,Email sent.
Ron,
Hehe, everybody has different ideas for where things should go. But yeh, you're right, it is all good in the end :)
T.
Torque 3D Owner Tom Bampton