|
|
|
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » Building & using U++ without TheIDE
 Building & using U++ without TheIDE [message #11360] |
Sun, 09 September 2007 22:03  |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
Hi! I wasn't sure where this belongs, so I posted here.
I was looking for a good cross-platform GUI instead of MFC/WTL/Win32API. Found many alternatives (wxWidgets, Qt, FOX, FLTK, VCF), but U++ seems to be closest to what I want - opensource, relatively light, but with enough features, and using C++ style (not macros).
The thing is, I just couldn't build the library. I'm a newcomer to opensource, but still I managed to build and use wxWidgets, FOX, FLTK (no success with VCF though). Using the default setup, programs work within TheIDE, but I want to work with Code::Blocks + MinGW, or maybe MSVC.
Might be a bit offtopic, but I'll say what was the first experience. While I've read people turn U++ down due to the way the code looks, I'll say that's the reason I want to use it. I like pointers (used them in 2D graphics, and implementation of data structures), but these simply don't belong to interface design - it should be nice, clean class code. Just the way it is in U++. Other toolkits just have lots of pointers to stuff an news/deletes everywhere.
But TheIDE and the layout designer are quite a disappointment (sorry, but that's my opinion). Build system is interesting, but the interface itself seems very unmature. Same goes for layout designer (especially inserting controls through right click, and not having splitter there). Although I might just be spoiled (VB / VB.Net have excellent IDEs and designers). I'd suggest nicer icons, a treeview to show packages and files, and a toolbox for widgets (all of them if possible).
So, I would like to use only the library part of U++, not TheIDE and layout designer. I tried to just include it, the way I did with WTL, but it didn't work - U++ has CPP files (WTL consists of several H files). I've read in another thread that the code cannot work as a DLL the way it is, so I tried to build a static library. That didn't work too - lots of warnings, and some errors. Started with some weird error about String's << operator (which I managed to fix), it continued with ambigous names (GetLocaleInfoA/W is name of Win32 API and of String's functions), and then it couldn't find classes definitions/declarations. That led me to finding that some CPPs (like Locale in Core) didn't have H files, and the classes they implemented were in H's of different names. I'm not sure just how legal is that from C++'s point of view, but I have no idea how to compile that.
Could anyone help me with building a static/dynamic U++ library without using TheIDE? I would really like to use U++ due to its potential, but there isn't much sense gaining cross-platformness at the cost of losing IDE/compiler freedom. If a static library / DLL would be available for download, I guess people would be more comfortable at trying U++ out with the IDE/compiler they're used to (IMHO most difficult part of using open-source projects is getting them to start working). Installing U++ isn't difficult, but TheIDE is very confusing at first.
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11361 is a reply to message #11360] |
Sun, 09 September 2007 23:47  |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
Search the forum, there was quite a lot of discussion about this topic.
Generally, it is possible to build U++ apps using generic make. So far, it is not possible to use other build systems to directly build it because of .icpp issue.
DLL version might not be the biggest problem; after all you can always use some tool to generate .def file.
My take is that library version is definitely possible, perhaps with some workarounds that to deal with things that theide build system deals with automatically.
What is missing is a devoted maintainer of such version; the problem would most likely involve rebuilding the tree to more classic form, maybe even using some automated source-changing procedures (like inserting registration routines as .icpp replacement).
The first iteration: You can use theide to get .obj files of everything, then simply gather them and make libraries...
Of course, the fundamental question is how you would reorganize U++ packages into perhaps bigger .lib files. If all you need is a single .lib per package, you can even generate .lib directly, but I am afraid that would yield too much .libs...
Mirek
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11364 is a reply to message #11360] |
Mon, 10 September 2007 01:48 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
Thanks for the quick reply.
I did search the forum previously, all I found was outdated MSVC solution files. Now I've seen your new post about icpp, previously I didn't even understand what they were.
I renamed icpp to cpp, inserted dummy functions, but then I don't think these were the cause of my problems (yet?). Static libraries build every cpp, and include every h included, right? (that would explain locale.cpp with no locale.h).
I might be missing something here. Here's what I'm doing:
1) In Code::Blocks (recent nightly build) using MinGW (GCC 3.4.5), I created a static library project.
2) Copied everything from uppsrc folder to project folder, added all cpp (including icpp, renamed to cpp so they get compiled), h and rc.
3) Defined PLATFORM_WIN32 in project options.
4) Ran build all. Got a bunch of warnings and an error.
Warning are mostly signed/unsigned. One was more serious:
Core\Util.h:283: warning: `class Upp::CharFilterTextTest' has virtual functions but non-virtual destructor
Error:
CbGen\CppGen.cpp:: In function `void CallbackGen(Upp::String, Upp::String, int, Upp::String, Upp::String)':
CbGen\CppGen.cpp:27: error: no match for 'operator<<' in 'String(((const char*)"template <class OBJECT, class METHOD")) << If(Upp::String, Upp::String)(Upp::operator+(const char*, const Upp::String&)(((const Upp::String&)((const Upp::String*)(&classdef)))))'
That was on:
String cl_temp = String("template <class OBJECT, class METHOD") << If(classdef, ", " + classdef) << ">";
I changed that to (not sure if correct, just wanted to continue):
String cl_temp = String("template <class OBJECT, class METHOD");
cl_temp <<= If(classdef, ", " + classdef);
cl_temp <<= ">";
Tried to rebuild. Even more warnings - signed/unsigned, and virtual for PrintPageDraw. It also found that:
Item& AddMenu(const String& t, const UPP::Image& m, Callback c) { AddMenu(t, m, c); }
Didn't return a value though it should.
And again an error. This time in Core\t.h:
INITBLOCK_(COMBINE3(LNG_MODULE, LNG_VERB, LNG_VERA))
{
static LngEntry__ langset[] = {
#include TFILE
{ 0, NULL }
};
#ifdef LNGMODULE
AddModule(langset, #LNGMODULE);
#else
AddModule(langset);
#endif
}
LngEntry__ and AddModule are undefined.
Included <Core/i18n.h> to this file. Looks like it helped.
Next error: String undefined in i18n, including <Core/String.h> helped.
Next - seems like due to my modifications String got included more than once. And looks like it doesn't have include guards.
OK, I might be able to go on "fixing" the source, but I guess something is wrong if I'm getting all these errors. Or maybe it's due to BLITZ putting all files together and thus solving dependancy problems...
I'd be glad to hear if there is an easy way to solve this. I didn't find a makefile to build U++. I guess taking *.o files from TheIDE could be a solution, but I'd prefer to be able to build a library without TheIDE.
|
|
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11369 is a reply to message #11360] |
Mon, 10 September 2007 12:25 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
Actually the idea was to make one big lib of everything. I guessed it would be about 2MB or so, which IMHO is acceptable as an exe size. Linking to the lib and including whatever I need (e.g. CoreLib/CoreLib.h) would give me access to the library.
I removed some unnecessary stuff from building. I also realized that there is no documentation on what file / folder is what - and that sources are uncommented.
Now I'm building (folders): Core, Crypto, CtrlCore, CtrlLib, Draw, DropGrid, Geom, GLCtrl, PdfDraw, plugin, RichEdit, RichText, Web.
Still, extra files weren't the problem. It just skipped the previously first errors, right to the t.h and i18n.h undefineds. BLITZ problem or not, I just can't get the structure of the sources right. I set former icpp-files priority higher than the rest to make them compile first, but that didn't change a thing. I tried pragma once and ifdef guards, but no use. At least one thing is undefined/redefined.
I think the structure of the CPP/H is the root of the problem. I'm used to the classic CPP+H pairs, plus a main file. There's also a purely-H system (like STL and WTL). This structure is neither of them - there are CPPs without H, Hs without CPP. Moreover, any given file doesn't include its dependencies (e.g. i18n doesn't include String, although it uses it).
Is there any reason for such a structure? Can it be modified to be more "compileable"? If there are no further problems I'm unaware of, it should be possible to restructure most of the source within several days (all headers with pragma once, and include all dependencies). I could try to do it, if it would work and there is no better solution. Ideally, I'd wish it were a set of headers for immediate use, but since CPP are necessary, static library is just fine.
P.S. some warnings in non-core files (e.g. no return in AddItem) do seem to be errors, no?
P.S.2 why do files in plugin folder use short includes (#include "bmp.h" and not #include "plugin/bmp/bmp.h")?
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11370 is a reply to message #11369] |
Mon, 10 September 2007 13:56 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Mon, 10 September 2007 06:25 |
I removed some unnecessary stuff from building. I also realized that there is no documentation on what file / folder is what - and that sources are uncommented.
|
That is not quite true:
http://www.ultimatepp.org/srcdoc$Core$Packages$en-us.html
While documentation lacks & lags, most of GUI stuff and Core is actually documented. However, we are using TheIDE's ability to bind rich text documentation with the code, so instead of comments it is in separate files (just press the Help button).
| Quote: |
Is there any reason for such a structure?
|
Definitely  It is the most optimal structure for very large projects.
| Quote: |
Can it be modified to be more "compileable"?
|
Do you in include path the root of package nest, in this case "uppsrc"? (like c:\upp\uppsrc ?).
| Quote: |
P.S. some warnings in non-core files (e.g. no return in AddItem) do seem to be errors, no?
|
AddItem was error, thank you, already fixed.
| Quote: |
P.S.2 why do files in plugin folder use short includes (#include "bmp.h" and not #include "plugin/bmp/bmp.h")?
|
OK. The idea is that usually, the package has the "main include", which is usually named the same as the package, e.g. CtrlLib/CtrlLib.h. Anyway, puttin all the stuff into single file would make it too big, that is why it is divided to parts.
But for .cpp files, the simplest way how to do #include is to use this main package header too.
#include "xxx.h" searches for the header in the same directory (as opposed to #include <xxx.h>) Less typing....
Mirek
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11371 is a reply to message #11360] |
Mon, 10 September 2007 15:53 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
Include stuff is interesting. Does that mean that any #include <> could be replaced with #include ""?
I didn't add to include uppsrc dir. But I don't think I should - it's also the root of the project in Code::Blocks, so compiler should be able to find whatever it needs, right? Or maybe I have to since #include <> and not #include "" is used in many sources?
I don't quite understand why such a structure is optimal for very large projects (especially if precompiled headers exist), but my problem with it is that it seems (to me, at least) incorrect. Not in terms that I don't like the style, but due to the fact that there are files (headers) that use classes/structures defined in other files (headers), without including them. t.h uses LngEntry__ defined in i18n.h without including it. i18n.h uses String class without including Core/String.h (actually i18n.h only includes the miniature t_.h, but it also uses FileOut defined in Core/Stream.h). AFAIK this means that these files are supposed to be compiled later than the files declaring classes they use, but without referencing them through include, how is the compiler supposed to know that?
It's the first time I encounter such coding style. Are there other (more simple) examples of relying on existance of classes (without explicit including)? It just doesn't seem to be correct C++ coding (does it conform to C++ standards?).
And what exactly is the problem with the classic CPP+H pairs? Just headers (like WTL) is problematic due to, well, huge headers. But why not create a pair of CPP and H for every class / several classes, include the H in the CPP, and in the H use guarding ifndefs, and include all dependencies? Any header will be included at most once, and only the necessary pairs will be used.
One more thing, does BLITZ solve all these problems by finding what needs what and placing it in the correct order? Where could I find info on BLITZ (Google thinks I'm looking for Blitz Basic).
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11374 is a reply to message #11371] |
Mon, 10 September 2007 17:17 |
Zardos
Messages: 62
Registered: April 2007
|
Member |
|
|
| sergei wrote on Mon, 10 September 2007 15:53 |
I don't quite understand why such a structure is optimal for very large projects (especially if precompiled headers exist), but my problem with it is that it seems (to me, at least) incorrect. Not in terms that I don't like the style, but due to the fact that there are files (headers) that use classes/structures defined in other files (headers), without including them. t.h uses LngEntry__ defined in i18n.h without including it. i18n.h uses String class without including Core/String.h (actually i18n.h only includes the miniature t_.h, but it also uses FileOut defined in Core/Stream.h). AFAIK this means that these files are supposed to be compiled later than the files declaring classes they use, but without referencing them through include, how is the compiler supposed to know that?
|
The trick is simple:
1.) Only .c / .cpp / ... files gets compiled.
2.) The exists a single central header filer for example. "Core.h"
3.) .cpp /.c /... files only include the central header file: Core.h
4.) .h / .hpp - files Include NO header files.
Imagine there would exists only one header file: Core.h
All cpp files only include this header file.
=> You don't have to include any other header files in a hedaer file even if you are using class and functions from other files in this header file, because these files don't get compiled. Only the cpp files and these include the central header file Core.h containing ALL classes / functions etc.
One important thing fur such a structure is the order of the included header files in Core.h, You have to include the most basic stuff not depending on other files. And step by step you climb down the dependency tree.
You don't need any include guards because, you only include each header file once in the central header file. And the other header files includes NOTHING!
After you have really understood the idea you might find the concept interesting, too. There are some obvious advantages: For example you don't have to think what you have to include in each ".h", ".cpp." files. Just include the central header in the cpp files and nothing in the header files.
This has nothing to do with BLITZ, btw.
But I prefer the "standard including style" , too
- Ralf
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11375 is a reply to message #11360] |
Mon, 10 September 2007 17:57 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
Oh, so that's what this is about. Thanks for the info. Quite similar to the approach with stdafx.h and precompiled headers in MSVC. Advantage is rather obvious, but so is the disadvantage - you take on yourself the job of defining compile order, and I'm not sure if that's easier than defining dependencies. Not sure if it affects build time (there shouldn't be any difference IMHO).
So I'll try to guess what the compiler does:
1) Pick a random CPP.
2) See that it needs Core.h, go to Core.h
3) Go from first to last include
4) For every include, define stuff in H and compile stuff in CPP
5) When done, Core.h and most CPPs will be compiled, and rest could be finished
That's the way it should work? If so, in a static lib there's no need for dummy functions in icpp, since nothing is thrown out, right?
Ok, let's see what's in Core.h:
#include <algorithm>
#include <string>
I thought U++ replaced STL with own containers...
I see that all includes are ordered, so it should've worked...
I'll try again at home, but I've found that XML.h, that is included just before Lang.h and i18n.h that I have trouble with, has #include <Core/Core.h>. XML.cpp includes "Core.h" too.
Why not add #pragma once to all H, just in case?
There are also some minor includes inside includes (like AString.hpp and t_.h), but these probably don't affect the big idea.
P.S. what's the difference between #ifdef and #if defined()? Both are used in Core.h.
P.S.2 I've found the tpp help files, is there any external viewer?
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11377 is a reply to message #11375] |
Mon, 10 September 2007 18:09 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
Sergei, .h never get compiled (in any C++ build system) and except some minor differencies (BLITZ and .icpp), U++ build system, w.r.t. compiler, is not really too different from any other build system.
C++ compiler is the same, rules for #include are defined by C/C++ standard (as are rules for #include "" vs #include <>, although these can be a little bit implementation specific).
It is therefore somewhat pointless to try to find out what "U++ compiler does", it is regular GCC or MSC compiler and it does nothing else than with any other C++ code.
My bet is that the main problem of your attempt is wrong include path.
Also, compile .c/.cpp/.icpp files only (I am not sure how codeblocks deals with .h files, if it invokes the compiler for them, you are certainly in trouble).
| Quote: |
#include <algorithm>
#include <string>
I thought U++ replaced STL with own containers...
|
Yes, that is correct, but people require certain level of compatibility. You can use STL algorithms with NTL (as long as elements satisfy STL requirements). Upp::String / Upp::WString have conversions from/to std::string.
It is MSC specific, not defined by C++ standard. Main headers use normal define guards.
.hpp files are somewhat special, using this extension for template implementation stuff. Once again, this is about dividing long headers and grouping the stuff.
"#ifdef" and "#if defined" is the same thing.
.tpp: Just click the help button. Magenta button with question mark.
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11379 is a reply to message #11375] |
Mon, 10 September 2007 18:15 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Mon, 10 September 2007 11:57 |
I've found that XML.h, that is included just before Lang.h and i18n.h that I have trouble with, has #include <Core/Core.h>. XML.cpp includes "Core.h" too.
|
This include is a sort of benign bug, it was forgoten when moving the header from development package to Core. #include guards of Core.h made it effectively a NOP....
Mirek
[Updated on: Mon, 10 September 2007 18:20] Report message to a moderator |
|
|
|
| Re: Building & using U++ without TheIDE [message #11391 is a reply to message #11360] |
Mon, 10 September 2007 20:59 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
OK, this set some things straight. So I can think of BLITZ simply as a build time optimizer.
I made some progress. I "solved" the icpp issue by adding this main.cpp file:
#include "Core/Core.h"
#include "RichEdit/RichEdit.icpp"
#include "RichText/RichImage.icpp"
#include "Web/Web_init.icpp"
#include "plugin/bmp/BmpReg.icpp"
#include "plugin/gif/gif.icpp"
#include "plugin/jpg/jpgreg.icpp"
#include "plugin/png/pngreg.icpp"
#include "plugin/tif/tifreg.icpp"
#include "PdfDraw/PdfReport.icpp"
#include "CtrlLib/CtrlLib.icpp"
#include "Geom/Ctrl/GeomCtrl_init.icpp"
#include "Core/Core_init.icpp"
#include "CtrlCore/CtrlCore.icpp"
I also set it to high priority, to force it to compile first. Some of these icpp don't include Core.h first, which might be a problem, but since Code::Blocks only compiles C and CPP, it isn't.
This yielded an error of INITBLOCK being defined twice (actually, something inside it). Sounds reasonable, same macro used in both GIF and BMP icpp-s.
Reordering includes in main.cpp to:
#include "Core/Core.h"
#include "Core/Core_init.icpp"
#include "CtrlCore/CtrlCore.icpp"
#include "CtrlLib/CtrlLib.icpp"
#include "Geom/Ctrl/GeomCtrl_init.icpp"
#include "RichText/RichImage.icpp"
#include "RichEdit/RichEdit.icpp"
#include "PdfDraw/PdfReport.icpp"
#include "plugin/bmp/BmpReg.icpp"
#include "plugin/gif/gif.icpp"
#include "plugin/jpg/jpgreg.icpp"
#include "plugin/png/pngreg.icpp"
#include "plugin/tif/tifreg.icpp"
#include "Web/Web_init.icpp"
Resulted in the old error of LngEntry__ in t.h being undefined. But that struct is defined in Core/i18n.h, which is included in Core.h. Main.cpp is the first file compiled, so Core/Core.h should've been included. Weird.
And I did add project's dir to search directories of the compiler.
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11392 is a reply to message #11391] |
Mon, 10 September 2007 21:31 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Mon, 10 September 2007 14:59 |
OK, this set some things straight. So I can think of BLITZ simply as a build time optimizer.
I made some progress. I "solved" the icpp issue by adding this main.cpp file:
#include "Core/Core.h"
#include "RichEdit/RichEdit.icpp"
#include "RichText/RichImage.icpp"
#include "Web/Web_init.icpp"
#include "plugin/bmp/BmpReg.icpp"
#include "plugin/gif/gif.icpp"
#include "plugin/jpg/jpgreg.icpp"
#include "plugin/png/pngreg.icpp"
#include "plugin/tif/tifreg.icpp"
#include "PdfDraw/PdfReport.icpp"
#include "CtrlLib/CtrlLib.icpp"
#include "Geom/Ctrl/GeomCtrl_init.icpp"
#include "Core/Core_init.icpp"
#include "CtrlCore/CtrlCore.icpp"
I also set it to high priority, to force it to compile first. Some of these icpp don't include Core.h first, which might be a problem, but since Code::Blocks only compiles C and CPP, it isn't.
|
I am really not sure what priority is, but I bet it does not matter.
| Quote: |
This yielded an error of INITBLOCK being defined twice (actually, something inside it). Sounds reasonable, same macro used in both GIF and BMP icpp-s.
|
This is caused by the fact that INITBLOCK synthetises the name of some static variable based on the line number -> by including them into the single file, you are getting them defined twice...
I think the only correct solution is to add empty Init function to .icpp file (InitPluginPng) and call it from main. And rename .icpp to .cpp...
(Alternatively, you can create helper .cpp that includes .icpp and has this function - see technology section).
| Quote: |
Resulted in the old error of LngEntry__ in t.h being undefined. But that struct is defined in Core/i18n.h, which is included in Core.h. Main.cpp is the first file compiled, so Core/Core.h should've been included. Weird.
|
What is the actual error log?
BTW, you do not have to be so much obsessed about order of including - it does not really matter, as long as you include "highest-level" header for your application.
For GUI only, #include <CtrlLib/CtrlLib.h> is all you need. If you are doing SQL GUI app, #include <SqlCtrl/SqlCtrl> is all required (will include CtrlLib.h and CtrlCore.h and Draw.h and Core.h and Sql.h...)
Mirek
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11395 is a reply to message #11360] |
Mon, 10 September 2007 22:35 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
OK, I still don't understand the purpose of icpps. Some have extra includes, some INITBLOCKS and functions. Wouldn't it be easier to make one global function like InitUpp that would do the registers, and call it in GUI_APP_MAIN? I'm working on a static lib project, so empty functions probably don't matter - nothing should be thrown out in static lib.
Priority (in Code::Blocks at least) means that this CPP will get compiled earlier than the rest. In static lib there is no main CPP which contains function main, so I prioritized main.cpp to ensure it is the first one compiled.
I actually manged to solve the Lng error (or did I?). t.h was missing NAMESPACE_UPP at top and END_UPP_NAMESPACE at bottom.
Now, next errors:
#include <TCtrlLib/TCtrlLib.h> (in Geom/Ctrl/GeomCtrl.h)
#include <TCore/TCore.h> (in Geom/Coords/GeomCoords.h)
Didn't find these files in the sources.
Then RefBase is undefined somewhere in Geom (whole package seems problematic - what is it for - IDE or something else?) - that RefBase is defined in Web/util.h - how's that related to geometry...
I removed Geom from project to see if I can continue - then I reached, once again, the INITBLOCK. Assuming I give up modularity, and want to build a single lib containing everything, except from stuff needed only for TheIDE, can I do something about the icpps? I mean, there has to be a nicer solution than using INITBLOCKS in different CPPs so they don't see each other...
P.S. the documentation is incomplete, how can I know what is used for TheIDE and what isn't? UWord uses only a small subset, e.g. Sql, Web, etc. are part of the library but aren't used.
P.S.2 what do I need to define besides PLATFORM_WIN32? DEBUG? UNICODE?
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11401 is a reply to message #11376] |
Tue, 11 September 2007 09:25 |
Zardos
Messages: 62
Registered: April 2007
|
Member |
|
|
| luzr wrote on Mon, 10 September 2007 17:57 |
| Zardos wrote on Mon, 10 September 2007 11:17 |
This has nothing to do with BLITZ, btw.
|
Well, actually, a little it has: with BLITZ it does not too much matter how much you include w.r.t. compilation speed, means the old rule "include as little as possible to keep compilation fast" is irrelevant...
Mirek
|
Ah! I see your point! I think I change my position and find the used include style pattern, great - now! 
Another advantage with BLITZ is: It might produce better code in "release mode".
I know it was written here in the forum that code produced with BLITZ is often larger than without BLITZ.
This can be considered a good thing (sometimes)! It probably means that the compilers can do more agressive inlining even on function calls that goes across different cpp files and that are not explicit declared as inline.(With BLITZ there exists basically only one file which gets compiled). Well, some compilers (MSVC) can perform "Global optimization" across different object files. But I always have some doubts if they can use the same sophisticated optimization heuristic tthey use in a single file - optimize register allocation and all these nice things.
If I remeber right on the webpage on SQLite they claim a performance improvement of some percent (10?) if it gets compiled with the "one source file" version of it.
Unfortunately BLITZ has some problems on some packages in release mode. May be a another flag "No BLITZ in release mode" would help for some projects.
- Ralf
[Updated on: Tue, 11 September 2007 09:52] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Fri Apr 26 17:41:33 CEST 2024
Total time taken to generate the page: 0.03323 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
