- Boost - lists.boost.org

duplicate source files in boost- utf8_codecvt_facet
by Robert Ramey 07 Dec '04

07 Dec '04

We now have a at least one set of files more or less duplicated in boost. Ron Garcia's utf8_codecvt_facet is included in: boost/utf8_codecvt_facet.hpp boost/detail/utf8_codecvt_facet.hpp boost/libs/serialization/src/utf8_codecvt_facet.cpp boost/libs/program_options/detail/utf8_codecvt_facet.cpp boost/libs/doc/serialization/utf8_codecvt_facet.html boost/libs/serialization/test/test_utf8_codecvt_facet.cpp Leaving aside how this came to be, I would like to do the following: boost/detail/utf8_codecvt_facet.hpp boost/libs/detail // new directory boost/libs/detai/src/utf8_codecvt_facet.cpp boost/libs/detail/test/test_utf8_codecvt_facet.cpp boost/libs/detail/doc/utf8_codecvt_facet.html This would make both the serialization and program options libraries that much smaller and server our needs until a reviewed version of codecvt facets in added to boost. Robert Ramey

7 11

Program Options Custom Notifier Function Order of Execution
by Tony Han Bao 07 Dec '04

07 Dec '04

Hi all, Can anyone tell me the precise definition or behaviour of the order of execution of the user supplied functions to handle command line options defined in boost program options library. For example, my option menu was defined as follows boost::program_options::options_description menu("Valid Options"); menu.add_options() ("help,h", "Display this menu.") ("time,t", boost::program_options::value<double>(&time_arg_value) -> notifier(&my_function1) "Description of option") ("memory,m", boost::program_options::value<double>(&memory_arg_value) -> notifier(&my_function2), "Description of option") ("file,f", boost::program_options::value<std::vector<std::string> >(&file_arg_value) -> composing() -> notifier(&file_arg_handler<std::vector<std::string> >), "Something"); boost::program_options::variables_map menu_map; boost::program_options::store(boost::program_options:: parse_command_line(argc, argv, menu), menu_map); boost::program_options::notify(menu_map); Question is: Will the following two calls to the program result in different behaviour? >./Test --time 76 --memory 97 --help >./Test --memory 97 --time 76 --help I want my two functions for time and memory be independent of each other but I would like the function be called in the same order as the options specified on the command line. Sure I can test but can someone guarantee that what I discovered will remain valid in the future release of the library. Another question: What will happen if this program was called on the command line with the following options. >./Test --file myfile1 --time 87 --file myfile2 Will the file_arg_handler be called first with composed arguments and then time function (my_function1) or will the time function (my_function1) be called first and then the file_arg_handler function. Can I count on it that what happens will always happen in the future? Is there definitions for the order of execution guarantee by the library? Thanks in advance for your help! Best Regards, Tony Han Bao tonybao(a)mac.com

3 8

[named_params] member function overload autogen macro
by Cromwell Enage 07 Dec '04

07 Dec '04

It turns out that class member function definitions that take in named parameters will not compile with BOOST_NAMED_PARAMS_FUN. The first two lines of this macro, meant to generate the function prototype so that free function overloads can call it, cause a "duplicate definition" error when the macro is used in a class body. Fortunately, removing those two lines to create the BOOST_NAMED_PARAMS_MEMBER_FUN macro was all that was needed to eliminate the error. Sooo...here's yet another patch, along with a two-file program illustrating both macros in action. Cromwell D. Enage P.S. I better start adding my middle initial, to match with the name I use in my licensing info. __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

no auto-link for serialization
by Martin Slater 07 Dec '04

07 Dec '04

Posted before but being a lemon I put filesystem in the subject instead of serialisation, please see No auto-link for filesystem message from yesterday. sorry Martin

2 1

No auto-link for filesystem
by Martin Slater 07 Dec '04

07 Dec '04

Is there a reason for this or is it just an oversight? cheers Martin

2 3

[BUG] Missing method in gregorian::greg_year
by Joel Reed 07 Dec '04

07 Dec '04

the class gregorian::greg_year in the date_time library is missing a method implemented in greg_day and greg_month. the method is: unsigned short as_number() const {return value_;} i checked cvs, on 12/6/04, to confirm this is still an issue. http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/date_time/gregorian… we have been very impressed with this library and wanted to report this minor inconsistency as a small, small way to say thanks. jr -- ------------------------------------------------------------ Joel W. Reed 412-257-3881 ---------- http://home.comcast.net/~joelwreed/ ----------

2 1

Boost Sandbox layout?
by Rene Rivera 06 Dec '04

06 Dec '04

I'm looking at how things are placed in the sandbox and wondering about something... Currently the sandbox mirrors the layout of the main Boost CVS. That is: boost-sandbox /boost/... /libs /libs/<library>/... That layout has a few drawbacks when dealing with a single isolated library... 1) It makes it harder to package as one has to filter out the rest of the stuff there. 2) One can get conflicts when something in another library's code gets accidentally used. I ran into this when evaluating named_params as some MPL related files got picked off from the sandbox instead of from the Boost CVS. 3) Makes finding things much harder when someone mentions to look in the sandbox for their library. Was there ever a discussion as to the layout? (A cursory search did not reveal anything) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 8

Bug: thread_exception returns ref to local variable
by Ulrich Eckhardt 06 Dec '04

06 Dec '04

Cheers! The code in question is this: // boost/thread/exceptions.hpp class thread_exception { ... const char* message() const; }; // libs/thread/src/exceptions.cpp std::string system_message(int sys_err_code){..} const char* thread_exception::message() const { if (m_sys_err != 0) return system_message(m_sys_err).c_str(); return what(); } If message() is called and m_sys_err is set, it will return a pointer to storage of a temporary, which is bad, as we all know. I did some research on that, and I think this whole method can be removed completely because: - it is not decumented - it is not used - it never worked (probably, at least not with 1.32) Further, one could then remove <string> from the includes in the header and some more includes in the sourcefile. An alternative approach would be to change the returntype to std::string, of course, or (and I think that's an interesting alternative!) derive all those classes from std::runtime_error, which can hold a std::string natively. Uli

1 0

wiki spam
by Max Khesin 06 Dec '04

06 Dec '04

The CAPTCHA technology might be helpful: http://weblog.infoworld.com/udell/2004/12/01.html#a1124 There are apparently open-source implementations of CAPTCHA, might be something to consider. Another suggestion would be boost-specific CAPTCHA that asks you to enter a result of some enable_if statement as the answer to the question - guaranteed to stop spammers AND newbies! (an unexpected benefit?) regards, max This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

Novelty: autmatically assigning unique integral type ids
by Jonathan Turkanis 06 Dec '04

06 Dec '04

Hi all, Attached is some non-conforming code which automatically assigns a unique integer id to an arbitrary type. It's based on this post by Daniel Wallin: http://lists.boost.org/MailArchives/boost/msg69842.php Example: #include <boost/static_assert.hpp> #include <boost/unique_id.hpp> int main() { BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(void) == 0); BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(bool) == 1); BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(char) == 2); BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(void) == 0); BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(bool) == 1); BOOST_STATIC_ASSERT(BOOST_UNIQUE_ID(char) == 2); } Obviously the ids assigned will be different depending on the order in which types are passed to BOOST_UNIQUE_ID. It's a novelty not just because it's non-conforming but also because after assigning ids to about fifty types it slows down to a deadly crawl, and maxes out at about 110 types (on VC7.1, using over 300MB RAM). I tried several forms of loop unrolling, and they don't help much. I'm posting this now because yesterday I figured out how to make it work on EDG (except for Comeau). It now works on VC7.1, VC8.0 (beta), GCC 3.2 (MinGW), GCC 3.4.1 (Cygwin), Intel 7.0 and 8.0 for Windows (in strict mode), and on the preview of the Borland EDG-based compiler I downloaded about half a year ago. I still need conforming-compiler workarounds for Comeau and Metrowerks. ;-) Best Regards, Jonathan begin 666 unique_id.zip M4$L#! H``````'%R@S$````````````````/````;&EB<R]U;FEQ=65?:60O M4$L#!!0````(`!AP@S&5>-46[ ```+(&```7````;&EB<R]U;FEQ=65?:60O M=&5S="YC<'#MTT]/PC 8!O![DWZ')ERV"SB4?T%,4#GL`M&-<U/6RIJ4%M?6 MB_&[.SM%PHEW5^AQW2_/F_1Y.U(7RG-![C?&6->SCCE94&:MJ%RWW.\?,.J< M_..U?/>"2OY[CY'4CNR8U%&,T2=&I#Z/JU66TRR?Y^D3G6?9XC6/FF_K9?JR M7M#T.?HPDL=D-B,W\?1\50^A@DH@JBA9%50?HJS<:L')`=]"L->G_ Z479K* M!39HE?KOAQ!?OV5 HU:A?WH,T<KH;5"35ID'GH!Z]*8,:X9-0$WBQF^4:""H M3#]SDF,-:M-U6:[+<O'+\H71-U!+`P0*``````"<<H,Q```````````````` M!0```&QI8G,O4$L#!!0````(`$-O@S'*X)&D;@,``*,+```3````8F]O<W0O M=6YI<75E7VED+FAP<*5638^;,!"]K[3_8:1>8)M"4O7D4J0V&ZFI*K95V%XM M+PR)56*H,=VF5?][;2"$+!\;J3XA_&;FS;-G/*X+UM*&998?)-_N%'S*!%,[ M)B LY7<F> &OY_,WSO65Z\(M+Y3D#Z7"&$H1HP2U0_B0986"39:H1R81/O,( M18$S^(:RX)F A3-WP-H@`HNB;)\S<>!B6SE,>*H-ULM5L%G1!9T[ZI>"3$*D MZ0!3L%,J)Z[[^/CH/)@H3B:W[A.\8U]?'=E%*>-[E 2"3 %KF*7\03)Y< SL M!4\T[P0^W-UM0GH?K+_>K^CZEG[\\H6N@^7G^]O5K49I"!?X#,IX$U%:Q@A> MQ<Z-,I'PK;/+<[^_N<]3%W^RE/)D`L%C%(JKPQ1$J(G=G'$YLJT..5(E&5>% M&Z-B/'4/6%"14;-S@1$OZ,^,QR/(4O%4,W=1L(<43VF.ZFF%-A!2&1-2"OZC MU%:Q!R'XA)BXA&B]2C0N!-MCD;,(H<+#G_.?=3KF+_37]95"+0U3Z!FOQ@I" MMM74.LD1TN(a)`+1.ZPS1':6GL#!S'L=^:H .^M"==&&6D.K9<HXY\!L//0!\D M!'X-:>WW3'[7Y=7)I%9M$[X/UTNZO OT5Q!:1H=T!I5 \.X\[X+_QBRQAA*Q M[!E8F(a)TA.CKU`O_&GMMV7[9WPRZ'!+/!"',$FC^FPJH8AB/U*HY^M=,`_U9* M5O">-/<S:+^?J"/PEZ)#$AV#'@W[^51TFO+S!F])J[UWDF?NSR!H;J$_&S:K MT4W9CKAN<:8Z)S MKCZ<)C+<P.NQZ'VKN3^.'-F:3&U:-+,&A%M<()Q9EXK7 M8B\0L,7V1(27L'A.R'/KQ8289DUI?7':IJ>.G4S_=],;06)1IFJ@\OZK")H6 M[]7>QW(X*T3/E.R X$;LZ:O5*M!$&T]VN'<\2?@IK;!+:^ZWSLZEZWFI=PE) MN-0/S?CJ<!KU4:">">()'VS[]MCBF.*1GGR$#FI>AJ:S0^<AG.B:]7M6.ZIZ M98QZ&))($\E1##9+$Z23@UD-^*S+FQ&ADNT$&WXA3UI;-?=7AE5#W79U#[NQ MGS_#<]Z>%J@]MK/%M4Y,WQZF,JF]U1[_@IX#5SH#XRHO3I.!<_G+7?,BG71J M%YT1I7K<O= _-KC:Y \,D*C&DZ(>6NH)5&?%$P.Y;!:]OOH'4$L#! H````` M`)ER@S$````````````````&````8F]O<W0O4$L!`A0`"@``````<7*#,0`` M``````````````\````````````0`````````&QI8G,O=6YI<75E7VED+U!+ M`0(4`!0````(`!AP@S&5>-46[ ```+(&```7``````````$`( ```"T```!L M:6)S+W5N:7%U95]I9"]T97-T+F-P<%!+`0(4``H``````)QR@S$````````` M```````%````````````$ ```$X!``!L:6)S+U!+`0(4`!0````(`$-O@S'* MX)&D;@,``*,+```3``````````$`( ```'$!``!B;V]S="]U;FEQ=65?:60N M:'!P4$L!`A0`"@``````F7*#,0````````````````8````````````0```` @$ 4``&)O;W-T+U!+!08`````!0`%`"H!```T!0`````` ` end

5 11