- Boost - lists.boost.org

Re: [boost] boost::multi_index::key_extractors status
by JOAQUIN LOPEZ MU?Z 27 Feb '05

27 Feb '05

----- Mensaje original ----- De: Loïc Joly <loic.actarus.joly(a)wanadoo.fr> Fecha: Domingo, Febrero 27, 2005 7:04 pm Asunto: [boost] boost::multi_index::key_extractors status > Hello everybody, > > I'm discovering boost::multi_index, and something strikes me: I've > been > dreaming of something like boost::multi_index key extractors (and > especially member) for most of my std::set or std::sort uses. > > I therefore think that this part of boost::multi_index does not > belong > in this library, but is more general purpose, and deserves a > library of > its own, along with a way to get a suitable less predicate from > the > result of those. All the arguments that make such a framework > usefull > for boost::multi_index can equally be applied to STL containers > and > algorithms. > > I wonder if such a proposal has already been made (maybe it even > already > exists, boost has so many parts that I may be unaware of this), > and in > the positive case what were the arguments in favor or in > opposition of it. > This issue was considered during the review, and those who gave an opinion about it thought it was better to leave like it is now. Anyway, there's nothing preventing you from using the key extraction sublib for your own purposes, as it is headerwise separate from the rest. You'll only need some compose classes to plug key extractors into comparison predicates, something like this: template<typename KeyFromValue> struct key_less { typedef result_type bool; template <typename Arg> bool operator()(const Arg& x,const Arg& y) { return key(x)<key(y); } private: KeyFromValue key; }; ... typedef std::set< employee, key_less<member<employee,std::string,&employee::name> > > employee_set; HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

boost::multi_index::key_extractors status
by Loïc Joly 27 Feb '05

27 Feb '05

Hello everybody, I'm discovering boost::multi_index, and something strikes me: I've been dreaming of something like boost::multi_index key extractors (and especially member) for most of my std::set or std::sort uses. I therefore think that this part of boost::multi_index does not belong in this library, but is more general purpose, and deserves a library of its own, along with a way to get a suitable less predicate from the result of those. All the arguments that make such a framework usefull for boost::multi_index can equally be applied to STL containers and algorithms. I wonder if such a proposal has already been made (maybe it even already exists, boost has so many parts that I may be unaware of this), and in the positive case what were the arguments in favor or in opposition of it. Best regards, -- Loïc

1 0

Reading the contents of a directory
by Dark Haruka 27 Feb '05

27 Feb '05

Hello :) I'm searching a library for C/C++ which can access directorys. I have read that the boost library can it. So I have downloaded and installed it. But I'm searching a function with which I can look up which files are in a directory. I'd like to say a directory to scan to the function. The function should return the names of the files in that directory and if possible the name of subdirs. Does anyone know this function? Thank you in advance :)

2 1

Object-oriented preprocessor programming :-)
by Arkadiy Vertleyb 27 Feb '05

27 Feb '05

Hi all, If one needs to manage a lot of PP code, some code structuring technique might be helpful. So, how about the OO? The example below demonstrates this techinique with the canonical shapes example. An object is represented as a PP sequence of properties. The head of the sequence contains the "class name" and is used for dispatching. I believe this proved very useful in the BOOST_TYPEOF project where we polymorphicaly treat type, integral, and template template parameters. Comments? Regards, Arkadiy -- #include <boost/preprocessor/seq/transform.hpp> #include <boost/preprocessor/seq/enum.hpp> #include <boost/preprocessor/seq/cat.hpp> #include <boost/lambda/lambda.hpp> #include <algorithm> #include <iostream> // #define VIRTUAL(Fname, This) BOOST_PP_SEQ_CAT(\ (BOOST_PP_SEQ_HEAD(This))(_)(Fname)) // #define CIRCLE(r) (CIRCLE)(r) #define CIRCLE_RADIUS(This)\ BOOST_PP_SEQ_ELEM(1, This) #define CIRCLE_AREA(This)\ 2 * 3.14159 * CIRCLE_RADIUS(This) // #define RECTANGLE(h, w) (RECTANGLE)(h)(w) #define RECTANGLE_HIGHT(This)\ BOOST_PP_SEQ_ELEM(1, This) #define RECTANGLE_WIDTH(This)\ BOOST_PP_SEQ_ELEM(2, This) #define RECTANGLE_AREA(This)\ RECTANGLE_HIGHT(This) * RECTANGLE_WIDTH(This) // #define SQUARE(x) (SQUARE)(x) #define SQUARE_SIDE(This)\ BOOST_PP_SEQ_ELEM(1, This) #define SQUARE_AREA(This)\ SQUARE_SIDE(This) * SQUARE_SIDE(This) // #define MY_SHAPES\ (CIRCLE(5))\ (RECTANGLE(3, 4))\ (CIRCLE(3))\ (SQUARE(3))\ (SQUARE(5))\ (RECTANGLE(2, 6)) #define ENUM_AREAS(shapes)\ BOOST_PP_SEQ_ENUM(BOOST_PP_SEQ_TRANSFORM(OP, ~, shapes)) #define OP(s, data, elem)\ VIRTUAL(AREA, elem)(elem) double MyAreas[] = { ENUM_AREAS(MY_SHAPES) }; // int main() { using namespace std; using namespace boost::lambda; for_each( MyAreas, MyAreas + sizeof(MyAreas)/sizeof(MyAreas[0]), cout << _1 << "\n"); return 0; }

1 0

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