November 2007 - Boost - lists.preview.boost.org

[bjam] warn: Unable to construct <library target name>
by Dean Michael Berris 26 Nov '07

26 Nov '07

Hi Everyone, I've recently tried the suggestion in the Boost.Build documentation regarding the use of the lib rule to name libraries that can be supplied as dependencies and having the library available in the search path. I have a Jamfile that looks like: project my_project : requirements <include>.. <link>static ; lib some_system_installed_lib : : <name>mylib ; exe my_exe : my_main.cpp some_system_installed_lib ; I then get the 'warn: Unable to construct <library target name>' message when running bjam. Am I doing something wrong? I'm referring to this page: http://boost.org/boost-build2/doc/html/bbv2/tasks/libraries.html and I'm using the bjam updated to today. Have a good day everyone. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis(a)gmail.com] [+63 928 7291459] [+1 408 4049523]

2 2

FW: [Boost-users] [threads] Using boost::mutex raises access violation exception
by v2cechura 26 Nov '07

26 Nov '07

I posted this to the user's list (no answer till now), but later came to the conclusion that developer's list might be a better place. Any help on th issue appreciated. Vaclav -----Original Post------ I just recently installed and built boost library (1.34.1) using bcbboost. I wanted to try the boost::thread class. This simple code gives me "Access Violation" in Borland C++ Builder 2006 when boost::mutex is used: //-------------------------------------------------------------------------- - #include <iostream> #include <boost/thread.hpp> //-------------------------------------------------------------------------- - boost::xtime xt = {2}; boost::mutex console; // line A void thr() // int n, boost::mutex & display { for (int i = 0; i < 10; i++) { { boost::mutex::scoped_lock l(console); // line B std::cout << "thr" << 1 << ":" << i << std::endl; } boost::thread::sleep(xt); } // end for } int main(int argc, char* argv[]) { boost::thread_group tg; tg.create_thread(&thr); char c; std::cin >> c ; return 0; } If line A and line B are commented-out then the error is gone. The project is a multithreaded console application, both boost.threads and rtl are static-linked. Caller stack is: :7c812a5b kernel32.RaiseException + 0x52 :004129aa ___raiseDebuggerException + 0x1A :00412a84 ; ___raiseDebuggerException :7c9037bf ntdll.RtlConvertUlongToLargeInteger + 0x7a :7c90378b ntdll.RtlConvertUlongToLargeInteger + 0x46 :7c90eafa ntdll.KiUserExceptionDispatcher + 0xe :0041FA2B boost::mutex::do_unlock(this=NULL, =:0012FDE8) :0041E3A2 boost::detail::thread::lock_ops<boost::mutex>::unlock(m=NULL, state=:0012FDE8) :0041E12D boost::condition::do_wait<boost::mutex>(this=:0012FEA4, mutex=NULL) :0041DE2E boost::condition::wait<boost::detail::thread::scoped_lock<boost::mutex> >(this=:0012FEA4, lock=:0012FE5C) :0041D42F __UNNS__thread_01c827c2c2c9169a::thread_param::wait(this=:0012FE9C) :0041D201 boost::thread::thread(this=:00000FCC, threadfunc=:00000FC8) :00000001 :0012fe01 I put mutex.cpp in my directory and BCB2006 locates the error to be here: void mutex::do_unlock() { if (m_critical_section) //------------- Access violation HERE release_critical_section(m_mutex); else release_mutex(m_mutex); } The access violation is raised when thread::thread constructor is called. Looking at the caller stack I noticed that mutex parameter is NULL from some point and it results in this==NULL for the last call. Note that this mutex parameter is not the mutex "console" object I use in the program. It is a mutex that boost.threads library uses during thread initialization. On the other hand there is some dependance on mutex "console" because when I comment it out the error is gone. I maked console a pointer with appropriate changes to source and created it using new but it did not help. Am I missing something? Any help appreciated. Does anybody have experiences with boost::thread and mutex under BCB(2006,2007...)? Vaclav

5 8

[regex, threads, test] Exception problems
by Beman Dawes 26 Nov '07

26 Nov '07

In another posting, John Maddock wrote: > ... I'm a little concerned about some of > the regex library tests which haven't changed in ages, but are none the less > failing due to exceptions thrown from Boost.Thread and Boost.Test. I'm not > sure that this is necessarily these libraries fault, but we really ought to > try and get to the cause of this... I'm worried about these too. I'm also getting exception related dialog boxes during Windows smoke tests; they don't even say what program they are coming out of. Not sure if that is the same problem; I'll try to isolate one of them and report details. Which specific test are you concerned about? regex_regress_threaded? Any others? --Beman

7 14

[lexical_cast][trunk] problem with rev 41387 of boost/lexical_cast.hpp
by Joaquín Mª López Muñoz 26 Nov '07

26 Nov '07

Hello, the aforementioned revision adds a new Traits template parameter to boost::detail::lexical_stream, but it fails to accordingly upgrade the usage of lexical_stream at line 1183: template<typename Target, typename Source> Target lexical_cast(Source arg) { detail::lexical_stream<Target, Source> interpreter; Target result; ... Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 6

FYI... Minimal or complete builds.
by Rene Rivera 26 Nov '07

26 Nov '07

I finally got around to implementing the build change to only build one variant by default <http://svn.boost.org/trac/boost/changeset/41380>. I would appreciate if people test this on various platforms to make sure I didn't mess up ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 1

[typeof] Typeof support for Visual Studio with Code Analysis enabled
by Peder Holt 25 Nov '07

25 Nov '07

Is there a way to detect at compile time whether you are running code analysis or not? The 'native' typeof implementation for Visual Studio uses a hack to deduce the type of an expression. Originally, the type of the expression was coupled with a compile time integer in order to be able to access the type later, so all you need to do is take the size of some template function and ask the deducer about what type it corresponds to. This method works, but we experienced some problems with ICEs on VC7.1 and VC8.0, so I started experimenting with using typeid in stead (extract_type<typeid(encode_type(expr))>::type). Completely nonstandard, but so is the rest of the hack, so why not. This seemed to eliminate the ICEs on mentioned platforms, and also eliminated the limit on number of typeof invocations in a single compilation unit (~1000) Now it turns out that microsofts code analysis tool complains about the use of typeid. When using sizeof, reverting to sizeof, it also ICES on the following expression: void f() {} template<class T> struct tpl { typedef BOOST_TYPEOF_TPL(&f) type; }; It would be nice to disable code analysis for this piece of code. I'll revert the code to using sizeof for now. Regards Peder

1 0

[website] Tools docs usability problem
by Beman Dawes 25 Nov '07

25 Nov '07

Some of the documentation that used to live within the boost-root/tools directory sub-tree has been moved to the website-root\public_html\beta\development directory. That creates a usability problem because boost-root/tools/tool-name/index.html is no longer present. When working with these tools, you are usually using either the command line or a GUI directory tree browser, not a web browser. Thus it is now a real pain in the anatomy to locate the docs since aren't right there where you are working. Worse yet, you may fail to realize there *are* any docs, and never look for them at all. In the boost-root/libs directory tree, we solve this same problem by providing an index.html file for each library that automatically redirects to wherever the docs for the library actually live. Because that is generally a relative link, it finds either the web version or the version within the local disk tree, depending on whether you are browsing the web or a local working copy. This is expected behavior, and works very well in practice. If you are using a working copy, you get the docs as of that working copy. If you are looking at the web site, you get the docs matching the web site release. Perhaps we can solve the problem for tools in the same way. Each tool could have an index.html file that redirects to the actual docs location. With the docs now in a sub-tree that is not within the boost-root tree, the redirection requires a bit of logic: If index.html is a local working copy, redirect to beta.boost.org/... otherwise redirect to www.boost.org/... Is this the best solution? Is Javascript capable of doing that? --Beman

5 11

[Report] 362 failures on trunk (2007-11-25)
by Douglas Gregor 25 Nov '07

25 Nov '07

Boost regression test failures Report time: 2007-11-25T12:24:06Z This report lists all regression test failures on release platforms. Detailed report: http://boost.org/regression/trunk/developer/issues.html 362 failures in 23 libraries bimap (4) concept_check (3) conversion (8) date_time (11) dynamic_bitset (6) function_types (36) fusion (2) gil (9) graph (10) interprocess (30) lambda (1) math (1) mpl (2) numeric/interval (19) parameter (1) ptr_container (1) python (71) regex (10) serialization (116) spirit (6) test (5) thread (5) tokenizer (5) |bimap| foreach: hp_cxx-71_006_tru64 test_bimap_info: hp_cxx-71_006_tru64 test_bimap_ordered: hp_cxx-71_006_tru64 test_bimap_unordered: hp_cxx-71_006_tru64 |concept_check| stl_concept_check: hp_cxx-71_006_tru64 where: intel-linux-9.0 intel-vc8-win-10.0 |conversion| lexical_cast_test: darwin-4.0.1 gcc-4.2.1 intel-linux-9.0 intel-vc8-win-10.0 msvc-7.1 msvc-8.0 msvc-8.0 msvc-8.0_64 |date_time| testlocal_time_facet: darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 testtime_serialize_xml_std_config: darwin-4.0.1 testtz_database: darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 |dynamic_bitset| dyn_bitset_unit_tests3: gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 dyn_bitset_unit_tests4: gcc-4.2.1 intel-linux-9.0 |function_types| fast_mem_fn_example: msvc-7.1 interface_example: msvc-7.1 member_ccs: darwin-4.0.1 darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64 member_ccs_exact: darwin-4.0.1 darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64 nonmember_ccs: gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64 nonmember_ccs_exact: gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 intel-vc8-win-10.0 msvc-8.0_64 |fusion| deduce_sequence: intel-vc8-win-10.0 repetitive_view: intel-vc8-win-10.0 |gil| channel: intel-vc8-win-10.0 image: gcc-4.1.2_sunos_i86pc intel-vc8-win-10.0 image_io: gcc-4.1.2_sunos_i86pc main: gcc-4.1.2_sunos_i86pc intel-vc8-win-10.0 pixel: gcc-4.1.2_sunos_i86pc intel-vc8-win-10.0 pixel_iterator: gcc-4.1.2_sunos_i86pc |graph| betweenness_centrality_test: gcc-4.2.1_linux_x86_64 csr_graph_test: msvc-8.0_64 cycle_ratio_tests: intel-vc8-win-10.0 msvc-8.0 floyd_warshall_test: gcc-4.2.1_linux_x86_64 graphml_test: intel-vc8-win-10.0 msvc-8.0 graphviz_test: intel-vc8-win-10.0 msvc-8.0 matching_test: gcc-4.2.1_linux_x86_64 |interprocess| condition_test: gcc-4.2.1 hp_cxx-71_006_tru64 deque_test: hp_cxx-71_006_tru64 doc_anonymous_semaphoreA: gcc-4.2.1 doc_anonymous_semaphoreB: gcc-4.2.1 doc_named_mutex: gcc-4.2.1 file_mapping_test: gcc-4.2.1 mapped_file_test: gcc-4.2.1 hp_cxx-71_006_tru64 message_queue_test: gcc-4.2.1 hp_cxx-71_006_tru64 named_condition_test: gcc-4.2.1 hp_cxx-71_006_tru64 named_mutex_test: gcc-4.2.1 hp_cxx-71_006_tru64 named_recursive_mutex_test: gcc-4.2.1 hp_cxx-71_006_tru64 named_semaphore_test: gcc-4.2.1 hp_cxx-71_006_tru64 named_upgradable_mutex_test: gcc-4.2.1 hp_cxx-71_006_tru64 semaphore_test: gcc-4.2.1 shared_memory_mapping_test: gcc-4.2.1 shared_memory_test: gcc-4.2.1 hp_cxx-71_006_tru64 shared_ptr_test: gcc-4.2.1 string_test: hp_cxx-71_006_tru64 upgradable_mutex_test: gcc-4.2.1 hp_cxx-71_006_tru64 vector_test: hp_cxx-71_006_tru64 |lambda| operator_tests_simple: msvc-7.1 |math| test_igamma_inva_real_concept: gcc-4.2.1_linux_x86_64 |mpl| is_seq: intel-vc8-win-10.0 token_equal: intel-vc8-win-10.0 |numeric/interval| det: gcc-4.2.1 msvc-8.0_64 integer: gcc-4.2.1 mul: darwin-4.0.1 darwin-4.0.1 gcc-4.2.1 msvc-8.0_64 overflow: darwin-4.0.1 darwin-4.0.1 gcc-4.2.1 msvc-8.0_64 pi: darwin-4.0.1 darwin-4.0.1 gcc-4.2.1 msvc-8.0_64 pow: gcc-4.2.1 msvc-8.0_64 test_float: gcc-4.2.1 msvc-8.0_64 |parameter| python_test: msvc-8.0 |ptr_container| serialization: intel-vc8-win-10.0 |python| andreas_beyer: msvc-8.0 args: msvc-8.0 auto_ptr: msvc-8.0 back_reference: msvc-8.0 bases: intel-linux-9.0 ben_scott1: msvc-8.0 bienstman1: msvc-8.0 bienstman2: msvc-8.0 bienstman3: msvc-8.0 callbacks: msvc-8.0 const_argument: msvc-8.0 crossmod_exception: msvc-8.0 crossmod_opaque: msvc-8.0 data_members: msvc-8.0 defaults: msvc-8.0 dict: msvc-8.0 docstring: msvc-8.0 enum: msvc-8.0 exception_translator: msvc-8.0 exec: gcc-4.1.2_sunos_i86pc intel-linux-9.0 msvc-8.0 exec-dynamic: intel-linux-9.0 msvc-8.0 extract: msvc-8.0 implicit: msvc-8.0 import_: intel-linux-9.0 msvc-8.0 injected: msvc-8.0 iterator: msvc-8.0 keywords: msvc-8.0 list: msvc-8.0 long: msvc-8.0 minimal: msvc-8.0 multi_arg_constructor: msvc-8.0 nested: msvc-8.0 numpy: msvc-8.0 object: intel-vc8-win-10.0 msvc-8.0 opaque: msvc-8.0 operators: msvc-8.0 operators_wrapper: msvc-8.0 pearu1: msvc-8.0 pickle1: msvc-8.0 pickle2: msvc-8.0 pickle3: msvc-8.0 pickle4: msvc-8.0 pointee: intel-linux-9.0 pointer_type_id_test: intel-linux-9.0 pointer_vector: msvc-8.0 polymorphism: msvc-8.0 polymorphism2: msvc-8.0 polymorphism2_auto_ptr: msvc-8.0 properties: msvc-8.0 pytype_function: msvc-8.0 raw_ctor: msvc-8.0 return_arg: msvc-8.0 select_arg_to_python_test: msvc-8.0 shared_ptr: msvc-8.0 slice: msvc-8.0 staticmethod: msvc-8.0 stl_iterator: msvc-8.0 str: msvc-8.0 test_pointer_adoption: msvc-8.0 try: msvc-8.0 tuple: msvc-8.0 upcast: intel-linux-9.0 vector_indexing_suite: msvc-8.0 virtual_functions: msvc-8.0 voidptr: msvc-8.0 wrapper_held_type: msvc-8.0 |regex| regex_regress_threaded: gcc-4.2.1_linux_x86_64 intel-vc8-win-10.0 regex_timer: darwin-4.0.1 gcc-4.2.1 intel-linux-9.0 intel-vc8-win-10.0 msvc-7.1 msvc-8.0 msvc-8.0 msvc-8.0_64 |serialization| test_demo_portable_archive: gcc-4.2.1 test_demo_portable_archive_dll: gcc-4.2.1 test_demo_xml: darwin-4.0.1 test_diamond_binary_archive: intel-vc8-win-10.0 test_diamond_binary_archive_dll: intel-vc8-win-10.0 test_diamond_text_archive: intel-vc8-win-10.0 test_diamond_text_archive_dll: intel-vc8-win-10.0 test_diamond_text_warchive: intel-vc8-win-10.0 test_diamond_text_warchive_dll: intel-vc8-win-10.0 test_diamond_xml_archive: intel-vc8-win-10.0 test_diamond_xml_archive_dll: intel-vc8-win-10.0 test_diamond_xml_warchive: intel-vc8-win-10.0 test_diamond_xml_warchive_dll: intel-vc8-win-10.0 test_exported_binary_archive: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 intel-vc8-win-10.0 test_exported_binary_archive_dll: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 intel-vc8-win-10.0 test_exported_text_archive: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 intel-vc8-win-10.0 test_exported_text_archive_dll: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 intel-vc8-win-10.0 test_exported_text_warchive: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 intel-vc8-win-10.0 test_exported_text_warchive_dll: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 intel-vc8-win-10.0 test_exported_xml_archive: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 intel-vc8-win-10.0 test_exported_xml_archive_dll: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 intel-vc8-win-10.0 test_exported_xml_warchive: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 intel-vc8-win-10.0 test_exported_xml_warchive_dll: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64 intel-vc8-win-10.0 test_inclusion: intel-vc8-win-10.0 test_mult_archive_types: intel-vc8-win-10.0 test_mult_archive_types_dll: intel-vc8-win-10.0 test_no_rtti_binary_archive: intel-vc8-win-10.0 test_no_rtti_binary_archive_dll: intel-vc8-win-10.0 test_no_rtti_text_archive: intel-vc8-win-10.0 test_no_rtti_text_archive_dll: intel-vc8-win-10.0 test_no_rtti_text_warchive: intel-vc8-win-10.0 test_no_rtti_text_warchive_dll: intel-vc8-win-10.0 test_no_rtti_xml_archive: intel-vc8-win-10.0 test_no_rtti_xml_archive_dll: intel-vc8-win-10.0 test_no_rtti_xml_warchive: intel-vc8-win-10.0 test_no_rtti_xml_warchive_dll: intel-vc8-win-10.0 test_shared_ptr_132_binary_archive: intel-vc8-win-10.0 test_shared_ptr_132_binary_archive_dll: intel-vc8-win-10.0 test_shared_ptr_132_text_archive: intel-vc8-win-10.0 test_shared_ptr_132_text_archive_dll: intel-vc8-win-10.0 test_shared_ptr_132_text_warchive: intel-vc8-win-10.0 test_shared_ptr_132_text_warchive_dll: intel-vc8-win-10.0 test_shared_ptr_132_xml_archive: intel-vc8-win-10.0 test_shared_ptr_132_xml_archive_dll: intel-vc8-win-10.0 test_shared_ptr_132_xml_warchive: intel-vc8-win-10.0 test_shared_ptr_132_xml_warchive_dll: intel-vc8-win-10.0 test_shared_ptr_binary_archive: intel-vc8-win-10.0 test_shared_ptr_binary_archive_dll: intel-vc8-win-10.0 test_shared_ptr_text_archive: intel-vc8-win-10.0 test_shared_ptr_text_archive_dll: intel-vc8-win-10.0 test_shared_ptr_text_warchive: intel-vc8-win-10.0 test_shared_ptr_text_warchive_dll: intel-vc8-win-10.0 test_shared_ptr_xml_archive: intel-vc8-win-10.0 test_shared_ptr_xml_archive_dll: intel-vc8-win-10.0 test_shared_ptr_xml_warchive: intel-vc8-win-10.0 test_shared_ptr_xml_warchive_dll: intel-vc8-win-10.0 |spirit| owi_mt_tests: intel-vc8-win-10.0 scanner_value_type_tests: gcc-4.2.1 gcc-4.2.1_linux_x86_64 scanner_value_type_tests_debug: gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 |test| prg_exec_fail3: gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1 gcc-4.2.1_linux_x86_64 intel-linux-9.0 |thread| test_condition: gcc-4.2.1_linux_x86_64 test_condition_lib: gcc-4.2.1_linux_x86_64 test_once: gcc-4.2.1_linux_x86_64 test_shared_mutex: gcc-4.2.1_linux_x86_64 test_shared_mutex_lib: gcc-4.2.1_linux_x86_64 |tokenizer| simple_example_5: darwin-4.0.1 gcc-4.1.2_sunos_i86pc gcc-4.2.1 gcc-4.2.1_linux_x86_64 hp_cxx-71_006_tru64

1 0

non-template ostream_iterator?
by Andreas Harnack 25 Nov '07

25 Nov '07

Hi @, does anybody know why the ostream_iterator class has been mad a template if a template just for the assignment operator would have been sufficient? I.e., why does it say: template<class T> ostream_iterator { ... public: ostream_iterator& operator=(T const&); ... }; instead of ostream_iterator { ... public: template<class T> ostream_iterator& operator=(T const&); ... }; or possibly: template<class os=std::ostream> ostream_iterator { ... public: typedef typename os::char_type char_type; typedef typename os::traits_type traits_type; typedef os ostream_type; template<class T> ostream_iterator& operator=(T const&); ... }; In my compiler version (g++ 3.0 and g++ 3.4) the type T is used nowhere else. As a consequence I have to specify myContainer v; copy(v.begin(), v.end(), ostream_iterator<myContainer::value_type>(cout, "\n")); while it just could be: copy(v.begin(), v.end(), ostream_iterator(cout, "\n")); or copy(v.begin(), v.end(), ostream_iterator<>(cout, "\n")); The answer is obvious for istream_iterators: They provide their input values through the operator*() and have, giving the fact that it does not take any argument, no way to deduce the required return type, so it needs to be specified explicitly. That's different for ostream_iterators. They get their output values as arguments and are perfectly capable of deducing their type, so requiring it as an explicit template argument seems to be an unnecessary over-specification. One could argue, that the template argument adds to type safety, but that sound rather weak to me, especially if standard streams are involved. After all, std::cout and std::cerr are both global, so there's nothing at all to prevent me from printing to them from anywhere else in my application, even from a call implicitly made by function used in the expression above; let alone threads or other operating system processes. So, it seems to me, that the template argument does not provide any additional value but only makes the expression above unnecessary complicate. Am I missing something? Thanks, Andreas

3 3

Old Boost Bugs [ > 36 months ]
by Marshall Clow 25 Nov '07

25 Nov '07

There are several bugs in the Trac system that have been there since (at least) 2004. That makes them more than three years old. I really think that these should be dealt with (fixed, marked as obsolete, declared "wontFix") for 1.35. [ Note that I'm not talking about "Feature requests" or "Tasks", just "Bugs ] They are: #241 Miss " = ParserT()" spirit djowel 03/01/04 #283 Compiler error for tokenizer on Solaris tokenizer jbandela 06/20/04 #284 pool::purge_memory() does not reset next_size pool shammah 07/02/04 #287 wrong usage of ios_base::narrow date_time az_sw_dude 07/12/04 #290 perfomance: memory cleanup for pool takes too long pool shammah 07/21/04 #314 spirit insert_key_actor.hpp spirit djowel 11/03/04 #315 Implement operator[] for Tokenizer tokenizer jsiek 11/04/04 #316 date_time type conversion warning date_time az_sw_dude 11/19/04 I know that Stephen Cleary (pool) and John Bandela (tokenizer) don't seem to be around any more. I am volunteering to look at the pool bugs - can anyone look at the tokenizer bugs? And those maintainers who are still around (Jeff, Joel, Jeremy), please close these bugs? Thanks in advance! -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> Freedom isn't being able to do what you like, it's allowing someone else to do or say something you hate and supporting their right to do so.

3 4