Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Inheriting from STL bitset

Reply
Thread Tools

Inheriting from STL bitset

 
 
shaun roe
Guest
Posts: n/a
 
      11-05-2004
I want something which is very like a bitset<64> but with a couple of
extra functions: set/get the two 32 bit words, and conversion to
unsigned long long.

I can do this easily by inheriting from bitset<64>, but I know that STL
has no virtual destructor. Can I get around this by calling the
baseclass destructor explicitly in my derived class?

Is there another way to get all of the bitset<64> functionality without
rewriting a lot of code?

cheers

shaun
 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      11-05-2004
shaun roe wrote:
> I want something which is very like a bitset<64> but with a couple of
> extra functions: set/get the two 32 bit words, and conversion to
> unsigned long long.


There is no unsigned long long in C++. You must be talking about some
compiler extension you're using.

> I can do this easily by inheriting from bitset<64>, but I know that STL
> has no virtual destructor. Can I get around this by calling the
> baseclass destructor explicitly in my derived class?


You don't need to. Virtual destructor is needed when you delete an object
of derived class using a base class pointer. If you're not going to use
dynamic memory allocation, the destructor of the derived class _will_ call
the destructor of the base class.

> Is there another way to get all of the bitset<64> functionality without
> rewriting a lot of code?


Do your inheriting thing and see how it goes.

V
 
Reply With Quote
 
 
 
 
P.J. Plauger
Guest
Posts: n/a
 
      11-05-2004
"shaun roe" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

>I want something which is very like a bitset<64> but with a couple of
> extra functions: set/get the two 32 bit words, and conversion to
> unsigned long long.
>
> I can do this easily by inheriting from bitset<64>, but I know that STL
> has no virtual destructor. Can I get around this by calling the
> baseclass destructor explicitly in my derived class?
>
> Is there another way to get all of the bitset<64> functionality without
> rewriting a lot of code?


There's nothing wrong with inheriting from a class without a
virtual destructor, so long as:

1) you don't add member objects in the derived class that might
get sliced away at destruction, or

2) you're careful never to destroy such an object via a pointer
to base (which will slice).

Just do it.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


 
Reply With Quote
 
Ivan Vecerina
Guest
Posts: n/a
 
      11-05-2004
"shaun roe" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I want something which is very like a bitset<64> but with a couple of
> extra functions: set/get the two 32 bit words, and conversion to
> unsigned long long.
>
> I can do this easily by inheriting from bitset<64>, but I know that STL
> has no virtual destructor. Can I get around this by calling the
> baseclass destructor explicitly in my derived class?
>
> Is there another way to get all of the bitset<64> functionality without
> rewriting a lot of code?


What's wrong with just providing a couple of non-member functions
that do what you need ?
E.g.:
unsigned long long asUint64( std::bitset<64> const& bs );

What is the point of deriving from a class that has no virtual
functions and no protected members ?
What is even the point of adding creating an additional type
that has no new data members and no new invariants to preserve?
It is possible to derive a new type, but the risks and drawbacks
that result are not worth it IMNSHO.


The problem either way might be that the interface of std::bitset
does not provide efficient r/w access to anything but the lower
bits (that fit in an unsigned long).
Depending on the application, this might be a reason to avoid
std::bitset -- especially since you seem to already be making
the assuption that a 64 bit integer is available on your platform.



Regards,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form


 
Reply With Quote
 
Julie
Guest
Posts: n/a
 
      11-05-2004
Ivan Vecerina wrote:
>
> "shaun roe" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > I want something which is very like a bitset<64> but with a couple of
> > extra functions: set/get the two 32 bit words, and conversion to
> > unsigned long long.
> >
> > I can do this easily by inheriting from bitset<64>, but I know that STL
> > has no virtual destructor. Can I get around this by calling the
> > baseclass destructor explicitly in my derived class?
> >
> > Is there another way to get all of the bitset<64> functionality without
> > rewriting a lot of code?

>
> What's wrong with just providing a couple of non-member functions
> that do what you need ?
> E.g.:
> unsigned long long asUint64( std::bitset<64> const& bs );
>
> What is the point of deriving from a class that has no virtual
> functions and no protected members ?


What is the point of *not* doing it? No new data? What about new *methods*?

If C++ is supposed to be OO, then why get all procedural whenever you need to
extend the functionality of a class?


> What is even the point of adding creating an additional type
> that has no new data members and no new invariants to preserve?
> It is possible to derive a new type, but the risks and drawbacks
> that result are not worth it IMNSHO.
>
> The problem either way might be that the interface of std::bitset
> does not provide efficient r/w access to anything but the lower
> bits (that fit in an unsigned long).
> Depending on the application, this might be a reason to avoid
> std::bitset -- especially since you seem to already be making
> the assuption that a 64 bit integer is available on your platform.
>
> Regards,
> Ivan
> --
> http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

 
Reply With Quote
 
Ivan Vecerina
Guest
Posts: n/a
 
      11-06-2004
"Julie" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Ivan Vecerina wrote:
> > What is the point of deriving from a class that has no virtual
> > functions and no protected members ?

>
> What is the point of *not* doing it? No new data? What about new

*methods*?

Because doing it:
- creates potential slicing issues (during object copies)
- adds an opportunity for undefined behavior (during delete & array access)
- contradicts the "keep it simple" principle by adding a new type for no
purpose (new class in your hierarchy tree, and potentially
conversions/operators to add).
- may require unnecessary object copying/conversions when interfacing
with code that uses the type being derived from (this is especially true
when deriving from std::string or std::vector).


> If C++ is supposed to be OO, then why get all procedural whenever you need

to
> extend the functionality of a class?



Are you saying that writing obj.f() instead of f(obj) is what defines
object-oriented programming, languages, and design ?

I think you need an objective reason to support the derivation
of a new type. A reason such as:
- being able to override a virtual method
- gaining access to protected data members (but having protected
members in a class with no virtual methods hardly makes sense).
- being able to enforce new invariants, possibly adding data members
(but in this case public inheritance is not an option,
and containment typically should be preferred).
- import a bunch of names into the scope of your class
(this is not OOP, but a technique used in generic programming)

Do you disagree?


Kind regards,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form


 
Reply With Quote
 
John Harrison
Guest
Posts: n/a
 
      11-06-2004
>
> There's nothing wrong with inheriting from a class without a
> virtual destructor, so long as:
>
> 1) you don't add member objects in the derived class that might
> get sliced away at destruction, or
>


I've never heard this before, could you explain a bit more what the problem
is. At the moment I don't get it.

john


 
Reply With Quote
 
P.J. Plauger
Guest
Posts: n/a
 
      11-06-2004
"John Harrison" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

>> There's nothing wrong with inheriting from a class without a
>> virtual destructor, so long as:
>>
>> 1) you don't add member objects in the derived class that might
>> get sliced away at destruction, or
>>

>
> I've never heard this before, could you explain a bit more what the
> problem is. At the moment I don't get it.


Say you have a class B with no virtual destructor. You derive from this
an object D with an extra data member or two. You can easily contrive
a pointer p to just the base part of a derived object d by writing
p = (B *)&d. If you destroy p, all the B destructor knows about is
the B component. Any destructor D has will never get called. You have
*sliced* the object.

OTOH, if B has a virtual destructor, then D automatically has one too.
Destroying p ensures that the whole chain of virtual destructors gets
called in the proper order. No slicing.

So slicing is always a potential problem if you derive from a class
with no virtual destructor, but it is not necessarily a real problem
for the reasons I cited before. The Standard C++ library, in fact,
has a number of classes clearly intended to serve as bases even
though they have no virtual destructors.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


 
Reply With Quote
 
John Harrison
Guest
Posts: n/a
 
      11-06-2004

"P.J. Plauger" <(E-Mail Removed)> wrote in message
news:1099735809.8gAGue89zX+1PxoiHZoraQ@teranews...
> "John Harrison" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>>> There's nothing wrong with inheriting from a class without a
>>> virtual destructor, so long as:
>>>
>>> 1) you don't add member objects in the derived class that might
>>> get sliced away at destruction, or
>>>

>>
>> I've never heard this before, could you explain a bit more what the
>> problem is. At the moment I don't get it.

>
> Say you have a class B with no virtual destructor. You derive from this
> an object D with an extra data member or two. You can easily contrive
> a pointer p to just the base part of a derived object d by writing
> p = (B *)&d. If you destroy p, all the B destructor knows about is
> the B component. Any destructor D has will never get called. You have
> *sliced* the object.
>
> OTOH, if B has a virtual destructor, then D automatically has one too.
> Destroying p ensures that the whole chain of virtual destructors gets
> called in the proper order. No slicing.
>
> So slicing is always a potential problem if you derive from a class
> with no virtual destructor, but it is not necessarily a real problem
> for the reasons I cited before. The Standard C++ library, in fact,
> has a number of classes clearly intended to serve as bases even
> though they have no virtual destructors.
>
> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com
>


OK but isn't that essentially the same as point two which I was familiar
with.

john


 
Reply With Quote
 
Ivan Vecerina
Guest
Posts: n/a
 
      11-06-2004
"P.J. Plauger" <(E-Mail Removed)> wrote in message
news:1099735809.8gAGue89zX+1PxoiHZoraQ@teranews...
> "John Harrison" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>>> There's nothing wrong with inheriting from a class without a
>>> virtual destructor, so long as:
>>>
>>> 1) you don't add member objects in the derived class that might
>>> get sliced away at destruction, or
>>>

>>
>> I've never heard this before, could you explain a bit more what the
>> problem is. At the moment I don't get it.

>
> Say you have a class B with no virtual destructor. You derive from this
> an object D with an extra data member or two. You can easily contrive
> a pointer p to just the base part of a derived object d by writing
> p = (B *)&d. If you destroy p, all the B destructor knows about is
> the B component. Any destructor D has will never get called. You have
> *sliced* the object.


While this is the typical observable behavior, what you formally get
in this case is undefined behavior IIRC. For example, an implementation
could rely on the object's size to determine how to release memory;
deleting an instance of D through a pointer to B could result in
a global corruption of the heap.
I think that this stretches the usual meaning of "slicing"...

> OTOH, if B has a virtual destructor, then D automatically has one too.
> Destroying p ensures that the whole chain of virtual destructors gets
> called in the proper order. No slicing.

As the saying goes: the destructor of a class intended derived from
should be virtual (or else at least protected).

> So slicing is always a potential problem if you derive from a class
> with no virtual destructor, but it is not necessarily a real problem
> for the reasons I cited before. The Standard C++ library, in fact,
> has a number of classes clearly intended to serve as bases even
> though they have no virtual destructors.

I find it dangerous to make such a statement here without clarifying
which classes you are talking about.
Because I do not think that this would include any container or
string class - but instruments used for generic programming
such as binary_function.

And by the way, would it not be a good idea for the standard
to demand that such base classes used for generic probramming
provide a 'protected:' destructor ?
This could help avoid accidental destruction through a base
class pointer. Would it break any correct code ?



Kind regards,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
bitset<32> and bitset<64> efficiency Ninds C++ 14 12-03-2012 11:02 PM
Is there any better approach to private inheriting from the STL containers? Michael Tsang C++ 0 04-27-2011 07:58 AM
STL bitset class slow.. crea C++ 58 03-20-2011 09:32 PM
Is bitset class is not a STL container? Sarath C++ 4 05-31-2007 06:36 PM
Performance of java.util.BitSet Timo Nentwig Java 4 12-11-2003 12:43 AM



Advertisments