not being overly familiar with old skool c style file IO, i use regular old c++ iostreams and fstreams for my strings and file access. the hardest part for me in using Irrlicht has been making the routines to read files work for me. since the irrlicht string class has the name "string" just like the regular VC++ one i cant use the VC++ one cuz i get a namespace conflict. actually, the irrlicht string class isnt bad, but it's missing what i view to be two VITAL operators, ">>" and "<<". I will of course see what i can do about adding them myself. i wondered if anyone else had run into this or if im the only dipstick not doin it right heh
btw, in order to avoid any flames of "hey stupid, irrlicht has file IO built in!!", i KNOW, its just that it LOOKS JUST LIKE C, and i DONT GET IT!!!
-Ted
irrlicht string class
irrlicht string class
My irrlicht-based projects have gone underground for now, but if you want, check out my webcomic instead! http://brokenboomerang.net
actually, im using std::string right now.
first off, i dont use 'using namespace xxx' anywhere in my code, except inside of functions where I know the will only be using that namespace and will never need something that would conflict with it.
otherwise, i generally use the full path to all types EX: "irr::s32" or "std::string"
first off, i dont use 'using namespace xxx' anywhere in my code, except inside of functions where I know the will only be using that namespace and will never need something that would conflict with it.
otherwise, i generally use the full path to all types EX: "irr::s32" or "std::string"
a screen cap is worth 0x100000 DWORDS
thats one way...
yeh i had thought of that, and i suppose its a possibility, but at the same time, having a string class in irrlicht has advantages too, it would help ensure the portability of my code.
mostly though, debugging stuff that i gave wrong paths for, or forgot to include isnt fun, i tend to over-include prolly, just to make sure i can avoid it.
to be honest its more that i dont see a DISadvantage in adding the operators to irrlicht's string class...
is there one i missed?
surely its a low priority, but still, i feel my arguments of portability and usefullness have some merit...
-Ted
mostly though, debugging stuff that i gave wrong paths for, or forgot to include isnt fun, i tend to over-include prolly, just to make sure i can avoid it.
to be honest its more that i dont see a DISadvantage in adding the operators to irrlicht's string class...
is there one i missed?
surely its a low priority, but still, i feel my arguments of portability and usefullness have some merit...
-Ted
My irrlicht-based projects have gone underground for now, but if you want, check out my webcomic instead! http://brokenboomerang.net