template error

[Adam Coutee]

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/gstGenericMatri x.h", line 115:
error(1424):
constant "DIMM" is not used in declaring the parameter types of
function template "gstGenericMatr ix::mulPointMat rix"
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

[Alf P. Steinbach]

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/gstGenericMatri x.h", line 115:
error(1424):
constant "DIMM" is not used in declaring the parameter types of
function template "gstGenericMatr ix::mulPointMat rix"
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... ;-)

[Ron Natalie]

"Alf P. Steinbach" <al***@start.no > wrote in message news:3f******** ********@News.C IS.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.

[Alf P. Steinbach]

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.C IS.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.

[Ron Natalie]

"Alf P. Steinbach" <al***@start.no > wrote in message news:3f******** ********@News.C IS.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.

[Alf P. Steinbach]

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.C IS.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.

[Adam Coutee]

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