On Aug 20, 2010, at 10:38 AM, Robert Ramey wrote:

Jeff Flinn wrote:

...

Building boost 1.44 on Mac OSX generating universal binaries fails to compile serialization lib, due to static asserts in basic_binary_?archive.hpp's at:

BOOST_STATIC_ASSERT(sizeof(tracking_type) == sizeof(char));

It appears that this fails for the ppc architecture.

Robert, Any ideas on fixing this?

Thanks, Jeff

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

I included these asserts to trap any future change in the size of these types. Accidently changing these sizes silently breaks previous archives which is a major pain.

boost/archive/tracking_type is actually a bool - which I had assumed would be a char in all machines. So I guess that correct way to express this would be:

BOOST_STATIC_ASSERT(sizeof(tracking_type) == sizeof(bool));

Try making this change and verify that it fixes the problem and I'll check in the change.

Tests done on my Mac running 10.6.4: $ g++ --version i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664) $ cat junk.cpp #include <iostream> int main ( int argc, char *argv[] ) { std::cout << "sizeof (bool) = " << sizeof (bool) << std::endl; return 0; } $ g++ -arch i386 junk.cpp && ./a.out sizeof (bool) = 1 $ g++ -arch x86_64 junk.cpp && ./a.out sizeof (bool) = 1 $ g++ -arch ppc junk.cpp && ./a.out sizeof (bool) = 4 -- Marshall

Marshall Clow wrote:

On Aug 20, 2010, at 9:47 AM, Marshall Clow wrote:

...

On Aug 20, 2010, at 10:38 AM, Robert Ramey wrote:

...

Jeff Flinn wrote:

...

Building boost 1.44 on Mac OSX generating universal binaries fails to compile serialization lib, due to static asserts in basic_binary_?archive.hpp's at:

BOOST_STATIC_ASSERT(sizeof(tracking_type) == sizeof(char));

It appears that this fails for the ppc architecture.

Robert, Any ideas on fixing this?

Thanks, Jeff

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

I included these asserts to trap any future change in the size of these types. Accidently changing these sizes silently breaks previous archives which is a major pain.

boost/archive/tracking_type is actually a bool - which I had assumed would be a char in all machines. So I guess that correct way to express this would be:

BOOST_STATIC_ASSERT(sizeof(tracking_type) == sizeof(bool));

Try making this change and verify that it fixes the problem and I'll check in the change.

Tests done on my Mac running 10.6.4:

$ g++ --version i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)

$ cat junk.cpp #include <iostream>

int main ( int argc, char *argv[] ) { std::cout << "sizeof (bool) = " << sizeof (bool) << std::endl; return 0; }

$ g++ -arch i386 junk.cpp && ./a.out sizeof (bool) = 1

$ g++ -arch x86_64 junk.cpp && ./a.out sizeof (bool) = 1

$ g++ -arch ppc junk.cpp && ./a.out sizeof (bool) = 4

Better test (looks like Robert's change will work):

$ cat junk.cpp #include <iostream> #include <boost/archive/basic_archive.hpp>

int main ( int argc, char *argv[] ) { std::cout << "Sizeof (bool) = " << sizeof (bool) << std::endl; std::cout << "Sizeof (tracking_type) = " << sizeof (boost::archive::tracking_type) << std::endl; return 0; }

$ g++ -I /Marshall/Sources/boost/boost_1_44_0 -arch ppc junk.cpp && ./a.out Sizeof (bool) = 4 Sizeof (tracking_type) = 4

$ g++ -I /Marshall/Sources/boost/boost_1_44_0 -arch i386 junk.cpp && ./a.out Sizeof (bool) = 1 Sizeof (tracking_type) = 1

$ g++ -I /Marshall/Sources/boost/boost_1_44_0 -arch x86_64 junk.cpp && ./a.out Sizeof (bool) = 1 Sizeof (tracking_type) = 1

I concur, with Robert's fix I can build universal binaries on OSX 10.5.8. Thanks for the quick response. By the way Robert, thanks for clearing up all of the compiler warnings in both the lib and in portable_binary_archive over the last couple of releases. Thanks, Jeff

On Fri, Aug 20, 2010 at 1:02 PM, Robert Ramey <ramey@rrsd.com> wrote:

Jeff Flinn wrote:

...

By the way Robert, thanks for clearing up all of the compiler warnings in both the lib and in portable_binary_archive over the last couple of releases.

I'm glad you appreciate this.  I caused an unintended ripple effect which resulted in much agony - which is likely not over..

advice to prospective library developer's - use warning level 4 it's cheaper in the long run.

#pragma warning(push,1) on MSVC, and #pragma gcc system_header are cheaper. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Fri, Aug 20, 2010 at 5:13 PM, Robert Ramey <ramey@rrsd.com> wrote:

Emil Dotchevski wrote:

...

On Fri, Aug 20, 2010 at 1:02 PM, Robert Ramey <ramey@rrsd.com> wrote:

...

Jeff Flinn wrote:

...

By the way Robert, thanks for clearing up all of the compiler warnings in both the lib and in portable_binary_archive over the last couple of releases.

I'm glad you appreciate this. I caused an unintended ripple effect which resulted in much agony - which is likely not over..

advice to prospective library developer's - use warning level 4 it's cheaper in the long run.

#pragma warning(push,1) on MSVC, and #pragma gcc system_header are cheaper.

hmmm - please expand upon this.

I'm not sure if this is a good idea in general but I'm using this in Boost Exception and I'm not aware of any problems it causes. I have #if defined(__GNUC__) && !defined(BOOST_EXCEPTION_ENABLE_WARNINGS) #pragma GCC system_header #endif #if defined(_MSC_VER) && !defined(BOOST_EXCEPTION_ENABLE_WARNINGS) #pragma warning(push,1) #endif at the top of the header files (and the matching pop for MSVC at the end of the file), so when I build the code I can use whatever warning level is comfortable for me (combined with #define BOOST_EXCEPTION_ENABLE_WARNINGS), while everyone else doesn't see any warnings (I hope.) Of course that is a moot point if you like warning level 4 or the --pedantic stuff in GCC, but I find it very difficult to justify many of the things (for example, casts) people normally do to work around warnings. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Fri, Aug 20, 2010 at 9:33 PM, Robert Ramey <ramey@rrsd.com> wrote:

Emil Dotchevski wrote:

...

On Fri, Aug 20, 2010 at 5:13 PM, Robert Ramey <ramey@rrsd.com> wrote:

...

Emil Dotchevski wrote:

...

On Fri, Aug 20, 2010 at 1:02 PM, Robert Ramey <ramey@rrsd.com> wrote:

...

Jeff Flinn wrote:

...

By the way Robert, thanks for clearing up all of the compiler warnings in both the lib and in portable_binary_archive over the last couple of releases.

I'm glad you appreciate this. I caused an unintended ripple effect which resulted in much agony - which is likely not over..

advice to prospective library developer's - use warning level 4 it's cheaper in the long run.

#pragma warning(push,1) on MSVC, and #pragma gcc system_header are cheaper.

hmmm - please expand upon this.

I'm not sure if this is a good idea in general but I'm using this in Boost Exception and I'm not aware of any problems it causes. I have

#if defined(__GNUC__) && !defined(BOOST_EXCEPTION_ENABLE_WARNINGS) #pragma GCC system_header #endif #if defined(_MSC_VER) && !defined(BOOST_EXCEPTION_ENABLE_WARNINGS) #pragma warning(push,1) #endif

at the top of the header files (and the matching pop for MSVC at the end of the file), so when I build the code I can use whatever warning level is comfortable for me (combined with #define BOOST_EXCEPTION_ENABLE_WARNINGS), while everyone else doesn't see any warnings (I hope.)

Of course that is a moot point if you like warning level 4 or the --pedantic stuff in GCC, but I find it very difficult to justify many of the things (for example, casts) people normally do to work around warnings.

When I read you're response, I was thinking it was another way to enable maximum warnings.  If I understand you correctly, your view is that the warnings should be suppressed even when users enable higher levels.

So it seems we've got entirely opposed points of view here.

Personally, I found that the excercise of modifying code to eliminate warnings at the level resulted in eliminating a couple of potential bugs and hopefully maintaining this will keep new ones from creeping it.  I will concede that some warnings are over the top and I would like a better way (in GCC) to suppress them on a case by case basis.

I agree with you 100%. I wish there was a way to *suppress* a warning without altering the semantics of the program. But in GCC, there isn't. So the question is what to do with those pesky warnings that you think are over the top yet users of the library find useful? One option is to "fix" them anyway. Unfortunately, a lot of times this involves casting, and in general I find it ill-advised to use a cast to suppress a warning. Think about it: casts are used to tell the compiler to do something it wouldn't normally do because it is dangerous. This is true for all casts, including the ones people sprinkle around to "fix" warnings. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

Sent from my iPhone On Aug 20, 2010, at 9:09 PM, Emil Dotchevski <emil@revergestudios.com> wrote:

One option is to "fix" them anyway. Unfortunately, a lot of times this involves casting, and in general I find it ill-advised to use a cast to suppress a warning. Think about it: casts are used to tell the compiler to do something it wouldn't normally do because it is dangerous. This is true for all casts, including the ones people sprinkle around to "fix" warnings.

True, but you can often avoid those casts by allowing (presumably safer) implicit conversions to do the same work,e.g. instead of static_cast<Base&>(derived), declare and initialize a named Base&.

Dave Abrahams wrote:

Sent from my iPhone

On Aug 20, 2010, at 9:09 PM, Emil Dotchevski <emil@revergestudios.com> wrote:

...

One option is to "fix" them anyway. Unfortunately, a lot of times this involves casting, and in general I find it ill-advised to use a cast to suppress a warning. Think about it: casts are used to tell the compiler to do something it wouldn't normally do because it is dangerous. This is true for all casts, including the ones people sprinkle around to "fix" warnings.

True, but you can often avoid those casts by allowing (presumably safer) implicit conversions to do the same work,e.g. instead of static_cast<Base&>(derived), declare and initialize a named Base&.

Here is what I did. I had a bunch of warnings that I could have fixed with casts. In some cases I did. But in most cases I felt I was "Hiding the problem" by puting in a cast. What I ended up doing in many cases was make a special type such as // a special type of integer. This is used as an 'id" so it makes no // sense to apply arithmetic operation or to compare it to other integers // which are not this type of id class special_type { int m_i; public: // trap uninitialized values special_type(int i) : m_i(i) {} // trap erroneous comparisons bool operator==(const & special_type rhs) const { return m_i == rhs.m_i } // don't permit id to change - don't define assignment // but copying is ok special_type(const special_type & s) : m_i(s.m_i) ; }; Now compile your program and all the warning are now errors. (plus a whole new raft of errors). Then start doing things like replace int id; if(id == original_id) ... with special_type id(... ah think about this - this is a good thing); if(id == original_id) ... Now a) your warnings disappear b) you might have fixed a bug c) you have set things up to avoid future bugs d) at no cost in execution time This might look like a lot of work. But it really isn't. You have to think carefully about what kind of operations you want to actually permit and/or trap which is some work. But fixing the generated errors is very easy as the whole system almost tells you what to fix. I can do it while participating in an otherwise mind numbing phone conference. In fact it's a good way to do as it makes me sound less disinterested. Robert Ramey

At Sat, 21 Aug 2010 18:04:37 +0100, David Irvine wrote:

This looks like a good move and I think very efficient, although I think perhaps for completeness you should declare the assignment operator private, to prevent the compiler declaring if for you.

Not just perhaps; definitely. The intent clearly appears to be that assignment should be forbidden: // don't permit id to change - don't define assignment // but copying is ok special_type(const special_type & s) : m_i(s.m_i) ; And probably the constructor should be explicit. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

On Sat, Aug 21, 2010 at 7:38 PM, Emil Dotchevski <emil@revergestudios.com> wrote:

On Sat, Aug 21, 2010 at 10:08 AM, Robert Ramey <ramey@rrsd.com> wrote:

...

replace    int id;    if(id == original_id)        ...

with    special_type id(... ah think about this - this is a good thing);    if(id == original_id)

Yes, we have user-defined types in the language to define custom behaviors in case the semantics of the built-in types are inadequate or incomplete. But whether such a change is a good thing can not be argued in the abstract, each case is different. I bet that sometimes the feeling of satisfaction we get when we see no warnings at all at the highest possible level gets in the way of our good judgment.

Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

I bet your right (almost certain of it in many cases, which I have seen), although logic would assume that the inference would propose never switching on the highest possible level of warnings. I know your not proposing that per se' but perhaps with boost being the closest to a c++ standards extension library in many cases, it does arguably require definitive policy on warnings (excuse my ignorance if this exists). I understand the compliers all react differently but perhaps teir 1 compilers could be considered and the policy strictly applied. Yes I realise this has gone way off topic now, so I am sorry. I think doing this also fleshes out some strange / 'unreadable for everyone' code at the same time.

Emil Dotchevski wrote:

On Sat, Aug 21, 2010 at 10:08 AM, Robert Ramey <ramey@rrsd.com> wrote:

...

replace int id; if(id == original_id) ...

with special_type id(... ah think about this - this is a good thing); if(id == original_id)

Yes, we have user-defined types in the language to define custom behaviors in case the semantics of the built-in types are inadequate or incomplete. But whether such a change is a good thing can not be argued in the abstract, each case is different.

This discussion has go about as far as it can without getting to specific cases. And there is a case to support any point of view here.

I bet that sometimes the feeling of satisfaction we get when we see no warnings at all at the highest possible level gets in the way of our good judgment.

I think I accidently hijacked the thread. I originally looked into this with the idea of suppressing the warnings basically because I got tired of people bugging me about them. I'm thinking the "the warnings are just BS since the code is correct" and people are just to lazy to filter them out when the look at the error messages - and btw -they were all in the library build anyway. So I started off with sort of a bad attitude. I started thinking about the best way go get people to stop bugging me without mucking up my code with a lot of "warning hiding" code. As I started looking carefully at this I found that, in my case at least, many/most of the messages were related to implicit conversions between "similar" types so I resolved to eliminate these. It started out as sort of an experiment but as it progressed I realized that by addressing this in the way I outlined about, I was actually making the code better in every way. An the best part was that it didn't require too much of my steadily atrophying brain power to accomplish. When I restricted the type conversion - all the questionable cases showed up as errors. Then it was easy to decide to either change the code provoking the error and/or add another explicit conversion to the type. So the final result a) traps more errors when I introduce them b) eliminates warnings c) makes the code easier to read by replacing "int" with the name of a specific type. d) was easy to implement I'm not disagreeing with you. I think that adding "warning hiding" code is a bad idea. I think that one can leverage on the type system to improve the code and elminate most of the warning as a side effect. Robert Ramey

Emil Dotchevski wrote:

I agree with you 100%. I wish there was a way to *suppress* a warning without altering the semantics of the program. But in GCC, there isn't.

+1

One option is to "fix" them anyway. Unfortunately, a lot of times this involves casting, and in general I find it ill-advised to use a cast to suppress a warning. Think about it: casts are used to tell the compiler to do something it wouldn't normally do because it is dangerous. This is true for all casts, including the ones people sprinkle around to "fix" warnings.

In many cases, the casts are to make explicit what is otherwise implicit and, in so doing, quiet the warning. Addressing such warnings, however, should include considering that the implicit behavior was not actually desirable. In that case, one should employ mitigating strategies other than casts, such as Robert did. Many other alterations are appropriate to quiet warnings and relatively few changes involve altogether different code that is buggy or questionable, IME. If one finds an unacceptable change necessary to quiet a warning, then strong-arm tactics like GCC's system header pragma are certainly worth consideration. That approach is not without problems, however. From the point you introduce that pragma, there will be no warnings from the affected header without establishing a careful maintenance protocol to disable the pragma whenever the code changes, verify each and every warning, and then reenable the pragma, just to determine if the code change triggered a warning that shouldn't be suppressed. That's hardly a good use of maintenance time, so eliminating warnings is the best approach for all reasonable cases. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Robert Ramey wrote:

FYI - after I did this, I was left with a few warnings still. I couldn't quiet them in a way that I found acceptable so I just left them in. The main one was comparison between signed/unsigned ints in a few cases. So I think the goal of warning elimination is not worth persuing. The goal should be warning minimization. From my perspective this is doable and helpful.

I can't argue against your pragmatic viewpoint, but you're missing support for Boost users that like to make errors of warnings. That's a means to force dealing with all warnings. Using pragmas to suppress your remaining warnings would address that constituency. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.