From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11240 invoked by alias); 10 Dec 2001 10:41:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 11181 invoked from network); 10 Dec 2001 10:41:12 -0000 Received: from unknown (HELO service.sh.cvut.cz) (147.32.127.214) by sources.redhat.com with SMTP; 10 Dec 2001 10:41:12 -0000 Received: from stoupa.sh.cvut.cz (stoupa.sh.cvut.cz [147.32.127.196]) by service.sh.cvut.cz (Postfix) with SMTP id C03551E7AB; Mon, 10 Dec 2001 11:41:06 +0100 (CET) Received: from there (seli@seli.sh.cvut.cz [147.32.122.38]) by stoupa.sh.cvut.cz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id LAA06063; Mon, 10 Dec 2001 11:41:06 +0100 Message-Id: <200112101041.LAA06063@stoupa.sh.cvut.cz> Content-Type: text/plain; charset="iso-8859-2" From: Lubos Lunak To: kde-core-devel@mail.kde.org Subject: Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd) Date: Mon, 10 Dec 2001 02:45:00 -0000 X-Mailer: KMail [version 1.3.2] References: <200112042250.OAA02613@atrus.synopsys.com> <200112100729.fBA7TSl18050@linux.local> <20011210093919.A24527@master.kde.org> In-Reply-To: <20011210093919.A24527@master.kde.org> Cc: Joe Buck , Franz Sirl , gcc@gcc.gnu.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SW-Source: 2001-12/txt/msg00485.txt.bz2 On Mon 10. December 2001 09:39, Simon Hausmann wrote: [snip] > > The regular expression editor is one example (it is loaded > dynamically in khtml/kate/klipper, exactly like in 3993) , some of > the texteditor interfaces in kdelibs/interfaces another one. If we > don't want to use RTLD_GLOBAL I see too solutions from our side: > > 1) Use intermediate shared libraries. Like the regular expression > editor component gets another shared library to which all apps > using the component would have to link against. This doesn't > scale very well for a big amount of components. > > 2) Don't use C++ RTTI to determine whether the given object inherits > from the pure base class but use Qt RTTI instead (qt_cast) . > Syntactically not as beautiful (we could hide it behind a d-cast > like template though) it does quite the same job as when C++ rtti > falls back on the string comparison approach. (which while being > slower should still be fine for KDE as we usually don't do that > casting in inner loops or other time critical places - I think > functionality is here more important) > Maybe I'm missing something obvious, but how about this one? 3) Persuade gcc folks to add compiler switch that makes gcc use string comparing when doing rtti, and simply compile whole KDE with this switch turned on. It seems to be very similar to 2), with some advantages, like working also for classes not inheriting from QObject without problems. Also whether dynamic_cast etc. uses just pointer comparing or string comparing shouldn't(?) affect the ABI, so I don't see any serious problem with it. -- Lubos Lunak llunak@suse.cz ; l.lunak@kde.org http://dforce.sh.cvut.cz/~seli