May 2006 - Boost - lists.preview.boost.org

[thread] 1.33.1 with vc71, links against msvcrt and msvcprt
by Andrew Finkenstadt 15 May '06

15 May '06

The goal: upgrade from boost 1.32 to 1.33.1. The gotcha: Somehow a programmer here managed to build a version of boost::thread version 1.32 whose .LIB file did not contain any directives to link against MSVCRT and MSVCPRT; there doesn't seem to be anything I do with bjam that causes version 1.33.1 to do the same. (He just handed me the .lib files to install into the right place, I knew I should have insisted he learn to do it himself. :) ) "dumpbin /directives /archivemembers libboost_thread-vc71-mt-s-1_33_1.lib" yields several Linker Directives ----------------- /DEFAULTLIB:"msvcprt" /DEFAULTLIB:"MSVCRT" commands. Which totally breaks my application (which requires the use of LIBCMT) by complaining of duplicate symbols defined in both. /NODEFAULTLIB: is not appropriate. The frustration: I can't seem to find where bjam's rules for specifying the CC Options *are*, much less know how to twiddle the Jamfile.v2 file for boost::threads. The steps I've taken: I had a similar problem with the regex library, but the vc71.mak file built perfect libraries. There's no corresponding vc71.mak file that I've found yet, for threads. So, to build threads, I basically go to the top level of boost_1_33_1 and run bjam with the vc71 toolset option. The reward: my eternal gratitude... and my sincerest thanks for help in answering this, no doubt, simple question. I've been reading the list for about a year, but don't remember seeing this specific issue discussed. Last year in http://lists.boost.org/boost-users/2005/05/11725.php was a discussion about whether boost::thread in 1.32 supported static runtime linking , and the answer appears to be yes, but like I said -- i have no idea how Junior Programmer got it done and working. Best regards, andy

4 4

[serialization] The trouble with BCB2006
by Nicola Musatti 15 May '06

15 May '06

Robert, I think I found the problem, but I'm not sure on how to code a workaround. Apparently BCB2006 introduced a bug which causes writes to a BOOST_STRONG_TYPEDEF to fail, just as if a temporary was updated. This is affecting specifically the reading of archive versions. The code below is an example of an effective workaround: version_type input_library_version; #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x582)) && __BORLANDC__ >= 0x580 unsigned int v; * this->This() >> v; input_library_version.t = v; #else * this->This() >> input_library_version; #endif Probably it would be sufficient to just pass input_library_version.t to operator>> . The real problem I have with this workaround is that it would be much better to factor it into BOOST_STRONG_TYPEDEF's definition, but I'm not sure about what is exactly causing the problem and I'm not very confident about my ability to add conditions to a macro definition. Cheers, Nicola Musatti

2 4

[Boost-bugs] [ boost-Bugs-1488660 ] Bug in xml_oarchive_impl<Archive>::save(const std::string&)
by SourceForge.net 15 May '06

15 May '06

Bugs item #1488660, was opened at 2006-05-15 07:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1488660&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: serialization Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexey Bash (alexey-b) Assigned to: Robert Ramey (ramey) Summary: Bug in xml_oarchive_impl<Archive>::save(const std::string&) Initial Comment: Bug in file "boost/archive/impl/xml_oarchive_impl.ipp" line 82 method: template<class Archive> BOOST_ARCHIVE_DECL(void) xml_oarchive_impl<Archive>::save(const std::string & s ). Second argument of call: std::copy( xml_escape_translator(BOOST_MAKE_PFTO_WRAPPER(s.data() )), xml_escape_translator(BOOST_MAKE_PFTO_WRAPPER(s.data()+ s.size())), boost::archive::iterators::ostream_iterator<char>(os)) is wrong: in constructor of xml_escape_translator the method template<class Base> char xml_escape<Base>::fill( const char * & bstart, const char * & bend) is called for after-last symbol!!! If this symbol is, e.g., '>' - we have error: iterators _First and _Last in call of std::copy (see above) are always not equal (members 'm_bnext' and 'm_bend' are always non-zero and comparation of these iterators in this case are return always 'false') and we have access violation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1488660&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Test: please ignore
by Douglas Gregor 15 May '06

15 May '06

Please ignore

1 0

Re: [boost] [wave] ifndef/ifdef callbacks
by Hartmut Kaiser 14 May '06

14 May '06

Hi Felipe, > In fact, it was easy to implement for this particular case. > The 'evaluated_conditional_expression()' preprocessing hook > now has a bool return value, which forces Wave to re-evaluate > the expression as long as it is 'true'. The new prototype will be: > > template <typename ContextT, typename ContainerT> > bool > evaluated_conditional_expression(ContextT const &ctx, > ContainerT const& expression, bool expression_value) > { return false; } // ok to continue, do not > re-evaluate expression > > > Wave guarantees to keep the own state unchanged during this, > which means you can save the context state, change a macro > definition and return true to force the expression to be > re-evaluated. This scheme should ensure a consistent behaviour. > > I'll check these changes into the CVS as soon as it will be > up again. It won't be part of the Boost 1.34.0 release, though. The changes are checked into the Boost CVS::HEAD now. Please let me know if this fits your needs now. Regards Hartmut

1 0

[Boost-bugs] [ boost-Bugs-1488329 ] a coding error in the file: regex_traits_defaults.cpp
by SourceForge.net 14 May '06

14 May '06

Bugs item #1488329, was opened at 2006-05-14 14:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1488329&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: tangxinfa (tangxinfa) Assigned to: John Maddock (johnmaddock) Summary: a coding error in the file: regex_traits_defaults.cpp Initial Comment: this release i download from sourceforge named boost_1_33_1.exe, when i build it i found failed to build regex library, i read the error message, then open the source file boost_1_33_1\libs\regex\src\regex_traits_defaults.cpp, some line like "regex_constants::syntax_char, /*?/" had a bad format comment(it lose a '*'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1488329&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

GOOD DAY
by jsiek＠osl.iu.edu 14 May '06

14 May '06

R��U��D��Huj>X�zb�Y�ܸ��}2��U�/�Ǚ&�s��1K��S�v��G�F�*W2��Y4�c"e?͙�{��]-kLjO�6ZHy��n�#��Vq4�֪̳*�Se2O�T?XZ�)�]�Hǽ��U��`emlP�f�,��k��^.Q�u��#G��^�%K�둸w��g�6`G�5M��~^ɮ�Nyv�^x�0҈�� sΨ�T-3�.�r��i�~:��^�P��2��3"�˸�4�F Qi5 '��E|0*,�SZ�o��(O�~�m�H�- �W�%&}ʫ#_(3�i;Pߦы S��ل��R�g�KCSl�K?�Y��/��Ɛl$}L� L ��"(/�/��4ls�ԡQ�5��j�B�D��r��W�� U��Hj&��i��V��?-Y'c��>�z[g��ڒ"i�yD��د $�C%Fm��`v�xD��*��L/��Mh�6�H-�� JZM��._7M~J:kŗ�,��<� 8j��(�|��2J}P9��

1 0

[1.34] Regressions
by Thomas Witt 13 May '06

13 May '06

Hi, The following libraries show fails across almost all platforms in the 1.34 regression tests concept_check io mpl ptr_container python wave I would be thankful for a short update on the reason and plans for mitigation. AFAICS this has to be dealt with before we even think about a Beta release. Thanks Thomas Release Manager -- Thomas Witt witt(a)acm.org

7 12

[typeof] Limitations in BOOST_TYPEOF_NESTED_TYPEDEF for VC8.0
by Peder Holt 13 May '06

13 May '06

It turns out that BOOST_TYPEOF_NESTED_TYPEDEF has a problem when used inside functions on VC8.0 (possibly other compilers as well) This is because BOOST_TYPEOF_NESTED_TYPEDEF internally defines a member template: struct a { template<typename T> struct b{ }; }; VC8.0 doesn't handle this (error C2892: local class shall not have member templates) It is possible to avoid this problem, but this would cripple BOOST_TYPEOF_NESTED_TYPEDEF because it would reintroduce the BOOST_TYPEOF_LIMIT_SIZE limitation on the expression complexity. The alternative is to disallow NESTED_TYPEDEF inside functions, and write a note on this in the docs. Is this acceptable? Regards, Peder

4 3

Proposal: formal update review
by Fernando Cacciola 12 May '06

12 May '06

Given the recent "incident" about users complaining about updates to boost and the fact that we have a wounderful METHOD that gave us so much respect and popularity, I'd like to propose something that's been in my mind for quite some time. The very high quaility of boost libraries is due to the so-called BOOST METHOD (I just coined the term, but how I like it :): the managed and peer-reviewed acceptance process. But there is a "hole" in this method, once a library is accepted the mantainer can do whatever it pleases with it. Of course we all assume and expect the maintainer to keep its hight quality, but this is a deviation from the basic "peer-reviewing is a requirement" principle. If the assumtion here were grounded we could just as well accept libraries directly because we trust the good jugdment of the author; but we don't, and there lies our "credibility". I really think is time to come up with a "direct-update" vs "managed-update" policy. The policy would define which updates can be directly executed by the library mantainer and which need a "formal update rewiew". Naturally, the formal update review should follow the same rules as the formal acceptance review. At the very least, interface-breaking changes should require a formal update review IMO. What do you all think? -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/

6 10