- Boost - lists.preview.boost.org

[threads] final decision on making parts of Boost.Threads header-only
by JOAQUIN M. LOPEZ MUÑOZ 04 Jun '09

04 Jun '09

Hi, A few weeks ago we had a discussion about the convenience of making part of Boost.Threads, namely mutexes and locks, header-only. Some (including Anthony Williams) supported the idea, others disliked it: http://lists.boost.org/Archives/boost/2009/04/150524.php What the final decision on this issue is? If positive (i.e. favoring the change), can it be expected to be done for Boost 1.40? As a remainder, I've created an associated trac ticket: https://svn.boost.org/trac/boost/ticket/2964 Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

boost trac for upcoming libraries?
by Barend Gehrels 04 Jun '09

04 Jun '09

Hi, Is the Boost Trac system intended for official libraries only, or can we also use it for (to be) proposed libraries? Thanks, Barend

6 6

Discussion on compilation-error-when-using-ptr-container
by Eric Niebler 04 Jun '09

04 Jun '09

You should direct questions to boost(a)lists.boost.org.

1 0

[lexical_cast] Locale used during conversion
by Adam Badura 04 Jun '09

04 Jun '09

lexical_cast does not allow to pass the locale to be used during conversion. This is justified with analogy of lexical_cast to other casts which all take only one parameter. So lexical_cast always uses the current global locale. A reasonable choice. However I wanted to propose some additional features. It would be useful to provide (lets call it so for now) classic_lexical_cast which would use std::locale::classic() instead of the global one. I just finalized globalization/localization of our application by adding setting of the global locale to appropriate value according to the selected language. I noticed that all of sudden serialized data (mainly projects) stopped loading/saving correctly. The reason was easy to find. Where previously we had XML node named "item1000" we now have "item1,000" in English or "item1 000" in Polish for example. The projects are no longer interchangeable between applications running in different language version. I corrected this by adding our own lexical_cast which resets the global locale to the classic one, calls boost::lexical_cast and finally resets the global locale back. This special cast is used now whenever we are dealing with texts which are not presented to the final user. This works fine however it seems that resetting the global locale often (each time we save a number in the project for example...) is causing significant performance overhead. (Exact tests have not been yet performed but this seems the only change which might have affected all serialization slowdown.) I might reset it before saving the project and then save the project as usually but this is not very handy as I would have to remember to do it each time I am serializing any data. Also other problems are implied. Other threads for the short period of time see different global locale as well and thus might produce bad strings. And in the end it is impractical. It would be handy to have classic_lexical_cast as well as it could introduce some optimizations knowing that the requested locale is the classic one. Another thing is that it would be handy to introduce a function textual_convert (another example name) which would act like lexical_cast but would take the requested locale as a parameter (this is no longer a cast so it may). lexical_cast might take that locale as a second parameter with default value being the global locale so it could still be used just as any other casting. But I suppose this would not be well seen. Thus why not introduce a different function for that (or maybe there already is one?). It seems those changes would not be difficult to implement and could be hidden in the details of lexical_cast easily. What do you think of that? Finally lexical_cast's documentation might mention explicitly that current global locale is used as it does not mention that if I am not mistaken (I haven't found "locale" word in that document). Adam Badura

3 6

Bug Sprint Report for Wednesday, June rd
by Marshall Clow 04 Jun '09

04 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. Wednesday was not a good day in terms of bug closing; the good news is that we've already (as of 6 AM) closed more bugs on Thursday than all of Wednesday. Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. 6:00 AM PDT 6/4: 739 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. 6/3 4 new tickets, 19 modifications, 2 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. There are 35 tickets that are still open that are marked as "to be fixed in Boost 1.36" See <https://svn.boost.org/trac/boost/report/3> for a list of open tickets by milestone. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Trac unwell?
by Vladimir Prus 04 Jun '09

04 Jun '09

Hi, it looks like Trac is not feeling very well: 1. Opening an issue takes at least 10 seconds, sometimes a minute. 2. Adding a comment to an issue takes equally weird time. 3. From time to time it gives: "Database locked" errors. The page with the error does not have any additional information. Can somebody look into this? - Volodya

5 6

Ticket #637 - Adjusts mpl::pair concept to be compatible with STL pairs
by Joel Falcou 04 Jun '09

04 Jun '09

https://svn.boost.org/trac/boost/ticket/637 Is this feature request still sensible or does fusion make this useless somehow ? If not, I can provide patch+test -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

4 4

trunk vs release
by troy d. straszheim 04 Jun '09

04 Jun '09

From another thread: Steven Watanabe wrote: > AMDG > > troy d. straszheim wrote: >> I've been wondering a bit about this in-syncness recently. >> >> - Does anybody know offhand what the last release was that was >> branched directly from trunk? >> >> - Is there a way to determine, with SVN, how many lines of diff >> there are between trunk and release? I've tried without >> success.... the diff gets to ~80k lines and then the network times >> out. I wonder if I'm doing something wrong. Of course I can get >> some numbers with git but I'm not quite sure I trust them yet. >> >> % git diff --shortstat svn/release svn/master 3505 files changed, >> 209061 insertions(+), 58428 deletions(-) > > This is probably correct as far as it goes. However, it's hard to > tell how much it really means. About half the modified files seem to > be generated html, judging by the output of > > svn diff https://svn.boost.org/svn/boost/branches/release > https://svn.boost.org/svn/boost/trunk --summarize > Hm, that svn command isn't very helpful and runs for ~5 minutes. I'm seeing about 160k lines total changed in actual code (.cpp, .ipp, .hpp). Full report in case anybody is interested: http://sodium.resophonic.com/trunk_vs_release.txt Poking around it looks like the current release branch was created from the fixed 1.34.1 tag in oct 2007 (@ r40341). The 1.34.1 release was in turn branched from... looks like that goes back into the days of CVS, I'll consider it lost. Git maintains that the last common commit between the current trunk and release branches is > 3 years ago: http://gitorious.org/boost/svn/commit/4914d4934fbc7368e2d43e057f6fffdac0f46… So if the trunk is really just a staging area for merges to release, does the notion of having the release branch and trunk 'in sync' at this point make any sense? Why have just one such staging area? -t

13 74

[Serialization]#3118 basic_binary_oarchive.hpp - save_override possible loss of data warnings
by Jeff Flinn 04 Jun '09

04 Jun '09

I've posted the following ticket in light of the current bug sprint. ----------- The following save_override overloads cause possible loss of data warnings on MSVC8 and XCode3.1.2/gcc4.0.1 void save_override(const version_type & t, int) void save_override(const class_id_type & t, int) void save_override(const class_id_reference_type & t, int) with their respective assignments: const unsigned char x = t.t; const int_least16_t x = t.t; While a possible fix would be: const unsigned char x = static_cast<unsigned char>(t.t); const int_least16_t x = static_cast<int_least16_t>(t.t); there is still a possibility of a silent loss of data. We could be safer and use numeric_cast, but that would possibly impact code size and performance, and would introduce a library dependency. Why are the xxx_type strong typedef's using int rather than the smaller types that are being serialized? Any thoughts on the best solution? Thanks, Jeff

4 5

[Bug Sprint][random] overload resolution for constructors/seed
by Steven Watanabe 03 Jun '09

03 Jun '09

AMDG I'm looking at the following tickets: https://svn.boost.org/trac/boost/ticket/351 https://svn.boost.org/trac/boost/ticket/2887 https://svn.boost.org/trac/boost/ticket/2424 #351 and #2887 are effectively the same boost::mt19937 prng1; boost::mt19937 prng2(prng1); // does not call copy constructor #2424 is int seed = 0; boost::mt19937 prng1(seed); // doesn't compile #2424 can be fixed easily without breaking backwards compatibility. Fixing #351 and #2887 will silently change the meaning of the constructor call above. It will also be difficult to emulate the previous (documented) behavior. However, looking at the current standard draft, the constructor that causes these problems is not present, so the standard mersenne twister will have a well behaved copy constructor. Also, only lagged_fibonacci_01, mersenne_twister, and subtract_with_carry provide the offending constructor, so Boost.Random is not consistent. I'd like to have the copy constructor called. What do others think? When testing fixes, I found that rand48 behaves differently with an int64_t seed than with an int32_t seed. According to the current draft standard, they should be equivalent. Should rand48 be changed or should I leave it alone? In Christ, Steven Watanabe

2 2

[iostreams] #2406: implementation in header causes link errors
by Vladimir Prus 03 Jun '09

03 Jun '09

Looking at Trac, I've run into the bug above, which seems both fairly severe and easy to fix, so I took the liberty to commit a patch: https://svn.boost.org/trac/boost/changeset/53427 I've tested it on Linux. Can somebody give it a try on Windows? While I've added necessary BOOST_IOSTREAMS_DECL, I might have missed something. Thanks, Volodya

2 1

[parameter] Testing for existence of a parameter, building ArgumentPacks, more lazy return types
by Jeremiah Willcock 03 Jun '09

03 Jun '09

I have a few questions about the parameter library. Please note that I am using argument packs directly, since I am creating them from another data structure. 1. Is there a way to build Boost.Parameter ArgumentPacks from a program? I am currently using many internal data structures of Boost.Parameter (empty_arg_list and such). Is there another interface to use? 2. Is there a way to tell at compile-time whether a particular parameter exists in an ArgumentPack? I currently have a metafunction that uses a special default type and tests for that; is there a more "official" way? 3. I have a case where the default type for a named parameter cannot be instantiated in some cases where that parameter is given explicitly. The operator||() lazy defaults don't seem to work for that because they get the result_type member from my default right away, even if it won't be used. I currently have a hack to work around this using my parameter_exists test and some metaprogramming. The reason I am working on this low of a level is that I am playing with converting Boost.Graph named parameter structures into ArgumentPacks to have access to Boost.Parameter's nicer capabilities and syntax. I thus need to build all of the argument data structures and such within another function and then access them later. Thank you for your help. -- Jeremiah Willcock

2 5

[Modularization] A new approach to header modularization
by Beman Dawes 03 Jun '09

03 Jun '09

I've started to put together a wiki page based on our ongoing Header Modularization discussions. See http://svn.boost.org/trac/boost/wiki/HeaderModularization I listed eight approaches to meeting the Goals/Objectives/Needs/Wants, and was about to identify the weaknesses of each approach when I hit on approach nine: Move (permanently) each library's root/libs/libname contents into root/boost/libname for the library. In other words, instead of moving the boost/... tree headers to the libs/... tree, merge the libs/... tree into the boost/... tree. For example, Boost.Filesystem is currently organized like this: root/ boost/ filesystem.hpp filesystem/ config.hpp convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp libs/ filesystem/ build/ ... CMakeLists.txt doc/ ... example/ ... index.html ... module.cmake src/ ... test/ ... After the reorganization, filesystem would be organized like this: root/ boost/ filesystem.hpp filesystem/ config.hpp convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp build/ ... CMakeLists.txt doc/ ... example/ ... index.html ... module.cmake src/ ... test/ ... In theory, the root/libs/... tree isn't needed anymore. In practice we might want to keep a root/libs/libname/index.html entry for each library so docs links don't break. Apologies if someone already suggested this approach. It is so simple I can't believe someone didn't already suggest it. Unless I'm missing something, this is the only approach that appears to do fairly well for all of the Goals/Objectives/Needs/Wants, and very well for most of them. It would require some rework of scripts and other setups that depend on the current organization of libs/..., but that seems minor compared to the long-term benefits. Comments? --Beman

18 50

Attachments from old bug tracker
by Jeremiah Willcock 03 Jun '09

03 Jun '09

It appears that somebody attached patches to the equivalent of bug 900 (https://svn.boost.org/trac/boost/ticket/900) in the old bug tracker, and these patches were not moved over to the new tracker. Is it possible to get these attachments? -- Jeremiah Willcock

2 1

Re: [boost] boostcon videos?
by Chandrashekhar Kumar 03 Jun '09

03 Jun '09

> > does anyone know where can I get the videos of the presentations at >> boostcon? >> > > When they are available (i.e, when I finish working on them), I will post > here > detailing where they are. > > Note: Not all the presentations were videotaped. > Thanks! Just curious, was the presentation by Andrei(Iterators must go) was videotaped? and any chance to grab the videotapes(and the ppts) for earlier boostcons?

2 1

boostcon videos?
by Chandrashekhar Kumar 03 Jun '09

03 Jun '09

does anyone know where can I get the videos of the presentations at boostcon?

2 1

[Bug Sprint] What to do with "library submissions"?
by Marshall Clow 03 Jun '09

03 Jun '09

I'm not sure they belong in the Trac system; but where do they belong? I guess it depends on what's going to happen to them.... If they're additions to existing libraries, should they be "feature requests"? If they're new libraries, should they go in the sandbox? https://svn.boost.org/trac/boost/ticket/2749 https://svn.boost.org/trac/boost/ticket/2893 -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 1

Bug Sprint Report for Friday, May 29th
by Marshall Clow 03 Jun '09

03 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. We're off to a great start! Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added three new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> The following bugs appear to have been fixed, but the tickets were never closed. I would appreciate it if the library maintainers could verify this and close the tickets. https://svn.boost.org/trac/boost/ticket/145 Iterator https://svn.boost.org/trac/boost/ticket/287 date_time The following tickets are feature requests that are unlikely ever to be implemented. Should they be closed? https://svn.boost.org/trac/boost/ticket/558 database https://svn.boost.org/trac/boost/ticket/100 concept_check https://svn.boost.org/trac/boost/ticket/182 concept_check --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

3 3

[#1497] Ruling needed on tracker usage
by Beman Dawes 03 Jun '09

03 Jun '09

Dave is pressing to do something about this ticket: > Yes, please! Beman, please read the head of that thread: > http://thread.gmane.org/gmane.comp.lib.boost.devel/167139 > > IMO this is '''exceedingly''' important, and the only reason I'm not doing > it myself is that it seems to be the domain of the release managers. It > will be an especially huge missed opportunity if we don't get this > straightened out before the bug sprint. Oops! That starts today! We'd > better get moving. > > Again, if there's any way I can help, including writing the policy, please > let me know. By the way, I'm not attached to eliminating "to be > determined," if that helps in any way to resolve this. The concern of the thread mentioned was about milestones for 1.35.0. The same concern applies today, although the milestone numbers have changed. > [the milestone list] > shows all the tickets that have been assigned to the 1.35.0 milestone. > Does this list have any meaning? It doesn't for me, and hasn't since we went to a schedule-driven release system a year and a half ago. > In other words, are we actually > intending to address all of these problems for 1.35, and put off other > tickets for 1.35.1 or 1.36.0? > > IMO getting this list sorted out and handling the tickets one-by-one > is the most productive way to get us from here to a successful release > of 1.35.0. That may mean a number of new tickets need to be added > (probably at least one for each major failure we're seeing in > http://engineering.meta-comm.com/boost-regression/1_34_1/developer/issues.h… > and possibly others) and it will require part of the release team to > triage the whole list of tickets assigned to 1.35.0 and make some > decisions to put certain tickets off for later. In an organization with paid developers and paid managers, it might be possible to look at the tickets, look at the people and other resources available, assign milestone priorities accordingly, and then use progress on clearing them as a metric to guide release activities. But I'm at a loss for how we could use such milestones for Boost. So any ideas would be appreciated if folks think the milestones do have a place in Boost's process of getting releases out. --Beman

3 2

[profile_templates] minor issue + patch
by Jonathan Franklin 03 Jun '09

03 Jun '09

Steven, I was playing around w/ the profile_templates tool on my Ubuntu box (Jaunty Jackelope - 9.04), and wasn't getting any results. After a little investigation, I discovered that the regex that postprocess.cpp uses for the enter_message wasn't matching the warning that my gcc compiler (4.3.3) was spitting out. Turns out that the regex is looking for a single char here: (.*): warning: .int -----------------^ But I'm getting a unicode E28098 (left single quotation mark), which is 3 chars, hence the failure to match. Being somewhat content w/ my terminal settings (and lazy to boot), I just modified the regex to match .+int instead of .int, and it *seems* to work fine. I think I have a sandbox account, and can commit the attached patch if you like the fix. Jon

2 2

Bug Sprint Report for Tuesday, June 2nd
by Marshall Clow 03 Jun '09

03 Jun '09

The boost bug sprint started Friday, May 29th, and runs through Sunday June 7th. We slowed down a lot on Tuesday - let's pick it up again. Status <https://svn.boost.org/trac/boost/report/1> 7:00 AM PDT 5/29: 797 open tickets. 7:45 AM PDT 5/30: 772 open tickets. 6:00 AM PDT 5/31: 761 open tickets. 6:00 AM PDT 6/2: 747 open tickets. 6:00 AM PDT 6/3: 748 open tickets. Activity: 5/29: 6 new tickets, 77 modifications, 25 tickets closed 5/30: 2 new tickets, 42 modifications, 17 tickets closed 5/31: 2 new tickets, 27 modifications, 8 tickets closed 6/1: 2 new tickets, 42 modifications, 17 tickets closed 6/2: 5 new tickets, 18 modifications, 5 tickets closed. [ Numbers may not add up because I am counting via two different methods, using data that is time-stamped in two different time zones. Also, tickets can be closed and reopened. ] What can you do? See <https://svn.boost.org/trac/boost/wiki/BugSprintJune2009> for details. I've added four new reports to the trac: Open ticket count by owner: <https://svn.boost.org/trac/boost/report/18> Open ticket count by component: <https://svn.boost.org/trac/boost/report/19> Open ticket count by ticket type: <https://svn.boost.org/trac/boost/report/20> Open ticket count by milestone: <https://svn.boost.org/trac/boost/report/21> There's been a lot of discussion on the list about tickets; and there are about a dozen patches that have been tested and are ready to be applied. If you're looking to help, you can look at some of the older bugs, say, the ones for Boost 1.36, and determine if they still apply. If they do, note that in the ticket. There are 35 tickets that are still open that are marked as "to be fixed in Boost 1.36" See <https://svn.boost.org/trac/boost/report/3> for a list of open tickets by milestone. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Unicode: what kind of binary compatibility do we want?
by Mathias Gaunard 03 Jun '09

03 Jun '09

As I am finishing putting property look-up together for the Unicode library GSoC, I am wondering what kind of binary compatibility it should aim for. The work from Graham Barnett back in 2005 defined an abstract base class with virtual functions for every unicode-related feature but I believe that's overkill. Basically, the current property design I have is like this struct some_property { enum type { some_default, some_value1, some_value2, ... _count; } }; some_property::type get_some_property(char32 ch); With get_some_property a simple look-up in the table, but the table layout being version dependent it would need to be in the library TUs. However, a new version of the library may return a value that is not within the enum. Should it then work like this? some_property::type get_some_property(char32 ch) { some_property::type p = get_some_property_impl(ch); if(p >= some_property::_count) return some_property::some_default; return p; } some_property::type get_some_property_impl(char32 ch); Is that suitable? Or do we want more/less flexibility? Apart from that, expect a documentation update by the end of the week.

5 7

[parameter] Bug 3114
by Jeremiah Willcock 03 Jun '09

03 Jun '09

I submitted bug 3114 (https://svn.boost.org/trac/boost/ticket/3114) with a preliminary patch to implement my feature request several days ago, and have not yet received a response. I believe that this feature would make Boost.Parameter much more useful for certain use cases, especially in libraries such as Boost.Graph where the defaults for named parameters may use templates that cannot be instantiated or do not include required members in some cases when users specify explicit arguments to a function. I made sure not to change the interface for existing default handlers by requiring a special tag to enable the new interface on a handler-by-handler basis. Could I please have the patch examined, generalized to more platforms, and possibly applied? Thank you. -- Jeremiah Willcock

2 1

[Bug Sprint][smart_ptr] #398
by Steven Watanabe 02 Jun '09

02 Jun '09

AMDG It looks like https://svn.boost.org/trac/boost/ticket/398 can just be closed? In Christ, Steven Watanabe

1 0

boost.timer library submission...
by JohnQ 02 Jun '09

02 Jun '09

While using Boost for a recent project, I needed a timer class that would allow me to set a time in the future at which some data would be handed back to me via callback. It had to be thread-safe, boost friendly, and allow for deletion of timers after they were set but before they expired. I took a look at the Timer library that Beman had submitted but that didn't appear to satisfy my needs, so I wrote one. I think this type of library is a fairly common request... while looking for one I saw a number of people also looking for the same thing... so I'm hoping this fills a gap. In addition, I'm hoping that peer review will help increase the robustness of this library to the benefit of all. Where do I begin for submitting it? Thanks, John Q.

5 4