- Boost - lists.boost.org

Autoconfiguration problem with wcs* functions?
by Julio M. Merino Vidal 27 Feb '05

27 Feb '05

Hi all, I'm using the autoconfiguration framework under NetBSD 2.99.14 to generate an user.hpp file. The libs/config/test/boost_no_cwchar.ipp test passes successfully, so Boost ends up thinking that wcs* functions work. In fact, they do, but in C (defined in wchar.h). The problem is that those functions (I'm referring to wcscmp and wcslen, but maybe there are some others) are not (yet) defined in the std:: namespace. (The wchar stuff is being worked on at the moment, AFAICT; at least, it's very recent.) So, what happens? As the BOOST_NO_CWCHAR constant is not defined, the build will try to use cwchar functions. And it will fail at multiple places. The "problem" is that the code is using std::wcscmp and std::wcslen because it thinks it can. I don't know which is the correct fix. Just temporally, I've changed the test to use the functions in the std:: namespace rather than the other ones, so that I get a failure and cwchar is disabled. But this seems suboptimal (basically because the functions do exist). Any comments on how this should be handled? Thanks, -- Julio M. Merino Vidal <jmmv84(a)gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/

2 1

Type of Review for Unordered Associative Containers & Hash Functions
by Daniel James 27 Feb '05

27 Feb '05

Hello everyone, I've just uploaded a new version of the unordered associative containers, this time in the 'Hash' folder on the file vault. There's also the file 'hash.tar.gz', which is just the hash function object. The hash function objects are ready for review, the container library is almost ready, it mainly just needs more documentation. The implementation has been split into two libraries. Boost.Hash implements the hash function objects which would go into <functional>, so it is proposed that these are added to the functional library. This is needed for Joaquín's MultiIndex library, so it would be good to add it to Boost as soon as possible. The other part is Boost.Unordered, which implements the unordered associative containers. This is a little larger and more complicated, and there's no immediate need for it (unless you count Boost.Tr1). We're not sure what kind of review these libraries will need. Since they're both based on the draft standard, their design isn't really up for review here (right?), but the documentation and implementation is. Do you think they require a full review, or will a fast track review be appropriate? A fast track review is tentatively scheduled for the hash function objects after the review of the finite state machine, with Thorsten managing it. The full container library could be included in this, if that is considered acceptable. Or it could be added to the queue for a full review? Any opinions? Daniel

7 10

runtime rvalue detection for Visual C++ 6.0
by Peder Holt 26 Feb '05

26 Feb '05

I was looking through the FOR_EACH - implementation, and noticed that it lacks rvalue detection for Visual C++ 6.0. After some investigation, I have found one very sleazy way of detecting rvalue-ness runtime without evaluating the argument more than once: # define BOOST_FOREACH_TYPEOF(COL) \ *(true ? 0 : &::boost::for_each::wrap(COL)) template<typename T> inline static_any<simple_variant<T const> > contain(int const& position_test,T const &t, bool const &, mpl::false_) { int rvalue_test=int(&t)-int(&position_test); bool rvalue=(rvalue_test<=8); return rvalue ? simple_variant<T const>(t) : simple_variant<T const>(&t); } Since this relies on the position of objects on the stack, there are probably cases where it will fail. Pointers (e.g. string constants) must be handled separately. Regards Peder

3 2

typeid/type_info proposal (long, go get another jolt cola)
by Jody Hagins 26 Feb '05

26 Feb '05

Warning: This is a fairly lengthy post, as I have had a difficult time putting my thoughts into words (also, I have had very little free time lately -- though it is hard to say that with a straight face since I just spent the holiday weekend skiiing). If you want to skip my monotonous musings, read the summary only, and possibly skip down a few paragraphs until you see a significant amout of vertical white space, then read some more technical points. I would really appreciate any thoughts or insights, as I am quite frankly not very satisfied with my own. SUMMARY: I would like to delay proposing a typeid() replacement. Instead, I'd like to submit my testsuite, and ask people to run it on various platforms and report the results. This will help us decide how best to approach this seemingly simple, but very difficult, subject. I would like to propose a boost::type_info class now (or very soon). Meaningful instances of boost::type_info will be constructed from a std::type_info resulting from a native typeid() call. Once we figure out what route to take wrt typeid(), then I think it can be used in a very straight forward manner. Now for some rumblings, where I try to sort out my experiences with typeid (I apologize in advance for the lack of polish, but I want to get this out for comment because I am going out of town Friday afternoon, and will not be back until Sunday night). A while back, I had some of my own code to use typeid/type_info. The code was inspired by the TypeInfo class in "Modern C++ Design" by Andrei Alexandrescu. However, I ran into some issues (namely the infamous g++ shared library problem). A search of boost found an implementation in Boost.Python. As has been mentioned in the past, this seems like a useful utility to have around, so I made an attempt to bring it out of Boost.Python, and give it life of its own. David suggested that such a small exposure is a good candidate for a fast track review, so I naively thought that meant it would be a small amount of work. Along the way, I ran into several portability issues, and decided to make sure the code had the best typeid/type_info support I could imagine. Unfortunately, this took me down a very twisted highway. I could not find an existing test suite, so I wrote my own, based on the standard (5.2.8 and 18.5.1). Well, this turned into a nightmare, because I have had a hard time finding any compiler that will pass all my tests. I have had to move to gcc 3.4 to get most of them to pass, and still some fail (though it may be due to my tests... I am still looking into that). I will say that I now know more about typeid() than I ever thought I'd want to know (I could quite possibly quote verbatum section 5.2.8, and a fair bit of 18.5.1 to boot). Anyway, getting a portable typeid/type_info library working is not exactly as easy as it appears. A previous post of mine attributes most typeid problems to older msvc/intel compilers. This is only mostly true. They are the worst, because they do not even try to remove the top-level cv-qualifiers. However, even relatively recent versions of gcc has had problems with this in esoteric cases (multidimensional array with cv qualifiers mixed with typedefs). All this to say that I have my doubts that many compilers fully support typeid() correctly. To top it all off, many implementations have trouble honoring the comparison mechanism across separate shared libraries (as noted in the Boost.Python implementation), so there are some workarounds needed for type_info as well. Since I have seen so many problems, I am no longer certain that the review of typeid can be done quickly. While the implementation in Boost.Python works well, it also has several holes, so I do not think it wise to simply "bring it out" into boost. Thus, I have made an attempt to "industrialize" it. With this in mind, I thought I'd give a rundown of the major issues. I recently posted some of my concerns, but due to the length of that post, and possibly its ramblings, I have not seen any replies. Yes, I know, this one is longer, and possibly more "rambling" but I am hopeful yet ;-) I will leave the more minor issues for later, but would really like some input on the bigger ones. The library, as used in Boost.Python, relies on calling the no-parameter template function, type_id, to get the type info object. Use of typeid() by itself is absent, because of the problem with compilers getting the typeid() implementation correct. For example: struct foo { /* ... */ }; boost::python::type_info ti = boost::python::type_id< foo >(); Unfortunately, boost::python::type_id<>() has a couple major drawbacks (and a number of "minor" ones). 1. It only supports type-id calls, with a specific type passed as a template parameter. The ability to compute type_info based on the result of an expression is scant (a bit more functionality can possibly be obtained with more tricks like the ingenious typeof() stuff recently posted). 2. To add support for expressions and lvalues, overloads of type_id() can be provided. This works reasonably well (with enough machinery to get around compiler problems), but the spec for typeid() says that the expression is not supposed to be evaluated (unless the expression is an lvalue of a polymorphic type, or dereferences a pointer to a polymorphic type). I have yet to see a way to call a function and prevent the expression from being evaluated (maybe with some modern tricks and is_polymorphic -- but we are then probably leaving several compilers behind as well). Also, I have been unable to get the "workaround" to throw std::bad_typeid when dereferencing a null pointer, as specified in 5.2.8.2). 3. For compilers with bad cv-qualifier support wrt typeid(), it requires a fair amount of machinery to get rid of the cv-qualifiers. Unfortunately, the same machinery makes it difficult to preserve the polymorphic requirements of 5.2.8.2, and I have yet to find the right code to get this to work (though I think it may be possible). Thus, we face a dilemma. Either always use the native typeid(), knowing that your compiler may not fully support it "by the book" or provide some workaround, that will not provide everything either. By fixing some things, others are broken. We are left with some options: 1. Always use the native typeid() in code, and live with what the compiler does. 2. Always use a "workaround" and live with whatever level of "brokeness" that provides. I am not convinced that we can get a consistent level of brokeness for all compilers, though it is more likely to be close for all compilers than just using typeid(). 3. Provide a macro BOOST_TYPEID(), which is set depending on which compiler is being used, to get the "best" effect. Depending on the day, I feel differently about which option I like. Thus, I have written a fairly extensive set of tests for native typeid(). I feel fairly certain that they can tell us what to expect from any compiler relative to typeid conformance. We could use those tests results, from "all" the supported platforms to see where we are (my access to compilers/platforms is quite limited). Maybe if we had a better idea about what each of the "major" platoforms do/not support we could get a better idea as to how we want to proceed. In any case, I do not think this will be super quick. So, let's move to type_info. I think this one is a bit more clear (though we still need some compiler workarounds). However, the only real workarounds I have found so far involve "broken" comparison operators. I think these are fairly well known, and mostly solved. I also have a fairly extensive set of tests for native std::type_info, as well as the new boost::type_info. However, I am still hung up on the whole typeid thing stated above. I tend to think that most use of typeid() will work as expected. The "major" problems concern quite old compilers (I think), and some of the problems in more modern compilers are in the "corners" of usage. Thus, it makes sense to get boost::type_info in place, and wait until we have some test results to see what is the propor course of action for typeid. Thanks, and if you read this far, maybe YOU should go skiing ;-)

5 8

Gauging interest: minimalistic test library
by Pavel Vozenilek 26 Feb '05

26 Feb '05

In sandbox http://boost-sandbox.sourceforge.net/vault/ is small (1 header minitest.hpp) Boostified library to help with testing. I use it instead of other frameworks as it doesn't require any work. Example of use: _________________________________ #include <boost/minitest.hpp> BOOST_MINITEST { assert(....); } BOOST_MINITEST { assert(....); .... } ... boost::minitest::execute_all_tests(); _________________________________ Features: - no helper classes, functions or naming conventions needed - allows to execute tests randomly (I found this very helpful) - it is possible to execute tests only from last N modified source files. This allows to re-run tests after every minor source modification (i.e. Test Driven Development) - no *.cpp files - works on systems w/o exceptions enabled, doesn't need RTTI - works with DLLs (it is needed to "register" every DLL). DLLs can be dynamically loaded/unloaded. - tested with VC6, Intel 7, BCB 6. Should work on UNIXes (I don't try yet). - allows to re-run failed test immediatelly if user wishes _________________________________ Disadvantages: - tests must be written on top level (i.e. not within functions) - no mechanism to select what "exact" tests to run is available (by design - I found it rather useless for me) - testing a DLLs requires few lines of support code per DLL - the "test only few last changed files" feature is rather brittle - it doesn't deal with headers and dependencies (it is just quick an dirty tool) Would this tiny tool be useful as part of Boost? - as complement to Boost.Test. If there's interest I can write docs and add tests. /Pavel

2 1

portable lock free algorithms
by Maxim Yegorushkin 25 Feb '05

25 Feb '05

Hi there, I've just read the paper "High Performance Dynamic Lock-Free Hash Tables and List-Based Sets" by Maged M. Michael at http://www.cs.tau.ac.il/~shanir/reading%20group/p73-michael.pdf and wonder if the subject has become feasible. The paper basically states that the algorithms can be implemented on most current processor architectures using CAS or LL/CS instructions, rather than rare DCAS/CAS2 instructions. Is that true? Is there something going on in boost with regards to the subject? -- Maxim Yegorushkin

2 1

Wave accepted
by Tom Brinkman 25 Feb '05

25 Feb '05

The boost::wave library is accepted into boost. A couple of review comments are summarized below from Paul Mensonides and Joel de Guzman. Paul Mensonides stated: "I think that the design and implementation are good. The library has reasonable performance in preprocessing complex examples and is more conformant to the standards than most other vendors' preprocessors. Nearly every tool that analyzes C++ source effectively needs to have the ability to preprocess that source. Having a plugable preprocessor is a boon for tool developers--including possible future Boost tools. That said, the potential usefulness of the library (as a library) is fairly restricted to tool development. OTOH, the driver can be used as a replacement for faulty preprocessors without a great deal of effort. Furthermore, the tracing ability of the library (and, by extension, the driver) makes it hands-down the best tool for debugging complex preprocessor metaprograms. This is especially true because tracing can be turned on and off mid-expansion with pragmas (in particular, with the _Pragma operator borrowed from C99). My use of the wave-driver has spanned a couple years now, and during that time Hartmut has fixed nearly all problems that I've encountered. Beyond the utility and capabilities of the library, the existence of the library makes a worthwhile political statement to compiler vendors. I endorse the concept of a Boost preprocessor, and I endorse this particular realization of that concept. Furthermore, I endorse the author (Hartmut). He has been a very responsible and responsive implementor/maintainer--for Spirit as well as the Wave project." Joel de Guzman stated: "I think this (wave) is the most flexible pre-processor I know. It's a c++ library, so I expected full extensibility. Hartmut was very thorough in his design with more than enough links and hooks through policies and callbacks to do almost anything imaginable. The structure is highly modular. The implementation is very good. Hartmut has been a very avid Spirit developer and I've known him to be an excelent coder. I took a peek at the code, sure enough, he's a Spirit expert who can churn out really cool Spirit parsers." Review Managers Conclusion: As the wave library has been in active development for three years, has the endorsement of key boost members, and has demonstrated great utility, I think that boost::wave should be added to boost without delay. Congratulations and thanks to Hartmut Kaiser for his submission. Tom Brinkman Review Manager - boost::wave __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

6 6

proposed extension for boost::any
by Frantz Maerten 25 Feb '05

25 Feb '05

Hi all, While using boost::any with pointers, I realized the following problem for polymorphic classes: \code class A { public: virtual ~A() {} } ; class B: public A {} ; int main() { boost::any b(new B) ; try { A* a = boost::any_cast<A*>(b) ; } catch (const boost::bad_any_cast&) {/*failed*/} } \endcode Of course the following code failes, since rtti information is used for casting. I extended the boost::any concept, and incorporated a boost::any_dynamic_cast (see attachment) This extension uses boost::is_polymorphic and boost::remove_pointer, and allows dynamic casting if possible. Does anyone need this features, and can it be incorporated (after some regression tests) into the boost::any library? Thanks for any comment about it. --Frantz Maerten

2 1

[test] regressions with Borland and VC7
by Jonathan Turkanis 25 Feb '05

25 Feb '05

Hi, Starting yesterday, unit_test_suite.cpp fails to compile with Borland and VC71. Here are the errors I get (I just ran cvs update): ********** Borland 5.6.4 ********** borland-C++-action ..\..\..\bin\boost\libs\test\build\libboost_unit_test_framework.lib\borland\debu g\unit_test_suite.obj c:\documents and settings\turkanis\home\libraries\boost\libs\test\build\../src/unit_test_suite.cp p: Error E2268 C:\CBuilderX\include\stl/_algo.c 432: Call to undefined function 'rand' in function _STL::int __random_number<int>(int) *** 1 errors in Compile *** "bcc32" -j5 -g255 -q -c -P -w -Ve -Vx -a8 -b- -DBOOST_TEST_NO_AUTO_LINK=1 -v -Od -vi- -tWC -tWR -tWC -WM- -w-8080 -w-8001 -I"..\..\..\bin\boost\libs\test\b uild" -I"C:\Documents and ettings\turkanis\Home\Libraries\boost" -o"..\..\..\bin\boost\libs\test\build\li bboost_unit_test_framework.lib\borland\debug\unit_test_suite.obj" "C:\Documents and Settings\turkanis\Home\Libraries\boost\libs\test\build\../src/unit_test_suite.cp p" ...failed borland-C++-action ..\..\..\bin\boost\libs\test\build\libboost_unit_test_framework.lib\borland\debu g\unit_test_suite.obj... ********** VC 7.0 ********** vc-C++ ..\..\..\bin\boost\libs\test\build\libboost_unit_test_framework.lib\vc7\debug\th reading-multi\unit_test_suite.obj unit_test_suite.cpp C:\Documents and Settings\turkanis\Home\Libraries\boost\boost\test\impl\unit_test_suite.ipp(83) : error C2558: class 'boost::unit_test::callback0<R>' : no copy constructor available or copy constructor is declared 'explicit' with [ R=boost::unit_test::ut_detail::unused ] CALL "C:\PROGRA~1\MICROS~1.NET\VC7\bin\VCVARS32.BAT" >nul "C:\PROGRA~1\MICROS~1.NET\VC7\bin\cl" /Zm800 -nologo EHsc -c -DBOOST_TEST_NO_AUTO_LINK=1 /Z7 /Od /Ob0 /EHsc /GR /MDd /Op /Zc:forScope c:wchar_t -I"..\..\..\bin\boost\libs\test\build" -I"C:\Documents and Settings\turkanis\Home\Libraries\boost" -Fo"..\..\..\bin\boost\libs\test\build \libboost_unit_test_framework.lib\vc7\debug\threading-multi\unit_test_suite.obj" -Tp"C:\Documents and Settings\turkanis\Home\Libraries\boost\libs\test\build\../src/unit_test_suite.cp p" ..failed vc-C++ ..\..\..\bin\boost\libs\test\build\libboost_unit_test_framework.lib\c7\debug\thr eading-multi\unit_test_suite.obj... ************************** Jonathan

2 10

STL containers with contracts, any interest?
by christopher diggins 25 Feb '05

25 Feb '05

I am writing a set of contract verification classes for the various STL containers. These are wrapper classes which verify DbC style contracts (i.e. preconditions, postconditions and invariants). I have already written one for std::vector you can see it at: http://www.ootl.org/pwc/ Is anyone interested in seeing this submitted Boost, if I extend it to cover the basic collections? e.g. list, map, set, multimap, multiset, deque, queue, stack? Thanks, Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

5 9