On Tuesday 07 August 2007 22:12, Josh Fisher wrote:
> Kern Sibbald wrote:
> > 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:
> >>>
> >>> ...
> >>
> >> 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.
>
> Absolutely agree.
>
> >> 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.
>
> Yes.
>
> >> 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)?
>
> Yes to the first part. No to the second. The compiler uses "name
> mangling", meaning the function parameter types are encoded into the
> mangled name of the function. The mangled names are used internally by
> the compiler. For example, :
>
> inline char *next(const char *item) const { return (char *)next(( const
> void *)item); }
> inline xyz *next(const xyz *item) const { return (xyz *)next(( const
> void *)item); }
>
> Since, these two functions take different parameters, their mangled
> names are different. Thus the compiler sees them as two entirely
> different functions. Likewise, next(( const void *)item) has yet a
> different mangled name, so we can call it from the other two by casting
> their respective parameters to (const void *).
>
> For comparison, consider these two:
>
> char *next(const char *item);
> void *next(const char *item);
>
> This is illegal and will generate an error because two functions with
> identical mangled names are defined with different return types.
Duh, I was so fixed on the different return types that I totally forgot about
the different arguments and name mangling. Rather obvious when it is
explained in simple English.
Thanks for the tip. I'll certainly use it since it will reduce the casting
and thus improve readability for everyone except the C purists :-)
>
>
>
> -------------------------------------------------------------------------
> 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
