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

template error

P: n/a
Hello,

I am trying to compile some code that includes third party header files
(part of a library). I keep getting an error on the templates they've
defined. An example error follows:

"/usr/local/SensAble/GHOST/v31/include/gstGenericMatrix.h", line 115:
error(1424):
constant "DIMM" is not used in declaring the parameter types of
function template "gstGenericMatrix::mulPointMatrix"
template <class PT1, class PT2, class MAT, int DIMM, int DIMN>

The code excerpt that generates this error is:

template <class PT1, class PT2, class MAT, int DIMM, int DIMN>
inline void mulPointMatrix(PT1 & res,
const PT2 & p,
const MAT & m)
{
for (int i = 0; i < DIMN; ++i)
{
res[i] = 0;
for (int j = 0; j < DIMM; ++j)
{
res[i] += p[j] * m[j][i];
}
}
}

Does anyone know what the problem is? As mentioned, this is a header file
for a third-party library (that I don't have source code for). Apparently,
they built their applications with MIPSpro 7.3. I am using MIPSpro 7.2.1 on
an Octane running Irix 6.5.19f. Is this something that is allowed in MIPSpro
7.3, but not MIPSpro 7.2.1?

Thanks for any help,
Adam
Jul 19 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
On Tue, 19 Aug 2003 12:53:18 -0400, "Adam Coutee" <gt*****@prism.gatech.edu> wrote:
I am trying to compile some code that includes third party header files
(part of a library). I keep getting an error on the templates they've
defined. An example error follows:

"/usr/local/SensAble/GHOST/v31/include/gstGenericMatrix.h", line 115:
error(1424):
constant "DIMM" is not used in declaring the parameter types of
function template "gstGenericMatrix::mulPointMatrix"
template <class PT1, class PT2, class MAT, int DIMM, int DIMN>

The code excerpt that generates this error is:

template <class PT1, class PT2, class MAT, int DIMM, int DIMN>
inline void mulPointMatrix(PT1 & res,
const PT2 & p,
const MAT & m)
{
for (int i = 0; i < DIMN; ++i)
{
res[i] = 0;
for (int j = 0; j < DIMM; ++j)
{
res[i] += p[j] * m[j][i];
}
}
}

Does anyone know what the problem is?


That the compiler requires all template parameters to be used somehow
in the function's signature (because the compiler says so).

One solution could be to introduce dummy arguments, like so:
inline void mulPointMatrix(
PT1& res,
PT2 const& p,
MAT const& m,
int dummy1 = DIMM,
int dummy2 = DIMN
)
or perhaps
inline void mulPointMatrix(
PT1& res,
PT2 const& p,
MAT const& m,
int dummy1[DIMM] = 0,
int dummy2[DIMN] = 0
)
Another solution, to use a better compiler.

A third solution, not incompatible with the second, to use a better
library... ;-)

Jul 19 '05 #2

P: n/a

"Alf P. Steinbach" <al***@start.no> wrote in message news:3f****************@News.CIS.DFN.DE...
inline void mulPointMatrix(
PT1& res,
PT2 const& p,
MAT const& m,
int dummy1 = DIMM,
int dummy2 = DIMN
) I don't think this one will work. If the compiler relies on the function signature
to differentiate the template specializations, then it still fails.
inline void mulPointMatrix(
PT1& res,
PT2 const& p,
MAT const& m,
int dummy1[DIMM] = 0,
int dummy2[DIMN] = 0
)


I don't think this will work either, the arrays are converted to int* to form the function
type.
Jul 19 '05 #3

P: n/a
On Tue, 19 Aug 2003 13:23:58 -0400, "Ron Natalie" <ro*@sensor.com> wrote:

"Alf P. Steinbach" <al***@start.no> wrote in message news:3f****************@News.CIS.DFN.DE...
inline void mulPointMatrix(
PT1& res,
PT2 const& p,
MAT const& m,
int dummy1 = DIMM,
int dummy2 = DIMN
)

I don't think this one will work. If the compiler relies on the function signature
to differentiate the template specializations, then it still fails.
inline void mulPointMatrix(
PT1& res,
PT2 const& p,
MAT const& m,
int dummy1[DIMM] = 0,
int dummy2[DIMN] = 0
)


I don't think this will work either, the arrays are converted to int* to form the function
type.


Well, what "used" means obviously depends on the (erronous) compiler.

But how about
template< int N >
struct Dummy
{
Dummy( int ) {}
};

template <class PT1, class PT2, class MAT, int DIMM, int DIMN>
inline void mulPointMatrix(
PT1& res,
PT2 const& p,
MAT const& m,
Dummy<DIMM> dummy1 = 0,
Dummy<DIMN> dummy2 = 0
)
{
}

?

Of course, the best solution for the OP would be to use both a better
compiler and a better library, if possible.

Jul 19 '05 #4

P: n/a

"Alf P. Steinbach" <al***@start.no> wrote in message news:3f****************@News.CIS.DFN.DE...


Well, what "used" means obviously depends on the (erronous) compiler.

But how about
template< int N >
struct Dummy
{
Dummy( int ) {}
};

template <class PT1, class PT2, class MAT, int DIMM, int DIMN>
inline void mulPointMatrix(
PT1& res,
PT2 const& p,
MAT const& m,
Dummy<DIMM> dummy1 = 0,
Dummy<DIMN> dummy2 = 0
)
{
}


That one looks better.
Another solution would be to wrap the function in a class that depends on the
template args.
Jul 19 '05 #5

P: n/a
On Tue, 19 Aug 2003 13:36:16 -0400, "Ron Natalie" <ro*@sensor.com> wrote:

"Alf P. Steinbach" <al***@start.no> wrote in message news:3f****************@News.CIS.DFN.DE...


Well, what "used" means obviously depends on the (erronous) compiler.

But how about
template< int N >
struct Dummy
{
Dummy( int ) {}
};

template <class PT1, class PT2, class MAT, int DIMM, int DIMN>
inline void mulPointMatrix(
PT1& res,
PT2 const& p,
MAT const& m,
Dummy<DIMM> dummy1 = 0,
Dummy<DIMN> dummy2 = 0
)
{
}


That one looks better.
Another solution would be to wrap the function in a class that depends on the
template args.


If the library can be redesigned then _much_ better solutions exist. Keeping
the "fixed size matrix type" idea the size should be deducible from the type.
Even better, if possible allow mixture of fixed-size and dynamic-size with
compile time checking where all necessary information is available (now that
is, I think, a nice design problem -- is it possible to do in a clean way?).

But the intent was to not require any changes to existing client code.

Jul 19 '05 #6

P: n/a


Of course, the best solution for the OP would be to use both a better
compiler and a better library, if possible.


Thanks for all of the info guys...
Sadly enough, I can't get a better library (what I have is what I get). :(

However, it seems to me that you think a newer version of the compiler
(MIPSpro) may do the trick. Is this the case?

Thanks again,
Adam
Jul 19 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.