Deriving a regular class from a template?

[Steven T. Hatton]

This may be another question having an obvious answer, but I'm not seeing
it. I'm trying to create a class that derives from
std::valarray<s td::string>. I don't need a template, and I haven't come
across any examples of a construct like what I show below. Perhapes it's
simply a bad idea. If there is something fundamentally wrong with this
approach please let me know.

Can anybody tell me if there is a way to get the following to work? I can
get the class StringArray to compile, but it fails to link correctly:

#include <valarray>
#include <string>

namespace stringer{
using std::valarray;
using std::string;

class StringArray:pub lic valarray<string > {
public:
StringArray(con st size_t& vsize):valarray <string>(vsize) {}
};

StringArray stringV(3); // this is what seems to be failing
}

This is the point where it fails:

g++ -o stringer main.o -L/usr/lib/ -L/usr/lib/qt3/lib/ -L/usr/X11R6/lib/
-lqt -lXext -lX11 -lm
main.o(.text+0x d7): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `std::basic_str ing<char, std::char_trait s<char>,
std::allocator< char> >::_Rep::_S_emp ty_rep_storage'
main.o(.text+0x 155): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `std::basic_str ing<char, std::char_trait s<char>,
std::allocator< char> >::_Rep::_S_emp ty_rep_storage'
main.o(.text+0x 196): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `__gnu_cxx::__e xchange_and_add (int volatile*, int)'

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[John Harrison]

"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote in message
news:u5******** ************@sp eakeasy.net...

This may be another question having an obvious answer, but I'm not seeing
it. I'm trying to create a class that derives from
std::valarray<s td::string>. I don't need a template, and I haven't come
across any examples of a construct like what I show below. Perhapes it's
simply a bad idea. If there is something fundamentally wrong with this
approach please let me know.

Can anybody tell me if there is a way to get the following to work? I can
get the class StringArray to compile, but it fails to link correctly:

#include <valarray>
#include <string>

namespace stringer{
using std::valarray;
using std::string;

class StringArray:pub lic valarray<string > {
public:
StringArray(con st size_t& vsize):valarray <string>(vsize) {}
};

StringArray stringV(3); // this is what seems to be failing
}

This is the point where it fails:

g++ -o stringer main.o -L/usr/lib/ -L/usr/lib/qt3/lib/ -L/usr/X11R6/lib/ -lqt -lXext -lX11 -lm
main.o(.text+0x d7): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `std::basic_str ing<char, std::char_trait s<char>,
std::allocator< char> >::_Rep::_S_emp ty_rep_storage'
main.o(.text+0x 155): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `std::basic_str ing<char, std::char_trait s<char>,
std::allocator< char> >::_Rep::_S_emp ty_rep_storage'
main.o(.text+0x 196): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `__gnu_cxx::__e xchange_and_add (int volatile*, int)'

Your code compiles and links for me. I can't see anything illegal about it.

OTOH I'm not sure its a good idea.

Firstly from the code you posted

typedef std::valarray<s td::string> StringArray;

seems a simpler option, but maybe you have reasons for doing this that
aren't in the posted code.

Secondly valarray is really designed for numeric types, I don't think using
it with strings is illegal but its a bit odd, why not
std::vector<std ::string>?

Thirdly deriving from standard container classes is frowned upon because
they lack a virtual destructor. Something like this is safer and may be
closer to your needs

class StringArray
{
public:
...
private:
std::valarray<s td::string> data;
};

john

[Steven T. Hatton]

John Harrison wrote:

Your code compiles and links for me. I can't see anything illegal about
it.
Indeed. I just built and installed gcc (GCC) 3.4.0. I had been using qmake
to create the Makefile. That's would have worked if my setup were
standard. But it was trying to link against a different set of libs. In
particular the -L/usr/lib. I thought gcc would take precedence over that,
until I looked it up. Oh, and then there's the aclocal-1.8 that came with
automake, and didn't get the proper symlink from the `make install'! It
goes on and on... :-/
OTOH I'm not sure its a good idea.

Firstly from the code you posted

typedef std::valarray<s td::string> StringArray;

seems a simpler option, but maybe you have reasons for doing this that
aren't in the posted code.
My initial motivation was to set the values of the valarray in an
initialization function, hence the desire for a derived class.
Secondly valarray is really designed for numeric types, I don't think
using it with strings is illegal but its a bit odd, why not
std::vector<std ::string>?
I'm using the strings so I can mark the individual elements while I play
around with different slicing, indexing and etc. It's just a learning toy.
Thirdly deriving from standard container classes is frowned upon because
they lack a virtual destructor.
That's good to know. I'm now wondering if I can explicitly call the
destructor on the baseclass. Hmmmm....
Something like this is safer and may be
closer to your needs

class StringArray
{
public:
...
private:
std::valarray<s td::string> data;
};

That crossed my mind. In this case, it's probably better to do the has-a
rather than an is-a. Thanks for the help. The verification that it
compiled was valuable information.

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Dave Moore]

"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote in message news:<u5******* *************@s peakeasy.net>.. .

This may be another question having an obvious answer, but I'm not seeing
it. I'm trying to create a class that derives from
std::valarray<s td::string>. I don't need a template, and I haven't come
across any examples of a construct like what I show below. Perhapes it's
simply a bad idea. If there is something fundamentally wrong with this
approach please let me know.

Can anybody tell me if there is a way to get the following to work? I can
get the class StringArray to compile, but it fails to link correctly:

#include <valarray>
#include <string>

namespace stringer{
using std::valarray;
using std::string;

class StringArray:pub lic valarray<string > {
public:
StringArray(con st size_t& vsize):valarray <string>(vsize) {}
};

StringArray stringV(3); // this is what seems to be failing
}

This is the point where it fails:

g++ -o stringer main.o -L/usr/lib/ -L/usr/lib/qt3/lib/ -L/usr/X11R6/lib/
-lqt -lXext -lX11 -lm
main.o(.text+0x d7): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `std::basic_str ing<char, std::char_trait s<char>, : undefined reference to `__gnu_cxx::__e xchange_and_add (int volatile*, int> std::allocator< char> >::_Rep::_S_emp ty_rep_storage'
main.o(.text+0x 155): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `std::basic_str ing<char, std::char_trait s<char>,
std::allocator< char> >::_Rep::_S_emp ty_rep_storage'
main.o(.text+0x 196): In function `__static_initi alization_and_d estruction_
(int, int)':)'

One possibility is that, since the std::valarray container is really
for optimized numerical calculations, it has some special restrictions
which cause problems if you try to initialize a valarray with a
non-numerical type (c.f. sec 26.3 of the standard). I would suggest
using std::vector<std ::string> .. that should definitely work .. I
have used it myself in the past.

HTH, Dave Moore

[Michiel Salters]

"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote in message news:<u5******* *************@s peakeasy.net>.. .

Can anybody tell me if there is a way to get the following to work? I can
get the class StringArray to compile, but it fails to link correctly:

#include <valarray>
#include <string>

namespace stringer{
using std::valarray;
using std::string;

class StringArray:pub lic valarray<string > {
public:
StringArray(con st size_t& vsize):valarray <string>(vsize) {}
};

StringArray stringV(3); // this is what seems to be failing
}

Should work, and in fact works when compiled with VC7.1. It seems
you should ask in the group for your compiler.

Regards,
Michiel Salters

[Uwe Schnitker]

"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote in message news:<u5******* *************@s peakeasy.net>.. .

This may be another question having an obvious answer, but I'm not seeing
it. I'm trying to create a class that derives from
std::valarray<s td::string>.
This is a bad idea, for at least three reasons:

i) valarray is a special container designed for numerical applications,
so there is propbably no point in using it with string

ii) IIRC there are some restrictions in the standard for using valarray,
to the consequence that using it with string yields undefined
behaviour

iii) deriving from classes which are not designed as base classes, like
the standard library containers, is considered bad practice in C++,
e.g. the lack of a virtual destructor may prove fatal

To your more general question if one can derive a concrete class from
a template instantiation: Yes, that's possible.

If you had used vector instead of valarray, your example would be correct,
even if bad style, for reason iii).

And if you look at your error message, you might see that the code as written
compiled fine. The error message refers to a linker error. You are probable
not linking against the C++ runtime library, or maybe you are linking against
a wrong one.

To solve this problem, check your documentation or ask in a newsgroup topical
to your compiler system.
I don't need a template, and I haven't come
across any examples of a construct like what I show below. Perhapes it's
simply a bad idea. If there is something fundamentally wrong with this
approach please let me know.

Can anybody tell me if there is a way to get the following to work? I can
get the class StringArray to compile, but it fails to link correctly:

#include <valarray>
#include <string>

namespace stringer{
using std::valarray;
using std::string;

class StringArray:pub lic valarray<string > {
public:
StringArray(con st size_t& vsize):valarray <string>(vsize) {}
};

StringArray stringV(3); // this is what seems to be failing
}

This is the point where it fails:

g++ -o stringer main.o -L/usr/lib/ -L/usr/lib/qt3/lib/ -L/usr/X11R6/lib/
-lqt -lXext -lX11 -lm
main.o(.text+0x d7): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `std::basic_str ing<char, std::char_trait s<char>,
std::allocator< char> >::_Rep::_S_emp ty_rep_storage'
main.o(.text+0x 155): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `std::basic_str ing<char, std::char_trait s<char>,
std::allocator< char> >::_Rep::_S_emp ty_rep_storage'
main.o(.text+0x 196): In function `__static_initi alization_and_d estruction_
(int, int)':
: undefined reference to `__gnu_cxx::__e xchange_and_add (int volatile*, int)'

[John Harrison]

>

Thirdly deriving from standard container classes is frowned upon because
they lack a virtual destructor.

That's good to know. I'm now wondering if I can explicitly call the
destructor on the baseclass. Hmmmm....

There's no need to do that. The problem is with code like the following

valarray<string >* p = new StringArray(10) ;
delete p;

That is undefined behaviour. Deleting a derived class object through a
pointer to a base class when that base class lacks a virtual destructor
results in undefined behaviour. The issue for you is how likely it is that
code like the above will be written with your StringArray class.

john

[Dave Moore]

sc************* *******@sigma-c.com (Uwe Schnitker) wrote in message news:<30******* *************** ****@posting.go ogle.com>...

iii) deriving from classes which are not designed as base classes, like
the standard library containers, is considered bad practice in C++,
e.g. the lack of a virtual destructor may prove fatal

This idea is new to me .. do you have a reference where I can read
about it in more detail? In the past I have routinely derived classes
from std::vector and std::valarray, usually publicly, but sometimes
privately. I have done this when it seemed natural to do so in terms
of the "is-a" formalism for building class hierarchies. For example,

class positionArray : public std::vector<dou ble> {
// some private data that is needed for manipulating the elements
// of the array
public:
positionArray(i nt size) : std::vector<dou ble>(size) {
// whatever
}

void permute(); //
};
In my application positionArray is conceptually a vector of double, so
it makes sense to apply operations like subscripting directly, rather
than through an access function referencing a std::vector<dou ble>
member. The positionArray class then would then typically also have a
few member functions for carrying out particular operations on the
underlying std::vector<dou ble>.

I rarely use virtual functions or multiple inheritance, so the lack of
a virtual destructor has never been a problem for me .. although I
certainly see your point about that being a potential problem in the
more general case. Are there other weaknesses associated with
deriving from STL containers? If there are none, then it seems like
your advice above is perhaps a bit too restrictive.

Just my $0.02 ... Dave Moore

[Victor Bazarov]

"Dave Moore" <dt*****@rijnh. nl> wrote...

sc************* *******@sigma-c.com (Uwe Schnitker) wrote in message news:<30******* *************** ****@posting.go ogle.com>...

iii) deriving from classes which are not designed as base classes, like the standard library containers, is considered bad practice in C++, e.g. the lack of a virtual destructor may prove fatal

[...] Are there other weaknesses associated with
deriving from STL containers? If there are none, then it seems like
your advice above is perhaps a bit too restrictive.

No other weaknesses. The advice is usually directed at newbies so
that they don't get into a habit of deriving whenever they need to.

A note: I often find it helpful to derive privately. Then I can
control what functionality is exposed and I definitely prevent such
blunders as accidental polymorphic deletion.

Victor

[Julie]

Victor Bazarov wrote:

"Dave Moore" <dt*****@rijnh. nl> wrote...

sc************* *******@sigma-c.com (Uwe Schnitker) wrote in message

news:<30******* *************** ****@posting.go ogle.com>...

iii) deriving from classes which are not designed as base classes, like the standard library containers, is considered bad practice in C++, e.g. the lack of a virtual destructor may prove fatal

[...] Are there other weaknesses associated with
deriving from STL containers? If there are none, then it seems like
your advice above is perhaps a bit too restrictive.

No other weaknesses. The advice is usually directed at newbies so
that they don't get into a habit of deriving whenever they need to.

A note: I often find it helpful to derive privately. Then I can
control what functionality is exposed and I definitely prevent such
blunders as accidental polymorphic deletion.

Victor

So, if that is the case, then deriving from std containers should *NOT* be
labeled as a bad practice (bad design, etc.), but rather as an 'advanced
construct or idiom'.

I'm sure that _misnaming_ something 'bad practice/design' causes a lot more
problems that it is intended to solve.