Warning C4244: conversion from 'int' to 'unsigned short' in microsec_time_clock.hpp line 103

[james@…]

With Visual Studio 2005, the compiler raises the following warning:

c:\programme\boost\boost_1_38_0\boost\date_time\microsec_time_clock.hpp(103) : warning C4244: 'argument' : conversion from 'int' to 'unsigned short', possible loss of data

The members of the std::tm struct are ints, but the greg_year type is declared as unsigned short in greg_year.hpp.

[james@…]

Line 99ff:

...
  std::tm curr;
  std::tm* curr_ptr = converter(&t, &curr);
  date_type d(static_cast<date_type::year_type::value_type>(curr_ptr->tm_year + 1900),
    static_cast<date_type::month_type::value_type>(curr_ptr->tm_mon + 1),
    static_cast<date_type::day_type::value_type>(curr_ptr->tm_mday));
...

This will suppress this warning.

[gareth.sylvester-bradley@…]

FWIW, this problem still applies to current release (1.41.0) and trunk. The file <boost/date_time/microsec_time_clock.hpp> ends up included in a lot of situations, e.g. via Boost.Thread, so I see this warning many many many times in my code base.

I independently reinvented the same patch as the OP. Unfortunately I didn't think to check Trac until I had one - any chance of this being applied so nobody else has to..?

[james@…]

Please fix this... The warnings are annoying.

[Andrey Semashev]

(In [61293]) Refs #2757. Added explicit casts to avoid warnings on MSVC.

[gareth.sylvester-bradley@…]

Thank you Andrey!

I assume this will have to wait for merge until 1.44.0?

[Andrey Semashev]

Yes, the problem is not that critical to push it for 1.43.

[Andrey Semashev]

(In [61892]) Fixes #2757. Added explicit casts to avoid warnings on MSVC.

[michael.cowperthwaite@…]

Seeing this warning with Boost 1.49, MSVS 2008. The warnings are not suppressible using MS's #pragma warning feature.

[anonymous]

Replying to michael.cowperthwaite@…:

Seeing this warning with Boost 1.49, MSVS 2008. The warnings are not suppressible using MS's #pragma warning feature.

Sorry, I was wrong; warning at different location. See new ticket #6936.