By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,190 Members | 811 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,190 IT Pros & Developers. It's quick & easy.

template vector, incomplete type error

P: n/a
Hi,
I am migrating some std::vectors to use a template instead, but I get
an incomplete type error in a struct declaration.

#include <vector>

template < typename T >
class Vec : public std::vector< T {
public:
Vec():Vec<T>() { }
Vec( int s ) : std::vector<T>(s) { }
T& operator[](int i) { return at(i); }
const T& operator[](int i ) const { return at(i); }
};
typedef Vec<doublevecdbl;
typedef Vec<vecdblmatdbl;
#include "matvec.h"
// that is it above

typedef vecdbl memvec;

struct felt
{
...
memvec m; // <- incomplete type error

Sep 30 '06 #1
Share this Question
Share on Google+
13 Replies


P: n/a
In article <11**********************@c28g2000cwb.googlegroups .com>,
<im*****@hotmail.co.ukwrote:
>Hi,
I am migrating some std::vectors to use a template instead, but I get
an incomplete type error in a struct declaration.

#include <vector>

template < typename T >
class Vec : public std::vector< T {
public:
Vec():Vec<T>() { }
Vec( int s ) : std::vector<T>(s) { }
T& operator[](int i) { return at(i); }
const T& operator[](int i ) const { return at(i); }
};
typedef Vec<doublevecdbl;
typedef Vec<vecdblmatdbl;
#include "matvec.h"
// that is it above

typedef vecdbl memvec;

struct felt
{
..
memvec m; // <- incomplete type error
I don't understand Vec():Vec<T>() and probably you're compiler
doesn't either eventually makeing Vec<Tincomplete classes
because of that problem.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Sep 30 '06 #2

P: n/a
In article <ef**********@panix1.panix.com>,
Greg Comeau <co****@comeaucomputing.comwrote:
>In article <11**********************@c28g2000cwb.googlegroups .com>,
<im*****@hotmail.co.ukwrote:
>>Hi,
I am migrating some std::vectors to use a template instead, but I get
an incomplete type error in a struct declaration.

#include <vector>

template < typename T >
class Vec : public std::vector< T {
public:
Vec():Vec<T>() { }
Vec( int s ) : std::vector<T>(s) { }
T& operator[](int i) { return at(i); }
const T& operator[](int i ) const { return at(i); }
};
typedef Vec<doublevecdbl;
typedef Vec<vecdblmatdbl;
#include "matvec.h"
// that is it above

typedef vecdbl memvec;

struct felt
{
..
memvec m; // <- incomplete type error

I don't understand Vec():Vec<T>() and probably you're compiler
doesn't either eventually makeing Vec<Tincomplete classes
because of that problem.
Also on a different aspect: std::vector was not written to be
derived from.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Sep 30 '06 #3

P: n/a
im*****@hotmail.co.uk wrote:
#include <vector>

template < typename T >
class Vec : public std::vector< T {
public:
Vec():Vec<T>() { }
Vec() : std::vector<T>() {}
Vec( int s ) : std::vector<T>(s) { }
T& operator[](int i) { return at(i); }
& operator[](int i) { return this->at(i); }
const T& operator[](int i ) const { return at(i); }
const T& operator[](int i ) const { return this->at(i); }
};
typedef Vec<doublevecdbl;
typedef Vec<vecdblmatdbl;
#include "matvec.h"
// that is it above

typedef vecdbl memvec;

struct felt
{
..
memvec m; *// <- incomplete type error

Best

Kai-Uwe Bux
Sep 30 '06 #4

P: n/a
I don't understand Vec():Vec<T>() and probably you're compiler
doesn't either eventually makeing Vec<Tincomplete classes
because of that problem.
I tried these but it gives same error

template < typename T >
class Vec : public std::vector< T {
public:
Vec(): std::vector<T>() { }
Vec( int s ) : std::vector<T>(s) { }
T& operator[](int i) { return at(i); }
const T& operator[](int i ) const { return at(i); }
};

and

template < typename T >
class Vec : public std::vector< T {
public:
T& operator[](int i) { return at(i); }
const T& operator[](int i ) const { return at(i); }
};

Do I need std:: infront of anything else ? What is the "(s)" about ?

Sep 30 '06 #5

P: n/a
Greg Comeau wrote:
In article <ef**********@panix1.panix.com>,
Greg Comeau <co****@comeaucomputing.comwrote:
>>In article <11**********************@c28g2000cwb.googlegroups .com>,
<im*****@hotmail.co.ukwrote:
>>>Hi,
I am migrating some std::vectors to use a template instead, but I get
an incomplete type error in a struct declaration.

#include <vector>

template < typename T >
class Vec : public std::vector< T {
public:
Vec():Vec<T>() { }
Vec( int s ) : std::vector<T>(s) { }
T& operator[](int i) { return at(i); }
const T& operator[](int i ) const { return at(i); }
};
typedef Vec<doublevecdbl;
typedef Vec<vecdblmatdbl;
#include "matvec.h"
// that is it above

typedef vecdbl memvec;

struct felt
{
..
memvec m; // <- incomplete type error

I don't understand Vec():Vec<T>() and probably you're compiler
doesn't either eventually makeing Vec<Tincomplete classes
because of that problem.

Also on a different aspect: std::vector was not written to be
derived from.
If you look at the OP's code, the template class Vec<Tis clearly a
debugging tool: I would bet that the intended use is to redefine some
typedefs that currently go to std::vector to hunt down some out of bounds
errors. Once those are fixed, the typedef will hopefully be changed back to
std::vector in production code. I cannot see any harm in this little trick.

Of course, a full-fledged debugging vector (e.g., whose iterators would
guard against invalidation) would be even better.
Best

Kai-Uwe Bux
Sep 30 '06 #6

P: n/a
Greg Comeau wrote:
Also on a different aspect: std::vector was not written to be
derived from.
--
Why was I recommended to wrap this in a template in the first place ?

Sep 30 '06 #7

P: n/a
im*****@hotmail.co.uk wrote:
Greg Comeau wrote:
>Also on a different aspect: std::vector was not written to be
derived from.
--

Why was I recommended to wrap this in a template in the first place ?
To cut a long story short: std::vector does not have a virtual destructor.
That implies that you get undefined behavior if you use a std::vector<T>*
polymorphically and you delete an object of a derived class through this
pointer. Another source of surprises is that references to derived objects
will silently convert to references of type std::vector<T>.

Certain people think that it is therefore a BadIdea(tm) to ever inherit
publicly from std::vector<T>. Others think it's ok as long as you know
about the possible traps. In your case, it looks as though you use this
inheritance just as a temporary debugging tool and there is probably no
harm. Also, you could go back to std::vector<Tin production code once
the out of bounds errors have been found. In principle, you should be able
to do the switch with a simple typedef in your code.

Inheriting from std::vector<Tcan be tricky. That does not imply it is
always bad. But you have to be aware of the difficulties that can arise.
Best

Kai-Uwe Bux
Sep 30 '06 #8

P: n/a

Kai-Uwe Bux wrote:
Inheriting from std::vector<Tcan be tricky. That does not imply it is
always bad. But you have to be aware of the difficulties that can arise.
Best

Kai-Uwe Bux
Thanks, I'll check this out. Does this count as inheriting ?

class myc
{
std::vector<doublex;
...

Sep 30 '06 #9

P: n/a
im*****@hotmail.co.uk wrote:
>
Kai-Uwe Bux wrote:
>Inheriting from std::vector<Tcan be tricky. That does not imply it is
always bad. But you have to be aware of the difficulties that can arise.
Best

Kai-Uwe Bux

Thanks, I'll check this out. Does this count as inheriting ?

class myc
{
std::vector<doublex;
..
Nope, that is usually called composition. The drawback is that you have to
write tons of boilerplate code to forward all the member functions.

Also, I did not intend to scare you away from public inheritance in this
particular case. If you do not use pointers to std::vector polymorphically
(and you don't have a reason to do that anyhow), you will almost certainly
be fine.

To complete the picture, you might want to read up on private inheritance:

class my_vector : private std::vector<double{

using iterator;
using ...
// tons of using declarations forwarding all members that we want.

};

This avoids the pitfalls of public inheritance and is less boilerplate code
than composition.
Best

Kai-Uwe Bux
Sep 30 '06 #10

P: n/a
Greg Comeau wrote:
....
>I don't understand Vec():Vec<T>() and probably you're compiler
doesn't either eventually makeing Vec<Tincomplete classes
because of that problem.

Also on a different aspect: std::vector was not written to be
derived from.
In what way was it not written to be derived from ?

(I hope you don't say that it does not have a virtual destructor...)
Oct 1 '06 #11

P: n/a
In article <45***********************@per-qv1-newsreader-01.iinet.net.au>,
Gianni Mariani <gi*******@mariani.wswrote:
>Greg Comeau wrote:
...
>>I don't understand Vec():Vec<T>() and probably you're compiler
doesn't either eventually makeing Vec<Tincomplete classes
because of that problem.

Also on a different aspect: std::vector was not written to be
derived from.

In what way was it not written to be derived from ?

(I hope you don't say that it does not have a virtual destructor...)
From the get go, except for I guess iostreams, the intent
of the containters was to be stand alone self contained entities.

In what way was it written to be derived from ?
It is purposely designed to be extensible, but through templates,
which is a different type of relationship approach.
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Oct 1 '06 #12

P: n/a
Greg Comeau wrote:
....
>
In what way was it written to be derived from ?
It is purposely designed to be extensible, but through templates,
which is a different type of relationship approach.
So there is nothing specific that makes the classes "designed" to not be
inherited.

So there should be no reason that these classes can't be inherited from.
(modulo all the regular gotchas - slicing dicing and deleting from the
wrong pointer etc...)
Oct 1 '06 #13

P: n/a
In article <45**********************@per-qv1-newsreader-01.iinet.net.au>,
Gianni Mariani <gi*******@mariani.wswrote:
>Greg Comeau wrote:
...
>In what way was it written to be derived from ?
It is purposely designed to be extensible, but through templates,
which is a different type of relationship approach.

So there is nothing specific that makes the classes "designed" to not be
inherited.

So there should be no reason that these classes can't be inherited from.
(modulo all the regular gotchas - slicing dicing and deleting from the
wrong pointer etc...)
What? So except for the obvious normal stuff there is no reason. Uh-huh.

I guess I don't understand what you don't understand. I am not a
C++ standard library expert, but it seems to me:
* The authors have said so.
* All useful data in vector (and perhaps unuseful ones too) is private
(not that it would be public but perhaps at least protected).
* There is no virtuals.
* It seems to me that there is a disconnect between related things
such as iterators, which need to go hand in hand with it. I could be wrong.

IOWs, except for an instrumentation example given earlier (it had not
dawned on me that's what the OP was doing duh) there is not really all
that much that could be gained. So it seems to me that the extensibility
is as a template. I would probably expect a particular instantiation
to be derived from if anything but even that I guess I would think about.
Also, in such cases where a design needs to be bent, or enhanced,
I often find that more superior solutions can come about in other ways
(containment (which isn't perfect either), private inheritance,
the typedef mentioned earlier, even regular (thought perhaps template'd)
functions (aka "free functions", etc.).
--
Greg Comeau / 20 years of Comeauity! Intel Mac Port now in alpha!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Oct 2 '06 #14

This discussion thread is closed

Replies have been disabled for this discussion.