Null class bug on x64 targets

[Kakhkhor Abdijalilov]

Null<Size> may not properly compile on x64 targets because. This
happened to me  with Intel C++ compiler. Proposal to change the Null
class with something like this.

//---------------------------------------------------------------------------
#include <ql/types.hpp>
#include <limits>
#include <boost/type_traits.hpp>

typedef double Real;

template <bool>
struct IntegerNull {
    static int value() {
        return std::numeric_limits<int>::max();
    }
};

template <>
struct IntegerNull<false> {
    static Real value() {
        return std::numeric_limits<Real>::max();
    }
};

template <typename T>
class Null {
public:
    Null() {}
    operator T() const {
        return T(IntegerNull<boost::is_floating_point<T>::value>::value());
    }
};
//---------------------------------------------------------------------------

Even better solution would be replace it with boost::optional but I
guess Null is needed for backward compatibility.

Regards,
Kakhkhor Abdijalilov.

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Kim Kuen Tang]

Hi Kakhkhor,

Kakhkhor Abdijalilov schrieb:
> Null<Size> may not properly compile on x64 targets because. This
> happened to me  with Intel C++ compiler.
i tested the original code in quanlib and i 've got the error that no
constructor is provided. But this is due to the fact that the macro x64
is not recognised by the compiler.
In fact there is no such symbol defined by the C++ standard. It depends
on the compiler.
 See the following code snippet:

#ifdef x64
    //! template class providing a null value for a given type.
    template <>
    class Null<Size> {
      public:
        Null() {}
        operator Size() const { return Size(QL_NULL_INTEGER); }
    };
#endif

If the macro is properly set then the compile error should disappear. In
case of visual stuio it is _M_X64. Perhaps boost has implemented an
universal one.
> Proposal to change the Null
> class with something like this.
>  
If you really want to change the class, you should open a ticker and
supply a patch.
But i see the problem that ur code doesnt prevent the user from writing
code like Null<std::vector<double> >().

Kim

> //---------------------------------------------------------------------------
> #include <ql/types.hpp>
> #include <limits>
> #include <boost/type_traits.hpp>
>
> typedef double Real;
>
> template <bool>
> struct IntegerNull {
>     static int value() {
>         return std::numeric_limits<int>::max();
>     }
> };
>
> template <>
> struct IntegerNull<false> {
>     static Real value() {
>         return std::numeric_limits<Real>::max();
>     }
> };
>
> template <typename T>
> class Null {
> public:
>     Null() {}
>     operator T() const {
>         return T(IntegerNull<boost::is_floating_point<T>::value>::value());
>     }
> };
> //---------------------------------------------------------------------------
>
> Even better solution would be replace it with boost::optional but I
> guess Null is needed for backward compatibility.
>
> Regards,
> Kakhkhor Abdijalilov.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>  

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Kakhkhor Abdijalilov]

Null class is rather confusing. We have Null<int>, Null<long>,
Null<long long>, Null<unsigned long>, Null<unsigned int>, Null<float>,
Null<double>, Null<long double> etc. Null<Size> is bound to conflict
with some of those Nulls on 32 bit platforms, that is why a macro
switch was needed. But the same macro brakes Null on 64 bit platforms.
Boost::optional is much better and already used in QuantLib. We should
use it instead of Null whenever possible. But working Null is still
needed for backward compatibility.

Only POD types need Null. Null<std::vector<double> > isn't a
minefield. We can't accidentally do something like this

POD_type x = Null<std::vector<double> >.

It won't compile.


Below is the null.hpp I am using with QuantLib. I doesn't depend on
x64 macro and works on both 32 and 64 bit platforms.

//---------------------------------------------------------------------------------------------
#ifndef quantlib_null_hpp
#define quantlib_null_hpp

#include <ql/types.hpp>
#include <limits>
#include <boost/type_traits.hpp>

namespace QuantLib {

    template <bool>
    struct FloatingPointNull;

    // null for floating poit types
    template <>
    struct FloatingPointNull<true> {
        static float nullValue() {
            return std::numeric_limits<float>::max();
        }
    };

    // null for integer types
    template <>
    struct FloatingPointNull<false> {
        static int nullValue() {
            return std::numeric_limits<int>::max();
        }
    };

    template <typename T>
    class Null {
    public:
        Null() {}
        operator T() const {
            return
T(FloatingPointNull<boost::is_floating_point<T>::value>::nullValue());
        }
    };

}

#endif
//---------------------------------------------------------------------------------------------

Regards,
Kakhkhor Abdijalilov.

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Dimathematician]

We had this discussion before. I think the agreement was to move to
boost optional and discourage
the usage of the Null class without removing it. One could use
boost::optional it in the following way

void testOptional(boost::optional<double> x=boost::optional<double>());

void testOptional(boost::optional<double> x){

    if(!x){
        std::cout << "x empty" << std::endl;
    }
    else{
        std::cout << x << std::endl;
    }
}

and call it with

        testOptional();
        testOptional(1.2);






Kakhkhor Abdijalilov schrieb:

> Null class is rather confusing. We have Null<int>, Null<long>,
> Null<long long>, Null<unsigned long>, Null<unsigned int>, Null<float>,
> Null<double>, Null<long double> etc. Null<Size> is bound to conflict
> with some of those Nulls on 32 bit platforms, that is why a macro
> switch was needed. But the same macro brakes Null on 64 bit platforms.
> Boost::optional is much better and already used in QuantLib. We should
> use it instead of Null whenever possible. But working Null is still
> needed for backward compatibility.
>
> Only POD types need Null. Null<std::vector<double> > isn't a
> minefield. We can't accidentally do something like this
>
> POD_type x = Null<std::vector<double> >.
>
> It won't compile.
>
>
> Below is the null.hpp I am using with QuantLib. I doesn't depend on
> x64 macro and works on both 32 and 64 bit platforms.
>
> //---------------------------------------------------------------------------------------------
> #ifndef quantlib_null_hpp
> #define quantlib_null_hpp
>
> #include <ql/types.hpp>
> #include <limits>
> #include <boost/type_traits.hpp>
>
> namespace QuantLib {
>
>     template <bool>
>     struct FloatingPointNull;
>
>     // null for floating poit types
>     template <>
>     struct FloatingPointNull<true> {
>         static float nullValue() {
>             return std::numeric_limits<float>::max();
>         }
>     };
>
>     // null for integer types
>     template <>
>     struct FloatingPointNull<false> {
>         static int nullValue() {
>             return std::numeric_limits<int>::max();
>         }
>     };
>
>     template <typename T>
>     class Null {
>     public:
>         Null() {}
>         operator T() const {
>             return
> T(FloatingPointNull<boost::is_floating_point<T>::value>::nullValue());
>         }
>     };
>
> }
>
> #endif
> //---------------------------------------------------------------------------------------------
>
> Regards,
> Kakhkhor Abdijalilov.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>  

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Kim Kuen Tang]

Kakhkhor Abdijalilov schrieb:
> Null class is rather confusing. We have Null<int>, Null<long>,
> Null<long long>, Null<unsigned long>, Null<unsigned int>, Null<float>,
> Null<double>, Null<long double> etc. Null<Size> is bound to conflict
> with some of those Nulls on 32 bit platforms, that is why a macro
> switch was needed.
Sorry, cant agree with this point. For a 32-bit msvc compiler size_t is
just unsigned int. ( The actual implementation depends on the
compiler.)  Since a specialization for the class Null already exists ,
you can write Null<Size>.
A macro switch is needed because for a 64bit msvc compiler size_t is
defined by
typedef unsigned __int64    size_t; (see crtdefs.h, line 488).
And since the class Null is not specialised for this type, u need
explicitly to define one.

>  But the same macro brakes Null on 64 bit platforms.
>  
Again u just need to set the correct macro, then the error should disappear.
> Boost::optional is much better and already used in QuantLib. We should
> use it instead of Null whenever possible. But working Null is still
> needed for backward compatibility.
>
> Only POD types need Null.
There exist also specializations for Non-POD objects like Array and  
IntervalPrice.

Kim

> Null<std::vector<double> > isn't a
> minefield. We can't accidentally do something like this
>
> POD_type x = Null<std::vector<double> >.
>
> It won't compile.
>
>
> Below is the null.hpp I am using with QuantLib. I doesn't depend on
> x64 macro and works on both 32 and 64 bit platforms
> //---------------------------------------------------------------------------------------------
> #ifndef quantlib_null_hpp
> #define quantlib_null_hpp
>
> #include <ql/types.hpp>
> #include <limits>
> #include <boost/type_traits.hpp>
>
> namespace QuantLib {
>
>     template <bool>
>     struct FloatingPointNull;
>
>     // null for floating poit types
>     template <>
>     struct FloatingPointNull<true> {
>         static float nullValue() {
>             return std::numeric_limits<float>::max();
>         }
>     };
>
>     // null for integer types
>     template <>
>     struct FloatingPointNull<false> {
>         static int nullValue() {
>             return std::numeric_limits<int>::max();
>         }
>     };
>
>     template <typename T>
>     class Null {
>     public:
>         Null() {}
>         operator T() const {
>             return
> T(FloatingPointNull<boost::is_floating_point<T>::value>::nullValue());
>         }
>     };
>
> }
>
> #endif
> //---------------------------------------------------------------------------------------------
>
> Regards,
> Kakhkhor Abdijalilov.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>  

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Kakhkhor Abdijalilov]

>Sorry, cant agree with this point. For a 32-bit msvc compiler size_t is just unsigned int.
That was my point as well. On 32bit targets Null<Size> and
Null<unsigned int> are the same thing. You need a macro to fix it.
There is also Null<unsigned long long> which conflicts with Null<Size>
on x64.

>Again u just need to set the correct macro, then the error should disappear.
And that is the problem. It means more work for the users. The
implementation from my previous e-mail could free the users from
dealing with macros. It will not overwrite any other specialization.

K.A.

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Thu, 2010-08-12 at 17:00 -0500, Kakhkhor Abdijalilov wrote:
> >Again u just need to set the correct macro, then the error should disappear.
> And that is the problem. It means more work for the users. The
> implementation from my previous e-mail could free the users from
> dealing with macros. It will not overwrite any other specialization.

The two of you are arguing the same thing, I think.  The users should't
even need to know there's a macro, or any other mechanism.  That used to
be the case, but a macro needs to be maintained across compilers and
means more work for the library writers.  Your solution puts the burden
on the Boost type-traits maintainers, which is fine with me...

As for Kim's worry about non-builtins, I though of that too, because I
remembered that we had Null<Date> and Null<Array> in the code---but I
had forgotten that somewhere along the way we removed the old catch-all
template and added explicit specializations for Null<Date> etc.
So Kakhkhor's template is going to cover integer and floating-point
types, and specializations will take care of the other classes.

I guess I'll go and check that the proposed implementation works on my
compilers, now.  Kakhkhor, a question: you report that your file doesn't
work with the Intel 11.1 compiler.  But the current version (the one in
the official QuantLib) doesn't work either, right?

Luigi


--

Any software problem can be solved by adding another layer of
indirection.
-- David J. Wheeler



------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Kakhkhor Abdijalilov]

QL compiles and works well with Visual C++ 2008 both in 32 and 64 bit
modes. I only tested Intel C++ compiler 11.1 in 64 bit mode with
Windows Vista 64. Everything compiles and links, but the program
crashes with all zero output. Curiously enough, everything works fine
in debug mode. The error comes from within Event::hasOccured method.
Could be either Singleton class or Settings class. I don't know yet.

Btw, without x64 macro auto linking with MS compiler won't work. I am
for not using separate names for 32 and 64 bit builds.

Regards,
K.A.

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Fri, 2010-08-13 at 14:40 -0500, Kakhkhor Abdijalilov wrote:
> Btw, without x64 macro auto linking with MS compiler won't work. I am
> for not using separate names for 32 and 64 bit builds.

Noted, but the idea was to allow different builds to coexist in the same
directory, so I'm afraid the different names are staying.

Luigi


--

When I was a boy of fourteen, my father was so ignorant I could hardly
stand to have the old man around. But when I got to be twenty-one, I
was astonished at how much the old man had learned in seven years.
-- Mark Twain



------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Kakhkhor Abdijalilov]

Some more ICC for Windows related issues showed up

1) BOOST_MSVC is not defined on IA-32, which prevents auto linking.
Including auto_link.hpp directly works.

2) The second issue is not caused directly by QuantLib, but it is good
to know about it.
Bjam compiles boost with _SECULRE_SCL=0 when ICC is used. But Visual
Studio's STL uses _SECULRE_SCL=1 by default and ICC relies  on Visual
Studio's implementation. QuantLib itself doesn't use any compiled
boost libraries, but the test suite links to boost unit test
framework, which is a compiled library. Inconsistent _SECULRE_SCL
values violate one definition rule and cause the test suite to fail or
even crash. To fix this issue one needs to recompile all libraries
using the same _SECULRE_SCL value.

Regards,
K.A.

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Tue, 2010-08-17 at 20:01 -0500, Kakhkhor Abdijalilov wrote:
> Some more ICC for Windows related issues showed up
>
> 1) BOOST_MSVC is not defined on IA-32, which prevents auto linking.
> Including auto_link.hpp directly works.

Does ICC define any macro that can be used to identify it?

Luigi


--

No, I'm not interested in developing a powerful brain. All I'm after
is just a mediocre brain, something like the president of American
Telephone and Telegraph Company.
-- Alan Turing on the possibilities of a thinking machine, 1943.



------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Kakhkhor Abdijalilov]

On Windows ICC defines both _MSC_VER and __INTEL_COMPILER.

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev