Re: Libsigc++ for KDE/Qt

[Mosfet <mosfet jorsm com>]

You didn't answer the question... You said the identifers used by Qt hurt it's
portability. I listed all the systems Qt runs on and asked you to identify a
Unix (or Windows) system where the identifers conflict. I don't think you will
be able to. As far as to what systems KDE runs on, I personally know users using
on on HPUX 10.20, Digital Unix 4.0B, Solaris, and FreeBSD as well as Linux.

I can sympathize with your artistic values, but they do not affect Qt
portability in any way and I kindly ask you to stop claiming they do.

On Sun, 29 Aug 1999, Karl Nelson wrote:
> >Sorry but this is pure FUD. I think you are listening to Nathan Myers too
> >much ;-) Just because Qt defines the signal and slot identifiers does not hurt
> >portability at all. Here is a list of platforms QT runs on and is commercially
> >supported (including Windows):
> 
> Well that is a rather regretable position.  C++ libraries should
> as good citizens take only from their namespace.  Just because one
> can get away with it by delaying including ones header does not
> change the issue.  If I wanted to have lots of macros, I
> would go code in C for GNOME. ;-)
> 
> The one that most bothers me is the emit definition.  There
> is no reason to take a word out just to look pretty.  If the KDE 
> crew would just be so kind as doing a "sed '/emit //g'"  on all the 
> files it would be a good start.  (At least that way people
> could make full used of libsigc++ and Qt at the same time.)
> 
> I understand the signals/slots being needed by the 
> code generator, but emit does not appear anywhere in the code generator
> thus is a pointless code definition.
> 
> 
> Tell me which looks like a function call to you?
> 
> int F::foo()
>   {
>     emit sig();
>   }
> 
> Compared to this.
> 
> int F::foo()
>   {
>     sig();
>   }
> 
> What difference did the emit make?  NONE. :-(  KDE should remove
> emit so that such a useless definition does not propogate.  Tell
> the people at Troll that you don't need useless words to pretty up
> the code.  This is my opinion not Nythan Myers, I stated it
> independently of him a month ago.  Whether it is a portablity
> issue or not, it is just good C++ citizenship.
> 
> As one of the largest open source C++ projects should you
> not try to set a good example?
> 
> [...]
> >So, now can you point me to *any* system where these identifiers hurt
> >portability? I think not.
> 
> Great, but libsigc++ can be made to run on all those systems as well.
> including the Windows.  (Currently, I don't support some due to lack 
> of time, but should someone care to pay me to get them running 
> on those systems it would not be a problem.  You can't honestly think 
> that anyone compiles with HP cc. ;-)  You are skirting the issue at hand
> by assuming that libsigc++ is less portable than Qt. In truth libsigc++
> could run where ever KDE wanted it to.    
> 
> Name some platform which represents a reasonable fraction of your users 
> in which libsigc++ can't be ported and KDE does then portablity may be 
> an issue.  
> 
> I am not trying to flame you but, having those macros does
> make it less portably with other C++ libraries including 
> my own.  Nythan may be exagerating, but it is not pure FUD.
> 
> --Karl
-- 
Daniel M. Duley - Unix developer & sys admin.
mosfet@mandrakesoft.com
mosfet@kde.org
mosfet@jorsm.com