lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Where to implement this dtor? [Was: Group premium quotes]


From: Vadim Zeitlin
Subject: Re: [lmi] Where to implement this dtor? [Was: Group premium quotes]
Date: Tue, 18 Aug 2015 23:38:55 +0200

On Tue, 18 Aug 2015 17:30:23 +0000 Greg Chicares <address@hidden> wrote:

GC> In 'group_premium_pdf_gen.hpp', this class's constructor is implemented
GC> inline:
GC> 
GC>   class LMI_SO group_premium_pdf_generator
GC> ...
GC>   {
GC>     public:
GC> ...
GC>       virtual ~group_premium_pdf_generator();
GC> ...
GC>     protected:
GC>       group_premium_pdf_generator() {}
GC>   };
GC> 
GC> but its destructor is in 'group_premium_pdf_gen.cpp':
GC> 
GC>   group_premium_pdf_generator::~group_premium_pdf_generator() {}
GC> 
GC> Is there any objection to implementing the dtor inline as follows?
GC> 
GC> -      virtual ~group_premium_pdf_generator();
GC> +      virtual ~group_premium_pdf_generator() {}

 No, not really. I'm afraid this is another leftover from an earlier
version as I started using a impl-created-by-factory approach for this
class but then realized that doing it the way it's done now would be both
simpler and more in line with how the rest of the code in lmi does it, so
changed it -- but forgot to put the now trivial dtor back inline.

GC> Or would it be even better to write the ctor out of line near the dtor, in
GC> 'group_premium_pdf_gen.cpp'?

 In practice this wouldn't matter from performance point of view, so it's
basically a question of taste. I'd probably make both the ctor and the dtor
inline because they seem to be very unlikely to change without other, more
significant changes to this class which would result in recompilation of
all of its clients anyhow, so there doesn't seem to be any disadvantage in
making them inline.

GC> AFAICT, objects of a type derived from this
GC> abstract base class are created only in 'group_premium_pdf_gen_wx.cpp',
GC> which necessarily depends on 'liblmi', so it just seems tidiest to have
GC> both implementations there.

 Assuming by "there" you mean in liblmi (still in
group_premium_pdf_gen.cpp), and not in group_premium_pdf_gen_wx.cpp as I
had initially understood the above (and spent some time writing that this
couldn't work before realizing that this must have been obvious to you as
well and so I must have misunderstood you...), I don't see any problems
with this but, again, I don't see any problems with making both ctor and
dtor inline neither.

GC> I'm sure either way is valid C++14, because they both compile and link
GC> with g++-3.4.5 .

 I obviously have to just accept the results of your tests, but notice that
you might need to upgrade your compiler soon as C++17 is just around the
corner and g++ 3.4.5 doesn't have quite 100% support for it.

 Regards,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]