User forums > General (but related to Code::Blocks)
xrc vs c++
djesus:
Hi all, firt of all thank you for your work!. I would like to know if is more faster to load a xrc file or insert in c++ and compile. I used the great wxSmith and I choose to generate xrc, but I don't know the advantages of xrc.
Can generate with wxSmith c++ code from a xrc generetated or if i choose xrc i can't any more to go back.
thomas:
It is certainly faster to insert the C++ code, as this eleminates ZIP decompression and XML parsing. XRC still has to call the C++ functions to build the controls and add them to the dialog.
However... does it really matter? One takes one millisecond, and the other maybe takes two. A dialog is usually generated a few times and is open several seconds (or longer).
XRC, despite being slower, has one big advantage: it is easily extensible without the need to recompile anything (and without very painful code bashing).
I believe that XRC versus C++ is not the correct place to think about optimizing for speed.
Game_Ender:
Using XRC does have overhead. You incur a slight penalty for everything forc reating the dialog and referencing widgets that are XRC only. The advantage of XRC is that there are many wxWidgets RAD tools that can load and save dialogs directly from XRC so you can use wxSmith, DialogBlocks, and wxDesigner all to work on the same set of Dialogs. I really don't know how much slower XRC loading is than just creating the dialog in pure C++, but I wouldn't be surprised if took a 2 to 3 times as long to create a dialog from XRC than it did with C++. It is important to note though, that a could design will have you just showing and hiding dialogs, not destroying them, so you don't really have to worry about the creation penalty. From a design standpoint it is easier to understand the layout of a dialog from and XRC than code, so you have that advantage there too.
thomas:
--- Quote from: Game_Ender on February 19, 2006, 10:30:52 pm ---I wouldn't be surprised if took a 2 to 3 times as long to create a dialog from XRC than it did with C++.
--- End quote ---
True, but like I said... who cares. You don't load a dialog 20 times per second, but you load it once and display it for 20 seconds. No matter what, the user won't know whether it takes 1ms, 5ms, or even 20ms to load. :)
Editing the structure of a dialog when it is coded in C++ is a pain in the anus. On the other hand, in XRC it is a matter of a few seconds, even without using a RAD - any cheap text editor will do. You just move a few tags around, and you're fine. If you have it hardcoded in C++, then the same thing is a desaster (plus, you have to recompile). That is the most important thing in my opinion.
Game_Ender:
--- Quote from: thomas on February 19, 2006, 10:23:13 pm ---has one big advantage: it is easily extensible without the need to recompile anything (and without very painful code bashing).
--- End quote ---
Now the ability to quickly make a layout changes is very useful, especially if you don't have a RAD tool like DialogBlocks or wxSmith. The catch is you can't change the name of any components without a code update and a recompile, and you can't make new event handlers or change event handlers, which is the other half of GUI programming. Those task require a recompile, but I still think XRC is pretty good at what it does: Quick GUI layout changes, and data interoperability. I am not trying to bash XRC, but it is not a complete widget marshaling tool.
Navigation
[0] Message Index
[#] Next page
Go to full version