we can't use std::unique_ptr because it's not available on mac os 10.6's
libstdc++
Using get() however is inline with the std::unique_ptr API so I think this
is a
good change.
https://codereview.chromium.org/101763003/diff/1/src/smart-pointers.h
File src/smart-pointers.h (right):
https://codereview.chromium.org/101763003/diff/1/src/smart-pointers.h#newcode54
src/smart-pointers.h:54: ~SmartPointerBase() { if (p_)
Deallocator::Delete(p_); }
On 2013/12/04 07:44:48, alph wrote:
On 2013/12/04 07:34:01, yurys wrote:
> On 2013/12/03 16:17:55, svenpanne wrote:
> > Hmmm, this has been like that before, but why is it safe to have a
non-virtual
> > destructor in a base class here? As it is, nothing prevents an
incorrect
usage
> > AFAICT...
>
> This is a good question. I believe the problem is that
SmartArrayPointer and
> SmartPointer inherit from SmartPointerBase. This could be solved
e.g. by
making
> SmartPointer a template with single parameter T. Then it may use
Deallocator
as
> type traits internally, Deallocator in turn can be specialized for
array
types.
> This way we could use SmartPointer for both array types and scalar
types.
How about making the SmartPointerBase destructor protected?
Actually nobody should have reference it via the base class.
> It may make sense to replace current implementation of SmartPointer
with one
> from Blink or Chromium where all such problems have already been
solved. WDYT?
Yes, making it protected makes sense. Since this is a template thing and
not a virtual class hierarchy it should not be virtual.
https://codereview.chromium.org/101763003/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
