George <greerga@CIRCLEMUD.ORG> writes:
> On Mon, 20 Apr 1998, James Turner wrote:
>
> >If C++ is really desired, I think there are several muds designed this
> Read: http://www.mozilla.org/docs/tplist/catBuild/portable-cpp.html
I've read this before. As it points out, a great deal of the nicer,
newer features of C++ just aren't that portable. That's one of my
objections to the C++ification of Circle.
> 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.
Not in C (at least, not under GCC). Functions should _never_ be
declared in a C header file. They don't belong there. Using gcc, you
don't need to declare functions in headers or whatnot. You can simply
declare the function, adding the identifier 'inline' before the return
type. That's all.
> >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.
Agreed, there isn't. However, note how I said using gotos -- to
replace C's loop directives. That is certainly not one of the good
uses for goto's. They're nice when you're trying to break out of
nested loops where continue/break won't work (something that Perl
takes care of with what essentially amounts to goto's). But this is
bad, no question:
x = 0;
y = 14;
top:
x++;
y--;
if (x < 10) goto top;
In this case, the use of goto is ridiculous. This is the type of use
I was referring to in my statement above.
> >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.
I don't understand quite what you're arguing here. Breaking
declarations up into structures/types, prototypes, and external
declarations makes sense, and is a logical design. What part of it do
you feel isn't?
> >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.
I just did some informal testing. The following file compiled 36
times in 28 seconds on my system. It includes 5 .h files, which total
4000 lines (around 130k). #ifdef'ing the includes out, the same
compile, 36 times, takes 7 seconds. So the headers add about 21
seconds to the compile. The headers in this case are the only headers
any of my files include besides library headers. The time compiling
headers is miniscule, and really shouldn't be a factor in deciding how
to break the headers up.
(I realize these tests are very ad hoc and have little scientific
backing, but they are solid numbers. I'm using egcs 1.0.2 on a K6
200. It takes about half a second to compile 130k lines of headers,
which includes structure definitions, typedefs, prototypes (for every
Circle function, plus those that I have added, which is quite a bit),
and every extern).
#include "../src/conf.h"
#include "../src/sysdep.h"
#include "../src/structs.h"
#include "../src/protos.h"
#include "../src/externs.h"
int
main(int argc, char *argv[])
{
return 1;
}
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerj1/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST