headers
David Abrahams | 1 Dec 01:35
Picon
Picon
Favicon
Gravatar

Re: Breaking existing libraries


on Mon Nov 24 2008, "Tomas Puverle" <Tomas.Puverle-AT-morganstanley.com> wrote:

>> Aside from skirmishes over the meaning of life, I thought the opposite.
>
> This isn't intended as a jibe, but what do you think is the outcome of the 
> discussion so far?
>
> It seems like we've agreed on nothing.  

You didn't seem to take Thorsten's offer very seriously.

> Nothing is changing.  

"nothing has changed yet" != "nothing is changing"

> I don't feel like we've achieved much.

I believe we've achieved some understanding about the problem and the
specifics of the new and old designs.

> My only hope is that at least people will be more mindful of changing
> things in the future.  At least that would be some kind of result.

Yes it would.  But I think we can reasonably hope to do better than that.

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Abrahams | 1 Dec 01:37
Picon
Picon
Favicon
Gravatar

Re: Breaking existing libraries


on Mon Nov 24 2008, "Tomas Puverle" <Tomas.Puverle-AT-morganstanley.com> wrote:

>> suppose we set up a mailing list
>> to which all the test checkins are posted?  Then anyone who wants to
>> monitor the evolution of a library's tests can subscribe to that list.
>
> Dave, I don't know how much email you get a day but this doesn't sounds 
> workable.

Along with filtering rules, it can be managed.

> It's bad enough to try to keep up with the users and devel traffic, let 
> alone with extra emails whenever the developer decides to change a test 
> case.
>
> This cannot be automated - I would argue that it should be the 
> responsibility of the library maintainer to let the users know of any large 
> impeding changes.

Of course it is, but the suggestions to which I responded seemed not to
be aimed at leaving it _entirely_ in the hands of the maintainers.

--

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hartmut Kaiser | 1 Dec 02:14
Picon
Gravatar

[Review] UUID library (mini-)review ends today, November 30rd

Hi all,

the review of Andy Tompkins' UUID library ends today, November 30th.
Nevertheless, it's still possible to submit a review for at least a week, as
I'm not going to have time for the analysis of the review before Christmas.

Thanks to all of you who submitted a review.

Regards Hartmut
Review Manager
Permalink | Reply | 0 comments |
headers
Jeff Garland | 1 Dec 02:59
Picon

Re: [date_time] Internal header testfrmwk.hpp

A little late, but yes I'm reading it.  Moving it to test is fine as your
analysis is correct, it isn't used in the library implementation just the
test.

Jeff

On Sat, Nov 22, 2008 at 4:32 AM, Andrey Semashev
<andrey.semashev <at> gmail.com>wrote:

> Hi,
>
> There is a testfrmwk.hpp header in the boost/date_time directory. This
> header contains some utility to aid testing of the library and I believe is
> not a part of the library interface (that is, it's not in boost namespace
> and I don't see it documented). I don't know why the header resided in the
> boost/date_time directory in the first place, so I intend to move it into
> the test directory. Does anyone have objections? (Jeff, I hope, you're
> reading this)
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Andy Tompkins | 1 Dec 06:02
Favicon
Gravatar

Re: [Review] UUID library (mini-)review starts today, November 23rd

On Sat, 29 Nov 2008 00:14:47 +1100, "Vladimir Batov"
<batov <at> people.net.au> said:
> Andy,
>
> Thank you for taking the criticism the right way and my apologies if
> some of my comments sound(ed) somewhat harsh. It is never my
> intention. I won't be addressing the points below directly as some
> issues I raised are petty (and I somewhat wish I did not raise them).
> I admit I felt uneasy with the proposal but could not pin-point what
> it was. I'll try again.

No offense taken.  I value the criticism.  It gave my a lot to think 
about.

> Background: We are in our project currently using uuid facility
> heavily and very dependent on it. The version we use (from memory) is
> something like (it's not necessarily exactly what we use and I'll omit
> some scaffolding and stick with the basics):
>
> struct uuid : public std::string
> {
>     typedef std::string base;
>     uuid() : base(generate()) {}
>     explicit uuid(string const& s) : base(s) {}
>     static uuid null() { return uuid(std::string()); }
>   private:
>     std::string generate();
> };
>
> On Linux the generate() function calls uuid_generate(). No one (in our
(Continue reading)

Permalink | Reply | 2 comments |
headers
Anthony Williams | 1 Dec 09:45
Picon

Re: [Boost.Thread] ids obtained from the same thread not equal

Karp Dantax <karpdantax <at> yahoo.com.br> writes:

> Using boost::thread::get_id() in an executable and one of its DLLs
> generate different ids although the calls are made from the same
> thread. Until Boost 1.34.1, which used GetCurrentThreadId() to compare
> two boost::thread objects, it worked perfectly. I have not delved into
> the code, but now that the library is using thread local storage to
> store the current thread id, it is not working in the context
> mentioned above.
>
> Well, thats it. Maybe i am missing something here?

If you wish to use the thread library from the main executable and a
DLL and have everything work nicely together, you need to use the DLL
build of Boost.Thread. If your main EXE and DLL use Boost.Thread
internally, but entirely separately, then you can statically link to
the thread library independently in each.

Anthony
--

-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams

Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arno Schödl | 1 Dec 10:19
Favicon

Re: [Iterator][MultiIndex]iterator-specificpartition_point-relatedfunctions

>> using std::lower_bound;
>> CustomIt itA, itB;
>> lower_bound( itA, itB );
>>
>> Do we agree that this is how the client side should work?
>No, I don't think so.  I'm not sure exactly the implications but at
>first glance it looks too clever by half.

How is that clever? It follows the same pattern as the one for a custom swap:

using std::swap;
CustomType tA, tB;
swap( tA, tB );

What do you propose instead?

>> The only way to achieve that, as far as I can see, is to implement a lower_bound for
>> each and every iterator that defines its own partition_point. Or do you have an idea?
>You can always provide a CRTP base class template people can use, and
>implement lower_bound for that.

The reason I used a macro is that CRTP requires that library maintainers are willing to change their code.
Specifically for my application, you (as maintainer of boost.Iterator?) would have to change
boost::transform_iterator/filter_iterator and Joaquin multi_index_container. If we can agree on
that, I will change the code to CRTP. 

Instead, I could derive from the existing classes and implement CRTP on top, but that creates two versions
of each iterator, which is IMO unwarranted if the semantics of the two are the same, the only difference
being performance.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Paul A. Bristow | 1 Dec 12:44

Re: [Review] UUID library (mini-)review starts today, November 23rd

> -----Original Message-----
> From: boost-bounces <at> lists.boost.org [mailto:boost-bounces <at> lists.boost.org]
On
> Behalf Of Manuel Fiorelli
> Sent: 29 November 2008 20:38
> To: boost <at> lists.boost.org
> Subject: Re: [boost] [Review] UUID library (mini-)review starts today,
November 23rd
> 
> Having seen all these issues, I consider that the platform specific
> generator could be deferred until one discovers how to construct them
> correctly.
> 
> Isn't there some one, who knows how to get the MAC address?

There is plenty of info, it sounds as though getting a MAC address may be
iffy, and not portable.

So would it not still be useful to provide an implementation that only goes
as far as expecting a MAC address as a parameter?

Leaving the user to provide the MAC address.

That doesn't preclude later adding an overloaded function which does it
'automatically' - if that is ever possible/desirable.

Paul

---
Paul A. Bristow
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Garland | 1 Dec 13:30

[review][constrained_value] Review of Constrained Value Library begins today

Hi all,

The review of the Robert Kawulak's Constrained Value library begins today 
December 1, 2008, and will end on December 10th -- I will be the review 
manager.  Please post reviews to the developer list.

Here's the library synopsis:

The Boost Constrained Value library contains class templates useful for 
creating constrained objects. A simple example is an object representing an 
hour of a day, for which only integers from the range [0, 23] are valid values.

       bounded_int<int, 0, 23>::type hour;
       hour = 20; // OK
       hour = 26; // exception!

Behavior in case of assignment of an invalid value can be customized. The 
library has a policy-based design to allow for flexibility in defining 
constraints and behavior in case of assignment of invalid values. Policies may 
be configured at compile-time for maximum efficiency or may be changeable at 
runtime if such dynamic functionality is needed.

The library can be downloaded from the here:
http://rk.go.pl/f/constrained_value.zip

The documentation is also available online here:
http://rk.go.pl/r/constrained_value

---------------------------------------------------
(Continue reading)

Permalink | Reply | 194 comments |
headers
Jeff Garland | 1 Dec 13:59

[review][constrained_value] Review of Constrained Value Library begins today

Hi all,

The review of the Robert Kawulak's Constrained Value library begins today 
December 1, 2008, and will end on December 10th -- I will be the review 
manager.  Please post reviews to the developer list.

Here's the library synopsis:

The Boost Constrained Value library contains class templates useful for 
creating constrained objects. A simple example is an object representing an 
hour of a day, for which only integers from the range [0, 23] are valid values.

       bounded_int<int, 0, 23>::type hour;
       hour = 20; // OK
       hour = 26; // exception!

Behavior in case of assignment of an invalid value can be customized. The 
library has a policy-based design to allow for flexibility in defining 
constraints and behavior in case of assignment of invalid values. Policies may 
be configured at compile-time for maximum efficiency or may be changeable at 
runtime if such dynamic functionality is needed.

The library can be downloaded from the here:
http://rk.go.pl/f/constrained_value.zip

The documentation is also available online here:
http://rk.go.pl/r/constrained_value

---------------------------------------------------
(Continue reading)

Permalink | Reply | 43 comments |

Gmane