Re: Circlemud design issues

From: George (greerga@CIRCLEMUD.ORG)
Date: 04/20/98

On Mon, 20 Apr 1998, James Turner wrote:

>If C++ is really desired, I think there are several muds designed this
>way from the ground up.  I have nothing against the C++ language -- it
>is very good.  However, at this late time, converting to C++ would not
>be the way to go.


>Certainly, most do support inlining.  As George pointed out in another
>post, gcc supports it with -O3 and -finline-functions.  However, those
>optimizations are done by the code on what functions it feels should
>be inlined.  The optimizer in gcc (and its derivatives) is very good;
>however, it is not that good.  It only has compile time information to
>go by.  We need to be able to explicitly request some functions be
>inlined (which gcc supports, even in C).

The very bad thing about inlined functions is that you have to put them in
header files (or a C file, but that's not the usual place).  Then any
change to that function causes large recompilation.  Then if you have a
compiler that doesn't support inlining, you lose.

>backwards compatible.  But using C++ like a procedural language is
>like using goto and labels in C code instead of its loop directives
>(for, while, do).

There's nothing wrong with 'goto' so long as you use it properly.

>externs.h.  You and George are right that this does significantly
>increase the compile size; however, it simplifies the coding.

Huh? If you're including a header for declarations you probably also need
some prototypes from it as well.  If logically organized that is.

>Further, compiling a header takes a LOT less time than compiling
>normal code.  They are declarations, not executable code.  A 20k
>header compiles significantly faster than a 20k code file.

Yes, but you're compiling that 20k header 36 times in stock CircleMUD.

George Greer  -   | Genius may have its limitations, but stupidity | is not thus handicapped. -- Elbert Hubbard

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST