U++ forum: Welcome to the forum

Search on this site

Search in forums

Home » U++ Library support » U++ Core » Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined.

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined. [message #16423]

Fri, 13 June 2008 21:33

Novo
Messages: 1358
Registered: December 2006

Ultimate Contributor

In such situation MK__s is defined as:

#define MK__s MK__s_(__LINE__)

And that means that INITBLOCK must always be put on lines with different line numbers (not just in one file, but in all files).
Otherwise INITBLOCK will produce functions having the same name, and as a result duplicate symbol names.

This issue prevents me from compiling of U++ using MSVC project files. (Have no idea how TheIDE does that.)

I�ve tried to improve INITBLOCK using __COUNTER__ macro, but couldn�t succeed in that.

Regards,
Novo

[Updated on: Fri, 13 June 2008 22:13]

Report message to a moderator

Re: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined [message #16441 is a reply to message #16423]

Sun, 15 June 2008 19:18

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

INITBLOCK creates static variables, these should not be visible outside the file compiled (as long files are not combined using BLITZ - and that is why there is that crazy workaround).

Mirek

Report message to a moderator

Re: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined [message #16444 is a reply to message #16441]

Mon, 16 June 2008 06:05

Novo
Messages: 1358
Registered: December 2006

Ultimate Contributor

luzr wrote on Sun, 15 June 2008 13:18

INITBLOCK creates static variables, these should not be visible outside the file compiled (as long files are not combined using BLITZ - and that is why there is that crazy workaround).

Mirek

And this workaround is working fine with UPP build system. But this approach is not working with init-files. I do not have a self-explanatory test case right now, but I'll try to prepare one.

Regards,
Novo

Report message to a moderator

Re: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined [message #16448 is a reply to message #16444]

Mon, 16 June 2008 10:38

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

Hm, I guess you are right... no need for testcase. Ops Smile

(Mentioning "init" would bring me to this conclusion much sooner Smile

.

Have to think about this. I guess we will have to introduce some unique identifier to init. Either GUID based or derived from file path.

Mirek

Report message to a moderator

Re: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined [message #16471 is a reply to message #16448]

Tue, 17 June 2008 09:33

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

OK, I have done this:

In Defs.h:

#ifdef  BLITZ_INDEX__
#define MK__s            MK__s_(COMBINE3(BLITZ_INDEX__, _, __LINE__))
#else
#define MK__s            MK__s_(__LINE__)
#endif

(replaced #ifdef flagBLITZ -> #ifdef BLITZ_INDEX__)

and then changed theide so that typical init file looks like this:

#ifndef _CtrlLib_icpp_init_stub
#define _CtrlLib_icpp_init_stub
#include "CtrlCore/init"
#include "RichText/init"
#include "PdfDraw/init"
#define BLITZ_INDEX__ F16649F474E89066DCB3F468E96F1D0DD
#include "CtrlLib.icpp"
#undef BLITZ_INDEX__
#endif

Mirek

Report message to a moderator

Re: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined [message #31810 is a reply to message #16471]

Tue, 29 March 2011 13:10

kohait00
Messages: 939
Registered: July 2009
Location: Germany

Experienced Contributor

this is still an issue though..

using MSC optimal, which may not use BLITZ, we end up with broken INITBLOCKs..because no index. compiling MSC9 with BLITZ my app works, with optimal and thus without BLITZ the app doesnt.

any idea how to make this work?

BTW: at which point the init files are used? in the ide oder somewhere in the code?

EDIT: in another thread i found that init files are only used with BLITZ, is that right? so thats why no BLITZ_INDEX__ to meangle the static names

but i still wonder, why it doesnt work, if the problem described in the thread only arised with blitz..and i am needing blitz to make it work..sth is weired here

[Updated on: Tue, 29 March 2011 14:06]

Report message to a moderator

Re: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined [message #31811 is a reply to message #31810]

Tue, 29 March 2011 14:12

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

kohait00 wrote on Tue, 29 March 2011 07:10

The most common cause is that linker excludes the file completely.

That is why we have introduced .icpp.

Is this the case?

Report message to a moderator

Re: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined [message #31813 is a reply to message #31811]

Tue, 29 March 2011 14:59

kohait00
Messages: 939
Registered: July 2009
Location: Germany

Experienced Contributor

thanks mirek, for the hint.

searched a bit in forum, seems i found sth related. please verify, this might / should go to documentation.

i've got some custom init code in a package, packed into a INITBLOCK, this all resides in a cpp file with appearently no referencing from other code, simple global/static init code.

did work with BLITZ, on both MSC and GCC in debug compile however in release, MSC didnt work, since i had to turn off BLITZ. with gcc it also only works with BLITZ enabled. so turning off BLITZ may possibly break INITBLOCK sections in one's app.

solution: i renamed the cpp file with the INITBLOCK code into .icpp file and woops, it works in MSC optimal without blitz. this assures the cpp file wont get kicked out by linker, since its code is not referenced by anything from another code section in app.

is this a general behaviour? can it be considered rule of thumb to rename the INITBLOCK containing cpp file to icpp file, if there is nothing in the file which will guarantee it's presence in linker later, like i.e. referenced code. if so, maybe this should be outlined somewhere in the docu

hints in: http://www.ultimatepp.org/forum/index.php?t=msg&goto=811 8&

[Updated on: Tue, 29 March 2011 15:28]

Report message to a moderator

Re: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined [message #31935 is a reply to message #31813]

Fri, 08 April 2011 23:31

mirek
Messages: 13975
Registered: November 2005

Ultimate Member

kohait00 wrote on Tue, 29 March 2011 08:59

is this a general behaviour? can it be considered rule of thumb to rename the INITBLOCK containing cpp file to icpp file, if there is nothing in the file which will guarantee it's presence in linker later, like i.e. referenced code. if so, maybe this should be outlined somewhere in the docu

Well,

1) you have to aware about hits regardless INITBLOCK, because it affects all global initialization code (read: global constructors)

2) I can imagine situation where you want to put INITBLOCK into .cpp as well, with current behaviour

Report message to a moderator

Re: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined [message #31947 is a reply to message #31935]

Sun, 10 April 2011 16:18

kohait00
Messages: 939
Registered: July 2009
Location: Germany

Experienced Contributor

that's right. maybe to place it as 'caveats' or 'pitfalls' or common mistakes Smile

in the manual..

Report message to a moderator

Re: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined [message #31954 is a reply to message #31947]

Mon, 11 April 2011 11:14

cbpporter
Messages: 1401
Registered: September 2007

Ultimate Contributor

A small question: I have never had problems with INITBLOCK and I always use it in CPPs to initialize data. Should I be rather using ICPPs? What are the more specific rules?

Report message to a moderator

Re: Incorrect implementation of INITBLOCK (and similar macros) in case when flagBLITZ is not defined [message #31956 is a reply to message #31954]

Mon, 11 April 2011 11:59

kohait00
Messages: 939
Registered: July 2009
Location: Germany

Experienced Contributor

well thats exacltly the question/problem.

as long as your INITBLOCK EXITBLOCK stuff resides in a cpp file which is actually used (the code is referenced somewhere) the linker will link it. if the INITBLOCK EXITBLOCK is the only thing in a cpp file, no more other code, it will be dropped by the linker. since there is no code referenced by some oder code.

the stuff in INITBLOCK actually registers itself in a init facility from upper code.. so no code ref downwards exists. such files should be icpp files.

as mirek stated out, this is a general problem, that has to be taken in account.

Report message to a moderator