RE: [Libmesh-devel] Real != double

[Roy S. <roy...@ic...>]

On Tue, 1 Nov 2005, KIRK, BENJAMIN (JSC-EG) (NASA) wrote:

> If you have an account on longhorn you might check there.  I noted the same
> issue there before I left last night.  If you don't have one I am sure John
> can re-create it.
>
> Here is my typical build procedure on that machine:
>
> cdw
> dmget $PETSC_DIR
> cvs -d:ext:...  co libmesh; cd libmesh
> ./configure --disable-shared --disable-tecplot
> make
> ...
>
> and the error comes quick:
> longhorn$ make
> Compiling C++ (in optimized mode) src/base/dof_map.C...
> "/work/utexas/ao/bkirk/libmesh/include/numerics/type_vector.h", line 538.1:
> 1540 -1269 (S) The template argument for the non-type template parameter of
> type "boo l" must be an integral constant expression.
> "/work/utexas/ao/bkirk/libmesh/include/numerics/type_vector.h", line 683.6:
> 1540 -0700 (I) The previous message was produced while processing
> "operator*".
> gmake: *** [src/base/dof_map.powerpc-ibm-aix5.2.0.0.opt.o] Error 1

Hmmm... I perhaps should have looked more closely at the boost
compiler compatibility tests.  It looks like Sun's compilers need some
work.

http://engineering.meta-comm.com/boost-regression/1_33_0/user/utility_.html

Apparantly there's a "BOOST_NO_SFINAE" define that they use to turn
off stuff like enable_if<> on compilers that won't support it.  In
/usr/include/boost/config/compiler/sunpro_cc.hpp is:

#    if (__SUNPRO_CC <= 0x540) || !defined(BOOST_STRICT_CONFIG)
#      define BOOST_NO_TEMPLATE_TEMPLATES
        // see http://lists.boost.org/MailArchives/boost/msg47184.php
        // and http://lists.boost.org/MailArchives/boost/msg47220.php
#      define BOOST_NO_INCLASS_MEMBER_INITIALIZATION
#      define BOOST_NO_SFINAE
#      define BOOST_NO_ARRAY_TYPE_SPECIALIZATIONS
#    endif

I'm not sure if this means that Sun compilers newer than version 0x540 support
these feature, or if it just means that 0x540 was the newest version
as of my boost release.

Want me to write a workaround?  I don't see any way to get operator*
to work properly for both arbitrary scalars and vectors without
something like that enable_if trick; however we could replace it with
explicit definitions for just the four Scalar types we currently use.
---
Roy