home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!math.fu-berlin.de!pbinfo!trachos
- From: trachos@uni-paderborn.de (Konstantin Trachos)
- Subject: risky inline
- Message-ID: <1992Aug27.142700@uni-paderborn.de>
- Keywords: inline, safe programming
- Sender: news@uni-paderborn.de (News Uni-Paderborn)
- Nntp-Posting-Host: sunkist
- Organization: Uni-GH Paderborn, Germany
- Date: Thu, 27 Aug 1992 12:27:00 GMT
- Lines: 45
-
- Maybe this topic is well known, but I realy want to know the reason,
- inline has been introduced for.
-
- Inline-expansion is surely more effective than #defines, but it isn't
- less risky than that.
-
- Consider folowing example:
- C.hxx and C.cxx are used to build C.lib.
- After that you use only C.hxx and C.lib:
-
- // Interface C.hxx -----------------------------
- class C{
- int a() {return 0;} // OK
- inline int b() {return 0;} // OK
- int c(); // ...
- int d(); // ...
- };
- // EOF C.hxx -----------------------------------
-
- // Code C.cxx ----------------------------------
- #include "C.hxx"
- inline int C::c() {return 1;}// !
- int C::d() {return 0;}// OK
- // EOF C.hxx -----------------------------------
-
-
- The Problem is, that #including C.hxxin your main file
- will make the cfront handle the C::c() as a function-call
- instead of expanding the code.
- You can also build more .libs including code invoking C::c().
- But the linker will fail, because he is going to miss c__1CFv.
-
- I think, that a safe compiler requires safe Language-rules,
- not only carefull Programmers.
-
-
- --
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=
- _ __
- | | _ _/ / 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
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-