[Kde-windows] KDE/kdelibs/win

[Jarosław Staniek]

Ralf Habacker said the following, On 2005-10-18 10:17:


>>>>>>>>BTW2: I think that there is a better way to create pre/after main
>>>>>>>>functions. You can create a class and create a global instance of
>>>>>>>>this. This instance will be created and the constructor be called
>>>>>>>>before main.
>>>>>>>>
>>>>>>>>
>>>>>>>>#include <stdio.h>
>>>>>>>>
>>>>>>>>class KDEbootstrap {
>>>>>>>>public:
>>>>>>>>	KDEbootstrap();
>>>>>>>>	~KDEbootstrap();
>>>>>>>>};
>>>>>>>>
>>>>>>>>
>>>>>>>>KDEbootstrap::KDEbootstrap()
>>>>>>>>{
>>>>>>>>	printf("bootstrap created\n");
>>>>>>>>	// stuff called before main
>>>>>>>>}
>>>>>>>>
>>>>>>>>KDEbootstrap::~KDEbootstrap()
>>>>>>>>{
>>>>>>>>	printf("bootstrap delete\n");
>>>>>>>>	// stuff called after main
>>>>>>>>}
>>>>>>>>
>>>>>>>>KDEbootstrap bootstrap;
>>>>>>>
>>>>>>>We dont want to require devs to put
>>>>>>>
>>>>>>>KDEbootstrap bootstrap;
>>>>>>>
>>>>>>>into application code (e.g. main.cpp).
>>>>>>>
>>>>>>>
>>>>>>>So where do you want to put it? My candidate could be KInstance....
>>>>>>
>>>>>>See the updated bootsrap.cpp (kde_bootstrap() may be directly included
>>>>>>into the constructor and kde_destroy() in the destructor)
>>>>>
>>>>>First, read dfaure answer - existing solution doesn't break anything:
>>>>>developers cannot see a difference...
>>>>>
>>>>>Now note it's dangerous to rely on static members destruction: you never
>>>>>know in which order destructors are called. With kdemain() it's always
>>>>>deterministic. SO here I'd vote for not using KDEbootstrap object, unles
>>>>>you know something annoing our devs..
>>>>
>>>>The testcase below illustrate the recent implementation, showing that
>>>>kde_bootstrap will be called after all global object instantiation, which
>>>>will be to late and kde_destroy() before all global object destruction.
>>>>
>>>>TestClass stands for any external class, whch has global objects. They
>>>>are initialised before main().  kde_bootstrap() setup a env var like the
>>>>recent implementation setting HOME. If you compile and run the testcase,
>>>>the env var in
>>>>TestClass::TestClass() isn't set.
>>>>
>>>>I have appended  another testcase (c++constructor-order.zip), which shows
>>>>the ordering of global constructor and destructor.
>>>>on mingw constructors are called in reverse order and destructors in
>>>>normal order based on the file sequence.
>>>>
>>>>C:\Daten\kde4\kdelibs\test\constructor>scons
>>>>scons: Reading SConscript files ...
>>>>win32
>>>>win32
>>>>scons: done reading SConscript files.
>>>>scons: Building targets ...
>>>>g++ -o first.o -c first.cpp
>>>>g++ -o main.o -c main.cpp
>>>>g++ -o second.o -c second.cpp
>>>>g++ -o third.o -c third.cpp
>>>>g++ -o test.exe first.o second.o third.o main.o
>>>>scons: done building targets.
>>>>
>>>>C:\Daten\kde4\kdelibs\test\constructor>test
>>>>ThirdClass created (null)
>>>>SecondClass created (null)
>>>>FirstClass created (null)
>>>>main
>>>>FirstClass deleted
>>>>SecondClass deleted
>>>>ThirdClass deleted
>>>
>>>This let me assume, that using a global object in kdewin32, which will be
>>>the last library on the link line, would be run first
>>>
>>>Any infos about msvc order  ?
>>
>>No idea *in general* and that's why the macro exists...
> 
> 
> Have you compiled the constructor test application with msvc ? This will 
> report how msvc handles this stuff.

FirstClass created (null)
SecondClass created (null)
ThirdClass created (null)
main
ThirdClass deleted
SecondClass deleted
FirstClass deleted

...you never know how, say ICC, or other compilers will do that unless test them.

>>>BTW: If the global object ordering will be a problem on other compilers,
>>>a complete other approach for problems like the HOME env var on windows
>>>95 is to redefine the getenv() function and do the required
>>>initialisation on the first call. This  will be independent off any
>>>global objects and it is guarantated that HOME will be set before.
>>
>>Could you help with this one?
> 
> of course. ;-) 
> 
> Please add the HOME related code from bootstrap.cpp to kde_getenv 
> win/getenv.c.  Additional redirect original getenv definition to kde_getenv()  
> in include/msvc/stdlib.h 
> 
> Regards 
> Ralf 
> 
> 
> 
> int kde_init_getenv()
> {
> 	if (osver.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS) {
> 		// stuff from bootstrap.cpp 
> 	}
> 	return 1; 
> }
> 
> 
> KDEWIN32_EXPORT char * kde_getenv(const char *name)
> {
>   char dummy[1];
>   int len;
>   char *p;
> //<--- 
>   static init = 0; 
>   if (!init) 
>     init = kde_init_getenv();


^^^^^^^^^^^^^
This would be good because improved startup speed, but needs to be fixed 
because is not thread safe....

> //--->
>   if (!name)
>     return 0;
>   len = GetEnvironmentVariableA(name, dummy, 0);
>   if (len == 0)
>     return 0;
> 
>   len++;
>   // NOTE: This creates a memory whole, because it will never be free'd 
>   //       better use a static char vector 
>   p = malloc(len);
>   if (GetEnvironmentVariableA(name, p, len))
>     return p;
> 
>   free(p);
>   return 0;
> }

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska
  Kexi Developer:
      http://www.kexi-project.org | http://koffice.org/kexi
  KDE3, KDE4 libraries for developing MS Windows applications:
      http://wiki.kde.org/tiki-index.php?page=KDElibs+for+win32