[Qt-interest] Qt-interest Digest, Vol 11, Issue 168

[master.of.brainless.things at gmx.net]

i hope i'm not annoying here anyone to much, but qt-support's just makeing me confused.

> There have been no changes to the way Qt is compiled, one way or another.  

ok, than visual studio 2008 just prints warnings of using /clr without _fastcall option but _stdcall,
and that this might lead to problems cause qt uses _fastcall.
so this is no problem?

>   
> > so, as a user of the commercial qt version, now compiled with _fastcall
> >  things, and support option for this qt version,
> > i'm not anymore able to call qt methods from .net code?  
> 
> Qt is C++, so 99% of its methods are technically "__thiscall"
>   

i must confess, that i successfully programmed c++ 
without knowing how the compiler makes binaries of it, till now, at least not well enough.
so what i've read is, that the compiler is using other technics
for parameter passing when using _fastcall as when using _stdcall.
so you say, when i've a dll compiled with _fastcall methods, 
my header methods - using _stdcall due to /clr - will still work perfect?

another thing is that a qt-support person told us, qt doesn't support .net.
and that qt is now compiled with _fastcall, and that, if we want to use /clr, 
we would have to recompile whole qt with an option: QT_FASTCALL set to _stdcall in corelib/global/qglobal.h.
_fastcall is used by qchar since 4.3.5.
but after all, clr would not be supported and the qt-support couldnt garantee that this would work than.

i'm a little confused about the _fastcall/_stdcall mechanisms by now, but i think they are incompatible.
so qchar using _fastcall methods in my dll would lead to big problems using /clr and with it _stdcall convention on qchar methods.
or will the compiler handle this at compile time, and therefore no problems will exist at runtime using the _fastcall'ed qt-dll?

with kind regards && thx for reading...
alex
--