[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [1.34.0beta] many, many warnings... :(
From:       Jeff Garland <jeff () crystalclearsoftware ! com>
Date:       2007-05-06 14:37:43
Message-ID: 463DE837.7080709 () crystalclearsoftware ! com
[Download RAW message or body]

David Abrahams wrote:
> on Sat May 05 2007, Jeff Garland <jeff-AT-crystalclearsoftware.com> wrote:

>> As a practical example, my super string 'experiment' uses this technique for 
>> interface compatibility with std::string. In one incarnation super_string 
>> inherits from std::string, which doesn't have a virtual destructor.  Since 
>> super_string only adds functions to the type, has no state, and a trivial 
>> destructor I don't care that it's not called.  So, I have an extended type 
>> with functions useful to me, it's backward compatible with the existing type, 
>> and no virtual table/destructor is needed.
>>
>> http://www.crystalclearsoftware.com/libraries/super_string/index.html
> 
> As long as you don't tell people a super_string IS-A std::string,
> you're arguably okay... though even then, they'll still probably end
> up invoking UB unintentionally.
>

I actually don't think it's too important what I say.  Most code won't invoke 
the UB, but even if the user strays into the UB it's harmless. Technically 
there is a risk that some future compiler might change the UB into bad 
behavior, but that risk seems small.  All this is making me wonder if there 
isn't some reason that this has to be UB since all the compilers have the same 
solution...

Jeff



[prev in list] [next in list] [prev in thread] [next in thread]