Kern Sibbald wrote:
> Hello John,
>
> On Tuesday 07 August 2007 13:44, John Drescher wrote:
>
> ...
> Here you have stumbled on one of the more non-standard features of Bacula. I
> don't particularly like most C++ constructs and especially new xxx. The
> problem with new is that there is no good way to interpose code such as
> Bacula's smartalloc, which checks for orphaned buffers (memory leaks), double
> frees, and corrupted heap. The solution a C++ programmer came up with was
> the New() construct, which I have decided to eliminate slowly but surely in
> favor of a C like interface -- e.g. new_dlistString("xxx");
>
>
That is not exactly true. The New() macro (when using smartalloc) is
using the C++ "placement new" operator, which was designed for just such
a purpose. The programmer who coded New() and the SMARTALLOC class did
so in the accepted C++ way. However, (and I mean no disrespect to that
C++ programmer), IMO, the C like interface is much more intuitive, even
to a C++ programmer.
> In addition, I don't like templates. 5 years ago, they were not at all
> portable. This means that all the list routines that Bacula uses are written
> using offsets to allow handling links, and using void to handle multiple
> types --- from a C++ programmer's standpoint, this complicates things a lot,
> but from my standpoint, it gives me a lot more control, avoids templates, and
> allows me to share the same subroutines for lots of different types -- it
> just requires a bit of casting.
>
Hmm...one way to compromise is to define member functions such as:
inline some_type *next(const some_type *item) const { return
(some_type*)next((const void*)item); }
to class dlist in dlist.h, where 'some_type' is whatever types are
commonly being placed in dlists? This should only need to be done for
next(), prev(), first(), and last(). It would eliminate the casting
requirement, but wouldn't affect the class's use in any other way. And
it wouldn't break any existing code that is already using dlists with
casting, nor would it prevent it from being used (with casting) for any
"undefined" types. These member functions would just be a convenience to
prevent the need for type casting.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel