Home » U++ Library support » U++ Library : Other (not classified elsewhere) » Building & using U++ without TheIDE
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11819 is a reply to message #11818] |
Wed, 26 September 2007 18:44   |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
| luzr wrote on Wed, 26 September 2007 18:25 |
| sergei wrote on Wed, 26 September 2007 09:13 |
I'd love a unique ID generator, but that wouldn't be portable.
|
Current implmentation IS FULLY PORTABLE. What makes it unportable is SCU. You cannot simply include everything into a single file and expect it to work - that is not 100% C/C++ compatible.
| Quote: |
P.S. I personally dislike the idea of INITBLOCK. Such code would be difficult to debug in case something goes wrong, since it executes before main. And it's scattered in the source.
|
That is the point. Module intialization is placed into the module. No action is required by client besides adding the module.
Mirek
|
I was talking about your BLITZ_INDEX__ suggestion - that would work only with BLITZ. INITBLOCK without BLITZ, is indeed portable without SCU. I agree that SCU isn't C/C++ compatible. But once it's made to work, it can be maintained relatively easily. + If code works with SCU you don't have to worry about naming if you wish to transfer some code from one file to another. But why argue? Just tell me if it's fine to change the INITBLOCKs to INITBLOCK_s like I did, or I'll have to find another way around.
I'm not against the idea that the only action required is adding the module, I actually like that. What I dislike is the code scattered among constructors. There is no easy way to go through these initializations while debugging, one by one.
I'm probably unclear, so here's my idea: create a global array of pointers to functions (get void, return void) - like 1000 cells, and an index saying how many pointers are actually stored. In INITBLOCKs, instead of doing something, the only action would be to append the initialization function to the global array (and increment index). That way, when main is started, you'll have an array with pointers to functions you have to call to initialize everything. Add a for loop there, that would initialize things. The pro is that you then can debug these initializations by stepping in during the loop. You'll also be able to do something before the initializations, in case that will ever be necessary (who knows, charset setup or something). Additionally, INITBLOCK could look like INITBLOCK(MyPkgInitFunc), and as long as the initialization function name is meaningful, it probably would be unique. MyPkgInitFunc would contain all the register stuff, and it could be debugged. Con is that you don't know how many INITBLOCKs will be, so you'll have to statically allocate a big enough array of function pointers.
|
|
|
|
| Re: Building & using U++ without TheIDE [message #11823 is a reply to message #11819] |
Wed, 26 September 2007 19:26 |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Wed, 26 September 2007 12:44 |
| luzr wrote on Wed, 26 September 2007 18:25 |
| sergei wrote on Wed, 26 September 2007 09:13 |
I'd love a unique ID generator, but that wouldn't be portable.
|
Current implmentation IS FULLY PORTABLE. What makes it unportable is SCU. You cannot simply include everything into a single file and expect it to work - that is not 100% C/C++ compatible.
| Quote: |
P.S. I personally dislike the idea of INITBLOCK. Such code would be difficult to debug in case something goes wrong, since it executes before main. And it's scattered in the source.
|
That is the point. Module intialization is placed into the module. No action is required by client besides adding the module.
Mirek
|
I was talking about your BLITZ_INDEX__ suggestion - that would work only with BLITZ.
|
Why? You can use it in any SCU system. Actually, it just makes U++ sources more usable with SCU approach.
| Quote: |
But once it's made to work, it can be maintained relatively easily.
|
Once you create some release system, it can be as easily maintained as it is.
| Quote: |
Just tell me if it's fine to change the INITBLOCKs to INITBLOCK_s like I did, or I'll have to find another way around.
|
Well, I wanted to tell you that I am not going to avoid this feature (I mean, unnamed INITBLOCK) only because of SCU experiment. Means, I do not have a problem with it, but expect to fix these for each release...
| Quote: |
There is no easy way to go through these initializations while debugging, one by one.
|
Maybe not one by one, but breakpoints still work....
| Quote: |
I'm probably unclear, so here's my idea: create a global array of pointers to functions (get void, return void) - like 1000 cells, and an index saying how many pointers are actually stored. In INITBLOCKs, instead of doing something, the only action would be to append the initialization function to the global array (and increment index). That way, when main is started, you'll have an array with pointers to functions you have to call to initialize everything.
|
Actually, that is exactly how global constructors (and therefore INITBLOCKs) are implemented 
| Quote: |
Add a for loop there, that would initialize things. The pro is that you then can debug these initializations by stepping in during the loop. You'll also be able to do something before the initializations, in case that will ever be necessary (who knows, charset setup or something). Additionally, INITBLOCK could look like INITBLOCK(MyPkgInitFunc), and as long as the initialization
function name is meaningful, it probably would be unique.
|
Yes, great. So instead of calling initializations directly, we will have an array of functions (global constructors). This array will be performed by C++ runtime to create another array of functions and that one will be performed in main?
Also, if you need to do something more, you simply cannot use INITBLOCK.
Mirek
|
|
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #12054 is a reply to message #11831] |
Tue, 09 October 2007 19:14 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
| luzr wrote on Wed, 26 September 2007 22:56 |
| sergei wrote on Wed, 26 September 2007 15:01 |
OK, never mind...
I'll just add BLITZ_INDEX defines everywhere.
Did the other changes (like IsLeapYear) make it into the main source?
|
Working on it... But majority is INITBLOCK anyway...
Mirek
|
I see that 710dev1 is released, but AFAIK most of my proposed changes weren't applied  Nevermind the INITBLOCKs, but why the other changes didn't make it?
I didn't have time yet to thoroughly test it, but these changes seem to still apply:
Info:
Packages coff/uar/uld/uar.upp and Geom/Coords/Ctrl/Ctrl.upp should be removed from source tree.
Core:
TimeDate.cpp - Removed #define IsLeapYear.
TimeDate.h - Added #define IsLeapYear since it has to be visible is CtrlLib/DateTimeCtrl.
z.cpp - removed enum, ASCII_FLAG, HEAD_CRC, EXTRA_FIELD, ORIG_NAME, COMMENT, RESERVED already defined in plugin/z,
GZ_MAGIC1, GZ_MAGIC2 were replaced with gz_magic[0], gz_magic[1] defined in plugin/z.
CtrlLib:
DateTimeCtrl.h - commented IsLeapYear function - already #defined in Draw/TimeDate.
Draw:
MetaFile.cpp - IsClipboardFormatAvailable replaced with ::IsClipboardFormatAvailable to resolve naming conflict.
Palette.cpp - BINS, BINSHIFT replaced with palBINS, palBINSHIFT to resolve naming conflict with BINS in Core/lheap.
Esc
Esc.h - #ifndef/#define ESC_H replaced with _ESC_H_ to resolve naming conflict with plugin/pcre.
GridCtrl:
GridCtrl.upp - reordered files to ensure first file is the main header of the package.
(something was changed about LG, might/might not work now)
PdfDraw:
PdfDraw.upp - removed Test.cpp - test program, not part of the package.
RichEdit:
Find.cpp - ReplaceText() renamed to ReplacementText() to resolve naming conflict with Win32 API function.
RichEdit.h - ReplaceText() renamed to ReplacementText() to resolve naming conflict with Win32 API function.
plugin/png:
png.h - marked modification.
pngread.c - added casts.
pngrutil.c - added casts.
pngset.c - added casts.
plugin/jpg:
Whole plugin rework.
Appended filename to functions marked LOCAL to resolve naming conflicts.
Added include guards.
Modified #define/typedef names to resolve naming conflicts.
plugin/z:
Whole plugin rework. Updated to version 1.2.3.
Changed function declarations from K&R to ASNI C style.
Added include guards.
Modified #define/typedef names to resolve naming conflicts.
Though I'm really glad to see unicode (W versions) implemented so quickly. I'll try my unicode files/registry test later.
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #12067 is a reply to message #12054] |
Wed, 10 October 2007 00:02 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Tue, 09 October 2007 13:14 |
Info:
Packages coff/uar/uld/uar.upp and Geom/Coords/Ctrl/Ctrl.upp should be removed from source tree.
Core:
TimeDate.cpp - Removed #define IsLeapYear.
TimeDate.h - Added #define IsLeapYear since it has to be visible is CtrlLib/DateTimeCtrl.
CtrlLib:
DateTimeCtrl.h - commented IsLeapYear function - already #defined in Draw/TimeDate.
Draw:
MetaFile.cpp - IsClipboardFormatAvailable replaced with ::IsClipboardFormatAvailable to resolve naming conflict.
Palette.cpp - BINS, BINSHIFT replaced with palBINS, palBINSHIFT to resolve naming conflict with BINS in Core/lheap.
Esc
Esc.h - #ifndef/#define ESC_H replaced with _ESC_H_ to resolve naming conflict with plugin/pcre.
GridCtrl:
GridCtrl.upp - reordered files to ensure first file is the main header of the package.
(something was changed about LG, might/might not work now)
PdfDraw:
PdfDraw.upp - removed Test.cpp - test program, not part of the package.
|
Above are used.
| Quote: |
RichEdit:
Find.cpp - ReplaceText() renamed to ReplacementText() to resolve naming conflict with Win32 API function.
RichEdit.h - ReplaceText() renamed to ReplacementText() to resolve naming conflict with Win32 API function.
|
I see no naming conflict; it is a method, not a global function. Well, it might get macro-replace with ReplaceTextA, but who cares?
| Quote: |
plugin/png:
png.h - marked modification.
pngread.c - added casts.
pngrutil.c - added casts.
pngset.c - added casts.
plugin/jpg:
Whole plugin rework.
Appended filename to functions marked LOCAL to resolve naming conflicts.
Added include guards.
Modified #define/typedef names to resolve naming conflicts.
Core
z.cpp - removed enum, ASCII_FLAG, HEAD_CRC, EXTRA_FIELD, ORIG_NAME, COMMENT, RESERVED already defined in plugin/z,
GZ_MAGIC1, GZ_MAGIC2 were replaced with gz_magic[0], gz_magic[1] defined in plugin/z.
plugin/z:
Whole plugin rework. Updated to version 1.2.3.
Changed function declarations from K&R to ASNI C style.
Added include guards.
Modified #define/typedef names to resolve naming conflicts.
|
Is it really that good idea to change 3rd party code?
Mirek
|
|
|
|
| Re: Building & using U++ without TheIDE [message #12068 is a reply to message #12067] |
Wed, 10 October 2007 00:51 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
| Quote: |
Well, it might get macro-replace with ReplaceTextA, but who cares?
|
Exactly. ReplaceText is a macro and thus doesn't care what is a global function and what isn't. In my case it replaced it with ReplaceTextA, instead of using method, in this call for example: Insert(cursor, ReplaceText(), false);
| Quote: |
Is it really that good idea to change 3rd party code?
|
Not as a general rule. But U++ 3rd party plugins are mostly under BSD-style license, so, unlike GPL, there should be absolutely no problems modifying it (that's the point of BSD, isn't it). + Last zlib release is from 2005, jpeg from 1998, so it's rather unlikely any of them will be changed anytime soon (ever?). Thus IMHO modifying these two shouldn't be a problem - one time change and that's it. While SCU reasoning probably won't appeal to you, I'll note that some modifications were also due to non-C++ code (K&R style, missing casts, use of this as variable name, defines conflicting with code in other packages).
Some other libraries (tiff, png) are still maintained, these should be examined each. PNG should be used IMHO since the modifications are merely casts required by C++ but not by C. TIFF and others, I haven't checked yet.
Some "tough" libraries like sqlite could possibly be built as a separate lib. For non-core plugins (like zlib) this makes sense - every time such a library is updated, plugin could be rebuilt. Can TheIDE use libs internally?
P.S. Checked unicode on files, works out of the box  Now U++ has 99% unicode support (except for surrogate pairs).
|
|
|
|
| Re: Building & using U++ without TheIDE [message #12107 is a reply to message #12068] |
Thu, 11 October 2007 05:40 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Tue, 09 October 2007 18:51 |
| Quote: |
Well, it might get macro-replace with ReplaceTextA, but who cares?
|
Exactly. ReplaceText is a macro and thus doesn't care what is a global function and what isn't. In my case it replaced it with ReplaceTextA, instead of using method, in this call for example: Insert(cursor, ReplaceText(), false);
|
As macro, it should be substituted
Insert(cursor, ReplaceTextA(), false);
But the method name is ReplaceTextA() too...
I just wonder, was it some real problem to solve?
| Quote: |
P.S. Checked unicode on files, works out of the box Now U++ has 99% unicode support (except for surrogate pairs).
|
Well, I am afraid there are more details to care about... But time will tell  (also, network names are not unicode(d) yet, but in fact, NetNode is not yet used anywhere).
Mirek
|
|
|
|
| Re: Building & using U++ without TheIDE [message #12164 is a reply to message #12107] |
Mon, 15 October 2007 00:35 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
| luzr wrote on Thu, 11 October 2007 05:40 |
| sergei wrote on Tue, 09 October 2007 18:51 |
| Quote: |
Well, it might get macro-replace with ReplaceTextA, but who cares?
|
Exactly. ReplaceText is a macro and thus doesn't care what is a global function and what isn't. In my case it replaced it with ReplaceTextA, instead of using method, in this call for example: Insert(cursor, ReplaceText(), false);
|
As macro, it should be substituted
Insert(cursor, ReplaceTextA(), false);
But the method name is ReplaceTextA() too...
I just wonder, was it some real problem to solve?
Mirek
|
Purely compilation problem. ReplaceText() is a member function. ReplaceText is a macro expanding to ReplaceTextA. In the Insert call, the member function call was supposed to be executed but actually the macro was used, and thus ReplaceTextA. Since signatures didn't match - compilation error. My suggested solution was to call member function ReplacementText(), or maybe call it explicitely (this->ReplaceText()).
|
|
|
|
| Re: Building & using U++ without TheIDE [message #12169 is a reply to message #12164] |
Mon, 15 October 2007 07:27 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| sergei wrote on Sun, 14 October 2007 18:35 |
| luzr wrote on Thu, 11 October 2007 05:40 |
| sergei wrote on Tue, 09 October 2007 18:51 |
| Quote: |
Well, it might get macro-replace with ReplaceTextA, but who cares?
|
Exactly. ReplaceText is a macro and thus doesn't care what is a global function and what isn't. In my case it replaced it with ReplaceTextA, instead of using method, in this call for example: Insert(cursor, ReplaceText(), false);
|
As macro, it should be substituted
Insert(cursor, ReplaceTextA(), false);
But the method name is ReplaceTextA() too...
I just wonder, was it some real problem to solve?
Mirek
|
Purely compilation problem. ReplaceText() is a member function. ReplaceText is a macro expanding to ReplaceTextA. In the Insert call, the member function call was supposed to be executed but actually the macro was used, and thus ReplaceTextA. Since signatures didn't match - compilation error. My suggested solution was to call member function ReplacementText(), or maybe call it explicitely (this->ReplaceText()).
|
Sorry, I still do not get it.
ReplaceText is defined by Win32 as ReplaceTextA. EVERYWHERE. Means in .h too.
Therefore, the method name, after macro replacement, is ReplaceTextA too. Call is to ReplaceTextA.
Means signatures DO MATCH.
(Note that this obviously compiles without a problem with TheIDE).
Mirek
|
|
|
|
| Re: Building & using U++ without TheIDE [message #12173 is a reply to message #12169] |
Mon, 15 October 2007 10:48 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
[quote title=luzr wrote on Mon, 15 October 2007 01:27]| sergei wrote on Sun, 14 October 2007 18:35 |
| luzr wrote on Thu, 11 October 2007 05:40 |
| sergei wrote on Tue, 09 October 2007 18:51 |
| Quote: |
Well, it might get macro-replace with ReplaceTextA, but who cares?
|
Exactly. ReplaceText is a macro and thus doesn't care what is a global function and what isn't. In my case it replaced it with ReplaceTextA, instead of using method, in this call for example: Insert(cursor, ReplaceText(), false);
|
As macro, it should be substituted
Insert(cursor, ReplaceTextA(), false);
But the method name is ReplaceTextA() too...
I just wonder, was it some real problem to solve?
Mirek
|
Purely compilation problem. ReplaceText() is a member function. ReplaceText is a macro expanding to ReplaceTextA. In the Insert call, the member function call was supposed to be executed but actually the macro was used, and thus ReplaceTextA. Since signatures didn't match - compilation error. My suggested solution was to call member function ReplacementText(), or maybe call it explicitely (this->ReplaceText()).
|
Ah, I think I know where the problem is. I beleive it is your ruthless SCU approach again - if I preprocess that file in theide, I do not even get ReplaceTextA, because corresponding Win32 header is not included at global level.
Mirek
|
|
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #12204 is a reply to message #12199] |
Wed, 17 October 2007 21:58 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
| luzr wrote on Wed, 17 October 2007 19:12 |
| sergei wrote on Mon, 15 October 2007 06:18 |
That's because you use MSVC, where you include Windows' stuff separately. In MinGW, you include <windows.h> and thus the macro's defined.
|
Nope, in MinGW, it stays "ReplaceText". ReplaceTextA is defined in "Commdlg.h" - and that is not visible in RichText.
The real trouble is perhaps the Commdlg.h in your SCU is included AFTER RichEdit.h but BEFORE RichText RichEdit::ReplaceText().
If it would be included before RichEdit.h, everything would work too - both occurences of ReplaceText, in the header and in the .cpp would replaced by ReplaceTextA....
Mirek
|
Aha... there had to be a reason why it worked in TheIDE 
Indeed in SCU RichEdit.h is included way before Find.cpp (which uses ReplaceText). And using MinGW in TheIDE, it doesn't stay ReplaceText, it becomes ReplaceTextA in both places (so I guess whatever defined ReplaceText macro got included earlier), and thus works.
Any chance you fix that (rename the method)?
|
|
|
|
|
|
| Re: Building & using U++ without TheIDE [message #12206 is a reply to message #12205] |
Thu, 18 October 2007 01:34 |
sergei
Messages: 94
Registered: September 2007
|
Member |
|
|
| luzr wrote on Wed, 17 October 2007 22:54 |
| sergei wrote on Wed, 17 October 2007 15:58 |
Any chance you fix that (rename the method)?
|
No.
IMO, you require me to fix the code to compile using unstandard broken method. I do not see that as bright idea. You can break the compilation in many ways. Should I fix the code to support them all?
Maybe you should rather think about fixing the build system...
Mirek
|
So far, not many things got wrong... AFAIK this is the last one, excluding C (non-C++ plugins). And they all were at least slightly unusual - using macro as function name, using an API function as a member function, having 2 equal enum members in different enums. You have used code to fix MSVC6 bugs - to support non-standard behavior. But I'm not MS
Your BLITZ approach isn't standard either. It's used, because it works, and because it has its benefits - speed. I wouldn't use SCU, if I didn't see how great BLITZ's benefits are - it's like edit-and-continue for library modifications. My SCU approach isn't much different. It's an attempt to mimic BLITZ behavior. Not a perfect attempt, I agree. I used a different include order (first all headers, then all CPPs) than BLITZ (for each package, first header, then CPPs), and that was the reason for ReplaceText problem.
But it looks like you treat SCU as non-standard and BLITZ as "just fine" - it isn't so. They are slightly different speed-up solutions. BLITZ is smarter regarding macros, but it's still SCU. In a.cpp write int MyVar, in b.cpp write float MyVar. In standard C++ this would compile (variables are local), but both in BLITZ and SCU this would fail. I might be wrong, but I don't think you intended ReplaceText member function to be substituted with ReplaceTextA in all places - this sound like something that can potentially break compilation (like if you define another ReplaceTextA function thinking it's a different one). Something else might work with my SCU but not BLITZ (like using #defines from a header in CPP from another package) - neither good nor intended.
I can change include order in my SCU to make it resemble BLITZ even more, yet this won't make neither SCU nor BLITZ standard.
Fixing the build system does sound more reasonable regarding C plugins. These indeed could be a time-bomb in SCU, especially the updating ones. Except for zlib (which works and is a vital part of Core), others could be packaged as libs (3rd party plugins are usually lib-friendly). That shouldn't be bad for BLITZ too.
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Apr 19 18:44:39 CEST 2024
Total time taken to generate the page: 1.01663 seconds
|
Members
Pages
Help
Register
Login
Home
