September 2005 - Boost - lists.boost.org

Re: [boost] [Review] xpressive
by Scott Woods 19 Sep '05

19 Sep '05

* What is your evaluation of the design? Good. It has taken some powerful, established technologies (e.g. regular expressions and parser generators) and delivered a C++ facillity that uses some of the latest C++ techniques. Hosting these technologies within C++ syntax has resulted in some slightly jarring constructs (e.g. prefix "one-or-more", tag assignment) but the set of design decisions made seem very reasonable. There were some corners that got me curious; the following queries are therefore more about curiosity than suggestions for change. 1. What is the benefit of providing the complete match in the first entry of the results? e.g. "what[0]". While this is consistent with a long tradition in RE, after some time with STL it's presence at position zero wasnt as comfortable as I expected. 2. Why the slash syntax in dynamic regex? The resulting requirement for a double is fairly ugly. It may be consistent with something (Perl/ECMA/..?) but on balance is it worth it? 3. Why ">>" and not "," (comma). Did the "set" facillity take priority or does the low precedence of comma just result in a different ugliness (sorry, not really the word I want to use :-). 4. C++ operators and RE operators are not really comfortable bed-fellows. While the operator overloading technique has given something useful and concise was there no flirtation with "key words" (i.e. in the manner of "as_xpr"). "+" could have been "one_or_more( xpr )". Maybe the keyword version is viable as an alternate targeted at beginners? Unjustifiably complex? 5. There didnt appear to be much specific thought given to file processing. Is this another "not yet implemented"? In particular elegant integration with any async I/O facillity arising from sockets and file I/O initiatives. 6. Very interested in the future of "semantic actions". Actions and file processing probably go together? * What is your evaluation of the implementation? Cannot say. Not used. * What is your evaluation of the documentation? Good. I liked the balance of technical terminology combined with some informality. Appeared to be some minor problems such as initially not knowing what "_w" and "_d" meant. Was this my failing or was there a missing definition. Was the later use of "+alpha" and others inconsistent? * What is your evaluation of the potential usefulness of the library? Huge. Some of that answer refers to the usefulness of RE but xpressive is obviously more. There has been some discussion about overlap with regex. It would be nice to clarify that. The uptake of RE within the development community (at least, the one where I live) is almost embarrassingly low. I have seen many circumstances that cried out for the power and rigor of RE that instead got limited, buggy hand-written solutions. The ease-of-use (installation, build and coding) of xpressive might help? * Did you try to use the library? With what compiler? Did you have any problems? No. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in-depth study with a glaring omission; the library was not used. Lack of time, old compiler, employer resistance to boost. * Are you knowledgeable about the problem domain? Yes. * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes. Cheers.

8 24

[serialization] portable_binary_archive
by troy d. straszheim 18 Sep '05

18 Sep '05

Hi Robert, boost... I've implemented a portable binary archive, wondering if there is general interest. I've tested (very thoroughly) on our target platforms, which are 32 and 64 bit linux, and osx on a g5, each platform reads and writes archives written by the others, down to the bit. The archive itself is stored little-endian (as the vast majority of my users are on intel hardware) so big-endian platforms are responsible for byteswapping, though this could be configurable. The problem types are (unsigned) long int and long double. For long int, the archive checks to see if it is small enough to fit into 32 bits, if so it stores it in 32 bits, otherwise it throws. For long double, it just throws, as that's 12 bytes on some platforms, 16 on others, no good way to handle this, and the type is seldom used anyhow. Float and double are assumed to be ieee754, and are just handled as blocks of 32 or 64 bytes. So if the write succeeds, the read is guaranteed to. Part of the idea here is that without resorting to widespread use of int32_t and friends, 4-byte-long platforms are always be able to write archives readable on 8-byte-long platforms. On 8-byte-long platforms, you could write archives readable on the smaller machines, but best to choose either int or long long int or a typedef thereof (int32_t or int64_t). The code is at http://svn.resophonic.com/pub/boost, in boost/archive/detail/portable_binary_archive.hpp boost/archive/portable_binary_iarchive.hpp boost/archive/portable_binary_oarchive.hpp libs/serialization/src/portable_binary_iarchive.cpp libs/serialization/src/portable_binary_oarchive.cpp libs/serialization/test/portable_binary_archive.cpp Issues that come to mind: The test isn't boost-test, that'd need rewriting. Haven't tried any of this on microsoft. Maybe there is some preferred way to detect endianness. The decision to go little-endian was relatively arbitrary, maybe the byte-swapping should be configurable. A possibility I considered was to upgrade all 32 bit longs to 64 bit and do the range-check/throw when *reading* (We nixed this idea, preferring to have the error come up sooner rather than later), maybe this should be configurable as well. There's surely platforms out there with other differences that aren't handled, I don't have a good feel for whether they would make the archive useless to a wider audience. The tests require having access to binary archives written on other platforms, haven't yet thought about how to put that together in the boost build/test context. So have a look, let me know if you're interested. Thanks again for a great lib. troy d. straszheim

4 10

boost::spirit inter-grammar rule referencing
by Hugh Hoover 18 Sep '05

18 Sep '05

I have a pair of grammars where one is currently used purely as if it were a single rule in the second grammar. I'm finding that I want to use a second rule in the first grammar for a start rule when invoked from a particular rule in the second grammar. sort of like this: struct grammarA : public grammar<grammarA> { ... struct definition<ScannerT> { ... definition(grammarA const& self) { r_ruleOne = ... r_ruleTwo = ... ... } rule<ScannerT, parser_context<>, parser_tag<ruleOneId> > const & start() const { return r_ruleOne; } }; }; grammarA r_grammarA; struct grammarB : public grammar<grammarB> { struct definition<ScannerT> { ... definition(grammarB const& self) { r_ruleBOne = ( r_grammarA | chseq_p("foo") ); r_ruleBTwo = ( chseq_p("bar") >> ??? r_grammarA.definition.r_ruleTwo ??? ); // obviously bogus - // r_ruleBTwo is currently like the above with just r_grammarA in the second part. ... } ... }; }; Is this possible? grammar_def doesn't appear to apply here - it could work if I wanted to start the WHOLE parse at a different start node, but referenced from another grammar? I can't find any (other) appropriate wordage under "rule" or "grammar" in the spirit docs. is my example understandable? I elided a lot of "boilerplate" to keep it short... I can't separate grammarA::r_ruleTwo from grammarA, it needs other rules in grammarA. I >could< just copy the whole damn grammarA and specify a different start rule, but that just doesn't seem very elegant, no'wuddimean? Hugh Hoover Enumclaw Software

2 1

Checked Integral Class
by Dan McLeran 18 Sep '05

18 Sep '05

I've written a template class to hold a range of valid integral values. My intent was to mimic Ada's ability to define a type like this: type SmallInt is range -10 .. 10; One can then declare objects of this type and any subsequent assignment that violated this range constraint woud throw an exception. I have built a C++ template class that does the same thing: template<typename T, T min, T max> struct CheckedIntegralValue To define a type that can hold the same range as the example above: typedef CheckedIntegralValue<int, -10, 10> SmallIntType; SmallIntType i = -10;//OK SmallIntType i2 = -100;//Will throw an exception at run-time for value out-of-range I won't include the whole thing here, but I can do so if there is enough interest. I have defined most of the operators one needs to use this type just as one would use a 'normal' integer. Would anyone be interested in something like this in the Boost libraries? Regards, Dan McLeran

8 22

condition Win32 based on events
by Roland Schwarz 18 Sep '05

18 Sep '05

While reviewing the current implementation of boost thread in an effort to split the code into platform specific parts for easier maintanace, I looked into the current implementation of condition variables too. Altough I know the past discussions about this topic to some degree, nevertheless I like to drop in another solution for review. The idea is based on the PulseEvent and SetEvent solution of "Strategies for Implementing POSIX Condition Variables on Win32" from Douglas C. Schmidt http://www.cs.wustl.edu/~schmidt/win32-cv-1.html . The most "concise and intuitive" solution there is described as suffering from the so called "lost wakeup bug". Nevertheless I used this as a starting point. To overcome the lost wakeup bug I introduced the concept of a gate, and using stateful (manual reset) events. The gate is closed whenever a broadcast or signal is underway. On entry to wait the gate also has to be passed through, while simultaneously successful entries are recorded. The trick is that the gate can be closed by one thread (the signaling one) and reopened by another (the waiting one). This can be achieved by using a Semaphore instead of a mutex for the gate implementation. Semaphores can be set/reset from different threads. Altough I think I was careful enough, it might well be that I made an mistake. Also since the idea is so simple and it needs so less code for implementation, I am wondering whether someone else came up with this solution. I would be very glad if someone could take a look at the code and show me its pitfalls. For my draft I used VC7.1 on W2K. The code is without error handling yet. The main() implements a small test, simulating a queue that is served by three threads. Code follows: #include <windows.h> #include <boost/thread/thread.hpp> using namespace boost; typedef CRITICAL_SECTION pthread_mutex_t; void pthread_mutex_init(pthread_mutex_t* mutex) { InitializeCriticalSection(mutex); } void pthread_mutex_destroy(pthread_mutex_t* mutex) { DeleteCriticalSection(mutex); } void pthread_mutex_lock(pthread_mutex_t* mutex) { EnterCriticalSection(mutex); } void pthread_mutex_unlock(pthread_mutex_t* mutex) { LeaveCriticalSection(mutex); } // the condition variable implementation starts here // -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- #define SIGNAL 0 #define BROADCAST 1 typedef struct { HANDLE events_[2]; HANDLE gate_; int waiters_; } pthread_cond_t; void pthread_cond_init(pthread_cond_t *cv) { cv->events_[SIGNAL] = CreateEvent(NULL,FALSE,FALSE,NULL); cv->events_[BROADCAST] = CreateEvent(NULL,TRUE,FALSE,NULL); // use a semaphore instead of mutex since // they can be used cross thread cv->gate_ = CreateSemaphore(NULL,1,1,NULL); cv->waiters_ = 0; } void pthread_cond_destroy(pthread_cond_t* cv) { CloseHandle(cv->events_[SIGNAL]); CloseHandle(cv->events_[BROADCAST]); CloseHandle(cv->gate_); } void pthread_cond_wait( pthread_cond_t* cv, pthread_mutex_t* external_mutex) { // we may only enter when no wakeups active // this will prevent the lost wakeup WaitForSingleObject(cv->gate_, INFINITE); ++cv->waiters_; // count waiters passing through ReleaseSemaphore(cv->gate_,1,NULL); LeaveCriticalSection(external_mutex); switch(WaitForMultipleObjects( 2, cv->events_,FALSE,INFINITE)) { // on unblocking of the thread the gate is closed case WAIT_OBJECT_0+SIGNAL: --cv->waiters_; // one is leaving ReleaseSemaphore(cv->gate_,1,NULL);//reopen // no need to reset event, it is automatic break; case WAIT_OBJECT_0+BROADCAST: if (0 == --cv->waiters_) { ResetEvent( cv->events_[BROADCAST]); // last leaving, reopen the gate ReleaseSemaphore(cv->gate_,1,NULL); } break; } EnterCriticalSection(external_mutex); } void pthread_cond_broadcast (pthread_cond_t *cv) { WaitForSingleObject(cv->gate_, INFINITE);//close gate if (cv->waiters_) // if no waiters just reopen gate SetEvent (cv->events_[BROADCAST]); // wake all else ReleaseSemaphore(cv->gate_,1,NULL); } void pthread_cond_signal (pthread_cond_t *cv) { WaitForSingleObject(cv->gate_, INFINITE);//close gate if (cv->waiters_) // if no waiters just reopen gate SetEvent (cv->events_[SIGNAL]); // wake one else ReleaseSemaphore(cv->gate_,1,NULL); } // -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- // the condition variable implementation ends here // a small example for testing follows: // 3 worker threads try to consume input and update output // main thread generates input and then waits until all // input has been processed by checking the output pthread_mutex_t m; pthread_cond_t ci, co; bool run; int input, output, total; int done1, done2, done3; void do_work1() { pthread_mutex_lock(&m); while (run) { while (0 == input && run) pthread_cond_wait(&ci, &m); if (!run) break; --input; ++output; ++done1; pthread_cond_signal(&co); } pthread_mutex_unlock(&m); } void do_work2() { pthread_mutex_lock(&m); while (run) { while (0 == input && run) pthread_cond_wait(&ci, &m); if (!run) break; --input; ++output; ++done2; pthread_cond_signal(&co); } pthread_mutex_unlock(&m); } void do_work3() { pthread_mutex_lock(&m); while (run) { while (0 == input && run) pthread_cond_wait(&ci, &m); if (!run) break; --input; ++output; ++done3; pthread_cond_signal(&co); } pthread_mutex_unlock(&m); } int main(int argc, char* argv) { pthread_mutex_init(&m); pthread_cond_init(&ci); pthread_cond_init(&co); done1 = done2 = done3 = 0; total = input = output = 0; run = true; boost::thread t1(do_work1); boost::thread t2(do_work2); boost::thread t3(do_work3); for (int n = 0; n<1000; ++n) { pthread_mutex_lock(&m); input+=5; total+=5; pthread_cond_broadcast(&ci); pthread_mutex_unlock(&m); } pthread_mutex_lock(&m); while (output < total) pthread_cond_wait(&co, &m); run = false; pthread_cond_broadcast(&ci); pthread_mutex_unlock(&m); t1.join(); t2.join(); t3.join(); pthread_cond_destroy(&co); pthread_cond_destroy(&ci); pthread_mutex_destroy(&m); return 0; } Regards, Roland

4 16

Boost regression notification (2005-09-18 [RC_1_33_0])
by Douglas Gregor 18 Sep '05

18 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-18T14:45:10Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 113 failures in 9 libraries: concept_check (18) foreach (1) graph (5) multi_index (1) random (1) range (3) serialization (73) thread (8) wave (3) |concept_check| stl_concept_covering: borland-5_6_4 cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-4.0.1-linux gcc-4_0-darwin intel-8.1-linux intel-9.0-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 |foreach| rvalue_const: vc-7_1 |graph| betweenness_centrality_test: gcc-3.4.4-linux dag_longest_paths: gcc-3.4.4-linux dijkstra_cc: gcc-3.4.4-linux dijkstra_heap_performance: gcc-3.4.4-linux relaxed_heap_test: gcc-3.4.4-linux |multi_index| test_serialization: intel-win32-9_0 |random| random_test: gcc-3.3.6-linux |range| array: vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_binary_archive: gcc-3.2.3-linux test_class_info_load_binary_archive_dll: gcc-3.2.3-linux test_class_info_load_text_archive: gcc-3.2.3-linux test_class_info_load_text_archive_dll: gcc-3.2.3-linux test_class_info_load_text_warchive: gcc-3.2.3-linux test_class_info_load_text_warchive_dll: gcc-3.2.3-linux test_class_info_load_xml_archive: gcc-3.2.3-linux test_class_info_load_xml_archive_dll: gcc-3.2.3-linux test_class_info_load_xml_warchive: gcc-3.2.3-linux test_class_info_load_xml_warchive_dll: gcc-3.2.3-linux test_exported_binary_archive: vc-6_5 test_exported_binary_archive_dll: vc-6_5 test_exported_text_archive: vc-6_5 test_exported_text_archive_dll: vc-6_5 test_exported_text_warchive: vc-6_5 test_exported_text_warchive_dll: vc-6_5 test_exported_xml_archive: vc-6_5 test_exported_xml_archive_dll: vc-6_5 test_exported_xml_warchive: vc-6_5 test_exported_xml_warchive_dll: vc-6_5 test_map_xml_archive: vc-6_5 vc-7_0 test_map_xml_archive_dll: vc-6_5 vc-7_0 test_map_xml_warchive: vc-6_5 vc-7_0 test_map_xml_warchive_dll: vc-6_5 vc-7_0 test_no_rtti_binary_archive: vc-6_5 test_no_rtti_binary_archive_dll: vc-6_5 test_no_rtti_text_archive: vc-6_5 test_no_rtti_text_archive_dll: vc-6_5 test_no_rtti_text_warchive: vc-6_5 test_no_rtti_text_warchive_dll: vc-6_5 test_no_rtti_xml_archive: vc-6_5 test_no_rtti_xml_archive_dll: vc-6_5 test_no_rtti_xml_warchive: vc-6_5 test_no_rtti_xml_warchive_dll: vc-6_5 test_shared_ptr_132_binary_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_binary_archive_dll: vc-6_5 test_shared_ptr_132_text_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_archive_dll: vc-6_5 test_shared_ptr_132_text_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_text_warchive_dll: vc-6_5 test_shared_ptr_132_xml_archive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_archive_dll: vc-6_5 test_shared_ptr_132_xml_warchive: vc-6_5 vc-6_5-stlport test_shared_ptr_132_xml_warchive_dll: vc-6_5 test_shared_ptr_binary_archive: borland-5_6_4 vc-6_5 test_shared_ptr_binary_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive: borland-5_6_4 vc-6_5 test_shared_ptr_text_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_text_warchive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_archive_dll: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive: borland-5_6_4 vc-6_5 test_shared_ptr_xml_warchive_dll: borland-5_6_4 vc-6_5 |thread| test_barrier_lib: intel-9.0-linux test_condition_lib: intel-9.0-linux test_mutex_lib: intel-9.0-linux test_once_lib: intel-9.0-linux test_read_write_mutex_lib: intel-9.0-linux test_thread_lib: intel-9.0-linux test_tss_lib: intel-9.0-linux test_xtime_lib: intel-9.0-linux |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: intel-9.0-linux

1 0

Boost regression notification (2005-09-18 [HEAD])
by Douglas Gregor 18 Sep '05

18 Sep '05

Boost regression test failures ------------------------------ Report time: 2005-09-18T05:00:27Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. typeof Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 222 failures in 15 libraries: concept_check (14) date_time (5) filesystem (8) foreach (7) graph (4) math (6) mpl (2) parameter (17) python (1) regex (1) serialization (40) spirit (2) thread (24) typeof (87) wave (4) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 vc-7_1 |date_time| testlocal_time_iterator: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc testlocal_time_period: gcc-2.95.3-linux msvc |filesystem| convenience_test: msvc default_name_check_test: msvc fstream_test: msvc large_file_support_test: msvc operations_test: msvc operations_test_dll: msvc path_test: msvc path_test_dll: msvc |foreach| user_defined: cw-8_3 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-6_5-stlport vc-7_0 |graph| graphviz_test: vc-7_1 vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |math| octonion_test: gcc-4_0-darwin gcc-4_0-darwin quaternion_test: gcc-4_0-darwin gcc-4_0-darwin special_functions_test: gcc-4_0-darwin gcc-4_0-darwin |mpl| size_t: gcc-4_0-darwin gcc-4_0-darwin |parameter| basics: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc macros: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux msvc unnamed: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux vc-7_1 |python| data_members: msvc |regex| static_mutex_test: msvc |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |spirit| traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_barrier: msvc test_barrier_lib: intel-9.0-linux msvc test_condition: msvc test_condition_lib: intel-9.0-linux msvc test_mutex: msvc test_mutex_lib: intel-9.0-linux msvc test_once: msvc test_once_lib: intel-9.0-linux msvc test_read_write_mutex: msvc test_read_write_mutex_lib: intel-9.0-linux msvc test_thread: msvc test_thread_lib: intel-9.0-linux msvc test_tss: msvc test_tss_lib: intel-9.0-linux msvc test_xtime: msvc test_xtime_lib: intel-9.0-linux msvc |typeof| data_member_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux data_member_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 function_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc function_ptr_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ptr_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 function_ref_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux function_ref_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 lvalue_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux lvalue_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc member_function_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux member_function_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 modifiers_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux modifiers_native: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_int_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_int_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 template_tpl_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_tpl_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 msvc template_type_emulation: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux template_type_native: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 intel-win32-9_0 type_emulation: borland-5_6_4 cw-8_3 cw-9_4 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux type_native: borland-5_6_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 intel-win32-9_0 |wave| test_re2c_lexer: intel-9.0-linux test_slex_lexer: intel-9.0-linux testwave: gcc-3.3.6-linux intel-9.0-linux

1 0

[lambda] extension question
by Brock Peabody 18 Sep '05

18 Sep '05

Hi, I'm trying to learn how to make my own lambda compatible function objects and I'm hoping that someone can nudge me in the right direction. My first try is called tuple_element. It takes an index as a template parameter and a tuple as an argument, returning the element at the given index: //should print "x" cout << tuple_element<1>(_1)(tuple<int,std::string>(2, "x")); I've got everything working except for the sig template. tuple_element looks like (mostly copied from lambda source code): template <int Index> struct tuple_element_action {}; template <int Index, typename Arg> inline const lambda_functor< lambda_functor_base< tuple_element_action<Index>, tuple<lambda_functor<Arg> > > > tuple_element(const lambda_functor<Arg>& a) { return lambda_functor_base< tuple_element_action<Index>, tuple<lambda_functor<Arg> > > ( tuple<lambda_functor<Arg> >(a)); } and the action: template<typename Args, int Index> class lambda_functor_base<tuple_element_action<Index>, Args> { public: Args args; template <class T> struct sig : tuples::element<Index,T> {}; explicit lambda_functor_base(const Args& a) : args(a) {} template<class RET, CALL_TEMPLATE_ARGS> RET call(CALL_FORMAL_ARGS) const { return detail::select(get<0>(args), CALL_ACTUAL_ARGS).get<Index>(); } }; When I try to compile my example in VC 7.1 I get an error that seems to indicate that the type being passed to the sig template is boost::tuples::null_type. Everything works if I hardwire it like: template <class T> struct sig { typedef std::string type; }; Any ideas? Thanks, Brock

5 13

[Boost-bugs] [ boost-Bugs-1294420 ] html docs frequently missing key words
by SourceForge.net 18 Sep '05

18 Sep '05

Bugs item #1294420, was opened at 2005-09-18 01:55 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=1294420&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ivo Roper (ivolucien) Assigned to: Nobody/Anonymous (nobody) Summary: html docs frequently missing key words Initial Comment: Some (many?) of the html formatted reference docs are missing the name Boost or other key works in their text. Here are some examples: boost_1_33_0/doc/html/threads.html is missing "boost" in several places. Search for "allows C++" or "destructors never" and various others... boost_1_33_0/doc/html/program_options/overview.html is missing other key words or phrases, search for "classes: " and also "describes a number" It's my guess that this is most likely the result of a documentation generator bug or the like and spans all docs that use whatever syntax is used to generate the examples above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1294420&group_… ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[range] naming adl functions
by Thorsten Ottosen 18 Sep '05

18 Sep '05

Hi all, Could we agree on a naming scheme/implementation scheme for the customization-points? I prefer range_begin() range_end() range_size() to boost_range_begin() boost_range_end() boost_range_size() and think these identifiers are unique enough, the small amout of global costomization-points taken into consideration. The consequence of this is that other libraries should always call boost::begin() with qualification. This function must always fall back on a function template which implements the default behavior. The consequence for users is that they must - provide hooks in their own namespace wich is then found via ADL. - Users can specialize boost::begin, but not boost::unspecified_namespace::range_begin. - Global functions will not be found. - derived to base-class conversion are not performed before ADL tries to locate a function -Thorsten

3 5