On Tuesday 07 August 2007 20:50, Josh Fisher wrote:
> 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.
Unfortunately, I was mixing two different thoughts without explaining them
very well. What is non-standard is *my* implementation of the alist and dlist
classes. What I don't particularly like is the kludgy non-C, non-C++ New()
construct that was necessary to properly subclass the smartalloc code.
> 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.
Yes, that is why over time, I will be converting to using new_dlist() as the
way to construct a dlist. There *are* a few "new xxx" calls in Bacula but
they are quite rare, and I use them only when I am 100% sure I can guarantee
that there is a corresponding delete.
>
> > 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); }
That is interesting. Since I am not a C++ guru I was not aware that you could
declare multiple next() functions that return different types -- I am not
even sure how the compiler would know which one to use.
>
> to class dlist in dlist.h, where 'some_type' is whatever types are
> commonly being placed in dlists?
Typically they are pointers to char or pointers to some structure.
> 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.
Are you saying I could define:
inline char *next(const char *item) const { return (char *)next((
const void *)item); }
and
struct xyz { ...}
inline xyz *next(const xyz *item) const { return (xyz *)next((
const void *)item); }
and the compiler would be happy and figure out which inline to use (I assume
by knowing the type of the destination)?
>
>
>
> -------------------------------------------------------------------------
> 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
-------------------------------------------------------------------------
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
