🚀 go-pugleaf

Es ist mir nie ganz klar geworden, welchen Nutzen man hat von dem Spezifikator inline. Er soll (und hat) fuer die Bedeutung eines Programmes keine Auswirkung. Aber ignorieren, wie B.S. sagt, sollte man ihn trotztem nicht. Dass er naemlich mehr als ein Hinweis an den Compiler sein kann, zeigt folgenes Beispiel:

Ein Softwarehersteller baut aus C.hxx und C.cxx die Library C.lib.
Der Anwender kriegt C.hxx und C.lib, und folgendes Beispiel 
Stroustroups Segen:

// Interface C.hxx -----------------------------
   class C{
          int a() {return 0;}	// OK
   inline int b() {return 0;}	// OK
          int c();		// abwarten ...
	  int d();		// abwarten ...
   };
// EOF C.hxx -----------------------------------

// Code C.cxx ----------------------------------
   #include "c.hxx"
   inline int C::c() {return 1;}// PENG!
          int C::d() {return 0;}// OK
// EOF C.hxx -----------------------------------

Der Anwender freut sich auf seine neu erworbene Classe ...
Der cfront sagt OK, der C Compiler sagt OK, neue Libraries
koennen erzeugt werden ... 

Aber der Linker kann das Token c__1CFv, d.h. Member C::c() 
nicht finden! Bananenschale!

Die Verwendung von inline ist eines der besten Argumente fuer die moegliche Effizienz von C++-code. Aber sicheres Compilieren kann nicht dem Programmierer allein ueberlassen werden, sondern erfordert konsistente Sprachregeln.

Wie soll hier also gemacht werden:
 - Revision der Inline-Regeln ?
 - Spracherweiterung z.B. um ein ?

Gruesse

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 _          __  
| |  _    _/ /   Uni-GH Paderborn, FB 14   
| |/ /   /  __/  Dipl.-Inf. K. Trachos   
| |\ \   / /     Pohlweg 47-49                     Tel: +49 5251 60 3227
|_| \_\ /__/     D-4790 Paderborn                  FAX: +49 5251 60 3238
                                     email: trachos@dat.uni-paderborn.de
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=