- Boost - lists.boost.org

Fw: Is there interest for iterator based conversion library? attempt #2
by Alexander A Potocki 20 Jul '06

20 Jul '06

No comments during about 2 weeks. what's wrong? > Hi boost community! > > I would like to propose my iterator based conversion library. > It allows declaring and using transformations by following way: > > std::wstring utf16string(L”some sequence to convert”); > > typedef cvt::encoder<wchar_t, char> coder_t; > coder_t coder = cvt::utf16() >> cvt::utf8(); > > That piece of code declares converter from wchar_t to char sequences and > then instantiate such converter by utf16 to utf8 transformation. > > Then that converter instance can be used by following way: > typedef cvt::convert_input_iterator<coder_t, std::wstring::const_iterator > > it_t; > - declaration of input iterator > > std::string result; > std::copy( > it_t(coder, utf16string.begin(), utf16string.end()), > it_t(coder, utf16string.end(), utf16string.end()), > std::back_inserter(result) > ); > Now we have utf8 encoded string in result container. That’s all. > > Library contains implementation for following transformations/algorithms: > utf7, utf8, utf16(be/le), utf32(be, le), Unicode simple folding, base64, > rc5(cipher/decipher). > Library allows creating pipeline converters, e.g.: > > typedef cvt::encoder<char, char> coder_t; // char to char sequence > transformation > coder_t coder = cvt::utf7() >> cvt::utf16() >> cvt::utf8() / cvt::int8() > >> cvt::rc5<32,12,8>(key) / cvt::int8() >> cvt::base64(); > > That expression defines pipeline transformation. Utf7 encoded sequence > transforms to utf16 encoded sequence, then to utf8 encoded, then performs > rc5 cipher with specified key, then performs base64 encoding. > > Library can be found at http://sourceforge.net/projects/trotter-cvt/ > > > Alexander Potocki

2 1

[asio] Modified SSL client to reproduce error
by Scott 20 Jul '06

20 Jul '06

Chris, I took the existing SSL client.cpp code and added a thread to it. I removed the code to prompt the user for a string to send to the server and instead it will randomly pick one of 3 messages to constantly send them. In the 2nd thread, it basically does the same thing, but sends 1 of 3 different messages. Both threads are using the same socket. The first thread is using async IO to read and write the messages. The 2nd thread only sends synchronous messages at random intervals (the first thread picks up the responses from the 2nd thread's asio::write). This program fails rather quickly on Windows XP using MSVS 7.1. First off, did I program this correctly? If so, then I think it can be used to determine some of the SSL issues. :) Thanks, Scott

3 2

Boost.Build V2, Milestone 11 released
by Vladimir Prus 20 Jul '06

20 Jul '06

I'm pleased to announce that the next milestone release of Boost.Build V2 is available at http://prdownloads.sourceforge.net/boost/boost-build-2.0-m11.tar.bz2 http://prdownloads.sourceforge.net/boost/boost-build-2.0-m11.zip See also http://boost.org/boost-build2/ for online docs (a copy is included in distribution). Changes in this release: - New C++ compilers: IBM xlf, HP aCC, HP CXX, Intel fortran compiler. - New tools: Qt4 support, MS message compiler and IDL compiler. - New main targets: 'notfile' and 'cast'. - Core changes: - Only one file required at top level of a project, named Jamroot. - Jamfiles can now contain project-specific help messages. - "Indirect conditional requirements" introduced (http://tinyurl.com/mn3jp) - Strip suffix in main target names when computing names of generated files (URL) - The 'source-location' project attribute can contain several directories. - Usage requirements are propagated not only direct dependents, but to indirect dependents. - Command line option changes (see http://tinyurl.com/zbycz) - New option --build-dir - The --clean option cleans only target below the current directory, not globally. - New --clean-all option was added. - New option --debug-building - Running "bjam some_directory" works even if there's no Jamfile in the current directory. - Toolset improvements: - Assembling support with gcc, borland and msvc. - Support amd64/ia64 cross-compiling with msvc. - Improved, registry-based autodetection for msvc. - Serialize execution of gcc.link actions - Precompiled headers supported on MSVC (Need documentation) - New features <warnings> and <warnings-as-errors> - The 'glob' rule accepts wildcards in directory names. - The 'stage' rule was renamed to 'install' (the old name still available for compatibility) - The <tag> feature can accept user-defined function as value (URL) - The 'install' rule can install a directory hierarchy preserving relative paths. - The 'install' rule no longer allows to change library name during install. - The Jamfile referred via 'use-project' may declare project id different from the one in 'use-project'. - The 'using' rule now searches the directory of containing Jamfile. The following bugs were fixed: - The <library> feature was ignored for static linking - Fix #include scanning for C files. - Child projects were sometimes loaded before parent projects. - Fix project references with absolute paths on Windows. - The <dependency> feature was ignored for 'install' targets. - A generator having the same type in sources and targets was causing hang. - Use 'icpc' command for Intel, fixing errors with 8.1 and higher. - Generation of PS files with the FOP tool really produces .PS files. - No dependency scanning was done for C files. - The 'constant' and 'path-constant' rules did not accept multi-element value. - Don't pass -fcoalesce-templates to gcc on OSX 10.4 - Fix static lib suffix on OSX. - Fix rpath setting on Intel/Linux. - The 'install' rule don't unnecessary scans #includes in installed headers. Developer visible changes: - Ability to customize type's prefix depending on build properties. - Generator's 'run' method can return usage-requirements. - Main target rule is automatically declared for each new target type. - 'Link incompatible' feature attribute was removed - Generators no longer bypass unhandled sources, they just ignore them. - If there are several applicable generators, immediately report ambiguity. Provide a way to explicitly resolve conflicts between generators. - The 'flags' rule can match absense of feature. - Great improvement in response files handling - The 'toolset.flags' rules allows value-less feature to signify absense of this feature (fix hack-hack). - Automatically declare main target rule for each declared target type. - When inheriting types, inherit generators for the base type, as opposed to using various hacks to invoke base generators when needed. - Improve diagnostic for "duplicate actual target" and generator ambiguity. - Volodya -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2

1 0

Boost regression notification (2006-07-19 [RC_1_34_0])
by Douglas Gregor 19 Jul '06

19 Jul '06

Boost Regression test failures Report time: 2006-07-19T11:39:31Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 243 failures in 24 libraries algorithm/string (1) concept_check (1) filesystem (2) graph (6) integer (3) io (1) iostreams (39) mpl (7) numeric/conversion (4) numeric/interval (1) numeric/ublas (7) parameter (30) pool (3) program_options (9) python (25) random (1) rational (4) serialization (30) signals (16) spirit (2) test (2) tr1 (41) typeof (7) utility (1) |algorithm/string| regex: borland-5_6_4 |concept_check| class_concept_check_test: vc-7_1-stlport |filesystem| operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport |graph| adjacency_matrix_test: vc-7_0 bidir_remove_edge: vc-7_0 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport matching_test: msvc-8.0 |integer| integer_traits_test: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| array_test: vc-6_5 auto_close_test: vc-6_5 buffer_size_test: vc-6_5 bzip2_test: msvc-7.1 msvc-8.0 code_converter_test: vc-6_5 component_access_test: vc-6_5 compose_test: borland-5_6_4 vc-6_5 copy_test: vc-6_5 counter_test: vc-6_5 direct_adapter_test: vc-6_5 example_test: vc-6_5 vc-6_5-stlport file_descriptor_test: vc-6_5 file_test: vc-6_5 filtering_stream_test: vc-6_5 vc-7_1-stlport finite_state_filter_test: cw-9.4 flush_test: vc-6_5 gzip_test: msvc-7.1 msvc-8.0 invert_test: vc-6_5 line_filter_test: vc-6_5 mapped_file_test: vc-6_5 newline_test: vc-6_5 null_test: vc-6_5 pipeline_test: vc-6_5 positioning_test: vc-6_5 regex_filter_test: vc-6_5 restrict_test: vc-6_5 seekable_file_test: vc-6_5 seekable_filter_test: vc-6_5 stdio_filter_test: vc-6_5 symmetric_filter_test: vc-6_5 tee_test: vc-6_5 wide_stream_test: vc-6_5 zlib_test: msvc-7.1 msvc-8.0 |mpl| apply: gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc multiset: gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 |numeric/conversion| converter_test: borland-5_8_2 traits_test: borland-5_8_2 udt_example_0: borland-5_8_2 udt_support_test: borland-5_8_2 |numeric/interval| test_float: vc-7_1-stlport |numeric/ublas| concepts: vc-7_1-stlport vc-7_1-stlport test1: vc-7_1-stlport test2: vc-7_1-stlport test4: vc-7_1-stlport test5: vc-7_1-stlport vc-7_1-stlport |parameter| basics: borland-5_6_4 borland-5_8_2 duplicates: borland-5_6_4 borland-5_8_2 earwicker: borland-5_6_4 borland-5_8_2 macros: borland-5_6_4 borland-5_8_2 maybe: vc-6_5 vc-6_5-stlport vc-7_0 mpl: borland-5_6_4 borland-5_8_2 preprocessor: borland-5_6_4 borland-5_8_2 vc-6_5 vc-6_5-stlport python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 sfinae: borland-5_6_4 borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |pool| test_pool_alloc: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp |program_options| cmdline_test_dll: cw-9.4 options_description_test_dll: cw-9.4 parsers_test_dll: cw-9.4 positional_options_test_dll: cw-9.4 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test_dll: borland-5_8_2 cw-9.4 winmain_dll: cw-9.4 |python| bases: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux exec: cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp pointee: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux pointer_type_id_test: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux select_from_python_test: darwin-4.0.1 qcc-3.3.5_cpp qcc-3.3.5_gpp upcast: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_class_info_load_text_warchive: vc-6_5 test_codecvt_null: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_non_default_ctor2_text_archive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_reset_object_address: vc-7_0 test_reset_object_address_dll: vc-7_0 test_simple_class_binary_archive_dll: vc-6_5 test_simple_class_text_archive_dll: vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_utf8_codecvt: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 |signals| dead_slot_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp trackable_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |spirit| loops_tests_debug: msvc-8.0 scanner_value_type_tests: intel-linux-9.0 |test| parameterized_test_test: vc-6_5 vc-6_5-stlport |tr1| std_test_bind: darwin-4.0.1 std_test_ref_wrapper_tricky: borland-5_6_4 borland-5_8_2 darwin-4.0.1 gcc-3.4.3_sunos gcc-3.4.5_linux_x86_64 gcc-3_4_4_tru64 gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 msvc-7.1 msvc-8.0 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_gpp test_bind: darwin-4.0.1 test_boost: vc-7_1-stlport test_hash: vc-7_1-stlport test_random: vc-7_1-stlport test_ref_wrapper_tricky: borland-5_6_4 borland-5_8_2 darwin-4.0.1 gcc-3.4.3_sunos gcc-3.4.5_linux_x86_64 gcc-3_4_4_tru64 gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc hp_cxx-71_006_tru64 msvc-7.1 msvc-8.0 msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_gpp test_regex: vc-7_1-stlport tr1_has_trivial_destr_test: borland-5_6_4 tr1_has_virtual_destr_test: borland-5_6_4 tr1_tky_abstract_type_test: borland-5_6_4 tr1_tky_function_type_test: borland-5_6_4 tr1_tky_incomplete_type_test: borland-5_6_4 borland-5_8_2 tr1_tky_partial_spec_test: borland-5_6_4 |typeof| function_binding_native: vc-6_5 vc-6_5-stlport vc-7_0 nested_typedef_emulation: cw-9.4 odr_no_uns: vc-6_5 vc-6_5-stlport vc-7_0 |utility| operators_test: gcc-3.4.5_linux_x86_64

2 1

Re: [boost] boost::array support for runtime-sized arrays
by Sohail Somani 19 Jul '06

19 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Burns > Sent: Wednesday, July 19, 2006 12:56 PM > To: boost(a)lists.boost.org > Subject: [boost] boost::array support for runtime-sized arrays > > I realize you could simply use std::vector, but sometimes all > you want is a > fixed-size array (but sized at runtime). Besides, I am not > sure about the > overhead involved with std::vector for these simple scenarios. I doubt it would be much more if at all slower to use vector so long as you only allocate once.

2 1

Re: [boost] Exception Visitor
by Ames Andreas 19 Jul '06

19 Jul '06

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Andreas Huber > Sent: Tuesday, July 18, 2006 10:05 PM > Subject: Re: [boost] Exception Visitor > > // Untested code > #include <stdexcept> > > // Generic handler function > void HandleException() > { > try > { > throw; > } > catch (const std::logic_error &) > { > // whatever > } > catch (const std::exception &) > { > // whatever > } > } > > int main() > { > try > { > // throwing code > } > catch (...) > { > HandleException(); > } > > return 0; > } If you forget to handle a relevant exception in HandleException, is your debugger able to show you the 'right' backtrace (i.e. where the exception really occurred)? I don't think the op's idea has that problem. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya DOT com

3 2

Generic Trees
by Manfred Doudar 19 Jul '06

19 Jul '06

Hi all: Lately I've taken look at the available material re Boost SoC Generic Tree container, and find many parallels in what I am trying to attempt here at work (with seemingly one exception, see query below), and making good headway with a relatively robust and generic design (, though I'd hate to be reinventing the wheel). However, what I could not pick out is whether or not the proposed tree can or intends to support a node owning multiple parents(?) Apologies to all others for the noise, but I wasn't sure where else to post the question. Cheers, -- Manfred Doudar - Research Engineer National ICT Australia - Canberra Research Lab | www.nicta.com.au Research School of Information Sciences and Engineering (RSISE) The Australian National University - Canberra, ACT 0200 AUSTRALIA

8 11

Re: [boost] Is there a one-to-one map class in boost?
by Wang Weiwei 19 Jul '06

19 Jul '06

>Meanwhile you can have a look at the bidirectional map implementation using >B.MI here: > >http://www.boost.org/libs/multi_index/example/bimap.cpp > > SeskaPeel > yes, It's a nice stuff, even though a little bit complicated in syntax. Thanks. Max

1 0

Re: [boost] Please don't define a fake "operator <" justfor ordered containers
by Sohail Somani 19 Jul '06

19 Jul '06

> No. For pointers going into the same array segment > (including one-past-end) > or the same access-level class block, operator "<" is > defined. Using the > operator is unspecified if the pointers are from different spans. The > "std::less<T*>" specializations have to give the same results as the > operator when the operator is defined, but must give a total > ordering so > pointers from different spans (or NULL) can be compared. Due > to potential > exclusivities in comparison domains, it's possible that the > operator and the > class template use separate definitions. I must leave it in your capable hands to provide a summary and solution for this thread. It would be very interesting.

2 1

Release procedures
by Fernando Cacciola 19 Jul '06

19 Jul '06

Hi, I must be doing something wrong or I'm expecting something I shouldn't: (1) I updated from the trunk (HEAD) (2) Fixed a couple of things (3) Commited to the trunk (4) Updated from RC_1_34 (over the same working folder) (5) Merged "merged_from_RC_1_34" and "HEAD" into working folder. For step 5 I'm using ToroiseCVS 1.8.26 using the merge dialog as follow: Start: merged_from_RC_1_34 End: HEAD After that I get lots of updated, and even conflicted, files, way beside those which are mine. Is that expected? I figured I would get only my files merged. If it is, is it OK to just commit my files and not the others? What about the tag? TIA Fernando Cacciola

8 14