[Kde-windows] KDE/kdelibs/win

[Ralf Habacker]

> 
> >>>>>>>>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....

What would be the result ? Do you have a better implementation ? 
 
> > //--->
> >   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
Ralf