irrlicht string class

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Post Reply
buhatkj
Posts: 444
Joined: Fri Dec 12, 2003 4:53 am
Contact:

irrlicht string class

Post by buhatkj »

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
My irrlicht-based projects have gone underground for now, but if you want, check out my webcomic instead! http://brokenboomerang.net
keless
Posts: 805
Joined: Mon Dec 15, 2003 10:37 pm
Location: Los Angeles, California, USA

Post by keless »

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"
a screen cap is worth 0x100000 DWORDS
buhatkj
Posts: 444
Joined: Fri Dec 12, 2003 4:53 am
Contact:

thats one way...

Post by buhatkj »

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
My irrlicht-based projects have gone underground for now, but if you want, check out my webcomic instead! http://brokenboomerang.net
powerpop
Posts: 171
Joined: Thu Jan 08, 2004 1:39 am
Location: san francisco

Post by powerpop »

the other nice thing to have would be string.c_ptr() which gives you access to the char structure so that strings could be copied to char* structs - i ran into this one today when trying to interface an irrlicht string with another library i am using that likes char*
Post Reply