methods inherited from template superclass

  • Thread starter Thread starter Nishith Prabhakar
  • Start date Start date
N

Nishith Prabhakar

Hi,

I have a class which inherits from a template (vector). This class is
defined in the header file as below.

Output.h

class _DLL_RESPONSE_SERVER Output : public vector<SingleOutput>
{
public:
Output();
const string& getActualText() const {return m_actualText;}
void insert(const SingleOutput& so);
}

The "Output::Insert" is defined in a CPP file separately.
Output.cpp

void ResponseServer::Output::insert(const ResponseServer::SingleOutput&
so)
{
// doSomething
}

That code gets compiled into a "LIB" and a "DLL".

When i try to use the Output.h in another project and try to link to
the LIB, i get an external symbols unresolved error for the size()
method.

Is this because templates will have some kind of inlining ?

What am i missing here ? Wont the "size()" method defined in the
template vector

1) either get compiled into the Output.LIB
2) OR will it not be picked up in the target consumer project where i
have access to the Output.h and to the Vector LIB/H as well. How do i
need to setup the consumer project to use the Output.LIB and at the
same time have definitions even for the superclass template?

Thanks
Nishith
 
Nishith said:
Hi,

I have a class which inherits from a template (vector). This class is
defined in the header file as below.

Output.h

class _DLL_RESPONSE_SERVER Output : public vector<SingleOutput>
{
public:
Output();
const string& getActualText() const {return m_actualText;}
void insert(const SingleOutput& so);
}
Click to expand...

This is a bad idea for at least three reasons:

1. Using std::containers (or even std::string) in DLL interfaces ties
users of your DLL to a specific compiler, library, version and CRT.
There is not much point in having a DLL under these circumstances - why
not make it a static lib?
2. Inheriting publically from std::containers is generally not a good
idea, since they have no virtual functions so it is not possible to
introduce any new invariants, etc. Better to either:
a) Have the vector as a member, and just add the member functions you
actually need. Or,
b) Just use std::vector directly, and write some namespace scope
functions to operate on the vector.
3. Your insert function "hides" vector::insert - hiding is rarely a good
idea.
The "Output::Insert" is defined in a CPP file separately.
Output.cpp

void ResponseServer::Output::insert(const ResponseServer::SingleOutput&
so)
{
// doSomething
}

That code gets compiled into a "LIB" and a "DLL".
Click to expand...

Any reason why not just a lib?
When i try to use the Output.h in another project and try to link to
the LIB, i get an external symbols unresolved error for the size()
method.

Is this because templates will have some kind of inlining ?
Click to expand...

I think it's probably because you haven't exported vector. Try adding this:

template class _DLL_RESPONSE_SERVER std::vector<SingleOutput>;

You also need to export SingleOutput of course, if you aren't already.
What am i missing here ? Wont the "size()" method defined in the
template vector

1) either get compiled into the Output.LIB
Click to expand...

Only if you specify that it should.
2) OR will it not be picked up in the target consumer project where i
have access to the Output.h and to the Vector LIB/H as well. How do i
need to setup the consumer project to use the Output.LIB and at the
same time have definitions even for the superclass template?
Click to expand...

I think it doesn't look, since it assumes it will be in the DLL. Not too
sure about this.

Still, rather than all this hassle, the right way to do a DLL is to either:
1) Have a simple C API, possibly providing a C++ facade at the client
side to simplify ease of use (and hopefully even provide for dynamic
loading of the DLL).
2) Use COM, or a similar technology.

That way you aren't completely tied to a particular compiler version.

Tom
 
Back
Top