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

Template class member for one specialisation only?

P: n/a
Ben
Hi all.

I'm trying to make a third party lib (Rogue Wave's math.h++) compile
(under VC7) and I'm having some problems with what I think is code
that was written specifically to work with the older (less standard)
versions of the VC compiler.

There's a class like this (the comments are mine):

class RWMathVec
{
// .. constructors + other stuff.

// the interesting bit.
RWMathVec( const RWMathVec<double>& re, const RWMathVec<double>& i
);
};

Now that last c'tor is not implemented anywhere except a .cpp file
(one that isn't #include'd anywhere) in the library and in there it is
specialised (am I applying this term correctly here?) for a type
DComplex, like this:

template<>
RWMathVec<DComplex>::RWMathVec( const RWMathVec<double>& re, const
RWMathVec<double>& im )
{
//.. stuff.
}

Now, I don't really think this is right (up to standard?) because
there is no definition for the c'tor in the class definition, and sure
enough I get warnings when trying to compile the library:

C:\vs.net\Vc7\include\xmemory(111) : warning C4661:
'RWMathVec<T>::RWMathVec(const RWMathVec<double> &,const
RWMathVec<double> &)' : no suitable definition provided for explicit
template instantiation request

This is what I would expect. So, I have a few questions:

1. Is it legal/good practice to declare a c'tor (or any member) in a
template class and then provide only certain specialised
implementations of that c'tor?
2. What can I do to sort this problem out?

I want to fix it without having to delve too deep or make too many
changes to the code. I'm hoping that compile and link errors can help
me to judge whether the code it 'right' or not after making my
changes. I suppose I'm looking for the 'right' way to do this sort of
thing!

I should just say that when I tried taking the specialised c'tor
implementation code out of the .cpp file and sticking it inline in the
class def and changing it to work on any type T, rather than just on
DComplex I got compile errors. This was because the implementation has
code like this in:

blah = DComplex(re(i),im(i));

and when I changed that to:

blah = T(re(i),im(i));

I got:

.../../rw\math\mathvec.cc(147) : error C2564: 'int' : a function-style
conversion to a built-in type can only take one argument
which I understand. So that tells me why they have specialised this
c'tor.

Hope that all makes sense and I wasn't too long-winded.

Ben
Jul 19 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
"Ben" <be****@hotmail.com> wrote...
I'm trying to make a third party lib (Rogue Wave's math.h++) compile
(under VC7) and I'm having some problems with what I think is code
that was written specifically to work with the older (less standard)
versions of the VC compiler.
[...]


You might be better off talking to Rouge Wave or posting your
question to a VC++ newsgroup. Math.h++ is reported obsolete
by Rogue Wave itself. Whether you will be able to upgrade your
library is not really a language question. However, from the
sanity point of view, if the manufacturer of the product has
given up on it, there is no sense to spend time doing their job
just to save a few bucks.

Of course, you could continue rewriting Math.h++ to work with
the current version of VC++, but (a) wouldn't you rather solve
your own problems? and (b) what if you need to change compilers,
will you rewrite all your other libraries that need that, too?

As to the specialisation, try declaring it in the header. Let
the implementation be in the translation module, just add

template<>
RWMathVec<DComplex>::RWMathVec(
const RWMathVec<double>& re,
const RWMathVec<double>& im);

after the RWMathVec template definition.

If that doesn't solve the problem, try asking in a VC++ newsgroup.

Victor
Jul 19 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.