James Turner wrote:
>
> 1. The biggest issue in my opinion is the use of macros.
Macros are the _only_ way to encapsulate code you want to inline. A
function call is still costly. It is absolutely ridiculous to make a
function call for a single line of code, and macros offer flexible
functionality that functions do not.
As for how macros are expanded: this is a matter of writing good
code. If you don't write your macros right, they won't expand how
you expect them.
> (Additionally, for speed issues, gcc allows for the inlining of
> functions, even in C code. Perhaps VC++ provides a similar facility,
> but with the progression of Cygnus' gnuwin32 [which I am assuming
> supports inlining like this], I see less and less need to explicitly
> support such an alien compiler).
Inline functions are part of the C++ standard. However, just because a
function is called inline does not mean it will be. The compiler is
still in charge of determining whether or not a function should be
inlined. This has the single advantage that the compiler can define
different rules for different platforms.
> 2. Expandability.
This is why the code is there. CircleMUD is meant as a base system.
People add their own code to it, and patches offer functionality that
is desired by others but not a part of stock for one reason or another.
> 3. Layout. The code in circlemud is, to be honest, poorly laid out.
Why is having several header files a problem? Multiple header files
have the benefit of only requiring you to recompile code that is
affected by header file changes. For many people, compilation time
is not trivial and recompiling the entire MUD every time you want to
change a function definition or macro is not desirable.
> 7. Linked lists. The current linked list support is, well, somewhat
> dirty. Imbedding next elements into all the structures then using the
> REMOVE_FROM_LIST macro is extremely ugly. We need to get a simple
> linked list library written (a fairly simple task), or use one out
> there. I personally use the singly linked list class from glib (a
> subcomponent of gtk, which provides a large amount of common C
> algorithms and structures, including hashes, lists, and I believe
> trees), which is exactly what we need. The only downside is that,
> though glib itself is cross-platform I believe, gtk probably doesn't
> port to Win32 yet.
I don't see any problem with CircleMUD's implementation of linked
lists. It's _MUCH_ cleaner and more readable than a generic linked
list library written in C (or a linked list template in C++) would be
and it provides all the functionality required.
-dak
+------------------------------------------------------------+
| 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