- Boost - lists.boost.org

RE: [boost] Re: BOOST_FOREACH and break
by Rozental, Gennadiy 23 Jul '04

23 Jul '04

> There is a hidden variable in BOOST_FOREACH that tracks this > information, but it is scoped, so you can't get at it. (And > rightly so; > the scoping of hidden control variables is what makes BOOST_FOREACH > well-behaved.) BTW, while we are on topic. Your implementation uses code like this struct any_t {...}; template<typename T> struct static_any_t : any_t {...} template<typename T> static_any_t<T> foo(...); If( any_t const& ref = foo() ) { // here you are using ref } Is it indeed allowed in standard and ref is valid reference to temp? Gennadiy.

2 1

Re:Re: [boost] Re: Re:Re: Re:Re: additional boost libraries?
by Robert Ramey 23 Jul '04

23 Jul '04

Rene Rivera wrote: Robert Ramey wrote: > >> a) If the compiler is an older compiler >> b) && SPIRIT_ROOT is defined to something not null >> c) || the compiler is a newer compiler. >> >> I think the build jamfile could altered to do this. I spent a little >> time at it but didn't immediately see how to do it. But I think it >> should be possible. Its probably trivial for a BJAM guru - so feel >> free anyone. Also it would be nice if it echoed a comment indicating >> that its skipping the XML components for lack of SPIRIT_ROOT. >Although it's now possible to do this, I would *not* recommend this as a >solution. The basic problem with changing the Jamfile to skip the building >is that it will only work if people use the Jamfile. That's fine for >testing, but not for release. Many people out there don't use BB for >building Boost. Well, if boost build isn't being used then there is no issue. Such users would just exclude libs/serialization/src/*xml*.cpp files from the library build. This is what I would like to see the boost build system do. Seems by far the simplest to me. Robert Ramey

2 1

[multi_index] regression with GCC 4.1
by Joaquín Mª López Muñoz 23 Jul '04

23 Jul '04

The test at http://boost.sourceforge.net/regression-logs/cs-Linux-links.html#multi_inde… shows this message: Date: 2004-07-23 09:44 ../libs/multi_index/test/test_mpl_ops_main.cpp:20: internal compiler error: in size_of_die, at dwarf2out.c:6220 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. Strangely enough, this test used to work for GCC 3.4.1, and I'm not aware of any significant change in the code of the library or any of its dependencies. Ideas, please? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

BOOST_FOREACH and break
by Rozental, Gennadiy 23 Jul '04

23 Jul '04

Hi, I am trying to use construct similar to BOOST_FOREACH macro. In many cases I need to be able to detect whether loop was aborted with break or not. BOOST_FOREACH( ... ) { } // here if( aborted ) { .... } else { } Is there way to do so? Gennadiy.

2 1

Regression reports at regression-logs/developer in-accessible.
by Rene Rivera 23 Jul '04

23 Jul '04

I get permission denied errors when trying to look at the regression outputs in .../developer/output. Seems someone forgot to make that directory+files world readable. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

4 4

Re:[boost] Re: Re:Re: Re:Re: additional boost libraries?
by Robert Ramey 23 Jul '04

23 Jul '04

Edward Diener wrote: >> If you don't >> want to take the 15 minutes to do this, you can build with an older >> compiler and without spirit at all, you could easily modify the >> jamfile. Spirit is only used in the building of the library. >How can the jamfile be modified so that those who have an older compiler, >and don't need Spirit 1.6 for XML serialization, can build the >serialization library without Spirit 1.6 ? That was my point essentially. In order to compile with older compilers the variable SPIRIT_ROOT has to be defined and point to the root where spirit is installed. So the build jamfile would have to be modified so that that the modules for XML are build if and only if: a) If the compiler is an older compiler b) && SPIRIT_ROOT is defined to something not null c) || the compiler is a newer compiler. I think the build jamfile could altered to do this. I spent a little time at it but didn't immediately see how to do it. But I think it should be possible. Its probably trivial for a BJAM guru - so feel free anyone. Also it would be nice if it echoed a comment indicating that its skipping the XML components for lack of SPIRIT_ROOT. >BTW, your library is great and you should never feel that because you don't >hear from others about it that this indicates a lack of interest in users. >What it often indicates is that the library is working so flawlessly for >99.99% of its needs that users are content and do not need to send you any >reports about problems or errors. >From my vantage point it has become so large and intricate after accommodating all the "requirements" including features and portability that it's really hard for me to believe that it actually works all that well. Oh well. Robert Ramey

2 1

typeof: type registration
by Arkadiy Vertleyb 23 Jul '04

23 Jul '04

Hello everybody, Recently there was a discussion about a typeof emulation library. The library determines the type of an expression by passing it to a function template, encoding the type as a list of integers, "returning" them one-by-one via sizeof(), and decoding the type. One of the main problems of any such emulation is the need to associate types and templates with unique compile-time integral identifiers. This becomes even bigger problem, when expressions can contain types/templates from different libraries. It's not quite clear how to ensure uniqueness of identifiers in this case (GUID would be an option, but it's far too big to fit into an integer). An attempt was made to generate the identifiers automatically. However, since mechanisms to achieve this always work inside only one compilation unit, there is no way to preserve the same identifiers for the same entities throughout different compilation units. Hence, inevitably, we run into the ODR violation. An attempt to work this around by defining stuff in anonimous namespace, forces everything that uses this facility to also be defined in the anonimous namespace or, again, the ODR is violated. Although compilers don't seem to care much about ODR in this particular case (meta-functions only, no runtime constructs), somehow I feel uneasy to proceed with the solution that does not quite comply to the standard. And so, once again, I tried to come-up with a registration scheme that, on the one hand, would not violate the ODR, and on the other hand, would not put a significant burden on the end user -- the crutial condition for this library to be of any use at all. Here is this scheme: The typeof library registers primitive types, as well as some other standard stuff, like functions, pointers, references, arrays, consts, etc. If the user only wants any combination of those, no additional actions is required, such as the following type: int& (*)(char[20], double&) would be handled. If, in addition to this, the user wants to handle types from other libraries, such as Spirit, Lambda, etc., it works as following: - The typeof library #defines a preprocessor constant, currently called BOOST_TYPEOF_USER_GROUP, which is the next identifier after the last one it actually used. - The Spirit library registers its types against some symbolic identifiers. Only one per file is required (inside the same file __LINE__ does the job). Something looking similarly to the include guard seems like a decent choice. In addition, Spirit defines a separate header where it enumerates all these symbolic identifiers. This header looks something like this: <boost/spirit/groups.hpp> #ifndef SPIRIT_GROUPS_HPP_INCLUDED #define SPIRIT_GROUPS_HPP_INCLUDED #include <boost/spirit/typeof/typeof.hpp> enum { SPIRIT_REGISTER_HPP = BOOST_TYPEOF_USER_GROUP, SPIRIT_LAST }; #undef BOOST_TYPEOF_USER_GROUP #define BOOST_TYPEOF_USER_GROUP SPIRIT_LAST #endif//SPIRIT_GROUPS_HPP_INCLUDED IOW, the Spirit identifiers start where the typeof library identifiers ended, and BOOST_TYPEOF_USER_GROUP is, again, the next available. - The Lambda library does the same, etc. - The user combines all the groups in a single include, effectively chaining the enums: #ifndef GROUPS_HPP_INCLUDED #define GROUPS_HPP_INCLUDED #include <boost/spirit/groups.hpp> #include <boost/lambda/groups.hpp> #endif//GROUPS_HPP_INCLUDED - The user includes this file before any registration file provided by these libraries. Since the file contains only enums, the compile-time penalty is minimal. This insures that identifiers remain fixed across compilation units. - Whenever the user needs to register her own classes, she provides identifiers by any means she prefers, such as enum, etc., starting from BOOST_TYPEOF_USER_GROUP. See http://groups.yahoo.com/group/boost/files/typeof.zip (or Spirit repository, TYPEOF_DEV branch) for how it all works together. I appologize for such a long post (if you are still here :) ) Any comments? Regards, Arkadiy

5 15

[thread] scoped_unlock
by Russell Hind 23 Jul '04

23 Jul '04

I think it was discussed ages ago on these lists (but can't find the messages now, probably when Bill was still around) about adding scoped_unlock classes to complement scoped_lock classes? Are there still plans to add these? My current use is nothing more than unlock in the constructor, and lock again in the destructor. Thanks Russell

1 0

I build regex with stlport , but have some problem
by 猛许 23 Jul '04

23 Jul '04

I build the regex libs with vc7.1-stlport. Then I test it: #include <boost/regex.hpp> int _tmain(int argc, _TCHAR* argv[]) { boost::regex ex; return 0; } but link error: test1.obj : error LNK2019: unresolved external symbol "public: __thiscall boost::reg_expression<char,class boost::regex_traits<char>,class _STL::allocator<char> >::reg_expression<char,class boost::regex_traits<char>,class _STL::allocator<char> >(class _STL::allocator<char> const &)" (??0?$reg_expression@DV?$regex_traits@D@boost@@V?$allocator@D@_STL@@@boost@@ QAE@ABV?$allocator@D@_STL@@@Z) referenced in function "public: __thiscall boost::basic_regex<char,class boost::regex_traits<char>,class _STL::allocator<char> >::basic_regex<char,class boost::regex_traits<char>,class _STL::allocator<char> >(class _STL::allocator<char> const &)" (??0?$basic_regex@DV?$regex_traits@D@boost@@V?$allocator@D@_STL@@@boost@@QAE @ABV?$allocator@D@_STL@@@Z) test1.obj : error LNK2019: unresolved external symbol "public: __thiscall boost::reg_expression<char,class boost::regex_traits<char>,class _STL::allocator<char> >::~reg_expression<char,class boost::regex_traits<char>,class _STL::allocator<char> >(void)" (??1?$reg_expression@DV?$regex_traits@D@boost@@V?$allocator@D@_STL@@@boost@@ QAE@XZ) referenced in function "public: __thiscall boost::basic_regex<char,class boost::regex_traits<char>,class _STL::allocator<char> >::~basic_regex<char,class boost::regex_traits<char>,class _STL::allocator<char> >(void)" (??1?$basic_regex@DV?$regex_traits@D@boost@@V?$allocator@D@_STL@@@boost@@QAE @XZ) how to solve it? thanks. _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

2 1

A nitpick about newly generated Linux tests
by Joaquín Mª López Muñoz 23 Jul '04

23 Jul '04

Linux tests, as generated Friday 23 July 2004 09:28:26 UTC http://boost.sourceforge.net/regression-logs/cs-Linux.html show a huge amount of warnings everywhere for GCC tests (for every successful pass, actually.) I guess the problem is that the compiler emits the date of compilation and this is is interpreted by the test engine as a warning. Probably this new behavior is due to some GCC configuration parameter? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1