Virion, thanks for the kind words . greenya nice trick but i hate macros
Sudi no hell brother just peace...
and DtD i will try to follow you're advice
Funtion
%
I am almost approx. 9% done with it but I will try to follow your advice my friend
small example of what i'm doing
befor: device->setWindowCaption(L"text...");
And now: WN(device, "text..");
small example of what i'm doing
befor: device->setWindowCaption(L"text...");
And now: WN(device, "text..");
Code: Select all
void WN(IrrlichtDevice * Device , char * Text)
{
if (Device != 0)
{
int size = strlen(Text);
wchar_t unicode_string[30];
size_t length = 0;
length = mbstowcs_s(&length, unicode_string, Text, size+1);
Device->setWindowCaption(unicode_string);
}
}
-
- Posts: 208
- Joined: Sun Apr 02, 2006 9:20 pm
I nearly spat my coffee on my keyboard when I read that. Unlike footballers as C gets older it stays just as fast and functional as it ever wasVirion wrote:but i'm sure you can't really program an entire game using C-style API. so its quite pointless.
Wrapping Irrlicht in a C interface carefully actually adds very little overhead into your program.
Right my coffee can stay in my mouth this time. I would entirely agree that unless you have a good reason for wrapping the code (e.g: you need to access it from a language or tool that does not support C++ mangled DLLs) you would be better off sticking with C++, avoiding any overhead (no matter how small) and saving time on your project.Virion wrote:my advice is spend time on doing your game or whatever project than re-wrapping the whole Irrlicht.
If you decide to continue producing a wrapper some pieces of advice I would offer from my own experience are to use consistent function names that are close to the irrlicht names for example I would use setWindowCaption its nice and descriptive, pass parameters in consistent ways and pass parameters in a manner that does not increase the overhead by reformatting the parameters once inside the wrapper function.
Whatever you decide M4UNOT good luck with your project.
Macros are a good thing to hate they can cause very cryptic issues if done incorrectly. (But don't diss them too much, they can also be very useful for making readable code, for example, this is a file from our game engine: http://pastebin.com/xR3gW1qb without macros that would be a huge mess.)
Also, like Frank said, "WN(device, "text..");" doesn't actually tell you anything about what the function does, for all we know it means "Window Notifty" and it displays a message box belonging to the specified device with that text. Have you discovered code completion yet? It will make typing those long function names much less tiring. (EG: You would just type device->setW and hit Ctrl+Space and the IDE does the rest.)
Also, also: All of that string conversion stuff is a dangerous game, you should avoid converting values unless it is necessary (EG: You get user input as a string and you need a float, or some library uses unsigned ints when another needs a float.)
Also, like Frank said, "WN(device, "text..");" doesn't actually tell you anything about what the function does, for all we know it means "Window Notifty" and it displays a message box belonging to the specified device with that text. Have you discovered code completion yet? It will make typing those long function names much less tiring. (EG: You would just type device->setW and hit Ctrl+Space and the IDE does the rest.)
Also, also: All of that string conversion stuff is a dangerous game, you should avoid converting values unless it is necessary (EG: You get user input as a string and you need a float, or some library uses unsigned ints when another needs a float.)
Have looked on that code.DtD wrote:... they can also be very useful for making readable code, for example, this is a file from our game engine: http://pastebin.com/xR3gW1qb without macros that would be a huge mess.)
IMHO, this is not good style of usage, because that macro is only usable at that file, even more -- only inside a method because it uses particular name of variable ("as") and does particular call on it ("RegisterEnumValue"). It should be defined -> used -> undefined (right at the place where it actually used; and should be visible only where it has meaning).
for example:
Code: Select all
...
#define _BIND_KEY(key) as->RegisterEnumValue("EKEY_CODE",#key,irr:: ## key)
_BIND_KEY(KEY_NUMPAD8)+
...
_BIND_KEY(KEY_OEM_CLEAR);
#undef _BIND_KEY
...
+ when somebody include your file, he will not get _BIND_KEY macro in global namespace;
+ same macro name can be reused many times even in single file or function; (on MS VS2008 compiler, when you redefining existing macro you getting proper warning)