[config] polygon library long long, long double portability

[Simonson, Lucanus J]

Christian Henning wrote:
> Lucanus, this following compiles just fine with mine MSVC8. I have
> basically moved the enable_if as a function parameter. I hope this
> helps you. I for myself had similar issues when I set up the the new
> gil::io. These compiler errors are very painful to deal with.
>

Sneaky!  I like it.  I'm glad someone who has dealt with the issue in the past was able to offer some guidance.  It may take me some time to apply the fix because the number of functions in question is large.

Thank you,
Luke
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Simonson, Lucanus J]

Christian Henning wrote:
> Lucanus, this following compiles just fine with mine MSVC8. I have
> basically moved the enable_if as a function parameter. I hope this
> helps you. I for myself had similar issues when I set up the the new
> gil::io. These compiler errors are very painful to deal with.

It turns out this only works because the two versions of encompass in my example differ in their arguments such that the compiler can disambiguate them without SFINAE.

There are three versions of encompass related to rectangle.  The two that work on rectangle,rectangle and rectangle,point respectively still don't compile with your fix:

  // enlarge rectangle to encompass the Rectangle b
  template <typename rectangle_type_1, typename rectangle_type_2>
  bool
  encompass(rectangle_type_1& rectangle, const rectangle_type_2& b,
  typename enable_if< typename gtl_and<
    typename is_mutable_rectangle_concept<typename geometry_concept<rectangle_type_1>::type>::type,
    typename is_rectangle_concept<typename geometry_concept<rectangle_type_2>::type>::type>::type,
                       void>::type *dummy = 0) { return true; }

  // enlarge rectangle to encompass the point b
  template <typename rectangle_type_1, typename point_type>
  bool
  encompass(rectangle_type_1& rectangle, const point_type& b,  
  typename enable_if<
    typename gtl_and<
typename is_mutable_rectangle_concept<typename geometry_concept<rectangle_type_1>::type>::type,
typename is_point_concept<typename geometry_concept<point_type>::type>::type>::type,
    void>::type *dummy = 0) { return true;  }

The compiler gives a "redefinition of default parameter : parameter 3" for these two overloads, failing to take SFINAE into account.  By changing the type from void* to int* the compiler allows them to both instantiate, but then gives a "function call is ambiguous" error because it is using the normal rules for overloading and only by specifying the third parameter would the caller be able to select the correct function.

Luke

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christian Henning]

We have to make sure we are trying to compile the same code! The
following works when using MSVC8. There are three encompass functions.
Can you tell me if that's the right code?


#include "isotropy.hpp"
#include "rectangle_data.hpp"
#include "point_data.hpp"
#include "point_traits.hpp"
#include "interval_traits.hpp"
#include "rectangle_traits.hpp"
#include "point_concept.hpp"
#include "interval_concept.hpp"
//#include "rectangle_concept.hpp"

namespace boost { namespace polygon {

struct rectangle_concept{};

template <typename T>
struct geometry_concept< rectangle_data< T > >
{
typedef rectangle_concept type;
};

template <typename T>
struct is_mutable_rectangle_concept { typedef gtl_no type; };
template <>
struct is_mutable_rectangle_concept< rectangle_concept > { typedef
gtl_yes type; };

template <typename T>
struct is_rectangle_concept { typedef gtl_no type; };
template <>
struct is_rectangle_concept< rectangle_concept > { typedef gtl_yes type; };

template< typename rectangle_type
        , typename interval_type
        >
bool
encompass( rectangle_type& rectangle
         , const interval_type& b
         , orientation_2d orient
         , typename enable_if< typename gtl_and< typename
is_mutable_rectangle_concept< typename geometry_concept<
rectangle_type >::type >::type
                                               , typename
is_interval_concept         < typename geometry_concept< interval_type
 >::type >::type
                                               >::type
                             , bool
                             >::type* ptr = 0
         )
{
    return true;
}

// enlarge rectangle to encompass the Rectangle b
template < typename rectangle_type_1
         , typename rectangle_type_2
         >
bool
encompass( rectangle_type_1& rectangle
         , const rectangle_type_2& b
         , typename enable_if< typename gtl_and< typename
is_mutable_rectangle_concept<typename
geometry_concept<rectangle_type_1>::type>::type
                                               , typename
is_rectangle_concept<typename
geometry_concept<rectangle_type_2>::type>::type
                                               >::type
                             , void
                             >::type* dummy = 0
      )
{
    return true;
}

// enlarge rectangle to encompass the point b
template <typename rectangle_type_1, typename point_type>
bool
encompass( rectangle_type_1& rectangle
         , const point_type& b
         , typename enable_if< typename gtl_and< typename
is_mutable_rectangle_concept< typename
geometry_concept<rectangle_type_1 >::type>::type
                                               , typename
is_point_concept            < typename geometry_concept<point_type
  >::type>::type
                                               >::type
                             , void
                             >::type* dummy = 0
         )
{
    return true;
}

}
}

int main()
{
    using namespace boost;
    using namespace boost::polygon;
    rectangle_data<int> r;
    point_data<int> p;

    encompass(r, p);
    return 0;
}


Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Simonson, Lucanus J]

Christian Henning wrote:
> We have to make sure we are trying to compile the same code! The
> following works when using MSVC8. There are three encompass functions.
> Can you tell me if that's the right code?
>

Remember, I didn't get any syntax error from the start when convolve() wasn't declared before the encompass() functions.  When you add convolve back in the errors come back regardless of where enable_if goes.  Below I have added convolve() back in and tried to use your suggestion of putting enable_if as a default argument instead of return type pattern in convolve() as well.  Neither place for enable_if in convolve() is effective in eliminating the error.  Still, moving convolve() to follow the three encompass() functions makes the error go away, but since they are not directly related there is no way to know why.  I understand that it isn't intuitive what is going on.  Your sensible approach ought to work, but we need to remember that this is a compiler bug that results in inconsistent SFINAE behavior when templates are instantiated in the context of other templates that have arguments to enable_if in common.  One thing that does work is the *change the order* or arguments t
 o gtl_and<> in the enable_if of convolve() which breaks the (compiler internal) relationship between it and the overload of encompass such that compilation is able to succeed.  At this point I have enough understanding of the compiler bug to reason about how to work around it.  What is required is that *no two arguments to enable_if should ever be the same between any two functions in the entire compilation unit*.  This discipline can prevent the "optimization" MSVC8 is doing on template instantiations from breaking SFINAE because if no two enable_if's take the same arguments the compiler is forced to instantiate them all seperately and not change the order of instantiation (and make incorrect assumptions in doing so) in the way that breaks SFINAE.  I can likely do this easily by adding extra gtl_yes parameters to the gtl_and<> logic of functions that result in the erroneous error.  

By the way, what is the minimal header dependency I include to get the standard boost version of and<> to use in place of gtl_and?  I found the mpl header files rather hard to navigate and the documentation didn't answer my question.  Is the thing I need boost::mpl::and_<> which takes 2 or more parameters?

Thanks,
Luke

#include "isotropy.hpp"
#include "rectangle_data.hpp"
#include "point_data.hpp"
#include "point_traits.hpp"
#include "interval_traits.hpp"
#include "rectangle_traits.hpp"
#include "point_concept.hpp"
#include "interval_concept.hpp"
//#include "rectangle_concept.hpp"

namespace boost { namespace polygon {

struct rectangle_concept{};

template <typename T>
struct geometry_concept< rectangle_data< T > >
{
typedef rectangle_concept type;
};

template <typename T>
struct is_mutable_rectangle_concept { typedef gtl_no type; };
template <>
struct is_mutable_rectangle_concept< rectangle_concept > { typedef
gtl_yes type; };

template <typename T>
struct is_rectangle_concept { typedef gtl_no type; };
template <>
struct is_rectangle_concept< rectangle_concept > { typedef gtl_yes type; };

      // convolve with point
  template <typename rectangle_type, typename point_type>
 rectangle_type&
  convolve(rectangle_type& rectangle, const point_type& convolution_point,
    typename enable_if< typename gtl_and<
          typename is_mutable_rectangle_concept<typename geometry_concept<rectangle_type>::type>::type,
      typename is_point_concept<typename geometry_concept<point_type>::type>::type>::type,
                       void>::type *dummy = 0);

template< typename rectangle_type
        , typename interval_type
        >
bool
encompass( rectangle_type& rectangle
         , const interval_type& b
         , orientation_2d orient
         , typename enable_if< typename gtl_and< typename
is_mutable_rectangle_concept< typename geometry_concept<
rectangle_type >::type >::type
                                               , typename
is_interval_concept         < typename geometry_concept< interval_type
 >::type >::type
                                               >::type
                             , bool
                             >::type* ptr = 0
         )
{
    return true;
}

// enlarge rectangle to encompass the Rectangle b
template < typename rectangle_type_1
         , typename rectangle_type_2
         >
bool
encompass( rectangle_type_1& rectangle
         , const rectangle_type_2& b
         , typename enable_if< typename gtl_and< typename
is_mutable_rectangle_concept<typename
geometry_concept<rectangle_type_1>::type>::type
                                               , typename
is_rectangle_concept<typename
geometry_concept<rectangle_type_2>::type>::type
                                               >::type
                             , void
                             >::type* dummy = 0
      )
{
    return true;
}

// enlarge rectangle to encompass the point b
template <typename rectangle_type_1, typename point_type>
bool
encompass( rectangle_type_1& rectangle
         , const point_type& b
         , typename enable_if< typename gtl_and< typename
is_mutable_rectangle_concept< typename
geometry_concept<rectangle_type_1 >::type>::type
                                               , typename
is_point_concept            < typename geometry_concept<point_type
  >::type>::type
                                               >::type
                             , void
                             >::type* dummy = 0
         )
{
    return true;
}

}
}

int main()
{
    using namespace boost;
    using namespace boost::polygon;
    rectangle_data<int> r;
    point_data<int> p;

    encompass(r, p);
    return 0;
}
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christian Henning]

The following compiles and uses mpl::and_. Your problem is very
similar to a problem I once had. Steven Watanabe was able to fix by
just leaving out the ::type references. For instance

problem with msvc8:

mpl::and_< my_metafunction<...>::type, my_metafunction2<....>::type >::type

NO problem with msvc8:

mpl::and_< my_metafunction<...>, my_metafunction2<....> >

----------------

#include <boost/mpl/and.hpp>

#include "isotropy.hpp"
#include "rectangle_data.hpp"
#include "point_data.hpp"
#include "point_traits.hpp"
#include "interval_traits.hpp"
#include "rectangle_traits.hpp"
#include "point_concept.hpp"
#include "interval_concept.hpp"
//#include "rectangle_concept.hpp"

using namespace boost::mpl;

namespace boost { namespace polygon {

struct rectangle_concept{};

template <typename T>
struct geometry_concept< rectangle_data< T > >
{
typedef rectangle_concept type;
};

template <typename T>
struct is_mutable_rectangle_concept { typedef gtl_no type; };
template <>
struct is_mutable_rectangle_concept< rectangle_concept > { typedef
gtl_yes type; };

template <typename T>
struct is_rectangle_concept { typedef gtl_no type; };
template <>
struct is_rectangle_concept< rectangle_concept > { typedef gtl_yes type; };

// convolve with point
template< typename rectangle_type
        , typename point_type
        >
rectangle_type& convolve( rectangle_type& rectangle
                        , const point_type& convolution_point
                        , typename enable_if< typename mpl::and_<
typename is_mutable_rectangle_concept< typename geometry_concept<
rectangle_type >::type >
                                                                ,
typename is_point_concept            < typename geometry_concept<
point_type     >::type >
                                                                >
                                            , void
                                            >::type *dummy = 0
                        );

template< typename rectangle_type
        , typename interval_type
        >
bool
encompass( rectangle_type& rectangle
         , const interval_type& b
         , orientation_2d orient
         , typename enable_if< typename mpl::and_< typename
is_mutable_rectangle_concept< typename geometry_concept<
rectangle_type >::type >
                                               , typename
is_interval_concept         < typename geometry_concept< interval_type
 >::type >
                                               >
                             , bool
                             >::type* ptr = 0
         )
{
    return true;
}

// enlarge rectangle to encompass the Rectangle b
template < typename rectangle_type_1
         , typename rectangle_type_2
         >
bool
encompass( rectangle_type_1& rectangle
         , const rectangle_type_2& b
         , typename enable_if< typename mpl::and_< typename
is_mutable_rectangle_concept<typename
geometry_concept<rectangle_type_1>::type>
                                                 , typename
is_rectangle_concept<typename
geometry_concept<rectangle_type_2>::type>
                                                 >
                             , void
                             >::type* dummy = 0
      )
{
    return true;
}

// enlarge rectangle to encompass the point b
template <typename rectangle_type_1, typename point_type>
bool
encompass( rectangle_type_1& rectangle
         , const point_type& b
         , typename enable_if< typename mpl::and_< typename
is_mutable_rectangle_concept< typename
geometry_concept<rectangle_type_1 >::type >
                                                 , typename
is_point_concept            < typename geometry_concept<point_type
  >::type >
                                                 >
                             , void
                             >::type* dummy = 0
         )
{
    return true;
}

}
}

int main()
{
    using namespace boost;
    using namespace boost::polygon;
    rectangle_data<int> r;
    point_data<int> p;

    encompass(r, p);
    return 0;
}

I hope that fixes your problem and you have a great time fixing all of
your code. ;-) I was there already.

Regards,
Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Simonson, Lucanus J]

Christian Henning wrote:
> The following compiles and uses mpl::and_. Your problem is very
> similar to a problem I once had. Steven Watanabe was able to fix by
> just leaving out the ::type references. For instance

I tried replacing gtl_and and gtl_yes/no everywhere with mpl::bool_ and mpl::and_ and I get compile errors in MSVC9.  I have managed to work around bugs in MSVC9 with the way I have implemented gtl_and to return false by default and return true only in the case where I want the template to instantiate.  Because gtl_and_ has a complex default case MSVC9 incorrectly makes assumptions when optimizing its instantiation of multiple templates that cause it to ignore the SFINAE behavior I want under certain circumstances.  I don't fully understand what those circumstances are, but it is similar to the problems in MSVC8 where simple SFINAE tests work, but realistic code breaks down.  I don't believe it is feasible for me to use mpl::and_ and support even MSVC9.  

At this point I feel that the prospects for ever supporting MSVC8 are very dim.  SFINAE just doesn't work in MSVC well enough to use it to overload large numbers of generic functions.  This is why Barend and Bruno abandoned SFINAE, support for it in MSVC is so bad (inconsistent) it might as well not exist at all.  Porting my code to MSVC9 was extremely difficult and consumed several weeks for sustained (including overtime) effort.  If I would port to MSVC8 in 120 hours of programming effort comparable to what the port to MSVC9 took I might consider it, but I have no assurance that after 120 hour I would have SFINAE based code that works in MSVC8.  Since generic operators require SFINAE to not side swipe the stl and operator calls on enum types I have to use SFINAE, so changing to tag dispatching with static assert is not an option unless I defeature the operators.  I don't think supporting MSVC8 warrents re-writing the entire set of interfaces including defeaturing a signific
 ant number of them.

Regards,
Luke

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christian Henning]

Luke, I'm sure there are plenty of projects out there, including mine,
that make heavy use of SFINAE. Although, I understand that code can
become quite messy and hard to read, it does work fine in most of the
cases. For instance have a look at:

https://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension/io_new

esspecially at files like detail/read_image.hpp

If your project has a similar level of SFINAE usage, I would think we
could fix your code. I'm willing helping you out. Could you provide
minimal code that shows your problem with MSVC9?

Not all is lost. ;-)

Regards,
Christian

On Mon, Jul 6, 2009 at 2:47 PM, Simonson, Lucanus
J<lucanus.j.simonson@...> wrote:

> Christian Henning wrote:
>> The following compiles and uses mpl::and_. Your problem is very
>> similar to a problem I once had. Steven Watanabe was able to fix by
>> just leaving out the ::type references. For instance
>
> I tried replacing gtl_and and gtl_yes/no everywhere with mpl::bool_ and mpl::and_ and I get compile errors in MSVC9.  I have managed to work around bugs in MSVC9 with the way I have implemented gtl_and to return false by default and return true only in the case where I want the template to instantiate.  Because gtl_and_ has a complex default case MSVC9 incorrectly makes assumptions when optimizing its instantiation of multiple templates that cause it to ignore the SFINAE behavior I want under certain circumstances.  I don't fully understand what those circumstances are, but it is similar to the problems in MSVC8 where simple SFINAE tests work, but realistic code breaks down.  I don't believe it is feasible for me to use mpl::and_ and support even MSVC9.
>
> At this point I feel that the prospects for ever supporting MSVC8 are very dim.  SFINAE just doesn't work in MSVC well enough to use it to overload large numbers of generic functions.  This is why Barend and Bruno abandoned SFINAE, support for it in MSVC is so bad (inconsistent) it might as well not exist at all.  Porting my code to MSVC9 was extremely difficult and consumed several weeks for sustained (including overtime) effort.  If I would port to MSVC8 in 120 hours of programming effort comparable to what the port to MSVC9 took I might consider it, but I have no assurance that after 120 hour I would have SFINAE based code that works in MSVC8.  Since generic operators require SFINAE to not side swipe the stl and operator calls on enum types I have to use SFINAE, so changing to tag dispatching with static assert is not an option unless I defeature the operators.  I don't think supporting MSVC8 warrents re-writing the entire set of interfaces including defeaturing a signific
>  ant number of them.
>
> Regards,
> Luke
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Simonson, Lucanus J]

Christian Henning wrote:

> Luke, I'm sure there are plenty of projects out there, including mine,
> that make heavy use of SFINAE. Although, I understand that code can
> become quite messy and hard to read, it does work fine in most of the
> cases. For instance have a look at:
>
> https://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension/io_new
>
> esspecially at files like detail/read_image.hpp
>
> If your project has a similar level of SFINAE usage, I would think we
> could fix your code. I'm willing helping you out. Could you provide
> minimal code that shows your problem with MSVC9?
>
> Not all is lost. ;-)

Thank you for this kind offer.  The compile time logic of your code looks very similar to what I'm doing, and you do indeed have many overloads of read_image().  I'm gussing that the default argument usage of enable_if somehow gets around some of the problems I'm having with MSVC8 and 9.  I'd expect that it allows the compiler to decide that the functions are not ambiguous with its cursory examination and then if SFINAE actually gets triggered in all cases the enable_if'd argument doesn't need to be provided to call the functions.  I'll have to move literally hundreds of enable_if parameters from the return type to the last argument of every SFINAE protected function.  However, the operator functions cannot use this mechanism, and have to use SFINAE on the return type because they are limited to only two arguments.  It is likely that I cannot get them working at all in MSVC and will need to disable them with the preprocessor and provide alternative function call syntax.  I ma
 y end up separating them out into optional header files since generic operators are often prone to problems.

It looks like I have quite a bit of work ahead of me just to get my library compiling in MSVC9 using mpl::and_.  I'll see if I can get past the initial mass failures by moving the enable_if from the return type to the argument list so that I can determine what other problems I might have.

Thanks again,
Luke
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Simonson, Lucanus J]

Simonson, Lucanus J wrote:
>> If your project has a similar level of SFINAE usage, I would think we
>> could fix your code. I'm willing helping you out. Could you provide
>> minimal code that shows your problem with MSVC9?
>>
> It looks like I have quite a bit of work ahead of me just to get my
> library compiling in MSVC9 using mpl::and_.  I'll see if I can get
> past the initial mass failures by moving the enable_if from the
> return type to the argument list so that I can determine what other
> problems I might have.    
 
It turns out I was wrong, there were only a few instances where I needed to move enable_if from the return type to a default argument to get mpl::and_ working in MSVC9 in place of gtl_and.  Also, it looks like I am able to fix most problems in MSVC8 by moving enable_if to from the return type to a default argument and it turns out that with my workaround for MSVC8 enable_if can be induced to work on the return type for the operators that require that syntax if I take care to ensure that the argument to those enable_if instantiations is always a unique template.  I only have about 40 such operator declarations, so it is reasonable to do.  The easy way is to create a unique true type that inherits from mpl::bool_<true> for each such and add it in as an extra parameter to and_.  I may be able to work around all the MSVC bugs and have the entire library compiling in MSVC8 much easier than I had feared.  I still have to touch hundreds of declarations, but it looks like all problem
 s I'll encounter now have a proscribed solution.

Thanks, Christian, for not giving up on me,
Luke
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Simonson, Lucanus J]

Simonson, Lucanus J wrote:
> Simonson, Lucanus J wrote:
>>> If your project has a similar level of SFINAE usage, I would think
>>> we could fix your code. I'm willing helping you out. Could you
>>> provide minimal code that shows your problem with MSVC9?
>>>

All code compiles and generally passes my unit tests in MSVC8.  

It turns out that making the enable_if a default argument impacts regular overloading of functions and that adding a unique type into the enable_if logic to make all instantiations unique was a more reliable way to work around the compiler bugs.

I ran into a problem where boost::long_long_type isn't able to convert correctly to double.  In the code below the return type of square_euclidean_distance is long long because I need twice as many bits to store the result of a multiply.

  euclidean_distance(const rectangle_type& lvalue, const rectangle_type_2& rvalue) {
        double val = (double)square_euclidean_distance(lvalue, rvalue);
    return sqrt(val);
  }

It fails a runtime check stating that val is left unitialized and in the debugger I can see that the value is indeed uninitialized.  My question for any experts is why is this code failing?

I looking into the dissasembly and it looks like long long is 64 bit emulated in software in my 32 bit windows environment compiling with MSVC8.  I couldn't find anywhere the conversion from long long to double, and it seems that it is just silently failing to provide it, leaving me with uninitialized data.

In MSVC8 BOOST_HAS_LONG_LONG is defined and I'm using the boost::long_long_type the way it was suggested that I should.

Thanks,
Luke
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Steven Watanabe-4]

AMDG

Simonson, Lucanus J wrote:

> All code compiles and generally passes my unit tests in MSVC8.  
>
> It turns out that making the enable_if a default argument impacts regular overloading of functions and that adding a unique type into the enable_if logic to make all instantiations unique was a more reliable way to work around the compiler bugs.
>
> I ran into a problem where boost::long_long_type isn't able to convert correctly to double.  In the code below the return type of square_euclidean_distance is long long because I need twice as many bits to store the result of a multiply.
>
>   euclidean_distance(const rectangle_type& lvalue, const rectangle_type_2& rvalue) {
> double val = (double)square_euclidean_distance(lvalue, rvalue);
>     return sqrt(val);
>   }
>
> It fails a runtime check stating that val is left unitialized and in the debugger I can see that the value is indeed uninitialized.  My question for any experts is why is this code failing?
>
> I looking into the dissasembly and it looks like long long is 64 bit emulated in software in my 32 bit windows environment compiling with MSVC8.  I couldn't find anywhere the conversion from long long to double, and it seems that it is just silently failing to provide it, leaving me with uninitialized data.
>
> In MSVC8 BOOST_HAS_LONG_LONG is defined and I'm using the boost::long_long_type the way it was suggested that I should.
>  

I don't think this is related to the use of long long since the following
program works okay.

#include <iostream>

int main() {
    long long x = 1.0;
    double d = x;
    std::cout << x << std::endl;
}

I seem to recall seeing a problem like this before when
overload resolution doesn't quite work.
Perhaps you remember this thread?
http://lists.boost.org/Archives/boost/2009/01/146859.php
I think I had similar runtime weirdness in some
of the tests that I ran.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Simonson, Lucanus J]

Steven Watanabe wrote:

>> In MSVC8 BOOST_HAS_LONG_LONG is defined and I'm using the
>> boost::long_long_type the way it was suggested that I should.
>>
>
> I don't think this is related to the use of long long since the
> following program works okay.
>
> #include <iostream>
>
> int main() {
>     long long x = 1.0;
>     double d = x;
>     std::cout << x << std::endl;
> }
>

It turns out that I was using boost::long_long_type, and when I changed that typedef to long long the problem goes away.

I remember you mentioned this to me a while back:

> You might also consider using boost::int64_t from
> boost/cstdint.hpp guarded by BOOST_NO_INT64_T
>
> msvc has 64 bit ints, but doesn't call them long long.

I checked sizeof(long long) in my MSVC8 environment and it was 8 bytes, so I think I'm happy to use it.

Do you know what data type boost::long_long_type was using?

I ought to be able to check in a version of the code sometime tomorrow that works in MSVC8,9, gcc 3.2.2 and later, and icc9 and later.

Thanks,
Luke
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost