Namespaces
Namespaces
how to modify this code so it works without using namespace:
device->getTimer()->getTime();
Thanks in advance
device->getTimer()->getTime();
Thanks in advance
i'm having the same problem, how did you get around it ?
for
class ITimer : public IUnknown
{
public:
//! destructor
virtual ~ITimer() {}
//! returns current time in milliseconds. This value does not start
//! with 0 when the application starts. For example in one implementation
//! the value returne could be the amount of milliseconds which
//! have elapsed since the system was started.
virtual u32 getTime() = 0;
};
I get these errors about teh getTime() line :
25 C:\lfa\kenato\code\irrlicht-0.6\include\ITimer.h
cannot declare member
25 C:\lfa\kenato\code\irrlicht-0.6\include\ITimer.h
parse error before `->'
for
class ITimer : public IUnknown
{
public:
//! destructor
virtual ~ITimer() {}
//! returns current time in milliseconds. This value does not start
//! with 0 when the application starts. For example in one implementation
//! the value returne could be the amount of milliseconds which
//! have elapsed since the system was started.
virtual u32 getTime() = 0;
};
I get these errors about teh getTime() line :
25 C:\lfa\kenato\code\irrlicht-0.6\include\ITimer.h
cannot declare member
25 C:\lfa\kenato\code\irrlicht-0.6\include\ITimer.h
parse error before `->'
-
- Posts: 23
- Joined: Fri Aug 06, 2004 12:28 pm
The problem with Raknet and Irrlicht lies in the getTime-Class of Raknet, which includes the windows-header. As i found out, Windows has anywhere hidden an IUnknown Interface class... so there's a Problem because now there are two IUnknown classes...
I solved that in re-writing the getTime functionallity of Raknet, but it's still some problem
Can't niko rename the IUnknown interface to IIrrUnknown? That would solve some problems like that i think...
I solved that in re-writing the getTime functionallity of Raknet, but it's still some problem
Can't niko rename the IUnknown interface to IIrrUnknown? That would solve some problems like that i think...
wow, quick reply, thanks.
that's a bugger. I think I would like to see all clases and namespaces etc made to be as unique to irr' as possible; by prepending them with Irr
eg IrrString
to remove any conflicts with other libraries out there, like String for example
It's probably better coding and I consider it more professional to do so.
It's a fantasic engine nevertheless. It's just that little things like this make the "easy-to-use" engine that much more difficult to use.
that's a bugger. I think I would like to see all clases and namespaces etc made to be as unique to irr' as possible; by prepending them with Irr
eg IrrString
to remove any conflicts with other libraries out there, like String for example
It's probably better coding and I consider it more professional to do so.
It's a fantasic engine nevertheless. It's just that little things like this make the "easy-to-use" engine that much more difficult to use.
That is the purpose of having namespaces, so you dont get these conflicts. By effectively disabling them, you opened it up to potential conflicts. If that one is fixed, who knows for certain where the next one will pop up (based on other libraries that will be used, etc). Thus, why C++ came up with namespaces, and why, in a mixed library usage, they should probably be used.the_viking wrote: Can't niko rename the IUnknown interface to IIrrUnknown? That would solve some problems like that i think...
-
- Posts: 23
- Joined: Fri Aug 06, 2004 12:28 pm
I dont understand, are you suggesting a solution ?punt wrote: That is the purpose of having namespaces, so you dont get these conflicts. By effectively disabling them, you opened it up to potential conflicts.
Unlike the author of this thread I am using all the namespaces, and it hasn't helped me one bit. I'm not actually using the thing that has a problem. It just got included along with everything else, and its' name conflicts with something else i guess.
Which I why I suggested the unique names thing. That way namespaces or no you have a much more limited chance of problems. I mean irrlicht has the object String defined. Like no one else has ever defined that, coughSTL cough.
But STL has std::string, and Irrlicht uses irr::core::string. If you are using namespaces as you said it should have no problems
Tomasz Nowakowski
Openoko - www.openoko.pl
Openoko - www.openoko.pl
hmmm, not what i meant. i do that anyway and it's a PITA.warui wrote:But STL has std::string, and Irrlicht uses irr::core::string. If you are using namespaces as you said it should have no problems
why put all your eggs in one basket is waht i'm thinking : namespaces are great but they're not going to solve world hunger. and after recognising that they are not perfect why not help yourself a little by making your life a little easier and take the time to give your classes (fairly) unique names.
not only would that help conflicts like you get with String, but you also make your code a little clearer : i'm making a game that will use gfx, snd, net, physics and my own libraries. so there's going to be a few different variable types in there. and if i can save myself some time and thinking by having the owner of the library clearly marked for each variable then why not.
it's not a revolutionary idea. it's just one more step from
int* MyInt;
to
int* pMyInt;
i mean, niko already has most of the classes covered with this idea. i'd just like to see that applied to all classes. kill two birds with one stone :
1) reduce probability of these collisions
2) increase constantcy of irrlicht object/type naming convention
plus ! typing IrrString instead of irr::core::string is saving me 8 whole characters ! ( not to mention it's a whole buttload better readability and maintainability wise )
hmm, i'm taking this thread off topic. should i move this to a seperate thread. i feel like making a poll about this
solved my prob
once i found out that devcpp wasn't shoing me the whole error message i got some more clues. basically raknet has a
#define getTime blahblah
so that scews up irr's getTime
I edited raknet to not need the define, and now irr' and rak' compiled fine together. I have the edited files for raknet 2.26 if anyone needs them
once i found out that devcpp wasn't shoing me the whole error message i got some more clues. basically raknet has a
#define getTime blahblah
so that scews up irr's getTime
I edited raknet to not need the define, and now irr' and rak' compiled fine together. I have the edited files for raknet 2.26 if anyone needs them