From lidiaadm@cdc.informatik.tu-darmstadt.de Thu Jan 18 18:07:33 2001 Return-Path: Delivered-To: lidia-develop@mail.cdc.informatik.tu-darmstadt.de Received: from cdc19.cdc.informatik.tu-darmstadt.de (cdc19 [130.83.23.28]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 0BDE82C5C for ; Thu, 18 Jan 2001 18:07:33 +0100 (MET) Received: by cdc19.cdc.informatik.tu-darmstadt.de (8.8.8+Sun/SMI-SVR4) id SAA00741; Thu, 18 Jan 2001 18:07:32 +0100 (MET) Date: Thu, 18 Jan 2001 18:07:32 +0100 (MET) Message-Id: <200101181707.SAA00741@cdc19.cdc.informatik.tu-darmstadt.de> From: LiDIA - Administrator To: LiDIA-develop@cdc.informatik.tu-darmstadt.de Subject: [LiDIA-develop]CHECK IN Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: http://www.cdc.informatik.tu-darmstadt.de/pipermail/lidia-develop/ Hi, please *do* check in whatever changes to LiDIA you have. The C++ files are going to be renamed from *.c to *.cc, soon! (Volker, I will apply the patches you sent me). -- LiDIA-Administrator mailto:lidiaadm@cdc.informatik.tu-darmstadt.de http://www.informatik.tu-darmstadt.de/TI/LiDIA unsolicited commercial e-mail is strictly not wanted! From hamdy@cdc.informatik.tu-darmstadt.de Tue Jan 30 10:04:37 2001 Return-Path: Delivered-To: lidia-develop@mail.cdc.informatik.tu-darmstadt.de Received: from cdc19.cdc.informatik.tu-darmstadt.de (cdc19 [130.83.23.28]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id E482C2C51 for ; Tue, 30 Jan 2001 10:04:36 +0100 (MET) Received: by cdc19.cdc.informatik.tu-darmstadt.de (8.8.8+Sun/SMI-SVR4) id KAA05452; Tue, 30 Jan 2001 10:04:35 +0100 (MET) Message-Id: <200101300904.KAA05452@cdc19.cdc.informatik.tu-darmstadt.de> From: Safuat Hamdy To: LiDIA-Develop@cdc.informatik.tu-darmstadt.de Subject: [LiDIA-develop] Don't change anything in the doc directory Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.1 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Date: Tue, 30 Jan 2001 10:04:35 +0100 (MET) Hi, please do not change anything in the doc directory. Nearly everything is going to be rewritten (except the documentation itself). In particular, the Makefiles, the style file, the bibliography will be rewritten from scratch. Moreover, the LaTeX-code is cleaned up, because *almost every* author seem to have used LaTeX-primitives in a more or less random fashion (my favorites are ``\MATH{something} = \MATH{other}'', ``\MATH{something \MATH{braindead}}'' and ``\MATH{\TT{completely broken}}'')! Also, the process of generating html documentation is going to be reviewed. As a result, most of the old macros, such as MATH, BF, TT and so on will *not* survive. The new manual will be much more consistent and much nicer, so hold your breath and wait ... -- S. Hamdy | All primes are odd except 2, hamdy@cdc.informatik.tu-darmstadt.de | which is the oddest of all. | unsolicited commercial e-mail | D.E. Knuth is strictly not welcome | From hamdy@cdc.informatik.tu-darmstadt.de Wed Jun 20 15:26:54 2001 Return-Path: Delivered-To: lidia-develop@mail.cdc.informatik.tu-darmstadt.de Received: from cdc19.cdc.informatik.tu-darmstadt.de (cdc19 [130.83.23.28]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 450872C89 for ; Wed, 20 Jun 2001 15:26:54 +0200 (MET DST) Received: by cdc19.cdc.informatik.tu-darmstadt.de (8.8.8+Sun/SMI-SVR4) id PAA02747; Wed, 20 Jun 2001 15:26:54 +0200 (MET DST) Date: Wed, 20 Jun 2001 15:26:54 +0200 (MET DST) Message-Id: <200106201326.PAA02747@cdc19.cdc.informatik.tu-darmstadt.de> From: Safuat Hamdy To: LiDIA-develop@cdc.informatik.tu-darmstadt.de Subject: [LiDIA-develop] LiDIA + name spaces Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.1 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hi, I've just checked in my recent changes. This was a `jumbo checkin' for I modified *every* source (with few exceptions): I introduced name spaces (namespace LiDIA). However, some things now doesn't compile (this is not due to the namespaces, they just triggered the compiler to complain on some questionable C++ constructs). So in order to build LiDIA, configure without names paces (./configure --disable-namespaces, you must explicitely say this, for the default is --enable-namspaces). Hopefully, LiDIA will build with namespaces soon. -- S. Hamdy | All primes are odd except 2, hamdy@cdc.informatik.tu-darmstadt.de | which is the oddest of all. | unsolicited commercial e-mail | D.E. Knuth is strictly not welcome | From vmueller@ukdw.ac.id Sat Sep 1 05:12:38 2001 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from mail.ukdw.ac.id (unknown [202.155.16.131]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 5322F2CA7 for ; Sat, 1 Sep 2001 05:12:36 +0200 (MET DST) Received: from TIRH60.ukdw.ac.id ([192.168.3.2]) by mail.ukdw.ac.id (Netscape Messaging Server 3.62) with ESMTP id 319 for ; Sat, 1 Sep 2001 10:17:46 +0700 Date: Sat, 1 Sep 2001 10:19:51 +0700 (JAVT) From: "Volker Mueller" To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [LiDIA-develop] Corrections for elliptic curve classes Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.1 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hello, I recently checked out the complete elliptic curve and the eco tree of the LiDIA development version. Since I am going to do some significant changes to this code, I suggest that anyone else working on this code should contact me such that we can coordinate our changes. Note that there might also be few changes to gf_element which hopefully should be finished until moday or tuesday. Best wishes, Volker From vmueller@ukdw.ac.id Mon Sep 3 04:44:09 2001 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from mail.ukdw.ac.id (unknown [202.155.16.131]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 364782C8C; Mon, 3 Sep 2001 04:44:08 +0200 (MET DST) Received: from TIRH60.ukdw.ac.id ([192.168.3.2]) by mail.ukdw.ac.id (Netscape Messaging Server 3.62) with ESMTP id 302; Mon, 3 Sep 2001 09:49:17 +0700 Date: Mon, 3 Sep 2001 09:51:33 +0700 (JAVT) From: "Volker Mueller" To: , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [LiDIA-develop] Bug in bigmod Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.1 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hello all, I found a nice (but disturbing) bug in bigmod, more precisely in src/base/include/LiDIA/bigmod.h. The unary minus is encoded as operator - (const bigmod & a) { bigmod c; <====== c.negate(); return c; } such that the result is ALWAYS 0 !! You should change "bigmod c" to "bigmod c(a)" and recompile, if you're using bigmod. For developers: The bug fix is already commited to the repository. Cheers, Volker From vmueller@ukdw.ac.id Mon Sep 3 04:44:17 2001 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from mail.ukdw.ac.id (unknown [202.155.16.131]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 9D0072C8C for ; Mon, 3 Sep 2001 04:44:15 +0200 (MET DST) Received: from TIRH60.ukdw.ac.id ([192.168.3.2]) by mail.ukdw.ac.id (Netscape Messaging Server 3.62) with ESMTP id 62 for ; Mon, 3 Sep 2001 09:49:26 +0700 Date: Mon, 3 Sep 2001 09:51:42 +0700 (JAVT) From: "Volker Mueller" To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [LiDIA-develop] Bug in timer.cc Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.1 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hello, there is a bug in timer.cc which leads to wrong timings. The reason for this bug is the fact that TIME_MODE uses the base hsec, HMS_MODE msec. If you use TIME_MODE first (or one of the private functions it uses), then the internal data will be converted and TIME_MODE will be wrong by a factor 10. The bug is fixed and committed to the LiDIA repository this morning. I also changed the code such that the base is msec for both formats (docu also updated). Cheers, Volker From hamdy@cdc.informatik.tu-darmstadt.de Mon Sep 17 15:19:07 2001 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from cdc19.cdc.informatik.tu-darmstadt.de (cdc19 [130.83.23.28]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 6E1EB2C8C for ; Mon, 17 Sep 2001 15:19:07 +0200 (MET DST) Received: by cdc19.cdc.informatik.tu-darmstadt.de (8.8.8+Sun/SMI-SVR4) id PAA20067; Mon, 17 Sep 2001 15:19:07 +0200 (MET DST) Date: Mon, 17 Sep 2001 15:19:07 +0200 (MET DST) Message-Id: <200109171319.PAA20067@cdc19.cdc.informatik.tu-darmstadt.de> From: Safuat Hamdy To: lidia-develop@cdc.informatik.tu-darmstadt.de Cc: lidia-develop@cdc.informatik.tu-darmstadt.de In-reply-to: (vmueller@ukdw.ac.id) Subject: Re: [LiDIA-develop] Corrections for elliptic curve classes References: Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.1 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Volker Mueller wrote: > I recently checked out the complete elliptic curve and the eco tree of > the LiDIA development version. Since I am going to do some significant > changes to this code, I suggest that anyone else working on this code > should contact me such that we can coordinate our changes. Note that > there might also be few changes to gf_element which hopefully should > be finished until moday or tuesday. Hi Volker, will you also clean up the design of the EC classes a bit? The non-template friend functions for some template classes seems to be technically ok, but at the same time they are a hint for an improper class design. Anyway, thanks for your efforts. -- S. Hamdy | All primes are odd except 2, hamdy@cdc.informatik.tu-darmstadt.de | which is the oddest of all. | unsolicited commercial e-mail | D.E. Knuth is strictly not welcome | From ccorn@cs.tu-berlin.de Thu May 2 09:21:13 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from Dachs.Bau (brln-d9b8048e.pool.mediaWays.net [217.184.4.142]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 1514F2C88 for ; Thu, 2 May 2002 09:21:13 +0200 (MET DST) Received: by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386), from userid 500) id A57BF5D7B; Thu, 2 May 2002 09:06:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386)) with ESMTP id A8980F86C for ; Thu, 2 May 2002 09:06:21 +0200 (CEST) Date: Thu, 2 May 2002 09:06:18 +0200 (CEST) From: Christian Cornelssen X-X-Sender: To: LiDIA Developers Mailing List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [LiDIA-develop] More robust Makefile rules Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Dear LiDIA developers and maintainers, I have added some (rarely needed) fragments to LiDIA's top-level Makefile.am and doc/Makefile.am. Makefile.am: Should now avoid packaging errors due to equal timestamps when making `dist*-pkgs' on very fast machines (those that can tar and gzip a partial archive in less than one second). I have not encountered that case so far, but just in case... doc/Makefile.am: The search paths are now set explicitly instead of mostly leaving that to texi2dvi. Reason: when doing a VPATH build of `LiDIA.dvi' with a copy of `LiDIA.tex' in the build tree, texi2dvi takes the local version (which is correct) and consequently does not set search paths for the source directory (which is still needed). Best regards, Christian Cornelssen From ccorn@cs.tu-berlin.de Fri May 3 18:01:14 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from Dachs.Bau (brln-d9b80fa0.pool.mediaWays.net [217.184.15.160]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id F1F262C96 for ; Fri, 3 May 2002 18:01:13 +0200 (MET DST) Received: by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386), from userid 500) id 65EB85DC2; Fri, 3 May 2002 18:03:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386)) with ESMTP id 8476CF8F6 for ; Fri, 3 May 2002 18:03:50 +0200 (CEST) Date: Fri, 3 May 2002 18:03:49 +0200 (CEST) From: Christian Cornelssen X-X-Sender: To: LiDIA Developers Mailing List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [LiDIA-develop] PDF re-enabled Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Dear LiDIA developers and maintainers, I have committed changes to LiDIA that re-enable generation of the manual in PDF format. The key step was to replace the EPS figure depicting the LiDIA layers by a handful of LaTeX picture macros, which are device independent. To achieve similarity to the previous version of the figure, I added grayscaled boxes with help of the standard `color' package. The similarity is "almost" 100% -- being "almost" because I used \sffamily\small as the default font, which better suits my taste... The downside: My svgalib-based DVI previewer displays all grayscales as black and thus blackens out the whole figure. I do not know whether xdvi does better. I also added `graphics.cfg' and `color.cfg' files because we expect to use dvips and/or pdflatex and therefore have to ensure an appropriate driver setup. In addition to the previous documentation targets `dvi', `ps', `psgz', and `psbz2', you can now make `pdf' and `dsc' from the top-level directory or directly in the doc/ subdirectory. The `dsc' target requires the "pdf2dsc" program, which comes with Ghostscript 6.x, and produces LiDIA.dsc, which is a PS wrapper for LiDIA.pdf that allows application of PS tools like psselect and others. In comparison to LiDIA.ps, the pdf+dsc combination is much more compact. I did all this at home where I do not run X11; therefore I could not try the Acrobat Reader on LiDIA.pdf (only Ghostscript), and consequently, I cannot report how much hyperlink fun is available in LiDIA.pdf now. I would appreciate some feedback from ambitioned testers. Best regards, Christian Cornelssen From vmueller@ukdw.ac.id Mon May 6 05:20:25 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from ukdw.ac.id (unknown [202.155.16.136]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 2D6A22C93 for ; Mon, 6 May 2002 05:20:22 +0200 (MET DST) Received: (qmail 27693 invoked by alias); 6 May 2002 03:22:41 -0000 Received: (qmail 27685 invoked from network); 6 May 2002 03:22:41 -0000 Received: from unknown (HELO TIRH60.ukdw.ac.id) (192.168.3.) by mail.ukdw.ac.id with SMTP; 6 May 2002 03:22:41 -0000 Date: Mon, 6 May 2002 10:20:37 +0700 (JAVT) From: Volker Mueller To: lidia-develop@cdc.informatik.tu-darmstadt.de Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Subject: [LiDIA-develop] Ideen Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, da es nun einen neuen Administrator gibt und LiDIA (hoffentlich) wieder etwas aktiver weiterentwickelt wird, hier einige Ideen von mir, was lohnenswert zu tun wäre: 1. Es sollte ein neues Target "make test" eingeführt und für ALLE Klassen möglichst EINHEITLICH implementiert werden. Es gibt bisher diese ominösen Appl-Files, aber diese variieren extrem stark, und oft enthalten sie auch keine Tests. Bei den "historischen" Klassen wie bigint, bigmod etc. sind diese Appl Files noch eher zum Testen geeignet; je neuer der Code wird, desto weniger brauchbar sind diese Testfiles. Häufiger zeigen sie nur auf, wie der Code benutzt werden kann. Dies sollte deutlicher getrennt werden. 2. Testumgebung: Ich hatte das vor meinem Weggehen aus Darmstadt schon mal vorgeschlagen, und soweit ich mich erinnere, gab es dazu auch eine Diplomarbeit, die aber nie "verwendbar" wurde (soweit ich das weiss). Die Idee ist die, dass wir eine Datenbank mit bekannten Bugs und zugehörigen Testprogrammen haben, aus denen automatisch Tests generiert und durchgeführt werden können. Damit liesse sich verhindern, dass schon gefixte Bugs erneut auftreten, weil A sie fixt, B sie später mit seinem ungefixten Code wieder einbaut mit commit (ist so schon passiert !!). Da koennten wir sicherlich von open source Programmen lernen bzw. profitieren, Stichwort bugzilla oder sowas. 3. Einführung von make optimize: Mehrere Klassen benutzen Parameter, um zwischen verschiedenen Algorithmen zu wählen (z.B. MPQS, Fp_polynomial, ...). Diese Parameter sind zur Zeit hard-coded, sollten aber besser für jeden Computer neu berechnet werden können (neuer Prozessor, Cache, Bus etc., die Parameter koennen sich dann wirklich drastisch aendern). Meine Idee ist daher, ein neues solches Target einzuführen, das Optimierungstests (die evtl. lange brauchen) ausführt und dann neu compiliert. Ich hatte sowas für Fp_polynomial mal geschrieben, wurde aber nicht eingebaut, Grund weiss ich nicht. 4. 64-fest machen: ich kenne einiger Stellen, wo LiDIA sicherlich NICHT 64 Bit fest ist. Das kommt daher, dass wir nie Zugang zu einem 64 Bit Rechner hatten. Die werden aber wohl in Zukunft populärer werden. Sollte da also die Möglichkeit geben, auf einen solchen rechner zuzugreifen, so sollte das ausgebaut und getestet werden (Testumgebung !!). 64-Bit Code fuer ECM habe ich uebrigens mal geschrieben, aber noch ungeftestet. 5. Es gibt etwas Code, der mehrfach vorhanden ist. Beispielsweise gibt es mindestens zwei Funktionen, um kleine Primzahlen zu bestimmen -- eine in ecm (da werden sie mit einem Sieb berechnet) und eine in den Matrixklassen (da werden sie aus der lidia_primes (??)) Datei gelesen. Diese beiden Klassen sollten vereint werden, wobei sicherlich die dynamische Variante weiterleben sollte (die Dateivariante ist in den möglichen Ausgaben beschränkt). 6. Neuer Code: extension fields of finite fields, d.h. Körpertürme. Dieses Thema sollte schon lange angegangen werden, aber es ist nie genauer untersucht und implementiert worden. Ich vermute, dass eine effiziente Implementierung von Körpertürmen in einigen Algorithmen helfen kann. 7. Neuer Code: multivariate Polynome. Hm, gab es mal, aber der Code war so schlecht geschrieben, dass wir in wieder entfernt haben. Und er war fast nicht reparierbar, danach wurde aber nie eine neue Diplomarbeit zu dem Thema vergeben, so dass es weiterhin fehlt. So, das sind nur einige Ideen, wie LiDIA in naher oder weiterer Zukunft verbessert werden kann. Viele Grüsse aus Indonesien, Volker -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE81faW6SwzB/rr6m4RAsLtAKDMvt/MXQEq7K6Qm4pwpg+cSE8GsQCeM8XL G/QTic1ePLRbSh8B1lS9Se4= =GUtW -----END PGP SIGNATURE----- From ccorn@cs.tu-berlin.de Mon May 6 11:06:45 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from Dachs.Bau (brln-d9b82c64.pool.mediaWays.net [217.184.44.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id B59A32CA6 for ; Mon, 6 May 2002 11:06:43 +0200 (MET DST) Received: by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386), from userid 500) id 9BD195DBC; Mon, 6 May 2002 11:07:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386)) with ESMTP id EB298F8F6 for ; Mon, 6 May 2002 11:07:04 +0200 (CEST) Date: Mon, 6 May 2002 11:07:03 +0200 (CEST) From: Christian Cornelssen X-X-Sender: To: LiDIA Developers Mailing List Subject: Re: [LiDIA-develop] Ideen In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hallo allerseits, On Mon, 6 May 2002, Volker Mueller wrote: > 1. Es sollte ein neues Target "make test" eingeführt und für ALLE > Klassen möglichst EINHEITLICH implementiert werden. Es gibt bisher > diese ominösen Appl-Files, aber diese variieren extrem stark, und oft > enthalten sie auch keine Tests. Bei den "historischen" Klassen wie > bigint, bigmod etc. sind diese Appl Files noch eher zum Testen > geeignet; je neuer der Code wird, desto weniger brauchbar sind diese > Testfiles. Häufiger zeigen sie nur auf, wie der Code benutzt werden > kann. Dies sollte deutlicher getrennt werden. Getrennte Unterverzeichnisse für Quellen von library/, examples/ und den (künftigen) tests/ sollten kein Problem sein. Eine definierte Testschnittstelle ist von Automake bereits vorgegeben (sofern man nicht DejaGNU verwendet, aber Christoph hat schon recht damit, dass die Ansprüche einer Testumgebung an das Build-System bescheiden gehalten werden sollten). > 2. Testumgebung: Ich hatte das vor meinem Weggehen aus Darmstadt schon > mal vorgeschlagen, und soweit ich mich erinnere, gab es dazu auch > eine Diplomarbeit, die aber nie "verwendbar" wurde (soweit ich das > weiss). Die Idee ist die, dass wir eine Datenbank mit bekannten Bugs > und zugehörigen Testprogrammen haben, aus denen automatisch Tests > generiert und durchgeführt werden können. Damit liesse sich > verhindern, dass schon gefixte Bugs erneut auftreten, weil A sie fixt, > B sie später mit seinem ungefixten Code wieder einbaut mit commit > (ist so schon passiert !!). Da koennten wir sicherlich von open source > Programmen lernen bzw. profitieren, Stichwort bugzilla oder sowas. Kenne ich von GCC-3 und den GNU Autotools. Lästig finde ich dabei allerdings den Mangel an Orthogonalität der Tests. Mit jedem Bugfix wächst die Zahl der Tests in der Distribution, und da die meisten Tests eher zum Prüfen der Bugfixes und darauffolgender Code-Mergings dienen, werden die Distributionsempfänger damit eigentlich unnötig belastet. Bemerkenswerterweise finden sich dann trotz hunderter Testfiles immer wieder neue Fehler, eben weil nur pragmatisch und nicht systematisch getestet wird. In der GCC-3-Suite finden sich ganze Verzeichnisse mit Testsuites, in deren Kommentaren steht, dass eigentlich keiner mehr weiß, wozu diese Tests eigentlich gut sein sollen, und dass oft auch die Tests selbst nicht mehr richtig sind (wg. der Standardisierung von C++ usw.). So kann's kommen... Das Argument eben kam aus Anwendersicht. Für Entwickler ist eine Testdatenbank, die das Wiederholen von Fehlern vermeiden hilft, allerdings unbezweifelbar hilfreich. Da Automake solche Testsuites unterstützt (und auch das Interface schon vorgibt), halte ich das Einrichten für gar nicht schwer, und wachsen tut die Testsuite ja dann mit der Zeit... Komplementär dazu würde ich allerdings auch ein System entwickeln wollen, das bereits beim Klassenentwurf eine Spezifikation von Beispielfällen z.B. in Form von speziellen Kommentaren erlaubt, deren Kern auf so etwas wie eine assert-Anweisung oder ein Programmfragment mit dazugehörigem E/A-Protokoll hinausläuft. Diese Beispielangaben können dann von einem Skript extrahiert und in Testprogramme umgewandelt werden. Für Programmierer ist das sehr bequem, da die gegebenen Beispielfälle auch zur Spezifikation beitragen; insbesondere das Verhalten in Randfällen ("ist n==0 für die Funktion f(n) noch zulässig, und was wird als Resultat geliefert?") kann damit zuverlässig dokumentiert werden. Typischerweise sind diese Spezifikationen dann Bestandteil der Header-Dateien, und wenn die Syntax verständlich gehalten wird, können auch Anwender damit etwas anfangen, z.B. falls im Handbuch die gewünschten Details nicht erwähnt werden. > 3. Einführung von make optimize: Mehrere Klassen benutzen Parameter, > um zwischen verschiedenen Algorithmen zu wählen (z.B. MPQS, > Fp_polynomial, ...). Diese Parameter sind zur Zeit hard-coded, sollten > aber besser für jeden Computer neu berechnet werden können (neuer > Prozessor, Cache, Bus etc., die Parameter koennen sich dann wirklich > drastisch aendern). Meine Idee ist daher, ein neues solches Target > einzuführen, das Optimierungstests (die evtl. lange brauchen) ausführt > und dann neu compiliert. Ich hatte sowas für Fp_polynomial mal > geschrieben, wurde aber nicht eingebaut, Grund weiss ich nicht. Ein "make optimize" habe ich mir auch auf meine TODO-Liste gesetzt, als ich die `MACHINE's und `crossover.tbl's der 2.1pre5 entdeckte. Mittlerweile haben einige maschinell erzeugte Header anscheinend richtige Namen bekommen und sind im include-Baum gelandet (src/base/include/LiDIA/mpqs_timing.h sowie src/finite_fields/include/LiDIA/Fp_pol_crossover.h), aber zumindest im GF2n-Teilbaum sind noch einige private Tuning-Header zu finden. Deren Problem: #include "crossover.tbl" sucht zunächst stets im Verzeichnis der cc-Eingabedatei, bei VPATH-Builds also NICHT im Buildtree, was ein Tuning im Buildtree erschwert. Für die verschobenen Tuning-Header wird hingegen die <>-Schreibweise verwendet, die VPATH-tauglich ist. NB: Ich habe bei der Umstellung auf Automake die o.g. Header-Dateien mit in die Installationslisten der `Makefile.am's aufgenommen. Das sollte vielleicht wieder rückgängig gemacht werden (stattdessen -> BUILT_SOURCES)? Viele Grüße, Christian Cornelssen From Stefan.Neis@t-online.de Mon May 6 13:19:47 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id D04C22CA6 for ; Mon, 6 May 2002 13:19:46 +0200 (MET DST) Received: from fwd10.sul.t-online.de by mailout07.sul.t-online.com with smtp id 174gWv-00031o-0G; Mon, 06 May 2002 13:19:45 +0200 Received: from webmail.t-online.de (333100012182-0001@[172.18.16.209]) by fwd10.bbul.t-online.de with smtp id 174gWp-1Psm6CC; Mon, 6 May 2002 13:19:39 +0200 To: lidia-develop@cdc.informatik.tu-darmstadt.de Subject: Re: [LiDIA-develop] Ideen From: Stefan.Neis@t-online.de Date: Mon, 06 May 2002 13:19:19 +0200 (CEST) Message-ID: <1020683496.3cd664e84329d@webmail.t-online.de> X-Priority: 3 (Normal) X-Approved: b40a0aedc4fc87cd392f79c07d12629be6560749023fc29d81e759ddc3436033 X-Mailer: T-Online WebMail 2.03 X-Complaints-To: abuse#webmail@t-online.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Sender: 333100012182-0001@t-dialin.net Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hallo, > 5. Es gibt etwas Code, der mehrfach vorhanden ist.=20 > Beispielsweise gibt=20 > es mindestens zwei Funktionen, um kleine Primzahlen zu=20 > bestimmen --=20 Es gibt sogar eine fertig implementierte prime_list-Klasse, die alles kann, was die beiden Funktionen brauchen, nur muesste mal jemand den vorhandenen Code so umschreiben, dass die auch benutzt wird. Bei Interesse kann ich den Code bestimmt nochmal irgendwo auf meiner Platte finden... > 6. Neuer Code: extension fields of finite fields, d.h.=20 > K=F6rpert=FCrme. =20 > > 7. Neuer Code: multivariate Polynome.=20 8. Mit "bigmod_matrix" haben wir eine aehnliche Dopplung wie mit den Primzahlen, allerdings noch keine Loesung in Sicht. Eine effiziente Implementierung von dem, was ich da prototypisch gestrickt habe, waere sogar wirklich was neues. Mal 'ne Randfrage: Wer liest eigentlich auf dieser -develop Mailing-Liste mit? Viele Gruesse, Stefan From cludwig@cdc.informatik.tu-darmstadt.de Tue May 14 12:19:28 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from cdc-ws9.cdc.informatik.tu-darmstadt.de (cdc-ws9 [130.83.23.69]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 70E092C9D for ; Tue, 14 May 2002 12:19:28 +0200 (MET DST) Received: (from cludwig@localhost) by cdc-ws9.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g4EAJQn13250 for lidia-develop@cdc.informatik.tu-darmstadt.de; Tue, 14 May 2002 12:19:26 +0200 (MEST) Date: Tue, 14 May 2002 12:19:15 +0200 From: Christoph Ludwig To: lidia-develop@cdc.informatik.tu-darmstadt.de Message-ID: <20020514121915.B13045@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mail-Followup-To: lidia-develop@cdc.informatik.tu-darmstadt.de References: <177GWM-074b0SC@fmrl10.sul.t-online.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <177GWM-074b0SC@fmrl10.sul.t-online.com>; from Stefan.Neis@t-online.de on Mon, May 13, 2002 at 04:09:49PM +0000 Subject: [LiDIA-develop] Re: [LiDIA] Wie kann ich mit Lidia-Bibliothek arbeiten!! Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: [If there is anyone subscribed to lidia-develop who prefers discussion in English, please protest.] On Mon, May 13, 2002 at 04:09:49PM +0000, Stefan.Neis@t-online.de wrote: > > Do you really think it is feasible to build LiDIA without linking > > against libstdc++? Besides I/O, it also contains operator new(). > > Hm, OK. good point. So this really doesn't make sense as soon as you > start using more than the most simple classes. However, if you have > crypto applications in mind, it definitly is possible. > > > (Aside: We either have to change > > that into new(std::nothrow) or to allow exception propagation...) > > What will happen otherwise? Is there any reasonable action to take > if we run out of memory? Womit müssen wir momentan rechnen? Ich bin mir nicht sicher, vielleicht crasht das Programm irgendwo in den Tiefen von operator new(). Oder new liefert irgendeinen zufälligen Pointer, so dass das Programm irgendwann später abstürzen wird. Oder... Was auch immer, das Programm wird höchstwahrscheinlich irgendwann abschmieren und der Grund wird für den Benutzer nicht offensichtlich sein, selbst wenn er sich den core dump anschaut. Dagegen scheint mir bereits ein "assert(ptr != NULL)" weitaus vernünftiger. Oder noch besser, LiDIAs error handler wird mit einer sinnvollen Fehlermeldung aufgerufen und beendet das Programm ordentlich. Ok, ich geb's zu. Es ist nervig und für die Lesbarkeit des Codes nicht zuträglich, wenn jeder Aufruf von new von einer Fehlerprüfung gefolgt wird, zumal man mit einem Eintreten des Fehlers sowieso fast nie rechnet. Und Programmierer sind per definitionem bequem. Es wird also nicht lange dauern, bis die Checks weggelassen werden. Und schon sind wir wieder dort, wo wir angefangen haben. Da erscheint es besser, std::bad_alloc nach oben durchzureichen. In den meisten Fällen kommt es ja ohnehin nicht darauf an, welche Allokation in welcher Zeile des Codes fehlschlug; die wichtige Information ist, dass die Berechnung wegen Speichermangels nicht ausgeführt werden konnte. Der Aufrufer kann dann angemessen reagieren. Meistens wird dies bedeuten, dass er eine Fehlermeldung schreibt und das Programm abbricht. Doch vielleicht steht auch noch ein alternativer Algorithmus zur Auswahl, der zwar länger braucht, aber geringere Anforderungen an den Speicher stellt. Selbstverständlich dürfen wir die Effizienz nicht völlig außer Acht lassen. Kennt jemand Benchmarks, welche Auswirkungen auf Laufzeit und Codegröße das Einschalten des Exception Handlings hat, solange keine Exceptions tatsächlich geworfen werden? Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA-CA: http://www.informatik.tu-darmstadt.de/TI/Forschung/LiDIA-CA/ From Stefan.Neis@t-online.de Tue May 14 15:40:53 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 5F1A12C9F for ; Tue, 14 May 2002 15:40:53 +0200 (MET DST) Received: from fwd11.sul.t-online.de by mailout05.sul.t-online.com with smtp id 177agP-0006Lh-0H; Tue, 14 May 2002 13:41:33 +0200 Received: from webmail.t-online.de (333100012182-0001@[172.18.16.211]) by fwd11.bbul.t-online.de with smtp id 177agM-0ri2GeC; Tue, 14 May 2002 13:41:30 +0200 To: lidia-develop@cdc.informatik.tu-darmstadt.de Subject: Re: [LiDIA-develop] Re: [LiDIA] Wie kann ich mit Lidia-Bibliothek arbeiten!! From: Stefan.Neis@t-online.de Date: Tue, 14 May 2002 13:41:12 +0200 (CEST) Message-ID: <1021376259.3ce0f703320e6@webmail.t-online.de> X-Priority: 3 (Normal) X-Approved: f0357b08519b55e83d89b5209275f78f43f0c985d1fd67ec363579b16994bc4b X-Mailer: T-Online WebMail 2.03 X-Complaints-To: abuse#webmail@t-online.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Sender: 333100012182-0001@t-dialin.net Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hallo, > Womit m=FCssen wir momentan rechnen? Ich krieg' eigentlich typischerweise immer das Errorhandling der Langzahlbibliothek zu sehen, "normalerweise" geht's anscheinend da schief ...=20 Ich bin mir nicht=20 > Selbstverst=E4ndlich d=FCrfen wir die Effizienz nicht v=F6llig=20 > au=DFer Acht=20 > lassen. Kennt jemand Benchmarks, welche Auswirkungen auf=20 > Laufzeit und=20 > Codegr=F6=DFe das Einschalten des Exception Handlings hat,=20 > solange keine=20 > Exceptions tats=E4chlich geworfen werden?=20 Benchmarks kenn' ich keine, aber die Theorie behauptet, glaube ich, dass es auf manchen Rechnerarchitekturen gar nichts kostet (Intel, Sparc, wenn ich mich recht erinnere) und auf anderen ziemlich teuer sein kann. Gruss, Stefan= From safuat@math.ucalgary.ca Tue May 14 17:27:46 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from msfs.math.ucalgary.ca (msfs.math.ucalgary.ca [136.159.61.8]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 405DB2C9B for ; Tue, 14 May 2002 17:27:45 +0200 (MET DST) Received: from rivendell.math.ucalgary.ca ([136.159.61.183]) by msfs.math.ucalgary.ca (8.11.6+Sun/8.11.6) with ESMTP id g4EFRhk08384 for ; Tue, 14 May 2002 09:27:44 -0600 (MDT) Received: by rivendell.math.ucalgary.ca (Postfix on SuSE Linux 7.3 (i386), from userid 500) id 0FB2925D83; Tue, 14 May 2002 09:28:00 -0600 (MDT) Content-Type: text/plain; charset="iso-8859-1" From: "Dr.S.Hamdy" Organization: University of Calgary, Dept. of Mathematics and Statistics To: lidia-develop@cdc.informatik.tu-darmstadt.de Subject: Re: [LiDIA-develop] Wie kann ich mit Lidia-Bibliothek arbeiten!! Date: Tue, 14 May 2002 09:28:00 -0600 X-Mailer: KMail [version 1.3.1] References: <1021376259.3ce0f703320e6@webmail.t-online.de> In-Reply-To: <1021376259.3ce0f703320e6@webmail.t-online.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020514152800.0FB2925D83@rivendell.math.ucalgary.ca> Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de X-Reply-To: hamdy@math.ucalgary.ca List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: On Tuesday 14 May 2002 05:41, you wrote: > Benchmarks kenn' ich keine, aber die Theorie behauptet, glaube > ich, dass es auf manchen Rechnerarchitekturen gar nichts kostet > (Intel, Sparc, wenn ich mich recht erinnere) und auf anderen > ziemlich teuer sein kann. Dann wird es wohl das einfachste sein, wenn man das als Konfigurations-Option einbaut. Oder der Benutzer schreibt es explizit in die CXXFLAGS. Das hätte den Vorteil, daß man nicht je nach Compiler nachsehen muß, wie das zu bewerkstelligen ist. Gruß -- Dr. S. Hamdy | All primes are odd except 2, Dept. of Mathematics & Statistics | which is the oddest of all. University of Calgary | | unsolicited commercial e-mail | is strictly not welcome | From Stefan.Neis@t-online.de Wed May 15 11:45:19 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 83AD32CAC for ; Wed, 15 May 2002 11:45:19 +0200 (MET DST) Received: from fwd06.sul.t-online.de by mailout02.sul.t-online.com with smtp id 177vLS-0003aL-0H; Wed, 15 May 2002 11:45:18 +0200 Received: from webmail.t-online.de (333100012182-0001@[172.18.16.208]) by fwd06.bbul.t-online.de with smtp id 177vLO-2FsORMC; Wed, 15 May 2002 11:45:14 +0200 To: lidia-develop@cdc.informatik.tu-darmstadt.de Subject: Re: [LiDIA-develop] Wie kann ich mit Lidia-Bibliothek arbeiten!! From: Stefan.Neis@t-online.de Date: Wed, 15 May 2002 11:44:56 +0200 (CEST) Message-ID: <1021455814.3ce22dc69c704@webmail.t-online.de> X-Priority: 3 (Normal) X-Approved: 76ed4356169ef55c12b2835eb645097ed1b79117a8826f821e53297a25423286 X-Mailer: T-Online WebMail 2.03 X-Complaints-To: abuse#webmail@t-online.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Sender: 333100012182-0001@t-dialin.net Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Dr.S.Hamdy schrieb: > On Tuesday 14 May 2002 05:41, you wrote: >=20 > > Benchmarks kenn' ich keine, aber die Theorie behauptet,=20 > glaube=20 > > ich, dass es auf manchen Rechnerarchitekturen gar=20 > nichts kostet=20 > > (Intel, Sparc, wenn ich mich recht erinnere) und auf=20 > anderen=20 > > ziemlich teuer sein kann. >=20 > Dann wird es wohl das einfachste sein, wenn man das als=20 > Konfigurations-Option =20 > einbaut. Oder der Benutzer schreibt es explizit in die=20 > CXXFLAGS. Das h=E4tte =20 > den Vorteil, da=DF man nicht je nach Compiler nachsehen=20 > mu=DF, wie das zu =20 > bewerkstelligen ist. Man will das Flag aber wirklich nur beim =DCbsersetzen von 1 oder 2 Files haben, es kostet n=E4mlich wirklich Luafzeit. Das global f=FCr alles zu setzen ist nicht wirklich eine gute Idee... Gruss, Stefan= From cludwig@cdc.informatik.tu-darmstadt.de Wed May 15 13:26:52 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from cdc-ws9.cdc.informatik.tu-darmstadt.de (cdc-ws9 [130.83.23.69]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 2B3FA2C91 for ; Wed, 15 May 2002 13:26:52 +0200 (MET DST) Received: (from cludwig@localhost) by cdc-ws9.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g4FBQpu00543 for lidia-develop@cdc.informatik.tu-darmstadt.de; Wed, 15 May 2002 13:26:51 +0200 (MEST) Date: Wed, 15 May 2002 13:26:50 +0200 From: Christoph Ludwig To: lidia-develop@cdc.informatik.tu-darmstadt.de Subject: [LiDIA-develop] CXXFLAGS Message-ID: <20020515132650.A483@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mail-Followup-To: lidia-develop@cdc.informatik.tu-darmstadt.de References: <1021455814.3ce22dc69c704@webmail.t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <1021455814.3ce22dc69c704@webmail.t-online.de>; from Stefan.Neis@t-online.de on Wed, May 15, 2002 at 11:44:56AM +0200 Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Kann es sein, dass Ihr aneinander vorbeiredet? Wenn Stefan meint, man wolle das Flag nur für einzelne wenige Files setzen, vermute ich, er bezieht sich auf die Diskussion über -ffloat-store. Das Flag zum Abschalten des Exception-Handlings muss man nämlich überall oder gar nicht setzen, ansonsten ist Chaos vorprogrammiert; ausserdem bringt es nach Stefans eigener Vermutung auf manchen Plattformen keine Geschwindigkeitsnachteile. Falls ich mich nicht irre, bezieht sich Safuat hingegen auf -fno-exceptions... Gruß Christoph On Wed, May 15, 2002 at 11:44:56AM +0200, Stefan.Neis@t-online.de wrote: > Dr.S.Hamdy schrieb: > > On Tuesday 14 May 2002 05:41, you wrote: > > > > > Benchmarks kenn' ich keine, aber die Theorie behauptet, > > glaube > > > ich, dass es auf manchen Rechnerarchitekturen gar > > nichts kostet > > > (Intel, Sparc, wenn ich mich recht erinnere) und auf > > anderen > > > ziemlich teuer sein kann. > > > > Dann wird es wohl das einfachste sein, wenn man das als > > Konfigurations-Option > > einbaut. Oder der Benutzer schreibt es explizit in die > > CXXFLAGS. Das hätte > > den Vorteil, daß man nicht je nach Compiler nachsehen > > muß, wie das zu > > bewerkstelligen ist. > > Man will das Flag aber wirklich nur beim Übsersetzen von > 1 oder 2 Files haben, es kostet nämlich wirklich Luafzeit. > Das global für alles zu setzen ist nicht wirklich eine gute > Idee... > > Gruss, > Stefan_______________________________________________ > LiDIA-develop mailing list > LiDIA-develop@cdc.informatik.tu-darmstadt.de > http://www.cdc.informatik.tu-darmstadt.de/mailman/listinfo/lidia-develop -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA-CA: http://www.informatik.tu-darmstadt.de/TI/Forschung/LiDIA-CA/ From Stefan.Neis@t-online.de Wed May 15 15:04:48 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 269A42CA7 for ; Wed, 15 May 2002 15:04:48 +0200 (MET DST) Received: from fwd07.sul.t-online.de by mailout03.sul.t-online.com with smtp id 177xWp-0006xG-06; Wed, 15 May 2002 14:05:11 +0200 Received: from webmail.t-online.de (333100012182-0001@[172.18.16.208]) by fwd07.bbul.t-online.de with smtp id 177xWi-2A9fLkC; Wed, 15 May 2002 14:05:04 +0200 To: lidia-develop@cdc.informatik.tu-darmstadt.de Subject: Re: [LiDIA-develop] CXXFLAGS From: Stefan.Neis@t-online.de Date: Wed, 15 May 2002 14:04:58 +0200 (CEST) Message-ID: <1021463838.3ce24d1e046e9@webmail.t-online.de> X-Priority: 3 (Normal) X-Approved: c13ba28ca2f79f77123496f2244d837396be29c8e921d7611a6987000a69e56e X-Mailer: T-Online WebMail 2.03 X-Complaints-To: abuse#webmail@t-online.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Sender: 333100012182-0001@t-dialin.net Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Christoph Ludwig schrieb: > Kann es sein, dass Ihr aneinander vorbeiredet?=20 Hast recht. Wer lesen kann, ist klar im Vorteil. :-( > Das Flag zum Abschalten des=20 > Exception-Handlings muss=20 > man n=E4mlich =FCberall oder gar nicht setzen, ansonsten ist=20 > Chaos=20 > vorprogrammiert;=20 Exakt. Mit einer Ausnahme: Es sollte m=F6glich sein,=20 -fno-exceptions zum Compilieren von LiDIA zu benutzen und das Ergebnis in ein Executable zu linken, das selber exceptions benutzt. (Umgekehrt hingegen nat=FCrlich nicht). Von daher w=FCrde ich dazu tendieren,=20 "-fno-exceptions -fno-rtti" beim =DCbersetzen von LiDIA zu verwenden, solange exceptions und RTTI nicht intern benutzt werden. Der Vorteil liegt darin, dass die Library (und nat=FCrlich auch die damit gelinkten Binaries) deutlich kleiner werden, w=E4hrend ich einen Nachteil noch nicht sehe... Gruss, Stefan Gruss, Stefan= From cludwig@cdc.informatik.tu-darmstadt.de Wed May 15 15:38:15 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from cdc-ws9.cdc.informatik.tu-darmstadt.de (cdc-ws9 [130.83.23.69]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 19EA22CA7 for ; Wed, 15 May 2002 15:38:14 +0200 (MET DST) Received: (from cludwig@localhost) by cdc-ws9.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g4FDcCa00649 for lidia-develop@cdc.informatik.tu-darmstadt.de; Wed, 15 May 2002 15:38:12 +0200 (MEST) Date: Wed, 15 May 2002 15:38:12 +0200 From: Christoph Ludwig To: lidia-develop@cdc.informatik.tu-darmstadt.de Subject: Re: [LiDIA-develop] CXXFLAGS Message-ID: <20020515153812.B636@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mail-Followup-To: lidia-develop@cdc.informatik.tu-darmstadt.de References: <1021463838.3ce24d1e046e9@webmail.t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <1021463838.3ce24d1e046e9@webmail.t-online.de>; from Stefan.Neis@t-online.de on Wed, May 15, 2002 at 02:04:58PM +0200 Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hallo, On Wed, May 15, 2002 at 02:04:58PM +0200, Stefan.Neis@t-online.de wrote: > Christoph Ludwig schrieb: > > Das Flag zum Abschalten des > > Exception-Handlings muss > > man nämlich überall oder gar nicht setzen, ansonsten ist > > Chaos > > vorprogrammiert; > > Exakt. Mit einer Ausnahme: Es sollte möglich sein, > -fno-exceptions zum Compilieren von LiDIA zu benutzen und > das Ergebnis in ein Executable zu linken, das selber > exceptions benutzt. (Umgekehrt hingegen natürlich nicht). > Von daher würde ich dazu tendieren, > "-fno-exceptions -fno-rtti" beim Übersetzen von LiDIA > zu verwenden, solange exceptions und RTTI nicht intern > benutzt werden. > Der Vorteil liegt darin, dass die Library (und natürlich > auch die damit gelinkten Binaries) deutlich kleiner > werden, während ich einen Nachteil noch nicht sehe... Wenn wir Exceptions grundsätzlich ausschließen, ist die Fehlerbehandlung im wesentlichen auf einen Aufruf von exit() oder abort() eingeschränkt. Das empfinde ich als ein wesentliches Manko. Ich hatte schon öfters den Fall, dass ein Programm mehrere Stunden gerechnet hat, ehe in irgendeiner Unterroutine ein Bereichsüberlauf eintrat, der einen Programmabruch verursachte. (Ich bin mir nicht sicher, ob mir das bislang nur mit NTL oder auch mit LiDIA passierte, aber eine solche Situation ist mit LiDIA sicher auch vorstellbar.) Hätte das Programm statt dessen eine Exception geworfen, hätte ich die bis dahin ermittelten Zwischenergebnisse weiternutzen können. Die einfachste Lösung scheint mir, dass die Fehlerbehandlungsroutine je nach Konfiguration die Fehlermeldung auf die Konsole schreibt und abbricht oder die Fehlermeldung in eine LiDIA::Exception packt und wirft. Das ist von einem puristischen Standpunkt aus zwar nicht optimal, aber man kann schließlich nicht alles haben :-) Gruß Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA-CA: http://www.informatik.tu-darmstadt.de/TI/Forschung/LiDIA-CA/ From cludwig@cdc.informatik.tu-darmstadt.de Tue May 28 17:34:45 2002 Return-Path: Delivered-To: lidia-develop@mailhost.cdc.informatik.tu-darmstadt.de Received: from cdc-ws9.cdc.informatik.tu-darmstadt.de (cdc-ws9 [130.83.23.69]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 84EFC2C95 for ; Tue, 28 May 2002 17:34:45 +0200 (MET DST) Received: (from cludwig@localhost) by cdc-ws9.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g4SFYiR29443 for lidia-develop@cdc-ws9.cdc.informatik.tu-darmstadt.de; Tue, 28 May 2002 17:34:44 +0200 (MEST) Date: Tue, 28 May 2002 17:34:44 +0200 From: Christoph Ludwig To: lidia-develop@cdc.informatik.tu-darmstadt.de Message-ID: <20020528173443.B27546@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [LiDIA-develop] gec-Paket im Hauptzweig Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hi, nur zur Information: Harald Baiers gec-Paket befindet sich seit heute in LiDIAs Hauptzweig im CVS. Es wird dann beim naechsten Release (2.1pre6) veroeffentlicht werden. Wie ich inzwischen weiss, bin ich nicht der einzige, der sich an LiDIAs drakonischer Fehlerbehandlung stoert. Ich moechte deshalb erreichen, dass der Benutzer beim Uebersetzen der Bibliothek via configure waehlen kann, ob LiDIA im Fehlerfall eine Exception werfen oder wie bisher das Programm abbrechen soll. (Leider habe ich Stellen gesehen, an denen die Fehlerbehandlungsroutine aus einem Signalhandler heraus aufgerufen wird; das macht die Umstellung etwas aufwendiger...) Falls jemand Einwaende oder konstruktive Vorschlaege hat, bitte ich, diese jetzt vorzubringen! Gruss Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA-CA: http://www.informatik.tu-darmstadt.de/TI/Forschung/LiDIA-CA/ From ccorn@cs.tu-berlin.de Wed May 29 00:05:14 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from Dachs.Bau (brln-d9b80f7c.pool.mediaWays.net [217.184.15.124]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 426AB2C8C for ; Wed, 29 May 2002 00:05:13 +0200 (MET DST) Received: by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386), from userid 500) id E4E7F5DAD; Tue, 28 May 2002 23:59:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386)) with ESMTP id 601ACF8FF for ; Tue, 28 May 2002 23:59:52 +0200 (CEST) Date: Tue, 28 May 2002 23:59:50 +0200 (CEST) From: Christian Cornelssen X-X-Sender: To: Subject: Re: [LiDIA-develop] gec-Paket im Hauptzweig In-Reply-To: <20020528173443.B27546@cdc-ws9.cdc.informatik.tu-darmstadt.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hallo allerseits, On Tue, 28 May 2002, Christoph Ludwig wrote: > Wie ich inzwischen weiss, bin ich nicht der einzige, der sich an > LiDIAs drakonischer Fehlerbehandlung stoert. Ich moechte deshalb > erreichen, dass der Benutzer beim Uebersetzen der Bibliothek via > configure waehlen kann, ob LiDIA im Fehlerfall eine Exception werfen > oder wie bisher das Programm abbrechen soll. (Leider habe ich Stellen > gesehen, an denen die Fehlerbehandlungsroutine aus einem Signalhandler > heraus aufgerufen wird; das macht die Umstellung etwas aufwendiger...) > Falls jemand Einwaende oder konstruktive Vorschlaege hat, bitte ich, > diese jetzt vorzubringen! Exceptions sind mit uneingeschränkten `throw's am besten handzuhaben. Den `throw' in einen lidia_error_handler zu packen, wäre schon deswegen unflexibel. Dann lieber gleich ein richtiges Exception Handling, d.h., `throw's direkt dort, wo der Fehler festgestellt wird, und brauchbare Exception-Klassendefinitionen. lidia_error_handler kann dann für absehbar fatale Fehler reserviert bleiben, wo abort() praktikabel ist. Wenn's konfigurierbar sein soll, schlage ich folgendes Fragment in `LiDIA.h.in' vor: // Define if you want real exception handling. #undef LIDIA_EXCEPTIONS #ifdef LiDIA_EXCEPTIONS #define LIDIA_THROW(x,msgs) { throw x; } #else #define LIDIA_THROW(x,msgs) { lidia_error_handler msgs; } #endif Dann ersetzt man (fast) alle Aufrufe des lidia_error_handler durch solche von LiDIA_THROW mit einem geeigneten Exception-Parameter x. Als msgs-Parameter für LIDIA_THROW ist die *geklammerte* Argumentliste für den lidia_error_handler zu übergeben. Zu den Exception-Klassen: Entwürfe mit einer sinnvollen Klassenhierarchie und wenigen, einfachen Konstruktoren sind wahrscheinlich brauchbarer für `catch' als "flache" Entwürfe mit Unmengen von parametrisierten Konstruktoren. Bis demnächst, Christian Cornelssen From cludwig@cdc.informatik.tu-darmstadt.de Wed May 29 10:52:08 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from cdc-ws9.cdc.informatik.tu-darmstadt.de (cdc-ws9 [130.83.23.69]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id EB1702C8C for ; Wed, 29 May 2002 10:52:07 +0200 (MET DST) Received: (from cludwig@localhost) by cdc-ws9.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g4T8q5g00155 for lidia-develop@cdc.informatik.tu-darmstadt.de; Wed, 29 May 2002 10:52:05 +0200 (MEST) Date: Wed, 29 May 2002 10:52:03 +0200 From: Christoph Ludwig To: lidia-develop@cdc.informatik.tu-darmstadt.de Subject: Re: [LiDIA-develop] gec-Paket im Hauptzweig Message-ID: <20020529105203.B139@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mail-Followup-To: lidia-develop@cdc.informatik.tu-darmstadt.de References: <20020528173443.B27546@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from ccorn@cs.tu-berlin.de on Tue, May 28, 2002 at 11:59:50PM +0200 Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hi, On Tue, May 28, 2002 at 11:59:50PM +0200, Christian Cornelssen wrote: > On Tue, 28 May 2002, Christoph Ludwig wrote: [...]> > Ich moechte deshalb > > erreichen, dass der Benutzer beim Uebersetzen der Bibliothek via > > configure waehlen kann, ob LiDIA im Fehlerfall eine Exception werfen > > oder wie bisher das Programm abbrechen soll. [...] > Exceptions sind mit uneingeschränkten `throw's am besten handzuhaben. > Den `throw' in einen lidia_error_handler zu packen, wäre schon > deswegen unflexibel. Dann lieber gleich ein richtiges Exception > Handling, d.h., `throw's direkt dort, wo der Fehler festgestellt wird, > und brauchbare Exception-Klassendefinitionen. Wieso ist ein throw in einer Fehlerbehandlungsroutine unflexibel? Das geworfene Objekt kann doch als Parameter übergeben werden. > > lidia_error_handler kann dann für absehbar fatale Fehler > reserviert bleiben, wo abort() praktikabel ist. > > Wenn's konfigurierbar sein soll, schlage ich folgendes Fragment in > `LiDIA.h.in' vor: > > // Define if you want real exception handling. > #undef LIDIA_EXCEPTIONS > > #ifdef LiDIA_EXCEPTIONS > #define LIDIA_THROW(x,msgs) { throw x; } > #else > #define LIDIA_THROW(x,msgs) { lidia_error_handler msgs; } > #endif Makros sind manchmal notwendig, speziell wenn das Programm zur Compilezeit konfiguriert werden soll. Dennoch sollte Ihr Einsatz auf möglichst wenige Stellen im Code reduziert bleiben; lidia_error_handler wird aber sehr häufig aufgerufen. Was spricht gegen folgenden Ansatz: namespace LiDIA { class BasicError : public std::runtime_error { public: explicit BasicError(const std::string& msg); // ... virtual void traditional_error_handler() const; }; BasicError::BasicError(const std::string& msg) : std::runtime_error(msg) { } void BasicError::traditional_error_handler() const { lidia_error_handler(what()); } void error_handler(const BasicError& ex) { #ifdef LiDIA_EXCEPTIONS throw ex; #else ex.traditional_error_handler(); #endif } } Dort, wo jetzt lidia_error_handler(msg) aufgerufen wird, würde man dann einfach error_handler(BasicError(msg)) schreiben. Konsequenzen: a) Die Umstellung wäre mit geringem Aufwand verbunden. Wird die Bibliothek ohne Exceptions konfiguriert, so ändert sich nichts am Verhalten des bestehenden Codes. b) Die Makros treten nur an einer Stellein Erscheinung, nämlich in der Definition von error_handler. c) Bei neuem Code kann man sehr einfach die Fehlermeldungen mit zusätzlichen Informationen versehen, die evtl. bei der Fehlerbehandlung helfen. Man muss lediglich eine neue Exception von BasicError ableiten. Will man bei der "traditionellen" Fehlerbehandlung diese Zusatzinfos ebenfalls ausgeben, kann man dies leicht durch Überschreiben von BasicError::traditional_error_handler() erreichen. BTW: Ich verstoße hier bewusst gegen die gängige Designregel, Klassen, die als innere Knoten in einer Vererbungshierarchie vorgesehen sind, abstrakt zu deklarieren. d) Stellt sich bei der Fehlerbehandlung heraus, dass die Situation "hoffnungslos" ist und das Programm doch abgebrochen werden muss, erhält man die ursprünglich vorgesehene Fehlermeldung mittels try { // some LiDIA function throws... } catch(LiDIA::BasicError& ex) { // Can we recover? ... No! ex.traditional_error_handler(); } > Zu den Exception-Klassen: Entwürfe mit einer sinnvollen > Klassenhierarchie und wenigen, einfachen Konstruktoren sind > wahrscheinlich brauchbarer für `catch' als "flache" Entwürfe > mit Unmengen von parametrisierten Konstruktoren. Fürs erste würde BasicError ausreichen. Wenn neue Pakete entstehen oder bestehende renoviert werden, können die jeweiligen Autoren Exception-Klassen nach Bedarf hinzufügen. Wie kompliziert die Konstruktoren sind, sollte uns nicht kümmern, weil die Benutzer ohnehin keinen Grund haben, die spezialisierten Exceptions zu erzeugen. (In der Regel würde ich die speziellen Exceptions in einem anonymen Namespace oder mit privatem Konstruktor definieren, so dass es ausserhalb des Paketes keine Möglichkeit gibt, derartige Objekte zu kreieren. Doch das muss man wohl im Einzelfall entscheiden.) Gruß Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA-CA: http://www.informatik.tu-darmstadt.de/TI/Forschung/LiDIA-CA/ From ccorn@cs.tu-berlin.de Wed May 29 21:22:40 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from Dachs.Bau (brln-3e36e59d.pool.mediaWays.net [62.54.229.157]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 8371B2C9B for ; Wed, 29 May 2002 21:22:38 +0200 (MET DST) Received: by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386), from userid 500) id CBCAA5DAD; Wed, 29 May 2002 18:04:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386)) with ESMTP id 574FEF8FF for ; Wed, 29 May 2002 18:04:21 +0200 (CEST) Date: Wed, 29 May 2002 18:04:20 +0200 (CEST) From: Christian Cornelssen X-X-Sender: To: Subject: Re: [LiDIA-develop] Exception Handling In-Reply-To: <20020529105203.B139@cdc-ws9.cdc.informatik.tu-darmstadt.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hallo allerseits, On Wed, 29 May 2002, Christoph Ludwig wrote: > Wieso ist ein throw in einer Fehlerbehandlungsroutine unflexibel? > Das geworfene Objekt kann doch als Parameter übergeben werden. Werfen geschieht nicht mit der Konstruktion, sondern erst mit dem `throw'. Es handelt sich also um ein zu werfendes Objekt, nicht um ein geworfenes. Und daraus ergibt sich das Problem mit den Wrapper-Funktionen, die ihre Argumente uniformieren. Korrigiere mich, wenn ich mich irre, aber void error_handler(const BasicError& ex) kann ex nur noch als BasicError-Exception werfen. Die Attribute und virtuellen Funktionen von ex bleiben zwar erhalten, aber die einzige Möglichkeit eines `catch' ist trotzdem catch(const BasicError& ex) { ... } weil der `throw' keine Anwendung von RTTI-Methoden impliziert. Demzufolge bräuchte man innerhalb des `catch'-Rumpfes spezielle Tests und `dynamic_cast's, um auf Attribute von abgeleiteten Fehlerklassen zugreifen zu können. Richtig? Bei direkten `throw's hätte man dieses Problem nicht... Nebenbei bemerkt, wird der lidia_error_handler mit variierender Argumentzahl (mindestens zwei) aufgerufen. Deswegen der Umstand mit dem msgs-Parameter! Ein "lidia_error_handler(what())" ist in diesem Zusammenhang etwas noch nicht Dagewesenes. (Wobei ich gegen eine dahin gehende Vereinheitlichung nichts einzuwenden hätte, da das eigentliche Exception Handling entweder schon vorher oder gar nicht stattfinden soll.) > Makros sind manchmal notwendig, speziell wenn das Programm zur > Compilezeit konfiguriert werden soll. Dennoch sollte Ihr Einsatz auf > möglichst wenige Stellen im Code reduziert bleiben; Der gewünschte Effekt kann auch mit Template-Funktionen erreicht werden, aber ein Makro erscheint mir hier viel durchsichtiger. Gespannt auf den nächsten Entwurf, Christian Cornelssen From cludwig@cdc.informatik.tu-darmstadt.de Thu May 30 14:10:47 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from cdc-ws9.cdc.informatik.tu-darmstadt.de (cdc-ws9 [130.83.23.69]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 6FB4F2C8C for ; Thu, 30 May 2002 14:10:47 +0200 (MET DST) Received: (from cludwig@localhost) by cdc-ws9.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g4UCAko17517 for lidia-develop@cdc.informatik.tu-darmstadt.de; Thu, 30 May 2002 14:10:46 +0200 (MEST) Date: Thu, 30 May 2002 14:10:45 +0200 From: Christoph Ludwig To: lidia-develop@cdc.informatik.tu-darmstadt.de Subject: Re: [LiDIA-develop] Exception Handling Message-ID: <20020530141045.A17319@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mail-Followup-To: lidia-develop@cdc.informatik.tu-darmstadt.de References: <20020529105203.B139@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from ccorn@cs.tu-berlin.de on Wed, May 29, 2002 at 06:04:20PM +0200 Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hi, On Wed, May 29, 2002 at 06:04:20PM +0200, Christian Cornelssen wrote: > On Wed, 29 May 2002, Christoph Ludwig wrote: > > > Wieso ist ein throw in einer Fehlerbehandlungsroutine unflexibel? > > Das geworfene Objekt kann doch als Parameter übergeben werden. > > Werfen geschieht nicht mit der Konstruktion, sondern erst mit dem > `throw'. Es handelt sich also um ein zu werfendes Objekt, nicht > um ein geworfenes. Und daraus ergibt sich das Problem mit den > Wrapper-Funktionen, die ihre Argumente uniformieren. Korrigiere mich, > wenn ich mich irre, aber > > void error_handler(const BasicError& ex) > > kann ex nur noch als BasicError-Exception werfen. Argh! Hat mich das Object Slicing 'mal wieder auf dem falschen Fuß erwischt! > Die > Attribute und virtuellen Funktionen von ex bleiben zwar erhalten, > aber die einzige Möglichkeit eines `catch' ist trotzdem > > catch(const BasicError& ex) { ... } > > weil der `throw' keine Anwendung von RTTI-Methoden impliziert. > Demzufolge bräuchte man innerhalb des `catch'-Rumpfes spezielle Tests > und `dynamic_cast's, um auf Attribute von abgeleiteten Fehlerklassen > zugreifen zu können. Richtig? Nein. Denn dem Handler wird nicht das geworfene Objekt selbst, sondern eine mit dem Copy-Konstruktor initialisierte *Kopie* übergeben, selbst wenn man die Regel "catch by reference" befolgt (vgl. 15.1p3 im C++ Standard). Bis der catch-Block betreten wird, existiert nur noch ein Objekt vom Typ BasicError, da hilft auch dynamic_cast nichts mehr. Wie ich schon sagte, ich bin auf das klassische Object Slicing hereingefallen. > Nebenbei bemerkt, wird der lidia_error_handler mit variierender > Argumentzahl (mindestens zwei) aufgerufen. Deswegen der Umstand mit > dem msgs-Parameter! Ein "lidia_error_handler(what())" ist in diesem > Zusammenhang etwas noch nicht Dagewesenes. (Wobei ich gegen eine dahin > gehende Vereinheitlichung nichts einzuwenden hätte, da das eigentliche > Exception Handling entweder schon vorher oder gar nicht stattfinden > soll.) Das kommt davon, wenn man sich auf das Handbuch verlässt... :-) Die zwei Parameter des Defaulthandlers habe ich stillschweigend in "msg" zusammengefasst, weil dies für die Beschreibung meiner Idee keine Rolle spielte. Das Makro lidia_error_handler_c ist zwar m.E. völlig unnötig und sollte in Zukunft als "deprecated" betrachtet werden, aber es kommt dem von mir in den Raum gestellten Entwurf nicht in die Quere. Wir müssten lediglich in seiner Definition wie überall sonst auch den Aufruf von lidia_error_handler anpassen. Dass sich unter der Haube noch zahlreiche Function Templates befinden, die offensichtlich benutzt werden sollen, wenn die Vorbedingungenen einer Funktion nicht eingehalten wurden, ist mir freilich entgangen. Vorausgesetzt wir bekommen den Typ der geworfenen Exception in den Griff, stellen diese Function Templates aber kein Problem dar. Wir müssen sie lediglich in geeignete Class Templates transformieren, die jeweils von BasicError abgeleitet sind. Lästig, aber einfach. > > Makros sind manchmal notwendig, speziell wenn das Programm zur > > Compilezeit konfiguriert werden soll. Dennoch sollte Ihr Einsatz auf > > möglichst wenige Stellen im Code reduziert bleiben; > > Der gewünschte Effekt kann auch mit Template-Funktionen erreicht > werden, Ganz Deiner Meinung, s.u. > aber ein Makro erscheint mir hier viel durchsichtiger. Das bezweifle ich hingegen. Dass lidia_error_handler genaugenommen ein Funktionszeiger ist, kann man im Debugger ja noch feststellen, so dass sich die Überraschung in Grenzen halten dürfte, wenn man plötzlich in einer Funktion mit anderem Namen landet. Aber wenn man den Aufruf hinter einem Makro versteckt, wird der Programmfluss noch obskurer; die meisten Debugger tun sich mit Makros schwer. Bei dem von Dir vorgeschlagenen Makro muss man zudem die Fehlerinformation im wesentlichen zweimal übergeben; sowohl in der Exception als auch in den Argumenten an lidia_error_handler. Ich bin überzeugt, über kurz oder lang würde entweder die Exception oder die Fehlermeldung nur noch generische Infos enthalten, je nachdem ob der jeweilige Entwickler Exceptions nutzt oder nicht. Wegen der automatischen Ableitung der Template Argumente beim Aufruf einer Templatefunktion bekoomt weder ein Anwender der Bibliothek noch ein Entwickler notwendigerweise mit, dass Templates im Spiel sind. Hier ist also mein nächster Versuch: namespace LiDIA { class BasicError : public std::runtime_error { public: explicit BasicError(const std::string& msg); BasicError(const std::string& classname, const std::string& msg); // ... virtual void traditional_error_handler() const; }; BasicError::BasicError(const std::string& msg) : std::runtime_error(msg) { } BasicError(const std::string& classname, const std::string& msg) : std::runtime(classname + "::" + msg) { } void BasicError::traditional_error_handler() const { lidia_error_handler(what()); } template inline void error_handler(const ExceptionType& ex) { // Maybe we want a compile time assert to make // sure ExceptionType is derived from BasicError. #ifdef LiDIA_EXCEPTIONS throw ex; #else ex.traditional_error_handler(); #endif } } Das Function Template error_handler muss leider in einem Header definiert werden. Weil es aber so oder so nicht mehr als ein Statement enthält, dürfte dies keinen Code Bloat verursachen. Das gilt übrigens auch, falls wir uns entschließen sollten, zu erzwingen, dass ExceptionType von BasicError abgeleitet ist. Compile Time Asserts erzeugen typischerweise keinen Assemblercode. (Zumindest, falls nicht mit Compileroption -O0 übersetzt wird.) Das Makro LiDIA_EXCEPTIONS taucht jetzt strenggenommen zwar in allen Translation Units auf, die den entsprechenden Header einbinden, doch ist es nach wie vor auf eine Funktion in einer Datei beschränkt. NB: Partial Specialization verbietet sich hier, weil wir dann wegen der partiellen Ordnung auf Function Templates wieder bei meinem ursprünglichen Entwurf wären. Ein Funktionsaufruf error_handler(MyExceptionClass(/* as many arguments as you like */)); wirft jetzt tatsächlich eine Exception vom Typ MyExceptionClass, falls LiDIA_EXCEPTIONS definiert ist. Andernfalls wird das Programm wie gewohnt mit einer Fehlermeldung abgebrochen. Die bisherigen Aufrufe von lidia_error_handler(classname, msg) würden jetzt geändert zu error_handler(BasicError(classname, msg)); Kommentare? Gruß Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA-CA: http://www.informatik.tu-darmstadt.de/TI/Forschung/LiDIA-CA/ From ccorn@cs.tu-berlin.de Thu May 30 16:10:24 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from Dachs.Bau (brln-d9b8014b.pool.mediaWays.net [217.184.1.75]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id EC1512C8C for ; Thu, 30 May 2002 16:10:23 +0200 (MET DST) Received: by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386), from userid 500) id 39F7E5DAD; Thu, 30 May 2002 16:12:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386)) with ESMTP id 8147DF8FF for ; Thu, 30 May 2002 16:12:50 +0200 (CEST) Date: Thu, 30 May 2002 16:12:50 +0200 (CEST) From: Christian Cornelssen X-X-Sender: To: Subject: Re: [LiDIA-develop] Exception Handling In-Reply-To: <20020530141045.A17319@cdc-ws9.cdc.informatik.tu-darmstadt.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hallo, On Thu, 30 May 2002, Christoph Ludwig wrote: > Bei dem von Dir vorgeschlagenen Makro muss man zudem die > Fehlerinformation im wesentlichen zweimal übergeben; sowohl in der > Exception als auch in den Argumenten an lidia_error_handler. Ich > bin überzeugt, über kurz oder lang würde entweder die Exception oder > die Fehlermeldung nur noch generische Infos enthalten, je nachdem ob > der jeweilige Entwickler Exceptions nutzt oder nicht. Ja, war nicht schön, hätte weitere "Convenience"-Makros nach sich gezogen. Hier nochmal Dein Entwurf, den ich schon ganz gut finde: > namespace LiDIA { > class BasicError : public std::runtime_error { > public: > explicit BasicError(const std::string& msg); > BasicError(const std::string& classname, const std::string& msg); > // ... > virtual void traditional_error_handler() const; > }; > > BasicError::BasicError(const std::string& msg) > : std::runtime_error(msg) { > } > > BasicError(const std::string& classname, const std::string& msg) > : std::runtime(classname + "::" + msg) { > } > > void BasicError::traditional_error_handler() const { > lidia_error_handler(what()); > } > > template > inline > void error_handler(const ExceptionType& ex) { > // Maybe we want a compile time assert to make > // sure ExceptionType is derived from BasicError. > #ifdef LiDIA_EXCEPTIONS > throw ex; > #else > ex.traditional_error_handler(); > #endif > } > } Auch wenn Du keine Makros magst, betrachte einmal anstelle der inline-Template-Funktionsdefinition des error_handler folgende Variante: #ifdef LiDIA_EXCEPTIONS #define error_handler(ex) { throw (ex); } #else #define error_handler(ex) { (ex).traditional_error_handler(); } #endif Sie bietet garantiertes Inlining UND den Compile-Time-Check, dass (ex) eine Member-Funktion namens traditional_error_handler() hat. Dass error_handler ein Makro ist, dürfte eigentlich nicht stören, da es den Aufruf gewissermaßen nur in einen anderen übersetzt. Beide Varianten unterscheiden sich nur noch in der Definition des error_handler, die in einer Header-Datei lokalisiert sein wird. Für die Benutzung ergeben sich keine Unterschiede: > Ein Funktionsaufruf > > error_handler(MyExceptionClass(/* as many arguments as you like */)); > > wirft jetzt tatsächlich eine Exception vom Typ MyExceptionClass, falls > LiDIA_EXCEPTIONS definiert ist. Andernfalls wird das Programm wie > gewohnt mit einer Fehlermeldung abgebrochen. > > Die bisherigen Aufrufe von lidia_error_handler(classname, msg) würden > jetzt geändert zu > > error_handler(BasicError(classname, msg)); ACK. Viele Grüße, Christian Cornelssen From Stefan.Neis@t-online.de Thu May 30 19:17:55 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 686A12C8C for ; Thu, 30 May 2002 19:17:55 +0200 (MET DST) Received: from fwd11.sul.t-online.de by mailout03.sul.t-online.com with smtp id 17DTYg-0004Cf-07; Thu, 30 May 2002 19:17:54 +0200 Received: from smtprelay.t-online.de (333100012182-0001@[217.4.179.55]) by fmrl11.sul.t-online.com with smtp id 17DTYe-0T4EXQC; Thu, 30 May 2002 19:17:52 +0200 To: lidia-develop@cdc.informatik.tu-darmstadt.de Priority: Normal Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0) Date: Thu, 30 May 2002 19:17:50 From: Stefan.Neis@t-online.de Subject: Re: [LiDIA-develop] Exception Handling Message-ID: <17DTYe-0T4EXQC@fmrl11.sul.t-online.com> X-Sender: 333100012182-0001@t-dialin.net Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hallo, > > template > inline > void error_handler(const ExceptionType& ex) { > // Maybe we want a compile time assert to make > // sure ExceptionType is derived from BasicError. > #ifdef LiDIA_EXCEPTIONS > throw ex; > #else > ex.traditional_error_handler(); > #endif > } > } > > Das Function Template error_handler muss leider in einem Header > definiert werden. Weil es aber so oder so nicht mehr als ein Statement > enth=E4lt, d=FCrfte dies keinen Code Bloat verursachen. > > Kommentare? Ich habe wie immer so meine Zweifel mit der Template-Instantiierung... Ich glaube nicht, dass der Compiler _irgendetwas_ automatisch instantiiert, wenn man mit -fno-implicit-templates compiliert, auch keine inline-Funktionen. Ich fuerchte, da braucht man ein Instantiierungs- file, in dem man das exlizit f=FCr alle "ExceptionType"s, die auftauchen, instantiiert. :-( Gruss, Stefan From ccorn@cs.tu-berlin.de Fri May 31 04:58:12 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from Dachs.Bau (brln-d9b81ce8.pool.mediaWays.net [217.184.28.232]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 6A25B2C8C for ; Fri, 31 May 2002 04:58:11 +0200 (MET DST) Received: by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386), from userid 500) id A714B5DAD; Fri, 31 May 2002 04:59:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386)) with ESMTP id 3320DF8FF for ; Fri, 31 May 2002 04:59:46 +0200 (CEST) Date: Fri, 31 May 2002 04:59:45 +0200 (CEST) From: Christian Cornelssen X-X-Sender: To: Subject: Re: [LiDIA-develop] Exception Handling In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hallo allerseits, On Thu, 30 May 2002, Christian Cornelssen wrote: > Auch wenn Du keine Makros magst, betrachte einmal anstelle der > inline-Template-Funktionsdefinition des error_handler folgende > Variante: > > #ifdef LiDIA_EXCEPTIONS > #define error_handler(ex) { throw (ex); } > #else > #define error_handler(ex) { (ex).traditional_error_handler(); } > #endif > > Sie bietet garantiertes Inlining UND den Compile-Time-Check, dass > (ex) eine Member-Funktion namens traditional_error_handler() hat. > Dass error_handler ein Makro ist, dürfte eigentlich nicht stören, > da es den Aufruf gewissermaßen nur in einen anderen übersetzt. Das habe ich ein bisschen blöd ausgedrückt. Gemeint ist, dass die inline-Variante (wenn sie funktioniert) und die Makro-Variante genau den gleichen Code erzeugen. Einen "Aufruf" von error_handler wird man im Debugger bei keiner der beiden Varianten finden. Ich bevorzuge die Makro-Variante, weil der Compiler sich dabei nicht querstellen kann :-) Nun noch einmal zur Benutzung: > > Ein Funktionsaufruf > > > > error_handler(MyExceptionClass(/* as many arguments as you like */)); > > > > wirft jetzt tatsächlich eine Exception vom Typ MyExceptionClass, falls > > LiDIA_EXCEPTIONS definiert ist. Andernfalls wird das Programm wie > > gewohnt mit einer Fehlermeldung abgebrochen. > > > > Die bisherigen Aufrufe von lidia_error_handler(classname, msg) würden > > jetzt geändert zu > > > > error_handler(BasicError(classname, msg)); Das ist schon viel schöner als der lidia_error_handler-Kram. Wenn man aber Exceptions WIRKLICH benutzen können will, sollte man besseren Stoff werfen, nicht bloss den BasicError-Einheitsbrei, denn das erfordert eingehende Untersuchungen innerhalb der `catch'-Rümpfe, die man sich mit dem C++-Exception-Modell wirklich ersparen kann und ersparen sollte. Zumindest bei denjenigen Exceptions, die nicht ohne weiteres auf falsche Programmierung zurückzuführen sind, weil sie von Laufzeit-Eingabedaten verursacht werden können, empfehle ich, die künftigen Exception-Klassen und throw-Spezifikationen als "subject to change" zu kennzeichnen, damit man allmählich eine brauchbare Ausnahmehierarchie entwickeln kann. Zum besseren Verständnis lasse ich ein wenig allgemeines Gelaber folgen. Beispiel: Sei Float eine Gleitkommaklasse, die vorzeichenbehaftetete Nullen, aber keine Unendlichkeiten unterstützt. // Problem: Steigungsdreieck. // Gegeben: Steigungswinkel alpha, Höhe h. // Gesucht: Breite b. Float Breite (Float alpha, Float h) { return h / tan(alpha); } Mögliche Ausnahmefälle: (a) alpha == 0 (mod Pi) => Division durch Null in Breite(...) (b) alpha == +/-Pi/2 (mod Pi) => Division durch Null in tan(alpha) Letzteres z.B. weil tan(alpha) = 1/tan(Pi/2-alpha). Diese Ausnahme ist behebbar; das Resultat von Breite(alpha,h) sollte eine Null mit sinnvollem Vorzeichen sein. Mit einer stumpfsinnigen Float::Exception kommt man nicht weit. Stattdessen wäre es angebracht, eine sinnvolle Exception-Hierarchie zu konstruieren: Float::Exception::Basic : runtime_error Float::Exception::Binary : Float::Exception::Basic // mit Operanden Float::Exception::DivByZero : Float::Exception::Binary Float::Exception::RightAngle : Float::Exception::DivByZero tan(alpha) fängt intern Float::Exception::DivByZero an der richtigen Stelle ab und wirft sie als Float::Exception::RightAngle weiter, wobei die Operanden bei 1,+/-0 belassen werden. Das Vorzeichen der Null deutet auf das Vorzeichen des reduzierten Winkels (+/-Pi/2) hin. Andere Exceptions (ggf. auch DivByZero an anderer Stelle) werden ohne "Veredelung" durchgeworfen! Somit kann Breite(alpha,h) intern zuverlässig Float::Exception::RightAngle abfangen und benutzen, um eine korrekt vorzeichenbehaftete Null zurückzuliefern. Nun sollte auch die Breite-Funktion ähnlich informativ sein und den Fall alpha == 0 (mod Pi) besonders kennzeichnen, also Float::Exception::DivByZero abfangen und als Float::Exception::StraightAngle : Float::Exception::DivByZero weiterkicken. Das mag hier übertrieben erscheinen, aber es erleichtert in komplexeren Umgebungen die eindeutige Identifizierung der Ausnahme. Auf diese Weise braucht man in `catch'-Rümpfen keine Untersuchungen anzustellen, was denn der Fehler sein könnte, da bereits die Fehlerklasse alles aussagt. `catch'-Rümpfe, die lediglich den allgemeineren Fehlertyp DivByZero erkennen wollen, können weiterhin auf diese Basisklasse testen. Allgemein kann man beim Weiterkicken zusätzliche Information mitgeben, indem man die abgeleiteten Fehlerklassen um entsprechende Attribute erweitert. In obigem Beispiel könnte in RightAngle der betreffende Winkel direkt mitgeliefert werden. Oder beim Dividieren mod N könnte der GCD mitgeliefert werden. Sehr praktisch für ECM-Faktorisierung. Das Abfangen und Weiterkicken mag lästig erscheinen, da es zusätzliche `catch'-Rümpfe in den Funktionen erfordert, aber erstens sind diese `catch'-Rümpfe sehr einfach, wenn man sich konsequent an das Prinzip "Spezielle Interpretation einer Ausnahme = abgeleitete Ausnahme" hält, und zweitens ist dies die angemessene Weise, Informationen über die Ausnahme zu kapseln. Es mag plausibel erscheinen, beim Lösen eines Gleichungssystems aus einer DivByZero auf die Nichteindeutigkeit der Lösung zu schließen, aber wenn der Implementor des Gleichungslösers eine dahingehende Spezifikation leisten muss, tut er besser daran, diese Exception an geeigneter Stelle zu veredeln. Viele Grüße, Christian Cornelssen From cludwig@cdc.informatik.tu-darmstadt.de Fri May 31 11:46:43 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from cdc-ws9.cdc.informatik.tu-darmstadt.de (cdc-ws9 [130.83.23.69]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id D96C92C8C for ; Fri, 31 May 2002 11:46:42 +0200 (MET DST) Received: (from cludwig@localhost) by cdc-ws9.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g4V9keV25220 for lidia-develop@cdc.informatik.tu-darmstadt.de; Fri, 31 May 2002 11:46:40 +0200 (MEST) Date: Fri, 31 May 2002 11:46:40 +0200 From: Christoph Ludwig To: lidia-develop@cdc.informatik.tu-darmstadt.de Subject: Re: [LiDIA-develop] Exception Handling Message-ID: <20020531114639.D17679@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mail-Followup-To: lidia-develop@cdc.informatik.tu-darmstadt.de References: <17DTYe-0T4EXQC@fmrl11.sul.t-online.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <17DTYe-0T4EXQC@fmrl11.sul.t-online.com>; from Stefan.Neis@t-online.de on Thu, May 30, 2002 at 07:17:50PM +0000 Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hallo, On Thu, May 30, 2002 at 07:17:50PM +0000, Stefan.Neis@t-online.de wrote: > > template > > inline > > void error_handler(const ExceptionType& ex) { > > // Maybe we want a compile time assert to make > > // sure ExceptionType is derived from BasicError. > > #ifdef LiDIA_EXCEPTIONS > > throw ex; > > #else > > ex.traditional_error_handler(); > > #endif > > } > > } > > > > Das Function Template error_handler muss leider in einem Header > > definiert werden. Weil es aber so oder so nicht mehr als ein Statement > > enthält, dürfte dies keinen Code Bloat verursachen. > > > > Kommentare? > > Ich habe wie immer so meine Zweifel mit der Template-Instantiierung... > Ich glaube nicht, dass der Compiler _irgendetwas_ automatisch > instantiiert, wenn man mit -fno-implicit-templates compiliert, auch > keine inline-Funktionen. Ich fuerchte, da braucht man ein Instantiierungs- > file, in dem man das exlizit für alle "ExceptionType"s, die auftauchen, > instantiiert. :-( Stefans Einwand ist korrekt; alle benötigten Templates müssen wir explizit instantiieren. Wie das geschehen muss, ist klar, weil wir es bereits z.B. bei den Vektor- und Matrixklassen praktizieren. Es ist auch nicht besonders schwierig, aber wegen der wenig intuitiven Template-Syntax durchschaut man die Konstruktion erst bei genauerem Hinsehen. Das fügt LiDIA möglicherweise unerwünschte Komplexität hinzu. Andererseits betrifft dies nur die LiDIA-Entwickler. Weshalb sollte ein Anwender neue LiDIA-Exceptions definieren? Eine Konsequenz ist übrigens, dass das Headerfile doch nur eine Deklaration des Function Templates enthalten muss, keine mit "inline" versehene Definition. On Thu, May 30, 2002 at 04:12:50PM +0200, Christian Cornelssen wrote: > Auch wenn Du keine Makros magst, betrachte einmal anstelle der > inline-Template-Funktionsdefinition des error_handler folgende > Variante: > > #ifdef LiDIA_EXCEPTIONS > #define error_handler(ex) { throw (ex); } > #else > #define error_handler(ex) { (ex).traditional_error_handler(); } > #endif > > Sie bietet garantiertes Inlining UND den Compile-Time-Check, dass > (ex) eine Member-Funktion namens traditional_error_handler() hat. > Dass error_handler ein Makro ist, dürfte eigentlich nicht stören, > da es den Aufruf gewissermaßen nur in einen anderen übersetzt. > > Beide Varianten unterscheiden sich nur noch in der Definition des > error_handler, die in einer Header-Datei lokalisiert sein wird. Inlining ist ein QoI issue, es gibt also keine Garantie vom Standard, wann ein Compiler einen Funktionsaufruf ersetzt. (Streng genommen hat das Schlüsselwort "inline" nur Auswirkungen in Bezug auf die One Definition Rule und auf die Linkage (wer weiss ein deutsches Wort dafür?) der Funktionen.) Wer LiDIA mit einem Compiler baut, der bei einer Releaseversion hier nicht inlined (von der Template-Intantiierungsproblematik abgesehen), wird aber ohnehin keine Freude haben. Das Programm möchte ich sehen, das Performanceprobleme hat, wenn der Aufruf der Fehlerbehandlungsroutine nicht inlined ist. In der bisherigen Implementierung konnte dieser Aufruf jedenfalls nicht mehr als einmal erfolgen... :-) Ich hatte das Inlining nur wegen des potentiellen Code Bloats erwähnt, der hier aber so oder so nicht zu befürchten wäre. Die Existenz der Elementfunktion traditional_error_handler() wird bei der Templatelösung zum Zeitpunkt der Instantiierung sichergestellt; ebenso wie bei Christians Makro-Lösung ist es aber eine syntaktische Prüfung. Jede Klasse mit einer Funktion dieses Namens würde akzeptiert. Ich halte aber eine Garantie für sinnvoll, dass LiDIA nur Exceptions aus einer bestimmten Hierrachie wirft. Das ermöglicht einem Benutzerprogramm, dass im Fehlerfall ausschließlich den geordneten Rückzug antreten möchte, nur LiDIA::BasicError zu fangen und trotzdem keine Probleme mit uncaught exceptions zu bekommen. Wir können natürlich niemanden mit C++-Mitteln daran hindern, mitten in einer LiDIA-Routine einen Ausdruck "throw 42;" einzufügen. Aber zumindest für die Benutzer des vorgesehenen Error Handlers könnten wir mit einem Compile Time Assert eine zusätzliche Überprüfung einbauen. Für das Design spielt das aber letzlich keine Rolle und sollte uns deshalb vorerst kein Kopfzerbrechen bereiten. Meine Abneigung gegen die Einführung neuer Makros hat einen Grund: Der Präprozessor kümmert sich keinen Deut um die Name Lookup Regeln von C++. Das Symbol "error_handler" wäre in allen LiDIA-Programmen effektiv verboten, völlig gleichgültig in welchem Namespace, ob als Name einer freien oder Elementfunktion oder als Variablennamen. Warum hat sich Safuat die Mühe gemacht, alles in den Namespace ::LiDIA einzupacken, wenn wir jetzt wieder den globalen Namensraum mit Makros kontaminieren?? Es ist leicht vorstellbar, dass ein Anwendungsprogramm oder eine andere Bibliothek ebenfalls eine Funktion error_handler() definiert. Deshalb müsste unser Makro lidia_new_error_handler o.ä. heißen. Damit sind wir aber wieder bei der Präfixkonvention, die eigentlich obsolet ist. Ich votiere deswegen nach wie vor für die Templates. Ich werde mal in einem Branch ausprobieren, ob sich damit irgendwelche Probleme ergeben, die wir noch nicht erkannt haben. Im Hinblick auf das Design der Exceptionhierarchie: Dieses Problem stellt sich wohl erst, wenn wieder ein neues LiDIA-Paket entwickelt oder ein bestehendes generalsaniert wird. Ich gehe deshalb davon aus, dass kurz- bis mittelfristig kein noch so eleganter Entwurf umgesetzt werden wird. Bis dahin wird jede Diskussion mehr oder weniger abstract nonsense bleiben. Gruß Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA-CA: http://www.informatik.tu-darmstadt.de/TI/Forschung/LiDIA-CA/ From ccorn@cs.tu-berlin.de Fri May 31 15:50:21 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from Dachs.Bau (brln-d9b82e3c.pool.mediaWays.net [217.184.46.60]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 2E07E2C8C for ; Fri, 31 May 2002 15:50:21 +0200 (MET DST) Received: by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386), from userid 500) id 226B95DAD; Fri, 31 May 2002 15:47:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by Dachs.Bau (Postfix on SuSE Linux 7.1 (i386)) with ESMTP id 58D2EF8FF for ; Fri, 31 May 2002 15:47:09 +0200 (CEST) Date: Fri, 31 May 2002 15:47:06 +0200 (CEST) From: Christian Cornelssen X-X-Sender: To: Subject: Re: [LiDIA-develop] Exception Handling In-Reply-To: <20020531114639.D17679@cdc-ws9.cdc.informatik.tu-darmstadt.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hallo, On Fri, 31 May 2002, Christoph Ludwig wrote: > Eine Konsequenz ist übrigens, dass das Headerfile doch nur eine > Deklaration des Function Templates enthalten muss, keine mit "inline" > versehene Definition. Wie wär's mit einer "inline static" Definition? Dann _muss_ der Compiler instantiieren, da er die Definition nur in der aktuellen Translation Unit finden kann; und der ganze Heckmeck mit dem expliziten Instantiieren entfällt. Ich hab's an einem kleinen Beispiel ausprobiert, und es funktionierte sogar mit "g++ -fno-implicit-templates -fno-inline". > Im Hinblick auf das Design der Exceptionhierarchie: Dieses Problem > stellt sich wohl erst, wenn wieder ein neues LiDIA-Paket entwickelt > oder ein bestehendes generalsaniert wird. Ich gehe deshalb davon aus, > dass kurz- bis mittelfristig kein noch so eleganter Entwurf umgesetzt > werden wird. Bis dahin wird jede Diskussion mehr oder weniger abstract > nonsense bleiben. Wenn der "abstract nonsense" später mit dem Verweis auf Kompatibilätsprobleme gegenstandslos gemacht wird, liegt wieder ein faules Ei im Nest. Also bitte: "Subject to change", und keine Gnade. Wobei das Werfen abgeleiteter Exceptions an sich kein Kompatibilitätsproblem sein muss, aber da alte `catch'es dann z.B. Textstrings untersuchen müssten, und die Fehlermeldungen diversifiziert werden könnten, wäre es besser, hier keine Erwartung eines unveränderten Fortbestands aufkommen zu lassen. Viele Grüße, Christian Cornelssen From cludwig@cdc.informatik.tu-darmstadt.de Fri May 31 16:19:33 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from cdc-ws9.cdc.informatik.tu-darmstadt.de (cdc-ws9 [130.83.23.69]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id D00962C8C for ; Fri, 31 May 2002 16:19:32 +0200 (MET DST) Received: (from cludwig@localhost) by cdc-ws9.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g4VEJVx25318 for lidia-develop@cdc.informatik.tu-darmstadt.de; Fri, 31 May 2002 16:19:31 +0200 (MEST) Date: Fri, 31 May 2002 16:19:20 +0200 From: Christoph Ludwig To: lidia-develop@cdc.informatik.tu-darmstadt.de Subject: Re: [LiDIA-develop] Exception Handling Message-ID: <20020531161920.A25314@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mail-Followup-To: lidia-develop@cdc.informatik.tu-darmstadt.de References: <20020531114639.D17679@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from ccorn@cs.tu-berlin.de on Fri, May 31, 2002 at 03:47:06PM +0200 Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hi, On Fri, May 31, 2002 at 03:47:06PM +0200, Christian Cornelssen wrote: > On Fri, 31 May 2002, Christoph Ludwig wrote: > > > Eine Konsequenz ist übrigens, dass das Headerfile doch nur eine > > Deklaration des Function Templates enthalten muss, keine mit "inline" > > versehene Definition. > > Wie wär's mit einer "inline static" Definition? Dann _muss_ der > Compiler instantiieren, da er die Definition nur in der aktuellen > Translation Unit finden kann; und der ganze Heckmeck mit dem > expliziten Instantiieren entfällt. > > Ich hab's an einem kleinen Beispiel ausprobiert, und es funktionierte > sogar mit "g++ -fno-implicit-templates -fno-inline". Klingt ganz gut. Das Problem ist, dass wir nicht nur den g++ zufrieden stellen wollen. Und Compilerhersteller sind dafür berüchtigt, bei der Templateinstantiierung jeweils eigene Süppchen zu kochen... Ich werde am Wochenende einige Tests durchführen und sehen, wie alle mir zugänglichen Compiler damit zurecht kommen. Dann können wir weitersehen. > > Im Hinblick auf das Design der Exceptionhierarchie: Dieses Problem > > stellt sich wohl erst, wenn wieder ein neues LiDIA-Paket entwickelt > > oder ein bestehendes generalsaniert wird. Ich gehe deshalb davon aus, > > dass kurz- bis mittelfristig kein noch so eleganter Entwurf umgesetzt > > werden wird. Bis dahin wird jede Diskussion mehr oder weniger abstract > > nonsense bleiben. > > Wenn der "abstract nonsense" später mit dem Verweis auf > Kompatibilätsprobleme gegenstandslos gemacht wird, liegt wieder ein > faules Ei im Nest. Also bitte: "Subject to change", und keine Gnade. > > Wobei das Werfen abgeleiteter Exceptions an sich kein > Kompatibilitätsproblem sein muss, aber da alte `catch'es dann z.B. > Textstrings untersuchen müssten, und die Fehlermeldungen > diversifiziert werden könnten, wäre es besser, hier keine > Erwartung eines unveränderten Fortbestands aufkommen zu lassen. Für den momentan bestehenden Code möchte ich ausschließlich die Garantie abgeben, das die geworfenen Exception von BasicError (oder wie auch immer wir die Klasse nennen) abgeleitet sind. Das schließt u.a. den Vorbehalt ein, dass wir künftig einmal spezialisierte Exceptionklassen werfen werden. Dass wir bereits jetzt z.B. an Stelle der lidia_error_handler() mit N Parametern evtl. abgeleitete Exceptions werfen, ist ein undokumentiertes Implementierungsdetail; wie Du sagtest, subject to change. Da sind wir uns, denke ich, völlig einig. Ich möchte lediglich die Debatte, wie die *längerfristig angestrebte* Exceptionhierarchie aussehen soll, nicht jetzt führen. Gruß Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA-CA: http://www.informatik.tu-darmstadt.de/TI/Forschung/LiDIA-CA/ From cludwig@cdc.informatik.tu-darmstadt.de Tue Jun 4 10:45:21 2002 Return-Path: Delivered-To: lidia-develop@mailhost.cdc.informatik.tu-darmstadt.de Received: from cdc-ws9.cdc.informatik.tu-darmstadt.de (cdc-ws9 [130.83.23.69]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 8FB482C88 for ; Tue, 4 Jun 2002 10:45:21 +0200 (MET DST) Received: (from cludwig@localhost) by cdc-ws9.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g548jKb06827 for lidia-develop@cdc-ws9.cdc.informatik.tu-darmstadt.de; Tue, 4 Jun 2002 10:45:20 +0200 (MEST) Date: Tue, 4 Jun 2002 10:45:09 +0200 From: Christoph Ludwig To: lidia-develop@cdc.informatik.tu-darmstadt.de Message-ID: <20020604104509.A6730@cdc-ws9.cdc.informatik.tu-darmstadt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i Subject: [LiDIA-develop] Instantiierung von inline function templates Sender: lidia-develop-admin@cdc.informatik.tu-darmstadt.de Errors-To: lidia-develop-admin@cdc.informatik.tu-darmstadt.de X-BeenThere: lidia-develop@cdc.informatik.tu-darmstadt.de X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: lidia-develop@cdc.informatik.tu-darmstadt.de List-Help: List-Post: List-Subscribe: , List-Id: Discussion forum for active LiDIA developers List-Unsubscribe: , List-Archive: Hi, ich habe am Wochenende ausprobiert, ob error_handler() in dem von mir vorgeschlagenen Entwurf für LiDIAs Fehlerbehandlung als inline-Funktion automatisch instantiiert wird. Das Ergebnis: g++ 2.95, 3.0: inline Function Templates werden auch dann automatisch instantiiert, wenn die Kommandozeilenoption '-fno-implicit-templates' angegeben ist. Dies wird nur durch die Option '-fno-implicit-inline-templates' unterdrückt. Wir haben freilich keinen Grund, letzteren Schalter zu benutzen... Das Verhalten ist jedenfalls in den info-Pages des gcc dokumentiert, so dass wir uns darauf wohl verlassen können. SunCC (WorkShop 6, C++ 5.1): Die Doku lässt sich nicht zu inline Function Templates aus. Aber das Testprogramm ließ sich problemlos übersetzen, binden und ausführen, auch wenn ich die automatische Instantiierung abgeschaltet hatte (Option: '-instances=explicit'). Weil Sun bei der Weiterentwicklung seiner Compiler extrem konservativ vorgeht (um es positiv auszudrücken :-), gehe ich davon aus, dass sich die Folgeversionen des Compilers ebenso verhalten. Comeau 4.2.45.2 (Linux): Die Dokumentation sagt, dass inline Function Templates immer instantiiert werden, auch wenn die automatische Template-Instantiierung abgeschaltet ist (Option: '-no_auto_instantiation'). Der Versuch bestätigt dies. Laut Doku der Edison Design Group gilt dies auch für die Anfang Mai erschienene neue Version ihres Front Ends. Comeau hat mir für diese Woche ein Beta der Version 4.3.0 versprochen, welche das neue Front End nutzt. Ich werde es dann ausprobieren. Die Compiler von Intel, KAI, SGI und Digital/Compaq basieren alle auf EDGs Front End, so dass wir auch bei diesen Compilern keine Probleme erwarten müssen. MSVC++ 6.0: Der Compiler schluckt das Testprogramm anstandslos. Das Problem ist nur, dass er keinen Kommandozeilenschalter (bzw. Schalter im Konfigurationsdialog des Projektes) besitzt, mit dem man die automatische Instantiierung abschalten kann. (Zumindest habe ich keinen gefunden. Wer etwas anderes weiss, soll sich bitte melden.) Im MSDN wird statt dessen eine "Microsoft specific extension" erwähnt; man kann die automatische Instantiierung eines Templates unterbinden, indem man der Definition das Schlüsselwort "extern" voranstellt. Sollten wir LiDIA eines Tages wieder auf MSVC++ portieren, müssen wir so oder so einigen Aufwand betreiben und dieses Schlüsselwort per Makro einfügen. Dann stören uns aber auch inline Template Functions nicht. Kommt jemand von Euch noch an andere Compiler heran, die als Zielplattform für LiDIA in Frage kommen? Ich denke z.B. an aCC/AIX, xlC/HP-UX und Metrowerks/MacOS. Die URL des Testprogramms ist http://www.cdc.informatik.tu-darmstadt.de/~cludwig/inlineTemplate.zip Gruß Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA-CA: http://www.informatik.tu-darmstadt.de/TI/Forschung/LiDIA-CA/ From cludwig@cdc.informatik.tu-darmstadt.de Tue Jun 11 19:02:45 2002 Return-Path: Delivered-To: lidia-develop@cdc.informatik.tu-darmstadt.de Received: from cdc-ws9.cdc.informatik.tu-darmstadt.de (cdc-ws9 [130.83.23.69]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id E008E2C98 for ; Tue, 11 Jun 2002 19:02:44 +0200 (MET DST) Received: (from cludwig@localhost) by cdc-ws9.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g5BH2gV08147 fo