Re: Libsigc++ for KDE/Qt

[Karl Nelson <kenelson ece ucdavis edu>]

> 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 wil
> l
> be able to. As far as to what systems KDE runs on, I personally know users us
> ing
> 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.

Okay, maybe "portablity" is not the right word, but "being a bad
C++ citizen" is a rather long and subjective thing.  I should
say that "Qt has poor code intercoperabity with other libraries due to  
unnecessary macros.  It risks header conflicts with headers of
as systems, but the problem is very unlikely and not yet realized.
Such macros where they are not necessary should be removed.
Libsigc++ has no header portablity problems resulting from macros,
but may be less portable as a result of poor support for templates 
on some compilers."  I consider these to be fair statements. 

Honestly though, insisting they don't have header conflicts problems because
the list of compilers one compiles it on hardly proves your point 
conclusively. Here is a program with some serious portablity problems that 
compiles on all those systems.
--------------------------------------------------------------
typedef char* wchar;
#define dest printf 
#define rgbmap
 
int alrm(wchar getstr,int rgbmap max)
  {
   int nz;
   for (nz=0;nz<max;nz++)
     dest(getstr,nz);
  }

int main()
  {
   int numnames=5;
   alrm("hello %d\n",numnames);
  }
--------------------------------------------------------------
If that was part of the header of my library and someone tried to
use it with any of a half dozen system headers it would have 
problems.  It used names that were macros in older libraries and
wiped out keywords that appear in other library's headers. 

Thus your list is literally meaningless.  You can't write programs
with Qt on any system which include system headers without risking
a conflict unless you know in advance the symbols that appear in
every one of those system headers.  However, the chance
of a conflict is likely very low.  I dare say collecting the 
list of symbols on all those systems and others that KDE may 
be interested in running on would be bit of a task. 

I think that this makes the statement "identifers used 
by Qt hurt it's portability" at least an arguable
position.  (1 line out 45)  But I will settle only for my 
fair statements, and retract my earlier assertion.

But we are straying far off topic here.  I agree I did not
use "portablity" in the same meaning as yours.  Clearly
you beleive libsigc++ will have problems with some compilers
without template support.  However, I can honestly say
that libsigc++ can be ported back to such earlier systems
as I have ported it to VC 5.0 which lacks many of the requirements
like partial specialization and void return handling.  Whether
it is worth it or not is questionable, as any sane person should
download the latest version of gcc. :-)

Addressing why libsigc++ is not as portable as Qt for
KDE use would be far more on topic of "gnome kde intercoperatity"
and likely more productive.  I think it is a non-issue.

--Karl