Re: MTL with MS Visual Studio 2005

The following old post might help? Among other small things MTL is not 
compatible with recently required use of typename. The fixes are actually 
quite simple and although I mentioned them for Visual Studio they will be 
the similar for any modern standards compliant compiler.



Terry






I thought it would be useful to others to explain the very small number (4)
of patches required to make 2.1.2-22 with the Markus Grabner,
mtl-2.1.2-22-gcc-4.02.patch from your web site and ITL 4.0.0-1 compatible
with the .Net 2003 version of Visual Studio.

As many of you will realise, the version of the C++ compiler shipped with
.Net 2003 is a much needed leap ahead in standard compliance and the changes
to MTL fall into two basic categories. The first type are removing checks
that introduced special fixes for the Microsoft scenario and second - to
make further compliance changes which push the MTL code closer to (someones
view of) the standards. The changes  (more typedefs... ) should not hurt
other compilers.

I cannot supply you with the diff files as I am afraid I am not really
familiar with the appropriate formats you use in unix builds - and in any
case thought that your developers would probably prefer to do it
differently - but if it helps I am happy to supply you with the few files
that I have mildly edited (and which i would hope still compatible with all
other recent compilers). With these changes the warnings that are raised
relate to the 64 bit incompatibility type (except the ITL examples which are
broken for different reasons) Almost all examples in the newest distribution
of ITL build fine. The warnings go away if one selects the ignore 64 bit
compatibility option in the C++ settings for the project.

I would hope that you can make these changes as I am sure many would be
greatful. I have not tried to supply projects or solutions - just the
changes needed for (what I hope works out as) perfect compilation of the
(vast majority of the example) code.

The most important (and surprising) change is in mtl_config.h . I took the
one created by a default ./configure under cygwin and made the following
change which eliminates certain special treatment since _MSC_VER_ is 1310,

changes in in mtl_config.h

#if defined(_MSC_VER) && !defined(__MWERKS__)
#     if      ( _MSC_VER < 1300 )
#           define _MSVCPP_ _MSC_VER
#     else
//tjl added next line
# if ( _MSC_VER < 1310 )
#           define _MSVCPP7_ _MSC_VER
//tjl added next line
#endif
#     endif
#endif

one side effect of this change is that blocking is allowed and as you
eliminated it for gcc on intel as well I wondered if this was a correct
decision on my part. All other changes I found in compiling all the tests
and examples in your distribution that do not use ITL or in the ITKL
distribution I would classify as minor compliance issues of the sort that
one always picks up when one uses different compilers. I have not tested the
changes with another compiler but expect they would be fine.:

more typenames needed in next expression in block2d.h
    //typedef typename IF<isConst, block_vector::const_reference,
    //           block_vector::reference>::RET reference;
           //tjl replaced the above expression with next lines
     typedef typename IF<isConst,typename  block_vector::const_reference,
              typename   block_vector::reference>::RET reference;

and in dense2D.h
// inline rect_offset<size_t,MM,NN>::rect_offset(const
rect_offset<size_t,MM,NN>::transpose_type& x)
// tjl
inline rect_offset<size_t,MM,NN>::rect_offset(const typename
rect_offset<size_t,MM,NN>::transpose_type& x)

The constant 10.0 defaults to double and needs to be float in utils.h
inline float
make_rand_element(float)
{
 float r = float(rand());
//  return r/float(RAND_MAX)*10.0;
 //tjl
   return r/float(RAND_MAX)*float(10.0);
}


in compiling the example subrange_vector the following code in mtl.h became
ambiguous, and the compiler identified two equivalent conversions for the
arguments to z[] and x[] in mtl.h so an explicit cast to the intended type
is provided to avoids an ambiguity and error in the example subrange_vector

// tjl the following does not generate an error in subrange_vector
     {
           typedef typename mtl::dense_iterator<Matrix::OneD::value_type
*>::Distance ind_type;
           T tmp = z[(ind_type)j.row()];
           for (; j != jend; ++j)
                 tmp += *j * x[(ind_type)j.column()];
           z[(ind_type)j.row()] = tmp;

           //T tmp = z[j.row()];
           //for (; j != jend; ++j)
           //  tmp += *j * x[j.column()];
           //z[j.row()] = tmp;
     }




_______________________________________________
This list is archived at http://www.osl.iu.edu/MailArchives/mtl-devel/