- Boost - lists.boost.org

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

MinGW 3.2.3 regression test
by Rob Lievaart 23 Jul '04

23 Jul '04

Hi All, In a couple of hours I am going on holiday for week, and i have not had the time to fully automate the test setup, so I am afraid that next week, there will be no fresh reports. I am going to try to get my colleagues to run the script a few times, but I don't know if it will work. :-( While on the subject of automating, two of the tests near the end generate a popup dialog about a division by zero error, that requires interaction. I haven't had the time to look into it yet, but is this something with win32, or with mingw, or my local setup? Kind regards, Rob Lievaart.

2 1

boost::thread TLS atexitthread DLL et.al.
by Roland 23 Jul '04

23 Jul '04

After having been off the list for a while now, because of other things to do, I'd like to share some thought about the still not solved question of TLS on Windows. As far as I remember the original author of the thread library (Bill Kempf) intended the thread local storage to be usable in an orthogonal way to boost::threads, i.e. TLS should be cleaned up even when used in the context of native threads. He came up with a solution of using a DLL to catch the very last breath of the thread. (I proposed a "piggy pack" DLL that can be embedded in the main executable, to get rid of the need to separately distribute a DLL file.) Now while rethinking the thing I have serious reservations about the DLL solution: The exit and cleanup is getting called AFTER the C-runtime library has been de-initialized for the thread. Is it save then to call any of the library functions in the yet "zombied" thread? May I even call free or delete on objects that have been created in context of the thread? Extending this question to threads that have been created by other means (including boost::thread) this means the exit handler must not access any features that have been in control of the thread mechanism. For me this means either to drop the (desirable) requirement of orthogonality and require the thread beeing created and managed by boost when using TLS, or force the user to obey strict rules about what she is allowed to do in an exit handler (destructor in turn of an object). To me the latter seems less appealing than the first. Yet another idea would be to require at least the availability of the C-library at destruction time, but require that the destructor must not access any thread specific (i.e. boost thread) data. Someone in this list has pointed out the existence of a TLS destructor list in the PE header of executables. I have digged into this a little. While current compilers do not yet make use of this field it still would not answer all questions. (Perhaps that is the reason why they are not currently supporting it?) However this destructor list would need to be called by whichever library has created global objects. (Normally this is the C/C++ runtime stub.) It definitely cannot be the resonsibility of the operating system to call this list (at least in my opinion). Wrapping it up: Having the C/C++ runtime available at thread exit seems desirable to me. Calling the exithandler from the DLL (THREAD_DETACH) is too late. Calling the exit handler from within _endthread seems desirable (and can be reasonably expected to be supported by compilers one time.) Fortunately there is a chance to trick the _endthread to call arbitrary exit functions by making use of the fp-init/deinit hook. I will try to provide example code, but also post this at the same time to get your thoughts about this. Roland

1 0

performance: pool cleanup takes too long
by AviadR 23 Jul '04

23 Jul '04

hi, In my project I use boost::pool because I have to instantiate millions of object at the beginning of the application, and only get rid of the at termination time. I noticed that when processing large data (which may require 1Gb memory for the application while it is running) the application may finish its processing approx after 10 seconds. the cleanup part (which consists only of calling the pool release methods on allocated objects) on the other hand, takes many minutes (I usually give up after 5 minutes) debugging the code i noticed that the while loop in the nextof function (of SIMPLE SEGREGATED STORAGE.HPP) takes many iterations. this leads me to the belief that the reason the cleanup takes too long is because trying to cleanup 1GB memory of million of objects at once causes pool to retain all its chunks in the hope of more allocations in the future which in turns causes it to waste all computation on running to the end of (endless) lists in the nextof function I will appreciate a suggestion on how to fix this until a more permanent solution is applied to the pool library thanks aviad aviadr(a)pob.huji.ac.il

2 1

Re:Re: [boost] [Boost.Test] bug
by Robert Ramey 23 Jul '04

23 Jul '04

>>>There's boost/compatibility/cpp_c_headers/cwctype and >>>boost/compatibility/cpp_c_headers/cctype. Can we use those >>>instead and be assured of portability? Everyone seems to be >>>reinventing workarounds for these nasty little beasts. > >> I was under impression that we should only use these headers where there >are >> no native headers with appropriate name. Isn't it true? >Not sure. It says in the documentation: ><http://www.boost.org/libs/compatibility/index.html> Joel de Guzman wrote: >I think it is the right place for a common workaround to such problems. >We too had the same problem as you had and had to write some similar >compatibility workarounds. Other libraries also provide some sort of >workaround (e.g. <http://www.boost.org/boost/regex/config/cwchar.hpp>). >I think it would be best to have a single place to put them. I had used these headers for this purpose. Then I came to a point where one of them wasn't appropriate so I wanted it changed. Then I was told it couldn't be done be cause they were automatically generated. I was told they weren't designed to be used for this purpose. So I had to use the current method. I asked a couple of times what good they were for and it was explained to me a couple of times but I never did understand the explanation so I just moved on. Robert Ramey

1 0

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

23 Jul '04

Jonathan Turkanis wrote: >"Edward Diener" <eddielee(a)tropicsoft.com> wrote in message >news:cdq036$1m7$1@sea.gmane.org... >> 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. >Lack of interest??? Soemtimes it seems that the boost developers list >is really the boost serialization list. ;-) Hmmm I was just thinking the same thing re mutex/threading. I guess it's a question of vantage point. Now 18 months ago - that's when the topic was hot. I probably consumed a couple of trees worth of energy just to power the related email. Robert Ramey

1 0

typeof: type registration
by 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

2 1