Hi,

Just had a quick look about the exporting makefiles issue in the VC++ help, and the 2003 version explicitly says that you can not export makefiles (whatever the reason for that may be). However, there seems to be the possibility of running the editor, would you believe it, in a command line mode that will treat the solution file as a makefile. Whatever was wrong with exporting makefiles and running them through nmake does not explain.

Anyhow, now that I am in rant mode about Visual Studio I will comment on a problem I have found. As I said in a previous message we are trying to write a wrapper that uses blitz and the intel MKL implementation of LAPACK. In general it is rather simple, just passing the pointers returned by the data() method to the LAPACK functions.

I started writing my code using gcc, just to check that the project was feasible and would not take a huge amount of time. Using gcc I used the following approach to wrap the LAPACK functions. For each function there are usually 4 flavours, two real (single and double precision) and two complex (again single and double). The signature of the function is the same, only the types of the arguments are different:

slapack_function(float *,float*,int*) // single precision real
dlapack_function(double*,double*,int*) // double precision real
clapack_function(MKL_Complex8*,MKL_Complex8*,int*) // single precision complex
zlapack_function(MKL_Complex16*,MKL_Complex16*,int*) // double precision complex

the MKL_Complex types are structs like:

struct MKL_Complex8 {
float real;
float imag;
};

so you can cast safely from complex<float>* to MKL_Complex8* and the other way around.

The C++ interface will be a set of classes that call MKL as a back-end, and use blitz for the matrix representation, like so:

template<class T> class LUFactorisation
{

public:

/// default constructor

CLUFactorisation(void):mResult(Array<T,2>(FortranArray<2>())),mIpiv(Array<int,1>(FortranArray<1>())){;}

/// implements the call to the LAPACK function

void Factor(const Array<T,2>&);

/// returns the L matrix

Array<T,2> L(void);

/// returns the U matrix

Array<T,2> U(void);

private:

Array<T,2> mResult;

/// contains the permutation vector, row i is swapped with row mIpiv(i)

Array<int,1> mIpiv;

};

There are two possibilities for getting Factor to call the right LAPACK function, explicit specialisation of the template for each type, or writing a template function that wraps the LAPACK function and let the compiler generate the four different Factor functions. The second approach is more economical, as in this case the only difference between the four template specialisations is which function to call, and the rest of the code is exactly the same.

So, I would write something like:

template<class T> void lapack_function_wapper(MKL_Traits<T>::Type *,MKL_Traits<T>::Type *,int*)

and specialise for each type. Here MKL_Traits<T>::Type returns the correct type expected by the MKL functions, float for T = float, double for T=double, MKL_Complex8 for complex<float> and MKL_Complex16 for complex<double>.

This worked fine with gcc, with these wrappers getting expanded in line, even without optimisation.

Now, here it is a VS only shop, so I need to port that code to VS, luckily VS .NET 2003 compiles blitz, so it should be a matter of just copying the files and generating the project, as there is nothing really fancy in what I have written, right? Nope, The above template trick will not work in VS, it refuses to recognise the specialisations as specialisations of the above template, and I end up with no other choice but to use overloading instead. Not that overloading is all that bad, but I would expect that templates would give slightly better performance, as they should get automatically inlined at compile time, while it might be slightly trickier to get the compiler to inline the overloaded functions.

So, my question is, is what I am trying to do non standard and it just happens that it works in gcc, but it is not really supposed to or is VS support of templates still slightly flaky?

Thanks for your patience

Carlos A. Rega, PhD
Development Scientist
Malvern Instruments Ltd
Grovewood Rd, Malvern
WR14 1XZ

Tel: +44 (0)1684 581 304
Fax: +44 (0)1684 892 789

e-mail: carlos.rega@malvern.co.uk

--------------------------------------------------------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed.

If you have received this email in error please notify the
originator of the message.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Malvern Instruments.