- Boost - lists.preview.boost.org

Re: [boost] Interest in an ODBC library?
by Brian Braatz 02 Aug '05

02 Aug '05

Joaquin, sorry for the few days response here- I had a "surprise" business trip I had to take which kept me out of town and away from mail for a few days Thoughts below (note- I have left a good chunk of the original mail intact for context) > -----Original Message----- > On Behalf Of Joaquin M Lopez Munoz > > Brian Braatz <brianb <at> rmtg.com> writes: > > If you would please elaborate. (some of us are "slower" than others :) > > ). > > > > is the problem getting to the index objects themselves via > > inherit_linearly? > > > > if you have dynamic data, then I am thinking you also have dynamically > > applied indices? > > > > Maybe I can elaborate- > > > > consider the following pseudo code: > > > > connection con = db.connect("myserver,root,password,mydatabase"); > > > > dynamic_table dt; > > > > // the select "*" means bring me back all the fields from that table > > // even though I don't know what the fields ARE yet > > dt = query("select * from person"); > > > > // ok so now dt has an UNKNOWN number of columns > > > > dt.add_index( index("first_name")); > > > > // or something along those lines. > > > > in this case, the index is applied dynamically. > > > > so how does that connect with the things you said ? > > > [Joaquin M Lopez Munoz Writes:] > Let me formulate the problem in the terminology > of Boost.MultiIndex --hopefully, the implications > for a DB framework scenario will be clear after this. > > Consider the following perfectly normal code dealing > with a static multi_index_container: > > typedef multi_index_container< > element, > indexed_by< > ordered_unique<identity<element> >, > sequenced<> > > > > static_mic_t; > > template<typename Index> > void reverse_dump(const Index& i) > { > std::copy( > i.rbegin(),i.rend(), > std::ostream_iterator<typename Index::value_type>(std::cout)); > } > > int main() > { > static_mic_t s_mic; > ... > reverse_dump(s_mic.get<0>()); > reverse_dump(s_mic.get<1>()); > } > > What would the equivalent be for the dynamic case? > > typedef dynamic_multi_index_container< > element > > dynamic_mic_t; // no indices specified at compile time > > int main() > { > dynamic_mic_t d_mic; > > // add indices at run time > d_mic.add_index<ordered_unique<identity<element> > >(); > d_mic.add_index<sequenced<> >(); > ... > > reverse_dump(d_mic.get(0)); // note index number is no longer > reverse_dump(d_mic.get(1)); // a template parameter > } > > Now, how are we supposed to define reverse_dump? Clearly > it cannot be the same template as in the static case, > since the types of the indices are only known at > run time. [Brian Braatz Writes:] ideas- have the container accept a list of possible index types then use inherit_linearly<> to make those types- (only as pointers) then when the index gets runtime added- you store it in the generated objects Additionally- one could also force the user to make a struct to use as a tag to reference the index (instead of the number) using this "type tag", you can lookup the runtime object(s) which were dynamically added. What I am suggesting is a similar design to what I recently got working on something else (almost ready for sharing with the world). I have yet another plan trip tomorrow (ALL DAY tomorrow). I will code a small sample of what I am suggesting. (code is easier to talk about than concepts sometimes :) ) Joaquín M López Muñoz writes: > If I wasn't clear enough please tell me so and > I'll try to elaborate. I'll be more than happy to > discuss and refine these ideas. IMHO the concepts > around a potential multi_index_container sketched > here can serve as the basis for a DB run-time data > structure, much like for instance IndexedDBView in the > DTL does. > > Best, > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo I am not as familiar with multi-index, but I am going to re-re-rereview that lib tomorrow along with the mail you wrote. Pleasure "talking" with you :) Brian

1 0

Still Can't Build Docs
by David A. Greene 02 Aug '05

02 Aug '05

I'd like to put the NTP library up on the sandbox but I need to be able to build documentation first. I updated to the latest CVS, build bjam and here's what I get: >>-waller-> which bjam /home/greened/bin/bjam >>-waller-> pwd /home/greened/src/boost/doc >>-waller-> bjam --v2 warning: Python location is not configured warning: the Boost.Python library won't be built 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). /home/greened/src/boost/tools/build/v2/tools/boostbook.jam:319: in object(boostbook-generator)(a)1.run warning: rulename $(base-target).depends expands to empty string /home/greened/src/boost/tools/build/v2/build/generators.jam:826: in try-one-generator-really /home/greened/src/boost/tools/build/v2/build/generators.jam:873: in try-one-generator /home/greened/src/boost/tools/build/v2/build/generators.jam:1080: in construct-really /home/greened/src/boost/tools/build/v2/build/generators.jam:1139: in generators.construct /home/greened/src/boost/tools/build/v2/build/targets.jam:1242: in construct /home/greened/src/boost/tools/build/v2/build/targets.jam:1128: in object(typed-target)(a)22.generate /home/greened/src/boost/tools/build/v2/build/targets.jam:757: in generate-really /home/greened/src/boost/tools/build/v2/build/targets.jam:730: in object(main-target)(a)1.generate /home/greened/src/boost/tools/build/v2/build/targets.jam:252: in object(project-target)(a)17.generate /home/greened/src/boost/tools/build/v2/build-system.jam:276: in load /home/greened/src/boost/tools/build/v2/kernel/modules.jam:259: in import /home/greened/src/boost/tools/build/v2/kernel/bootstrap.jam:153: in boost-build /home/greened/src/boost/boost-build.jam:12: in module scope /home/greened/src/boost/tools/build/v2/tools/boostbook.jam:324: in object(boostbook-generator)(a)1.run warning: rulename $(target[2]).set-path expands to empty string /home/greened/src/boost/tools/build/v2/build/generators.jam:826: in try-one-generator-really /home/greened/src/boost/tools/build/v2/build/generators.jam:873: in try-one-generator /home/greened/src/boost/tools/build/v2/build/generators.jam:1080: in construct-really /home/greened/src/boost/tools/build/v2/build/generators.jam:1139: in generators.construct /home/greened/src/boost/tools/build/v2/build/targets.jam:1242: in construct /home/greened/src/boost/tools/build/v2/build/targets.jam:1128: in object(typed-target)(a)22.generate /home/greened/src/boost/tools/build/v2/build/targets.jam:757: in generate-really /home/greened/src/boost/tools/build/v2/build/targets.jam:730: in object(main-target)(a)1.generate /home/greened/src/boost/tools/build/v2/build/targets.jam:252: in object(project-target)(a)17.generate /home/greened/src/boost/tools/build/v2/build-system.jam:276: in load /home/greened/src/boost/tools/build/v2/kernel/modules.jam:259: in import /home/greened/src/boost/tools/build/v2/kernel/bootstrap.jam:153: in boost-build /home/greened/src/boost/boost-build.jam:12: in module scope /home/greened/src/boost/tools/build/v2/tools/boostbook.jam:325: in object(boostbook-generator)(a)1.run warning: rulename $(target[2]).depends expands to empty string /home/greened/src/boost/tools/build/v2/build/generators.jam:826: in try-one-generator-really /home/greened/src/boost/tools/build/v2/build/generators.jam:873: in try-one-generator /home/greened/src/boost/tools/build/v2/build/generators.jam:1080: in construct-really /home/greened/src/boost/tools/build/v2/build/generators.jam:1139: in generators.construct /home/greened/src/boost/tools/build/v2/build/targets.jam:1242: in construct /home/greened/src/boost/tools/build/v2/build/targets.jam:1128: in object(typed-target)(a)22.generate /home/greened/src/boost/tools/build/v2/build/targets.jam:757: in generate-really /home/greened/src/boost/tools/build/v2/build/targets.jam:730: in object(main-target)(a)1.generate /home/greened/src/boost/tools/build/v2/build/targets.jam:252: in object(project-target)(a)17.generate /home/greened/src/boost/tools/build/v2/build-system.jam:276: in load /home/greened/src/boost/tools/build/v2/kernel/modules.jam:259: in import /home/greened/src/boost/tools/build/v2/kernel/bootstrap.jam:153: in boost-build /home/greened/src/boost/boost-build.jam:12: in module scope /home/greened/src/boost/tools/build/v2/build/targets.jam:1245: in construct from module object(typed-target)@22 error: unable to construct ./doc /home/greened/src/boost/tools/build/v2/build/targets.jam:1128: in object(typed-target)(a)22.generatefrom module object(typed-target)@22 /home/greened/src/boost/tools/build/v2/build/targets.jam:757: in generate-really from module object(main-target)@1 /home/greened/src/boost/tools/build/v2/build/targets.jam:730: in object(main-target)(a)1.generate from module object(main-target)@1 /home/greened/src/boost/tools/build/v2/build/targets.jam:252: in object(project-target)(a)17.generate from module object(project-target)@17 /home/greened/src/boost/tools/build/v2/build-system.jam:276: in load from module build-system /home/greened/src/boost/tools/build/v2/kernel/modules.jam:259: in import from module modules /home/greened/src/boost/tools/build/v2/kernel/bootstrap.jam:153: in boost-build from module /home/greened/src/boost/boost-build.jam:12: in module scope from module I edited tools/build/v2/user-config.jam to use the gcc toolset. Any ideas? -Dave

1 0

[1.33.0] Partial thaw on branch for fixing the remaining failures
by Doug Gregor 02 Aug '05

02 Aug '05

The RC_1_33_0 branch is partially thawed so that we can fix the remaining failures for release. I've started the regression notifications again, this time on the release branch: when no more failures show up, we release. Library authors: for any failures that you will not fix, mark them as expected failures on the branch. If you believe there is a configuration problem on one of the test machines, write to the list to say what you think is going on and we'll try to get it fixed. The list of issues we need to fix before we can release is here: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/ developer/issues.html Doug

8 15

[1.33.0] 300+ Broken links
by Jonathan Turkanis 01 Aug '05

01 Aug '05

Hi, I ran a shareware HTML link checker on release candidate 1, and found 334 broken links; I'm attaching the report. A few of them appear bogus ("Error: invalid syntax"), and some appear to reflect the temporary unavailability of news.gmane.org, but most appear legitimate. I'll volunteer to fix as many of them as I can, if it's not too late to make it into the relapse. Some I can't fix, because I don't know where they're supposed to point. Here are the affected areas of Boost: Libraries: - compatibility - conversion - crc - date_time - disjoint_sets - filesystem - format - function - graph - hash - iterator - math - minmax - multi_index - numeric/conversion - numeric/interval - numeric/ublas - parameter - preprocessor - property_map - ptr_container - python - random - range - rational - regex - serialization - smart_ptr - spirit - test - threads - timer - tuple - type_traits - utility - variant - wave Tools: - build (v1 + v2) - boostbook Misc: - index.htm - doc/html/index.html - doc/html/who_s_using_boost_.html - doc/html/who_s_using_boost_/open.html - more/discussion_policy.htm - more/mailing_lists.htm - more/test_policy.htm - more/background.html - more/bibliography.html - more/cpp_committee_meetings.html - more/error_handling.html - more/formal_review_schedule.html - more/generic_exception_safety.html - more/generic_programming.html - more/getting_started.html - more/regression.html - more/version_history.html - more/writingdoc/template/definitions.html - people/darin_adler.htm - people/dietmar_kuehl.htm - people/jonathan_turkanis.htm - people/mark_rodgers.htm - people/people.htm - people/ralf_w_grosse_kunstleve.htm - people/vesa_karvonen.htm Jonathan

1 0

[Boost-bugs] [ boost-Patches-1249809 ] Minor spell errors on lambda_functor_base.hpp header
by SourceForge.net 01 Aug '05

01 Aug '05

Patches item #1249809, was opened at 2005-08-01 16:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1249809&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: Duilio J. Protti (dprotti) Assigned to: Nobody/Anonymous (nobody) Summary: Minor spell errors on lambda_functor_base.hpp header Initial Comment: Attached is the patch with the corresponding corrections. The patch is not just for /boost/lambda/detail/lambda_functor_base.hpp file, but also for lambda_fwd.hpp. Bye, Duilio Protti. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1249809&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1160158 ] Perl style foreach iterating
by SourceForge.net 01 Aug '05

01 Aug '05

Patches item #1160158, was opened at 2005-03-09 17:05 Message generated for change (Comment added) made by dprotti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1160158&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: Amir Taaki (genjix) Assigned to: Nobody/Anonymous (nobody) Summary: Perl style foreach iterating Initial Comment: somewhere in boost, there should be a perl style foreach iterator, like so #define ITERATOR(obj) typeof(obj.begin()) #define foreach(v,i) for(ITERATOR(v) i = v.begin() ; i != v.end() ; i++) genjix at gmail.com ---------------------------------------------------------------------- Comment By: Duilio J. Protti (dprotti) Date: 2005-08-01 16:52 Message: Logged In: YES user_id=1012656 There is something like that. In fact, there is something much better, take a look at this article: http://www.informit.com/articles/article.asp?p=400651 About your submission, it's not a patch, is more like a feature request, so this is not the correct place to post it. Regards, Duilio Protti. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1160158&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

VC8?
by Daryle Walker 01 Aug '05

01 Aug '05

I don't use Visual C++, but people here talk like VC8 is still in beta. So why are we treating it like a supported compiler? Shouldn't we wait for VC8 to be finalized? (That means telling users to wait until 1.34 or stay with VC7.1.) Aren't there several VC8 betas being used by people here? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

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

01 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-08-01T15:32:34Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 1 failure in 1 library: thread (1) |thread| test_thread_lib: vc-6_5-stlport

1 0

Diff between variant and any?
by Neal Becker 01 Aug '05

01 Aug '05

In a nutshell, what is the difference between boost::variant and boost::any?

2 1

[1.33.0] Important: vc-6_5-stlport failure in Threads test
by Doug Gregor 01 Aug '05

01 Aug '05

Michael, This test is failing intermittently. Do you have any idea what could be going wrong? http://tinyurl.com/d2q9g Doug

1 0

Re: [boost] singleton and thread safety
by Martin Bonner 01 Aug '05

01 Aug '05

----Original Message---- From: Jason Hise [mailto:chaos@ezequal.com] Sent: 01 August 2005 02:35 To: boost(a)lists.boost.org Subject: [boost] singleton and thread safety > I need to ensure that certain objects (specifically the policy bundles > which manage singleton instances) are created in a thread-safe manner. > First question: Can two threads both initialize the same static > variable if they pass through the same function at the same time? Ex: > > void foo ( ) > { > static Thing t; > } > > Can t's constructor be called twice by two threads executing foo? The standard is silent on the issue (because it doesn't address threading). You would need to consult the documentation of each supported compiler. I can't find the documentation for VC7.1, but looking at the generated code, it appears that t's constructor CAN be called twice. > If so, I feel that I need to construct my policy bundles before > execution enters main, a time when it is pretty much guaranteed that > the application is operating in a single-threaded context. I thought > that this would be simple to do: just write a class that calls the > function with the static variable in its constructor and create > a global instance of that class. However, the standard appears to > say that initialization of such global variables can happen after main > is entered, so long as it happens before the global variable is used. # It does say that. In practise (and ignoring DLLs), no implementation takes advantage of that freedom. This is because it is quite easy to set up situations where A must be initialized before B, but B must also be initialized before A. (If the initialization occurs before main(), then the guarantees which cause the problem don't apply). > If the program starts > spawning threads before the global variable is constructed I would > still have the same problem. > > How can I ensure that initialization is performed before main is > entered? It is almost certainly safe to assume that globals are initialized before main is entered (ignoring dynamic libraries). If you don't want to ignore dynamic libraries, I am not sure how to proceed (except to say that it is tricky)! > If I cannot, is there some other way to make initialization > of static variables thread-safe? Lock a mutex. > I cannot lock a mutex to manage this, > because the mutex lives inside the threading policy instance and the > threading policy instance lives in the policy bundle that I am trying > to create in the first place. :-) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Boost regression notification (2005-07-31)
by Douglas Gregor 01 Aug '05

01 Aug '05

Boost regression test failures ------------------------------ Report time: 2005-07-31T16:16:22Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 31 failures in 1 library: serialization (31) |serialization| test_class_info_load_text_warchive_dll: vc-6_5 test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: vc-6_5 vc-6_5-stlport vc-7_0 test_demo_fast_archive_dll: vc-6_5 test_demo_pimpl_dll: vc-6_5 vc-7_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-9_0 test_demo_shared_ptr_dll: vc-6_5 vc-7_0 test_map_binary_archive_dll: vc-6_5 vc-7_0 test_map_text_archive_dll: vc-6_5 vc-7_0 test_map_text_warchive_dll: vc-6_5 vc-7_0 test_mult_archive_types_dll: vc-6_5 test_non_intrusive_binary_archive: vc-8_0 test_shared_ptr_132_xml_archive_dll: intel-win32-8_1

4 3

Review Schedule
by Tom Brinkman 01 Aug '05

01 Aug '05

I've started to compile the next review schedule. Please contact me if would like to be a review manager volunteer or have any other thoughts about the schedule or the libraries. I will try to get the next batch of reviews started in the next month or soo. I will post a review wizard status report in the next couple of weeks. Tom Brinkman Review Wizard reportbase(a)gmail.com

1 0

[Unicode] Some code for y'all
by Erik Wien 31 Jul '05

31 Jul '05

Hi. I finally got a few days off this weekend, so I used them to prepare a version of the Unicode library I have written so you guys can take a look at it. This is unfortunately a snapshot of the state of things a good while back, but it's the only somewhat stable version I could find in the hurry. The basic design hasn't changed much though, so it should work just fine for getting an idea of how things work. A download of the complete library, along with a *short* (and very high-level) description to help you along can be found at the site http://unicode.irritert.net. Sorry I couldn't provide you with any in-depth documentation or stuff like that right now, but you should be able to figure it out if you really want to. ;) Anyway, Feel free to comment on anything that might spring to mind. I'll try to check back now and again to answer any questions. - Erik

1 0

Re: [boost] [Serialization] Boost regression notification (2005-07-31)
by JOAQUIN LOPEZ MU?Z 31 Jul '05

31 Jul '05

----- Mensaje original ----- De: Douglas Gregor <doug.gregor(a)gmail.com> Fecha: Domingo, Julio 31, 2005 10:06 pm Asunto: Re: [boost] [Serialization] Boost regression notification (2005-07-31) > > On Jul 31, 2005, at 12:00 PM, Douglas Gregor wrote: > > 31 failures in 1 library: > > serialization (31) [...] > > I've gone through and marked up all of these, except this one > strange > regression: > > http://tinyurl.com/ajprh > > Looking at the output of the test, I don't even seeing an error. > To > make things more interesting, the other vc-8_0 tester isn't having > any > problem. Ideas, anyone? > This looks pretty much like some spurious errors I've been observing in Boost.MultiIndex tests for this same platform: no error indication or anything. The fun part is that these errors only show every so often and then disappear, so it'll probably vanish away on the next regression cycle. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS (OT): Excuse my insistence, but a post of mine about an (IMHO) outdated piece of info in the getting started page have received no response: http://lists.boost.org/boost/2005/07/31129.php I can't change the thing myself, I don't have CVS access during these days. Thank you, J

1 0

CVS Locked?
by David A. Greene 31 Jul '05

31 Jul '05

The threads library seems to be iniaccessible via CVS: cvs update: [20:11:39] waiting for agurtovoy's lock in /cvsroot/boost/boost/libs/thread This has been going on for about an hour now... -Dave

1 0

Building Docs
by David A. Greene 31 Jul '05

31 Jul '05

I'm trying to write documetation for NTPs using Boostbook but I'm having trouble. The Boostbook docs say that changing to boost/doc and running bjam --v2 should build the documentation, but; >>-waller-> pwd /home/greened/src/boost/doc >>-waller-> bjam --v2 /home/greened/src/boost/tools/build/v2/tools/package.jam:72: in package.install rule stage.install unknown in module package. ../Jamfile.v2:140: in load-aux /home/greened/src/boost/tools/build/v2/build/project.jam:310: in load-jamfile /home/greened/src/boost/tools/build/v2/build/project.jam:68: in load /home/greened/src/boost/tools/build/v2/build/project.jam:111: in load-parent /home/greened/src/boost/tools/build/v2/build/project.jam:389: in initialize /home/greened/src/boost/tools/build/v2/build/project.jam:292: in load-jamfile /home/greened/src/boost/tools/build/v2/build/project.jam:68: in project.load /home/greened/src/boost/tools/build/v2/build-system.jam:80: in load /home/greened/src/boost/tools/build/v2/kernel/modules.jam:259: in import /home/greened/src/boost/tools/build/v2/kernel/bootstrap.jam:120: in boost-build /home/greened/src/boost/boost-build.jam:12: in module scope I know almost nothing about Jam so these errors don't mean much to me. For NTPs, the source uses Doxygen comments so I plan to follow the guidelines for Doxygen use with Boostbook. I've found a number of Jamfile.v2s for different libraries that seem to use Doxygen, but I'm not entirely clear how the other bits of documentation (introduction, rationale, etc.) get integrated. The Boostbook documentation is rather sparse about Doxygen use. Can anyone guide me with this? -Dave

1 0

Re: [boost] Call for interest for native unicode character and string support in boost - updated definition
by Graham 31 Jul '05

31 Jul '05

>From: Rogier van Dalen <rogiervd(a)gmail.com> >Subject: Re: [boost] Call for interest for native unicode character and string support in boost - updated definition >Hi Graham, >I fear we might be heading off in a new direction here. I think enabling third parties to add codepoints, >if desirable at all (I still have my sincere doubts) should not be a primary concern. >I propose we focus on the interface first, and leave out the implementation bits. I have been working with Unicode for many years and cannot envisage any serious Unicode implementation where private characters are not required. I have given examples: Private characters like buttons, like wrapping markers for Thai, streaming format changes, etc. etc. Each developer will need to be able to customise it - after all how can you support Unicode but decide to ignore private characters that are part of the Unicode spec ! >Discussing the implementation, I'm afraid, will just make the discussion unclear, as I'll show by pointing out some things once. >- as for the "functions" struct, do you realise that C++ has a built-in feature called "virtual functions" to do things like this? Interesting you raise this point. I started off as an interface but hit a major problem - performance. I tried wrapping 100,000 words and the interface took a hell of a hit due to the way in which the compiled code takes the interface and then offsets to the member to call a function on the interface. So I looked at being able to access the function on the interface directly - this proved to be impossible via a static function and you cannot have statics being implemented on an interface and no better if you wrap an interface call using mem_fun. Then I considered how I would modify one function, like sort, without ANY performance hit - and ended up with what I had. How the hell can you do it more neatly without a performance hit? I am open to suggestions. Do not forget we must be able to optimise this for times when this interface will be hit millions of times per second - and yes this is something I have done a number of times in real life - e.g. formatting of live data feeds - and this must be a primary concern in the design. - Have you realised what happens when deque<>::iterators, or any other iterators to containers with non-contiguous elements, are fed into the get_uppercase method with the current implementation? What about iterators that process UTF-8 and pretend it to be a UTF-32 sequence? The implementation will work on any non-contiguous iterator as written, after all the single iterator version increments/ decrements the iterator then de-refs it. Of course from bitter experience I can tell you that working with a single iterator and not caching the values is a massive performance hit. - Do you realise that inline functions are not macros and thus need no backslashes at the end of lines? Sorry - I went through a number of iterations to try and get the code you saw - in one of the iterations I tried to inline the functions. >The implementation won't help discussing the interface, so I think we'd better leave them out for now I am actually finding that the snapshots I have included are important as they can help to reveal why the implementation might not work and what we can do about it. > >BTW, now looking at the code: do you fully realise how iterators work? >It seems to me that >StartOfGrapheme(functions* pFns, inputIterator chPrev, inputIterator ch, inputIterator chNext) is not really needed, >because it is quite easy to find an iterator to the next and previous position given the current one. That is correct(ish) - but processor intensive - I have had real problems when you process a document from a data feed and wrap it for storage in a database. As an example on a ".4 Gig Pentium 4 I have seen this take up to six seconds [depending on the text - and we were handling some large text documents] when fully optimised - and that required a lot of profiling to get the best performance. Wrapping a full document for the first time requires a lot of processing and you cannot just increment and decrement iterators - as I said in my previous e-mail [the one today, after the e-mail to which you have replied] the only way of doing this with reasonable performance is to have three iterators that get shuffled along. Remember these are really low level functions and get hit very heavily and often. >Please find attached a modified version of the header. Changes are: >- It now looks like C++: superfluous semicolons are deleted and identifiers are lowercase with underscores; This will mean altering the automatic conversion of the Unicode names to this form C++ names but this should not be a problem stripping out the upper case a replacing spaces and - with _. >- the last "uni" prefixes have been removed; >- it does not show the implementation any more; Unfortunately you seem to have fallen into the great trap of iterators. The code can no longer be used to/ from third party DLLs, please see my post of earlier today. Iterators do not work unless you have all the source code - which means that third party DLLs containing custom controls will not work with your changes. This would be a major step backwards as grid controls are a major business and many are shipped without source, just as DLLs with a defined interface. You cannot use an iterator across such a boundary - please see my previous code for an example of how I have ensured that it WILL work with third party DLLs such as grid controls without every DLL from a different company having to have it's own Unicode data. The implementation shown demonstrated how to do this and was included for that reason. >- I corrected some spelling errors, possibly introduced new ones (seperable is spelled sepArable, isn't it? I'm not 100% sure); >- a get_category() function is defined to get the general General Category (i.e. letter, mark, number, etc.) I have just realised that all the category enums need to be placed in a single enum as they are in fact in a single data space so your get_category becomes the single category call. >- I deleted the page0() function because I didn't see why it should be there (feel free to move it back in if I missed something). OK >- I provided only iterator-based grapheme, word and sentence skipping functions; This will not work across third party code when you don't have the source. Means you cant have any more grid control DLLs etc in Unicode unless they contain all the Unicode data separately or you insist that all suppliers have to sell their DLLs as source code. >- I provided a locale with a few lines sketching an idea of what a collation object should look like. Did you realise that string comparison should likely be passed to a function or >container as a comparison object? For example, my specification would allow: > >// Some container c of strings >// Some string s >std::lower_bound (c.begin(), c.end(), s, unicode::default_locale().collate_accents()); > >Any comments are, of course, most welcome! We need to make a collation object that is container independent as there are going to be several Unicode containers - not just one. We must therefore separate collation from container. It must work with third party DLLs where you don't have the source code so iterators are out. The collate_accents call is strange - I don't understand why you don't just pass a locale in. For example some languages sort <ae> differently and this is not an accent. I would therefore just pass in a uint32_t for the locale. Any thoughts? Yours, Graham

2 1

[1.33.0] Where is Logo???
by Pavel Chikulaev 31 Jul '05

31 Jul '05

Hello boosters, We only have some hours before release but the logo we all chose is not on the home page yet... What's happening? Or that logo was chosen for 1.34? -- Pavel Chikulaev

2 1

[regex] begin-/end-line need to be customizable via traits
by Eric Niebler 31 Jul '05

31 Jul '05

I think there is a problem in the regex standardization proposal regarding the begin- and end-of-line assertions (^ and $). It seems that there is no way to customize their behavior via the traits. This is inconsistent with the word boundary assertion, which is implementable in terms of the word character class (\w). The author of a traits class should be able to specify which characters are line separators. A simple fix would be to add a character class for line separator characters. Then, ^ and $ could be implemented in terms of lookup_classname and isctype, just as the word boundary assertion is. This leaves out an important corner case, though: \r is a line separator only if it is not immediately followed by a \n. I haven't yet come up with a traits interface that clean enough and general enough to satisfy. I'm open to suggestions. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

[Boost-bugs] [ boost-Support Requests-1248497 ] borland builder 6 compiler error
by SourceForge.net 31 Jul '05

31 Jul '05

Support Requests item #1248497, was opened at 2005-07-31 14:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1248497&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: hamid r. najafi (hrnajafi) Assigned to: Nobody/Anonymous (nobody) Summary: borland builder 6 compiler error Initial Comment: I want used BOOST in my projects. But I can't compile BOOST with Borland Builder 6. For example I'm compiled (ROOT)\libs\graph\example\print-adjacent- vertices.cpp and compiler reports more than 26 error. please see attached file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1248497&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Call for interest for native unicode character and string support in boost - updated definition 3
by Graham 31 Jul '05

31 Jul '05

Dear Rogier, >> What do you think? I am happy to go to uint16_t and limit to 4 levels as >> this is a reasonable performance/ implementation trade-off that I have >> previously used with success. >I hadn't thought of that, actually. But as for the sort keys: I was >actually thinking of packing the key *with* the string, so that the >string itself can be used as a tie-breaker (cos that's what you need >the 32 bits for, isn't it?). >class string_with_sort_key >{ > const string s; > std::vector <uint16_t> sort_key; >public: > string_with_sort_key (const string &); >}; >This would make a good key for, say, std::map: it woul implicitly >converting from string when required, e.g. when calling "find" with a >string. I think the string itself would be needed in case another >locale is required, and as a tie-breaker, but I haven't fully thought >this through yet. What do you think about this? Yes - almost exactly what I had in mind. We can then use the sort data to level 4 with uint16_t and the string is present. The final flourish might be to have a version that has the canonical decom of the string present as well for times when you hit a sort tie. I have never needed to handle a sort tie in this way, but we have the flexibility under this scheme to even have two classes string_with_sort_key and string_with_sort_key_and_decomp as this is just a wrapper round the actual processing call and developers can then use whichever they prefer for the memory/ complexity tradeoffs on their system. >> >done without producing sort keys. >> >> String equality [=] would be handled directly using on the fly >> comparison of canonically decomposed forms as I previously mentioned, >> and as you correctly mention. >> >> String equivalence [<] would be handled using sort level 4+. >I'd rather use binary comparison for the normal operator< and >operator==: that's what the Unicode standard recommends for speed >(5.18). For UTF-8 and UTF-32 it's as fast as normal string comparison, >and for UTF-16 it's only slightly slower. C++ has this habit of >passing comparison objects (like std::less) to algorithms and >containers that would nicely fit in with the need for locales. >Basically, a "collate" object would contain the information needed to >compare strings for a given locale on a certain level. Fine - I don't have a problem with it - the only reason that I have prevented it in the past was to ensure good programming practice [i.e. force use of the collation version] at the cost of removing the simple version. >I'm not sure I see what you mean, sorry. I'd probably have to see the >code. If I am correct, however, for advancing to the next grapheme >boundary you don't need a "previous" iterator, because it only has a >look-back (if that's the antonym of lookahead) of one character max. I used to think that I only needed two characters [current and next] for grapheme testing but then I hit some oddities. To do a reliable test you actually do need the previous character for: <cr><lf> as opposed to <lf> i.e. 123<lf>, the <lf> is a grapheme start but 123<cr><lf> the <lf> is not a grapheme start Hangul syllable sequences Base char + virama + letter And a few of the others... >Whoops... I'm only now starting to see that we probably have slightly >different headers in mind: I'm thinking of what the user needs, you're >thinking of what the "database" needs... sorry I didn't realise that. >Obviously, the DLL shouldn't use iterators, and should probably have, >well ermmm, just about the interface you propose. Hopefully this >realisation will get us somewhere because I'm sure any iterator type >can be used for processing, even if the database returns plain >pointers. It'll probably mean the database interface should be as >low-level as possible and any smarts should be outside it. These >should definitely be different header files, too... >For example, I think the database (DLL) should provide the >Grapheme_Cluster_Break property for every character; the actual >algorithm could be templated, allowing any iterator to be used. Great - this is an extremely important breakthrough in mindset - you have a fixed interface for sharing round third party DLLs etc, but can write templated iterators around the interface calls. >> ... >> > (I don't think "next" is >> needed for the grapheme_cluster case anyway.) > >Correcting myself: I meant to say "previous" rather than "next", but see up. Moving a cursor left requires previous grapheme. >> Does this mean that sorting will also require a locale? > >In my latest header proposal, I've grouped both functions under one >"locale" object, and I think this would be fast, allow for (later) >adding tailoring for language, and yield a reasonable syntax. What do >you think? What the implementation does internally and whether it decides to do use a locale class should not be specified at this level. I think it would be simpler to just pass a locale ID in, and then let the implementation move the few exceptions around dependent on the locale using whatever internal technique it wanted. Let me know what you think of the latest iteration that shows the interface into the character implementation and around which we will probably added templated inline calls for iterators etc. Yours, Graham

1 0

Re: [boost] Call for interest for native unicode character and string support in boost
by Graham 30 Jul '05

30 Jul '05

>From: Rogier van Dalen <rogiervd(a)gmail.com> >Subject: Re: [boost] Call for interest for native unicode character and string support in boost Dear Rogier, >> DWORD is actually uint32_t. >I know, but - correct me if I'm wrong - I think the sort keys consist of 16-bit integers. This depends on how we implement it - and if we implement or allow for more than 4 level comparison - if so the 5+ comparison if coded may require uint32_t. What do you think? I am happy to go to uint16_t and limit to 4 levels as this is a reasonable performance/ implementation trade-off that I have previously used with success. >> I believe collation must be here as there will be probably be several >> containers with Unicode characteristics and this is a good level for >> them to work on. >I'm not sure - seeing as I'd expect us to come up with at least the option to keep strings in some Normalisation Form, the >first step of the collation algorithm should be skipped in some cases. Furthermore, individual comparisons should probably be >done without producing sort keys. String equality [=] would be handled directly using on the fly comparison of canonically decomposed forms as I previously mentioned, and as you correctly mention. String equivalence [<] would be handled using sort level 4+. >Not being a native speaker of English I don't think I understand what a "coding hit" is. Reduction in performance - your English is better than a lot of the British ! >I'm assuming that the caller usually knows the start and end. (I'm obviously assuming a C++-style string and not a C-style >zero-terminated one.) In this case, the caller must check whether the end has been reached and whether it's at begin, >pass in 0 in those cases, and then start_of_grapheme has to check whether 0 was passed in. To me it >seem this would be slower, both to code and to execute. Performance can be argued back and forth, but when I looked at optimising the performance I needed three iterators as iterating graphemes is not a 'cheap' operation - and I moved the iterators along in series [step forward is curr->prev, next->curr, calculate next]. In 64 bit code iterating a uint_32t container, iterators can introduce high costs. The real problem though is that iterators do not work across DLL boundaries unless you have the code for the DLL and the caller. Have a look at my recently posted implementation. This implementation proposal would mean you can produce a DLL for sale that has a custom Unicode control in it - without having to have the source code for the iterators that it needs and providing an interface for each iterator type, or placing the whole of the Unicode data in that DLL and preventing the use of custom characters. >Furthermore, one'd better abstract away from the implementation as much as possible, and I don't think it is relevant to the caller >how far the functions want to look ahead. (I don't think "next" is needed for the grapheme_cluster case anyway.) A good example of next grapheme and start of grapheme is for default moving a cursor left/ right - the cursor may be on a grapheme [or optionally inside a grapheme if the editor supports this, as is optionally recommended in the standard] and you need to find the previous/next grapheme. >Ermmm... what's this doing then on p. 137 of Unicode standard 4.0.0? >"Characters may have case mappings that depend on the locale. The principal example is Turkish, ..." Ouch - I had not seen that before. I believe that this would mean that the upper/ lower case conversions will need to take a locale to allow for these special extensions at a later date. I have not seen any written rules for this - I guess because I had never worked with Turkish - but it should be allowed for. Does this mean that sorting will also require a locale? Please let me know what you think and if you can spot any other assumptions I have made in my attachment posted on the 28th. Yours, Graham

2 1

Boost regression notification (2005-07-30)
by Douglas Gregor 30 Jul '05

30 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-30T16:27:27Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 36 failures in 2 libraries: serialization (33) wave (3) |serialization| test_class_info_load_text_warchive_dll: vc-6_5 test_class_info_load_xml_warchive_dll: vc-8_0 test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: vc-6_5 vc-6_5-stlport vc-7_0 test_demo_fast_archive_dll: vc-6_5 test_demo_pimpl_dll: vc-6_5 vc-7_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 test_demo_shared_ptr_dll: vc-6_5 vc-7_0 test_map_binary_archive_dll: vc-6_5 vc-7_0 test_map_text_archive_dll: vc-6_5 vc-7_0 test_map_text_warchive_dll: vc-6_5 vc-7_0 test_mult_archive_types_dll: vc-6_5 test_no_rtti_text_warchive_dll: vc-8_0 test_shared_ptr_132_binary_archive_dll: intel-win32-8_1 test_shared_ptr_132_xml_archive_dll: intel-win32-8_1 test_simple_class_ptr_text_archive_dll: vc-8_0 |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: vc-8_0

1 0

Proposal: Still using NULL ?
by Anis Benyelloul 30 Jul '05

30 Jul '05

Hello ! Scott Meyers has presented a replacement for the (evil) NULL macro, in his "More Effective C++". I have posted some variation of it in the Boost File Vault, under the name 'boost_null.zip', and, I was wondering if it could fit in boost/utility.hpp. This is of no major innovation, and won't save the world, but at least we can say goodbye to NULL ! Indulge yourslef the NULL you desreve ! -- Anis Benyelloul

3 3

Boost regression notification (2005-07-29)
by Douglas Gregor 30 Jul '05

30 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-29T20:00:33Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 61 failures in 6 libraries: program_options (4) ptr_container (1) serialization (47) test (4) thread (1) wave (4) |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin |ptr_container| ptr_list: vc-8_0 |serialization| test_class_info_load_text_archive: cw-9_5-darwin test_class_info_load_text_archive_dll: cw-9_5-darwin test_class_info_load_text_warchive: cw-9_5-darwin test_class_info_load_text_warchive_dll: cw-9_5-darwin vc-6_5 test_class_info_load_xml_warchive: cw-9_5-darwin test_class_info_load_xml_warchive_dll: cw-9_5-darwin test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: vc-6_5 vc-6_5-stlport vc-7_0 test_demo_fast_archive_dll: vc-6_5 test_demo_pimpl_dll: vc-6_5 vc-7_0 test_demo_portable_archive_dll: borland-5_6_4 test_demo_shared_ptr_dll: vc-6_5 vc-7_0 test_diamond_binary_archive: cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: vc-6_5 vc-7_0 test_map_text_archive_dll: vc-6_5 vc-7_0 test_map_text_warchive_dll: vc-6_5 vc-7_0 test_mult_archive_types_dll: vc-6_5 test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_5-darwin |thread| test_thread: vc-6_5-stlport |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: cw-9_5-darwin vc-8_0

2 1

Boost Inspection Report, Run Date: 14:47:50 UTC, Saturday 30 July 2005
by Rene Rivera 30 Jul '05

30 Jul '05

[being run on the branch until release] http://www.boost.org/regression-logs/inspection_report.html -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org Boost Inspection Report *Run Date:* 14:47:50 UTC, Saturday 30 July 2005 An inspection program <http://www.boost.org/tools/inspect/index.html> checks each file in the current Boost CVS for various problems, generating this web page as output. Problems detected include tabs in files, missing copyrights, broken URL's, and similar misdemeanors. Totals 10418 files scanned 822 directories scanned 188 problems reported problem counts: 114 files with invalid line endings 0 bookmarks with invalid characters 0 invalid urls 17 broken links 28 unlinked files 22 file names too long 0 files with tabs 7 violations of the Boost min/max guidelines Summary *Library* *Problems* algorithm <#algorithm> 1 boost-root <#boost-root> 3 build <#build> 6 date_time <#date_time> 5 iostreams <#iostreams> 116 iterator <#iterator> 7 libs <#libs> 2 numeric <#numeric> 3 program_options <#program_options> 1 regex <#regex> 1 regression <#regression> 33 serialization <#serialization> 2 test <#test> 7 type_traits <#type_traits> 1 Details algorithm libs/algorithm/string/doc/external_concepts.html: unlinked file boost-root index.htm: broken link: doc/html/date_time/date_time_io.html, broken link: doc/html/date_time/details.html#date_time.changes, broken link: doc/html/date_time/local_time.html build tools/build/v2/example/libraries/util/foo/include/lib1.h: file's directory depth will exceed 8 levels if placed on a CD tools/build/v2/index.html: broken link: ../../../doc/html/bbv2.html, broken link: ../../../doc/html/bbv2/installation.html, broken link: doc/userman.pdf tools/build/v2/test/test_system.html: unlinked file date_time boost/date_time/date_parsing.hpp: violation of Boost min/max guidelines on line 80, violation of Boost min/max guidelines on line 81 boost/date_time/period.hpp: violation of Boost min/max guidelines on line 325, violation of Boost min/max guidelines on line 326 libs/date_time/xmldoc/date_time_docs_howto.html: unlinked file iostreams libs/iostreams/doc/acknowledgments.html: invalid (cr only) line-ending, unlinked file libs/iostreams/doc/bibliography.html: invalid (cr only) line-ending libs/iostreams/doc/classes/aggregate.html: invalid (cr only) line-ending libs/iostreams/doc/classes/array.html: invalid (cr only) line-ending libs/iostreams/doc/classes/back_inserter.html: invalid (cr only) line-ending libs/iostreams/doc/classes/bzip2.html: invalid (cr only) line-ending libs/iostreams/doc/classes/chain.html: invalid (cr only) line-ending libs/iostreams/doc/classes/char_traits.html: invalid (cr only) line-ending libs/iostreams/doc/classes/classes.html: invalid (cr only) line-ending libs/iostreams/doc/classes/code_converter.html: invalid (cr only) line-ending libs/iostreams/doc/classes/counter.html: invalid (cr only) line-ending libs/iostreams/doc/classes/device.html: invalid (cr only) line-ending libs/iostreams/doc/classes/file.html: invalid (cr only) line-ending libs/iostreams/doc/classes/file_descriptor.html: invalid (cr only) line-ending libs/iostreams/doc/classes/filter.html: invalid (cr only) line-ending libs/iostreams/doc/classes/filtering_stream.html: invalid (cr only) line-ending libs/iostreams/doc/classes/filtering_streambuf.html: invalid (cr only) line-ending libs/iostreams/doc/classes/gzip.html: invalid (cr only) line-ending libs/iostreams/doc/classes/line_filter.html: invalid (cr only) line-ending libs/iostreams/doc/classes/mapped_file.html: invalid (cr only) line-ending libs/iostreams/doc/classes/mode.html: invalid (cr only) line-ending libs/iostreams/doc/classes/newline_filter.html: invalid (cr only) line-ending libs/iostreams/doc/classes/null.html: invalid (cr only) line-ending libs/iostreams/doc/classes/regex_filter.html: invalid (cr only) line-ending libs/iostreams/doc/classes/stdio_filter.html: invalid (cr only) line-ending libs/iostreams/doc/classes/symmetric_filter.html: invalid (cr only) line-ending libs/iostreams/doc/classes/zlib.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/bidirectional_device.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/bidirectional_filter.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/blocking.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/closable.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/concepts.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/device.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/direct.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/dual_use_filter.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/filter.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/flushable.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/input_filter.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/localizable.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/multi-character.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/multi_character.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/optimally_buffered.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/output_filter.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/peekable.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/pipable.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/seekable_device.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/seekable_filter.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/sink.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/source.html: invalid (cr only) line-ending libs/iostreams/doc/concepts/symmetric_filter.html: invalid (cr only) line-ending libs/iostreams/doc/faq.html: invalid (cr only) line-ending libs/iostreams/doc/functions/close.html: invalid (cr only) line-ending libs/iostreams/doc/functions/combine.html: invalid (cr only) line-ending libs/iostreams/doc/functions/compose.html: invalid (cr only) line-ending libs/iostreams/doc/functions/copy.html: invalid (cr only) line-ending libs/iostreams/doc/functions/filter_test.html: invalid (cr only) line-ending libs/iostreams/doc/functions/flush.html: invalid (cr only) line-ending libs/iostreams/doc/functions/functions.html: invalid (cr only) line-ending libs/iostreams/doc/functions/get.html: invalid (cr only) line-ending libs/iostreams/doc/functions/imbue.html: invalid (cr only) line-ending libs/iostreams/doc/functions/invert.html: invalid (cr only) line-ending libs/iostreams/doc/functions/optimal_buffer_size.html: invalid (cr only) line-ending libs/iostreams/doc/functions/positioning.html: invalid (cr only) line-ending libs/iostreams/doc/functions/put.html: invalid (cr only) line-ending libs/iostreams/doc/functions/putback.html: invalid (cr only) line-ending libs/iostreams/doc/functions/read.html: invalid (cr only) line-ending libs/iostreams/doc/functions/restrict.html: invalid (cr only) line-ending libs/iostreams/doc/functions/seek.html: invalid (cr only) line-ending libs/iostreams/doc/functions/tee.html: invalid (cr only) line-ending libs/iostreams/doc/functions/write.html: invalid (cr only) line-ending libs/iostreams/doc/guide/asynchronous.html: invalid (cr only) line-ending libs/iostreams/doc/guide/buffering.html: invalid (cr only) line-ending libs/iostreams/doc/guide/code_conversion.html: invalid (cr only) line-ending libs/iostreams/doc/guide/concepts.html: invalid (cr only) line-ending libs/iostreams/doc/guide/convenience.html: invalid (cr only) line-ending, unlinked file libs/iostreams/doc/guide/exceptions.html: invalid (cr only) line-ending libs/iostreams/doc/guide/filtering_streams.html: invalid (cr only) line-ending libs/iostreams/doc/guide/generic_streams.html: invalid (cr only) line-ending libs/iostreams/doc/guide/guide.html: invalid (cr only) line-ending libs/iostreams/doc/guide/lifetimes.html: invalid (cr only) line-ending libs/iostreams/doc/guide/modes.html: invalid (cr only) line-ending libs/iostreams/doc/guide/pipelines.html: invalid (cr only) line-ending libs/iostreams/doc/guide/text_processing.html: invalid (cr only) line-ending libs/iostreams/doc/guide/traits.html: invalid (cr only) line-ending libs/iostreams/doc/guide/views.html: invalid (cr only) line-ending libs/iostreams/doc/home.html: invalid (cr only) line-ending libs/iostreams/doc/index.html: invalid (cr only) line-ending libs/iostreams/doc/installation.html: invalid (cr only) line-ending libs/iostreams/doc/macros/buffer_sizes.html: invalid (cr only) line-ending libs/iostreams/doc/macros/macros.html: invalid (cr only) line-ending libs/iostreams/doc/macros/workarounds.html: invalid (cr only) line-ending libs/iostreams/doc/menu.html: invalid (cr only) line-ending libs/iostreams/doc/portability.html: invalid (cr only) line-ending libs/iostreams/doc/quick_reference.html: invalid (cr only) line-ending libs/iostreams/doc/rationale.html: invalid (cr only) line-ending, unlinked file libs/iostreams/doc/reference.html: invalid (cr only) line-ending libs/iostreams/doc/tree/tree.css: invalid (cr only) line-ending libs/iostreams/doc/tutorial/container_device.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/container_sink.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/container_source.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/dictionary_filters.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/dual_use_filters.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/filter_usage.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/finite_state_filters.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/line_wrapping_filters.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/multichar_filters.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/shell_comments_filters.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/tab_expanding_filters.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/tutorial.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/unix2dos_filters.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/writing_devices.html: invalid (cr only) line-ending libs/iostreams/doc/tutorial/writing_filters.html: invalid (cr only) line-ending libs/iostreams/test/putback_test.hpp: invalid (cr only) line-ending iterator libs/iterator/doc/filter_iterator_ref.html: unlinked file libs/iterator/doc/indirect_iterator_ref.html: unlinked file libs/iterator/doc/issues.html: unlinked file libs/iterator/doc/iter-issue-list.html: unlinked file libs/iterator/doc/iterator_adaptor_ref.html: unlinked file libs/iterator/doc/make_filter_iterator.html: unlinked file libs/iterator/doc/ref_problem.html: unlinked file libs libs/libraries.htm: broken link: ../doc/boost.docbook, broken link: ../doc/boost.fo numeric boost/numeric/conversion/detail/old_numeric_cast.hpp: violation of Boost min/max guidelines on line 159, violation of Boost min/max guidelines on line 192 libs/numeric/conversion/doc/converter_policies.html: invalid (cr only) line-ending program_options boost/program_options/positional_options.hpp: violation of Boost min/max guidelines on line 43 regex libs/regex/performance/input.html: unlinked file regression regression/.htaccess: leading character of one of the path compontents is not alphabetic, nonportable path tools/regression/test/compile-fail~fail.cpp: nonportable path tools/regression/test/compile-fail~pass.cpp: nonportable path tools/regression/test/compile~fail.cpp: nonportable path tools/regression/test/compile~pass.cpp: nonportable path tools/regression/test/compile~warn.cpp: nonportable path tools/regression/test/run-fail~compile-fail.cpp: nonportable path tools/regression/test/run-fail~fail-warn.cpp: nonportable path tools/regression/test/run-fail~fail.cpp: nonportable path tools/regression/test/run-fail~pass.cpp: nonportable path tools/regression/test/run-fail~warn.cpp: nonportable path tools/regression/test/run~compile-fail.cpp: nonportable path tools/regression/test/run~fail-note.cpp: nonportable path tools/regression/test/run~fail-warn.cpp: nonportable path tools/regression/test/run~fail.cpp: nonportable path tools/regression/test/run~note.cpp: nonportable path tools/regression/test/run~pass.cpp: nonportable path tools/regression/test/run~warn-note.cpp: nonportable path tools/regression/test/run~warn.cpp: nonportable path tools/regression/xsl_reports/runner/instructions.html: unlinked file tools/regression/xsl_reports/xsl/html/issues_legend.html: unlinked file tools/regression/xsl_reports/xsl/html/library_developer_legend.html: unlinked file tools/regression/xsl_reports/xsl/html/library_user_legend.html: unlinked file tools/regression/xsl_reports/xsl/html/make_tinyurl.html: unlinked file tools/regression/xsl_reports/xsl/html/summary_developer_legend.html: unlinked file tools/regression/xsl_reports/xsl/html/summary_user_legend.html: unlinked file tools/regression/xsl_reports/xsl/v2/html/issues_legend.html: unlinked file tools/regression/xsl_reports/xsl/v2/html/library_developer_legend.html: unlinked file tools/regression/xsl_reports/xsl/v2/html/library_user_legend.html: unlinked file tools/regression/xsl_reports/xsl/v2/html/make_tinyurl.html: unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_developer_legend.html: unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_user_legend.html: unlinked file serialization libs/serialization/doc/serialization.html: broken link: ../../../boost/serialization/shared_count.hpp libs/serialization/vc7ide/test_reset_object_address.vcproj: filename > 31 chars test libs/test/doc/components/test_exec_monitor/compilation.html: broken link: ../../../src/supplied_log_formatters.cpp, broken link: ../../../src/unit_test_result.cpp libs/test/doc/components/utf/compilation.html: broken link: ../../../src/supplied_log_formatters.cpp, broken link: ../../../src/unit_test_result.cpp libs/test/doc/components/utf/components/test_case/boost_function_tc.html: broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp libs/test/doc/components/utf/components/test_case/param_boost_function_tc.html: broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp libs/test/doc/tests/unit_test_suite_ex_test.html: broken link: ../../test/unit_test_suite_ex_test.cpp type_traits libs/type_traits/cxx_type_traits.htm: unlinked file

2 1

Re: [boost] Call for interest for native unicode character and string support in boost - updated definition
by Graham 30 Jul '05

30 Jul '05

Hi, I enclose a new set of headers, put in one file for convenience. I have tried to enable the use of iterators and templates where possible but still allow the use of the functions by third party DLLs requiring sharing of source code and class definitions. This makes the use of iterators interesting. I look forward to any comments or ideas on how better to do this first/ third party compromise. Yours, Graham Barnett BEng, MCSD/ MCAD .Net, MCSE/ MCSA 2003, CompTIA Sec+

3 2

[repost][getting started][serialization] outdated info about Boost.Serialization
by JOAQUIN LOPEZ MU?Z 30 Jul '05

30 Jul '05

I think this msg might have went unnoticed, so allow me to repost it: Hello, the section on autolinking in the getting started page, as it appears in http://boost-consulting.com/boost/more/getting_started.html#auto-link states that Boost.Serialization is not autolinkable nor dynamically linkable. I think this is no longer true starting with Boost 1.33. If so, maybe the release manager will accept that this bit be changed before packing up (I can't do the change myself, though.) Joaquín M López Muñz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Call for interest for native unicode character and string support in boost
by Graham 30 Jul '05

30 Jul '05

>Date: Thu, 28 Jul 2005 06:24:52 +0200 >From: Rogier van Dalen <rogiervd(a)gmail.com> > >Hi Graham, > >> In my experience this is handled by the dictionary pass [outside the >> scope of this support] adding special break markers into the text [which >> need to be supported transparently as Unicode characters that happen to >> be in the private use range at this level] so that the text and string >> iterators can then be handled normally. The fact that the break markers >> are special characters in the private use range should not be relevant >> or special at this level. > >You mean that we invent a set of private characters that the >dictionary pass should use? Actually individual developers are free to use their own private range as they see fit - these characters are just one example of the use of non standard private characters - 'we' as in boost do not invent these - any developer can add these characters to their own code to handle Thai if private character definition on a per-developer instance is supported. >> We must provide a Unicode character system on which all libraries can >> operate consistently. >> >> Even working out a grapheme break may require different sets of >> compromises that must work consistently for any set of inter-related >> libraries to be successful. > >Do you have an example? I'm having trouble envisioning a situation in >which libraries based on different Unicode versions actually cause >conflicts. I enclose a few of the Unicode 4.0.1 to 4.1 differences as an example Notable Changes From Unicode 4.0.1 to Unicode 4.1.0 * Addition of 1273 new characters to the standard, including those to complete roundtrip mapping of the HKSCS and GB 18030 standards, five new currency signs, some characters for Indic and Korean, and eight new scripts. (The exact list of additions can be seen in DerivedAge.txt, in the age=4.1 section.) * Change in the end of the CJK Unified Ideographs range from U+9FA5 to U+9FBB, with the addition of some Han characters. The boundaries of such ranges are sometimes hardcoded in software, in which case the hardcoded value needs to be changed. >> This is actually a very difficult thing to do due to limitations in the >> Windows GDI scaling [which is not floating point but 'rounds' scaling >> calculations, and which can result in as much as a +/-10% difference in >> simple string lengths on different machines, unless handled specifically >> e.g. IIIIIIIIIIIIIIII can be the same length as WXWXWX on one machine >> but there can be a 20% difference on another machine] and requires >> access to the data conversion mechanisms and requires that you know how >> you are going to perform the rendering. > >I fear I don't understand what you mean. It sounds to me like you're >suggesting defining a new font format for the Boost Unicode library. Please accept that there are fundamental issues with the way in which scaling happens on a Windows platform that means that anybody who want to ensure that there are the same number of lines shown in a document regardless of the 'zoom' setting used to display that document so that the lines appear to have the same relative lengths at any zoom setting have to work very hard. This might be an example of where a particular implementation might store an array of wrapped lines rather than an array of characters. By moving the Unicode specific rules out of, and separate to, the storage, the storage method becomes an implementation issue. There can then be many different storage methods based on the same Unicode rules, e.g. implementations based on vector<char32_t> and vector<char16_t> to give two examples. >> >Why would you want to do canonical decomposition explicitly in a >> >regular expression? >> >> Let me give two examples: >> >> First why? >> >> If you use a regular expression to search for <e acute> - [I use angle >> brackets <> to describe a single character for this e-mail] then >> logically you should find text containing: >And <acute> is a combining acute? Yes >> <e><acute> and <e acute> as these are both visually the same when >> displayed to the user. > >> Second why do we need to know? If we decompose arbitrarily then we can >> cover over syntax errors and act unexpectedly: >> [...] >Yes, the Unicode library should by default process grapheme clusters >rather than code points. This would automatically solve the regex >issue. I would envision that the string storage classes would support UTF16, UTF32 and grapheme based iterators. It is important in some circumstances to be able to process UTF32 characters rather than graphemes - for example when drawing the string ! As graphemes are can be several UTF32 characters long and require calculation to determine their data length it is often not practical to make these the default processing scheme. >> This private use character data would NOT be published or distributed - >> the facility to merge them in during usage allows each developer the >> access to add their own private use data for their own system only. > >But surely this means every app would have to come with a different DLL? >I'm not so sure about this. For many cases other markup (XML or >something) would do. Maybe other people have opinions about this? I propose making it so that the Unicode data could be either placed in a DLL or an application. The data and boost functions would be supplied as a number of .h and .cpps that can be compiled in to either. The functions would be in supplied .h and .cpps, and the data .h and .cpps would be generated once only by a developer using a stand alone command line application. Access to the Unicode data would ONLY be by using the set of core functions or function wrappers round the core functions as outlined in my previous attachment and these core functions would be accessed by function pointers which can therefore be passed across DLLs even when the DLLS are written by third parties. The DLLs could then ask for the Unicode function pointers if required during initialisation so that first and third party DLLs could work with the same data. Yours, Graham

2 1

Error on Front Page
by Joe Gottman 30 Jul '05

30 Jul '05

There's an embarrassing typo on the redesigned front page. Near the top it says "More Boost libraries will part of the upcoming TR2". You need to add a "be" after the "will". Also, isn't this sentence a bit presumptuous? As far as I know, no library has been accepted into the TR2, or even formally proposed. Maybe you should have an adverb like "probably" or "likely" somewhere in this sentence. Joe Gottman

3 2

Re: [boost] Interest in an ODBC library?
by JOAQUIN LOPEZ MU?Z 29 Jul '05

29 Jul '05

----- Mensaje original ----- De: Joaquin M Lopez Munoz <joaquin(a)tid.es> Fecha: Viernes, Julio 29, 2005 5:28 pm Asunto: Re: [boost] Interest in an ODBC library? > > template<typename Element> > void reverse_dump(IBidirectionalContainer<Element> i) > { > std::copy( > i.rbegin(),i.rend(), > std::ostream_iterator<Element>(std::cout)); > } Thinking about it some more, we could really use the version of reverse_dump in the static case also for the dynamic situation: template<typename Index> void reverse_dump(const Index& i) { std::copy( i.rbegin(),i.rend(), std::ostream_iterator<typename Index::value_type>(std::cout)); } In the dynamic case, reverse_dump would be then instantiated as reverse_dump<IBidirectionalContainer<Element> >. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

bjam stage forgot symlinks FIX BEFORE RELEASE
by Neal Becker 29 Jul '05

29 Jul '05

I just built from a recent cvs using: ICU_PATH=/usr ICU_LINK="-licuuc -licui18n" PYTHON_ROOT=/usr PYTHON_VERSION=2.3 bjam -sTOOLS=gcc stage I noticed that symlinks are missing. for each lib "x", in stage/lib there is libx.so.1.0.0 (actual binary) libx.so -> libx.so.1.0.0 (link) but there must be also libx.so.1 -> libx.so.1.0.0 This is because (I guess) soname of the library is set to libx.so.1, and when you link to libx then at runtime it will look for libx.so.1 (which it won't find)

2 2

Re: [boost] Interest in an ODBC library?
by Brian Braatz 29 Jul '05

29 Jul '05

Joaquin! Glad you responded and Good to be "talking" with you again :) Below: > On Behalf Of JOAQUIN LOPEZ MU?Z [Brian Braatz Writes:] > > > > I am not sure if he is still interested, but Joaquin Munez and I > > exchanged emails awhile back about collaborating on such a beast. > > > > The general idea was to take the functionality in multi-index > > containerand make it work dynamically. > > > [JOAQUIN LOPEZ MUNEZ Writes:] > I am still interested, and it is my plan to implement a > dynamic_multi_index_container in the future, if there's > interest in such a thing --serving as the foundation for > a DB table structure would be a very exciting application, > undoubtedly. > > Let me sketch what I have in mind: The part of adding/removing > indices at run time is not too hard: I haven't written any actual > code, but the design of that feature seems reasonably > straightforward to me. Some speed/space performance will > be lost, but I guess this is expected. > > The hard part, IMHO, is how to gain access to such indices. > Clearly some kind of runtime polymorhpisn is involved > for a dynamic_multi_index_container to have any use: > otherwise, the user code would have to know the exact type > of the index it is retrieving. So we need something more powerful > than the current static get<> interface. A possibility > is to retrieve indices by mean of *interfaces* as > defined in Jonathan Turkanis' BIL library: [Brian Braatz Writes:] If you would please elaborate. (some of us are "slower" than others :) ). is the problem getting to the index objects themselves via inherit_linearly? if you have dynamic data, then I am thinking you also have dynamically applied indices? Maybe I can elaborate- consider the following pseudo code: connection con = db.connect("myserver,root,password,mydatabase"); dynamic_table dt; // the select "*" means bring me back all the fields from that table // even though I don't know what the fields ARE yet dt = query("select * from person"); // ok so now dt has an UNKNOWN number of columns dt.add_index( index("first_name")); // or something along those lines. in this case, the index is applied dynamically. so how does that connect with the things you said ? Thanks, Brian

2 1

[pointer container] new libraries docs?
by David Abrahams 29 Jul '05

29 Jul '05

Why does pointer container appear in both the new and updated libraries section of the main page? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[signals] making Assignable and CopyConstructable
by Rebooted 29 Jul '05

29 Jul '05

In my program I need to store a map of signals, with an integer id corresponding to a signal in the map. Objects can request to be informed when another a specific message is emitted by connecting a member function to the signal in this map at the index corresponding to that message type. However, since boost::signal inherits noncopyable, it cannot be stored in a map. What are the reasons for signal being noncopyable, and is there any chance this could be changed in the future?

4 3

[ptr_container] Inappropriate behaviours
by Allen 29 Jul '05

29 Jul '05

I am using the ptr_container library (the version in the CVS) in my current project recently. I am really suprised by the strange behaviour of nullable ptr containers. If someone is using nullable ptr containers, there always are needs to construct a ptr container with specific size and filled in with all null pointers. However, I found that the ptr container can only "reserve" specfic sized buffered, but cannot be constructed with specific size: ptr_vector<nullable<int> > v(10); Instead, I have to write this: ptr_vector<nullable<int> > v(10); for (int i = 0; i < 10; i++) v.push_back(0); It is really a superise in my opinion, and write a loop (or use an STL algorithm) to fill the container manually is awkward and unnecessary. I think it is more intuitive and natural that the above constructor constructs a ptr_vector of size 10, with 10 null pointers inside. If the container is not nullable, it could default-construct 10 objects (or clone 10 from a given one) instead. Another superise is it seems that the iterator returned by associative ptr containers are not std::pair like STL containers do, but the values in the associative container. I cannot see the reason for this incompatibility with STL, nor can I find any documentation or examples on this. Am I missing something? Comments are welcome. Best regards, Yao, Zhen

2 1

Request for more detailed change history with releases
by Russell Hind 29 Jul '05

29 Jul '05

I think the current change history for boost releases isn't adequate. It appears that libraries get changed (small and big changes) between releases but many of these aren't documented. A couple of reasons I'd like this to be changed are: 1. New functionality added to libraries my go un-noticed. e.g. I recently found out from c.l.m.c++ that bind now supports == and other comparison operators. Peter Dimov has now added this to index.html after my request, but if it wasn't there, we may have never realised that functionality existed which would be a shame as possibly only new users to the library would know about these changes. 2. Compatibility. e.g. ublas stopped supporting Borland C++Builder in 1.32. In 1.31 we used ublas and then tried to move to 1.32 but there was no indication of this in the changes history and this is quite important. Significant amounts of time can be invested trying to use the new release of boost only to find you can't because one library that is core to a user may have been deprecated for that compiler without any warning. It seems to me that there is no easy way to tell this for an end user. Yes there are reqression test results, but these would require the user to look at the regression tests for both 1.31 and 1.32 and compare the two, but I would expect most end users to ignore the regression tests, especially once they are already using a version of boost. I'd really like to see these addressed, especially as we are coming towards a 1.33.0 release and we are currently wondering how much effort to put in to see if 1.33.0 will work in our current environment which is working well with 1.32.0. I'd really like to see this sort of information on the front page of boost but at a minimum I'd like to see library authors keep a change history for each release such as that for date-time at http://www.boost.org/doc/html/date_time/details.html#date_time.changes Thanks Russell

2 1

Boost regression notification (2005-07-28)
by Douglas Gregor 29 Jul '05

29 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-28T15:44:28Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 117 failures in 9 libraries: filesystem (2) graph (1) program_options (4) python (4) random (2) serialization (92) test (5) thread (1) wave (6) |filesystem| operations_test_dll: mingw-3_4_2 path_test_dll: mingw-3_4_2 |graph| graphviz_test: intel-win32-8_1 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin |python| iterator: vc-7_1 map_indexing_suite: vc-7_1 pointer_vector: vc-7_1 vector_indexing_suite: vc-7_1 |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux msvc vc-6_5 vc-7_1 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr_dll: msvc vc-6_5 vc-7_0 test_diamond_binary_archive: cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mi_binary_archive_dll: intel-win32-8_1 test_mult_archive_types_dll: msvc vc-6_5 test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_shared_ptr_132_xml_archive_dll: intel-win32-8_1 |test| errors_handling_test: cw-9_5-darwin test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |thread| test_thread: vc-6_5 |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0

2 1

Re: [boost] singleton design plan
by Hickerson, David A 28 Jul '05

28 Jul '05

Have you checked out the loki library on SourceForge? It has a singleton implementation along the lines you are trying implement. If you have not read this paper about multi-threaded singletons, I suggest you do. http://erdani.org/publications/DDJ_Jul_Aug_2004_revised.pdf Dave -----Original Message----- From: Jason Hise [mailto:chaos@ezequal.com] Sent: Thursday, July 28, 2005 3:17 PM To: boost(a)lists.boost.org Subject: Re: [boost] singleton design plan Michael Goldshteyn wrote: >What is: > >namespace boost >{ > const class > { > >??? > const class { ... } null; Defines a global variable named null, which is constant and of an unnamed type defined by the class declaration. I think this is standards conforming, but now that you mention it I'm not positive. I will have to check with other compilers to make sure. -Jason _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

indeterminate tribool to bool
by Fernando Cacciola 28 Jul '05

28 Jul '05

Hi, I'm reading a draft of a proposal to standarize interval arithmetic (from the authors of Boost.Inverval). They propose to include the specialization "interval<bool>" to represent "false<->maybe<->true", that is, a tristate boolean expressed as an interval in the "lattice" range [false,true] They specifically mention that they propose interval<bool> instead of Boost.TriBool becasue they argue that conversion from indeterminate to bool shouldn't be false but fail with an exception. It turns out that in any actual case I can think of, throwing when trying to narrow an indeterminate tribool into true or false is indeed much prefered than returning false. The tribool documentation says that you should write: if ( b ) certainly_true(); else if (!b ) certainly_false(); else uncertain(); The authors of the proposal argue that even though you should follow that pattern, if you don't, so your code is written like: if ( b ) certainly_true(); else certainly_false(); then if b is indeterminate the false branch should not execute because that's hardly what the programer intended in the case of a tri-state logic. >From my own experience I cannot but agree. If you're implementing a complex triboolean predicate that nests child triboolean predicates (various levels down), you can rightly decide to use the simplified pattern (with just the 2 certain branches) and let the exception mechanisms wind up the "uncertain answer" up to the caller; but for this you need ideterminate->bool to fail... Of course there is always the choice of using the "correct" pattern that properly test for "certainly false". So, why doesn't tribool throw in this case? Fernando Cacciola SciSoft

1 0

Re: [boost] singleton design plan
by JOAQUIN LOPEZ MU?Z 28 Jul '05

28 Jul '05

----- Mensaje original ----- De: Jason Hise <chaos(a)ezequal.com> Fecha: Jueves, Julio 28, 2005 11:25 pm Asunto: Re: [boost] singleton design plan > Michael Goldshteyn wrote: > > >What is: > > > >namespace boost > >{ > > const class > > { > > > >??? > > > It worked with VC, but I just checked it with comeau and it failed > to > compile. To fix it, I had to provide a name for the class and an > explicit default constructor. Naming the class null works, > because then > the class name is hidden by the global variable name and thus > other > instances of type null cannot be declared. You can still gain access to the class type by typing "class null": class null other_null; Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] Interest in an ODBC library?
by JOAQUIN LOPEZ MU?Z 28 Jul '05

28 Jul '05

Hello Brian, ----- Mensaje original ----- De: Brian Braatz <brianb(a)rmtg.com> Fecha: Jueves, Julio 28, 2005 10:34 pm Asunto: Re: [boost] Interest in an ODBC library? > If you are interested in collaborating, I have wanted to (for some > timenow) build the table<> aspect of what you are working on. > > My goals: > 1- functional drop in replacement for ADO recordset > 2- Dynamic and static "views" and indexes > 3- binding model that does NOT force you to use the bindings supplied > with the library > this is something ADO lacks, and something I have had to work > around to great frustration > 4- the ability to COPY from one table<> to another table<> > * ADO does NOT ALLOW you to copy recordsets. (brilliant no?) > > > Additionally - > > I am not sure if he is still interested, but Joaquin Munez and I > exchanged emails awhile back about collaborating on such a beast. > > The general idea was to take the functionality in multi-index > containerand make it work dynamically. > I am still interested, and it is my plan to implement a dynamic_multi_index_container in the future, if there's interest in such a thing --serving as the foundation for a DB table structure would be a very exciting application, undoubtedly. Let me sketch what I have in mind: The part of adding/removing indices at run time is not too hard: I haven't written any actual code, but the design of that feature seems reasonably straightforward to me. Some speed/space performance will be lost, but I guess this is expected. The hard part, IMHO, is how to gain access to such indices. Clearly some kind of runtime polymorhpisn is involved for a dynamic_multi_index_container to have any use: otherwise, the user code would have to know the exact type of the index it is retrieving. So we need something more powerful than the current static get<> interface. A possibility is to retrieve indices by mean of *interfaces* as defined in Jonathan Turkanis' BIL library: http://www.kangaroologic.com/interfaces/libs/interfaces/doc/ This interface concept provides the needed run-time polymorphism without having to cast the index classes into a rigid abstract hierarchy. This would allow the user to tune the polymorphic functionality exposed by indices from the most general (iteration) to the most concrete (for instance, set-like functionality, so restricting the type of acceptable indices that can go into the container) only by defining the interface to which the indices must conform. Of course, this is just a bunch of random thoughts and the BIL library is not part as of yet of Boost, so I don't think I'll be ready to provide something until mid 2006 or so. Moreover, it's still to be seen whether a dynamic_multi_index_container is of interest to the Boost community. > > I am working on something unrelated to this discussion that could > form a > good foundation for table<>. I should have something to share > middle of > next week. > > Just let me know if you are interested in putting our heads together. > Sure! I'll be reading your table<> material as soon as you make it available. Soon I'll be on a three-week vacation, so I might have some time to write my ideas about a dynamic_multi_index_container in a more structured way. Best regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[1.33.0] Branch for release
by Doug Gregor 28 Jul '05

28 Jul '05

We've now branched for the 1.33.0 release. The branch is RC_1_33_0. The main trunk is open for changes, now, but I'd urge everyone to be somewhat cautious while we're dedicating our testing resources to the branch. Doug

3 2

MPL: for_each missing from ref manual
by Brian Braatz 28 Jul '05

28 Jul '05

sorry, (for the poor timing) I just noticed mpl::for_each does NOT seem to be in the MPL reference manual. it does appear in mpl_paper.pdf, but I could not find it anywhere else (grepped the html)

1 0

Re: [boost] MPL:Possible Placeholder problem with transform & if_(?)
by Brian Braatz 28 Jul '05

28 Jul '05

On Behalf Of Aleksey Gurtovoy > Brian Braatz writes: > > Either something strange is happening with arg<> and transform or I did > > not write this code correctly. ( :) ) > > The latter :). > By requesting '::type' on a metafunction you are immediately > instantiating it with the placeholder argument(s), which is not what > you want. Try > > typedef mpl::transform< > vec_t > , mpl::if_< > , boost::is_same<mpl::_1, A> > , YES< mpl::_1 > > , NO< mpl::_1 > > > > >::type result; > [Brian Braatz Writes:] THANK YOU - This is very helpful (in many ways) :)

1 0

index.htm frozen?
by Peter Dimov 28 Jul '05

28 Jul '05

Is everything frozen, or can I add a line about the changes to boost::bind in index.htm? -- Peter Dimov http://www.pdimov.com

2 1

[Boost-bugs] [ boost-Support Requests-1246745 ] Build is very slow with VC6
by SourceForge.net 28 Jul '05

28 Jul '05

Support Requests item #1246745, was opened at 2005-07-28 05:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1246745&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Build is very slow with VC6 Initial Comment: Since I start using boost libriaires in my project, it takes about 20 second to build each of my cpp file (less than 1 sec before using boost). I have included all needed headers in stdafx.h and nowhere else, and it is still so long. Can someone help me to build faster. Compiler: VC ++ 6 Boost: 1_32_00 Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1246745&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

2 1

[getting started] outdated info about Boost.Serialization
by JOAQUIN LOPEZ MU?Z 28 Jul '05

28 Jul '05

Hello, the section on autolinking in the getting started page, as it appears in http://boost-consulting.com/boost/more/getting_started.html#auto-link states that Boost.Serialization is not autolinkable nor dynamically linkable. I think this is no longer true starting with Boost 1.33. If so, maybe the release manager will accept that this bit be changed before packing up (I can't do the change myself, though.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[Regression Testing][1.33.0] Intel C++ 9.0?
by Aleksey Gurtovoy 28 Jul '05

28 Jul '05

The following message is a courtesy copy of an article that has been posted to gmane.comp.lib.boost.testing as well. Is there a reason why Intel C++ 9.0, being the latest released version of that compiler, is not on the list of the required toolsets? -- Aleksey Gurtovoy MetaCommunications Engineering

3 2

[inspect] Boost Inspection Report, Run Date: 20:26:32 UTC, Monday 25 July 2005
by Rene Rivera 28 Jul '05

28 Jul '05

10434 files scanned 822 directories scanned 179 problems reported problem counts: 4 files with invalid line endings 0 bookmarks with invalid characters 0 invalid urls 103 broken links 38 unlinked files 23 file names too long 4 files with tabs 7 violations of the Boost min/max guidelines http://www.boost.org/regression-logs/inspection_report.html Boost Inspection Report -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 1

Re: [boost] Call for interest for native unicode character and string support in boost
by Graham 28 Jul '05

28 Jul '05

Hi, I enclose a basic set of headers [in a single file for simplicity at this stage] so that the set of functions to provide Unicode character data can be discussed. I believe that the core functions calls will probably end up using functions pointers so that different DLLs can use the same functionality and still have the implementation be transparent, and that the function pointers will the retrieved during an initialise call. Does anybody have any strong opinions on this? Once the Unicode.h contents are agreed then I hope - if it is agreed quickly - to implement the necessary data generators to implement it. Once that is done then a string implementation should be fairly quick to implement. I welcome comments. Yours, Graham Barnett BEng, MCSD/ MCAD .Net, MCSE/ MCSA 2003, CompTIA Sec+

2 1

[docs] Who's Using Boost link goes nowhere.
by Rene Rivera 28 Jul '05

28 Jul '05

Just tried looking up that page. And the link on <http://boost-consulting.com/boost/more/background.html> goes to <http://boost-sandbox.sourceforge.net/doc/html/who_s_using_boost_.html>. First the page doesn't exist. Second I don't think pointing it to the sandbox is the right thing to do. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

5 16

[1.33.0] Code is frozen
by Douglas Gregor 28 Jul '05

28 Jul '05

The source code for Boost 1.33.0 is now frozen. Please do not check in any changes to the Boost source code without my explicit permission. You may still update parts of Boost that do not affect the regression tests in any way, until we have our final freeze of the entire tree at 11PM EST on Wednesday. Doug Gregor 1.33.0 Release Manager

16 37

MPL:Possible Placeholder problem with transform & if_ (?)
by Brian Braatz 28 Jul '05

28 Jul '05

Either something strange is happening with arg<> and transform or I did not write this code correctly. ( :) ) Any help pointing me to either conclusion appreciated. The next step is to try the same algorithm with transform_view. I really don't want a lazy sequence (how could mother be proud?), but sometimes life is disappointing. Thanks Guys. CODE: struct print_type { std::ostream & m_os; print_type(std::ostream & os = std::cout) : m_os(os) {} template <typename T> void operator()(T const& v) const { m_os << "[ " << typeid(v).name() << " ] "; } }; template <class seq_t> void _print_types(const char * pHeading) { std::cout << "** " << pHeading << std::endl; mpl::for_each<seq_t>(print_type()); std::cout << std::endl; } #define print_types(seq) _print_types<seq>(#sew); template <class T> struct YES { typedef YES type; }; template <class T> struct NO { typedef NO type; }; struct A{}; typedef mpl::vector<A> vec_t; typedef mpl::transform < vec_t, mpl::if_ < boost::is_same<mpl::_1, A >, YES< mpl::_1 >::type, NO< mpl::_1 >::type >::type >::type result; void test() { print_types (result); /* ////////////////////////// PRINTS: ** result [ struct NO<struct A> ] SHOULD PRINT: ** result [ struct YES<struct A> ] //////////////////////////// */ }

2 1

Re: [boost] Interest in an ODBC library?
by Brian Braatz 28 Jul '05

28 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Hajo Kirchhoff > Hi, > > > What I don't like in your approach is that you require that there is a > > type (my_table above) for each different rowset traversal "profile" - > > I don't. This is not required, this is merely an example. For small > tables and simple queries its the fastest way. But not the only way. > > > interested in only some of the columns - from 2 to 5, typically. Do you > > require that the application always retrieves all columns? > > Absolutely not. > > odbc::statement s("SELECT column1,column2,etc... FROM ..."); > > is supported of course. > > > Just imagine a single table with 4 columns - there are 15 different > > subsets of columns there (not counting the queries with no columns). > > Also there does not have to be a 1:1 relationship between the members in > my_table and the columns of the table. Subsets are fine. In fact, if you > have a table with 150 columns and want to select only a subset of > columns, you have a couple of options with my approach. > > a) write a struct ... containing only a few member variables for those > columns you want to select. > > b) use individual variables to bind them. > > c) all of the above > > Another example: > odbc::statement s("SELECT one([bindto]a), two([bindto b), sixteen, > seventeen, eighteen FROM huge_table"); > long a, b; > struct some_struct; // has members m_sixteen, ... > some_struct data; > > s.bind(a, "a"); // bind variable a to column one > s.bind(b, "b"); // bind variable b to column b > // bind all member variables of 'data' to columns > // of the same name ... if they exist > s.bind(data); > > > You does your approach scale in this aspect? > > It does. I do not see that it does. At a minimum, you need to support working like a dynamic ADO recordset does. that being, I can issue a call, and retrieve back the data, but I do NOT have priori knowledge of the types that is going to contain. I offer the following high level design thoughts- you split the lib into a few pieces: 1- Get the data from the data base and stream it into X 2- a stock form of "X" (like the table you described) 3- Helpers for binding if you built the thing that way, then it will be usable by those of us out there who have large bodies of code relying on things like ADO recordsets. I would love to replace the recordsets, but I need to be able to selectively use pieces of your library and I need to have a usage model that is similar. Thanks, Brian

2 1

Re: [boost] Call for interest for native unicode character and string support in boost
by Graham 28 Jul '05

28 Jul '05

Dear Doug, Thank you for your positive mail. >You seem to have a lot of valuable experience with Unicode. >I feel that the interface is the more urgent matter for now. The >implementation of the tables can always be changed as long as the >interface remains stable. Let me rephrase that: I think the issues of >programmer's interface and data tables are orthogonal, and programmers >will care most about the interface, and then about performance. This >is not to say you don't give a whole lot of important and difficult >issues that must be solved at some point. I agree that there is a large degree of orthogonally between the character and properties vs string handling, but there is also a fundamental and strong link. Until you have access to the character properties, or have at least defined what methods to access those properties will be available, you cannot support Unicode strings. A classic example of this is the fact that the lower case version of a single Unicode character may be series of Unicode characters - without understanding this and coding a method to handle this, the string handling cannot be written. I believe that we should agree a Unicode character data specification that will supply Unicode data so that we can then independently look at the string interface. In my experience the string part can then be split off and handled completely independently as you have correctly stated. Should these be character properties be supplied using an interface, published method calls, etc etc. ? What calls should there be? If we can agree the interface/ separation/ of Unicode character data from string interfaces then I believe that we will move forward quickly from there as we are then 'just' taking about algorithm optimisation on a known data set to create the best possible string implementation. >> How have you hooked in dictionary word break support for languages like >> Thai >IMO that would be beyond the scope of a general Unicode library. It is both outside the scope but also fundamental to the approach as this case must be handled/ provided for. In my experience this is handled by the dictionary pass [outside the scope of this support] adding special break markers into the text [which need to be supported transparently as Unicode characters that happen to be in the private use range at this level] so that the text and string iterators can then be handled normally. The fact that the break markers are special characters in the private use range should not be relevant or special at this level. >> How far have you gone? Do you have support for going from logical to >> display on combined ltor and rtol ? Customised glyph conversion for >> Indic Urdu? >Correct me if I'm wrong, but I think these issues become important >only when rendering Unicode strings. Aren't they thus better handled >by Uniscribe, Pango, or similar OS-specific libraries? I think a Boost >Unicode library should focus on processing symbolic Unicode strings >and keep away from what happens when they are displayed, just like >std::basic_string does. Unfortunately I believe that there may be serious limitations in this approach. I strongly believe that even if we do not actually write all the code we must not be in a position where, for example, you have to use a Uniscribe library based on Unicode 4 and a Boost library based on Unicode 4.1. [This is even ignoring UniScribe's 'custom' handling]. We must provide a Unicode character system on which all libraries can operate consistently. Even working out a grapheme break may require different sets of compromises that must work consistently for any set of inter-related libraries to be successful. As another example where display controls data organisation, what happens if you want to have a page of text display the same on several machines? This is actually a very difficult thing to do due to limitations in the Windows GDI scaling [which is not floating point but 'rounds' scaling calculations, and which can result in as much as a +/-10% difference in simple string lengths on different machines, unless handled specifically e.g. IIIIIIIIIIIIIIII can be the same length as WXWXWX on one machine but there can be a 20% difference on another machine] and requires access to the data conversion mechanisms and requires that you know how you are going to perform the rendering. >Why would you want to do canonical decomposition explicitly in a >regular expression? Let me give two examples: First why? If you use a regular expression to search for <e acute> - [I use angle brackets <> to describe a single character for this e-mail] then logically you should find text containing: <e><acute> and <e acute> as these are both visually the same when displayed to the user. Second why do we need to know? If we decompose arbitrarily then we can cover over syntax errors and act unexpectedly: e.g. If we type [\x1<e acute>] then we decompose it outside the syntactic context of the regular expression engine and we would get: [\x1e<acute>] This is NOT what we expect and is therefore an error as we are now looking only for an acute and the actual syntax error [incomplete hex number] is not reported. >> We will need to create a utility to take the 'raw'/ published unicode >> data files along with user defined private characters to make these >> tables which would then be used by the set of functions that we will >> agree such as isnumeric, ishangul, isstrongrtol, isrtol etc. > >I find the idea of users embedding private character properties >_within_ the standard Unicode tables, and building their own slightly >different version of the Unicode library, scary. Why is this needed? It is important that the private use range, which is part of the Unicode spec, be handled consistently with the other Unicode ranges otherwise we end up having to write everything twice ! The private use range is in the Unicode spec specifically as it has been recognised that any complex Unicode system will need private use characters. Classic examples are implementations that move special display characters into portions of the private use ranges to allow for optimal display of visible tabs, visible cr, special characters like Thai word breaks, and of course completely non-standard characters like a button that can be embedded in text and would be entirely implementation specific. Having the breaking characteristics of these characters be handled consistently with all Unicode characters is a massive simplification for coding. I strongly believe that we must therefore allow each developer who wants to use the Unicode system the ability to add these private use character properties into their own personal main character tables so they are handled consistently with all other characters, but acknowledge that these are implementation specific. This private use character data would NOT be published or distributed - the facility to merge them in during usage allows each developer the access to add their own private use data for their own system only. Yours, Graham Barnett BEng, MCSD/ MCAD .Net, MCSE/ MCSA 2003, CompTIA Sec+

2 1

Re: [boost] token_iterator flaw, format and date_time shadowing, regex gcc.mak problem, and Boost.Format suggestion
by Stephan T. Lavavej 28 Jul '05

28 Jul '05

[STL] > I have noted the following about Boost 1.32.0. > 1. boost/token_iterator.hpp is very broken on line 34. > > template <class TokenizerFunc, class Iterator, class Type> > class token_iterator > : public iterator_facade< > token_iterator<TokenizerFunc, Iterator, Type> > , Type // ********** SHOULD READ: const Type > , typename detail::minimum_category< > forward_traversal_tag > , typename iterator_traversal<Iterator>::type > >::type > , const Type& > > > > GCC 3.4.2 refuses to compile this when broken. [Dave Abrahams] > Why do you think so? I'm sorry, I misremembered it as a hard error. Actually, it produces a nontrivial warning under -Wcast-qual: C:/MinGW/bin/../lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/boost/iter ator/iterator_facade.hpp: In static member f unction `static typename boost::mpl::if_<boost::is_reference<Reference>, Pointer, boost::detail::operator_arrow_proxy<Va lueType> >::type boost::detail::operator_arrow_result<ValueType, Reference, Pointer>::make(Reference) [with ValueType = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Reference = const std::basic_string<char, std::c har_traits<char>, std::allocator<char> >&, Pointer = std::basic_string<char, std::char_traits<char>, std::allocator<char > >*]': C:/MinGW/bin/../lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/boost/iter ator/iterator_facade.hpp:644: instantiated from `typename boost::detail::operator_arrow_result<typename boost::detail::iterator_facade_types<Value, CategoryOrTrav ersal, Reference, Difference>::value_type, Reference, typename boost::detail::iterator_facade_types<Value, CategoryOrTra versal, Reference, Difference>::pointer>::type boost::iterator_facade<I, V, TC, R, D>::operator->() const [with Derived = boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::basic_string<char, std::char_traits<char> , std::allocator<char> > >, Value = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, CategoryOrTr aversal = boost::forward_traversal_tag, Reference = const std::basic_string<char, std::char_traits<char>, std::allocator <char> >&, Difference = ptrdiff_t]' C:/MinGW/bin/../lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/boost/date _time/time_parsing.hpp:81: instantiated fr om `time_duration boost::date_time::parse_delimited_time_duration(const std::string&) [with time_duration = boost::posix _time::time_duration]' C:/MinGW/bin/../lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/boost/date _time/posix_time/time_parsers.hpp:27: inst antiated from here C:/MinGW/bin/../lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/boost/iter ator/iterator_facade.hpp:325: warning: cast from `const std::basic_string<char, std::char_traits<char>, std::allocator<char> >*' to `std::basic_string<char, std::ch ar_traits<char>, std::allocator<char> >*' discards qualifiers from pointer target type Stephan T. Lavavej

1 0

[iostreams] [1.33.0] Please give me a couple of extra minutes
by Jonathan Turkanis 28 Jul '05

28 Jul '05

Hi, I need a few more minutes to fix some broken links. Sorry for the inconvenience. Jonathan

2 3

Interest in an ODBC library?
by Hajo Kirchhoff 28 Jul '05

28 Jul '05

Hi all, I'd like to gauge interest in an odbc wrapper library. I am currently writing one and the most important difference to other libraries I've seen is the ease with which my library allows binding variables to odbc columns and parameters. Given a table in the database named 'my_table' and a struct my_table, this would be the shortest code to retrieve all rows of that table and do something with them: odbc::table t; my_table data; t.bind(data); //!!! This does all the binding! t.open(); while (t.fetch().ok()) { } Note that this is the full, actual working code, not pseudo code. I have *not* omitted any function arguments. The only thing thats missing is setting the DSN and credentials for the default connection (see below). 'bind' makes use of another library 'data adapters', which allow writing runtime generic methods. I hope to make a separate announcement shortly, once I get my sourceforge CVS connection going agan. In the meantime, have a look at http://tinyurl.com/8ctju to get an idea of it. Other features: + ANSI SQL-92 "schema" support + uses DBMS strategy objects that handle DBMS specific functions such as creating a database, creating users and groups etc... + unit tests currently run with MS-Jet, MS-SQL Server 2000, postgres + has a macro 'preprocessor' for SQL statements built in that hides some of the differences between DBMS system. Example: CREATE TABLE abc(id $$SERIAL primary key not null) will expand to INT AUTOINCREMENT with MS-JET but to SERIAL on postgres. That way you can have one script that works with different databases. + always tries to fail gracefully if a feature is not supported by a specific DBMS Any interest? Best regards Hajo Two examples: Example ONE: Given this struct definition, which mirrors the table definition struct my_table { int m_id; char m_name[51]; string m_long_textfield; }; LWL_BEGIN_ADAPTER(my_table) PROP(m_id) PROP(m_name) PROP(m_long_textfield) LWL_END_ADAPTER() This is how you'd use the library In your main(), set the login data // set the credentials for the default 'unnamed' connection // all table/statement etc... will use this connection unless // specified otherwise odbc::connection::pool().set("MyDSN", "MyUserName", "MyPassword"); Anywhere use // instantiate my_table struct my_table data; // table uses the unnamed default connection odbc::table t; // bind does the magic. it automatically binds // all my_table member variables to the columns t.bind(data); // open the table t.open(); // fetch the rows while (t.fetch().ok()) { // do something cout << data.m_long_textfield; } // check for errors if (t.last_error().no_error()==false) { cerr << "ODBC error: " << t.last_error().as_string() << endl; } Example TWO: // create a statement with parameter marker statement s("SELECT * FROM my_table WHERE id=?([in]p_id)"); // bind the data to the columns my_table data; s.bind(data); // bind the WHERE parameter long parameter; s.bind(parameter, "p_id"); parameter=5; if (s.execute().ok() && s.fetch().ok()) { // data contains the row WHERE id = 5 cout << data.m_long_textfield; } else cerr << s.last_error().as_string() << endl; -- -------------------------------------------- Lit Window Library - Speed up GUI coding 10x http://www.litwindow.com/library?src=ml wxVisualSetup - integrate wxWidgets into Visual Studio .NET http://www.litwindow.com/Products/products.html?src=ml BugLister - Defect Tracker http://www.litwindow.com/buglister?src=ml Tips & Tricks for wxWidgets & MS Visual Studio http://www.litwindow.com/Knowhow/knowhow.html?src=ml

3 3

Release scripts for 1.33.0
by Misha Bergal 27 Jul '05

27 Jul '05

I've updated tarball/zipball making script (tools/release/make_tarballs.py). It has proven to be quite useful for 1.32.0 release. Basically it automates getting sources from CVS (with windows and unix newlines), building documentation, setting necessary Unix permission, cleaning up the intermediary results and making tarballs. There are some caveats though: 1. It runs on Windows and requires cygwin. 2. There might have been some changes in build procedure between 1.32.0 and 1.33.0, so the resulting tarballs need to be checked by a more knowledgable person. I will run the comparison between 1.32.0 and 1.33.0 tomorrow to check for obvious problems. 3. It doesn't have any documentation yet. 4. Release Manager's Checklist (http://www.boost.org/more/release_mgr_checklist.html) Distribution section has not been updated to include the reference to make_tarballs.py documentation. 5. Standard distrubitution of xsltproc has a show-stopper bug (http://tinyurl.com/bcp93) so the patched one needs to be obtained from our web site (http://engineering.meta-comm.com/boost/xsltproc-win32.zip) -- Misha Bergal MetaCommunications Engineering

4 5

singleton: zombie_call
by Jason Hise 27 Jul '05

27 Jul '05

I am trying to come up with a mechanism which allows member functions of the singleton to be called if the instance exists, and which do nothing if the instance does not exist (no creation is attempted, the operation is simply skipped). My current idea is a member function of the singleton pointer named zombie_call, which would be used something like: ptr.zombie_call ( &MySingletonType::SomeFunc, param1, param2, ... ); The only problem I have is what to do if the instance does not exist and the member function has a return value. Should I just return a default-constructed object in these cases? (And what should happen if the return type does not have a constructor taking no arguments?) Should I append a parameter to the end of zombie_call which is returned if the instance does not exist, and have it default to a default-constructed object? Should I append a parameter that is a reference to the return type, and just assign the return value to it if the operation is successful? (And what happens if the return type is already a reference?) Should I just enforce that member functions called with zombie_call return void? Also, is there any way to make the syntax of the call a bit nicer? I was originally hoping to have a separate pointer type called zombie_ptr, which just behaved in this manner when functions were accessed via operator->, but I couldn't think of a non-intrusive way to pull it off... Any and all thoughts are appreciated. -Jason

4 7

Re: [boost] Possible Placeholder problem with transform & if_ (?)
by Brian Braatz 27 Jul '05

27 Jul '05

Ok - I just fixed this- I don't understand WHY it fixed it but it did. I moved the if_<> into a metafunction class and passed the metafunction class to transform. I would think that either using it inline or as a mfc would be equivalent. (out of curiosity)- Anyone know the answer to this why this is the case? > -----Original Message----- > From: Brian Braatz > Sent: Wednesday, July 27, 2005 3:41 PM > To: 'boost(a)lists.boost.org' > Subject: MPL:Possible Placeholder problem with transform & if_ (?) > > Either something strange is happening with arg<> and transform or I did > not write this code correctly. ( :) ) > > Any help pointing me to either conclusion appreciated. The next step is to > try the same algorithm with transform_view. I really don't want a lazy > sequence (how could mother be proud?), but sometimes life is > disappointing. > > Thanks Guys. > > CODE: > > struct print_type > { > std::ostream & m_os; > print_type(std::ostream & os = std::cout) > : m_os(os) {} > > template <typename T> > void operator()(T const& v) const > { > m_os << "[ " << typeid(v).name() << " ] "; > } > }; > > template <class seq_t> > void _print_types(const char * pHeading) > { > std::cout << "** " << pHeading << std::endl; > mpl::for_each<seq_t>(print_type()); > std::cout << std::endl; > } > #define print_types(seq) _print_types<seq>(#sew); > > template <class T> > struct YES > { > typedef YES type; > }; > template <class T> > struct NO > { > typedef NO type; > }; > > struct A{}; > > typedef mpl::vector<A> vec_t; > > typedef mpl::transform > < > vec_t, > mpl::if_ > < > boost::is_same<mpl::_1, A >, > YES< mpl::_1 >::type, > NO< mpl::_1 >::type > >::type > >::type result; > > void test() > { > print_types (result); > > /* ////////////////////////// > > PRINTS: > > ** result > [ struct NO<struct A> ] > > SHOULD PRINT: > > ** result > [ struct YES<struct A> ] > > //////////////////////////// > */ > }

1 0

token_iterator flaw, format and date_time shadowing, regex gcc.mak problem, and Boost.Format suggestion
by Stephan T. Lavavej 27 Jul '05

27 Jul '05

Hi, I have noted the following about Boost 1.32.0. 1. boost/token_iterator.hpp is very broken on line 34. template <class TokenizerFunc, class Iterator, class Type> class token_iterator : public iterator_facade< token_iterator<TokenizerFunc, Iterator, Type> , Type // ********** SHOULD READ: const Type , typename detail::minimum_category< forward_traversal_tag , typename iterator_traversal<Iterator>::type >::type , const Type& > GCC 3.4.2 refuses to compile this when broken. 2. boost/format/format_implementation.hpp contains shadowing on line 28. The constructor takes 'str', which is named identically to a member function. 3. boost/date_time/time_duration.hpp contains shadowing on line 53. The constructor takes 'hours', 'minutes', and 'seconds', which are named identically to member functions. 4. boost/date_time/time_system_counted.hpp contains shadowing on line 34. The constructor takes 'tod', which is named identically to a member function. Shadowing makes using Boost with GCC -Wshadow difficult, and these cases are very easy to fix. 5. libs/regex/build/gcc.mak mentions '-I../../../' twice. This breaks compilation on MinGW. '-I../../..' ought to work everywhere (it does on MinGW). 6. Suggestion: It would be useful if Boost.Format were capable of delayed evaluation. int main() { format mommy("%1% %1%"); format kiddy("x%1%y"); mommy % kiddy; kiddy % 10; cout << mommy << endl; } Thanks, Stephan T. Lavavej

4 3

[Boost-bugs] [ boost-Bugs-1246358 ] interval evaluation bug
by SourceForge.net 27 Jul '05

27 Jul '05

Bugs item #1246358, was opened at 2005-07-27 14:46 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=1246358&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: interval evaluation bug Initial Comment: evaluation of sin of [0,1] with interval template specification typedef boost::numeric::interval< double, boost::numeric::interval_lib::policies< boost::numeric::interval_lib:: save_state< boost::numeric::interval_lib:: rounded_transc_exact<double, boost::numeric:: interval_lib::rounded_arith_opp<double> > >, boost::numeric::interval_lib:: checking_strict<double> //boost::numeric::interval_lib:: checking_base<double> > > Interval; and rint definition in ms Windows static double inline rint( double x) // Copyright (C) 2001 Tor M. Aamodt, University of Toronto // Permisssion to use for all purposes commercial and otherwise granted. // THIS MATERIAL IS PROVIDED "AS IS" WITHOUT WARRANTY, OR ANY CONDITION OR // OTHER TERM OF ANY KIND INCLUDING, WITHOUT LIMITATION, ANY WARRANTY // OF MERCHANTABILITY, SATISFACTORY QUALITY, OR FITNESS FOR A PARTICULAR // PURPOSE. { if( x > 0 ) { __int64 xint = (__int64) (x+0.5); if( xint % 2 ) { // then we might have an even number... double diff = x - (double)xint; if( diff == -0.5 ) return double(xint-1); } return double(xint); } else { __int64 xint = (__int64) (x-0.5); if( xint % 2 ) { // then we might have an even number... double diff = x - (double)xint; if( diff == 0.5 ) return double(xint+1); } return double(xint); } } gives incorrect result: so sin([0,1]) = [ 0.841471 , -1.60814e-016 ] Thats looks incredible!!! How can i fix it out? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1246358&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

[Boost-bugs] [ boost-Bugs-1246336 ] reverse_graph and constness of property maps
by SourceForge.net 27 Jul '05

27 Jul '05

Bugs item #1246336, was opened at 2005-07-27 16:04 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=1246336&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: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Douglas Gregor (dgregor) Assigned to: Douglas Gregor (dgregor) Summary: reverse_graph and constness of property maps Initial Comment: accessing properties in a reverse_graph often fails because it's getting the "::type" when it should be getting the "::const_type", and vice-verse. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1246336&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

[Boost-bugs] [ boost-Bugs-1246308 ] MSVC support
by SourceForge.net 27 Jul '05

27 Jul '05

Bugs item #1246308, was opened at 2005-07-27 13:08 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=1246308&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: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: MSVC support Initial Comment: rint function is not declared in any of MSVC's include files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1246308&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

SF CVS having problems. ?? release delay ??
by Rene Rivera 27 Jul '05

27 Jul '05

As some of you may have noticed starting last night CVS access is not possible. This is currently preventing me from checking in changes to the explicit markup file. And of course also preventing me from getting any updates, and preventing it would seem the boost-consulting mirror from getting updated. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 2

[Signals] Proposal effort for TR2
by Doug Gregor 27 Jul '05

27 Jul '05

At the C++ committee meeting in Lillehammer last April, I'd asked if there was any interest in a TR2 proposal for the Signals library, and got a positive response. I'll be collaborating with the libsigc++ folks to put together a proposal for the upcoming meeting, which will be discussed on the libsigc mailing list: http://mail.gnome.org/mailman/listinfo/libsigc-list We'll naturally be taking the good features from both libraries (tracking, combining, syntax, etc.) and tossing out the bad (*ahem* named slot groups). Interested Boosters are welcome to join us over in that forum. Doug

1 0

Boost.Serialization archive constructor performance
by Kim Barrett 27 Jul '05

27 Jul '05

I've been experimenting with the Boost.Serialization library, to decide whether to use it in a project I'm working on. If it weren't for some performance issues, the decision of whether to use this library would be a no-brainer. Because it seemed otherwise so promising, I've spent some time investigating these performance issues, and have a couple of suggestions for improvements that would address them. (Obviously these suggestions are for post-1.33 release.) The use case being considered is marshalling values for transport to some other process. This is among the use cases discussed in the overview section of the library's documentation. However, it turns out that with relatively fine-grained marshalling operations, constructor / destructor time for the archive can amount to a significant fraction of the time spent in performing such an operation. The thing that seems to be using up most of the time is the initialization of various standard containers (std:set, std::vector, std::list), most of which are used for pointer tracking. For reference, a snippet to show the sort of thing I'm doing. (Please ignore the fact that this code snippet is obviously not thread-safe and similar issues; I've simplified things to show just the parts relevant to this issue.) const int binary_archive_flags = boost::archive::no_header | boost::archive::no_codecvt; const std::size_t size 64; static char buffer[size]; // allocate stream once, and reset for reuse static boost::iostreams::stream<io::array_sink> out(buffer, size); out.seekp(0); #if REUSE_ARCHIVES // allocate archive once, and reset for reuse static boost::archive::binary_oarchive oa(out, binary_archive_flags); oa.reset(); #else boost::archive::binary_oarchive oa(out, binary_archive_flags); #endif save_ss(ss, oa); // write ss into archive oa // arrange for destination process to receive the contents of // buffer containing serialized ss A change which I think should be not too difficult to make, and which would make a large difference, would be to provide a mechanism for resetting and reusing an archive. As part of my experiments I added a public void reset() operation boost::archive::detail::basic_iarchive and basic_oarchive, which clear the various tracking related containers in the associated pimpl objects. I then modified my tests to allocate their archives once and reset before each use. The result was a significant speedup. Rather than spending roughly 1/3 of the time in archive construction / destruction, the archive reset time is now close to the noise level in my measurements. (As you can see in the above code snippet, I'd already started reusing the streams for similar reasons.) I'm not necessarily proposing exactly the interface I used here for experimentation. A better interface might be to reset the archive when the associated stream is changed (which involves adding an interface for changing the stream, of course). But I'm not sure that's right either, since there is some separation between the stream handling part and the pointer tracking part of things. Perhaps there is an intent to support something other than streams, by using something other than boost::archive::basic_binary_[i,o]primitive? I think that once the details of this interface are determined, the implementation is pretty straight-forward. A second change, which may or may not be worthwhile, would be to avoid allocating the various tracking-related containers at all when the archive is created with no_tracking specified. With archive reuse as described above, this probably wouldn't make any directly noticeable performance difference for my usage. It might make a difference in space usage though, as the design I'm investigating this library for might end up with a significant number of archives devoted to various specific things, with pointer-less data being common in this design. So avoiding the allocation of a bunch of always empty containers, might be worthwhile, depending on the space used by such. This seems like it might be significantly more difficult to implement than the reuse support though. And whether it is actually worth doing depends on the internal implementation of the standard containers being used.

5 8

Re: [boost] [wave]: possible use for makefile dependencies
by Martin Bonner 27 Jul '05

27 Jul '05

----Original Message---- From: Pavel Vozenilek [mailto:pavel_vozenilek@hotmail.com] Sent: 26 July 2005 17:09 To: boost(a)lists.boost.org Subject: [boost] [wave]: possible use for makefile dependencies > Hello Hartmut, > > Wave executable could have feature for use > in makefiles or makefile generators. [snip] > Most likely output consisting from only > space separated dependent headers > (no *.obj, no foo.c itself) is the best ouput > as the text is futher manipulated. That breaks horribly as soon as you have any headers whose names contain spaces! (P.S. Is this the correct list for this?) -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

Re: [boost] Interest in a binary_int template for binary literals?
by Scott Schurr 26 Jul '05

26 Jul '05

Greetings, I'm back from vacation. I have a note and a question regarding the binary_int template. 1. I've compiled the binary_int template with Microsoft Visual Studio.NET version 7.0. It gets unhappy when the most significant bit is set in a 32-bit binary word. The compiler reports: warning C4307: '*' : integral constant overflow along with a bunch of other stuff about the template instantiation. It seems to be only a warning however, since the executable is still produced and runs properly. I tried a couple of things in the enum definition to try and convince the compiler to use an unsigned int for the computation, but to no avail. I couldn't figure out a way to get rid of the warning. 2. Pavel Vozenilek thinks that the names binary_nibble and binary_int could be improved on. Pavel suggests the names 'nibble' and 'bits', noting that the term 'binary' has too many connotations in C++. At any rate, what do folks think would be good names for these two templates? Thanks. Scott Schurr

2 1

zip iterator over containers of unequal sizes
by Leo Goodstadt 26 Jul '05

26 Jul '05

The zip iterator documentation says: "The zip iterator provides the ability to parallel-iterate over several controlled sequences simultaneously. ... Moving the zip iterator moves all the iterators in parallel." What is not specified is what happens when the several different sequences are of unequal size. At the moment, everything just blows up. python zip, if I remember correctly, just stops at the end of the shortest sequence in the tuple. (python map works differently). This seems a sensible thing to do. This requires just a modification to zip_iterator::equal. I guess distance_to might need to be changed as well. Leo Goodstadt The diff is attached at the end. Here is the example modified: #include <boost/iterator/zip_iterator.hpp> #include <boost/tuple/tuple.hpp> #include <iostream> #include <vector> int main() { typedef std::vector<int> IntSeq; // a = {1,2,3} IntSeq a; a.push_back(1); a.push_back(2); a.push_back(3); // b = {10,20,30,40} IntSeq b; b.push_back(10); b.push_back(20); b.push_back(30); b.push_back(40); // b = {100,200,300,400,500} IntSeq c; c.push_back(100); c.push_back(200); c.push_back(300); c.push_back(400); c.push_back(500); typedef boost::zip_iterator< boost::tuples::tuple< IntSeq::const_iterator, IntSeq::const_iterator, IntSeq::const_iterator> > ZIt; ZIt cur(boost::make_tuple(a.begin(), b.begin(), c.begin())); ZIt end(boost::make_tuple(a.end(), b.end(), c.end())); for ( ; cur != end; ++cur ) { std::cout << "{ " << boost::tuples::get<0>(*cur) << ", " << boost::tuples::get<1>(*cur) << ", " << boost::tuples::get<2>(*cur) << " }" << std::endl; } return 0; } diff old_boost/iterator/zip_iterator.hpp new_boost/iterator/zip_iterator.hpp 329a330,347 > > // Returns true if any tuples equal. NOTE: "==" for tuples currently (7/2003) > // has problems under some compilers, so I just do my own. > // No point in bringing in a bunch of #ifdefs here. This is > // going to go away with the next tuple implementation anyway. > // > bool tuple_any_equal(tuples::null_type, tuples::null_type) > { return false; } > > template<typename Tuple1, typename Tuple2> > bool tuple_any_equal( > Tuple1 const& t1, > Tuple2 const& t2 > ) > { > return t1.get_head() == t2.get_head() || > tuple_any_equal(t1.get_tail(), t2.get_tail()); > } 537c555 < return detail::tuple_impl_specific::tuple_equal( --- > return detail::tuple_impl_specific::tuple_any_equal(

4 4

Re: [boost] Boost.Filesystem i18n mini-review
by Jan Hermelink 26 Jul '05

26 Jul '05

Beman Dawes wrote: > "Jan Hermelink" <Jan.Hermelink(a)metalogic.de> wrote in message >> Another idea: >> - Get a WIN32 file handle with CreateFileW() >> - Get filename from handle: >> http://msdn.microsoft.com/library/en-us/fileio/fs/obtaining_a_file_name_ >> from_a_file_handle.asp - use thereby the "Ansi" function to get the >> "ansi" filename (GetMappedFileNameA()) >> >> However I have not tested this... > > I don't see how that could work unless the codepage is correct, but > like you I haven't actually tested. You are right - I have tried this with a file name with greek characters, and GetMappedFileNameA() failes to translate them correctly: all greek characters are replaced with '?' (with german system locale). Yet another idea: - open file with _wfopen() and get FILE pointer - construct basic_*fstream with this FILE pointer (Dinkumwares (and other) implementation has basic_fstream(FILE*) etc. as an extension) Jan

1 0

boost-jam-3.1.11 [was Re: Jam binaries for 1.33.0?]
by Rene Rivera 26 Jul '05

26 Jul '05

>>Doug Gregor wrote: >> >>>We'll need updated Jam binaries on Sourceforge for the 1.33.0 release. OK, that's done: <http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=72941…> Those are all the platforms I can directly generate bjam binaries for. If others would like to see specific platforms I would be glad to add them. To build a distribution package do: cd boost-root/tools/build/jam_src cvs -q -z3 update -r Boost_Jam_3_1_11 sh ./build.sh --- dist And upload the resulting "boost-jam-3.1.11-1-[platform].tgz" to ftp://uploads.sf.net/incoming -- And either add it directly to the SF file release system (all devs should be able to do this now). Or tell me the file is there and I'll do it. And of course you find anything wrong with the binaries please speak up. Enjoy. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 1

Re: [boost] Boost.Filesystem i18n mini-review
by Jan Hermelink 26 Jul '05

26 Jul '05

Beman Dawes wrote: > At 04:42 AM 7/20/2005, Jan Hermelink wrote: > > >Replacing the current implementation thru a simple narrow conversion > >helps as workaround. > > My understanding (which could be faulty) is that there is no general > way to do such a wide to narrow conversion that always works. I don't know. It works with filenames with german characters but I can't say for filenames with e.g. CJK characters. Another idea: - Get a WIN32 file handle with CreateFileW() - Get filename from handle: http://msdn.microsoft.com/library/en-us/fileio/fs/obtaining_a_file_name_ from_a_file_handle.asp - use thereby the "Ansi" function to get the "ansi" filename (GetMappedFileNameA()) However I have not tested this... Jan

2 1

Proposal: Add build output types to Boost.Config
by Jason Hise 26 Jul '05

26 Jul '05

If there is not currently a set of macros provided by config.hpp which detect the type of output the compiler is generating, is there interest in adding one? I am thinking something along the lines of: BOOST_CAN_DETECT_BUILDING_EXE BOOST_BUILDING_EXE BOOST_CAN_DETECT_BUILDING_SLL BOOST_BUILDING_SLL BOOST_CAN_DETECT_BUILDING_DLL BOOST_BUILDING_DLL -Jason

1 0

singleton_ptr
by Jason Hise 25 Jul '05

25 Jul '05

Background: Since the first version of my singleton library was rejected, I have been designing a new singleton library from the ground up. I feel that this is necessary because the first version was not designed with the concerns of threading in mind, and such concerns cannot easily be addressed efficiently as an afterthought. The new design should hopefully be able to handle threading effectively without introducing any overhead for the single threaded model. Question: With the new design, I am adding a policy to control exactly what happens if creation is attempted while the singleton instance exists. The options thus far include throwing an exception, doing nothing, or destroying and recreating the singleton, depending on the policy used. Does it make sense to have a similar policy for what happens when attempting to destroy an already destroyed instance? I can think of a few options that would make sense, such as doing nothing, throwing an exception, asserting, or creating the instance so that it can be re-destroyed, but I do not know if these would actually be useful enough to justify a point of customization. Thoughts? -Jason

8 16

singleton and dlls
by Jason Hise 25 Jul '05

25 Jul '05

To make my singleton work with dlls, I have determined that I need to export/import certain global lifetime management objects so that they are visible across dll boundaries. To keep the library header-only, I want to use the preprocessor to detect whether a windows dll, windows exe, or other is being built. If it is a windows exe I want to export the object. If it is a windows build and not an exe, I want to import the object. And if it is not a windows build I just want to define the object normally. A couple questions since this is unfamiliar territory for me: Can I export from an exe and import into a dll? It seems like normally the reverse would be done, but this seems like a good way to ensure that the object is only exported once. What boost macros would I use to detect which type of build is occurring? Is there any type of exporting or importing that should occur with the Linux equivalent of dlls? If so, is there some uniform interface provided by boost that wraps things like __declspec(dllexport) and __declspec(dllimport) for most platforms? -Jason

1 0

Boost regression notification (2005-07-25)
by Douglas Gregor 25 Jul '05

25 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-25T15:39:19Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 318 failures in 9 libraries: filesystem (4) graph (1) multi_index (1) program_options (4) python (4) random (2) serialization (287) test (5) wave (10) |filesystem| operations_test_dll: borland-5_6_4 mingw-3_4_2 path_test_dll: borland-5_6_4 mingw-3_4_2 |graph| graphviz_test: intel-win32-8_1 |multi_index| test_capacity: vc-8_0 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin |python| iterator: vc-7_1 map_indexing_suite: vc-7_1 pointer_vector: vc-7_1 vector_indexing_suite: vc-7_1 |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 vc-7_1 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_contained_class_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_contained_class_binary_archive_dll: cw-9_4 cw-9_5-darwin test_contained_class_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_contained_class_text_archive_dll: cw-9_4 test_contained_class_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_contained_class_text_warchive_dll: cw-9_4 test_contained_class_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_contained_class_xml_archive_dll: cw-9_4 test_contained_class_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_contained_class_xml_warchive_dll: cw-9_4 test_cyclic_ptrs_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_cyclic_ptrs_binary_archive_dll: cw-9_4 cw-9_5-darwin test_cyclic_ptrs_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_cyclic_ptrs_text_archive_dll: cw-9_4 test_cyclic_ptrs_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_cyclic_ptrs_text_warchive_dll: cw-9_4 test_cyclic_ptrs_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_cyclic_ptrs_xml_archive_dll: cw-9_4 test_cyclic_ptrs_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_cyclic_ptrs_xml_warchive_dll: cw-9_4 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 test_derived_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_binary_archive_dll: cw-9_4 cw-9_5-darwin test_derived_class_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_binary_archive_dll: cw-9_4 cw-9_5-darwin test_derived_class_ptr_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_ptr_binary_archive_dll: cw-9_4 cw-9_5-darwin test_derived_class_ptr_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_ptr_text_archive_dll: cw-9_4 test_derived_class_ptr_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_ptr_text_warchive_dll: cw-9_4 test_derived_class_ptr_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_ptr_xml_archive_dll: cw-9_4 test_derived_class_ptr_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_ptr_xml_warchive_dll: cw-9_4 test_derived_class_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_text_archive_dll: cw-9_4 test_derived_class_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_text_warchive_dll: cw-9_4 test_derived_class_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_xml_archive_dll: cw-9_4 test_derived_class_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_class_xml_warchive_dll: cw-9_4 test_derived_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_text_archive_dll: cw-9_4 test_derived_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_text_warchive_dll: cw-9_4 test_derived_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_xml_archive_dll: cw-9_4 cw-9_5-darwin test_derived_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_derived_xml_warchive_dll: cw-9_4 test_diamond_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_4 cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_4 cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_4 cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_4 cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_4 cw-9_5-darwin test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mi_binary_archive_dll: intel-win32-8_1 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 test_no_rtti_xml_archive: vc-8_0 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_null_ptr_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_binary_archive_dll: cw-9_4 cw-9_5-darwin test_null_ptr_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_text_archive_dll: cw-9_4 test_null_ptr_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_text_warchive_dll: cw-9_4 test_null_ptr_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_xml_archive_dll: cw-9_4 test_null_ptr_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_xml_warchive_dll: cw-9_4 test_nvp_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_nvp_binary_archive_dll: cw-9_4 cw-9_5-darwin test_nvp_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_nvp_text_archive_dll: cw-9_4 test_nvp_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_nvp_text_warchive_dll: cw-9_4 test_nvp_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_nvp_xml_archive_dll: cw-9_4 test_nvp_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_nvp_xml_warchive_dll: cw-9_4 test_recursion_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_recursion_binary_archive_dll: cw-9_4 cw-9_5-darwin test_recursion_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_recursion_text_archive_dll: cw-9_4 test_recursion_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_recursion_text_warchive_dll: cw-9_4 test_recursion_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_recursion_xml_archive_dll: cw-9_4 test_recursion_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_recursion_xml_warchive_dll: cw-9_4 |test| errors_handling_test: cw-9_5-darwin test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |wave| test_re2c_lexer: vc-7_1 vc-8_0 test_slex_lexer: vc-7_1 vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-7_1 vc-8_0

1 0

To:John Maddock about the extention of the Boost.Regex
by leecky 25 Jul '05

25 Jul '05

John Maddock, Hi, I'm writing codes for my corporation,and I am faced with an challenge that how can I do a wrap for the Boost.Regex according to our libarary which has used in our programs. firstly, the string type in our library is differ from the std::string, so how can I do a template partial version toward the basic_regex? many thanks for inconvenient! 　　　　　　　　Sincerely:leecky 　　　　　　　　liwenli08(a)163.net 　　　　　　　　　　2005-07-25

2 1

Re: [boost] Call for interest for native unicode character and string support in boost
by Graham 25 Jul '05

25 Jul '05

Message: 14 Date: Sun, 24 Jul 2005 20:14:29 +0200 From: Erik Wien <wien(a)start.no> Subject: Re: [boost] Call for interest for native unicode character and string support in boost To: boost(a)lists.boost.org Message-ID: <dc0lpu$ej0$1(a)sea.gmane.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Dear Erik, I have done extensive Unicode work, and would be very interested to see what you have done. I apologise if I ask a lot of questions but these are the questions that immediately spring to mind on any Unicode implementation. How have you organised the Unicode 4.1 data ? Optimising this is itself a project and I have gone through a number of iterations. Unfortunately I have no definitive answer as you ultimately trade off speed against data size. Have you allowed for updating against the current Unicode standard from the Unicode data files? Have you made any trade-off of border [grapheme etc] detection for a simplification of character data ? Have you given access to the character properties? Have you added Unicode sorting and done it in such a way as to not get a high performance hit, e.g. having a separate pair<sort data, string> class? Have you stopped equivalence or equality on a Unicode string? What was your trade off on canconical decomposition? How have you hooked in dictionary word break support for languages like Thai or have you just built in support for adding private characters so that you can support force work break, force no word break, and detected word break [to name just three necessary private characters - in this case for Thai]. How far have you gone? Do you have support for going from logical to display on combined ltor and rtol ? Customised glyph conversion for Indic Urdu? Should these discussions be in a separate mailing group? How can we ensure that other boost projects understand the implication of Unicode support and the subtle changes required, e.g. hooks to allow for canonical decomposition on string data portions of regular expressions in the regexpr project? I am open to suggestions as to the best way to proceed as I feel that there are so many factors that can be traded against each other that there must be some flexibility in the design to allow for speed or memory optimised designs and this will need a lot of careful thought from different informed view points. My feeling is that the first step must be to agree the organisation of the data tables that are parsed from the Unicode data to allow for character tests, upper/ lower case conversion, sort conversion etc. There must be agreement on how best to organise these for speed or size, and what character tests are required. Until we can perform test on Unicode characters and have the basics, getting into Unicode strings is jumping the gun ! We will need to create a utility to take the 'raw'/ published unicode data files along with user defined private characters to make these tables which would then be used by the set of functions that we will agree such as isnumeric, ishangul, isstrongrtol, isrtol etc. I think that this would allow us to progress in a way where we can build the foundations and then build everything else on top of them, and which would then allow the standard to be directly related to and updated from the Unicode standard itself. What do you think? Yours, Graham Barnett BEng, MCSD/ MCAD .Net, MCSE/ MCSA 2003, CompTIA Sec+

2 1

Call for interest in a buffer container
by Andrey Tarantsov 25 Jul '05

25 Jul '05

Hello! I've got a relatively simple queue-like container which can be efficiently used as a buffer. It allocates memory in chunks, and reuses these chunks without deallocating them. (Unused chunks are deallocated based on a simple heuristic.) It's generic (with element type and allocator as parameters), but is expected to be often instantiated with 'unsigned char' (byte) element type. The interface and implementation are not currently iterator-friendly, because I did not need iterator behaviour. As the buffer is expected to be used for storing multiple elements at a time from a continuous storage (C array), it does reads and writes more efficiently than by-element copying iterators can provide. But there is no problem adding iterators, if there will be any interest in this container. Here is the interface (which is short and hopefully more undestandable than my description): /* (constructor) * Specifies buffer memory management details. Storage is allocated in chunks * of [chunk_size] elements; this defaults to the count which makes each chunk * about 10Kb in size (a wild guess). Adjust [reuse_amount] to specify how * fast should the buffer deallocate unused chunks, in 1/128's of full buffer * fill-and-read cycle. A value of 128 (the default) corresponds to the time * all old elements in the buffer are read. A value of 256 means that * unneeded chunks are deallocated after filling and emptying the buffer * twice. */ buffer (size_t chunk_size = default_chunk_size, unsigned reuse_amount = default_reuse_amount); /* * Add the given elements to the end of buffer. */ void write (const El *data, size_t count); /* * Read the given number of elements data from the start of buffer, and remove * the read elements. If less then [count] elements are available, will * read (and remove) all the available elements. Returns the number of * elements read (and removed). */ size_t read (El *data, size_t count); /* * Read the given number of elements starting with the given position, * WITHOUT removing them from the buffer. Position starts at zero, so * specifying zero [pos] results in the behaviour similar to read(), but * without removing the elements. */ size_t read_at (size_t pos, El *data, size_t count); size_t size () const; bool empty () const; -- Andrey.

1 0

Boost.ProgramOptions dynamic linking on mingw
by Alo Sarv 25 Jul '05

25 Jul '05

As noted at: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/output… progopt library fails to link on mingw as dll. After some searching around, I found out that using -Wl,--enable-runtime-pseudo-reloc flag during linking, it works properly. However, one should be warned that this flag should not be used when some of the code isn't compiled with the same compiler (e.g. mixing dlls/binaries from different compilers) - the resulting binary will always crash. Alo

4 6

Re: [boost] Boost.Filesystem i18n mini-review
by Beman Dawes 25 Jul '05

25 Jul '05

At 04:42 AM 7/20/2005, Jan Hermelink wrote: >This is not (yet) a review, but I use your filesystem library in several >unicode projects and am very interested in the wide char implementation. >I have tried wpath and wpath_directory_iterator with two projects and >run in several minor problems: > >- Building >I can't build the DLLs on my system (Windows XP SP2, VC 7.1): > path.cpp(51) : error C2491: 'boost::filesystem::wpath_traits::imbue' : > definition of dllimport function not allowed > >Static builds run fine. This should be fixed soon. Thanks for the report. >- fstream.hpp: > Declaration of function narrow_path(const std::wstring & file_ph, ...) >If several filesystem fstream objects are declared in different >translation units, the linker complains this symbol as multiple defined. > >Adding an inline specifier helps as workaround. > >- fstream.hpp: > Implementation of function narrow_path(const std::wstring & file_ph, >...) >This function doesn't work at all on my system, it returns always the >empty string. Why is this 8.3 conversion needed, It is a hack. To avoid having to modify the standard library (which doesn't support wide-character filenames), the 8.3 names are used instead. These appear to always be narrow even if the full name is wide. > can this work on NTFS reliable? Apparently not. I wasn't aware you could turn them off. >Replacing the current implementation thru a simple narrow conversion >helps as workaround. My understanding (which could be faulty) is that there is no general way to do such a wide to narrow conversion that always works. I'd love to be proven wrong. >- is_symlink() >Why isn't this function implemented on Windows? A NTFS junction is >symlink, isn't it? So I've been told. I tried a couple of times to figure out how to use junctions, but my eyes glazed over long before understanding occurred. >After fixing the above problems the library seems to run fine. > >Thank you for your work! And thank you for your comments! --Beman

1 0

Re: [boost] Call for interest for native unicode character
by Graham 24 Jul '05

24 Jul '05

Message: 2 Date: Sat, 23 Jul 2005 19:32:03 -0400 From: Ben Artin <macdev(a)artins.org> Subject: Re: [boost] Call for interest for native unicode character and string support in boost To: boost(a)lists.boost.org Message-ID: <macdev-DD69FE.19320323072005(a)sea.gmane.org> Dear Ben, Thanks for the reference, I have already taken a look at the previous posts. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1040.pdf does mention the primitive types. I see that vector is a preference as a container - however I don't see any handling of graphemes, words, lines, and sentences which are integral parts on the Unicode 4 specification. Nor do I see any proposal for how to integrate the actual Unicode data which is vital to being able to implement Unicode iterators, sort, upper/lower case conversion, and the rest.... I have not seen anything on providing the necessary support for character information e.g. to convert logical to display order. This data even when optimised will still be several meg of data - but a Unicode implementation cannot fly without it. Nor do I see how you can ensure that if you base Unicode strings on vector that you can ensure that the contents is a Unicode string [e.g. adding the first member of a surrogate only and not adding the second member]. Has the conversation moved on? Where is this currently being discussed? Thanks. Yours, Graham Barnett BEng, MCSD/ MCAD .Net, MCSE/ MCSA 2003, CompTIA Sec+

2 1

Boost regression notification (2005-07-24)
by Douglas Gregor 24 Jul '05

24 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-24T15:10:21Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 700 failures in 10 libraries: filesystem (4) graph (1) lambda (1) multi_index (1) program_options (4) python (4) random (2) serialization (668) test (5) wave (10) |filesystem| operations_test_dll: borland-5_6_4 mingw-3_4_2 path_test_dll: borland-5_6_4 mingw-3_4_2 |graph| graphviz_test: intel-win32-8_1 |lambda| bind_tests_simple_f_refs: vc-8_0 |multi_index| test_projection: vc-8_0 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin |python| iterator: vc-7_1 map_indexing_suite: vc-7_1 pointer_vector: vc-7_1 vector_indexing_suite: vc-7_1 |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 vc-7_1 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_contained_class_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_contained_class_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_contained_class_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_contained_class_text_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_contained_class_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_contained_class_text_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_contained_class_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_contained_class_xml_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_contained_class_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_contained_class_xml_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_cyclic_ptrs_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_cyclic_ptrs_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_cyclic_ptrs_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_cyclic_ptrs_text_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_cyclic_ptrs_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_cyclic_ptrs_text_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_cyclic_ptrs_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_cyclic_ptrs_xml_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_cyclic_ptrs_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_cyclic_ptrs_xml_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_demo: intel-win32-8_1 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception: intel-win32-8_1 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin intel-win32-8_1 test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 test_demo_xml_load: intel-win32-8_1 test_demo_xml_save: intel-win32-8_1 test_derived_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_ptr_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_ptr_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_ptr_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_ptr_text_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_ptr_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_derived_class_ptr_text_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_derived_class_ptr_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_ptr_xml_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_ptr_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_derived_class_ptr_xml_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_derived_class_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_text_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_derived_class_text_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_derived_class_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_xml_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_class_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_derived_class_xml_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_derived_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_text_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_derived_text_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_derived_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_xml_archive_dll: cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_derived_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_derived_xml_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_diamond_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_4 cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_4 cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_4 cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_4 cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_4 cw-9_5-darwin test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_null_ptr_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_binary_archive_dll: cw-9_4 cw-9_5-darwin test_null_ptr_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_text_archive_dll: cw-9_4 test_null_ptr_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_text_warchive_dll: cw-9_4 test_null_ptr_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_xml_archive_dll: cw-9_4 test_null_ptr_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin test_null_ptr_xml_warchive_dll: cw-9_4 test_nvp_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_nvp_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_nvp_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_nvp_text_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_nvp_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_nvp_text_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_nvp_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_nvp_xml_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_nvp_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_nvp_xml_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_recursion_binary_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_recursion_binary_archive_dll: cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_recursion_text_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_recursion_text_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_recursion_text_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_recursion_text_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 test_recursion_xml_archive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_recursion_xml_archive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin mingw-3_4_2 vc-7_1 vc-8_0 test_recursion_xml_warchive: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 test_recursion_xml_warchive_dll: cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-7_1 vc-8_0 |test| errors_handling_test: cw-9_5-darwin test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |wave| test_re2c_lexer: vc-7_1 vc-8_0 test_slex_lexer: vc-7_1 vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-7_1 vc-8_0

2 1

[Slightly OT] How to close bugs on SF?
by Markus Schöpflin 24 Jul '05

24 Jul '05

Hello, I'm wondering how to assign or close a bug report on SF. Do I need special rights for this? If yes, can't we just give those rights to all boost members? Markus

3 10

Call for interest for native unicode character and string support in boost
by Graham 24 Jul '05

24 Jul '05

Hi, I am considering creating a set of Unicode support classes for boost that would add native Unicode support to boost and would like to find out if there is any interest in either using it or helping to write it. 1. unistring This would store UTF16 logically ordered data and allow Unicode actions and iterations. It would be largely similar the basic_string except the iterators supported would be forward only and would be arranged in the following class hierarchy: Data UTF16 - const iterator Grapheme Word Sentence Line Identifier Data: WORDs of data *Data Iterator: WORD UTF16: UTF16 encoded words [i.e. includes surrogates which are two WORDs] *UTF16 Iterator: const WORD Grapheme: What appears to the user as a character but may consist of several UTF16 encoded WORDs [e.g. e followed by acute]. *Grapheme Iterator: unichar Word: Word breaks [n.b. this would not work in languages like Thai where that cannot be computed from the characters]. *Word iterator: unistring [return portion of string as new and independent string] Line: Line breaks [n.b. ditto Thai ...] *Line iterator: unistring [return portion of string as new and independent string] Identifier: Language parsing iterator * Identifier iterator: unistring [return portion of string as new and independent string] All iterators would support basedata() which would convert the iterator to a Data iterator which can then have const cast off as required. The unistring would support equality (=) but not equivalence (<). Equality would perform canonical decomposition on the fly and compare decomposed data. Equivalence would be supported by a separate class called unistringsort. The following methods would be supported: empty size decompose tolower toupper assignUFT7 assignUTF8 assignUTF16 assignUTF32 insertUFT7 insertUTF8 insertUTF16 insertUTF32 find find_if replace replace_if others ... 2. unistringsort unistringsort would have two members, a const unistring and a const vector<WORD> of sort data [4 words per Unicode character]. Equality (=) would not be supported. Equivalence (<) would be supported which would do a level 4 compare on the sort data. Sort level 4 is the level used for display sorting of strings. Other levels allow ignoring case accents etc. The following methods would be supported: equals(const unistringsort & other, sortlevel level) would allow other sort levels (1, 2, 3, and 4) to be tested. const unistring& string() const vector<WORD>* data() Note: Unicode sorting is complex and involves sort decomposition, canonical decomposition, mathematical expansion of characters using a predetermined table and rules to 4 words per character that are then parsed in priority order. 3. unichar A unichar data type would also be created to allow Unicode tests on individual characters which will be DWORDs for ease due to the fact that Unicode characters are 21 bits. This would allow testing of: isstrongright isright isleft isstrongleft isleftjoining isrightjoining isbothjoining isnumeric etc... The implementation would require a few of Meg of data files created from the current Unicode release and my initial thoughts are that the following files would need to be parsed: allkeys.txt CaseFolding.txt GraphemeBreakTest.txt LineBreak.txt SentenceBreakTest.txt SpecialCasing.txt UnicodeData.txt WordBreakTest.txt The data files created would be header files containing native c arrays containing specially organised data to support all the above functionality. A program would be created to produce these files from the source automatically from an up to date Unicode release. The ranges in Blocks.txt would need to be hard coded to support functions like ishangul etc. Questions: 1. Is this worth doing are enough people interested to make it worthwhile? 2. Which would be the best implementation of basic_string to use? 3. Should unistring support equality due to the overhead in decomposition or should there be a decompunistring? 4. Do we need other classes or to include functionality such as the ability to convert to display order? 5. What other methods are required on the classes? 6. Any comments ? Yours, Graham Barnett BEng, MCSD/ MCAD .Net, MCSE/ MCSA 2003, CompTIA Sec+

4 3

Re: [boost] Regressions in your Boost libraries as of 2005-07-19
by Joel de Guzman 24 Jul '05

24 Jul '05

Douglas Gregor wrote: > You are receiving this report because one or more of the libraries you > maintain has regression test failures that are not accounted for. > A full version of the report is sent to the Boost developer's mailing > list. > > Detailed report: > http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… > > There are failures in these libraries you maintain: > spirit (1) > > |spirit| > owi_mt_tests: gcc-3_3-darwin I do not know how to fix this last remaining problem. I desperately need some help! Thanks, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

6 7

[config] Possible bug in config/platform/win32.hpp
by Edward Diener 24 Jul '05

24 Jul '05

In config/platform/win32.hpp I see: #if !defined(__GNUC__) && !defined(BOOST_HAS_DECLSPEC) # define BOOST_HAS_DECLSPEC #endif This tells me that __declspec can be possibly used for all Windows compilers except for gcc. I believe, however, that for Comeau-Win32 __declspec can also not be used. When trying to build Boost libraries for Comeau with the VC7.1 backend, the compiler gives this error in the date/time library when trying to compile greg_month.cpp with BOOST_ALL_DYN_LINK defined: ""H:\Utilities\BoostLibraries\boost_1_32_0\boost/date_time/gregorian/greg_month.h pp", line 55: error #70: incomplete type is not allowed class BOOST_DATE_TIME_DECL greg_month : public greg_month_rep {" ^ I could be wrong but this seems to me that the compiler is objecting to BOOST_DATE_TIME_DECL, which becomes __declspec(dllexport) because BOOST_HAS_DECLSPEC is defined for the Comeau compiler. Needless to say many other errors along thr same lines occur in the build for other libraries which use __declspec(dllexport).

3 4

cvs down?
by Neal Becker 24 Jul '05

24 Jul '05

cvs -z3 update -d -P cvs [update aborted]: unrecognized auth response from cvs.sourceforge.net: M PserverBackend::PserverBackend() Connect (Connection refused)

2 1

[OT] Mailinglist performance
by Martin Wille 23 Jul '05

23 Jul '05

Hi, I'm experiencing long delays between sending a message to this list and getting it back from the list (even a lot longer than the usual hour it took on good days). Also, messages from other people on the list arrive very late here and they often do not appear in the order they've been sent in. Looking at the traces left in the header of Joel's recent message, I see: Received: from 129.79.245.239 (EHLO milliways.osl.iu.edu) (129.79.245.239) by mta184.mail.re2.yahoo.com with SMTP; Sat, 23 Jul 2005 13:22:27 -0700 Received: from milliways.osl.iu.edu (localhost [127.0.0.1]) by milliways.osl.iu.edu (8.12.11/8.12.11/IUCS_2.66) with ESMTP id j6NI1TRS008999; Sat, 23 Jul 2005 13:02:39 -0500 (Note the different timezones.) This seems to indicate the message wasn't processed for two hours at OSL. Is there a problem at OSL? Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com

3 2

[Marketing] Quote on front page?
by Doug Gregor 23 Jul '05

23 Jul '05

The Spirit page (http://spirit.sourceforge.net/) has a quote on its front page, which I find appealing. So I stole the idea and added the C++ Coding Standards quote (which is, perhaps, the most flattering of the few we've collected) to the Boost front page header. The effect can be seen here: http://www.osl.iu.edu/~dgregor/boost/index.htm Opinions? Should this go into the front page? Doug

7 7

Home page adjustments?
by David Abrahams 23 Jul '05

23 Jul '05

The boxes on the right side of the new home page design look like they should be closer together, to me, rather than lined up with the various sections of the left-hand text. Especially when the page is a comfortably narrow width, the Groups/Contribute box ends up too far down. -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 3

[boost-users] [date_time] length of generic periods
by Friedrich Wilckens 23 Jul '05

23 Jul '05

Hi, the concept of the length of generic periods puzzles me. The "normal" case p.length() = p.end() - p.begin() makes sense to me, but why is a period with last() == begin() treated as a special case, having length 0? Having this special case make the length concept behave strangely. For example, [2005-May-1/2005-May-1] has length 0, but [2005-May-1/2005-May-2] has length 2! Actually there is no period of length 1 at all. As I understand from the documentation, the philosophical reason behind this seems to be that the end points of periods are considered "points" and that a point and therefore a period that consists of a single point has zero extension. This sounds plausible if you think of the periods like intervals on the real number line. But our situation is different, I think, since we always deal with discrete quantities that have a finite length (or "duration"). I would interpret the period [2005-May-1/2005-May-1] as the time period that lasts during the whole day 2005-May-1, from 00:00 up to 23:59:59.999... Therefore, I would give it the length (duration) 1. [2005-May-1/2005-Apr-30] would accordingly be an empty period of length 0, and [2005-May-1/2005-Apr-29] would be an invalid period of length -1. The length of a date_period p would then be simply the number of days in p, multiplied with the unit of the duration_type. The template parameter duration_type can be used to defined different measurements of the length. In the standard case (duration of a day is 1) you measure the period length in days. But you could also measure it in seconds, by using a duration_type with unit() = 86400. What do you think about this? Sincerely, Friedrich

2 3

Boost regression notification (2005-07-23)
by Douglas Gregor 23 Jul '05

23 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-23T15:34:21Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 168 failures in 9 libraries: assign (2) filesystem (4) multi_index (38) program_options (4) random (2) serialization (105) test (5) thread (1) wave (7) |assign| multi_index_container: cw-9_5-darwin gcc-3_4_3-sunos |filesystem| operations_test_dll: borland-5_6_4 mingw-3_4_2 path_test_dll: borland-5_6_4 mingw-3_4_2 |multi_index| test_basic: cw-9_5-darwin gcc-3_4_3-sunos test_capacity: cw-9_5-darwin gcc-3_4_3-sunos test_comparison: cw-9_5-darwin gcc-3_4_3-sunos test_composite_key: cw-9_5-darwin gcc-3_4_3-sunos test_conv_iterators: cw-9_5-darwin gcc-3_4_3-sunos test_copy_assignment: cw-9_5-darwin gcc-3_4_3-sunos test_hash_ops: cw-9_5-darwin gcc-3_4_3-sunos test_iterators: cw-9_5-darwin gcc-3_4_3-sunos test_list_ops: cw-9_5-darwin gcc-3_4_3-sunos test_modifiers: cw-9_5-darwin gcc-3_4_3-sunos test_mpl_ops: cw-9_5-darwin gcc-3_4_3-sunos test_observers: cw-9_5-darwin gcc-3_4_3-sunos test_projection: cw-9_5-darwin gcc-3_4_3-sunos test_range: cw-9_5-darwin gcc-3_4_3-sunos test_safe_mode: cw-9_5-darwin gcc-3_4_3-sunos test_set_ops: cw-9_5-darwin gcc-3_4_3-sunos test_special_list_ops: cw-9_5-darwin gcc-3_4_3-sunos test_special_set_ops: cw-9_5-darwin gcc-3_4_3-sunos test_update: cw-9_5-darwin gcc-3_4_3-sunos |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin vc-8_0 test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin |test| errors_handling_test: cw-9_5-darwin test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |thread| test_thread_lib: mingw-3_4_2 |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0

1 0

Re: [boost] [serialization] bug in latest changetoboost/serialization/base_object.hpp
by JOAQUIN LOPEZ MU?Z 23 Jul '05

23 Jul '05

Hello Robert, ----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Viernes, Julio 22, 2005 3:15 pm Asunto: Re: [boost] [serialization] bug in latest changetoboost/serialization/base_object.hpp > Sorry, I fixed this but I see someone already beat me to it. It was me, I finally managed to grab CVS access yesterday. > > I'll add a compile only test for this. > Thank you! There's still a pending problem with boost/serialization/base_object.hpp in tru64cxx65-042 and como-4_3_3-vc7_1 (both EDG-based): http://tinyurl.com/9a5em http://tinyurl.com/d25mz Basically, the compiler detects at compile time and bans dereferencing a null pointer as it's done in static const void_cast_detail::void_caster & invoke(){ return static_cast<const void_cast_detail::void_caster &>( * static_cast<const void_cast_detail::void_caster *>(NULL) ); } This is the same problem as previously discussed (in other context) in http://article.gmane.org/gmane.comp.lib.boost.devel/126588 The problem is currently breaking all Boost.Serialization tests in the aforementioned toolsets. As this implementation has been recently included to cope with some CW problems, maybe an easy workaround is to have it only for that platform, and revert to the previous "static void invoke" interface for other toolsets. Another alternative (not tested) could be resorting to a dummy non-null pointer: static const void_cast_detail::void_caster & invoke(){ static const void_cast_detail::void_caster * dummy_ptr; return * dummy_ptr; } I'm sorry I can't be more helpful, but I'm on a short vacation, away from my development environment (writing this from an Internet café.) Hope this helps a little, though. Good luck, Joaquín M López Muñoz Telefónica, Inevstigación y Desarrollo

1 0

Question about shared_prt doc's
by Joe Gottman 23 Jul '05

23 Jul '05

In the documentation for the shared_ptr constructor that takes a weak_ptr parameter, it says that if the weak_ptr is empty then so is the constructed shared_ptr. But it also says that if the weak_ptr has a use_count() of 0 then a bad_weak_ptr exception is thrown. Since an empty weak_ptr has a use_count() of 0, these statements can't both be true. Which one is? Joe Gottman

2 2

Potentially breaking change in VC8
by Carl Daniel 23 Jul '05

23 Jul '05

Current builds of VC8 (newer than the June CTP) are implementing the change suggested by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html I don't know how or if this affects any Boost code, but it's something to watch out for. I would expect the next CTP of VC8 may well include this change. -cd PS: The change makes code like this ill-formed: template <unsigned n> struct bit_count { enum { value = n ? bit_count<n >> 1>::value+1 : 0 }; }; template <> struct bit_count<0> { enum { value = 0 }; };

1 0

[parameter] New libraries docs?
by Rene Rivera 22 Jul '05

22 Jul '05

The new Parameter library is not listed in the usual places where new libraries are listed. What's up with that? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

2 1

Lambda::bind, throw() and VC71
by Richard Crossley 22 Jul '05

22 Jul '05

The following simple example fails to compile with VC71, (OK with Intel 8.1). Is there a workaround for this? Regards, Richard. ---------------------- #include <boost/lambda/bind.hpp> struct S{ void mfn1(){}; void mfn2() throw() {}; }; int main() { using namespace boost::lambda; S s; bind(&S::mfn1,_1)(s); // OK bind(&S::mfn2,_1)(s); // Error with VC71 } ---------------------- cl /c /Od /Gm /EHsc /RTC1 /MLd /Zc:wchar_t /Zc:forScope /GR /ZI /W3 /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Fo"Debug/" /Fd"Debug/vc70.pdb" /Gd /TP .\TestBind.cpp TestBind.cpp c:\boost\boost\lambda\detail\bind_functions.hpp(220) : error C2664: 'boost::lambda::lambda_functor<T>::lambda_functor(const boost::lambda::lambda_functor<T> &)' : cannot convert parameter 1 from 'boost::lambda::lambda_functor_base<Act,Args>' to 'const boost::lambda::lambda_functor<T> &' with [ T=boost::lambda::lambda_functor_base<boost::lambda::action<2,boost::lambda:: function_action<2>>,boost::tuples::tuple<const boost::lambda::detail::bind_traits<void (__thiscall S::* const )(void)>::type,const boost::lambda::detail::bind_traits<const boost::lambda::placeholder1_type>::type,boost::lambda::detail::bind_traits::type,boost::lambda::detail::bind_traits<boost::tup les::null_type>::type,boost::lambda::detail::bind_traits<boost::tuples::null _type>::type,boost::lambda::detail::bind_traits<boost::tuples::null_type>::t ype,boost::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost ::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost::lambda: :detail::bind_traits<boost::tuples::null_type>::type,boost::lambda::detail:: bind_traits<boost::tuples::null_type>::type>> ] and [ Act=boost::lambda::action<2,boost::lambda::function_action<2>>, Args=boost::tuples::tuple<const boost::lambda::detail::bind_traits<void (__thiscall S::* const )(void) throw()>::type,const boost::lambda::detail::bind_traits<const boost::lambda::placeholder1_type>::type,boost::lambda::detail::bind_traits::type,boost::lambda::detail::bind_traits<boost::tup les::null_type>::type,boost::lambda::detail::bind_traits<boost::tuples::null _type>::type,boost::lambda::detail::bind_traits<boost::tuples::null_type>::t ype,boost::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost ::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost::lambda: :detail::bind_traits<boost::tuples::null_type>::type,boost::lambda::detail:: bind_traits<boost::tuples::null_type>::type> ] and [ T=boost::lambda::lambda_functor_base<boost::lambda::action<2,boost::lambda:: function_action<2>>,boost::tuples::tuple<const boost::lambda::detail::bind_traits<void (__thiscall S::* const )(void)>::type,const boost::lambda::detail::bind_traits<const boost::lambda::placeholder1_type>::type,boost::lambda::detail::bind_traits::type,boost::lambda::detail::bind_traits<boost::tup les::null_type>::type,boost::lambda::detail::bind_traits<boost::tuples::null _type>::type,boost::lambda::detail::bind_traits<boost::tuples::null_type>::t ype,boost::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost ::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost::lambda: :detail::bind_traits<boost::tuples::null_type>::type,boost::lambda::detail:: bind_traits<boost::tuples::null_type>::type>> ] Reason: cannot convert from 'boost::lambda::lambda_functor_base<Act,Args>' to 'const boost::lambda::lambda_functor<T>' with [ Act=boost::lambda::action<2,boost::lambda::function_action<2>>, Args=boost::tuples::tuple<const boost::lambda::detail::bind_traits<void (__thiscall S::* const )(void) throw()>::type,const boost::lambda::detail::bind_traits<const boost::lambda::placeholder1_type>::type,boost::lambda::detail::bind_traits::type,boost::lambda::detail::bind_traits<boost::tup les::null_type>::type,boost::lambda::detail::bind_traits<boost::tuples::null _type>::type,boost::lambda::detail::bind_traits<boost::tuples::null_type>::t ype,boost::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost ::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost::lambda: :detail::bind_traits<boost::tuples::null_type>::type,boost::lambda::detail:: bind_traits<boost::tuples::null_type>::type> ] and [ T=boost::lambda::lambda_functor_base<boost::lambda::action<2,boost::lambda:: function_action<2>>,boost::tuples::tuple<const boost::lambda::detail::bind_traits<void (__thiscall S::* const )(void)>::type,const boost::lambda::detail::bind_traits<const boost::lambda::placeholder1_type>::type,boost::lambda::detail::bind_traits::type,boost::lambda::detail::bind_traits<boost::tup les::null_type>::type,boost::lambda::detail::bind_traits<boost::tuples::null _type>::type,boost::lambda::detail::bind_traits<boost::tuples::null_type>::t ype,boost::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost ::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost::lambda: :detail::bind_traits<boost::tuples::null_type>::type,boost::lambda::detail:: bind_traits<boost::tuples::null_type>::type>> ] No constructor could take the source type, or constructor overload resolution was ambiguous c:\Source\TestBind\TestBind.cpp(13) : see reference to function template instantiation 'const boost::lambda::lambda_functor<T> boost::lambda::bind<void(__thiscall S::* )(void),boost::lambda::placeholder1_type>(const Arg1 & ,const Arg2 &)' being compiled with [ T=boost::lambda::lambda_functor_base<boost::lambda::action<2,boost::lambda:: function_action<2>>,boost::tuples::tuple<const boost::lambda::detail::bind_traits<void (__thiscall S::* const )(void)>::type,const boost::lambda::detail::bind_traits<const boost::lambda::placeholder1_type>::type,boost::lambda::detail::bind_traits::type,boost::lambda::detail::bind_traits<boost::tup les::null_type>::type,boost::lambda::detail::bind_traits<boost::tuples::null _type>::type,boost::lambda::detail::bind_traits<boost::tuples::null_type>::t ype,boost::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost ::lambda::detail::bind_traits<boost::tuples::null_type>::type,boost::lambda: :detail::bind_traits<boost::tuples::null_type>::type,boost::lambda::detail:: bind_traits<boost::tuples::null_type>::type>>, Arg1=void (__thiscall S::* )(void), Arg2=boost::lambda::placeholder1_type ]

2 1

[parameter] Tutorial checked in
by David Abrahams 22 Jul '05

22 Jul '05

I think the tutorial documentation is close to complete. Last minute editorial comments would be appreciated. See libs/parameter/doc/html/index.html The best way to make comments is to embed them in a copy of the source: libs/parameter/doc/index.rst and post that. Don't worry about whether I'll miss the comment; I have diff tools ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com

9 42

Boost regression notification (2005-07-22)
by Douglas Gregor 22 Jul '05

22 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-22T14:42:00Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 449 failures in 10 libraries: assign (12) filesystem (4) multi_index (304) program_options (5) ptr_container (1) random (2) serialization (108) spirit (1) test (5) wave (7) |assign| multi_index_container: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-win32-8_1 mingw-3_4_2 vc-8_0 |filesystem| operations_test_dll: borland-5_6_4 mingw-3_4_2 path_test_dll: borland-5_6_4 mingw-3_4_2 |multi_index| test_basic: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_capacity: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_comparison: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_composite_key: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_conv_iterators: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_copy_assignment: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_hash_ops: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_iterators: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_list_ops: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_modifiers: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_mpl_ops: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_observers: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_projection: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_range: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_safe_mode: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_set_ops: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_special_list_ops: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_special_set_ops: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 test_update: cw-8_3 cw-9_4 cw-9_5-darwin 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-4.0.0-linux intel-8.1-linux intel-win32-8_1 mingw-3_4_2 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |ptr_container| view_example: vc-8_0 |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_exported_text_archive: vc-8_0 test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_registered_xml_archive: intel-win32-8_1 test_shared_ptr_132_binary_archive_dll: intel-win32-8_1 test_shared_ptr_binary_archive_dll: vc-8_0 |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0

1 0

[Boost-bugs] [ boost-Bugs-1242266 ] Move comments in BOOST_STATIC_CONSTANT
by SourceForge.net 22 Jul '05

22 Jul '05

Bugs item #1242266, was opened at 2005-07-21 05: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=1242266&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: type_traits Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: Move comments in BOOST_STATIC_CONSTANT Initial Comment: There appears to be some comments in one of the macro function calls of BOOST_STATIC_CONSTANT (line 124 of "type_traits/is_enum.hpp): BOOST_STATIC_CONSTANT(bool, selector = (::boost::type_traits::ice_or< ::boost::is_arithmetic<T>::value , ::boost::is_reference<T>::value , is_class_or_union<T>::value // However, not doing this on non-conforming compilers prevents // a dependency recursion. >::value)); This is not incorrect but it expands to incorrect code in case you run the Visual Studio.NET 2002/2003/2005 C++ compiler with the compiler options "/E /C". The result after preprocessing is: // However, not doing this on non-conforming compilers prevents// a dependency recursion.enum { selector = (::boost::type_traits::ice_or< ::boost::is_arithmetic<T>::v alue , ::boost::is_reference<T>::value , is_class_or_union<T>::value >::value) }; which obviously hides the definition of "selector"! Since we are performing code checking on the preprocessed file our code checker is unable to check C++ files that contain "is_enum.hpp". This is clearly a bug in the Visual Studio C++ compiler, but my hopes are that the comments can be moved in Boost, e.g. towards the start of the macro function call or the end. This will solve the problem of being able to code check this file. It might solve problems with other preprocessors as well. In case you need further details, contact me at Paul.Jansen(a)tiobe.com. Regards, Paul Jansen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1242266&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

2 1

[serialization] bug in latest change to boost/serialization/base_object.hpp
by JOAQUIN LOPEZ MU?Z 22 Jul '05

22 Jul '05

Hello, A change to boost/serialization/base_object.hpp made 10 hrs ago is currently breaking virtually every Boost.MultiIndex test in every platform: as of now, already four engines are showing the problem, see for instance http://tinyurlcom/ccaqx. More will come. The bug is silly enough, some names are not declared but used when boost/serialization/base_object.hpp is included without having previously included any of boost/archive/*.hpp. Please somebody fix this, currently I don't have CVS access, can't do it myself. I don't want to sound harsh, but it is my humble opinion that this kind of trivial bugs should be checked against before commiting to the CVS. For the record, a similar problem (undeclared stuff if no archive header is included) popped up some weeks ago in exactly the same fashion, current vacpp results (not updated since quite some time) are a sad memory of that bug, see http://tinyurl.com/7tyda. This would be trivially detected before commiting if only a test would be added to Boost.Serialization testsuite that merely included serialization headers but no archive headers. No current test is doing that (except mine :) which is a serious hole wrt to source code coverage, as we're seeing now. Anyway, now it's too close to 1.33, maybe this suggestion could be taken into consideration after release. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[serialization] Building for Borland problem
by Edward Diener 22 Jul '05

22 Jul '05

I downloaded the standalone Spirit 1.62 and put it in a directory of my machine. I set SPIRIT_ROOT to that directory in my environment. I then used bjam to build my Boost libraries for Borland and Bcb6. The serialization build reports errors from the spirit/core/config.hpp in my Boost 1.32 directory tree that my compiler is not supported. Of course I was expecting it to pick up Spirit files from my SPIRIT_ROOT directory tree. Why is this not working correctly ?

1 0

random_test regressions (and some solutions)
by John Maddock 22 Jul '05

22 Jul '05

I've tracked down the cause of the random_test failures with some Win32 compilers (Borland and Intel 8 and 9 certainly). Within the test, the random number generator gets passed around by value when constructing a variate_generator. However there are a couple of generators that contain large arrays of long's (the mersenne twister is the first to be tested that has this problem). It's reasonably well known that on Windows, copying large arrays on the stack can overrun Window's stack protection and growth mechanism, resulting in the program trying to write to an invalid address. For the Borland compiler, adding: <linkflags>-lS:8000000 <linkflags>-lSc:8000000 Fixes the regression. For Intel adding: <linkflags>-STACK:8000000:8000000 Works most of the time, but seems to be a bit capricious (it appears you have to delete all temporary linker files before attempting the link, otherwise strange things happen). I'm not even sure if this is the right fix: should we really be passing such large arrays around on the stack in the first place? John.

2 2

[Boost-bugs] [ boost-Bugs-1242857 ] Can't delete automatically in circularly included object.
by SourceForge.net 22 Jul '05

22 Jul '05

Bugs item #1242857, was opened at 2005-07-22 00:30 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=1242857&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: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: Can't delete automatically in circularly included object. Initial Comment: hi,all: I am a chinese student.Please forgive me because of my poor english. I found an error on smart pointer shared_ptr when i add an shared_ptr object to itself. The code is below.Class StatusBase is a subclass of Status.There is a method name addEventResult in class StatusBase. As you can see, EventResult is an object which made up of object Status( StatusBase actually because of Status is an abstract class ),Action and Event.In the case, I try to let them passed in share_ptr wrpper whenever in constructor or normal method.As my opinion,I think that will not be error and when I exit my program it will free the memory for me automatically. But in fact it will not. shared_ptr<Status> A( new Status() ); shared_ptr<Event> B( new Event() ); shared_ptr<Action> C( new Action() ); shared_ptr<EventResult> ABC( new EventResult( A, B, C ) ); //the row below will result the object A can't be released, so as to the object ABC , B and C A.addEventResult( ABC ); //next is about the decleartion of StatusBase and EventResult. For class Event and Action, it is the history. class StatusBase : public Status //{{{ { public: StatusBase(){} virtual ~StatusBase(){} public: int getEventResultCount() const ; boost::shared_ptr<EventResult> getEventResult( int index ) const ; void addEventResult( const boost::shared_ptr<EventResult>& v ) ; private: std::vector< boost::shared_ptr<EventResult> > events ; }; //}}} class EventResult : public pqkit::Object //{{{ { public: EventResult( const boost::shared_ptr<Event>& e, const boost::shared_ptr<Action>& a, const boost::shared_ptr<Status>& s ) : event(e),action (a),newStatus(s){} virtual ~EventResult() {} public: virtual const std::string toString() const { return Object::toString() ; } virtual const pqkit::Class getClass() const { return pqkit::Class("EventResult","inhert:Object->EventResult"); } boost::shared_ptr<Event> getEvent() const { return event; } boost::shared_ptr<Action> getAction() const { return action; } boost::shared_ptr<Status> getNewStatus() const { return newStatus; } private: boost::shared_ptr<Event> event ; boost::shared_ptr<Action> action ; boost::shared_ptr<Status> newStatus ; }; //}}} yours JinheZeng at GDUT from China. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1242857&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Random] Mersenne Twister initialization problem [PATCH]
by Tiago de Paula Peixoto 21 Jul '05

21 Jul '05

Hi. The Mersenne Twister RNG was updated by the original author in 2002, because of a small problem in the seeding procedure, which was that the most significant bit of the seed was not well reflected to the state vector. Read http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html for more details. The version implemented in Boost is the original 1998 one, which contains the problem. The attached patch implements the new seeding procedure, which uses something different than the linear congruential RNG to initialize the state vector. I haven't identified the new procedure to match any generator already implemented in Boost, so I just wrote it there (please correct me if I'm wrong). I have compared the output to the official implementation output, and it's identical. If the patch is OK, could it be applied? Thanks. -- Tiago de Paula Peixoto <tiago(a)forked.de>

4 5

enable_if for partial specialization of fnc
by Neal Becker 21 Jul '05

21 Jul '05

I have a question on usage of enable_if for faking partial specialization of function templates. Suppose I have a func F that has a general implementation, and a partial specialization for std::complex<T>. The obvious way to do this is to forward to a class member: template<typename T> struct F_impl { void DoF (); }; template<typename T> struct F_impl<std::complex<T> >{ void DoF (); }; template<typename T> void F () { F_impl<T>(); } Alternatively, I can define is_cmplx: template<typename T> struct is_cmplx { static const bool value = false; }; template<typename FLT> struct is_cmplx<std::complex<FLT> > { static const bool value = true; }; And use enable_if/disable_if. Both work. My question is, why would I prefer one over the other approach?

2 1

Links to deprecated and outdated mailing archives
by Pavel Chikulaev 21 Jul '05

21 Jul '05

Hi all, There is a link to deprecated mail archive MailMan Archive http://lists.boost.org/MailArchives/boost/ (That page explicitly says that it's deprecated and there is no new messages since 2 April 2005) at http://boost-consulting.com/boost/more/mailing_lists.htm#main. Also page http://www.mail-archive.com/boost%40lists.boost.org/ mentioned at the same page at boost.org doesn't seem up to date (Last message dated 4 September 2003). These links should be removed isn't it? And search from the home page at doesn't look working good - it seems like it actually searching all the archives (they should be identical isn't?) and sometimes a search lead to these archives. This should be changed IMO. -- Pavel Chikulaev

1 0

Re: [boost] singleton_ptr
by cedric.venet 21 Jul '05

21 Jul '05

> > > > struct MySingletonCategory; > > > > // must provide specializations in singleton namespace > > namespace boost { namespace singleton { > > > > // the following specifies that multi threading will be used for > > singletons which use MySingletonCategory > > template < > > > struct threading_policy < MySingletonCategory > > > { > > typedef multi_threaded type; > > }; > > This should be called *trait* not a policy. Policy is type orthogonal. And > btw I don't think traits-based solution will work here. I most definitely > may want different threading policies for the same singleton type in > different circumstances. > why not simply pass the category as a template parameter: struct MyCategory ; namespace boost { namespace singleton { template < > struct threading_policy < MyCategory > { typedef multi_threaded type; }; } } // close namespace void test ( ) { singleton_ptr < MySingletonType,MyCategory > ptr; } you can have the same category for many type but also many category for one type. if you really want no policy in the type declaration, you can provide a default who would search for a type declared category as in your code (I am not very understandable I think, perhaps the following code while be more explicit): struct defaultcategory; tempate< class T, class category_param = defaultcategory > class singleton_ptr { typedef mpl::if< mpl::IsSame<category_param,defaultcategory>, category<T>::type, category_param>::type the_category; ... }; the syntaxe is perhaps not correct but it's the principe who count. so you can use: struct another_type; template<> category<another_type> { typedef MT_category type; }; int main() { singleton_ptr<MyType> a_defaut_singleton; singleton_ptr<another_type> a_MT_singleton; singleton_ptr<MyType,MT_category> another_MT_singleton; } perhaps it don't work, or it's stupid, but perhaps it can help you. And sorry for my poor english. you can also want to read the papers here: http://www.prakinf.tu-ilmenau.de/~czarn/cpe2000/ --(space [webmail cut my space :( ) Cédric Venet ECP student Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34/mn) ; tél : 08 92 68 13 50 (0,34/mn)

2 1

[Threads] incorrect citation
by David Abrahams 21 Jul '05

21 Jul '05

"Concurrent Programming Concepts" is incorrectly cited as having been published in 1983. It was '73. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

My ports being scanned by boost.sourceforge.net?
by Pavel Chikulaev 21 Jul '05

21 Jul '05

Hi all, I've got a software firewall installed on my Windows XP machine, and while surfing www.boost.org I've received Attack detection report that said that boost.sourceforge.net(66.35.250.209) was scanning my ports (3953, 3943, 3889, 3881, 3835, 3826). What can it be? Any thoughts? -- Pavel Chikulaev

2 1

Boost regression notification (2005-07-21)
by Douglas Gregor 21 Jul '05

21 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-21T15:30:19Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 133 failures in 8 libraries: filesystem (4) program_options (5) random (2) serialization (107) spirit (1) test (6) thread (1) wave (7) |filesystem| operations_test_dll: borland-5_6_4 mingw-3_4_2 path_test_dll: borland-5_6_4 mingw-3_4_2 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_registered_xml_archive: intel-win32-8_1 test_shared_ptr_132_binary_archive_dll: intel-win32-8_1 |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |thread| test_thread_lib: vc-7_0 |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0

1 0

[serialization] Why can't hyphens appear in NVP's?
by Jonathan Turkanis 21 Jul '05

21 Jul '05

Hi, I'm using the serialization library for the first time. Everything works pretty nicely, but I'm a little surprised that I can't use hyphens in the first component of a name-value pair. What's the purpose of this restriction? As long as the hyphen is not the first character of a name, it should correspond to perfectly legal XML. Jonathan

6 20

Re: [boost] Regressions in your Boost libraries as of 2005-07-13
by Jens Maurer 21 Jul '05

21 Jul '05

Douglas Gregor wrote: > You are receiving this report because one or more of the libraries you > maintain has regression test failures that are not accounted for. > A full version of the report is sent to the Boost developer's mailing > list. > > Detailed report: > http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… > > There are failures in these libraries you maintain: > random (2) > > |random| > random_test: intel-win32-8_1 intel-win32-8_1 I'm sorry, but I think I can't do anything about that. I can only imagine there is an optimization issue here, but I don't have Windows and thus can't test the Windows compiler. :-/ Jens Maurer

2 1

[serialization] using non-intrusive load and save
by Jonathan Turkanis 21 Jul '05

21 Jul '05

Hi, What's the recommended way to spit non-intrusive serialization into two functions? It looks like I could use tag dispatch with the nested metafunction is_saving or is_loading, but I want to give a very simple example of non-intrusive serialization. Also, is there any reason that instances of these metafunctions aren't convertible to bool, like the boolean metafunctions from type_traits and mpl? Jonathan

1 1

Minor bug in shared_ptr documentation
by Joe Gottman 21 Jul '05

21 Jul '05

The documentation for the shared_ptr default constructor has the following sentence in the Effects clause: "Empty shared_ptr objects have an unspecified use_count." This is no longer true, since the default constructor now includes the postcondition that use_count() == 0. Joe Gottman

1 0

Re: [boost] Interest in a binary_int template for binary literals?
by Scott Schurr 20 Jul '05

20 Jul '05

Greetings, I've placed the binary_int template in the Boost sandbox at Sourceforge. I've also included a crude unit test and a rough shot at documentation. I'd like to thank Pavel Vozenilek for his improvements on the template and for his guidance through the Boost process. I'm going to be on vacation for the next week (until July 25th). So if you send comments I'll get back to you after I return. Thanks for your attention. Scott Schurr

3 2

compile time version of double
by Peder Holt 20 Jul '05

20 Jul '05

I have now completed a compile time version of double which (as far as I have been able to test) the same results as the runtime equivalent. I have implemented mpl-support for all arithmetic operations plus all comparison operations. To test the accuracy, I have tested it against Cromwells sine-implementation (which by the way had a bug: In stead of 1-(angle*angle*/((2*i+2)*(2*i+3))*next_term it had (angle*angle*/((2*i+2)*(2*i+3))*next_term-1) and got the same result as a runtime-equivalent implementation of the same algorithm. There are four ways to construct a double: integral_to_double<mpl::int_<-355> > or integral_c_to_double<int,-355>::type string_c_to_double<3,'.',1,4,1,5,9,2,6,5,3,5,8,9,7,9,3,2,3,8,4,6,2,6,4,3,3,8,3,2,7,9> typedef BOOST_DOUBLE(3.141592653589793238462643383279502884197169399375105820974944592) pi; double_<mantissa<0x6487ed51,0x085a3000>,1,0> <-Equivalent of pi. The algorithm behind string_c_to_double is not very efficient, so if anyone has a better idea for an implementation, feel free to contribute :) BOOST_DOUBLE is a non-compliant macro that relies on compile time behaviour of floating operations. I have not yet added code to handle +-infinity,QNan,and SNan, but this is relatively easy. 0.0 is not represented correctly (has wrong exponent when converted to double) +0.0 does not equal -0.0 yet. On the upside, this implementation uses a 61 bit mantissa, so it is possible to utilize the full mantissa without rounding when calculating e.g. sine. This is done using boost::metamath::detail::plus_double_double<a,b>::type boost::metamath::detail::times_double_double<a,b>::type boost::metamath::detail::divides_double_double<a,b>::type The user should then deal with rounding before returning the final value: boost::metamath::detail::round<a>::type; or boost::metamath::detail::cutoff<a>::type; if no rounding is wanted. The source is available from the vault: http://boost-sandbox.sourceforge.net/vault/ <metamath.zip> Regards, Peder Holt

3 9

Boost regression notification (2005-07-20)
by Douglas Gregor 20 Jul '05

20 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-20T14:32:43Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 135 failures in 10 libraries: filesystem (2) multi_index (1) program_options (5) random (2) serialization (110) spirit (1) test (5) thread (1) variant (1) wave (7) |filesystem| operations_test_dll: borland-5_6_4 path_test_dll: borland-5_6_4 |multi_index| test_special_list_ops: vc-8_0 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_registered_xml_archive: intel-win32-8_1 test_shared_ptr_132_binary_archive_dll: intel-win32-8_1 test_variant_binary_archive: vc-8_0 |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |thread| test_thread: cw-8_3 |variant| variant_test5: gcc-3.2.3-linux |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0

1 0

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 20 Jul '05

20 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart > From: "Jost, Andrew" <Andrew_Jost(a)mentor.com> > > From: boost-bounces(a)lists.boost.org <clip> > > example code (BTW, others seem to prefer the spelling > "adaptor," which > > is more consistent with other standardized names like > "iterator," so > > I'll conform to that): > > I took a look at "adapter" and "adaptor" at dictionary.com. > Most dictionaries list "adapter" as the main entry and > "adaptor" as a variant. WordNet at Princeton University > makes the two synonymous only for this usage. > > A quick Google search showed 18.2 million hits for "adapter" and > 4.1 million for "adaptor." > > I think "adapter" is the right spelling in this case. > I also checked dictionary.com and came to the same initial conclusion, but so many people used "adaptor" in their replies that it made me wonder whether that spelling was more appropriate. I prefer whichever spelling is intuitive for most users. <clip> > > > // METHOD #2a: define a custom predicate template< class T, class > > Pred, T Def = T() > class optPred : public > > std::binary_function<boost::optional<T>, > > boost::optional<T>, bool> { > > Pred f; > > T _eval( const boost::optional<T>& x ) const { > > return ( x ? x.get() : Def ); > > } > > public: > > optPred() : f( Pred() ) {} > > bool operator()( const first_argument_type& a, const > > second_argument_type& b ) const { > > return f( _eval(a), _eval(b) ); > > } > > }; > > opt_int opt_max; > > opt_max= *std::max_element( v.begin(), v.end(), optPred< int, > > std::less<int>, -1 >() ); > > That's a lot of work. You'd want to use something like > Boost.Lambda to make this more reasonable. > Yes, way too much work. See below. > > // METHOD #2b: use an adaptor-like predicate template< > class T > class > > adaptor_substitute : public std::unary_function< > boost::optional<T>, T > > > { > > T Def; > > public: > > _adaptor_() : Def( T() ) {} > > _adaptor_(T def) : Def( def ) {} > > T operator()(const argument_type& x ) { > > return ( x ? x.get() : Def ); > > } > > }; > > max = *std::max_element( > > boost::make_transform_iterator( v.begin, > > adaptor_substitute<int>(-1) ), > > boost::make_transform_iterator( v.end, > adaptor_substitute<int>(-1) > > ) > > ); > > This isn't really an adapter substitute. It is an adapter, > adapted (pun intended) to be a predicate. > But a predicate must return bool, not T. Did I miss something? > > // METHOD #3: use an adaptor > > max = *std::max_element( > > boost::make_transform_iterator( v.begin, > > boost::optional<int>::adaptor(-1) ), // NOTE: > > boost::optional<int>::adaptor does not currently exist > > boost::make_transform_iterator( v.end, > > boost::optional<int>::adaptor(-1) ) > > ); > > That is clearly the most straightforward of the bunch, but > I'd like to see a proper Boost.Lambda or Boost.Function > variant for comparison. > I would prefer to use Boost.Lambda, but I am currently stuck on VC6 for Win32 development. It is becoming a problem... > BTW, why have you shown the adapter as a nested type of > boost::optional? Do you not think it is applicable to > anything else? I can envision adapting pointers or even > floating point types (where NaN is the "empty" value), to > name just two more types adapter might support. I guess I started with Boost.Optional in mind and never considered anything else. Also, depending on the implementation the adapter may need to interact with Boost.Optional. Can you provide examples of some ways you might use an adapted pointer or float? -Andy

2 1

[parameter] Preliminary Reference Checked In
by David Abrahams 20 Jul '05

20 Jul '05

Before he went away for the week, Daniel Wallin was working on the reference docs. I checked in what he had done so far (libs/parameter/doc/html/reference.html), and embedded comments in the .rst file at libs/parameter/doc/reference.rst. I got about halfway through the document adding comments. It might be helpful to Daniel to finish quickly when he gets back if some other people felt like picking up the editorial commenting. IMO it's still quite rough, so be warned -- it may not be easy. Also, please read my embedded comments to get an idea of the direction I'm going in before you start adding yours. Regards, -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Interest in Graph Clustering Algorithms
by Eric Breimer 20 Jul '05

20 Jul '05

We are interested in submitting a collection of novel graph clustering algorithms to the Boost Graph Library and we wanted to see if there was any interest. Unlike conventional clustering algorithms that partition a graph into disjoint subsets, our algorithms efficiently compute locally optimal dense subsets. This can lead to overlapping clusters, which has advantages in many applications. The algorithms have been shown to work effectively on both synthetic and real-world graphs, and also have been shown to outperform well-known k-neighborhood heuristics. See: 1. http://www.cs.rpi.edu/~goldberg/publications/isi-05-clust.pdf 2. http://www.cs.rpi.edu/~goldberg/publications/iadis-clus.doc The algorithms are truly general-purpose. They work on any type of graph; A user only needs to supply a density metric. A density metric can factor the size of the cluster to help control or regulate the size of the desired clusters. We have efficient algorithms for creating an initial set of clusters based on a given density metric, and we have efficient algorithms that can refine and optimize the density of an existing set of clusters.

1 0

Boost regression notification (2005-07-19)
by Douglas Gregor 20 Jul '05

20 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-19T15:08:59Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 143 failures in 11 libraries: filesystem (4) io (1) lambda (1) multi_index (5) parameter (1) program_options (5) random (2) serialization (110) spirit (1) test (6) wave (7) |filesystem| operations_test_dll: borland-5_6_4 mingw-3_4_2 path_test_dll: borland-5_6_4 mingw-3_4_2 |io| ios_state_unit_test: intel-win32-8_1 |lambda| exception_test: vc-8_0 |multi_index| test_basic: intel-win32-8_1 test_mpl_ops: intel-win32-8_1 test_range: intel-win32-8_1 test_set_ops: intel-win32-8_1 test_update: intel-win32-8_1 |parameter| sfinae: cw-8_3 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 vc-7_1 vc-8_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_list_text_archive: vc-8_0 test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0

2 1

Re: [boost] Boost.Filesystem i18n mini-review
by Jan Hermelink 20 Jul '05

20 Jul '05

Russell Hind wrote: > Peter Dimov wrote: >> >> No. 8.3 aliases are optional on NTFS and turning them off improves >> the performance of the file system, sometimes significantly. >> > > Do you have any links to documentation on this (MSDN or whatever?) I > didn't realise you could disable that feature and would be interested > to > read about the advantages/disadvantages of doing so. Sorry, no link. Bit I have described the registry value for this in my other post. You also can use the "fsutil" command: fsutil.exe behavior query disable8dot3 queries your setting, and fsutil.exe behavior set disable8dot3 1 disables 8.3 alias generation. Jan

1 0

Re: [boost] Boost.Filesystem i18n mini-review
by Jan Hermelink 20 Jul '05

20 Jul '05

This is not (yet) a review, but I use your filesystem library in several unicode projects and am very interested in the wide char implementation. I have tried wpath and wpath_directory_iterator with two projects and run in several minor problems: - Building I can't build the DLLs on my system (Windows XP SP2, VC 7.1): path.cpp(51) : error C2491: 'boost::filesystem::wpath_traits::imbue' : definition of dllimport function not allowed Static builds run fine. - fstream.hpp: Declaration of function narrow_path(const std::wstring & file_ph, ...) If several filesystem fstream objects are declared in different translation units, the linker complains this symbol as multiple defined. Adding an inline specifier helps as workaround. - fstream.hpp: Implementation of function narrow_path(const std::wstring & file_ph, ...) This function doesn't work at all on my system, it returns always the empty string. Why is this 8.3 conversion needed, can this work on NTFS reliable? Replacing the current implementation thru a simple narrow conversion helps as workaround. - is_symlink() Why isn't this function implemented on Windows? A NTFS junction is symlink, isn't it? After fixing the above problems the library seems to run fine. Thank you for your work! Jan

3 3

Re: [boost] Boost.Filesystem i18n mini-review
by Jan Hermelink 20 Jul '05

20 Jul '05

Peter Dimov wrote: > Jan Hermelink wrote: > >> - fstream.hpp: >> Implementation of function narrow_path(const std::wstring & >> file_ph, ...) This function doesn't work at all on my system, it >> returns always the empty string. Why is this 8.3 conversion needed, >> can this work on NTFS reliable? > > No. 8.3 aliases are optional on NTFS and turning them off improves the > performance of the file system, sometimes significantly. Now I remember it: In fact I have turned off the 8.3 aliases for my machine months ago. I have set the registry value NtfsDisable8Dot3NameCreation (HKLM\System\CurrentControlSet\Control\FileSystem) to 1. Jan

1 0

[config] Why is BOOST_HAS_LONG_LONG defined in suffix.hpp?
by Markus Schöpflin 20 Jul '05

20 Jul '05

The first few lines of suffix.hpp currently look like this: #include <limits.h> # if !defined(BOOST_HAS_LONG_LONG) \ && !defined(BOOST_MSVC) && !defined(__BORLANDC__) \ && (defined(ULLONG_MAX) || defined(ULONG_LONG_MAX) || defined(ULONGLONG_MAX)) # define BOOST_HAS_LONG_LONG #endif What is the reason for this code being there? Isn't it enough to test for this in the platform/compiler/stdlib config? I'm asking this question because currently stdlib/libstdcpp3.hpp explicitely turns off BOOST_HAS_LONG_LONG when the library indicates that there is no support for long long, and this is foiled by the code in suffix.hpp, which turns on BOOST_HAS_LONG_LONG again. (And this causes errors with gcc-3.3.x on Tru64.) Maybe we need two config macros for this? One for BOOST_COMPILER_HAS_LONG_LONG, and one for BOOST_STDLIB_HAS_LONG_LONG? Comments or thoughts, anyone? Markus

4 7

Re: [boost] multi_array 64-bit patch
by Thomas Klimpel 19 Jul '05

19 Jul '05

Ronald Garcia wrote: > I made the changes you show below thanks > with the exception of the switch to ptrdiff_t for the index type. > It's not obvious to me that that is the correct change to make I have to admit that the name "std::ptrdiff_t" sounds strange in the context of "index", but there are some container classes in boost that use std::ptrdiff_t as the argument type for operator[], "boost::scoped_array" and "boost::shared_array" for example. And I think "std::ptrdiff_t" makes perfect sense as the index type for an operator[] that accepts both negative and positive integers. There might be types with more comforting names like typedef boost::intmax_t index; // from "boost/cstdint.hpp" typedef boost::detail::integer_traits<std::size_t>::difference_type index; // from "boost/detail/numeric_traits.hpp" typedef intmax_t index; typedef intptr_t index; but "intmax_t" and "intptr_t" seem to be more part of the "c standard" than of the "c++ standard", and the boost types don't help me with the annoying warnings on 32-bit windows with Visual C++.NET. On 32-bit windows, size_t is defined as "typedef _W64 unsigned int size_t;" where the _W64 just means that I will get warning messages, if I convert this type to a type without _W64. Now ptrdiff_t works for me, because it is defined as "typedef _W64 int ptrdiff_t;". Besides the warnings issue, "boost::detail::multi_array::index" should be a signed integer type, that satisfies the assertion "assert(sizeof(boost::detail::multi_array::index) == sizeof(std::size_t));". While this assertion will probably be satisfied on all current platforms, it is not garantied by the standard, which just reads: "The types are 'ptrdiff_t' which is the signed integer type of the result of substracting two pointers; 'size_t' which is the unsigned integer type of the result of the sizeof operator;". Thanks, Thomas

1 0

extra semicolons
by Arkadiy Vertleyb 19 Jul '05

19 Jul '05

Hi all, Not having extra semicolons is one of the strongest arguments against incuding a trailing semicolon into a statement-generating macro. Can anybody explain why having an extra semicolon is considered a potential problem by some compilers? Isn't null as good as any other number? Shouldn't an empty statement be considered as good as any other statement? Regards, Arkadiy

6 15

Generic Factory Library
by Dean Michael Berris 19 Jul '05

19 Jul '05

Good Day, For the past few years, I have been exposed to both C++ software development as well as Java software development. I have been lucky enough to get to use many different frameworks from both languages (ACE in C++ and countless othes in Java). Introductions aside, I would like to ask whether a generic object factory implementation would be best put in a framework or a library. What I am looking for is something to the effect of the Spring [1] framework but in C++. With the issues like late/dynamic binding having many different implementations in many different platforms, the best I could conceptualize is a static template for different object types. What I'm looking for is something that will be able to allow me to forget about reimplementing the static factory every time I need it, and use a generic template instead. Something that will allow me the following functionalities: <code> // return a reference to a _huge_ statically allocated object, // too impractical to always instantiate whenever an instance of it // is needed: static_factory<Object> ObjectFactory; ... Object & object1 = ObjectFactory.getObject(); ... // later perhaps Object & object2 = ObjectFactory.getObject(); ... // later still Object & object3 = ObjectFactory.getObject(); </code> For other cases when I want a different instance returned every time I need a reference to something new, there's a dynamic_factory -- returning a pointer or reference to an object: <code> dynamic_factory<Object> ObjectFactory; Object instance1 = ObjectFactory.getObject(); std::auto_ptr<Object> instance2 (ObjectFactory.getObject()); </code> -- Of course, it is assumed that `Object' has a default constructor in both dynamic_factory and static_factory. Do you know of anything similar to these already? Otherwise, I would be most glad to put up a sample implementation soon. TIA PS. Perhaps XML definition files may be used to provide object registration when the factory is used dynamically to load object definitions from dynamic libraries. -- Dean Michael C. Berris <mikhailberis(a)free.net.ph> GPG Key: 0x08AE6EAC http://mikhailberis.blogspot.com Mobile: +63 921 7841815

3 4

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 19 Jul '05

19 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola > Sent: Saturday, July 16, 2005 12:48 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state <clip -- discussion on why ?: is clearer than "adaptor"> > You said that > > "the door has been flung open to many templated constructs > that are more difficlt with the ?: operator. For example, a > boost::transform_iterator could be created with the adaptor > to automatically access the underlying objects in a sequence." > > I disagree.. can you post a concrete example with a construct > that is indeed more difficult with operator ?: (... and be > fair; i.e. code the operator version the right way...) > > > IMO you still need to show that the adpator is indeed a good > thing; if you do that we can start discussing a proper design > and implementation for it. > Okay, I'll try. How about finding the max_element (or min_element) of a series of optional integers? Using the ?: operator, we might do this in two steps, the first to filter out non-existent values, the second to apply the max_element algorithm. Another way would be to write a custom predicate function that knows how to compare "full" and "empty" Boost::Optional objects or that duplicates the functionality of adaptor. However, by using an adaptor in conjunction with boost::transform_iterator, the job can be accomplished in one loop without the difficulty of writing a custom predicate. Here is some example code (BTW, others seem to prefer the spelling "adaptor," which is more consistent with other standardized names like "iterator," so I'll conform to that): // -- begin typedef boost::optional<int> opt_int; typedef std::vector<opt_int> Vec; typedef Vec::const_iterator cIter; Vec v; int max; v.push_back(0); v.push_back(1); v.push_back(2); v.push_back(boost::none); v.push_back(3); v.push_back(4); v.push_back(boost::none); v.push_back(5); // METHOD #1a: copy to a new vector std::vector<int> tmp; for( cIter p = v.begin(); p != v.end(); ++p ) { if( *p ) tmp.push_back( p->get() ); } max = *std::max_element( tmp.begin(), tmp.end() ); // METHOD #1b: copy using ?: to provide a signal value for undefined elements (similar to adaptor) tmp.clear(); for( cIter p = v.begin(); p != v.end(); ++p ) { tmp.push_back( *p ? p->get() : -1 ); } max = *std::max_element( tmp.begin(), tmp.end() ); // METHOD #2a: define a custom predicate template< class T, class Pred, T Def = T() > class optPred : public std::binary_function<boost::optional<T>, boost::optional<T>, bool> { Pred f; T _eval( const boost::optional<T>& x ) const { return ( x ? x.get() : Def ); } public: optPred() : f( Pred() ) {} bool operator()( const first_argument_type& a, const second_argument_type& b ) const { return f( _eval(a), _eval(b) ); } }; opt_int opt_max; opt_max= *std::max_element( v.begin(), v.end(), optPred< int, std::less<int>, -1 >() ); // METHOD #2b: use an adaptor-like predicate template< class T > class adaptor_substitute : public std::unary_function< boost::optional<T>, T > { T Def; public: _adaptor_() : Def( T() ) {} _adaptor_(T def) : Def( def ) {} T operator()(const argument_type& x ) { return ( x ? x.get() : Def ); } }; max = *std::max_element( boost::make_transform_iterator( v.begin, adaptor_substitute<int>(-1) ), boost::make_transform_iterator( v.end, adaptor_substitute<int>(-1) ) ); // METHOD #3: use an adaptor max = *std::max_element( boost::make_transform_iterator( v.begin, boost::optional<int>::adaptor(-1) ), // NOTE: boost::optional<int>::adaptor does not currently exist boost::make_transform_iterator( v.end, boost::optional<int>::adaptor(-1) ) ); // -- end It seems to me the adaptor, at the very least, saves us the trouble of defining a custom predicate. The similar exercise for min_element can be done by choosing a different signal value, such as 0x7FFFFFFF (the point at "infinity"). I hope this clears up my comment about using adaptor with boost::transform_iterator, but let me know if I haven't convinced you. -Andy

2 1

[iostreams][tru64] can't pass static mem fn to API expecting extern "C"
by Jonathan Turkanis 19 Jul '05

19 Jul '05

Hi, Compaq C++ for Tru64 seems to have found a problem with the iostreams library that none of the other compilers caught. zlib and libbz2 allow the programmer to customize memory management by specifying a pair of function pointers for allocation and deallocation. I wanted to provide an adaption layer so that users could specify standard library compatible allocators instead. To do this, I defined a class template parameterized by an allocator and having two static member functions with the same signature as the allocation and deallocation functions, and then passed pointers to these static member functions to the zlib and libbz2 API. Unfortunately, when compiled as C++, the zlib and libbz2 headers declare the allocation and deallocation function pointer types as extern "C", and Compaq (correctly, I think) refuses to let me assign pointers to static member functions to variables whose type are declared extern "C". Is there some way to get around this? If not, what should I do? 1. expose the C-language customization interface (yuck) 2. remove the customization interface 3. remove the customization interface only for platforms where it doesn't work 4. Use some more elaborate trick, such as supplying extern "C" allocation functions which operate by delegating to pointers stored in a table. I like 2. Jonathan

4 4

[mpl] integral_c bool partial specialization
by Matt Calabrese 19 Jul '05

19 Jul '05

The bool partial specialization of ::boost::mpl::integral_c currently does not appear to contain a value_type type member meaning it does not fully conform to the Integral Constant pure abstraction specified in documentation.

2 1

[tokenizer] Type requirements
by Nikolay Mladenov 18 Jul '05

18 Jul '05

Hi All, What are the requirements on the Type template parameter of boost::tokenizer. I could not find this in the documentation. I want to pass type similar to std::pair < std::string::const_iterator, std::string::const_iterator > . But it seems that the type should have operator += and/(or?) assign member. Is that correct? Is there any other customization mechanism here? Thanks Nikolay

1 0

multi_array 64-bit patch
by Thomas Klimpel 18 Jul '05

18 Jul '05

Hello, The Boost Multi_Array library produces some 64-bit related warnings when used with Visual C++.NET. It seems to me that these warnings are valid and correspond to real 64-bit problems. To get rid of these annoying warnings, I have fixed two minor inconsistencies in multi_array/iterator.hpp and multi_array/multi_array_ref.hpp, but that was not enough. I also had to change the definition of boost::detail::multi_array::index in multi_array/types.hpp from "typedef int index;" to "typedef std::ptrdiff_t index;". There might be better solutions, but it was the best I could think of, because std::ptrdiff_t is a signed type and will adapt to a 64-bit environment. Index: multi_array/iterator.hpp =================================================================== --- multi_array/iterator.hpp (Revision 1040) +++ multi_array/iterator.hpp (Arbeitskopie) @@ -98,7 +98,7 @@ array_iterator() {} - array_iterator(int idx, TPtr base, const size_type* extents, + array_iterator(index idx, TPtr base, const size_type* extents, const index* strides, const index* index_base) : idx_(idx), base_(base), extents_(extents), Index: multi_array/types.hpp =================================================================== --- multi_array/types.hpp (Revision 1040) +++ multi_array/types.hpp (Arbeitskopie) @@ -26,7 +26,7 @@ // needed typedefs typedef std::size_t size_type; -typedef int index; +typedef std::ptrdiff_t index; } // namespace multi_array } // namespace detail Index: multi_array/multi_array_ref.hpp =================================================================== --- multi_array/multi_array_ref.hpp (Revision 1040) +++ multi_array/multi_array_ref.hpp (Arbeitskopie) @@ -389,7 +389,7 @@ // Calculate the array size num_elements_ = std::accumulate(extent_list_.begin(),extent_list_.end(), - 1,std::multiplies<index>()); + size_type(1),std::multiplies<size_type>()); #if 0 assert(num_elements_ != 0); #endif

2 1

[Preprocessor] Workaround for CW8.3
by David Abrahams 18 Jul '05

18 Jul '05

BOOST_PP_SEQ_ENUM is failing for me when invoked from another macro; When the argument is (A0) I get BOOST_PP_SEQ_ENUM_2 and when the argument is (A0)(A1) I get BOOST_PP_SEQ_ENUM_4 I think what happens is that CW "sees through" the outer set of parens in # define BOOST_PP_SEQ_ENUM(seq) BOOST_PP_CAT(BOOST_PP_SEQ_ENUM_, BOOST_PP_SEQ_SIZE(seq)) seq and pastes seq to itself, yielding a length of 4 instead of 2. Here's a workaround: # define BOOST_PP_SEQ_ENUM_I(size,seq) BOOST_PP_CAT(BOOST_PP_SEQ_ENUM_, size) seq # define BOOST_PP_SEQ_ENUM(seq) BOOST_PARAMETER_SEQ_ENUM_I(BOOST_PP_SEQ_SIZE(seq), seq) I hope this is useful. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[1.33.0] Inspection report
by Douglas Gregor 18 Jul '05

18 Jul '05

The inspection report shows that we have a bunch of little fixes to make before we release. Please check it out and fix whatever you can: http://www.boost.org/regression-logs/inspection_report.html Doug

8 14

some ptr_container issues
by Ross Boylan 18 Jul '05

18 Jul '05

I'm using the cvs version (as of a couple of days ago) of the ptr_container library with a regular 1.32 boost. Should transfer operations between dissimilar containers (e.g., ptr_vector and ptr_list, assuming both have the same underlying type) work? They don't seem to. I can't quite tell from the docs (which define these abstractly, e.g., for ptr_sequence) whether this should work or not. Previous versions of the docs made it explicit that the operations were templated on the type of the second container. Second, the definition of transfer does not say where the elements are to be inserted (i.e., whether they go before the "before" iterator, or whether the "before" iterator will end up before the inserted elements). While it's not hard to guess right with some knowledge of how the standard works (and even how other ptr_container functions work), it would be nice to be explicit. Third, I didn't see any explicit discussion of circumstances that invalidate iterators. Again, it's pretty easy to guess this is the same as the corresponding standard classes, but it's probably worth saying so. Finally, the discussion of exception classes does not describe the circumstances under which the exceptions are thrown. Some functions do discuss their exceptions, but I'm not sure if they all do. I was surprised that at throws bad_ptr_container_operation; I would have expected bad_index (this behavior *is* documented--I'm just saying it seems odd). Thanks for your work on these utilities. -- Ross Boylan wk: (415) 502-4031 530 Parnassus Avenue (Library) rm 115-4 ross(a)biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062

2 3

Re: [boost] Macros at namespace scope: trailing semicolon?
by Dave Gomboc 18 Jul '05

18 Jul '05

You were asking another, but... > 1) Do you think that the LOG() macro should contain a trailing > semicolon? The macro itself should, yes, so the user need not type one. > 2) I'm pretty sure you'll say #1, but which of the following examples > do you prefer? > > int foo() > { > LOG("NO SEMICOLON HERE?") // 1 > stuff(); > > LOG("OR does this seem better?"); // 2 > more_stuff(); > } #1. If someone did #2, yielding an extra, empty statement, it's not a tragedy, however (unless my compiler warned about such empty statements -- in which case I would delete the extraneous semicolon.) There's undoubtedly some compiler that boost supports that will do this, so best not to have the extra one there in the first place, I think. > 3) Do you see harm if the macro does not contain the trailing > semicolon? If so, what harm is it? Specifically, how does usage > #2 above re-enforce bad understanding of macros? (Or am I > misconstruing the nature of your objection?) It's logically inconsistent for the macro to not to perform its entire job. If that job is to "expand into an expression", certainly, it shouldn't generate a semicolon. If that job is to "expand into a statement", then just as certainly, it should. But its job ought not to be to "expand into a statement except for the trailing semicolon": that would be absurd. > 4) What is the important degree of indirection that I would be missing > by talking about the usage of the LOG macro as a call to the log > function? I understand that I could call it "a macro that expands > to a call to the log function" but I don't think that anyone would > be more enlightened by that. Other than being more detailed about > what's really happening, it's not clear to me what important > mistake is being made that bothers you. If our coding convention > states that macros are uppercase, then we already know it's a > macro, so simply repeating that is unnecessary, IMHO. Referring to it as the log function is clearly wrong. The listener might doubt your understanding, even if you knew perfectly well that it was indeed a macro that expanded to a function call. I see no disadvantage in referring to it as the LOG macro. Dave

1 0

Boost regression notification (2005-07-18)
by Douglas Gregor 18 Jul '05

18 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-18T15:30:25Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 229 failures in 12 libraries: filesystem (2) io (1) multi_index (1) parameter (7) program_options (5) python (53) random (2) serialization (139) spirit (1) test (6) thread (2) wave (10) |filesystem| operations_test_dll: borland-5_6_4 path_test_dll: borland-5_6_4 |io| ios_state_unit_test: intel-win32-8_1 |multi_index| test_special_set_ops: vc-8_0 |parameter| basics: gcc-3_4_3-sunos vc-8_0 macros: gcc-3_4_3-sunos vc-8_0 sfinae: cw-8_3 gcc-3_4_3-sunos vc-8_0 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |python| andreas_beyer: intel-win32-8_1 args: intel-win32-8_1 auto_ptr: intel-win32-8_1 back_reference: intel-win32-8_1 ben_scott1: intel-win32-8_1 bienstman1: intel-win32-8_1 bienstman2: intel-win32-8_1 bienstman3: intel-win32-8_1 builtin_converters: intel-win32-8_1 callbacks: intel-win32-8_1 const_argument: intel-win32-8_1 crossmod_exception: intel-win32-8_1 data_members: intel-win32-8_1 defaults: intel-win32-8_1 dict: intel-win32-8_1 docstring: intel-win32-8_1 enum: intel-win32-8_1 exception_translator: intel-win32-8_1 extract: intel-win32-8_1 implicit: intel-win32-8_1 injected: intel-win32-8_1 iterator: intel-win32-8_1 keywords: intel-win32-8_1 list: intel-win32-8_1 long: intel-win32-8_1 map_indexing_suite: intel-win32-8_1 minimal: intel-win32-8_1 multi_arg_constructor: intel-win32-8_1 nested: intel-win32-8_1 numpy: intel-win32-8_1 object: intel-win32-8_1 opaque: intel-win32-8_1 operators: intel-win32-8_1 pearu1: intel-win32-8_1 pickle1: intel-win32-8_1 pickle2: intel-win32-8_1 pickle3: intel-win32-8_1 pickle4: intel-win32-8_1 pointer_vector: intel-win32-8_1 polymorphism: intel-win32-8_1 polymorphism2: intel-win32-8_1 properties: intel-win32-8_1 raw_ctor: intel-win32-8_1 return_arg: intel-win32-8_1 shared_ptr: intel-win32-8_1 slice: intel-win32-8_1 staticmethod: intel-win32-8_1 str: intel-win32-8_1 test_pointer_adoption: intel-win32-8_1 try: intel-win32-8_1 tuple: intel-win32-8_1 vector_indexing_suite: intel-win32-8_1 virtual_functions: intel-win32-8_1 |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 vc-7_1 vc-7_1 vc-8_0 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: vc-6_5 vc-6_5-stlport vc-7_0 test_demo: intel-win32-8_1 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception: intel-win32-8_1 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: vc-6_5 test_demo_pimpl_dll: vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 vc-7_1 vc-7_1 vc-7_1 vc-7_1 vc-8_0 vc-8_0 vc-8_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin intel-win32-8_1 test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 vc-7_0 test_demo_xml_load: intel-win32-8_1 test_demo_xml_save: intel-win32-8_1 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: vc-6_5 vc-7_0 test_map_text_archive_dll: vc-6_5 vc-7_0 test_map_text_warchive_dll: vc-6_5 vc-7_0 test_mi_xml_archive_dll: vc-8_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_registered_xml_archive: vc-8_0 |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |thread| test_mutex: vc-7_1 test_thread: vc-6_5 |wave| test_re2c_lexer: vc-8_0 vc-8_0 test_slex_lexer: vc-8_0 vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0 vc-8_0

1 0

[inspect] Boost Inspection Report *Run Date:* 14:43:58 UTC, Monday 18 July 2005
by Rene Rivera 18 Jul '05

18 Jul '05

-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org Boost Inspection Report *Run Date:* 14:43:58 UTC, Monday 18 July 2005 An inspection program <http://www.boost.org/tools/inspect/index.html> checks each file in the current Boost CVS for various problems, generating this web page as output. Problems detected include tabs in files, missing copyrights, broken URL's, and similar misdemeanors. Totals 10429 files scanned 821 directories scanned 180 problems reported problem counts: 4 files with invalid line endings 0 bookmarks with invalid characters 0 invalid urls 104 broken links 38 unlinked files 23 file names too long 4 files with tabs 7 violations of the Boost min/max guidelines Summary *Library* *Problems* algorithm <#algorithm> 1 boost-root <#boost-root> 3 build <#build> 6 date_time <#date_time> 5 iostreams <#iostreams> 86 iterator <#iterator> 7 libs <#libs> 3 mpl <#mpl> 2 numeric <#numeric> 3 program_options <#program_options> 1 python <#python> 11 quickbook <#quickbook> 8 regex <#regex> 1 regression <#regression> 32 serialization <#serialization> 2 test <#test> 7 type_traits <#type_traits> 2 Details algorithm libs/algorithm/string/doc/external_concepts.html: unlinked file boost-root index.htm: broken link: doc/html/date_time/date_time_io.html, broken link: doc/html/date_time/details.html#date_time.changes, broken link: doc/html/date_time/local_time.html build tools/build/v2/example/libraries/util/foo/include/lib1.h: file's directory depth will exceed 8 levels if placed on a CD tools/build/v2/index.html: broken link: ../../../doc/html/bbv2.html, broken link: ../../../doc/html/bbv2/installation.html, broken link: doc/userman.pdf tools/build/v2/test/test_system.html: unlinked file date_time boost/date_time/date_parsing.hpp: violation of Boost min/max guidelines on line 80, violation of Boost min/max guidelines on line 81 boost/date_time/period.hpp: violation of Boost min/max guidelines on line 339, violation of Boost min/max guidelines on line 340 libs/date_time/xmldoc/date_time_docs_howto.html: unlinked file iostreams libs/iostreams/doc/acknowledgments.html: unlinked file libs/iostreams/doc/faq.html: unlinked file libs/iostreams/doc/functions/reverse.html: broken link: ../../../../boost/iostreams/reverse.hpp, unlinked file libs/iostreams/doc/guide/adapters.html: broken link: ../../../../boost/iostreams/adapt.hpp, broken link: ../../../../boost/iostreams/device/container_device.hpp, broken link: ../functions/adapt.html libs/iostreams/doc/guide/code_conversion.html: broken link: ../../../../boost/iostreams/converting_stream.hpp, broken link: ../../../../boost/iostreams/converting_streambuf.hpp, broken link: ../classes/converting_stream.html, broken link: ../classes/converting_streambuf.html libs/iostreams/doc/guide/compression.html: broken link: ../../src/bzip2, broken link: ../../src/zlib libs/iostreams/doc/guide/concepts.html: broken link: ../../../boost/iostreams/concepts.hpp, broken link: classes/device.html, broken link: classes/device.html#sink, broken link: classes/device.html#source, broken link: classes/device.html#synopsis, broken link: classes/filter.html, broken link: classes/filter.html#multichar_filter, broken link: classes/filter.html#synopsis, broken link: concepts/bidirectional_device.html, broken link: concepts/bidirectional_filter.html, broken link: concepts/closable.html, broken link: concepts/device.html, broken link: concepts/direct.html, broken link: concepts/filter.html, broken link: concepts/input_filter.html, broken link: concepts/localizable.html, broken link: concepts/multi_character.html, broken link: concepts/output_filter.html, broken link: concepts/peekable.html, broken link: concepts/seekable_device.html, broken link: concepts/seekable_filter.html, broken link: concepts/sink.html, broken link: concepts/source.html libs/iostreams/doc/guide/filtering_streams.html: broken link: graphics/bidirectional_chain.gif, broken link: graphics/input_chain.gif, broken link: graphics/output_chain.gif, broken link: graphics/seekable_chain.gif libs/iostreams/doc/guide/generic_streams.html: broken link: ../modes.html libs/iostreams/doc/guide/guide.html: unlinked file libs/iostreams/doc/guide/modes.html: broken link: ../compression.html, broken link: graphics/important_modes.gif, broken link: graphics/key_bidirectional_seq.gif, broken link: graphics/key_important.gif, broken link: graphics/key_input_seq.gif, broken link: graphics/key_output_seq.gif, broken link: graphics/key_read_head.gif, broken link: graphics/key_read_write_head.gif, broken link: graphics/key_write_head.gif, broken link: graphics/modes.gif libs/iostreams/doc/quick_reference.html: broken link: ../bibliography.html#deutsch3, broken link: ../guide/code_conversion.html, broken link: concepts/filters.html, broken link: concepts/sinks.html, broken link: source.html, invalid (cr only) line-ending, unlinked file libs/iostreams/doc/rationale.html: broken link: functions/adapt.html, unlinked file libs/iostreams/doc/reference.html: unlinked file libs/iostreams/doc/tutorial/container_sink.html: broken link: ../non_blocking.html libs/iostreams/doc/tutorial/container_source.html: broken link: ../non_blocking.html libs/iostreams/doc/tutorial/writing_filters.html: broken link: ../classes/symmetric.hpp libs/iostreams/test/putback_test.hpp: invalid (cr only) line-ending iterator libs/iterator/doc/filter_iterator_ref.html: unlinked file libs/iterator/doc/indirect_iterator_ref.html: unlinked file libs/iterator/doc/issues.html: unlinked file libs/iterator/doc/iter-issue-list.html: unlinked file libs/iterator/doc/iterator_adaptor_ref.html: unlinked file libs/iterator/doc/make_filter_iterator.html: unlinked file libs/iterator/doc/ref_problem.html: unlinked file libs libs/libraries.htm: broken link: ../doc/boost.docbook, broken link: ../doc/boost.fo, invalid (cr only) line-ending mpl libs/mpl/doc/src/refmanual/Data.Integral.rst: filename contains more than one dot character ('.') libs/mpl/doc/src/refmanual/ExtensibleAssociativeSequence.rst: filename > 31 chars numeric boost/numeric/conversion/detail/old_numeric_cast.hpp: violation of Boost min/max guidelines on line 159, violation of Boost min/max guidelines on line 192 libs/numeric/conversion/doc/converter_policies.html: invalid (cr only) line-ending program_options boost/program_options/positional_options.hpp: violation of Boost min/max guidelines on line 43 python boost/python/object/pointer_holder.hpp: tabs in file libs/python/doc/new-conversions.html: unlinked file libs/python/doc/tutorial/doc/html/python/embedding.html: broken link: ../object.html libs/python/doc/v2/bibliography.html: unlinked file libs/python/doc/v2/errors.html: broken link: ../../../../doc/html/functionN.html libs/python/doc/v2/from_python.html: unlinked file libs/python/doc/v2/header.html: unlinked file libs/python/doc/v2/overview.html: unlinked file libs/python/doc/v2/rationale.html: unlinked file libs/python/pyste/tests/inherit3.h: tabs in file libs/python/test/docstring.py: tabs in file quickbook tools/quickbook/detail/quickbook.cpp: tabs in file tools/quickbook/doc/html/index.html: broken link: libraries.html tools/quickbook/doc/html/quickbook/docinfo.html: broken link: ../libraries.html tools/quickbook/doc/html/quickbook/highlight.html: broken link: ../libraries.html tools/quickbook/doc/html/quickbook/pyhighlight.html: broken link: ../libraries.html tools/quickbook/doc/html/quickbook/quickbook.html: broken link: ../libraries.html tools/quickbook/doc/html/quickbook/ref.html: broken link: ../libraries.html tools/quickbook/doc/html/quickbook/syntax.html: broken link: ../libraries.html regex libs/regex/performance/input.html: unlinked file regression tools/regression/test/compile-fail~fail.cpp: nonportable path tools/regression/test/compile-fail~pass.cpp: nonportable path tools/regression/test/compile~fail.cpp: nonportable path tools/regression/test/compile~pass.cpp: nonportable path tools/regression/test/compile~warn.cpp: nonportable path tools/regression/test/run-fail~compile-fail.cpp: nonportable path tools/regression/test/run-fail~fail-warn.cpp: nonportable path tools/regression/test/run-fail~fail.cpp: nonportable path tools/regression/test/run-fail~pass.cpp: nonportable path tools/regression/test/run-fail~warn.cpp: nonportable path tools/regression/test/run~compile-fail.cpp: nonportable path tools/regression/test/run~fail-note.cpp: nonportable path tools/regression/test/run~fail-warn.cpp: nonportable path tools/regression/test/run~fail.cpp: nonportable path tools/regression/test/run~note.cpp: nonportable path tools/regression/test/run~pass.cpp: nonportable path tools/regression/test/run~warn-note.cpp: nonportable path tools/regression/test/run~warn.cpp: nonportable path tools/regression/xsl_reports/runner/instructions.html: unlinked file tools/regression/xsl_reports/xsl/html/issues_legend.html: unlinked file tools/regression/xsl_reports/xsl/html/library_developer_legend.html: unlinked file tools/regression/xsl_reports/xsl/html/library_user_legend.html: unlinked file tools/regression/xsl_reports/xsl/html/make_tinyurl.html: unlinked file tools/regression/xsl_reports/xsl/html/summary_developer_legend.html: unlinked file tools/regression/xsl_reports/xsl/html/summary_user_legend.html: unlinked file tools/regression/xsl_reports/xsl/v2/expected_results_2_new_format.xsl: filename > 31 chars tools/regression/xsl_reports/xsl/v2/html/issues_legend.html: unlinked file tools/regression/xsl_reports/xsl/v2/html/library_developer_legend.html: unlinked file tools/regression/xsl_reports/xsl/v2/html/library_user_legend.html: unlinked file tools/regression/xsl_reports/xsl/v2/html/make_tinyurl.html: unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_developer_legend.html: unlinked file tools/regression/xsl_reports/xsl/v2/html/summary_user_legend.html: unlinked file serialization libs/serialization/doc/serialization.html: broken link: ../../../boost/serialization/shared_count.hpp libs/serialization/vc7ide/test_reset_object_address.vcproj: filename > 31 chars test libs/test/doc/components/test_exec_monitor/compilation.html: broken link: ../../../src/supplied_log_formatters.cpp, broken link: ../../../src/unit_test_result.cpp libs/test/doc/components/utf/compilation.html: broken link: ../../../src/supplied_log_formatters.cpp, broken link: ../../../src/unit_test_result.cpp libs/test/doc/components/utf/components/test_case/boost_function_tc.html: broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp libs/test/doc/components/utf/components/test_case/param_boost_function_tc.html: broken link: ../../../../../../../boost/test/unit_test_suite_ex.hpp libs/test/doc/tests/unit_test_suite_ex_test.html: broken link: ../../test/unit_test_suite_ex_test.cpp type_traits libs/type_traits/cxx_type_traits.htm: broken link: ../../doc/html/boost_typetraits/background.html, unlinked file

1 0

Defining compilers suggestion
by Edward Diener 18 Jul '05

18 Jul '05

It would be much easier, and less confusing, when looking at compiler workarounds in Boost code if their were defines for various compilers/versions in a configuratiion header file such as: #define BOOST_COMPILER_SOME_COMPILER_LOWER (PREPROCESSOR_TAG >= nnnn) #define BOOST_COMPILER_SOME_COMPILER_UPPER (PREPROCESSOR_TAG <= nnnn) #define BOOST_COMPILER_SOME_COMPILER (BOOST_COMPILER_SOME_COMPILER_LOWER && BOOST_COMPILER_SOME_COMPILER_UPPER) where SOME_COMPILER might be VC71,GCC40 etc. Then in code one could see: #if defined(BOOST_COMPILER_VC71) etc. rather than the less understandable #if defined(MSC_VER == nnnn) etc. I would just like to see more readability in the Boost code regarding compiler workarounds. I am also aware their is a workaround macro, but even that deals in compiler preprocessor tags rather than a more readable compiler version. I am aware that many workarounds have to deal with versions before or after a certain version number but even that can be made more readable by macros which tell one the actual compiler which is involved. I realize I am just a reader of Boost code and not a Boost developer but I think this suggestion would make for a little more readable code in its own small way.

11 61

[serialization][date_time] unresolved symbol 'special_value_from_string'
by Jonathan Turkanis 18 Jul '05

18 Jul '05

Hi, I'm trying to deserialize objects from an xml archive containing some gregorian dates. Using VC7.1 I get the linker error: serialization.obj : error LNK2019: unresolved external symbol "enum boost::date_time::special_values __cdecl boost::gregorian::special_value_from_string(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (?special_value_from_string@gregorian@boost@@YA?AW4special_values@date_time@2@AB V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) referenced in function __catch$??$load@Vxml_wiarchive@archive@boost@@@serialization@boost@@YAXAAVxml_wi archive@archive@1@AAVdate@gregorian@1@I@Z$0 Any ideas what's causing this? Jonathan

1 0

[filesystem] operations failues on gcc-3_4_4-cygwin
by Beman Dawes 18 Jul '05

18 Jul '05

I inadvertently upgraded my cygwin installation this morning to what __VERSION__ reports as "3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)". The good news is that two freshly added dll tests which had been failing under gcc/cygwin 3.3.3 pass under 3.4.4. The bad news is that even though operations_test_dll is passing, statically linked operations_test fails. The reason for the static link failures is that the Windows function ::GetLastError() is returning 0 after several critical functions return error indications. I'm guessing from the "cygming" name that mingw is being used, and is the cause of the problem. Why the same problem doesn't appear when dynamically linking is unclear to me. My initial reaction is just to note the problem in the docs and move on. It seems to close to release to try workarounds, which would have to be very carefully done. Any other ideas? --Beman

1 0

[Boost-bugs] [ boost-Bugs-1239906 ] no Boolean conversion for boost::rational
by SourceForge.net 17 Jul '05

17 Jul '05

Bugs item #1239906, was opened at 2005-07-17 16:15 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=1239906&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: Daryle L. Walker (dlwalker) Assigned to: Nobody/Anonymous (nobody) Summary: no Boolean conversion for boost::rational Initial Comment: The boost::rational class template, in header file <boost/ rational.hpp>, does not support conversion to a Boolean value. It does have an "operator !" defined, though. It is a surprise for a type to have one of these operations but not the other. Currently code like "if ( !r )" works but not "if ( r )", which should be expected. A solution is to add a conversion operator to a type that can be used in Boolean contexts, but as little else as possible. A suggestion is to use a pointer-to-member (to data or function) type that is unique to each version of boost::rational, where the exact values are private. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1239906&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] VC 7.1/8.0 regression testing, call for volunteers
by David Abrahams 17 Jul '05

17 Jul '05

"Carl Daniel" <cpdaniel(a)mvps.org> writes: > David Abrahams wrote: >> "Carl Daniel" <cpdaniel(a)mvps.org> writes: >>> Does anyone have a set of instructions for building and running the >>> regression tests WITHOUT using Python? Right now, that's the >>> sticking point - Python's not installed, and I'm unable to install >>> it. If I could put together a ZIP file with all the command line >>> tools pre-built and a simple BATch file to run them, that'd be a >>> workable solution. >> >> Somehow if they're letting us upload, build, and run our code it seems >> like it should be possible to upload, build, and run Python, no? > > True that - I could upload the sources and just build it in place. It's trivial; I would just go ahead and do it. The build system is set up to work with a development installation of Python. > Hopefully someone on the VC++ team can just install ActivePython on > the machine for me. If I build Python locally, is there a > straightforward way to identify all the files I'd need to push to > the machine to have it work there? Not that I know of. Why not just do the build remotely? > I'm assuming there'd be more to it than just python.exe. Yeah, all of the standard library, for example. And python.dll. Not sure what else right now. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Boost regression notification (2005-07-17)
by Douglas Gregor 17 Jul '05

17 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-17T14:58:38Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io utility Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 245 failures in 13 libraries: io (1) multi_index (1) parameter (23) program_options (5) python (53) random (2) serialization (140) spirit (1) test (6) thread (1) type_traits (1) utility (1) wave (10) |io| ios_state_unit_test: intel-win32-8_1 |multi_index| test_special_set_ops: vc-8_0 |parameter| basics: borland-5_6_4 cw-8_3 gcc-3_4_3-sunos vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 macros: borland-5_6_4 cw-8_3 gcc-3_4_3-sunos vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 sfinae: borland-5_6_4 cw-8_3 cw-9_4 gcc-3_4_3-sunos intel-win32-8_1 vc-6_5 vc-6_5-stlport vc-7_0 vc-8_0 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |python| andreas_beyer: intel-win32-8_1 args: intel-win32-8_1 auto_ptr: intel-win32-8_1 back_reference: intel-win32-8_1 ben_scott1: intel-win32-8_1 bienstman1: intel-win32-8_1 bienstman2: intel-win32-8_1 bienstman3: intel-win32-8_1 builtin_converters: intel-win32-8_1 callbacks: intel-win32-8_1 const_argument: intel-win32-8_1 crossmod_exception: intel-win32-8_1 data_members: intel-win32-8_1 defaults: intel-win32-8_1 dict: intel-win32-8_1 docstring: intel-win32-8_1 enum: intel-win32-8_1 exception_translator: intel-win32-8_1 extract: intel-win32-8_1 implicit: intel-win32-8_1 injected: intel-win32-8_1 iterator: intel-win32-8_1 keywords: intel-win32-8_1 list: intel-win32-8_1 long: intel-win32-8_1 map_indexing_suite: intel-win32-8_1 minimal: intel-win32-8_1 multi_arg_constructor: intel-win32-8_1 nested: intel-win32-8_1 numpy: intel-win32-8_1 object: intel-win32-8_1 opaque: intel-win32-8_1 operators: intel-win32-8_1 pearu1: intel-win32-8_1 pickle1: intel-win32-8_1 pickle2: intel-win32-8_1 pickle3: intel-win32-8_1 pickle4: intel-win32-8_1 pointer_vector: intel-win32-8_1 polymorphism: intel-win32-8_1 polymorphism2: intel-win32-8_1 properties: intel-win32-8_1 raw_ctor: intel-win32-8_1 return_arg: intel-win32-8_1 shared_ptr: intel-win32-8_1 slice: intel-win32-8_1 staticmethod: intel-win32-8_1 str: intel-win32-8_1 test_pointer_adoption: intel-win32-8_1 try: intel-win32-8_1 tuple: intel-win32-8_1 vector_indexing_suite: intel-win32-8_1 virtual_functions: intel-win32-8_1 |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 vc-7_1 vc-7_1 vc-8_0 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: vc-6_5 vc-6_5-stlport vc-7_0 test_demo: intel-win32-8_1 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception: intel-win32-8_1 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: vc-6_5 test_demo_pimpl_dll: vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 vc-7_1 vc-7_1 vc-7_1 vc-7_1 vc-8_0 vc-8_0 vc-8_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin intel-win32-8_1 test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 vc-7_0 test_demo_xml_load: intel-win32-8_1 test_demo_xml_save: intel-win32-8_1 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_list_xml_archive: vc-8_0 test_map_binary_archive_dll: vc-6_5 vc-7_0 test_map_text_archive_dll: vc-6_5 vc-7_0 test_map_text_warchive_dll: vc-6_5 vc-7_0 test_mi_xml_archive_dll: vc-8_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_registered_xml_archive: vc-8_0 |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |thread| test_mutex: vc-7_1 |type_traits| add_const_test: vc-8_0 |utility| compressed_pair_test: intel-win32-8_1 |wave| test_re2c_lexer: vc-8_0 vc-8_0 test_slex_lexer: vc-8_0 vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0 vc-8_0

1 0

[date_time] day_of_week function
by Friedrich Wilckens 17 Jul '05

17 Jul '05

date_time::date::day_of_week() calls two functions from the calendar template parameter: the first to convert the internal integer representation into a ymd_type, and the second to calculate the day_of_week for this ymd_type. Both do some non-trivial arithmetic. I wonder why the following simpler and more efficient approach is not used. In date_time::date: day_of_week_type day_of_week() const { return calendar::day_of_week(days_); } In date_time::gregorian_calendar_base add a method: static unsigned short day_of_week(const date_int_type& d) { return (d + 1) % 7; } As far as I know, the sequence of weeks in the gregorian calendar is completely regular and this simple calculation is correct. This approach would also not limit flexibility of the date template. If for another calendar there is some irregularity, we could for this calendar implement static unsigned short day_of_week(const date_int_type& d) { return day_of_week(from_day_number(d)); } Is there any problem in this reasoning? Sincerely, Friedrich

2 1

The OSL4 sunpro-5_8u1-sunos smart_ptr failures
by Peter Dimov 17 Jul '05

17 Jul '05

... are caused by a missing -features=tmplife option. Without it, temporaries are destroyed at the end of the block. -- Peter Dimov http://www.pdimov.com

2 1

static templates in BOOST
by Steve Clamage 17 Jul '05

17 Jul '05

We recently corrected the way our compiler (Sun C++) handles static templates, and ran into a problem with some BOOST code. More than 100 tests in the suite depend on code like this: template <typename T> struct S { void foo(int); }; template<class T , class U> static // static template ... void smart_cast_reference(U& u) {} template <typename T> void S<T>::foo(int c) { smart_cast_reference< T& >(c); // used in global function } int main() { S<int> s; s.foo(1); } You can't use a static template in a global template function because it violates the One-Definition Rule, among possibly other rules. I have found that other compilers accept this code, but reject it when you put them in standard-conformning mode. (To see the rejection with some compilers, you need to build the executable.) How critical to BOOST is this style of coding? Could the static templates be made global? --- Steve Clamage, stephen.clamage(a)sun.com

9 24

weak_ptr triple states
by Jaap Suter 17 Jul '05

17 Jul '05

Hi, a weak_ptr can be said to have three states. 1. Never been assigned to (default constructed) 2. Assigned to, lock will return a shared_ptr to a valid object. 3. Assigned to, but the object pointed to is dead and lock will return null. As far as I know it is currently impossible to distinguish between case 1 and 3. Am I overlooking something? If not, can somebody explain the reason why it is not possible to distinguish the two cases? Admittedly, I cannot come up with any elegant design in which such a distinction is useful, so the question is merely theoretical. Thanks, Jaap Suter

4 5

Re: [boost] VC 7.1/8.0 regression testing, call for volunteers
by David Abrahams 16 Jul '05

16 Jul '05

"Carl Daniel" <cpdaniel(a)mvps.org> writes: > Aleksey Gurtovoy wrote: >> Carl Daniel writes: >>> I now have access to weekly builds of VC8 (currently testing the >>> 7/11/2005 build!). At the moment, it's not feasible to do boost >>> regression testing on those builds (it's a machine at MSFT), but I >>> could look into getting it set up. >> >> I think you are in a unique position w.r.t. weekly VC 8.0 builds, and >> IMO it would be a great service to both us and the VC8 team to test >> against those in addition to CTP/Beta 2. > > It looks like this might be possible - stay tuned. It'll be mid next week > at best before I can do the first run (assuming things get set up). I won't > be able to do them very often - perhaps only once/week because it won't be > possible to fully automate the process (the machine cannot make outgoing > connections to the internet, so I'll have to push tarballs to it, run the > tests, and then pull the results back. > > Does anyone have a set of instructions for building and running the > regression tests WITHOUT using Python? Right now, that's the sticking > point - Python's not installed, and I'm unable to install it. If I could > put together a ZIP file with all the command line tools pre-built and a > simple BATch file to run them, that'd be a workable solution. Somehow if they're letting us upload, build, and run our code it seems like it should be possible to upload, build, and run Python, no? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 16 Jul '05

16 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart > Sent: Thursday, July 14, 2005 9:53 PM > To: boost(a)lists.boost.org > Cc: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > > From: "Jost, Andrew" <Andrew_Jost(a)mentor.com> > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart > > > From: "Jost, Andrew" <Andrew_Jost(a)mentor.com> > > > > > From: boost-bounces(a)lists.boost.org > > > > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando > > > > > Cacciola > > > > > > > > Here is a real example. Imagine a researcher with many > > > > instruments > > > > > > > > Okay. This works, but what about that ugly call to loadPoint? > > > > The problem is that the library function is expecting a signal > > > value, not > > > > a Boost.Optional! Boost.Optional helped us manage data > > > > collection, but does not help us call trend::loadPoint. Let's > > > > look at > > > > > > The library can just as easily expect a Boost.Optional. > > > > But you're assuming that we have control over the library. That's > > probably the exception rather than the rule in real life. > > If you can change the library to use an adaptor for an > optional, why can't you change the library to use the > optional directly? > But I never gave any indication that we can change the library at all! Not even to use the adapter. The adapter is a function object that returns exactly what the library function expects. > > > > Using adapters, the call to trend::loadPoint in the > first example > > > > might look like this: > > > > > > > > > > > > // -- begin > > > > // call trend::loadPoint > > > > opt_dp::adapter f(-1); > > > > for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { > > > > tr.loadPoint( f(*p) ); > > > > } > > > > // -- end > > > > > > Your version, with Boost.Optional was like this: > > > > > > > for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { > > > > tr.loadPoint( *p ? p->get() : -1 ); > > > > } > > > > > > (I think you could change "p->get()" to "**p" if you like, BTW.) > > > > > > The latter is simpler and seems far more direct and, therefore, > > > readable. I don't see that your adapter has added any value. > > > > I tried to make the examples as syntactically plain as > possile; they > > are optimized for clarity. There is a key advantage in the example > > with adapters because the adapter is a function object. In that > > respect, the door has been flung open to many templated constructs > > that are more difficlt with the ?: operator. For example, a > > boost::transform_iterator could be created with the adapter to > > automatically access the underlying objects in a sequence. > > Hmmm. This reminds me of using the STL algorithms before > having Boost.Lambda, Boost.Bind, etc. Without a library of > predefined function objects that perform useful, reusable > adaptations, or a lambda approach to creating the adapters, > one winds up separating the value extraction logic from the > context in which it is used. > The Boost.Optional::adapter syntax is its own predefined library and, though lambda is a fantastic approach, it won't compile using Microsoft so we can't say it's the new paradigm. > > > I don't really see the value as presented thus far. > There is a tiny > > > amount of syntactic sugar, but is that warranted? > > > > I'm not sure. > > It was your idea, and now you're questioning it? I take from > that the responses you've gotten have caused you to rethink > not just the approach, but the idea? > Not at all. I would distrust anyone who has total faith in the usefulness of a new idea such as this one. The need for another opinion is why forums such as this one even exist. > > > Your requirements are flawed. The adapter should hold an > instance > > > of type T as provided by the constructor. Then, if the > > > Boost.Optional has no value, the adapter can return it's default > > > instance. IOW, the adapter shouldn't impose its needs on the > > > optional type. Boost.Optional would then work fine, > though I still > > > question the value of your adapter. > > > > I would also like to see the adapter avoid "imposing its > needs" on the > > optional object, but conversely, I don't think it would be > right to to > > return whole T objects (instead of references). > > There's no need. As I pointed out, the adapter can hold its > own T instance which represents the default. Then, when > asked for a value (returned by reference), the adapter > queries the optional. > If the optional has a value, the adapter returns the > optional's value. If not, the adapter returns the default > value it holds. > I considered that approach. It could be used to return only const references, which may or may not be enough. -Andy

6 9

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 16 Jul '05

16 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart > Sent: Thursday, July 14, 2005 3:34 AM > To: boost(a)lists.boost.org > Cc: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > > From: "Jost, Andrew" <Andrew_Jost(a)mentor.com> > > > From: boost-bounces(a)lists.boost.org > > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando > > > Cacciola > > > > Here is a real example. Imagine a researcher with many instruments > [snip long example indicating that using Boost.Optional for > data collection works fine, but for using or reporting that > information, Boost.Optional falls short] > > > > Okay. This works, but what about that ugly call to loadPoint? The > > problem is that the library function is expecting a signal > value, not > > a Boost.Optional! Boost.Optional helped us manage data collection, > > but does not help us call trend::loadPoint. Let's look at > another example. > > The library can just as easily expect a Boost.Optional. But you're assuming that we have control over the library. That's probably the exception rather than the rule in real life. <clip> > > translation point is where I see the need for guaranteed object > > delivery, for it seems that Boost.Optional and guaranteed object > > delivery are two ends of the same pipeline: at the head, we > obtain (or > > fail to obtain) a value, and in the process escape the need for a > > signal value; at the tail, we use the values we've > obtained, possibly > > in a context that EXPECTS signal values. Requires them. > So far we've > > used only the trinary operator to perform this translation, but is > > there a better way? > > The fundamental issue seems to be that you want an object or > function that automagically produces a value, even if one > wasn't otherwise available. Yes. <clip> > > Using adapters, the call to trend::loadPoint in the first example > > might look like this: > > > > > > // -- begin > > // call trend::loadPoint > > opt_dp::adapter f(-1); > > for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { > > tr.loadPoint( f(*p) ); > > } > > // -- end > > Your version, with Boost.Optional was like this: > > > for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { > > tr.loadPoint( *p ? p->get() : -1 ); > > } > > (I think you could change "p->get()" to "**p" if you like, BTW.) > > The latter is simpler and seems far more direct and, > therefore, readable. I don't see that your adapter has added > any value. > I tried to make the examples as syntactically plain as possile; they are optimized for clarity. There is a key advantage in the example with adapters because the adapter is a function object. In that respect, the door has been flung open to many templated constructs that are more difficlt with the ?: operator. For example, a boost::transform_iterator could be created with the adapter to automatically access the underlying objects in a sequence. <snip> > > I don't really see the value as presented thus far. There is > a tiny amount of syntactic sugar, but is that warranted? > I'm not sure. > > But, why do I keep saying optional instead of > Boost.Optional? To see, > > we must think about how an adapter interacts with the > optional object > > on which it operates. I won't spell out the fairly obvious > point that > > adapters should return references rather than whole T > objects, but if > > this is so, then an adapter that operates on an empty > optional object > > must ask that optional to, first, construct a new T object, then > > return a reference to that new object. Based on this, we can say a > > few things about an optional object, X, on which an adapter > operates: > > > > (a) X must have valid EMPTY and FULL states. > > (b) There must exist for X a valid EMPTY state, S, in which X > > privately holds an object, x, of type T. > > (c) If X is EMPTY (including state S), then altering or > replacing the > > internal x without setting the state to FULL is a "const this" > > operation. > > Your requirements are flawed. The adapter should hold an > instance of type T as provided by the constructor. Then, if > the Boost.Optional has no value, the adapter can return it's > default instance. IOW, the adapter shouldn't impose its > needs on the optional type. Boost.Optional would then work > fine, though I still question the value of your adapter. I would also like to see the adapter avoid "imposing its needs" on the optional object, but conversely, I don't think it would be right to to return whole T objects (instead of references). > > -- > Rob Stewart stewart(a)sig.com > Software Engineer http://www.sig.com > Susquehanna International Group, LLP using std::disclaimer; > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

5 14

Boost regression notification (2005-07-16)
by Douglas Gregor 16 Jul '05

16 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-16T15:03:26Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 244 failures in 11 libraries: io (1) multi_index (1) parameter (18) program_options (5) python (53) random (2) serialization (144) spirit (1) test (7) thread (2) wave (10) |io| ios_state_unit_test: intel-win32-8_1 |multi_index| test_special_set_ops: vc-8_0 |parameter| basics: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-8_0 macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-8_0 sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin vc-8_0 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |python| andreas_beyer: intel-win32-8_1 args: intel-win32-8_1 auto_ptr: intel-win32-8_1 back_reference: intel-win32-8_1 ben_scott1: intel-win32-8_1 bienstman1: intel-win32-8_1 bienstman2: intel-win32-8_1 bienstman3: intel-win32-8_1 builtin_converters: intel-win32-8_1 callbacks: intel-win32-8_1 const_argument: intel-win32-8_1 crossmod_exception: intel-win32-8_1 data_members: intel-win32-8_1 defaults: intel-win32-8_1 dict: intel-win32-8_1 docstring: intel-win32-8_1 enum: intel-win32-8_1 exception_translator: intel-win32-8_1 extract: intel-win32-8_1 implicit: intel-win32-8_1 injected: intel-win32-8_1 iterator: intel-win32-8_1 keywords: intel-win32-8_1 list: intel-win32-8_1 long: intel-win32-8_1 map_indexing_suite: intel-win32-8_1 minimal: intel-win32-8_1 multi_arg_constructor: intel-win32-8_1 nested: intel-win32-8_1 numpy: intel-win32-8_1 object: intel-win32-8_1 opaque: intel-win32-8_1 operators: intel-win32-8_1 pearu1: intel-win32-8_1 pickle1: intel-win32-8_1 pickle2: intel-win32-8_1 pickle3: intel-win32-8_1 pickle4: intel-win32-8_1 pointer_vector: intel-win32-8_1 polymorphism: intel-win32-8_1 polymorphism2: intel-win32-8_1 properties: intel-win32-8_1 raw_ctor: intel-win32-8_1 return_arg: intel-win32-8_1 shared_ptr: intel-win32-8_1 slice: intel-win32-8_1 staticmethod: intel-win32-8_1 str: intel-win32-8_1 test_pointer_adoption: intel-win32-8_1 try: intel-win32-8_1 tuple: intel-win32-8_1 vector_indexing_suite: intel-win32-8_1 virtual_functions: intel-win32-8_1 |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-7_1 vc-7_1 vc-8_0 vc-8_0 test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: vc-6_5 test_demo_pimpl_dll: vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 vc-7_1 vc-7_1 vc-7_1 vc-8_0 vc-8_0 vc-8_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: vc-6_5 vc-7_0 test_map_text_archive_dll: vc-6_5 vc-7_0 test_map_text_warchive_dll: vc-6_5 vc-7_0 test_mi_xml_archive_dll: vc-8_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_registered_xml_archive: vc-8_0 test_shared_ptr_132_text_archive_dll: intel-win32-8_1 test_shared_ptr_132_xml_warchive: intel-win32-8_1 intel-win32-8_1 |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |thread| test_mutex: vc-7_1 test_thread_lib: gcc-3.2.3-linux |wave| test_re2c_lexer: vc-8_0 vc-8_0 test_slex_lexer: vc-8_0 vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0 vc-8_0

1 0

[1.33.0] Status as of July 14
by Doug Gregor 16 Jul '05

16 Jul '05

We're very close to being able to release. We need to resolve the following issues before releasing: 1) Parameter library: many regressions; docs need to be finished (?) 2) Serialization library: many regressions 3) Inspection report: We don't need a fully-clean report, but we need to fix broken links, too-long file names, and files with tabs. At this time, do not commit any changes to CVS unless it: 1) Resolves a failure listed on the unresolved issues page at: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/ issues.html , 2) resolves a problem listed on the inspection page: http://www.boost.org/regression-logs/inspection_report.html 2) Is a documentation change, or 3) is on a branch. If you believe there is something critical that needs to go into this release that does not meet the above criteria, e-mail me privately. Doug

9 16

New Library Proposal: dual_state
by Jost, Andrew 16 Jul '05

16 Jul '05

This is my first post to the Boost distribution list, so please feel free to speak up if you find any part of this message to be outside the normal decorum. I am curious if there is support for what I'm calling a "dual_state" template class. Anyone familiar with Perl will instantly recognize the parallel. The idea is to attach a "statedness" value to arbitrary objects, allowing us to consider them defined or undefined. Newly constructed dual_state objects are undefined. For example, // -- begin template < class T > class dual_state { ... }; dual_state<int> a; a.defined(); // FALSE defined(a); // same thing // -- end We can "define" a dual_state object by assigning a value to it, either as a base type, T, or as another dual_state object: // -- begin // assign an int to a a = 5; a.defined() // TRUE // assign another dual_state<int> to a dual_state<int> b; b = a; b.defined(); // TRUE // -- end We can undefine a defined dual_state object: // -- begin a.undefine(); undefine(b); // -- end In addition, we can utilize an instance of another class, the "undefined_object", to interrogate or set the defined property of a dual_state object: // -- begin const class undefined_object {} undef; a = undef; a.defined(); // FALSE a == undef; // same thing // -- end The dual_state class provides a conversion to T. This conversion will, for an undefined dual_state object, return default T objects generated using the expression "T()". As an aside, it seems Boost.value_init may provide a more general solution that is worth considering. There is no conversion to T& because some compilers are utterly confused by such conversions. To make dual_state compatible with large or uncopyable objects, two explicit conversions are provided: // --begin template < class T > class dual_state { ... const T& value() const; T& define(); }; // -- end The value() member is straightforward. As for define(), it is necessary to first define the dual_state object before assigning it a value. The operator= member normally takes care of this step, but when dealing with the T reference directly we must explicitly use define(). An example using define() is shown below: // -- begin dual_state<int> x; cin >> x.define(); // -- end In Perl, the defined/undefined concept is tremendously useful, so I would expect similar utility in C++. I have not given any thought to what a dual_state<bool> is or how it is related to Boost.tribool. Thanks to everyone who took the time to read this whole post. I am open to all suggestions, including a better name -- "dual_state" is quite incongruent, but I can't think of anything better. Here are some additional poor suggestions: bistate, managed, switched, stated, definable. -- Andrew M. Jost

6 5

Re: [boost] Macros at namespace scope: trailing semicolon?
by Dave Gomboc 16 Jul '05

16 Jul '05

I'm amazed at how this particular thread has exploded. My $0.02: I've yet to see any arguments that I consider compelling to support the "always require camp". I expect direct textual substitution from a macro -- if it's expanding into a single statement, it ought to be expanding to a series of characters that includes the semicolon signalling the end of that statement. Other possibilities would only cause confusion. I'm firmly in the "never require a user to append a semicolon to a macro themself" camp. Dave

1 0

Re: [boost] VC 7.1/8.0 regression testing, call for volunteers
by Aleksey Gurtovoy 15 Jul '05

15 Jul '05

Carl Daniel writes: > Aleksey Gurtovoy wrote: >> Victor A. Wagner Jr. writes: >>> my system will be going offline until around 2005 August 1 in less >>> than 24 hours as I've reported previously (we're moving) >> >> Thanks for the heads up. >> >> Is somebody else able/willing to pick up regular VC 7.1/8.0 regression >> testing? > > I now have access to weekly builds of VC8 (currently testing the 7/11/2005 > build!). At the moment, it's not feasible to do boost regression testing on > those builds (it's a machine at MSFT), but I could look into getting it set > up. > > I now (once again) have the infrastructure in place locally to do boost > regression testing on VC8 beta 2, and/or VC8 June CTP. Unless someone else > volunteers, I can try to get my regression testing up and running again on > either or both of these builds. I think you are in a unique position w.r.t. weekly VC 8.0 builds, and IMO it would be a great service to both us and the VC8 team to test against those in addition to CTP/Beta 2. -- Aleksey Gurtovoy MetaCommunications Engineering

3 2

Library request: pstream / socketstream / serial stream
by Marc Siegel 15 Jul '05

15 Jul '05

Hi, At our labs we share the desire for a C++ iostreams implementation that deals with these problem domains: 1. Inter-process communications, including simple popen-type usage, like a scripting language; also pipes for forking 2. Socket communications, TCP UDP and unix 3. Serial communications, and a wrapper to set the serial parameters For 1. and 2., we are currently using the socket++ library. I am also aware of the PStreams library for 1. for 3. we use hacked together mix of C and C++. Is there any sort of joint strategy planned to tackle this area? If there is, I may be able to contribute. Marc -- Marc Siegel MIT Lincoln Laboratory Wideband Tactical Networking Group mlsiegel(a)ll.mit.edu . (781)981-5434

5 5

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 15 Jul '05

15 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Joel de Guzman > Sent: Friday, July 15, 2005 11:41 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > > Jost, Andrew wrote: > > > >>Hmmm. This reminds me of using the STL algorithms before having > >>Boost.Lambda, Boost.Bind, etc. Without a library of predefined > >>function objects that perform useful, reusable adaptations, or a > >>lambda approach to creating the adapters, one winds up > separating the > >>value extraction logic from the context in which it is used. > >> > > > > > > The Boost.Optional::adapter syntax is its own predefined > library and, > > though lambda is a fantastic approach, it won't compile > using Microsoft > > so we can't say it's the new paradigm. > > lambda works on Microsoft VC7.1 and above. Did I miss the > context of your statement? > Sorry, you are right. I am using VC 6.0 :-( > Cheers, > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

[Boost-bugs] [ boost-Bugs-1239052 ] timeconv.inl line 116 copy/paste error
by SourceForge.net 15 Jul '05

15 Jul '05

Bugs item #1239052, was opened at 2005-07-15 10:10 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=1239052&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: threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mike Glassford (glassfordm) Summary: timeconv.inl line 116 copy/paste error Initial Comment: has: if (boost::xtime_get(&cur, boost::TIME_UTC) <= 0) should be: if (boost::xtime_cmp(xt, cur) <= 0) my email is gyaralov(a)ixiacom.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1239052&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost regression notification (2005-07-15)
by Douglas Gregor 15 Jul '05

15 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-15T15:24:22Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 199 failures in 8 libraries: io (1) parameter (6) program_options (5) python (53) random (2) serialization (118) test (7) wave (7) |io| ios_state_unit_test: intel-win32-8_1 |parameter| basics: gcc-3.2.3-linux intel-win32-8_1 macros: gcc-3.2.3-linux intel-win32-8_1 sfinae: gcc-3.2.3-linux intel-win32-8_1 |program_options| cmdline_test_dll: mingw-3_4_2 positional_options_test_dll: mingw-3_4_2 unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |python| andreas_beyer: intel-win32-8_1 args: intel-win32-8_1 auto_ptr: intel-win32-8_1 back_reference: intel-win32-8_1 ben_scott1: intel-win32-8_1 bienstman1: intel-win32-8_1 bienstman2: intel-win32-8_1 bienstman3: intel-win32-8_1 builtin_converters: intel-win32-8_1 callbacks: intel-win32-8_1 const_argument: intel-win32-8_1 crossmod_exception: intel-win32-8_1 data_members: intel-win32-8_1 defaults: intel-win32-8_1 dict: intel-win32-8_1 docstring: intel-win32-8_1 enum: intel-win32-8_1 exception_translator: intel-win32-8_1 extract: intel-win32-8_1 implicit: intel-win32-8_1 injected: intel-win32-8_1 iterator: intel-win32-8_1 keywords: intel-win32-8_1 list: intel-win32-8_1 long: intel-win32-8_1 map_indexing_suite: intel-win32-8_1 minimal: intel-win32-8_1 multi_arg_constructor: intel-win32-8_1 nested: intel-win32-8_1 numpy: intel-win32-8_1 object: intel-win32-8_1 opaque: intel-win32-8_1 operators: intel-win32-8_1 pearu1: intel-win32-8_1 pickle1: intel-win32-8_1 pickle2: intel-win32-8_1 pickle3: intel-win32-8_1 pickle4: intel-win32-8_1 pointer_vector: intel-win32-8_1 polymorphism: intel-win32-8_1 polymorphism2: intel-win32-8_1 properties: intel-win32-8_1 raw_ctor: intel-win32-8_1 return_arg: intel-win32-8_1 shared_ptr: intel-win32-8_1 slice: intel-win32-8_1 staticmethod: intel-win32-8_1 str: intel-win32-8_1 test_pointer_adoption: intel-win32-8_1 try: intel-win32-8_1 tuple: intel-win32-8_1 vector_indexing_suite: intel-win32-8_1 virtual_functions: intel-win32-8_1 |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-8_0 test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-8_0 test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-8_0 test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-8_0 test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 vc-8_0 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux vc-8_0 test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux vc-8_0 test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-8_0 test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: vc-6_5 test_demo_pimpl_dll: vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 vc-7_1 vc-8_0 vc-8_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: vc-6_5 vc-7_0 test_map_text_archive_dll: vc-6_5 vc-7_0 test_map_text_warchive_dll: vc-6_5 vc-7_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin vc-6_5 test_non_default_ctor_text_archive_dll: cw-9_5-darwin test_non_default_ctor_text_warchive_dll: cw-9_5-darwin test_non_default_ctor_xml_archive_dll: cw-9_5-darwin test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin test_non_intrusive_text_archive_dll: cw-9_5-darwin test_non_intrusive_text_warchive_dll: cw-9_5-darwin test_non_intrusive_xml_archive_dll: cw-9_5-darwin test_non_intrusive_xml_warchive_dll: cw-9_5-darwin test_shared_ptr_132_binary_archive: borland-5_6_4 test_shared_ptr_132_binary_archive_dll: borland-5_6_4 test_shared_ptr_132_text_archive: borland-5_6_4 test_shared_ptr_132_text_archive_dll: borland-5_6_4 test_shared_ptr_132_text_warchive: borland-5_6_4 test_shared_ptr_132_text_warchive_dll: borland-5_6_4 test_shared_ptr_132_xml_archive: borland-5_6_4 test_shared_ptr_132_xml_archive_dll: borland-5_6_4 test_shared_ptr_132_xml_warchive: borland-5_6_4 test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 |test| errors_handling_test: cw-9_5-darwin vc-8_0 vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |wave| test_re2c_lexer: vc-8_0 test_slex_lexer: vc-8_0 testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux vc-8_0

1 0

Re: [boost] Macros at namespace scope: trailing semicolon?
by Brian Allison 15 Jul '05

15 Jul '05

David Abrahams wrote: I don't know about the priorities of the rest of Boost, but I guess purity is a lower priority for me than some other things. FWIW, this tells me that I made the better choice to observe Boost, but not incorporate it yet if at all. At least, until I know what the highest priority are WRT Boost design. What are the most important issues for the designers of Boost? Please - I'm not trying to offend, but when I'm able to observe Boost's algebra of design issues then it'll mean either that I *can* incorporate Boost or that I need not spend time reading the mailing list anymore. Either way, it'll mean more of the only irreplaceable commodity (time). :) thanks, Brian

2 1

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 15 Jul '05

15 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola > Sent: Tuesday, July 12, 2005 1:11 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > Now we're getting somewhere. Your post has led me in a new direction so, rather than answer the previous message point by point, I'll just use a few comments as anchors for my explanation. If I leave any question unanswered, please feel free to point it out. > > Hi Andrew, > > > [SNIP] > > > > *GUARANTEED OBJECT DELIVERY* > > First and foremost, dual_state is guaranteed to always > deliver a valid > > object (or reference), even if this object (or reference) must be > > conjured from nowhere. This is in direct contrast to > Boost.optional, > > which maintains that > > > Well, it never ocurred to me to let optional<> provide default values. > I just can't think right now of any situation were I would use it. > Can you post some *real life* examples? > (the example you posted is not good enough because as it is > one would argue wthat the optional/dual_state wrapper is not > needed to begin with) Here is a real example. Imagine a researcher with many instruments collecting data. To make it concrete, let's say we have a geologist with dozens of instruments spread across some mountain summit. When he pushes enter on his laptop, all the instruments take a measurement and transmit it to the laptop. Or not. Because sometimes instruments fail, or just fail to respond. Which is why he's using Boost.Optional to store the measurements. So that solves the problem and we can all go home, right? But wait! Once we get off the mountain there is more work to do. Our geologist friend still must retrieve and analyze his data. He will load it into containers and call functions. One of those functions is a member named of the class trend named trend::loadPoint. This member accepts data points into the class then, after all the points are loaded, a call to trend::calculate returns some useful number. To do its work, trend must account for missed measurements, so loadPoint accepts a signal -- namely, any negative value -- to indicate no measurement. For the sake of argument, we'll assume that "trend" is located in a library the geologist cannot change. His code might resemble the following example program: // -- begin #include <boost/optional/optional.hpp> #include <boost/none.hpp> #include <iostream> #include <vector> typedef long double data_point; typedef boost::optional<data_point> opt_dp; typedef std::vector< opt_dp > data_set; // the real "trend" is in a library -- this definition is for illustration only class trend { public: void loadPoint( data_point x ) { if( x<0 ) { cout << "no measurement" << endl; } else { cout << "point: " << x << endl; } } }; int main() { data_set d; trend tr; // make up some data d.push_back(5); d.push_back(boost::none); d.push_back(10); // call loadPoint for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { tr.loadPoint( *p ? p->get() : -1 ); } return 0; } // -- end Okay. This works, but what about that ugly call to loadPoint? The problem is that the library function is expecting a signal value, not a Boost.Optional! Boost.Optional helped us manage data collection, but does not help us call trend::loadPoint. Let's look at another example. Say I'm working on a project that persists some configuration data. Momentarily forgetting that Boost.Program_options exists, I decide to use a simple model in which I map string parameter names to string values. Values are allowed to be non-existent, so the map structure might be declared as follows: // -- begin typedef boost::optional<string> param_map_value; typedef std::map<string, param_map_value> param_map; param_map pMap; // -- end After our program runs for a while, and after the user has set a few persistable parameters, it is time to quit, so the program opens a configuration file and begins writing the contents of pMap to that file, which should look like this: // -- begin # CONFIG FILE PARAM_A VALUE_A PARAM_B VALUE_B PARAM_C <undef> ... // -- end In the particular case above, the user has apparently set values for the "A" and "B" parameters, but not for "C". We might write such a file with the following code: // -- begin // assume cf_out is an open ofstream for( param_map::iterator p = pMap.begin(); p != pMap.end(); ++p ) { cf_out << p->first << " " << ( p->second ? p->second.get() : "<undef>" ) << endl; } // -- end This illustrates the same problem as before, namely that it requires us to translate an empty Boost.Optional into something else. This translation point is where I see the need for guaranteed object delivery, for it seems that Boost.Optional and guaranteed object delivery are two ends of the same pipeline: at the head, we obtain (or fail to obtain) a value, and in the process escape the need for a signal value; at the tail, we use the values we've obtained, possibly in a context that EXPECTS signal values. Requires them. So far we've used only the trinary operator to perform this translation, but is there a better way? > > As David Abraham said, however, IF it turned out to be useful > (I can't see it right now) it seems that such an "optional > with default" could be a specialized form of optional<>. > > Off the top of my head, a default value could be supported in > at least 3 ways: > > (1) Storing an actual default value in each optional instance. > > (2) Parameterizing optional<> with a static factory that can > be called to provide such defauts. > > (3) Using T's default constructor (if any) to create such a value. > > Notice that optional<> does not require T to be DefaultConstructible. > Several people were quick to point out a key conceptual flaw in the original dual_state concept. By delivering only default-constructed objects, dual_state is an arbitrarily circumscribed implementation of a more general, and powerful, model. Suggestions (1) and (2), proposed in the above clip, are a bit better because they let us specify the default value, but a deeper problem remains. It is that by combining the default value with the optional-like storage object, we commit the mortal sin of joining metadata with the real data it describes. It's the same reason we use iterators to serially access containers, rather than absurdly assigning some "current_element" state to the container itself. Returning to the trend::loadPoint example, that function expects the signal value to be a negative number. The next function might expect 0. A third function, yet another signal. The default value is not a property of our data, rather it is a property of the functions that USE our data. In light of this, a better implementation of guaranteed delivery would make use of template function objects that I'll call "adapters". The role of an adapter would be to evaluate a given optional object (I'll refer to anything resembling Boost.Optional as an "optional" object) into either the valid object it contains, or a default value, which is probably defined in the adapter's template specification or constructor. Adapters separate our optional objects from the defaults we might want to use in place of uninitialized T objects. Note that they are incompatible with noncopyable T objects. Using adapters, the call to trend::loadPoint in the first example might look like this: // -- begin // call trend::loadPoint opt_dp::adapter f(-1); for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { tr.loadPoint( f(*p) ); } // -- end The second example would look like this: // -- begin // assume cf_out is an open ofstream param_map_value::adapter f("<undef>"); for( param_map::iterator p = pMap.begin(); p != pMap.end(); ++p ) { cf_out << p->first << " " << f(p->second) << endl; } // -- end With a little creativity, programmers could make further use of the STL to craft strikingly elegant solutions. It seems to me adapters would make a useful and appropriate addition to our toolbox, improving the flexibility with which we can access copyable T objects contained in an optional container. But, why do I keep saying optional instead of Boost.Optional? To see, we must think about how an adapter interacts with the optional object on which it operates. I won't spell out the fairly obvious point that adapters should return references rather than whole T objects, but if this is so, then an adapter that operates on an empty optional object must ask that optional to, first, construct a new T object, then return a reference to that new object. Based on this, we can say a few things about an optional object, X, on which an adapter operates: (a) X must have valid EMPTY and FULL states. (b) There must exist for X a valid EMPTY state, S, in which X privately holds an object, x, of type T. (c) If X is EMPTY (including state S), then altering or replacing the internal x without setting the state to FULL is a "const this" operation. As it currently is, Boost.Optional, which we can think of as a stack with fixed capacity 1 and variable size, is incompatible with adapters, but we could certainly define a class derived from Boost.Optional that meets the above requirements. Perhaps, for contrast it could be called "Required"? User's might choose to use Required, sacrificing compatibility with noncopyable objects, in cases where they think adapters will come in handy. This message is already too long, so I'll reserve my additional thoughts until others have a chance to respond. -Andy

4 3

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 15 Jul '05

15 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola > Sent: Tuesday, July 12, 2005 1:27 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] New Library Proposal: dual_state > > > "Jost, Andrew" <Andrew_Jost(a)mentor.com> escribió en el > mensaje > news:8F7931C35114FA4F9D25E1A9299408E20276DFA7@SVR-ORW-EXC-06.m > gc.mentorg.com... > >> Boost.Optional has some interaction with (including initialization > >> from) boost::none, which seems to correspond to your "undef". > > > > Good point, but I would also like to see overloaded == and != > > operators using boost::none. > > > That is already supported. I think this is another documentation problem. http://www.boost.org/libs/optional/doc/optional.html shows a constructor and operator= using boost::none, but no operators == or !=. But you are right that the functionality is supported in the library. > > Fernando Cacciola > SciSoft > > > >

2 1

[iostreams] please vote on template names
by Jonathan Turkanis 15 Jul '05

15 Jul '05

Hi, I'm trying to pick good names for the fundamental iostreams components streambuf_facade and stream_facade: template<typename Device ... > class streambuf_facade : public basic_streambuf< > { // Peform i/o using an instance of Device }; template<typename Device ... > class stream_facade : public basic_[i][o]stream< > { // Peform i/o using an instance of Device }; Here are the candidates: 1. streambuf_facade / stream_facade 2. generic_streambuf / generic_stream 3. streambuf / stream 4. xstreambuf / xstream 5. device_streambuf / device_stream 6. devbuf / devstream Please let me know what you think. Jonathan

10 33

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 15 Jul '05

15 Jul '05

>From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eelis van der Weegen >Jost, Andrew wrote: >> I am curious if there is support for what I'm calling a "dual_state" >> template class. > From your description it sounds a lot like Boost.Optional. What are the main differences? >Eelis I'll admit I did not even pause at Boost.optional when I scanned the library listing for previous work, a failure in my ability to connect the description, "Discriminated-union wrapper for optional values," with the concept I had in mind. I'm not sure if the problem is in my unfamiliarity with the subject, the description itself, or the concept's general ineffability. In any case, I'll contrast Boost.optional with dual_state to see where the differences lie. But first, let's find a common starting point. The Boost.optional documentation succinctly states the purpose of that library: "optional<T> intends to formalize the notion of initialization/no-initialization allowing a program to test whether an object has been initialized" That document also discusses various solutions to the general problem of handling "signal" values, including cases where the cumbersome pair<T, bool> construct is necessary because no sensible signal can be defined. I would say that dual_state is intended to tackle the same set of problems. However, I see three important differences. *GUARANTEED OBJECT DELIVERY* First and foremost, dual_state is guaranteed to always deliver a valid object (or reference), even if this object (or reference) must be conjured from nowhere. This is in direct contrast to Boost.optional, which maintains that "access to the value of an uninitialized object is **undefined behaviour**" The above quote is also from the Boost.optional documentation (emphasis mine). Boost.optional and dual_state appear to address the same problems, but with two fundamentally distinct philosophies. Consider a dual_state<string>. In the following code, the char* in the final expression is guaranteed to be valid, so the programmer needn't even bother to check it before calling strlen: // -- begin typedef dual_state<std::string> state_string; state_string str; int len; ... len = strlen( str->c_str() ); // always a valid char* // -- end Note that operator-> is used to access a base class' member. The analogous code using Boost.optional is as follows: // -- begin typedef boost::optional<std::string> opt_string; opt_string str; int len; len = strlen( str.get().c_str() ); // UNDEFINED! // the correct way if( !str ) { // do something else <== HERE } else { len = strlen( str.get().c_str() ); // okay now } // -- end A programmer may view dual_state's "guaranteed delivery" behavior as either advantage or liability, but his opinion, if tenable, must focus on the relative benefits afforded by guaranteed objects versus the risks posed by -- one might say -- "junk" default values. I would say it depends on the application. More to the point, if the answer to what goes "<== HERE" is always "set len = 0" for a particular application, then dual_state could offer greater clarity with less work. *FULL OPERATOR SUPPORT* A second difference is that dual_state directly supports the full complement of operators (for built-in types), this due to the fact that most operators are delegated through the implicit conversion-to-base-type operator. Exceptions to implicit delegation are those operators that modify the dual_state object itself. The example below demonstrates two operators, + and +=. Addition operates via the conversion to T (not T&) operator and therefore returns a regular T object, at the cost of one extra copy (a copy, incidentally, that can be avoided by using the value() member). The concerted += operator, which is defined by dual_state, avoids copies and evaluates to a dual_state reference: // -- begin typedef dual_state<int> state_int; state_int x; x + 5; // evaluates to (int); x still undefined x += 5; // evaluates to (state_int&); x is defined, equal to 5 x.value() + 5; // also evaluates to (int) typedef boost::optional<int> opt_int; opt_int y; y + 5; // won't compile y += 5; // nor will this y.get() + 5; // evaluates to (int) // -- end Again, the question of which behavior is most desirable hinges on the programmer's needs. While Boost.optional and dual_state both give the programmer a way manage defined and undefined objects; a way to manage initialized and uninitialized data; a way to sidestep "signal" values: EOF, -1, n_pos -- the semantics of one approach or the other may be better suited for a given application. *THE UNDEFINED_OBJECT* A third difference between Boost.optional and dual_state involves the very personal issue of syntax. It is nonsense to tell people to prefer one syntax over another, but I will note that dual_state's use of the undefined_object lends a unique feel to code that uses it. The programmer's intent is unmistakably clear when "undef" is used to initialize members: // -- begin using dual_state_namespace::constants::undef; class bar { ... }; class foo { public: dual_state<int> x, y, z; dual_state<bar> a; foo() : a(undef), x(undef), y(undef), z(undef) {} }; // -- end The concept of using self-evident constructs to obviate documentation is a valuable one. It is detailed in the Boost.noncopyable notes. *SUMMARY* My intent has been to clearly and accurately articulate the conceptual differences I see between Boost.optional, a reviewed and tested library having several years usage history, and dual_state, a concept. In that I have succeeded or failed, others may comment, judge. -- Andrew M. Jost

15 43

[intrusive_ptr] Constructor not explicit.
by Russell Hind 15 Jul '05

15 Jul '05

Just wondered why intrusive_ptr(T * p, bool add_ref = true); isn't explicit? The second arg defaults so (using bcc32-5.6.4), an intrusive_ptr can be explicitly constructed from a raw ptr. Is this intended when shared_ptr is designed to prevent this? Cheers Russell

2 2

Parameters Library Overload Generation Macros
by David Abrahams 15 Jul '05

15 Jul '05

It just occurred to me as I was writing the docs (it's amazing how writing documentation clarifies design issues!) that for the parameters library, "The Forwarding Problem" usually isn't really as bad as it might seem. In a family of overloaded forwarding functions, the only positions in which we need a T&/T const& overload pair are those in which the corresponding parameter is an out (or in/out) parameter. When passed non-positionally, the const/non-const issue is handled by the overloaded operator= on the keyword objects. So I'm thinking the macros for generating the overloads, in the next release at least, should just take care of generating the right overloads. For example, something like BOOST_NAMED_PARAMETER_FUNCTION( void, depth_first_search, (required(in))(in)(in)(out)(in) ) might work. For reference, the docs for depth_first_search are at http://www.boost.org/libs/graph/doc/depth_first_search.html Here I am assuming that the parameter order would be: graph visitor index_map color_map root_vertex [Doug, I am a little concerned about how to translatate the interface for tutorial purposes, since the documented positional interfaces don't include an overload that takes 5 parameters: index_map can only be passed as a named parameter! I don't want to confuse people. Could you take a look at libs/parameter/doc/html/index.html and give your feedback? -- Thanks] Of course, this idea doesn't work out so well for an unnamed parameter interface, which we're also going to support after 1.33. But that's a separate macro ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[preprocessor] How to prevent macro expansion with SEQ?
by Markus Schöpflin 15 Jul '05

15 Jul '05

Hello, I have the following macro code: #define PY_DEFINE_CONSTANT(X) scope().attr(#X) = X #define PY_DEFINE_CONSTANTS_HELPER(R, DATA, X) PY_DEFINE_CONSTANT(X); #define PY_DEFINE_CONSTANTS(SEQ) \ BOOST_PP_SEQ_FOR_EACH(PY_DEFINE_CONSTANTS_HELPER, BOOST_PP_EMPTY, SEQ) This works fine when used with non-macro arguments: PY_DEFINE_CONSTANTS((foo)(bar)) expands to: scope().attr("foo") = foo; scope().attr("bar") = bar; But when foo and bar are macros like this: #define foo 1 #define bar 2 it expands to: scope().attr("1") = 1; scope().attr("2") = 2; Is there a way to get this: scope().attr("foo") = 1; scope().attr("bar") = 2; or this: scope().attr("foo") = foo; scope().attr("bar") = bar; IOW, how can I prevent macro expansion for X when invoked from PY_DEFINE_CONSTANTS()? TIA, Markus

3 5

Re: [boost] VC8 type traits documentation
by Jason Shirk 15 Jul '05

15 Jul '05

> -----Original Message----- > From: narechk [mailto:narechk@gmail.com] > Sent: Wednesday, July 13, 2005 10:29 AM > Subject: Re: VC8 type traits documentation > > > It appears the support for compiler intrinsic type traits in Beta2 is > implemented only partially: > > typedef int T; > __is_pod(T); > __has_trivial_constructor(T); > __has_trivial_copy(T); > __has_trivial_assign(T); > __has_trivial_destructor(T); > __has_nothrow_constructor(T); > __has_nothrow_copy(T); > __has_nothrow_assign(T); > > Ditto for the rest of fundamental types. All of the above return false, > which AFAIK is incorrect! [§3.9, ¶10; §9, ¶4] > The compiler intrinsics are only there to provide the type information that is otherwise unavailable. Put another way, for fundamental types, we decided we don't care what the value is (we default to false) since an implementation of type traits can get the right value. This simplifies the implementation and puts the burden on the library implementation which can change more easily than the compiler. > struct A > { > A() {} > A(const A&) {} > const A& operator=(const A&) {} > }; > > typedef A T; > __is_pod(T); // false > __has_trivial_constructor(T); // false > __has_trivial_copy(T); // false > __has_trivial_assign(T); // false > __has_trivial_destructor(T); // true > __has_nothrow_constructor(T); // false, too conservative > __has_nothrow_copy(T); // false, too conservative > __has_nothrow_assign(T); // false, too conservative > > The compiler is too conservative regarding nothrow, it should be able to > deduce that constructor, copy and assign can never throw. > > struct B > { > B() throw() {} > B(const B&) throw() {} > const B& operator=(const B&) throw() {} > }; > > typedef B T; > __is_pod(T); // false > __has_trivial_constructor(T); // false > __has_trivial_copy(T); // false > __has_trivial_assign(T); // false > __has_trivial_destructor(T); // true > __has_nothrow_constructor(T); // true > __has_nothrow_copy(T); // true > __has_nothrow_assign(T); // true > > It seems the compiler needs an explicit nothrow statement in order for > ctor, copy and assign to be qualified as nothrow. Presumably the result > of nothrow deduction is not fed to the intrinsics correctly in this > version. > > Can someone comment on the above. > You are correct that the compiler _could_ deduce nothrow in your example, but in general the compiler couldn't (for example, if the definition of the function is in the current translation unit), and therefore shouldn't try. -- Jason Shirk VC++ Compiler Team

3 2

Re: [boost] Interest in a binary_int template for binary literals?
by Scott Schurr 15 Jul '05

15 Jul '05

Greetings, I wrote in part: > Prompted by some discussion on comp.sdt.c++.moderated, I have a > small template that allows the user to declare an integer literal > in binary. > > Usage looks like: > > #include "binary_int.hpp" > > unsigned int binary = binary_int<1001,0011,1011,0000>::b; Thanks for all the responses. Here are answers to some of the questions I got. ------------------------ Pavel Vozenilek asked: > * How does it deal with bit values like 0111? This is octal value. Right. There are specilizations for decimal and octal values. This means there is some aliasing. A few non-binary decimal and octal values leak through. For example 0111 (octal) is 73 decimal and, for that matter, 0x49 hex. So the template accepts all of these values. It's not perfect, but it's the best I could figure out. > * Does it check that the digits are 0 or 1 during compile time? It doesn't check individual digits. It checks for specific numeric values which would be good at representing a 4-bit binary value. See the binary_nibble specializations in the appended code. > * Would it work with hex values like: > bits<unsigned, 0xF,0x8>::value; No, not as it is currently implemented. ------------------------ Vladimir Prus responded: > Why is that better than > > unsigned x = strtoul("1010010001000010000001", 0, 2); > > ? I believe that 'strtoul' is part of C99. Not a bad approach. The binary_int template does the translation at compile time rather than at run time. It does the check (as best it can) for valid binary values at compile time as well. ----------------------- Paul A Bristow replied: > Can you post reference to discussion... I'm not very clever with URLs but the discussion, according to Google Groups, was titled "Power of 2 Enumerations" in comp.std.c++. The discussion in question started with a post by David Abrahams on November 1st, 2004 where he wrote: > You can even write a simple template that makes these into > compile-time constants: > > const feature_t FEATURE1 = binary<001>::value; > const feature_t FEATURE2 = binary<010>::value; > const feature_t FEATURE3 = binary<100>::value; Paul also asked: > and perhaps append the binary_int.hpp file as it sounds quite > short? Yes, the template is only 150 lines or so including comments. I've appended it, in its current state, to the end of this response. I did some editing of the template in an attempt to make it boost compatible, although I didn't put it in the Boost name space. Even though it says it's a boost file, I'm fully aware that it isn't. Sorry about that. Thanks for everyone's attention. Scott Schurr binary_int.hpp -------------------------------------------------------------- // Boost general library binary_int.hpp header file -------------------------// // Copyright Credence Systems 2005, as submitted by Scott Schurr. Use, // modification, and distribution are subject to the Boost Software License, // Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) #ifndef BOOST_BINARY_INT_HPP #define BOOST_BINARY_INT_HPP // Make a couple of templates to help catch bad binary_nibble parameters template <bool> struct binary_nibble_VALID_VALUES_BINARY_0000_THROUGH_1111; template <> struct binary_nibble_VALID_VALUES_BINARY_0000_THROUGH_1111<true> { }; // Write a 4-bit integer value as binary. // // Usage: // unsigned int n = binary_nibble<1011>::b // // The tricky part is remembering to include the '::b' at the end. // For example: // // #include "binary_int.h" // ... // int regValue = binary_nibble<1001>::b; // // Make a general binary_nibble type that causes a failure. Only // the specializations are valid usages. template <unsigned int v> struct binary_nibble { binary_nibble_VALID_VALUES_BINARY_0000_THROUGH_1111<false> t; enum { b = 0 }; }; // Specialize the binary_nibble template for values we allow. // The following values work for both decimal and octal. template<> struct binary_nibble<0> { enum { b = 0x0 }; }; template<> struct binary_nibble<1> { enum { b = 0x1 }; }; // Decimal values. template<> struct binary_nibble<10> { enum { b = 0x2 }; }; template<> struct binary_nibble<11> { enum { b = 0x3 }; }; template<> struct binary_nibble<100> { enum { b = 0x4 }; }; template<> struct binary_nibble<101> { enum { b = 0x5 }; }; template<> struct binary_nibble<110> { enum { b = 0x6 }; }; template<> struct binary_nibble<111> { enum { b = 0x7 }; }; template<> struct binary_nibble<1000> { enum { b = 0x8 }; }; template<> struct binary_nibble<1001> { enum { b = 0x9 }; }; template<> struct binary_nibble<1010> { enum { b = 0xA }; }; template<> struct binary_nibble<1011> { enum { b = 0xB }; }; template<> struct binary_nibble<1100> { enum { b = 0xC }; }; template<> struct binary_nibble<1101> { enum { b = 0xD }; }; template<> struct binary_nibble<1110> { enum { b = 0xE }; }; template<> struct binary_nibble<1111> { enum { b = 0xF }; }; // Octal values. template<> struct binary_nibble<010> { enum { b = 0x2 }; }; template<> struct binary_nibble<011> { enum { b = 0x3 }; }; template<> struct binary_nibble<0100> { enum { b = 0x4 }; }; template<> struct binary_nibble<0101> { enum { b = 0x5 }; }; template<> struct binary_nibble<0110> { enum { b = 0x6 }; }; template<> struct binary_nibble<0111> { enum { b = 0x7 }; }; // The following helper template determines the behavior of the // binary_int template when default arguments are passed in. // A default argument (0ul-1) will leave the previously calculated // value unchanged. A non-default argument multiplies the previously // calculated value by 16 and adds in the new (non-default) argument. template<unsigned int v> struct binary_int_arg { enum { b = binary_nibble<v>::b, mul = 16, }; }; template<> struct binary_int_arg<0ul-1> { enum { b = 0, mul = 1, }; }; // Declare a binary value in the following form: // // int i = binary_int<1100,1010,0001>::b // // Usage: // // unsigned int = binary_int<up to 16 binary_nibble>::b // // Write an integer as a binary value composed of up to 16 nibbles. // The tricky part is remembering to include the '::b' at the end. // For example: // // #include "binary_int.h" // ... // int regValue = binary_int<1000,1001,0011,0000>::b; // // One to 16 nibble-sized arguments are allowed, which allows for word // lengths up to 64 bits. If it's not working for you make sure that // you are including the closing '::b'. template<unsigned int b15, unsigned int b14 = 0ul-1, unsigned int b13 = 0ul-1, unsigned int b12 = 0ul-1, unsigned int b11 = 0ul-1, unsigned int b10 = 0ul-1, unsigned int b9 = 0ul-1, unsigned int b8 = 0ul-1, unsigned int b7 = 0ul-1, unsigned int b6 = 0ul-1, unsigned int b5 = 0ul-1, unsigned int b4 = 0ul-1, unsigned int b3 = 0ul-1, unsigned int b2 = 0ul-1, unsigned int b1 = 0ul-1, unsigned int b0 = 0ul-1> struct binary_int { private: enum { v15_ = binary_int_arg<b15>::b, v14_ = (v15_ * binary_int_arg<b14>::mul) + binary_int_arg<b14>::b, v13_ = (v14_ * binary_int_arg<b13>::mul) + binary_int_arg<b13>::b, v12_ = (v13_ * binary_int_arg<b12>::mul) + binary_int_arg<b12>::b, v11_ = (v12_ * binary_int_arg<b11>::mul) + binary_int_arg<b11>::b, v10_ = (v11_ * binary_int_arg<b10>::mul) + binary_int_arg<b10>::b, v9_ = (v10_ * binary_int_arg<b9>::mul) + binary_int_arg<b9>::b, v8_ = (v9_ * binary_int_arg<b8>::mul) + binary_int_arg<b8>::b, v7_ = (v8_ * binary_int_arg<b7>::mul) + binary_int_arg<b7>::b, v6_ = (v7_ * binary_int_arg<b6>::mul) + binary_int_arg<b6>::b, v5_ = (v6_ * binary_int_arg<b5>::mul) + binary_int_arg<b5>::b, v4_ = (v5_ * binary_int_arg<b4>::mul) + binary_int_arg<b4>::b, v3_ = (v4_ * binary_int_arg<b3>::mul) + binary_int_arg<b3>::b, v2_ = (v3_ * binary_int_arg<b2>::mul) + binary_int_arg<b2>::b, v1_ = (v2_ * binary_int_arg<b1>::mul) + binary_int_arg<b1>::b, v0_ = (v1_ * binary_int_arg<b0>::mul) + binary_int_arg<b0>::b, }; public: enum { b = v0_ }; }; #endif // BOOST_BINARY_INT_HPP

4 3

Re: [boost] VC 7.1/8.0 regression testing, call for volunteers (Was: [1.33.0] Status as of July 14)
by Rene Rivera 15 Jul '05

15 Jul '05

Carl Daniel wrote: > Aleksey Gurtovoy wrote: > >>Victor A. Wagner Jr. writes: >> >>>my system will be going offline until around 2005 August 1 in less >>>than 24 hours as I've reported previously (we're moving) >> >>Thanks for the heads up. >> >>Is somebody else able/willing to pick up regular VC 7.1/8.0 regression >>testing? > > I now have access to weekly builds of VC8 (currently testing the 7/11/2005 > build!). At the moment, it's not feasible to do boost regression testing on > those builds (it's a machine at MSFT), but I could look into getting it set > up. > > I now (once again) have the infrastructure in place locally to do boost > regression testing on VC8 beta 2, and/or VC8 June CTP. Unless someone else > volunteers, I can try to get my regression testing up and running again on > either or both of these builds. Is that a "willing to run vc8 tests but not vc71" ? For those volunteering it would be good to mention what resources you have available; CPU, memory, disk space, and machine time. As it takes a considerable amount of resources for testing, especially disk space. And having the faster machine and large ram will speed up the testing. I'm not trying to discourage people from volunteering though :-) Just want to make sure we keep up a reasonable testing pace. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 0

Re: [boost] weak_ptr triple states
by Jaap Suter 14 Jul '05

14 Jul '05

>> a weak_ptr can be said to have three states. >> 1. Never been assigned to (default constructed) >> 2. Assigned to, lock will return a shared_ptr to a valid object. >> 3. Assigned to, but the object pointed to is dead and lock will >> return null. > There is no particular reason to make 1 and 3 indistinguishable. You are > right that weak_ptr could have provided an "is empty" query in addition to > expired(). There just aren't any compelling use cases for it, as far as I > know. Are there compelling reasons not to add such a member function, i.e. a different shared_ptr implementation wouldn't be able to provide such a function? A friend of mine actually came up with a use case in his code, which is what prompted this question. In pseudo-code, it looked like this: struct guarded_memory { void* memory; weak_ptr guard; guarded_memory(void* m) : guard(), memory(m) {} guarded_memory(void* m, weak_ptr g) : guard(g), memory(m) {} void access() { if (guard.never_been_assigned_to_before()) { // no guard means always accessible do_something_with(memory); } else { if (shared_ptr p = guard.lock()) { do_something_with(memory); } } } }; Basically; if the user never provided a guard, the memory is deemed accesible at all times, otherwise accessibility depends on the liveliness of the pointed to guard. In my opinion, the code is ackwardly assymetrical and not an example of great design, but alas, it's what he came up with in some context. The solution to the above code is too add a litle boolean that remembers which of the two constructors has been called. This boolean is strictly speaking redundant because weak_ptr already stores this information. Hence my question. Thanks, Jaap Suter

3 2

Type Traits Documentation Outdated?
by David Abrahams 14 Jul '05

14 Jul '05

It seems like the type traits docs have suffered some stagnation over time. For example, is it documented somewhere that almost all the traits are also Metafunctions? Also, the "guidelines for integral constant expressions" probably ought to be updated to recommend the use of MPL operations on integral constant wrappers instead of the baroque and long-winded ice_whatever templates. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Boost Wiki is corrupt
by Jody Hagins 14 Jul '05

14 Jul '05

Recent changes show... July 14, 2005 * (diff) BoostSocket/TimeValueConcept 11:10 am (2 changes) . . . . . 36.67-18-98.reverse.theplanet.com * (diff) BoostSocket/TimeValueConcept 11:10 am (2 changes) . . . . . 36.67-18-98.reverse.theplanet.com * (diff) BOOST WIKI 11:10 am (2 changes) . . . . . 36.67-18-98.reverse.theplanet.com * (diff) RecentChanges 11:10 am (2 changes) . . . . . 36.67-18-98.reverse.theplanet.com * (diff) RecentChanges 11:10 am (2 changes) . . . . . 36.67-18-98.reverse.theplanet.com

2 1

Re: [boost] Interest in a binary_int template for binary literals?
by Scott Schurr 14 Jul '05

14 Jul '05

Greetings, David Abrahams wrote: > Scott Schurr <scott_schurr(a)credence.com> writes: > >>> * How does it deal with bit values like 0111? This is octal value. >> >> Right. There are specilizations for decimal and octal values. >> This means there is some aliasing. A few non-binary decimal and >> octal values leak through. For example 0111 (octal) is 73 decimal >> and, for that matter, 0x49 hex. So the template accepts all of >> these values. It's not perfect, but it's the best I could figure >> out. > > I think the answer is confusing. I don't know what "aliasing" means > in this case, but: aside from zero, the decimal numerals containing > all 1s and 0s have distinct values from the octal numerals containing > all 1s and 0s, at least up to something like 16 bits. There's no > ambiguity. Yes, my answer was confusing. Sorry. Let me try again. The template operates on values that look as though they should be binary, but are expressed in decimal or octal. For example: o 1001 - is a decimal value of one thousand and one, or 0x3E9. The template transforms this value to decimal 9, or 0x9. o 0010 - is an octal value that represents the decimal value eight, or 0x8. The template transforms this value to decimal 2, or 0x2. For legitimate binary representations like these, in decimal and octal, there is never any ambiguity of interpretation. I don't have a general proof, but the template only relies on no ambiguity for up to four digits. I have, in effect, an exhaustive proof in the code that there is no ambiguity up to four digits. My confusing reference to 'aliasing' could also be called spoofing. The template can be intentionally misused with certain magic values. For example, it interprets all of the following numeric values identically: 1001 == 0x3E9 == 01751 // the template converts all of these // (equivalent) values to decimal nine. Therefore... assert(binary_int<1001>::b == binary_int<01751>::b); would both compile and return true. But clearly, someone typing a value other than 1 or 0 in this template is misusing the template. The vast majority of numeric values that don't look like binary are rejected by the template and don't compile. I don't personally think the 'aliasing' aspect is any cause for alarm. If you use the template as intended it works well. And it is resistant to most misuses, just not all of them. Scott Schurr

1 0

Boost regression notification (2005-07-14)
by Douglas Gregor 14 Jul '05

14 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-14T15:02:22Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 299 failures in 8 libraries: io (1) parameter (13) program_options (3) random (2) serialization (266) spirit (3) test (6) wave (5) |io| ios_state_unit_test: intel-win32-8_1 |parameter| basics: gcc-3.2.3-linux gcc-3_3-darwin intel-win32-8_1 intel-win32-8_1 macros: gcc-3.2.3-linux gcc-3_3-darwin intel-win32-8_1 intel-win32-8_1 sfinae: gcc-3.2.3-linux gcc-3_3-darwin intel-win32-8_1 intel-win32-8_1 msvc |program_options| unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 vc-7_1 vc-8_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 test_non_default_ctor2_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor2_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor2_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor2_text_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor2_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux test_non_default_ctor2_text_warchive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor2_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor2_xml_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor2_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor2_xml_warchive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor_text_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux test_non_default_ctor_text_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor_xml_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_intrusive_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_intrusive_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_intrusive_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_intrusive_text_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_intrusive_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux test_non_intrusive_text_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_intrusive_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_intrusive_xml_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_intrusive_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_non_intrusive_xml_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux test_shared_ptr_132_binary_archive: borland-5_6_4 test_shared_ptr_132_binary_archive_dll: borland-5_6_4 test_shared_ptr_132_text_archive: borland-5_6_4 test_shared_ptr_132_text_archive_dll: borland-5_6_4 test_shared_ptr_132_text_warchive: borland-5_6_4 test_shared_ptr_132_text_warchive_dll: borland-5_6_4 test_shared_ptr_132_xml_archive: borland-5_6_4 test_shared_ptr_132_xml_archive_dll: borland-5_6_4 test_shared_ptr_132_xml_warchive: borland-5_6_4 test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 |spirit| action_tests: gcc-3_4_3-sunos action_tests_debug: gcc-3_4_3-sunos owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |wave| testwave: cw-8_3 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3_4_3-sunos

1 0

Re: [boost] [regex and string algo] again strange split behaviour
by Jan Hermelink 14 Jul '05

14 Jul '05

> It looks more like a bug than by design if you ask me. I don't think so - this behaviour is specified in the standardization proposal. To quote from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1429.htm, Chapter "RE.8.2 Template class regex_token_iterator": "If the end of sequence is reached (regex_search returns false), the iterator becomes equal to the end-of-sequence iterator value, unless the sub-expression being enumerated has index -1: In which case the iterator enumerates one last string that contains all the characters from the end of the last regular expression match to the end of the input sequence being enumerated, provided that this would not be an empty string." !!! "provided that this would not be an empty string" !!! > I don't agree. > I think this is counterintuitive, both for string_algo and regex May be, but the above described behaviour has a good change to be standardized, and boost::split() should do the same thing. Jan -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thore Karlsen Posted At: Wednesday, July 13, 2005 6:03 PM Posted To: Boost Developer Conversation: [boost] [regex and string algo] again strange split behaviour Subject: Re: [boost] [regex and string algo] again strange split behaviour On Wed, 13 Jul 2005 16:42:06 +0200, "Jan Hermelink" <Jan.Hermelink(a)metalogic.de> wrote: >The 1.32 behaviour is compatible with Boost.Regex: > >boost::regex_token_iterator in splitting mode returns for > >"abc/abc/" -> 2 tokens > >This is compatible with the regex standardization proposal. > >I think the behaviour of boost::split should be the same. I don't agree. I think this is counterintuitive, both for string_algo and regex. It looks more like a bug than by design if you ask me. -- Be seeing you. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

5 4

Re: [boost] [regex and string algo] again strange split behaviour
by Jan Hermelink 14 Jul '05

14 Jul '05

The 1.32 behaviour is compatible with Boost.Regex: boost::regex_token_iterator in splitting mode returns for "abc/abc/" -> 2 tokens This is compatible with the regex standardization proposal. I think the behaviour of boost::split should be the same. Regards, Jan -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Slapeta Posted At: Wednesday, July 13, 2005 3:13 PM Posted To: Boost Developer Conversation: [boost] [string algo] again strange split behaviour Subject: [boost] [string algo] again strange split behaviour hi, I assume the behaviour of boost::split not to return the last token has been changed (in CVS). However, a side effect seems to be that there is also one token returned for _empty_ strings, which is very questionable IMO! summary (if '/' is the separator): boost 1.32: "" -> 0 tokens "abc/abc" -> 2 tokens "abc/abc/" -> 2 tokens CVS: "" -> 1 token (!) "abc/abc" -> 2 tokens "abc/abc/" -> 3 tokens should be IMO: "" -> 0 tokens "abc/abc" -> 2 tokens "abc/abc/" -> 3 tokens Thoughts? Stefan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

5 7

[Parameter] instance() causing lots of failures
by Douglas Gregor 14 Jul '05

14 Jul '05

Lines like this: keyword<name_>& name = instance(); are causing failures on lots of compilers. It looks like the workaround is simple, but we need to apply it to the platforms that are still failing... Doug

3 3

[Boost-bugs] [ boost-Bugs-1238306 ] shared_ptr_basic_tests warnings on linux
by SourceForge.net 14 Jul '05

14 Jul '05

Bugs item #1238306, was opened at 2005-07-14 09:14 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=1238306&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: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: shared_ptr_basic_tests warnings on linux Initial Comment: 1. warning: `struct X' has virtual functions but non-virtual destructor Resolution: add virtual keyword to destructor 2. warning: `struct Y' has virtual functions but non-virtual destructor Resolution: same as above ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1238306&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1238293 ] shared_from_this warnings on linux
by SourceForge.net 14 Jul '05

14 Jul '05

Bugs item #1238293, was opened at 2005-07-14 08:48 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=1238293&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: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: shared_from_this warnings on linux Initial Comment: 1. warning: `class X' has virtual functions but non-virtual destructor Resolution: add virtual keyword to destructor 2. warning: `class Y' has virtual functions but non-virtual destructor Resolution: same as above 3. warning: `class impl' has virtual functions but non-virtual destructor Resolution: add virtual destructor 4. warning: `class impl2' has virtual functions but non-virtual destructor Resolution: item [3] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1238293&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[parameter] ArgumentPack + macros
by Cromwell Enage 14 Jul '05

14 Jul '05

Whatever the final name of the concept is, shouldn't the template parameter type used by BOOST_PARAMETER_FUN and BOOST_PARAMETER_MEMFUN be called by this name? Cromwell D. Enage ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

2 2

[Boost-bugs] [ boost-Bugs-1238285 ] shared_ptr tests have warnings on linux
by SourceForge.net 14 Jul '05

14 Jul '05

Bugs item #1238285, was opened at 2005-07-14 08:36 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=1238285&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: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: shared_ptr tests have warnings on linux Initial Comment: 1. warning: `class n_spt_abstract::X' has virtual functions but non-virtual destructor Resolution: add virtual keyword to destructor 2. warning: `class n_spt_shared_from_this::X' has virtual functions but non-virtual destructor Resolution: add virtual keyword to destructor 3. warning: `class n_spt_shared_from_this::Y' has virtual functions but non-virtual destructor Resolution: add virtual keyword to destructor 4. warning: `class n_spt_shared_from_this::impl' has virtual functions but non-virtual destructor Resolution: same as above Might I suggest that the Boost community crank up their warning levels and clean up their code too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1238285&group_… ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Range] terminology
by David Abrahams 14 Jul '05

14 Jul '05

I note that http://www.boost.org/libs/range/doc/range.html uses the term "closed-open range." The term used in prior art is "half-open range." Is there a good reason to invent new terminology here? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 3

[filesystem] Windows 9X support?
by Beman Dawes 14 Jul '05

14 Jul '05

There have been two recent reports of Boost.Filesystem failures on Window 98. One involved Win98 using slightly different rules for network paths, the other was use of an unsupported function. The change to fix the first problem is very simple, but pervasive. It also applies only to the current version - the code is different for the i18n version, so will need to be tested again even if a change to the current version works OK. The second problem really needs testing, probably under a debugger. The full regression tests should also be run to ensure that more than one function isn't involved. I realize that those having to support legacy machines would like Boost.Filesystem to support Win 9X. But I don't really see any way to support 9X without some time consuming testing and debugging effort. But I just don't have the time and other resources to do that. So unless someone else volunteers to run Win 9X tests, debug problem reports, and submit patches, I'm not planning to try to support Win 9X. If anyone out there cares enough to volunteer some time and effort, please let me know. Thanks, --Beman

1 0

[regex] regex_replace with format string replaced as it is
by Lorenzo Bettini 14 Jul '05

14 Jul '05

Hi when I use template <class traits, class Allocator, class charT> basic_string<charT> regex_replace(const basic_string<charT>& s, const basic_regex<charT, traits, Allocator>& e, const basic_string<charT>& fmt, match_flag_type flags = match_default); is there a way to make the fmt string be substituted as IT is? I mean if I specify "(\\)", for instance, I want that actually those four characters to be substituted for the occurrences of e in s, without any interpretation of ( and \. Of cource I could escape both ( and \, but I was wondering if there's an option to avoid this. thanks in advance Lorenzo

3 16

[Boost-bugs] [ boost-Bugs-1238243 ] shared_ptr/weak_ptr tests are not C++ spec compliant
by SourceForge.net 14 Jul '05

14 Jul '05

Bugs item #1238243, was opened at 2005-07-14 07:30 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=1238243&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: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Peter Dimov (pdimov) Summary: shared_ptr/weak_ptr tests are not C++ spec compliant Initial Comment: Please refer to the latest C++ spec (Second edition, 2003-04-01), section 12.8.15, "Copying class objects". Look at your source code in test/weak_ptr_test.cpp. 1. You cannot assume the reference count of the shared_ptr going into the copy_assignment function is one. The spec says that compilers are allowed to make an optimization to eliminate a copy, but not mandated to do so. This means that the effective reference count upon entry to the function may be two, not one. To correct your unit tests, forcibly create a local object that you pass by value to guarantee the reference count is two upon entry for all compilers. To respond to the following email address, remove all capital Z's. rZoZbZeZrZt.bZuZcZk(a)mathworks.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1238243&group_… ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Web page with compiler macros and versions
by Edward Diener 14 Jul '05

14 Jul '05

I want to create a web page for Boost in which each compiler supported by Boost is listed with the name of the preprocessor which needs to be examined to determine the compiler version, and the numbers, in hex or decimal, which correspond to each version. The web page would be in the form of a simple table, but any good CSS expert can spruce it up. Currently I have on my Windows machine, Microsoft VC6, VC7, VC7.1, Borland BCB3, BCB4, BCB5, and BCB6, and Comeau 4.3.3. I need information about any other Windows compiler/versions which Boost supports as well as information about any Linux compilers and other compilers. Responses from those who do regression tests for other compilers would certainly be helpful, or perhaps the reuslts of indivbidual regression tests, such as config_info.cpp, which I believe tells that information, are available.

2 4

Re: [boost] [regex and string algo] again strange split behaviour
by Jan Hermelink 14 Jul '05

14 Jul '05

<Jan.Hermelink(a)metalogic.de> wrote: >> It looks more like a bug than by design if you ask me. >I don't think so - this behaviour is specified in the standardization >proposal. >To quote from >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1429.htm, >Chapter "RE.8.2 Template class regex_token_iterator": > >"If the end of sequence is reached (regex_search returns false), the >iterator becomes equal to the end-of-sequence iterator value, unless the >sub-expression being enumerated has index -1: In which case the iterator >enumerates one last string that contains all the characters from the end >of the last regular expression match to the end of the input sequence >being enumerated, provided that this would not be an empty string." > >!!! "provided that this would not be an empty string" !!! > How about this string: "/abc/abc". > Would this result in "", "abc", "abc"? Yes > Yet "abc/abc/" would result in "abc", "abc"? Yes > That seems terribly unbalanced to me, and this is not the behavior I would expect. Yes, you may have a point here. Or is it somewhat modeled after the C++ initializer syntax: { a, b, } is the same as { a, b } but { , a, b } isn't the same ... Maybe John can commence? Jan

4 3

Re: [boost] New Library Proposal: dual_state
by Jost, Andrew 14 Jul '05

14 Jul '05

<clip> > > Adapters don't have to require copyable objects. A > specialization can deal with noncopyable objects by replacing > requirement to underlying type to be copyable with > requirement to client code to accept const references and > don't require identity semantic. Also, the adapter should > live until it's default value is used somewhere. > > Here is pseudo-code: > > ------- > const T & adapter<T>::adapter(<constructor_parameters>) : > default_value_member(<constructor_parameters>) > { > } > > const T & adapter<T>::adapt(const T & value_to_adapt) { > return value_to_adapt ? value_to_adapt : default_value_member; } > ------- > > I think because this flavour of adapter manages the lifetime > of contained default value, it's possible to build a version > which would manage a container of multiple "default" objects > and would enable identity semantic and remove const > requirement. I don't think if this exotic case will be useful though. > I agree. Difficult as it was to find real cases that could use even a simple adapter, a multi-default adapter would seem to be a rare thing. > Also it's possible to decouple the adapter from its managed > default value object by using > > MO managed_object; > // accepts, stores and returns a reference adapter<MO> > f(managed_object); > > Also default values don't have to be constants. Default > objects can be generated by a generator object (which > produces values) or by a factory (which produces identities > and may allocate memory). For example, sometimes a random or > "next free" default value can be useful. Like in case of > bind() TCP socket function with optional port number. > Yes, a generator or factory would help if it decouples the adapter's interaction with the optional object. > And finally, it's possible to relax the requirements to both > underlying objects (T) and client code (loadPoint) by storing > a reference to an inplace factory inside of Optional objects, > but as a price for this improvement we are back to that > "metadata binding sin" then. Sorry, I don't fully understand. > > Or we can allow adapters simply to modify underlying objects: > > adapter<MO> f(<inplace factory for default values>); > > What do you think about all these proposed adapter designs? > > Andrey > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Boost regression notification (2005-07-13)
by Douglas Gregor 14 Jul '05

14 Jul '05

Boost regression test failures ------------------------------ Report time: 2005-07-13T15:12:24Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 365 failures in 9 libraries: date_time (2) io (1) parameter (22) program_options (3) random (2) serialization (321) spirit (1) test (6) wave (7) |date_time| testlocal_time_input_facet: cw-9_4 testtime_input_facet: cw-9_4 |io| ios_state_unit_test: intel-win32-8_1 |parameter| basics: gcc-3.2.3-linux gcc-3_3-darwin intel-win32-8_1 intel-win32-8_1 vc-8_0 macros: gcc-3.2.3-linux gcc-3_3-darwin intel-win32-8_1 intel-win32-8_1 sfinae: borland-5_6_4 cw-8_3 cw-9_4 cw-9_4 gcc-3.2.3-linux gcc-3_3-darwin gcc-3_4_3-sunos intel-win32-8_1 intel-win32-8_1 msvc vc-6_5 vc-6_5-stlport vc-7_0 |program_options| unicode_test_dll: cw-9_5-darwin gcc-3_3-darwin gcc-3_3-darwin |random| random_test: intel-win32-8_1 intel-win32-8_1 |serialization| test_class_info_load_binary_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_binary_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_archive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_text_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux vc-6_5 test_class_info_load_xml_archive: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_archive_dll: gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_class_info_load_xml_warchive_dll: cw-9_5-darwin gcc-3.3.6-linux gcc-3.4.4-linux test_const_load_fail1: borland-5_6_4 test_const_load_fail1_nvp: borland-5_6_4 test_const_load_fail2: borland-5_6_4 test_const_load_fail2_nvp: borland-5_6_4 test_const_save_fail1: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail2: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_const_save_fail3: msvc vc-6_5 vc-6_5-stlport vc-7_0 test_demo_dll: cw-9_4 cw-9_4 test_demo_exception_dll: cw-9_4 cw-9_4 test_demo_fast_archive_dll: msvc vc-6_5 test_demo_pimpl_dll: msvc vc-6_5 vc-7_0 test_demo_portable_archive: intel-win32-8_1 intel-win32-8_1 vc-7_0 vc-7_1 vc-8_0 test_demo_portable_archive_dll: borland-5_6_4 intel-win32-8_1 intel-win32-8_1 test_demo_shared_ptr: cw-9_4 cw-9_4 cw-9_5-darwin test_demo_shared_ptr_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 vc-7_0 test_diamond_binary_archive: cw-8_3 cw-9_5-darwin test_diamond_binary_archive_dll: cw-9_5-darwin test_diamond_text_archive: cw-8_3 cw-9_5-darwin test_diamond_text_archive_dll: cw-9_5-darwin test_diamond_text_warchive: cw-8_3 cw-9_5-darwin test_diamond_text_warchive_dll: cw-9_5-darwin test_diamond_xml_archive: cw-8_3 cw-9_5-darwin test_diamond_xml_archive_dll: cw-9_5-darwin test_diamond_xml_warchive: cw-8_3 cw-9_5-darwin test_diamond_xml_warchive_dll: cw-9_5-darwin test_map_binary_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_archive_dll: msvc vc-6_5 vc-7_0 test_map_text_warchive_dll: msvc vc-6_5 vc-7_0 test_mult_archive_types: cw-9_4 cw-9_4 cw-9_5-darwin test_mult_archive_types_dll: cw-9_4 cw-9_4 cw-9_5-darwin msvc vc-6_5 test_non_default_ctor2_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_text_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux vc-7_1 test_non_default_ctor2_text_warchive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_xml_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor2_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 test_non_default_ctor2_xml_warchive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_text_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux vc-7_1 test_non_default_ctor_text_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_xml_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_default_ctor_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 test_non_default_ctor_xml_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_binary_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_binary_archive_dll: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_text_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_text_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_text_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux vc-7_1 test_non_intrusive_text_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_xml_archive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_xml_archive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_non_intrusive_xml_warchive: gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 test_non_intrusive_xml_warchive_dll: cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-4.0.0-linux intel-8.1-linux vc-7_1 vc-8_0 test_polymorphic_xml_archive: vc-8_0 test_shared_ptr_132_binary_archive: borland-5_6_4 test_shared_ptr_132_binary_archive_dll: borland-5_6_4 test_shared_ptr_132_text_archive: borland-5_6_4 test_shared_ptr_132_text_archive_dll: borland-5_6_4 test_shared_ptr_132_text_warchive: borland-5_6_4 test_shared_ptr_132_text_warchive_dll: borland-5_6_4 test_shared_ptr_132_xml_archive: borland-5_6_4 test_shared_ptr_132_xml_archive_dll: borland-5_6_4 test_shared_ptr_132_xml_warchive: borland-5_6_4 test_shared_ptr_132_xml_warchive_dll: borland-5_6_4 |spirit| owi_mt_tests: gcc-3_3-darwin |test| errors_handling_test: cw-9_5-darwin vc-8_0 test_fp_comparisons: borland-5_6_4 test_tools_test: cw-9_4 cw-9_4 cw-9_5-darwin |wave| test_re2c_lexer: cw-9_4 test_slex_lexer: cw-9_4 testwave: cw-8_3 cw-9_4 cw-9_5-darwin gcc-3.2.3-linux gcc-3.3.6-linux

2 1

Re: [boost] [regex and string algo] again strange split behaviour
by Jan Hermelink 13 Jul '05

13 Jul '05

> The only reasonable thing is for split to return N+1 pieces for a string > with N separators, if you ask me. :-) This is lossless in the sense that it > allows you to reconstruct the original string. The non-reasonable behavior > can easily be implemented on top of that, but not vice versa. In fact you can implement the "non-reasonable behavior" on top the "reasonable behavior" with help of boost::sub_match : std::vector<std::string> result; std::string s = "abc/abc/"; boost::regex sep = "/"; boost::sregex_token_iterator tok(s.begin(), s.end(), sep, -1); boost::sregex_token_iterator last; boost::sub_match<boost::sregex_token_iterator> sm; for (; tok != last; ++tok) { sm = *tok; result.push_back(sm); } if (sm.second != s.end()) result.push_back(std::string()); But in the meantime I'm thinking too this should be the default behaviour. Jan

1 0

[string algo] again strange split behaviour
by Stefan Slapeta 13 Jul '05

13 Jul '05

hi, I assume the behaviour of boost::split not to return the last token has been changed (in CVS). However, a side effect seems to be that there is also one token returned for _empty_ strings, which is very questionable IMO! summary (if '/' is the separator): boost 1.32: "" -> 0 tokens "abc/abc" -> 2 tokens "abc/abc/" -> 2 tokens CVS: "" -> 1 token (!) "abc/abc" -> 2 tokens "abc/abc/" -> 3 tokens should be IMO: "" -> 0 tokens "abc/abc" -> 2 tokens "abc/abc/" -> 3 tokens Thoughts? Stefan

4 6