August 2005 - Boost - lists.preview.boost.org

missing stdio.h include in thread lib
by François Dumont 23 Aug '05

23 Aug '05

Hello I am submitting once again this patch for the thread library as the issue still exist with 1.33.0. When building boost with msvc-stlport toolset the _snprintf function used at read_write_mutex.cpp:151 is undefined as stdio.h has not been included next to tchar.h include at line 38. In order to have this patch apply this time I have study why _snprintf _is_ defined when using msvc toolset. The conclusion is that the definition comes from the <utility> include in boost/config/select_stdlib_config.hpp which is used to guess what is the std lib. In VC6 utility header include a lot of headers indirectly like cstring, cwchar, xstddef and cstdio which give _snprintf. The STLport utility try to limit the includes, maybe it shouldn't ;-) For your info I discovered an other issue, some guy from boost will have perhaps to work on it. I have only check it with VC6, don't know if it is reproductible with .NET 2002 or 2003. Even if you set your INCLUDE env variable to use the latest PSDK rather than the one integrated in VC6 you are still include of windows.h from boost during build process are still referencing the VC6 windows.h rather than the one of the latest SDK. I thought it was coming from the #include "windows.h" that exists in many VC6 headers but it is not the case. Bests *** read_write_mutex.cpp.orig Tue Aug 23 07:46:00 2005 --- read_write_mutex.cpp Tue Aug 23 19:02:08 2005 *************** *** 36,41 **** --- 36,42 ---- #ifdef BOOST_HAS_WINTHREADS # include <windows.h> # include <tchar.h> + # include <stdio.h> # if !((_WIN32_WINNT >= 0x0400) || (_WIN32_WINDOWS > 0x0400)) inline bool IsDebuggerPresent(void)

1 0

Boost regression notification (2005-08-23)
by Douglas Gregor 23 Aug '05

23 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-23T14:59:18Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 67 failures in 6 libraries: functional/hash (4) graph (14) parameter (4) python (22) serialization (22) wave (1) |functional/hash| point: borland-5_6_4 portable: msvc vc-6_5 vc-6_5-stlport |graph| cuthill_mckee_ordering: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dfs: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux vc-7_1 vc-7_1 vc-7_1 king_ordering: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: cw-8_3 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_4_3-sunos test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_derived_class_xml_warchive: vc-7_1 test_derived_class_xml_warchive_dll: vc-7_1 test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |wave| testwave: gcc-3.3.6-linux

1 0

boost dll versions
by Neal Becker 23 Aug '05

23 Aug '05

I think it is a bit unfortunate that we don't have a system to determine whether boost updates break existing api's. The usual process is that, for example, suppose we have libboost.so.1.33.0 Let's assign this soname libboost.so.1. Then a symlink is created libboost.so.1 -> libboost.so.1.33.0. Now if a bugfix comes out that does not change the api, be can have libboost.so.1.33.1, which also has soname libboost.so.1, and then symlink: libboost.so.1 -> libboost.so.1.33.1 OK, so that's the background. AFAICT, we (boost) don't have any way to tell if a new release breaks existing api, and whether to up the version. I think that is unfortunate. I don't really know what to do about it, though.

11 24

[Boost-bugs] [ boost-Bugs-1267229 ] Cannot compile on Sparc/NetBSD: redefinition of `struct
by SourceForge.net 23 Aug '05

23 Aug '05

Bugs item #1267229, was opened at 2005-08-23 17:51 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=1267229&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: Stephane Bortzmeyer (bortz) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot compile on Sparc/NetBSD: redefinition of `struct Initial Comment: I cannot compile Boost on my UltraSparc (64 bits) machine running NetBSD: ...found 4111 targets... ...updating 325 targets... gcc-C++-action /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/build/bin/boost/libs/dat e_time/build/libboost_date_time.so/gcc/release/shared-linkable-true/threading-multi/gr eg_month.o In file included from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/type_traits /intrinsics.hpp:39, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/type_traits /is_union.hpp:16, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/type_traits /is_class.hpp:14, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/detail/indi rect_traits.hpp:10, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/iterator/de tail/facade_iterator_category.hpp:27, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/iterator/it erator_facade.hpp:14, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/iterator/it erator_adaptor.hpp:15, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/token_itera tor.hpp:21, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/tokenizer.h pp:20, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/date_time/d ate_parsing.hpp:12, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/date_time/g regorian/parsers.hpp:13, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/boost/date_time/g regorian/greg_facet.hpp:14, from /usr/pkgsrc/devel/boost-libs/work/boost_1_33_0/libs/date_time/sr c/gregorian/greg_month.cpp:15: /usr/include/g++/type_traits.h:55: error: redefinition of `struct __true_type' /usr/include/g++/bits/type_traits.h:90: error: previous definition of `struct __true_type' /usr/include/g++/type_traits.h:58: error: redefinition of `struct __false_type' /usr/include/g++/bits/type_traits.h:91: error: previous definition of `struct __false_type' /usr/include/g++/type_traits.h:62: error: redefinition of `struct __type_traits<_Tp>' /usr/include/g++/bits/type_traits.h:94: error: previous definition of `struct __type_traits<_Tp>' /usr/include/g++/type_traits.h:96: error: redefinition of `struct __type_traits<bool>' /usr/include/g++/bits/type_traits.h:123: error: previous definition of `struct __type_traits<bool>' /usr/include/g++/type_traits.h:106: error: redefinition of `struct __type_traits<char>' NetBSD 2.0.1 gcc: % g++ -v Using built-in specs. Configured with: /home/nick/work/netbsd/src/tools/gcc/../../gnu/dist/gcc/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=i386-unknown-netbsdelf --host=sparc64--netbsd --target=sparc64--netbsd Thread model: posix gcc version 3.3.3 (NetBSD nb3 20040520) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1267229&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Issues with compile time double [metamath]
by Chris Weed 23 Aug '05

23 Aug '05

Hi, In order to use plus_double_double<a,b>::type I needed to make the following two changes to boost/metamath/double/detail/shift.hpp Change line 72 to: shift_integral_impl<shift_sign_overflow<Amount>::value>::template apply<T,Value,Amount> Change line 113 to: struct shift_mantissa : shift_mantissa_impl<shift_sign<Amount>::value>::template apply<Mantissa,Amount> I am using gcc 4.0 in debian. Chris

2 1

[regex] broken match_results functions for Intel 8.0
by Richard Hadsell 23 Aug '05

23 Aug '05

After upgrading to Boost 1.33.0 I found a problem with my code when built for Intel 8.0 on Linux. The problem doesn't show up with g++. I reduced it to a simple test case. With Intel 8.0 it compiles but fails to link the executable, complaining that it can't find the 'position' and 'str' functions. Note that it does find the 'length' function. I built the library with these options, and there were no errors: bjam -sTOOLS=intel-linux -sINTEL_PATH=/usr/local/intel/compiler80/ia32 --with-python-root=/usr --without-iostreams --without-python --without-serialization --stagedir=stage -sBUILD="debug release <threading>single" stage This copy of the console log documents the test case, working with g++ and failing to link with icpc: % cat RegexIntelLinuxBug.cc #include <iostream> #include <boost/regex.hpp> int main (int argc, const char * const *argv) { static const boost::regex pat ("[[:alpha:]]+"); const char str[] = "xyzzy"; boost::cmatch what; if (! boost::regex_search (str, what, pat)) std::cout << "not found" << std::endl; else { std::cout << "found '" << what.str () << "': " << what.length () << " characters at position " << what.position () << std::endl; } return 0; } % g++ -I/u/hadsell/cgi/Include/libboost -c -o RegexIntelLinuxBug.o RegexIntelLinuxBug.cc % g++ -o RegexIntelLinuxBug RegexIntelLinuxBug.o /u/hadsell/cgi/Lib/LINUX_X86FC3/libboostrgx.a % RegexIntelLinuxBug found 'xyzzy': 5 characters at position 0 % icpc -V Intel(R) C++ Compiler for 32-bit applications, Version 8.0 Build 20040304Z Package ID: l_cc_pc_8.0.058_pe061 Copyright (C) 1985-2004 Intel Corporation. All rights reserved. icpc: Command line error: no files specified; for help type "icpc -help" % icpc -I/u/hadsell/cgi/Include/libboost -c -o RegexIntelLinuxBug.o RegexIntelLinuxBug.cc % icpc -o RegexIntelLinuxBug RegexIntelLinuxBug.o /u/hadsell/cgi/Lib/LINUX_X86/libboostrgx.a RegexIntelLinuxBug.o(.text+0x1b1): In function `main': : undefined reference to `boost::match_results<char const*, std::allocator<boost::sub_match<char const*> > >::str(int) const' RegexIntelLinuxBug.o(.text+0x1fe): In function `main': : undefined reference to `boost::match_results<char const*, std::allocator<boost::sub_match<char const*> > >::position(unsigned) const' -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

3 6

[Boost-bugs] [ boost-Bugs-1266877 ] multitoken broken in program_options 1.33
by SourceForge.net 23 Aug '05

23 Aug '05

Bugs item #1266877, was opened at 2005-08-23 10:22 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=1266877&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: config Group: None Status: Open Resolution: None Priority: 5 Submitted By: Drazen Dotlic (rutavibaja) Assigned to: John Maddock (johnmaddock) Summary: multitoken broken in program_options 1.33 Initial Comment: Due to the changes in the parser, multitoken is broken in program_options [boost 1.33]. Looking at the code it is relatively clear why - the parser is too "greedy" and eats up all the options following the multitoken one without checking when to stop (for example, it should stop once it encounters another option/switch). If this functionality is to be deprecated as hinted in some mails on the mailing list, it should be removed from the public interface. If not, I guess it should be fixed :) The way to test it is to have a multitoken switch appear _in the middle_ of the command line (definitely not at the end) which should then simply eat all options to the right of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1266877&group_… ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Updated version history again
by Daryle Walker 22 Aug '05

22 Aug '05

Added notes for 1.10.3, the first numbered release, to "version_history.html". Should be in CVS and the web site. The CSS needs to be fixed. I attached a picture of how it looks on my system (Safari 2.0 on Mac OS X 10.4.2). The CSS neutralized my table's centering and made TH tags look the same as TD tags. I originally had the information as a DL list, but the CSS gave the DT and DD tags the same indentation amount, so that needs to be fixed too. Finally, there needs to be a gap between the last history item and the "...And the remainder are lost to the mists of time (for now, anyway)...." paragraph that is outside the history list. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Purpose adding a scope guard classes to the Boost library
by Andrey Semashev 22 Aug '05

22 Aug '05

Sometimes it is very useful to register some postponed actions regardless of some part of the program result (a function, for example). Smart pointers are obvious example of such actions (namely, freeing resources) and in fact are a special case of so called scope guards. Guards may be especially useful in heavilly-logical code with multiple (maybe folded into each other) checks or in code using exceptions. As a simple example, suppose we have a logging system that may trace function calls in our program. The easiest and obvious way to implement such functionality is to create some object in the beginning of each function to be traced. This object will add the function to the logger on its construction and remove it on destruction. Another application is resolving circular calling dependency issues which tend to come up in rather complex projects. The following example illustrates the problem: class A; // The objects of class B are managed by object of class A class B { public: void execute(A* pA, int n); }; // The object of main class A manages some other objects of class B class A { // Some internal data, which is provided to the managed objects std::set< int > m_Data; public: // The entrance method, called from somewhere outside void process(B* pB) { // Imagine we have some real processing here and m_Data is not empty pB->execute(this, *m_Data.begin()); // Here we cannot be absolutely sure if m_Data still contains the element we passed in line above } void remove(int n) { m_Data.erase(n); } }; void B::execute(A* pA, int n) { if (n > 10) pA->remove(n); } The case above is usually fixed by using some kind of state variables or flags or, in more complex cases, some stacks of postprocessing. I.e. in A::remove we don't actually erase the element but schedule some action to perform when control returns to A::process. This can easily be done by enqueued functors or scope guards. In some cases the latter are simplier to use and more laconic. I purpose to add a generalized scope guard classes to the Boost library. I have a rather simple but flexible implementation of such classes (I've attached the sources). Since I'm new here, I don't really know if they conform some source code conventions in Boost (if any), but if they don't - please, let me know. Few general words about the implementation. There are two general guard classes: leaving_scope_guard and scope_guard. The first one calls a functor (boost::function is used) with no arguments on its destruction if it is armed. The second class extends the first one by calling another functor on its construction (this is not a functionality of real necessity, but it allows to semantically group paired functions invocation, see the example above). A guard once created may be armed or disarmed later in thÕ program, but the armed status applies only to the destructing functor invoking (the constructing one is controlled via initial status of the guard which is passed in guard constructor arguments). The flexibility of implementation is in ability to change the functors invoking policy. In the simpliest case it is a direct invoking (all template parameters by default), but there is a policy with exception catching support. See the example: struct my_exception : public std::exception { /* ... */ }; void guarded_foo(int n, const char* p); // throws bad_cast, bad_alloc and my_exception // This is the class of the exception handler object struct CHandler { void on_exception(std::bad_cast& e) throw() { std::cout << "on_exception called, bad_cast caught" << std::endl; } void on_exception(std::bad_alloc& e) throw() { std::cout << "on_exception called, bad_alloc caught" << std::endl; } void on_exception(my_exception& e) throw() { std::cout << "on_exception called, my_exception caught" << std::endl; } }; void foo(int n) { leaving_scope_guard< guard::with_catcher< // Indicate that we're expecting some exceptions to be thrown by guarded_foo CHandler, // This is the class, which object is to process exceptions caught guard::exceptions< std::bad_cast, std::bad_alloc, my_exception >, // Exceptions to be caught (up to 10 exception types supported) boost::shared_ptr< CHandler > // An optional parameter describes the way the pointer to CHandler object should be stored. The default value would be CHandler*. > > guard(boost::bind(&guarded_foo, n, "called from foo"), boost::shared_ptr< CHandler >(new CHandler)); // Guard object // ... } There also are macroses defined for setting anonymous scope guards when there is no need for arming or disarming it. As for compatibility, I successfully compiled it on VC 7.1, ICC 9.0 and GCC 3.4.4 (MinGW version). I don 't think it will compile on VC 6 since explicit template function instantiation is used there which is not supported by the compiler, but I think it is possible to work around it. Besides that I don't think there should be any problems for other compilers. Any suggestions are welcome. begin 666 scope_guard.h M+RHA#0H@*B!<9FEL92 @('-C;W!E7V=U87)D+F@-"B J(%QA=71H;W(@4V5M M87-H978@06YD<F5Y#0H@*B!<9&%T92 @(#(U+C W+C(P,#4-"B J( T*("H@ M7&)R:65F("!'96YE<F%L:7IE9"!S8V]P92!G=6%R9"!D96-L87)A=&EO;@T* M("H@#0H@*B\-"@T*(VEF;F1E9B!?7U-#3U!%1U5!4D1?2%]?#0HC9&5F:6YE M(%]?4T-/4$5'54%21%](7U\-"@T*(VEN8VQU9&4@(F)O;W-T+V9U;F-T:6]N M+V9U;F-T:6]N,"YH<' B#0HC:6YC;'5D92 B8F]O<W0O;F]N8V]P>6%B;&4N M:'!P(@T*(VEN8VQU9&4@(F)O;W-T+W1Y<&5?=')A:71S+VES7V)A<V5?86YD M7V1E<FEV960N:'!P(@T*(VEN8VQU9&4@(F)O;W-T+W1Y<&5?=')A:71S+VES M7W!O:6YT97(N:'!P(@T*#0HO+R!-86-R;W-E<R!F;W(@9V5N97)A=&EN9R!R M96=U;&%R(&-O9&4-"B-D969I;F4@7U]30T]015]'54%21%]%3E5-15)!5$5? M34%#4D]?*&EM<&Q?;6%C<F\I7 T*"6EM<&Q?;6%C<F\H,2E<#0H):6UP;%]M M86-R;R@R*5P-"@EI;7!L7VUA8W)O*#,I7 T*"6EM<&Q?;6%C<F\H-"E<#0H) M:6UP;%]M86-R;R@U*5P-"@EI;7!L7VUA8W)O*#8I7 T*"6EM<&Q?;6%C<F\H M-RE<#0H):6UP;%]M86-R;R@X*5P-"@EI;7!L7VUA8W)O*#DI#0H-"B-D969I M;F4@7U]30T]015]'54%21%]%3E5-15)!5$5?34%#4D\H:6UP;%]M86-R;RE< M#0H):6UP;%]M86-R;R@P*5P-"@E?7U-#3U!%7T=505)$7T5.54U%4D%415]- M04-23U\H:6UP;%]M86-R;RD-"@T*(V1E9FEN92!?7U-#3U!%7T=505)$7TY5 M3$Q465!%4RAI=&5R*2!S=')U8W0@;G5L;'1Y<&4C(VET97(@.B!P=6)L:6,@ M;G5L;'1Y<&4@>WT[#0HC9&5F:6YE(%]?4T-/4$5?1U5!4D1?5$5-4$Q!5$5? M4$%204U3*&ET97(I("P@='EP96YA;64@17AC97!T:6]N5",C:71E7!E9&5F($5X8V5P=&EO;E0C(VET97(@97AC97!T M:6]N7W1Y<&4C(VET97([#0HC9&5F:6YE(%]?4T-/4$5?1U5!4D1?0T%40TA% M4RAI=&5R*5P-"@EC871C:" H='EP96YA;64@17AC97!T:6]N<TQI<W14.CIE M>&-E<'1I;VY?='EP92,C:71E&-E M<'1I;VY?='EP92,C:71E&-E<'1I;VY?:&%N9&QE<CP@97AC97!T:6]N<U]H86YD;&5R7W!O M:6YT97)?='EP92 ^*&U?<$AA;F1L97(L(&4I.UP-"@E]#0H-"FYA;65S<&%C M92!B;V]S="![#0H-"FYA;65S<&%C92!G=6%R9"![#0H-"B\O(2!%;G5M97)A M=&EO;B!O9B!S=&%T=7-E<R!O9B!G=6%R9 T*96YU;2!E;G5M4V-O<&5'=6%R M9%-T871U<R![#0H)87)M960@/2!F86QS92P-"@ED:7-A<FUE9" ]('1R=64- M"GT[#0H-"FYA;65S<&%C92!D971A:6P@>PT*#0H)+R\A($5M<'1Y('-T<G5C M='5R97,@9F]R(&EN9&EC871I;VX@;V8@='EP92!A8G-E;F-E#0H)<W1R=6-T M(&YU;&QT>7!E('M].PT*"5]?4T-/4$5?1U5!4D1?14Y53452051%7TU!0U)/ M7RA?7U-#3U!%7T=505)$7TY53$Q465!%4RD-"@T*"2\O(2!4:&ES(&-L87-S M(&1E=&5C=',@=&AE(&]P=&EM86P@<&%R86UE=&5R('1Y<&4@;V8@<&]I;G1E M<B!T;R!E>&-E<'1I;VX@:&%N9&QE<B!O8FIE8W0-"@ET96UP;&%T93P@='EP M96YA;64@5"P@8F]O;"!F4&]I;G1E7!E('L-"@D)='EP961E M9B!4(&-O;G-T)B!T>7!E.PT*"7T[#0H)=&5M<&QA=&4\('1Y<&5N86UE(%0@ M/@T*"7-T<G5C="!P;VEN=&5R7W1Y<&4\(%0L('1R=64@/B![#0H)"71Y<&5D M968@5"!T>7!E.PT*"7T[#0H-"@DO+R$@17AC97!T:6]N(&AA;F1L97(@:6YV M;VMI;F<@:&5L<&5R#0H)=&5M<&QA=&4\('1Y<&5N86UE(%0L(&)O;VP@9DYU M;&Q4>7!E(#T@8F]O<W0Z.FES7V)A<V5?86YD7V1E<FEV960\(&YU;&QT>7!E M+"!4(#XZ.G9A;'5E(#X-"@ES=')U8W0@1W5A<F1(96QP97(@>PT*"0ET96UP M;&%T93P@='EP96YA;64@52 ^#0H)"0ES=&%T:6,@:6YL:6YE('9O:60@:6YV M;VME7V5X8V5P=&EO;E]H86YD;&5R*'1Y<&5N86UE('!O:6YT97)?='EP93P@ M52 ^.CIT>7!E('!(86YD;&5R+"!4)B!E*2![#0H)"0DO+R!)9B!T:&4@9F]L M;&]W:6YG(&QI;F4@9F%I;',@=&\@8V]M<&EL92!T:&5N('1H97)E(&ES(&%N M(&5X8V5P=&EO;B!T>7!E+"!F;W(@=VAI8V@-"@D)"2\O(&]N7V5X8V5P=&EO M;B!F=6YC=&EO;B!I<R!N;W0@9&5F:6YE9"!I;B!E>&-E<'1I;VX@:&%N9&QE M<B!C;&%S<PT*"0D):68@*'!(86YD;&5R*2!P2&%N9&QE<BT^;VY?97AC97!T M:6]N*&4I.PT*"0E]#0H)?3L-"@ET96UP;&%T93P@='EP96YA;64@5" ^#0H) M<W1R=6-T($=U87)D2&5L<&5R/"!4+"!T<G5E(#X@>PT*"0ET96UP;&%T93P@ M='EP96YA;64@52 ^#0H)"7-T871I8R!I;FQI;F4@=F]I9"!I;G9O:V5?97AC M97!T:6]N7VAA;F1L97(H='EP96YA;64@<&]I;G1E<E]T>7!E/"!5(#XZ.G1Y M<&4L(%0F*2![#0H)"7T-"@E].PT*#0H)+R\A(%1H92!C;&%S<R!H;VQD<R!A M;F0@;6%N86=E<R!T:&4@<W1A='5S(&]F('1H92!G=6%R9 T*"6-L87-S('-C M;W!E7V=U87)D7W1R:6=G97(-"@E[#0H)<')O=&5C=&5D.@T*"0DO+R$@1W5A M<F0G<R!S=&%T=7,-"@D)96YU;5-C;W!E1W5A<F13=&%T=7,@;5]3=&%T=7,[ M#0H)<'5B;&EC.@T*"0ES8V]P95]G=6%R9%]T<FEG9V5R*&5N=6U38V]P94=U M87)D4W1A='5S(%-T871U<RD@.B!M7U-T871U<RA3=&%T=7,I('L-"@D)?0T* M"0EI;FQI;F4@=F]I9"!A<FTH*2![#0H)"0EM7U-T871U<R ](&%R;65D.PT* M"0E]#0H)"6EN;&EN92!V;VED(&1I<V%R;2@I('L-"@D)"6U?4W1A='5S(#T@ M9&ES87)M960[#0H)"7T-"@D):6YL:6YE(&5N=6U38V]P94=U87)D4W1A='5S M(&=E=%]S=&%T=7,H*2!C;VYS="![#0H)"0ER971U<FX@;5]3=&%T=7,[#0H) M"7T-"@E].PT*#0I]("\O(&YA;65S<&%C92!D971A:6P-"@T*+R\A($1I<F5C M="!F=6YC=&]R(&EN=F]K97(@8VQA<W,-"F-L87-S('-I;7!L95]I;G9O:V5R M('L-"G!R;W1E8W1E9#H-"@ET96UP;&%T93P@='EP96YA;64@1G5N8W1O<E0@ M/@T*"6EN;&EN92!V;VED(&9I<F4H1G5N8W1O<E0@8V]N<W0F($9U;F-T;W(I M(&-O;G-T('L-"@D)1G5N8W1O<B(a)I.PT*"7T-"GT[#0H-"B\O(2!#;&%S<R!F M;W(@96YU;65R871I;F<@97AC97!T:6]N('1Y<&5S#0IT96UP;&%T93P@='EP M96YA;64@17AC97!T:6]N5# @7U]30T]015]'54%21%]%3E5-15)!5$5?34%# M4D]?*%]?4T-/4$5?1U5!4D1?5$5-4$Q!5$5?4$%204U3*2 ^#0IS=')U8W0@ M97AC97!T:6]N<PT*>PT*"5]?4T-/4$5?1U5!4D1?14Y53452051%7TU!0U)/ M*%]?4T-/4$5?1U5!4D1?5%E0141%1E,I#0I].PT*#0HO+R$@17AC97!T:6]N M(&-A=&-H:6YG(&9U;F-T;W(@:6YV;VME<B!C;&%S<PT*=&5M<&QA=&4\(&-L M87-S($5(86YD;&5R5"P@8VQA<W,@17AC97!T:6]N<TQI<W14+"!T>7!E;F%M M92!%2&%N9&QE<E!T<E0@/2!%2&%N9&QE<E0J(#X-"F-L87-S('=I=&A?8V%T M8VAE&-E<'1I;VYS3&ES=%0-"GL-"G!U8FQI8SH-"@ET M>7!E9&5F($5(86YD;&5R5"!E>&-E<'1I;VYS7VAA;F1L97)?='EP93L-"@ET M>7!E9&5F($5(86YD;&5R4'1R5"!E>&-E<'1I;VYS7VAA;F1L97)?<&]I;G1E M<E]T>7!E.PT*#0IP<F]T96-T960Z#0H)97AC97!T:6]N<U]H86YD;&5R7W!O M:6YT97)?='EP92!M7W!(86YD;&5R.PT*#0IP=6)L:6,Z#0H)=VET:%]C871C M:&5R*"D@.B!M7W!(86YD;&5R*"D@>PT*"7T-"@EW:71H7V-A=&-H97(H='EP M96YA;64(a)9&5T86EL.CIP;VEN=&5R7W1Y<&4\(&5X8V5P=&EO;G-?:&%N9&QE M<E]P;VEN=&5R7W1Y<&4@/CHZ='EP92!P2&%N9&QE<BD@.B!M7W!(86YD;&5R M*'!(86YD;&5R*2![#0H)?0T*#0IP<F]T96-T960Z#0H)=&5M<&QA=&4\('1Y M<&5N86UE($9U;F-T;W)4(#X-"@EI;FQI;F4@=F]I9"!F:7)E*$9U;F-T;W)4 M(&-O;G-T)B!&=6YC=&]R*2!C;VYS="![#0H)"71R>2![#0H)"0E&=6YC=&]R M*"D[#0H)"7T@7U]30T]015]'54%21%]%3E5-15)!5$5?34%#4D\H7U]30T]0 M15]'54%21%]#051#2$53*3L-"@E]#0I].PT*#0I]("\O(&YA;65S<&%C92!G M=6%R9 T*#0HO+R$@1&5S=')U8W1I;F<@<V-O<&4@9W5A<F0@8VQA<W,-"G1E M;7!L871E/"!C;&%S<R!);G9O:V5R5" ](&=U87)D.CIS:6UP;&5?:6YV;VME MPT*<')O=&5C=&5D.@T* M"71Y<&5D968@9W5A<F0Z.F1E=&%I;#HZ<V-O<&5?9W5A<F1?=')I9V=E<B!T M<FEG9V5R7W1Y<&4[#0H-"G!U8FQI8SH-"@ET>7!E9&5F($EN=F]K97)4(&EN M=F]K97)?='EP93L-"@ET>7!E9&5F(&9U;F-T:6]N,#P@=F]I9" ^(&9U;F-T M;W)?='EP93L-"@T*<')O=&5C=&5D.@T*"69U;F-T;W)?='EP92!M7TQE879I M;F=&=6YC=&]R.PT*#0IP<FEV871E.@T*"6QE879I;F=?<V-O<&5?9W5A<F0H M*3L-"@T*<'5B;&EC.@T*"6QE879I;F=?<V-O<&5?9W5A<F0H9G5N8W1O<E]T M>7!E(&-O;G-T)B!,96%V:6YG1G5N8W1O<BP@:6YV;VME<E]T>7!E(&-O;G-T M)B!);G9O:V5R(#T@:6YV;VME<E]T>7!E*"DL(&=U87)D.CIE;G5M4V-O<&5' M=6%R9%-T871U<R!3=&%T=7,@/2!G=6%R9#HZ87)M960I#0H)"3H@=')I9V=E M<E]T>7!E*%-T871U<RDL(&EN=F]K97)?='EP92A);G9O:V5R*2P@;5],96%V M:6YG1G5N8W1O<BA,96%V:6YG1G5N8W1O<BD-"@E[#0H)?0T*"6QE879I;F=? M<V-O<&5?9W5A<F0H9G5N8W1O<E]T>7!E(&-O;G-T)B!,96%V:6YG1G5N8W1O M<BP@9W5A<F0Z.F5N=6U38V]P94=U87)D4W1A='5S(%-T871U<RP@:6YV;VME M<E]T>7!E(&-O;G-T)B!);G9O:V5R(#T@:6YV;VME<E]T>7!E*"DI#0H)"3H@ M=')I9V=E<E]T>7!E*%-T871U<RDL(&EN=F]K97)?='EP92A);G9O:V5R*2P@ M;5],96%V:6YG1G5N8W1O<BA,96%V:6YG1G5N8W1O<BD-"@E[#0H)?0T*"7YL M96%V:6YG7W-C;W!E7V=U87)D*"D@>PT*"0EI9B H*"AC:&%R*71R:6=G97)? M='EP93HZ9V5T7W-T871U<R@I('P@*&-H87(I=&AI<RT^;5],96%V:6YG1G5N M8W1O<BYE;7!T>2@I*2 ]/2 P*0T*"0D)=&AI<RT^9FER95]L96%V:6YG7V9U M;B(a)I.PT*"7T-"@DO+R$@5&AE(&UE=&AO9"!E>'!L:6-I=&QY(&-A;&QS('1H M92!L96%V:6YG(&9U;F-T;W(-"@EI;FQI;F4@=F]I9"!F:7)E7VQE879I;F=? M9G5N*"D@8V]N<W0@>PT*"0EI;G9O:V5R7W1Y<&4Z.F9I<F4H=&AI<RT^;5], M96%V:6YG1G5N8W1O<BD[#0H)?0T*"2\O(2!4:&4@;65T:&]D(')E9&5F:6YE M<R!T:&4@;&5A=FEN9R!F=6YC=&]R#0H):6YL:6YE('9O:60@87-S:6=N7VQE M879I;F=?9G5N*&9U;F-T;W)?='EP92!C;VYS="8@1G5N8W1O<BD@>PT*"0ET M:&ES+3YM7TQE879I;F=&=6YC=&]R(#T@1G5N8W1O<CL-"@E]#0I].PT*#0HO M+R$@0V]N<W1R=6-T:6YG(&%N9"!D97-T<G5C=&EN9R!S8V]P92!G=6%R9"!C M;&%S<PT*=&5M<&QA=&4\(&-L87-S($EN=F]K97)4(#T@9W5A<F0Z.G-I;7!L M95]I;G9O:V5R(#X-"F-L87-S('-C;W!E7V=U87)D(#H@<'5B;&EC(&QE879I M;F=?<V-O<&5?9W5A<F0\($EN=F]K97)4(#X-"GL-"G!R:79A=&4Z#0H)='EP M961E9B!L96%V:6YG7W-C;W!E7V=U87)D/"!);G9O:V5R5" ^(&)A<V5?='EP M93L-"@T*<')O=&5C=&5D.@T*"71Y<&5D968@='EP96YA;64@8F%S95]T>7!E M.CIT<FEG9V5R7W1Y<&4@=')I9V=E<E]T>7!E.PT*#0IP=6)L:6,Z#0H)='EP M961E9B!T>7!E;F%M92!B87-E7W1Y<&4Z.FEN=F]K97)?='EP92!I;G9O:V5R M7W1Y<&4[#0H)='EP961E9B!T>7!E;F%M92!B87-E7W1Y<&4Z.F9U;F-T;W)? M='EP92!F=6YC=&]R7W1Y<&4[#0H-"G!R;W1E8W1E9#H-"@EF=6YC=&]R7W1Y M<&4@;5]%;G1E<FEN9T9U;F-T;W([#0H-"G!R:79A=&4Z#0H)<V-O<&5?9W5A M<F0H*3L-"@T*<'5B;&EC.@T*"7-C;W!E7V=U87)D* T*"0EF=6YC=&]R7W1Y M<&4@8V]N<W0F($5N=&5R:6YG1G5N8W1O<BP-"@D)9G5N8W1O<E]T>7!E(&-O M;G-T)B!,96%V:6YG1G5N8W1O<BP-"@D):6YV;VME<E]T>7!E(&-O;G-T)B!) M;G9O:V5R(#T@:6YV;VME<E]T>7!E*"DL#0H)"6=U87)D.CIE;G5M4V-O<&5' M=6%R9%-T871U<R!3=&%T=7,@/2!G=6%R9#HZ87)M960-"@DI(#H@8F%S95]T M>7!E*$QE879I;F=&=6YC=&]R+"!);G9O:V5R+"!3=&%T=7,I+"!M7T5N=&5R M:6YG1G5N8W1O<BA%;G1E<FEN9T9U;F-T;W(I#0H)>PT*"0EI9B H*"AC:&%R M*71R:6=G97)?='EP93HZ9V5T7W-T871U<R@I('P@*&-H87(I=&AI<RT^;5]% M;G1E<FEN9T9U;F-T;W(N96UP='DH*2D@/3T@,"D-"@D)"71H:7,M/F9I<F5? M96YT97)I;F=?9G5N*"D[#0H)?0T*"7-C;W!E7V=U87)D* T*"0EF=6YC=&]R M7W1Y<&4@8V]N<W0F($5N=&5R:6YG1G5N8W1O<BP-"@D)9G5N8W1O<E]T>7!E M(&-O;G-T)B!,96%V:6YG1G5N8W1O<BP-"@D)9W5A<F0Z.F5N=6U38V]P94=U M87)D4W1A='5S(%-T871U<RP-"@D):6YV;VME<E]T>7!E(&-O;G-T)B!);G9O M:V5R(#T@:6YV;VME<E]T>7!E*"D-"@DI(#H@8F%S95]T>7!E*$QE879I;F=& M=6YC=&]R+"!);G9O:V5R+"!3=&%T=7,I+"!M7T5N=&5R:6YG1G5N8W1O<BA% M;G1E<FEN9T9U;F-T;W(I#0H)>PT*"0EI9B H*"AC:&%R*71R:6=G97)?='EP M93HZ9V5T7W-T871U<R@I('P@*&-H87(I=&AI<RT^;5]%;G1E<FEN9T9U;F-T M;W(N96UP='DH*2D@/3T@,"D-"@D)"71H:7,M/F9I<F5?96YT97)I;F=?9G5N M*"D[#0H)?0T*"2\O(2!4:&4@;65T:&]D(&5X<&QI8VET;'D@8V%L;',@=&AE M(&5N=&5R:6YG(&9U;F-T;W(-"@EI;FQI;F4@=F]I9"!F:7)E7V5N=&5R:6YG M7V9U;B@I(&-O;G-T('L-"@D):6YV;VME<E]T>7!E.CIF:7)E*'1H:7,M/FU? M16YT97)I;F=&=6YC=&]R*3L-"@E]#0H)+R\A(%1H92!M971H;V0@<F5D969I M;F5S('1H92!E;G1E<FEN9R!F=6YC=&]R#0H):6YL:6YE('9O:60@87-S:6=N M7V5N=&5R:6YG7V9U;BAF=6YC=&]R7W1Y<&4@8V]N<W0F($9U;F-T;W(I('L- M"@D)=&AI<RT^;5]%;G1E<FEN9T9U;F-T;W((a)/2!&=6YC=&]R.PT*"7T-"GT[ M#0H-"GT@+R\@;F%M97-P86-E(&)O;W-T#0H-"@T*+R\@36%C<F]S97,@9F]R M('-E='1I;F<@=7 @86YO;GEM;W5S('-C;W!E(&=U87)D<PT*#0HC9&5F:6YE M(%]?4T-/4$5?1U5!4D1?3D%-15\H<')E9FEX+"!P;W-T9FEX*2!P<F5F:7@C M(W!O<W1F:7@-"B-D969I;F4@7U]30T]015]'54%21%].04U%*'!R969I>"P@ M<&]S=&9I>"D@7U]30T]015]'54%21%].04U%7RAP<F5F:7@L('!O<W1F:7@I M#0H-"B\O($EN(%9#('=H96X@8V]M<&EL:6YG('=I=&@@+UI)(&]P=&EO;B!? M7TQ)3D5?7R!M86-R;R!I<R!C;W)R=7!T960-"B-I9B!D969I;F5D*%]-4T-? M5D52*2 F)B!?35-#7U9%4B ^/2 Q,S P#0H-"B-D969I;F4(a)3$5!5DE.1U]3 M0T]015]'54%21"AF=6YC=&]R*2!<#0H)8F]O<W0Z.FQE879I;F=?<V-O<&5? M9W5A<F0\(#X@7U]30T]015]'54%21%].04U%*%]G=6%R9%\L(%]?0T]53E1% M4E]?*2 H9G5N8W1O<BD[#0HC9&5F:6YE($Q%059)3D=?4T-/4$5?1U5!4D1? M15@H9G5N8W1O<BP@97AC7W1Y<&5?;&ES="P@97AC7VEF86-E+"!H86YD;&5R M*2!<#0H)8F]O<W0Z.FQE879I;F=?<V-O<&5?9W5A<F0\(&)O;W-T.CIG=6%R M9#HZ=VET:%]C871C:&5R/"!E>&-?:69A8V4L(&)O;W-T.CIG=6%R9#HZ97AC M97!T:6]N<SP@97AC7W1Y<&5?;&ES=" ^(#X@/B!?7U-#3U!%7T=505)$7TY! M344H7V=U87)D7V5X7RP(a)7U]#3U5.5$527U\I("AF=6YC=&]R+"!H86YD;&5R M*3L-"@T*(V1E9FEN92!30T]015]'54%21"AE;G1E<E]F=6YC=&]R+"!L96%V M95]F=6YC=&]R*2!<#0H)8F]O<W0Z.G-C;W!E7V=U87)D/" ^(%]?4T-/4$5? M1U5!4D1?3D%-12A?9W5A<F1?+"!?7T-/54Y415)?7RD@*&5N=&5R7V9U;F-T M;W(L(&QE879E7V9U;F-T;W(I.PT*(V1E9FEN92!30T]015]'54%21%]%6"AE M;G1E<E]F=6YC=&]R+"!L96%V95]F=6YC=&]R+"!E>&-?='EP95]L:7-T+"!E M>&-?:69A8V4L(&AA;F1L97(I(%P-"@EB;V]S=#HZ;&5A=FEN9U]S8V]P95]G M=6%R9#P@8F]O<W0Z.F=U87)D.CIW:71H7V-A=&-H97(\(&5X8U]I9F%C92P@ M8F]O<W0Z.F=U87)D.CIE>&-E<'1I;VYS/"!E>&-?='EP95]L:7-T(#X@/B ^ M(%]?4T-/4$5?1U5!4D1?3D%-12A?9W5A<F1?97A?+"!?7T-/54Y415)?7RD@ M*&5N=&5R7V9U;F-T;W(L(&QE879E7V9U;F-T;W(L(&AA;F1L97(I.PT*#0HC M96QS90T*#0HC9&5F:6YE($Q%059)3D=?4T-/4$5?1U5!4D0H9G5N8W1O<BD@ M7 T*"6)O;W-T.CIL96%V:6YG7W-C;W!E7V=U87)D/" ^(%]?4T-/4$5?1U5! M4D1?3D%-12A?9W5A<F1?+"!?7TQ)3D5?7RD(a)*&9U;F-T;W(I.PT*(V1E9FEN M92!,14%624Y'7U-#3U!%7T=505)$7T58*&9U;F-T;W(L(&5X8U]T>7!E7VQI M<W0L(&5X8U]I9F%C92P@:&%N9&QE<BD@7 T*"6)O;W-T.CIL96%V:6YG7W-C M;W!E7V=U87)D/"!B;V]S=#HZ9W5A<F0Z.G=I=&A?8V%T8VAE<CP@97AC7VEF M86-E+"!B;V]S=#HZ9W5A<F0Z.F5X8V5P=&EO;G,\(&5X8U]T>7!E7VQI<W0@ M/B ^(#X@7U]30T]015]'54%21%].04U%*%]G=6%R9%]E>%\L(%]?3$E.15]? M*2 H9G5N8W1O<BP@:&%N9&QE<BD[#0H-"B-D969I;F4@4T-/4$5?1U5!4D0H M96YT97)?9G5N8W1O<BP@;&5A=F5?9G5N8W1O<BD@7 T*"6)O;W-T.CIS8V]P M95]G=6%R9#P@/B!?7U-#3U!%7T=505)$7TY!344H7V=U87)D7RP@7U],24Y% M7U\I("AE;G1E<E]F=6YC=&]R+"!L96%V95]F=6YC=&]R*3L-"B-D969I;F4@ M4T-/4$5?1U5!4D1?15@H96YT97)?9G5N8W1O<BP@;&5A=F5?9G5N8W1O<BP@ M97AC7W1Y<&5?;&ES="P@97AC7VEF86-E+"!H86YD;&5R*2!<#0H)8F]O<W0Z M.FQE879I;F=?<V-O<&5?9W5A<F0\(&)O;W-T.CIG=6%R9#HZ=VET:%]C871C M:&5R/"!E>&-?:69A8V4L(&)O;W-T.CIG=6%R9#HZ97AC97!T:6]N<SP@97AC M7W1Y<&5?;&ES=" ^(#X@/B!?7U-#3U!%7T=505)$7TY!344H7V=U87)D7V5X M7RP@7U],24Y%7U\I("AE;G1E<E]F=6YC=&]R+"!L96%V95]F=6YC=&]R+"!H M86YD;&5R*3L-"@T*(V5N9&EF("\O(&1E9FEN960H7TU30U]615(I("8F(%]- M4T-?5D52(#X](#$S,# -"@T*(V1E9FEN92!30T]015]'54%21%]%6$-%4%1) M3TY37S$H97AC97!T:6]N7W1Y<&4P*2!E>&-E<'1I;VY?='EP93 -"B-D969I M;F4(a)4T-/4$5?1U5!4D1?15A#15!424].4U\R*&5X8V5P=&EO;E]T>7!E,"P@ M97AC97!T:6]N7W1Y<&4Q*5P-"@E30T]015]'54%21%]%6$-%4%1)3TY37S$H M97AC97!T:6]N7W1Y<&4P*2P@97AC97!T:6]N7W1Y<&4Q#0HC9&5F:6YE(%-# M3U!%7T=505)$7T580T505$E/3E-?,RAE>&-E<'1I;VY?='EP93 L(&5X8V5P M=&EO;E]T>7!E,2P@97AC97!T:6]N7W1Y<&4R*5P-"@E30T]015]'54%21%]% M6$-%4%1)3TY37S(H97AC97!T:6]N7W1Y<&4P+"!E>&-E<'1I;VY?='EP93$I M+"!E>&-E<'1I;VY?='EP93(-"B-D969I;F4@4T-/4$5?1U5!4D1?15A#15!4 M24].4U\T*&5X8V5P=&EO;E]T>7!E,"P@97AC97!T:6]N7W1Y<&4Q+"!E>&-E M<'1I;VY?='EP93(L(&5X8V5P=&EO;E]T>7!E,RE<#0H)4T-/4$5?1U5!4D1? M15A#15!424].4U\S*&5X8V5P=&EO;E]T>7!E,"P@97AC97!T:6]N7W1Y<&4Q M+"!E>&-E<'1I;VY?='EP93(I+"!E>&-E<'1I;VY?='EP93,-"B-D969I;F4@ M4T-/4$5?1U5!4D1?15A#15!424].4U\U*&5X8V5P=&EO;E]T>7!E,"P@97AC M97!T:6]N7W1Y<&4Q+"!E>&-E<'1I;VY?='EP93(L(&5X8V5P=&EO;E]T>7!E M,RP@97AC97!T:6]N7W1Y<&4T*5P-"@E30T]015]'54%21%]%6$-%4%1)3TY3 M7S0H97AC97!T:6]N7W1Y<&4P+"!E>&-E<'1I;VY?='EP93$L(&5X8V5P=&EO M;E]T>7!E,BP@97AC97!T:6]N7W1Y<&4S*2P@97AC97!T:6]N7W1Y<&4T#0HC M9&5F:6YE(%-#3U!%7T=505)$7T580T505$E/3E-?-BAE>&-E<'1I;VY?='EP M93 L(&5X8V5P=&EO;E]T>7!E,2P@97AC97!T:6]N7W1Y<&4R+"!E>&-E<'1I M;VY?='EP93,L(&5X8V5P=&EO;E]T>7!E-"P@97AC97!T:6]N7W1Y<&4U*5P- M"@E30T]015]'54%21%]%6$-%4%1)3TY37S4H97AC97!T:6]N7W1Y<&4P+"!E M>&-E<'1I;VY?='EP93$L(&5X8V5P=&EO;E]T>7!E,BP@97AC97!T:6]N7W1Y M<&4S+"!E>&-E<'1I;VY?='EP930I+"!E>&-E<'1I;VY?='EP934-"B-D969I M;F4(a)4T-/4$5?1U5!4D1?15A#15!424].4U\W*&5X8V5P=&EO;E]T>7!E,"P@ M97AC97!T:6]N7W1Y<&4Q+"!E>&-E<'1I;VY?='EP93(L(&5X8V5P=&EO;E]T M>7!E,RP@97AC97!T:6]N7W1Y<&4T+"!E>&-E<'1I;VY?='EP934L(&5X8V5P M=&EO;E]T>7!E-BE<#0H)4T-/4$5?1U5!4D1?15A#15!424].4U\V*&5X8V5P M=&EO;E]T>7!E,"P@97AC97!T:6]N7W1Y<&4Q+"!E>&-E<'1I;VY?='EP93(L M(&5X8V5P=&EO;E]T>7!E,RP@97AC97!T:6]N7W1Y<&4T+"!E>&-E<'1I;VY? M='EP934I+"!E>&-E<'1I;VY?='EP938-"B-D969I;F4@4T-/4$5?1U5!4D1? M15A#15!424].4U\X*&5X8V5P=&EO;E]T>7!E,"P@97AC97!T:6]N7W1Y<&4Q M+"!E>&-E<'1I;VY?='EP93(L(&5X8V5P=&EO;E]T>7!E,RP@97AC97!T:6]N M7W1Y<&4T+"!E>&-E<'1I;VY?='EP934L(&5X8V5P=&EO;E]T>7!E-BP@97AC M97!T:6]N7W1Y<&4W*5P-"@E30T]015]'54%21%]%6$-%4%1)3TY37S<H97AC M97!T:6]N7W1Y<&4P+"!E>&-E<'1I;VY?='EP93$L(&5X8V5P=&EO;E]T>7!E M,BP@97AC97!T:6]N7W1Y<&4S+"!E>&-E<'1I;VY?='EP930L(&5X8V5P=&EO M;E]T>7!E-2P@97AC97!T:6]N7W1Y<&4V*2P@97AC97!T:6]N7W1Y<&4W#0HC M9&5F:6YE(%-#3U!%7T=505)$7T580T505$E/3E-?.2AE>&-E<'1I;VY?='EP M93 L(&5X8V5P=&EO;E]T>7!E,2P@97AC97!T:6]N7W1Y<&4R+"!E>&-E<'1I M;VY?='EP93,L(&5X8V5P=&EO;E]T>7!E-"P@97AC97!T:6]N7W1Y<&4U+"!E M>&-E<'1I;VY?='EP938L(&5X8V5P=&EO;E]T>7!E-RP@97AC97!T:6]N7W1Y M<&4X*5P-"@E30T]015]'54%21%]%6$-%4%1)3TY37S@H97AC97!T:6]N7W1Y M<&4P+"!E>&-E<'1I;VY?='EP93$L(&5X8V5P=&EO;E]T>7!E,BP@97AC97!T M:6]N7W1Y<&4S+"!E>&-E<'1I;VY?='EP930L(&5X8V5P=&EO;E]T>7!E-2P@ M97AC97!T:6]N7W1Y<&4V+"!E>&-E<'1I;VY?='EP93<I+"!E>&-E<'1I;VY? M='EP93@-"B-D969I;F4(a)4T-/4$5?1U5!4D1?15A#15!424].4U\Q,"AE>&-E M<'1I;VY?='EP93 L(&5X8V5P=&EO;E]T>7!E,2P@97AC97!T:6]N7W1Y<&4R M+"!E>&-E<'1I;VY?='EP93,L(&5X8V5P=&EO;E]T>7!E-"P@97AC97!T:6]N M7W1Y<&4U+"!E>&-E<'1I;VY?='EP938L(&5X8V5P=&EO;E]T>7!E-RP@97AC M97!T:6]N7W1Y<&4X+"!E>&-E<'1I;VY?='EP93DI7 T*"5-#3U!%7T=505)$ M7T580T505$E/3E-?.2AE>&-E<'1I;VY?='EP93 L(&5X8V5P=&EO;E]T>7!E M,2P@97AC97!T:6]N7W1Y<&4R+"!E>&-E<'1I;VY?='EP93,L(&5X8V5P=&EO M;E]T>7!E-"P@97AC97!T:6]N7W1Y<&4U+"!E>&-E<'1I;VY?='EP938L(&5X M8V5P=&EO;E]T>7!E-RP@97AC97!T:6]N7W1Y<&4X*2P@97AC97!T:6]N7W1Y M<&4Y#0H-"B\O($-L96%N:6YG('5P(&UA8W)O<V5S#0HC=6YD968@7U]30T]0 M15]'54%21%]#051#2$53#0HC=6YD968@7U]30T]015]'54%21%]465!%1$5& M4PT*(W5N9&5F(%]?4T-/4$5?1U5!4D1?5$5-4$Q!5$5?4$%204U3#0HC=6YD M968@7U]30T]015]'54%21%].54Q,5%E015,-"B-U;F1E9B!?7U-#3U!%7T=5 M05)$7T5.54U%4D%415]-04-23PT*(W5N9&5F(%]?4T-/4$5?1U5!4D1?14Y5 M3452051%7TU!0U)/7PT*#0HC96YD:68@+R\@7U]30T]014=505)$7TA?7PT* ` end

3 5

Re: [boost] asio networking proposal
by Dave Gomboc 22 Aug '05

22 Aug '05

> - Consistency with a future asynchronous version of the same function. > As a rule, in async versions of the functions complex structures or > buffers need to be passed as arguments, andthe only difference between > the sync and async functions is the callback handler, i.e.: > > void operation(parameters); > > template <typename Handler> > void async_operation(parameters, Handler handler); Treating synchronous and asynchronous differently here seems less generic than always using template <typename Handler> void operation(parameters, Handler handler); Would it be bad to do it this way (possibly with a synchronous handler defaulted?) > Yes, I agree that read and write are better, because of the > "portability" of the names to non-sockets that it gives. I've wanted to > make that change for some time, but the thing that has been preventing > me is what to call the datagram functions sendto and recvfrom, as > writeto and readfrom don't seem quite right. Any suggestions? I don't perceive what's wrong with "write_to" and "read_from". Dave P.S. I saw in another Boost posting a poster using email address sid(a)6581.com. It's nice to see that there's other C=64 oldtimers out there! ;-)

3 2

[range] extension proposal - construct
by Pavol Droba 22 Aug '05

22 Aug '05

Hi, I have a proposal for addition to Boost.Range library: template<typename RangeT, typename OtherRangeT> RangeT construct<RangeT>(const OtherRangeT& Source); template<typename RangeT, typename IteratorT> RangeT construct<RangeT>(IteratorT From, IteratorT To); Both functions should construct a range of type RangeT, that will contain elements from Source or [From,To) respectively. Motivation: In the standard library Sequence concept defines a way for constructing a sequence from and arbitrary range of iterators. This is very useful concept and it would be nice to have something similar available in the Range library. Most significant advantage of this construct is that it allows to create algorithms, that modify an input range and return a copy of it. Currently there is no generic way for constructing or modifying a range, therefor it restricts the usage of range to non-mutable input parameters. For instance a simple to_lower algorithm (available in StringAlgo library) template<typename SequenceT> SequenceT to_lower_copy(const SequenceT& Input, const std::locale& Loc=std::locale()); requires the input to satisfy sequence requirements so it can construct the result. This effectively disables many advantages of Range library. Because it is not possible to adapt an external class (like CString) to work with this algorithm. Yes it could be very easy to implement construction for this class. There is already a similar function in the range library. It's called copy<> but, this function is provided solely for sequences and there is no feasible and documented way for customization. Best Regards, Pavol

3 3

logging v1.4 - some comments
by Darryl Green 22 Aug '05

22 Aug '05

Excuse the break in threading - gmane has lost/missed a lot of boost traffic. Hi John, I've only had a quick look at the latest version: The m_destroyed hack needs to go - this should only be relevant for static (not scoped) logs and the real issue is that you need to do thread-safe singletons - ie. you need to use posix call_once or equivalent to contstruct the thing. Destruction is a bit tricky - not doing it seems a reasonable option, though stopping leak detectors from compaining would be nice. The scoped log stuff doesn't seem to have been updated to support levels yet - in fact I'm not sure if it currently works? I think (fancy that - given the way it was in analog ;-)) that the named appenders need to be managed - currently, you can create multiple appenders with the same name, then when you delete by name you delete all appenders with that name. I don't see the utility of that model, which when combined with the wildcard matching is really fairly hard to use. For example, suppose I have an appender that logs to some sort of display for "real time" tracing. First off, I say: manipulate_logs("error.*").add_appender(displaywrite, "display") Then I notice an error about some component foo and decide to look at more detail about foo: manipulate_logs("*.foo").add_appender(displaywrite, "display") Now I get anything logged to "error.foo" written to "display" twice. I then say: manipulate_logs("error.*").del_appender("display") Because I want to concentrate on "foo" only. Now I find I don't get errors from foo displayed, only other less critical messaages. Then, foo goes out of scope (it's a scoped log), only to come back into scope again. When it does, and it generates an error, I'm (not really) suprised to see it sent to "display".... As the purpose of named appenders is to facilitate runtime modification of the appender set, surely the ability to make these modifications using *only* the name is reasonable. The fact that add requires a function while del only needs a name only highlights this. Regardless of what the rules for combining appenders/modifiers/enabledness are, they need to be consistent and to work across scoped logs going in/out of scope. I think what is needed is a set of connections (logs connect to appenders/modifiers) ordered by the log name which may include wildcards. Log name (segments) containing wildcards should be ordered before exact names so the more specific rules override the less specific ones. Note the above was from reading the docs + code - I haven't tried running it yet, and maybe I'm misunderstanding something. Regards Darryl.

6 9

logging v1.4 - multiple levels implemented!
by John Torjo 22 Aug '05

22 Aug '05

Hi all, Just updated the Logging library. Find it here: http://torjo.com/code/logging.zip Also, I've updated the docs. Feedback is welcome. Highlights: **** Multiple levels. **** Easier manipulation of logs **** Modifiers/Appenders can now be deleted. **** Shortcut for BOOST_IS_LOG_ENABLED **** Exception guards **** Shared Memory Appender **** Multiple levels. You can specify levels, very much like log4j. To assign a level to a message, use BOOST_LOGL, like this: BOOST_LOGL(app,dbg) << "some debug message"; BOOST_LOGL(app,err) << "some error"; BOOST_LOGL(gui,warn) << "some GUIsh warning"; Note the BOOST_LOG still works: BOOST_LOG(app) << "some message"; // equivalent to: // BOOST_LOGL(app,default_) << "some message" **** Easier manipulation of logs Every time you need to manipulate some logs (add/delete appenders/modifiers, set the log's level), you use manipulate_logs("logs_spec") Example: manipulate_logs("*") // all logs prefix the message by time .add_modifier(prepend_time("$hh:$mm:$ss "), DEFAULT_INDEX + 1 ) // all log' messages are prefixed by the log name .add_modifier(&prepend_prefix) // all messages are written to cout .add_appender(&write_to_cout); // write all dbg messages and above to app.* logs manipulate_logs("app.*").enable(boost::logging::level::dbg); **** Modifiers/Appenders can now be deleted. In order to delete a modifier/appender, just give it a name: // prepend time, and name this modifier as "time" manipulate_logs("*") .add_modifier(prepend_time("$hh:$mm:$ss "), "time" ); // at a later time BOOST_LOG(app) << "this is prefixed by time"; manipulate_logs("*") .del_modifier("time"); BOOST_LOG(app) << "this is NOT prefixed by time"; ***** Shortcut for BOOST_IS_LOG_ENABLED Instead of saying: // test if message should be written to this log if ( BOOST_IS_LOG_ENABLED(app,some_level)) ...; You can say: if ( app()(some_level)) ...; **** Exception guards When logging, if any modifier/appender throws, the exception is not allowed to propagate. **** Shared Memory Appender An appender that allows writing to a shared memory zone, internally using shmem library. Still to do: **** compile-time logs: write docs about it **** appenders to Event log **** alternate logging manager Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter) -- http://www.torjo.com/cb/ - Click, Build, Run!

5 15

Boost regression notification (2005-08-22)
by Douglas Gregor 22 Aug '05

22 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-22T15:05:38Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 65 failures in 6 libraries: functional/hash (9) graph (9) parameter (4) python (22) serialization (20) wave (1) |functional/hash| books: vc-6_5 vc-6_5-stlport vc-7_0 point: borland-5_6_4 vc-6_5 vc-6_5-stlport vc-7_0 portable: vc-6_5 vc-6_5-stlport |graph| graphviz_test: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux mingw-3_4_2 vc-7_1 vc-7_1 vc-7_1 |parameter| basics: borland-5_6_4 macros: borland-5_6_4 sfinae: borland-5_6_4 unnamed: borland-5_6_4 |python| exec: cw-8_3 cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_4_3-sunos gcc-4.0.1-linux intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1 vc-7_1 vc-7_1 |serialization| test_class_info_load_binary_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_binary_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_text_archive: gcc-3_4_3-sunos test_class_info_load_text_archive_dll: gcc-3_4_3-sunos test_class_info_load_text_warchive: gcc-3_4_3-sunos test_class_info_load_text_warchive_dll: gcc-3_4_3-sunos test_class_info_load_xml_archive: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_archive_dll: cw-9_5-darwin gcc-3_4_3-sunos test_class_info_load_xml_warchive: gcc-3_4_3-sunos test_class_info_load_xml_warchive_dll: gcc-3_4_3-sunos 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 |wave| testwave: gcc-3.3.6-linux

1 0

Start separating mandatory source?
by Daryle Walker 22 Aug '05

22 Aug '05

Since we just had a release, should be re-visit moving all the mandatory source code into a separate directory together? For the newbies, this means changing the BOOST_ROOT . libs .. date_time ... src .. graph ... src into something like BOOST_ROOT . src .. date_time .. graph Right now, using mandatory source files means scrambling into a lot of directories figuring out what to add. There is stuff like Boost-Build, but it doesn't work for everyone, and I feel that it's a "cute" overkill solution. No matter the plan there are some caveats: 1. Some platforms require some libraries to be put in separate DLLs. 2. You have to exclude the driver files from Boost-Test, since each includes a "main" function. (And if you actually are doing testing, then you know that you can include at most one driver file.) Besides the caveats, you can just dump all the mandatory source code into your IDE's project file (or make file) and don't worry Boost-Build. If some source needs to be in a DLL, then start a sub-project. (If you don't need a library at all, then exclude it from the project to save compile time. The linker will tell you, by choking, if you went too far.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

4 9

Should we add two simple character-to-Unicode converters?
by Daryle Walker 22 Aug '05

22 Aug '05

Nothing fancy, just something like: int_fast32_t char_to_Unicode( char c ); int_fast32_t wchar_to_Unicode( wchar_t c ); that converts a native character to a Unicode value. They would need a separate source file that contains #if blocks for each platform. Maybe they can start a namespace with "utf8_codecvt_facet"? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 3

interest in "policy_composite" library?
by Larry Evans 22 Aug '05

22 Aug '05

Is there any interest in a "policy_composite" library which will have policies just as the proposed policy_ptr: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/pol… library has policies? These composite policies might allow different allocation strategies for variant and possibly different CTOR arguments for tuple. It could also allow adding different methods, such as the get_base_ptr(void) as described here: http://groups-beta.google.com/group/comp.std.c++/msg/27e41e693228c6c7?hl=en& which would of course satisfy (hopefully) that OP's request for a variant extension.

1 0

Re: [boost] Should we add two simple character-to-Unicode converters?
by Graham 22 Aug '05

22 Aug '05

>From: Daryle Walker <darylew(a)hotmail.com> Dear Daryle, >I thought of these functions while considering how Wave process the various >phases of C++ translation (see section 2.1 of the standard). I wanted the >conversion to be one native-character to one code-point because that is how >Phase 1 implies it[1]. If you don't think that's right, maybe we should >file a defect with the Standard committee. Maybe I misunderstood you - you seem to be asking for code page conversion here not UTF conversion. Code page conversion is anything but simple and requires data conversion tables for many of the code pages. It is not very practical at the character level as you can see from the calls below, but would require conversion objects to be created that can then implement these functions. int_fast32_t char_to_Unicode(std::string locale, char c ); // very inefficient int_fast32_t wchar_to_Unicode(std::string locale, wchar_t c ); // very inefficient conv1250 = new convertor(std::string locale); // better convertor->char_to_Unicode(char c); >[1] In other words, any extended native character (i.e. not a character C++ >uses for parsing) must be mapped to one C++ Unicode name, which maps to a >single code-point. That depends on what you mean. For example <e><acute> can be one <e acute>, or two <e><acute> Unicode characters depending on how it is normalised. A character parser should understand this if it wants to present Unicode graphemes which are the default unit of parsing in unicode and which should be in any compliant native handler even if working with the local code page. I suggest you wait for the release of the unicode library, alternatively if you want to volunteer to write lots of code page conversion functions, and their data tables where necessary, please let us know. Yours, Graham

2 1

Updated version history
by Daryle Walker 22 Aug '05

22 Aug '05

I added items for 1.11.1 and 1.11.0, which I found in e-mails in the Archives. Worse, 1.11.1 was just incidentally mentioned and was not a subject of an e-mail. Updated CVS and the web site (hopefully not frying the latter). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[config] Why does BOOST_NO_INTEGRAL_INT64_T depend on BOOST_HAS_LONG_LONG?
by Markus Schöpflin 22 Aug '05

22 Aug '05

Currently config/suffix.hpp contains the following code which seems pretty wrong to me: ---%<--- #if !defined(BOOST_HAS_LONG_LONG) && !defined(BOOST_NO_INTEGRAL_INT64_T) # define BOOST_NO_INTEGRAL_INT64_T #endif --->%--- AFAICT, the existence of a 64 bit integral type has nothing to do with support for long long types. On Tru64 for example, uint64_t is defined as unsigned long and there is no unsigned long long when the compiler operates in strict ansi mode. Shouldn't these lines just be removed? Markus

3 10

build boost_1.33 on cygwin failed
by Bernd Martin Wollny 22 Aug '05

22 Aug '05

Hello, I am using cygwin on a Windows XP system. I can build boost 1_32.0 with no problems. If i Try to build boos_1.33 The build failed with the following error: ./bjam -sTools="gcc" --prefix=/usr stage Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). unknown target type for <@boost!libs!test!build>libboost_prg_exec_monitor.dll The error doesn't depend on prefix. what is wrong ??? buy Bernd

1 0

[type_traits] small workaround logic change
by Vladimir Prus 22 Aug '05

22 Aug '05

Hello, I suggest that the following patch be applied to type_traits/detail/cv_traits_impl.hpp: --- cv_traits_impl.hpp 22 Jun 2005 16:59:26 -0000 1.4 +++ cv_traits_impl.hpp 14 Jul 2005 06:49:40 -0000 @@ -19,7 +19,7 @@ // implementation helper: -#if !(BOOST_WORKAROUND(__GNUC__,== 3) && (__GNUC_MINOR__ <= 2)) +#if !(BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2)) namespace boost { namespace detail { #else The reason is that later in the file, we have: #if BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2) and first condition does not exactly match the second condition. Specifically, suppose __GNUC__ is set to 3 and __GNUC_MINOR__ is not set. The first condition will evaluate to ! (BOOST_WORKAROUND(__GNUC__, == 3) && (__GNUC_MINOR__ <= 2) = ! (1 && (0 <= 2)) = ! (1 && 1 ) = 0 The second condition in the file will evaluate to: BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2) = 1 && 0 = 0 So, both conditions evaluate to the same value, while they are supposed to be mutually exclusive. The case where __GNUC_MINOR__ is not set is a pathological -- I've found it when playing with some C++ parser, but the patch should do no harm. Opinions? - Volodya

3 2

Bug in boost::rational, no Boolean conversion; an operator template suggestion
by Daryle Walker 22 Aug '05

22 Aug '05

I'm writing a class template where the template parameter is a type that should represent real numbers. It started choking when using boost::rational when I needed Boolean conversion, e.g. template < typename T > void my_class<T>::my_func() { if ( this->s_ ) //... } Looking at boost::rational, I noticed that it does NOT have a Boolean conversion operator (i.e. an unspecified numeric/pointer type). Before anyone says that's proper, realize that boost::rational DOES have "operator not()" defined! This is a surprise to the typical C++ programmer. Either both should be defined, or neither. I think that boost::rational should add a Boolean conversion. (It's a quick fix, and it is critical, so it should be done for this release.) Incidentally, maybe we should define another helper template for <boost/operators.hpp>. If a type supports default construction and equality via "operator ==()", then a Boolean conversion and "operator not()" will be added. (It's up to the user to make sure the type is numeric and the default value is equivalent to zero.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 4

Re: [boost] Should we add two simple character-to-Unicode converters?
by Graham 22 Aug '05

22 Aug '05

Hi, Both: int_fast32_t char_to_Unicode( char c ); int_fast32_t wchar_to_Unicode( wchar_t c ) will require processing of surrogates on order to be Unicode 4 compliant. A Unicode library is currently under development that will give access to the surrogate ranges directly from the ucd to allow this to be done properly. Please bear with us. Yours, Graham >Message: 13 >Date: Fri, 19 Aug 2005 17:15:03 +0400 >From: Vladimir Prus <ghost(a)cs.msu.su> >Subject: Re: [boost] Should we add two simple character-to-Unicode > converters? >To: boost(a)lists.boost.org >Message-ID: <de4m0n$aq9$1(a)sea.gmane.org> >Content-Type: text/plain; charset=us-ascii > >Daryle Walker wrote: > >> Nothing fancy, just something like: >> >> int_fast32_t char_to_Unicode( char c ); >> int_fast32_t wchar_to_Unicode( wchar_t c ); >> >> that converts a native character to a Unicode value. > >Maybe, but it's hard to comment as you haven't even explained what those >function will do. What's a "native character" and what a "Unicode value" >and how the conversion will be done? If the first function does conversion >from local 8 bit encoding to unicode then: > > - do you have a working implementation? > - isn't dealing with individual characters too slow? > >- Volodya Graham Barnett BEng, ACGI, MCSD/ MCAD .Net, MCSE/ MCSA 2003, CompTIA Sec+

2 1

[Repost][RFC] Alternative any design
by Pablo Aguilar 22 Aug '05

22 Aug '05

I posted this the same day 1.33 was released, but got no reply, I'd like to think it was due to bad timing rather than lack of interest. Any comments are welcome... ---- Original post ---- Hi, First of all, thanks to everyone who's commented on the proposed any alternative. Given that the alignment issue doesn't seem to be easy to solve, I'm thinking of giving up on trying to align correctly, and just skip the "in place storing of value" optimization when it might be an issue. So I'm wondering, is the following a proper way to detect alignment problems? <code> typedef void* any_buffer_base_type; // could be customized int const ANY_BUFFER_SIZE = sizeof(any_buffer_base_type); union object_holder { char buffer[ANY_BUFFER_SIZE]; void* pointer; any_buffer_base_type alignment_dummy_; }; template<typename T> struct optimize { enum { T_size_ = sizeof(T) , base_size_ = sizeof(any_buffer_base_type) , size_ok_ = (T_size_ <= base_size_) , T_align_ = alignment_of<T>::value , base_align_= alignment_of<any_buffer_base_type>::value , align_ok_ = ((base_align_ % T_align_) == 0) , value = size_ok_ && align_ok_ }; }; </code> I looked at Optional's alignment tecnique, and couldn't come up with how to use it, given that the stored type for any changes at runtime. If there's something I missed about this, any help would be welcome. My current solution is to use the above shown code (assuming it works, of course!), and fall back on heap based storage when optimization is deemed not possible. The 2nd question I had to ask is, how should any's alignment type be specified, with a configuration macro or through a template parameter? I haven't posted an updated version, given that there's some issues (other than alignment) still requiring attention. Thanks in advance for any help you might provide, Pablo Aguilar

2 2