If you can read this, you have JavaScript turned off.
Please turn it on for optimal browsing experience.
In my previous post, I mentioned that Umbra's head revision now requires libtcod's revision 522 or later. Now, what I didn't mention was why. So, here's the reason.
As you already know, Umbra relies on libtcod's parser to load its main configuration (among other things). The configuration variables are registered in the parser so that it knows what to look for. OK, it's nothing new. Just look at the code. Here's what it used to look like:
//register configuration variables
TCODParserStruct * config = parser.newStructure("config");
config->addProperty("rootWidth",TCOD_TYPE_INT,true);
config->addProperty("rootHeight",TCOD_TYPE_INT,true);
config->addProperty("fontID",TCOD_TYPE_INT,true);
config->addProperty("fullScreen",TCOD_TYPE_BOOL,true);
config->addProperty("logLevel",TCOD_TYPE_STRING,true);
//optional custom font directory
config->addProperty("fontDir",TCOD_TYPE_STRING,false);
//optional module chaining
config->addProperty("moduleChain",TCOD_TYPE_STRING,false);
I don't know how you like this, but as a guy who works with jQuery, I felt this was... wrong. Each call of addProperty(), addFlag() and such returned void. What a waste. And so I decided it would return a pointer to the TCODParserStruct it was operating on, the very same way most jQuery functions return the jQuery object they're called on. What's the advantage of this? Well, check this out:
//register configuration variables
parser.newStructure("config")
->addProperty("rootWidth",TCOD_TYPE_INT,true)
->addProperty("rootHeight",TCOD_TYPE_INT,true)
->addProperty("fontID",TCOD_TYPE_INT,true)
->addProperty("fullScreen",TCOD_TYPE_BOOL,true)
->addProperty("logLevel",TCOD_TYPE_STRING,true)
//optional custom font directory
->addProperty("fontDir",TCOD_TYPE_STRING,false)
//optional module chaining
->addProperty("moduleChain",TCOD_TYPE_STRING,false);
As you can see, subsequent calls to the parser-related methods can now be chained. This works only in the C++ version of libtcod, as the C version takes the parser structure as a parametre, so instead of chaining we'd end up with nesting multiple functions within each other's arguments. Not a fun thing to do, trust me (even though I notoriously pass anonymous functions as parametres in jQuery, I know, I know...).
Of course, the old syntax is perfectly valid and will work nonetheless, so older code will not stop compiling. It's just a little extra syntactic sugar you can use in your C++ projects using libtcod :).
Comments
You should not return a
Submitted by Tapio on Sun, 02/13/2011 - 22:55
You should not return a pointer but a reference. Good C++ practice is to favor references (const if possible) over pointers whenever feasable. References are safer as they cannot be NULL (in chaining you definitely don't want the function to accidentally return NULL as that would lead to segfault) and they'll also make the code even shorter by exchanging the two characters in -> operator to just one in the dot. :)
That's a reasonable remark,
Submitted by Mingos on Sun, 02/13/2011 - 23:26