Subject: Re: Code guidelines, state of C++ compilers used, and general C++comments
From: Mike Nordell (tamlin@algonet.se)
Date: Tue May 09 2000 - 01:29:16 CDT
"Justin Bradford" wrote:
> On Tue, 9 May 2000, Mike Nordell wrote:
>
> > To use an intrusive double linked list template class could really be
of
> > benefit. An (incomplete) example of how such an interface could look
like
> > can be found with my patch of fp_Run.
>
> I thought we had a policy against templates.
Correct, but part of the issue with the message was to see if these kind
of "features" are missing from _any_ of the compilers we support
(basically 'bool' and class templates). For worries about platforms we
might support in the future I'm quite confident there's a C++ compiler
that can handle at least _basic_ class template usage since the C++
standard now is a couple of years old.
Please note that I'm not "lobbying" for usage of templates, I just wanted
a discussion on the usage of now-required-by-the-standard C++ "features".
I'm well aware that just because one _can_ do it one _shouldn't_
necessary do it.
> > I also note that the macro DELETEP is somewhat redundant
[snip]
> The DELETEP/FREEP macros also set the variable to NULL.
Note the usage of "somewhat".
> I believe the current implementation is something like:
> #define DELETEP(s) do { if (s) delete(s); (s) = NULL; } while (0)
>
> NULLing the pointer is a good thing, as it makes debugging easier.
It depends. To null e.g. member variables in the d'tor it's plain
wasteless and can actually prevent finding bugs.
> As for bloat, a decent compiler should make that macro only a few
> operations longer than a plain delete(s);
I agree that it isn't by much, but it still is. A more serious issue
might be something like fp_TabRun that's quite frequently used if I'm not
mistaken. On most platforms every instance of this class would need about
80 bytes. That might not sound much, but if you have 100.000 runs in a
document, that's over 7 MB. By just looking at its definition I see that
at least 32 bytes are waste, and that's without even beginning to
optimize.
It might be that this kind of optimization discussions are a bit early
for AbiWord, since its stability and usability should come first. But we
all know that the longer it gets delayed, the harder it will be to fix.
:-)
/Mike - please only post follow-ups to the list
This archive was generated by hypermail 2b25 : Tue May 09 2000 - 01:14:23 CDT