Hi, we are using boost to develp cross-platform stuff. I am the Mac developer. The Mac is a 64 bit Intel machine, development environment is Xcode, of course, using gcc as compiler. To create code as robust as possible I always turn on as many warning levels as possible. Usually I am using this: -Wall -Wextra -Wconversion -Wshorten-64-to-32 This worked great with all basic boost stuff that we've used previously. Now I tried just to include thread.hpp and I get many many compiler warnings! I just do: #include "boost/thread.hpp" The warnings are just two kinds of warnings: 1.) warning: implicit conversion shortens 64-bit value into a 32-bit value 2.) warning: missing initializer for member '...' An example for the first warning can be found in gregorian_calender.ipp (just showing relevant parts): template<typename ymd_type_, typename date_int_type_> BOOST_DATE_TIME_INLINE int gregorian_calendar_base<ymd_type_,date_int_type_>::week_number(const ymd_type& ymd) { ... unsigned long week = (juliantoday + day - julianbegin + 4)/7; if ((week >= 1) && (week <= 52)) { return week; } ... Here's clearly missing a cast to tell the compiler that it's ok to return the unisigned long as int. On most 64 bit systems, long is 64 bit but int is 32 bit. The second warning is caused by the following line in conversion.hpp: std::tm datetm = {}; // zero initialization is needed for extension members, like tm_zone In this line I get the "missing initializer" warning for every member of the struct, e.g. tm::tm_sec, tm::tm_min, tm::tm_hour etc. What's the intension by initializing with empty braces? IMO this is not a standard initialization method. Is there any chance that these errors get fixed? Any ideas how to use thread.hpp without reducing my warning levels? Does anyone have the same problems? Regards, Manfred Schwind -- http://mani.de - friendly software iVolume - listen to music hands-free LittleSecrets - the encrypted notepad Sahara - sand in your pocket Watchdog - baffle the curious
AMDG Manfred Schwind wrote:
The second warning is caused by the following line in conversion.hpp:
std::tm datetm = {}; // zero initialization is needed for extension members, like tm_zone
In this line I get the "missing initializer" warning for every member of the struct, e.g. tm::tm_sec, tm::tm_min, tm::tm_hour etc. What's the intension by initializing with empty braces? IMO this is not a standard initialization method.
Yes it is. In Christ, Steven Watanabe
I was wondering the same thing, whether or not this was going to be fixed or if there was a fix without having to change the code in that boost file. Why was religion brought into this coding thread? I don't understand what Steven Watanabe is talking about... -- -Jaime http://www.jaimerios.com On Thu, Apr 22, 2010 at 10:55 AM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
Manfred Schwind wrote:
The second warning is caused by the following line in conversion.hpp:
std::tm datetm = {}; // zero initialization is needed for extension members, like tm_zone
In this line I get the "missing initializer" warning for every member of the struct, e.g. tm::tm_sec, tm::tm_min, tm::tm_hour etc. What's the intension by initializing with empty braces? IMO this is not a standard initialization method.
Yes it is.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Tue, May 11, 2010 at 7:56 AM, Jaime Rios <xdev74@gmail.com> wrote:
I was wondering the same thing, whether or not this was going to be fixed or if there was a fix without having to change the code in that boost file. Why was religion brought into this coding thread? I don't understand what Steven Watanabe is talking about...
He just informs you that { } is a standard form of initialization. In Buddha, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Manfred Schwind <lists@mani.de> writes:
This worked great with all basic boost stuff that we've used previously. Now I tried just to include thread.hpp and I get many many compiler warnings! I just do:
#include "boost/thread.hpp"
The warnings are just two kinds of warnings: 1.) warning: implicit conversion shortens 64-bit value into a 32-bit value 2.) warning: missing initializer for member '...'
An example for the first warning can be found in gregorian_calender.ipp (just showing relevant parts):
Most of these warnings are from the Boost.DateTime library, which is used by Boost.Thread. I believe they are all harmless, if annoying. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Anthony Williams <anthony.ajw <at> gmail.com> writes:
Manfred Schwind <lists <at> mani.de> writes:
#include "boost/thread.hpp"
The warnings are just two kinds of warnings: 1.) warning: implicit conversion shortens 64-bit value into a 32-bit value 2.) warning: missing initializer for member '...'
An example for the first warning can be found in gregorian_calender.ipp
(just showing relevant parts):
Most of these warnings are from the Boost.DateTime library, which is used by Boost.Thread. I believe they are all harmless, if annoying.
Our development group's process specifically disallows any warnings in code before it is released. Some exceptions have been made in intransigent situations, but the warnings mentioned above do not fall into that category. Therefore, we have been forced to wrap thread.hpp's inclusion as follows: #if defined(_MSC_VER) #pragma warning(push,3) #endif // defined(_MSC_VER) #include "boost/thread.hpp" #if defined(_MSC_VER) #pragma warning(pop) #endif // defined(_MSC_VER) Compilation using gcc 4.1.2, even with -Wall, does not elicit the warnings. It's ugly, I know. We could have chosen to compile the entire translation unit, or even project, using warning level 3, but the advantage of compiling at the highest warning level wherever and whenever possible dictated the more focused approach above. Hopefully the code producing these warnings will be fixed in a near release... Geoff Shapiro FLIR Systems, Inc.
participants (6)
-
Anthony Williams
-
Emil Dotchevski
-
Geoff Shapiro
-
Jaime Rios
-
Manfred Schwind
-
Steven Watanabe