December 2004 - Boost - lists.preview.boost.org

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

[thread] SunPRO: test_mutex hangs when run via regression.py
by Caleb Epstein 06 Dec '04

06 Dec '04

The Boost.Threads test program test_mutex, when built with the SunPRO C++ compiler, always hangs when I run it on a Solaris machine under regression.py. The same binary finishes in short order with status 0 when run on the command line, but under regression.py it never exits. If I attach to it with the debugger, or with strace or truss, it finishes successfully. I'm unclear what could be going wrong here and expect it is either a bug in the code produced by SunPRO or a really subtle bug in the test program. Perhaps someone could take a look? I am stumped. Here's the output of a program I found called "thrstack" which produces a stack trace for each thread w/o attaching to it: status for pid 13551 (6 LWPs) -- LWP 1 -- ff19f48c: libc.so.1:__lwp_sema_wait + 0x8 ff2396dc: libthread.so.1:_park + 0x114 ff2393a4: libthread.so.1:_swtch + 0x424 ff23da10: libthread.so.1:_reap_wait_cancel + 0x40 ff23fc9c: libthread.so.1:_thrp_join + 0x344 ff33d0d8: libboost_thread-sw-mt-d-1_32.so:void boost::thread::join() + 0x18 000334a4: test_mutex:void __unnamed_lpburfiEtB2zM::indirect_adapter<void(*)()>::operator()()const + 0x44 000333b4: test_mutex:boost::detail::function::unusable boost::detail::function::void_function_obj_invoker0<__unnamed_lpburfiEtB2zM::indirect_adapter<void(*)()>,void>::invoke(boost::detail::function::any_pointer) + 0x1c ff330748: libboost_thread-sw-mt-d-1_32.so:void boost::function0<void,int>::operator()()const + 0x78 ff33cd4c: libboost_thread-sw-mt-d-1_32.so:thread_proxy + 0x44 ff24b01c: libthread.so.1:_thread_start + 0x40 ff33cd08: libboost_thread-sw-mt-d-1_32.so:thread_proxy + 0x0 -- LWP 2 -- ff19eddc: libc.so.1:__signotifywait + 0x4 ff23e950: libthread.so.1:_dynamiclwps + 0x1c ff241c2c: libthread.so.1:_thr_yield + 0x8c -- LWP 3 -- ff19f48c: libc.so.1:__lwp_sema_wait + 0x8 ff2396dc: libthread.so.1:_park + 0x114 ff2393a4: libthread.so.1:_swtch + 0x424 ff23ada0: libthread.so.1:_mutex_adaptive_lock + 0x160 ff23aab4: libthread.so.1:_cmutex_lock + 0x84 ff141cd0: libc.so.1:malloc + 0x18 ff136174: libc.so.1:calloc + 0x54 ff243e2c: libthread.so.1:_thr_setspecific + 0x38 ff2e54bc: libCrun.so.1:__Cimpl::ex_thread*__Cimpl::ex_thread::get_thr_data() + 0x118 ff2e4160: libCrun.so.1:__Cimpl::xstack*&__Cimpl::get_cur_xptr() + 0x4 ff2e41b0: libCrun.so.1:void*__Crun::ex_alloc(unsigned) + 0x14 0007c338: test_mutex:int boost::detail::catch_signals(boost::execution_monitor&,bool,int) + 0x310 0007ac38: test_mutex:int boost::execution_monitor::execute(bool,int) + 0x28 00076e40: test_mutex:boost::unit_test::ut_detail::unit_test_monitor::error_level boost::unit_test::ut_detail::unit_test_monitor::execute_and_translate(boost::unit_test::test_case*,void(boost::unit_test::test_case::*)(),int) + 0x60 0005c1b0: test_mutex:void boost::unit_test::test_case::run() + 0x498 0005cbc4: test_mutex:void boost::unit_test::test_suite::do_run() + 0x7c 0005c3e0: test_mutex:void boost::unit_test::test_case::run() + 0x6c8 00062208: test_mutex:main + 0x458 0002cbb0: test_mutex:_start + 0x108 -- LWP 4 -- ff19f48c: libc.so.1:__lwp_sema_wait + 0x8 ff2396dc: libthread.so.1:_park + 0x114 ff2393a4: libthread.so.1:_swtch + 0x424 ff23ada0: libthread.so.1:_mutex_adaptive_lock + 0x160 ff23aab4: libthread.so.1:_cmutex_lock + 0x84 ff142b64: libc.so.1:free + 0x18 ff2e6260: libCrun.so.1:void operator delete(void*) + 0x4 00031c24: test_mutex:__SLIP.DELETER__H + 0x2c 00031ba0: test_mutex:void boost::detail::sp_counted_base::destruct() + 0x40 00030a5c: test_mutex:void boost::detail::sp_counted_base::weak_release() + 0x6c 0002f9cc: test_mutex:void boost::detail::sp_counted_base::release() + 0x8c 0002f6ec: test_mutex:boost::detail::shared_count::~shared_count #Nvariant 1() + 0x24 0002ef58: test_mutex:boost::shared_ptr<boost::basic_wrap_stringstream<char> >::~shared_ptr() + 0x10 0002e540: test_mutex:boost::test_tools::extended_predicate_value::~extended_predicate_value() + 0x10 0002e2dc: test_mutex:bool boost::test_tools::tt_detail::equal_and_continue_impl<int,int>(const __type_0&,const __type_1&,boost::basic_wrap_stringstream<char>&,boost::unit_test::basic_cstring<const char>,unsigned,boost::unit_test::log_level,unsigned) + 0x37c 0002d6ac: test_mutex:boost::xtime __unnamed_lpburfiEtB2zM::delay(int,int,int) + 0x10c 0002d110: test_mutex:bool __unnamed_lpburfiEtB2zM::execution_monitor::wait() + 0x20 ff25c000: libthread.so.1:?? + 0x0 -- LWP 5 -- ff2491fc: libthread.so.1:private___lwp_cond_wait + 0x4 ff238998: libthread.so.1:_co_timerset + 0xa0 ff24b01c: libthread.so.1:_thread_start + 0x40 ff2388f8: libthread.so.1:_co_timerset + 0x0 -- LWP 6 -- ff19c980: libc.so.1:__door_return + 0xc ff2467c8: libthread.so.1:_sc_door_func + 0x54 ff23a358: libthread.so.1:_lwp_start + 0x18 ff241c2c: libthread.so.1:_thr_yield + 0x8c -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

variant==dependent pair, dependent function possible?
by Larry Evans 06 Dec '04

06 Dec '04

IIUC, the variant library is similar to a "dependent product" which can be thought of as a pseudo_pair<Index,TypeList>. where an instance: pseudo_pair<I,T> dpIT; is a pair of values (i,t) where: I i; T<i> t; IOW, there is only one value, but it can be one of many types depending on the valid values of I. BTW, would variant be made for readable by making variant take an enumeration: enum I{i0, i1, ...., in-1} as the discriminator? Anyway, back to the original question. Is there any interest in a "dependent function" where: dependent_function<I,T> df; where: T<i0>& df<i0>(); T<i1>& df<i1>(); ... T<in-1>& df<in-1>(): IOW, this would be like a regular struct (a record type), however, instead of: df.ix there would be: df<ix>(); BTW, this idea comes from Nuprl: http://www.cs.cornell.edu/Info/Projects/NuPrl/nuprl.html and I've recently had a need for it because I've got a template which is specialized on an enumeration; hence, this would come in handy if I wanted to have a structure containing all instances of the specializations.

1 1

Unexpected behaviour of boost::filesystem::equivalent
by Daniel Krügler 06 Dec '04

06 Dec '04

Hi booster, its quite a long time ago since I could follow the threads here more thoroughly :-( , so the following information might not be new one. During tests of the current Win32 implementation of boost::filesystem::equivalent I observed that the function unexpectingly fails (my test environment was Win XP SP 1 with MSVC7.1) if it compares a "soft link" created via the DOS command "subst" (or its API analogon ::DefineDosDeviceA/W) with the corresponding mapped path object (Lets say I map M: to the existing directory C:\temp). To get an understanding of the test failure I debugged the implementation and found that actually the first test part (getting the handles and comparing the VSN's + further data) gave the expected positive result, but that the very last step, i.e. the comparison of both st_dev values, gave a final unequality. Did others also observe this failure and don't you think that the expected result should show the identity of the underlying path objects? Of course there might be legitimate arguments for the decision for the current behaviour, but I would like to know about them. I am not an expert to argue about the comments in the source code which say that "In theory, volume serial numbers are sufficient to distinguish between devices, but in practice VSN's are sometimes duplicated, so device id is also checked.[..]" The question now is: Should different (MS DOS) device names pointing to the same underlying (Windows NT) device not be compared equivalent? I could think of the following test extension (at least under Windows, regrettably I am not a posix expert to provide a similar solution): If the VSN' and further data have returned a positive result, but the check of both st_dev values fails, one should try to check whether the underlying devices are actually the same, e.g. using the ::QueryDosDeviceA/W API function. What do you think? Greetings, Daniel Krügler

3 8

3D logo
by Joaquín Mª López Muñoz 06 Dec '04

06 Dec '04

Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

! Wiki Spam
by Christopher D. Russell 06 Dec '04

06 Dec '04

I just found the start page of the Wiki completely replaced with xanax drug spam. I removed the offending content and left a note in its place. Sorry - I'm not sure where the original content is archived or I would go fix it myself right now. Perhaps we need a password mechanism on the Wiki? This seems to work well over at http://www.program-transformation.org/ where you need to register and login to edit. - Chris

7 14

[Review Results] Named Parameters Library
by Doug Gregor 06 Dec '04

06 Dec '04

The Named Parameters Library has been accepted into Boost. Congratulations to the authors, David Abrahams and Daniel Wallin. The vast majority of reviews were positive, although most reviewers requested additional documentation. Here is a list of the most important/commonly-requested changes or additions to the library: - More documentation! Specifically, + Automatic overload generation should go into the tutorial + Document operator, + Performance data (what's the cost?) + Reference section + "Best practices" section. - Add a metafunction for getting the type of a parameter, e.g., param_type<Params, width_t>::type. - Add test cases for the automatic overload generation macros. - Fix the BOOST_NAMED_PARAMS_MAX_ARITY bug; Cromwell Enage provided a solution. Doug Gregor Review Manager

2 1

Anyone interested in a virtual constructor lib?
by Roland Schwarz 06 Dec '04

06 Dec '04

As a byproduct of my current work I factored out a small utility library that implements a virtual constructor. The implementation is based on boost::any and typeid(...).name(). It features dynamic creation of objects by name (string), and allows for default and custom constructors beeing called. It could be used as the basic step to object deserialization from a file, creation of operating system dependent implementations, or allow a library to instantiate user-pluggable classes. The design is inspired by the Io_obj example from Stroustrup's book on C++ programming. A small example to show the usage: #include <string> #include <iostream> #include "dynanew.hpp" using namespace dynanew; // a simple class hierarchy with abstact base class struct shape { virtual void draw() = 0; }; struct square : public shape { virtual void draw() { std::cout << "I am a square" << std::endl; } }; struct circle : public shape { circle() : radius(0) {} circle(double dr) : radius(dr) {} virtual void draw() { std::cout << "I am a circle of radius: " << radius << std::endl; } double radius; }; // create the type map TYPE_MAP(shape); // square with default constructor TYPE_REGISTER(shape, square); // circle with custom constructor taking a double parameter TYPE_REGISTER1(shape, circle, double); // circle with default constructor TYPE_REGISTER(shape, circle); int main(int argc, char* argv[]) { std::string type; type = "square"; shape* ps1 = dynamic_new<shape>(type); shape* ps2 = dynamic_new<shape>("circle", 20.0); shape* ps3 = dynamic_new<shape>("circle"); shape* ps4 = dynamic_new<shape>("square", 10.0); if (ps1) ps1->draw(); // prints: I am a square if (ps2) ps2->draw(); // prints: I am a circle of radius: 20.0 if (ps3) ps3->draw(); // prints: I am a circle of radius: 0.0 if (ps4) ps4->draw(); // does nothing since no ctor available delete ps1; delete ps2; delete ps3; delete ps4; return 0; } regards, Roland

5 14

date-time out of whack?
by Victor A. Wagner Jr. 06 Dec '04

06 Dec '04

The program that causes this error used to compile (until a few days ago) I'm using the cvs HEAD c:\boost\include\boost-1_32\boost\iterator\iterator_facade.hpp(326) : error C2664: 'boost::implicit_cast' : cannot convert parameter 1 from 'const std::string *__w64 ' to 'boost::mpl::identity::type' with [ T=boost::detail::operator_arrow_result,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::value_type,boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::reference,boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::pointer>::type ] Conversion loses qualifiers c:\boost\include\boost-1_32\boost\iterator\iterator_facade.hpp(325) : while compiling class-template member function 'boost::detail::operator_arrow_result::type boost::detail::operator_arrow_result::make(Reference)' with [ ValueType=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::value_type, Reference=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::reference, Pointer=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::pointer ] c:\boost\include\boost-1_32\boost\iterator\iterator_facade.hpp(642) : see reference to class template instantiation 'boost::detail::operator_arrow_result' being compiled with [ ValueType=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::va lue_type, Reference=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::reference, Pointer=boost::iterator_facade,std::basic_string,std::allocator>::const_iterator,std::string>,std::string,boost::detail::minimum_category::type>::type,const std::string &>::pointer ] c:\boost\include\boost-1_32\boost\token_iterator.hpp(41) : see reference to class template instantiation 'boost::iterator_facade' being compiled with [ Derived=boost::token_iterator,std::basic_string,std::allocator>::const_iterator,std::string>, Value=std::string, CategoryOrTraversal=boost::detail::minimum_category::type>::type, Reference=const std::string & ] c:\boost\include\boost-1_32\boost\date_time\date_parsing.hpp(119) : see reference to class template instantiation 'boost::token_iterator' being compiled with [ TokenizerFunc=boost::char_delimiters_separator, Iterator=std::basic_string,std::allocator>::const_iterator, Type=std::string ] c:\boost\include\boost-1_32\boost\date_time\gregorian\parsers.hpp(24) : see reference to function template instantiation 'date_type boost::date_time::parse_date(const std::string &,int)' being compiled with [ date_type=boost::gregorian::date ] Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

6 12

Boost.FileSystem, problem with exists()
by Martin Slater 06 Dec '04

06 Dec '04

Hi, I've been using boost.filesystem and have come up on a problem with exists(). Basically on a windows system it will return true if asking whether a file exists on a non-existent share. The problem is at, operations_posix_windows.cpp:327. There should (?) be an additional check against ERROR_BAD_NETPATH as well. The fuzziness of this function is quite disturbing as shown by the following comment in the code return false; // GetFileAttributes failed because the path does not exist // for any other error we assume the file does exist and fall through, // this may not be the best policy though... (JM 20040330) The windows docs don't really help that much by not specify exactly what the failures can be though. Personally I think it should always return false on GetAttributes() error to avoid false positives and the expense of the possible false negatives, but we need a list of all possible errors to be sure that this is the right thing to do. Oh and any chance you can put in serialization support for boost::filesystem::path? I've done it locally and the code is trivial but it would be nice to have it out the box. Anyhow, thanks for a great library (filesystem and the rest of boost). cheers martin

2 2

A few more filesystem documentation corrections
by Edward Diener 06 Dec '04

06 Dec '04

Here are a few more grammatical corrections to the excellent filesystem documentation. Default Name Check mechanism Dangers second sentence: "Since global variables are considered harmful [Wulf-Shaw-73], class path allows the default name check function can be set only once, and only before the first use." should be: "Since global variables are considered harmful [Wulf-Shaw-73], class path allows that the default name check function can be set only once, and only before the first use." or "Since global variables are considered harmful [Wulf-Shaw-73], class path allows the default name check function to be set only once, and only before the first use." Rationale Const vs non-const returns last sentence: "A requirement that path::iterator not be a non-class type was added to eliminate errors non-const iterator errors." should be: "A requirement that path::iterator not be a non-class type was added to eliminate non-const iterator errors." or better: "A requirement that path::iterator be a class type was added to eliminate non-const iterator errors." Finally, in operations.hpp, links on "class directory_iterator" and "other functions" to their explanations further down the page do not work using IE, Netscape, or Opera, so I imagine some HTML error.

2 1

Filesystem documentation error
by Edward Diener 06 Dec '04

06 Dec '04

The documentation to filesystem is outstanding. Congratulation Mr. Dawes ! I did find an error, however. In the class documentation to path.hpp there are two default_name_check member functions. In the specific documentation for default_name_check, there is only a single default_name_check mentioned and the return value in the declaration of the specific documentation has 'void' even while the "Returns:" says otherwise and correctly matches the return value given for either one of the default_name_checks given in the class documentation.

2 1

BOOST_FOREACH questions
by Vladimir Prus 05 Dec '04

05 Dec '04

Eric, I've some questions about BOOST_FOREACH (which is pretty cool, BTW). 1. Is it possible to use typeof on gcc, to avoid any possible overhead? While you've posted some results which show that gcc generally can optimise it very well, I'd like to be 100% sure). Something like: #define FOR_EACH(var, container) \ for(typeof(container.begin()) _for_each_i = container.begin(),\ _for_each_e = container.end();\ _for_each_i != _for_each_e; ++_for_each_i)\ if(bool _for_each_continue = false) {}\ else\ for(var = *_for_each_i; !_for_each_continue; _for_each_continue=true) which works perfectly for me. 2. Any chance that BOOST_FOREACH((pair<int, int> p), container) will work? I don't know how to make it work without require paranthethis in all cases, but maybe there's a smart trick. 3. Is it possible that you place this to sandbox, for easier access? - Volodya

7 31

[Boost-bugs] [ boost-Bugs-1079444 ] type_traits headers use #include ""
by SourceForge.net 05 Dec '04

05 Dec '04

Bugs item #1079444, was opened at 2004-12-05 08:59 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=1079444&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: type_traits headers use #include "" Initial Comment: The various type_traits headers (as of boost 1.32.0) use #include "" directives while the rest of boost headers uses #include <>. For example the use of #include "" in boost/type_traits/ add_reference.hpp compared to the use of #include <> in boost/ mpl/bool.hpp . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1079444&group_… ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Deserialization issue
by Jared McIntyre 05 Dec '04

05 Dec '04

I have a class that I am serializing using the non-intrusive method. It serializes just fine, but when I code the input stream, the compiler complains that the class doesn't implement the serialize function (which is, of course, true since I'm am doing the non-intrusive method on this class). Any idea what could be going wrong? The class I'm wrapping is being serialized as part of another class (if that helps at all). Visual Studio 7.1 Boost 1.32.0 tar ball Wide character XML output Jared McIntyre

2 7

Front page redesign...
by Rene Rivera 05 Dec '04

05 Dec '04

Fellow Boosters, Well I must say I've been smiling all day :-) Thanks for the encouraging feedback. And I've been putting finishing touches on my design hopefully coming up with something everyone can enjoy. I have two different sample for you to gander at. The first is the simple clean version... http://redshift-software.com/~grafik/boost/index.htm The second adds some background flair to the page... http://redshift-software.com/~grafik/boost/index_code.htm And for those with CSS switching browser, there's an alternate CSS on each of those which displays the page without any CSS. Just to show that everything is done in thee CSS ;-) Enjoy. Have a good weekend, and all that. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

17 64

[1.32] SunPRO build failures
by Caleb Epstein 04 Dec '04

04 Dec '04

% CC -V CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-20 2004/03/19 Sorry, I should have been testing this toolset earlier in the release process, but now that the official 1.32.0 is out and I've tried building it with the crufty old Sun CC, I've encountered a handful of errors and perhaps two valid warnings. The first is in date_time. It appears that Rogue Wave's std::locale::facet has an undocumented abstract virtual method __get_id. Attached is a patch which adds this method when building with SUNPRO_CC and RWSTD. This may be better done with some BOOST_* config macros, I'm not sure. There are several other errors in filesystem, program_options, serialization, and signals which manifest themselves as errors resolving overloads of iterator_traits. I'm attaching the output from my build as I'm unsure how to address these issues. Also, in archive/impl/basic_xml_grammar.hpp, the compiler warns that the StringType typedef is not accessible from the public interface of basic_xml_grammar (e.g. in the return_values struct). Making this one typedef public fixes this issue. Finally, the compiler warns about the "static" being anachronistic in boost_1_32_0/boost/smart_cast.hpp, lines 264 and 292 (the free functions smart_cast and smart_cast_reference). I think the compiler may actually be correct - what purpose does "static" serve here? I know this is a crufty toolset, but this code (at least date_time and filesystem) used to build with 1.31.0. -- Caleb Epstein caleb dot epstein at gmail dot com

8 28