KDElibs/win32 merge: How to resolve followin issue..

[Jarosław Staniek]

> Jarosław Staniek wrote:
> 
>>Changing return type for subclasses, e.g. in kio/kio
>>(KServiceFactory : public KServiceFactory):
>>
>>  virtual KService * KServiceFactory::createEntry(int offset);
>>
>>...is not portable outside gcc world.
> 
> 
> That's valid and correct C++ code. Specialised return types are specified in 
> the C++ standard.
> 
> There's also the covariant specialised return types that g++ doesn't 
> support, so you won't find in our code. But that's also valid C++ code.
> 
> 
>>There are more places like this. 
>>Originally I have just changed  KService* return type back to
>>KSycocaEntry* and added static_cast<KService*> when needed (not really
>>often). This is _portable_ and relatively clean (because it's a protected
>>method, so no public API is affected), and binary compatible. Not ifdefs,
>>and doxygen docs will remain clean.
> 
> [snip]
> 
>>Is all of this reasonable for you?
> 
> 
> Maybe for this _one_ case it's ok. But it is not for all cases. I am 
> thinking of my own code:
> 
> in KPassiveSocketBase (: public KSocketBase) we have:
> 	virtual KActiveSocketBase* accept() = 0;
> in KSocketDevice (: public KActiveSocketBase, public KPassiveSocketBase) we 
> have:
> 	virtual KSocketDevice* accept();
> in KServerSocket (: public KPassiveSocketBase), we _should_ have:
> 	virtual KStreamSocket* accept();
> which doesn't work in g++ because KStreamSocket's direct inheritance goes to 
> QObject first then KActiveSocketBase, so it's actually
> 	virtual KActiveSocketBase* accept();
> 
> You are asking us to dumb down perfectly working code because one compiler 
> doesn't implement the C++ standard fully. I can appreciate the problem, but 
> I would rather prefer to find another solution.
> 
> It's already bad that we have to take into account g++'s own deficiencies 
> (not being able to add "using" inside classes, for instance, or covariant 
> return types).
> 
> Isn't there an update available for your compiler that implements those 
> things?

No, it's MSVC...: not only me use this one (v 6.0), it's quite large 
user/developer base, also in enterprises, who like to simply use kdelibs, and 
compile them in 8 minutes instead of 2 hours, debug more easily, etc. :) ... 
Update of the whole environment to v7.0+ a) isn't free, b) can affect 
compatibility with other libraries, these are main problems.

Other solution I have in mind is a definition, (who knows if not more ugly 
than the original solution):

   virtual KService_ * KServiceFactory::createEntry(int offset);

.. where KService_ is KService for non-win32, and KService_ is KSycocaEntry 
for win32. But portable code that use createEntry() will still need a 
static_cast.. So, I am still voting for the first proposal.

I am asking for real-world solution, rising the arguments about various 
implementations of C++ standard can't help here. IMHO, the code I proposed 
originally is not bloated and is mostly internal. Looking at Qt code -it has 
similar workarounds- it's a must or we end up as specialized framework...

-- 
regards / pozdrawiam,
   Jaroslaw Staniek / OpenOffice Polska
   Kexi project: http://koffice.org/kexi/ http://www.kexi-project.org/
   Qt-KDE Wrapper project: http://iidea.pl/~js/qkw/