On Monday 07 March 2005 01:13, Holger Joukl wrote: > Giovanni wrote: > >... > >Your GCC compiler is almost 6 years old now. Isn't about time to update > >it? It would probably solve this and other problems with C++ codebases..
> Well, we are in the process of moving to a newer GCC. But we have quite > a lot of production code right now compiled with 2.95.2. Moreover, our > intention was to wait as long as possible to maybe see some standardization > regarding ABI and name mangling issues. The intention is that PyKDE should work for any KDE version >= 3.0 which implies systems still running gcc 2.95. While I like gcc and Gnu software generally, things like gcc and autotools don't have a stellar upgrade record - there can be some real issues just moving from one version to another. > >> <sipkdecorepart0.cpp> > >> ... > >> 48633 sipRes = reinterpret_cast<const > >> QValueList<int> *>( &sipCpp -> KStartupInfoData::pids() ); > >> 48634 > >> 48635 PyObject *sipResObj > >> sipConvertFrom_QValueList_1800(const_cast<QValueList<int> *>(sipRes)); > >> 48636 > >> 48637 return sipResObj; > >> 48638 } > >> 48639 } > >> ... > >> </sipkdecorepart0.cpp> > > > >I'm not sure a reinterpret_cast is *ever* a solution. Probably the point > >is where it is assumed that pid_t is int, rather than using pid_t > >directly. > I first tried to make QValueList<long> work with sip but did not succeed > immediately:-) (will look up how to > do that in the newly released snapshots which should fix this problem). But > above solution obviously works > for me and, as pointed out, int and long are the same for 32 bit compiles > on my machine. > Which makes a QValueList<int> the exact same as a QValueList<long> and > which makes the reinterpret_cast > perfectly valid int this situation. > Imho the solution is ugly because you have to modify *generated* code - but > it is a solution nevertheless. QValueList<long> is in sip/dcop/typedefs.sip; so is the modified pid_t typedef. It may not be a perfectly correct fix, but it appears to work on my system, yours, and the other reports I've had so far. If it still breaks something, it'll get more attention. Jim _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
