Re: Libsigc++ for KDE/Qt

[Karl Nelson <kenelson ece ucdavis edu>]

>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