headers
Matt Calabrese | 1 Jun 2011 01:12
Picon
Gravatar

Re: [contract] syntax redesign

On Tue, May 31, 2011 at 6:35 PM, lcaminiti <lorcaminiti <at> gmail.com> wrote:
>
> For example? (Just so I understand this case correctly.)
>

//////////
CONTRACT_FUNCTION(
public template( class T, class Alloc )
void (push_back)( (BOOST_IDENTITY_TYPE((std::vector< T, Alloc >&))) vector_,
(const T&) element ) {
  vector_.push_back(element);
}
//////////

In the above case, since the first parameter type actually ends up being the
result of a metafunction invocation, you can't simply call the function by
doing this_.push_back( an_instance_of_std_vector, 4 ). T and Alloc can no
longer be deduced.

--

-- 
-Matt Calabrese
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 2 comments |
headers
Sean Chittenden | 1 Jun 2011 01:15
Gravatar

Re: [pimpl] Mini Review

>>> Helping to implement copying and assignment is useful,
>>> provided the class is supposed to support those operations.
>> 
>> shared_ptr-based Pimpls copying and assignment are done by
>> shared_ptr.
> 
> That tells me that Pimpl provides copying and assignment for the derivate.

> As you've noted, this is only by virtue of using private inheritance.  I still don't think it is correct
behavior for a library implementing the Pimpl Idiom to modify the interface class' (Book's) interface. 
Consider a raw pointer Pimpl design:
> 
> class Book {
>   // state
> };
> 
> becomes:
> 
> class Book {
>   struct impl;
>   impl pimpl_;
> };
> 
> struct Book::impl {
>   // state
> };
> 
> Adding a pimpl did nothing to Book's interface.  Why then should Book's interface chance when using your
library?  That seems to be an extension of the idiom into the territory of the Bridge Pattern or something
else entirely.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kazutoshi Satoda | 1 Jun 2011 03:58
Picon
Gravatar

Re: [function] [1.47.0] #4717: Non-const local static variable stored_vtable

Marshall Clow wrote:
> On May 30, 2011, at 8:27 PM, Kazutoshi Satoda wrote:
>>  I want the fix for the following ticket (regression, I think) included
>>  in 1.47.
>>  "#4717: Non-const local static variable stored_vtable"
>>  https://svn.boost.org/trac/boost/ticket/4717
>>
>>  Here is a quote of a essential part of the fix.
>>  -      static vtable_type stored_vtable =
>>  +      static const vtable_type stored_vtable =
>>           { {&manager_type::manage },&invoker_type::invoke };
>>  https://svn.boost.org/trac/boost/attachment/ticket/4717/djw_function_const_vtable.patch
>
> I've applied the patch to the trunk - please test.
> If there are no problems, I will merge to release.

Thank you very much.

I ran bjam in libs/function/test at trunk r72316 for
gcc-4.3.4/debug (Cygwin) and msvc-9.0express/debug on my Win32 machine,
and found no problems.

--

-- 
k_satoda
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Vicente Botet | 1 Jun 2011 10:24
Picon

Re: [conversion] ADL and templates


Jeffrey Lee Hellrung, Jr.-2 wrote:
> 
> On Tue, May 31, 2011 at 1:06 PM, Vicente Botet
> &lt;vicente.botet <at> wanadoo.fr&gt;wrote:
> 
>>
>> Stewart, Robert wrote:
>> >
>> > Vicente Botet wrote:
>> >>
>> >> There is something that is troubling me on the fact that the
>> >> developer will customize the conversion function using
>> >> overload and ADL, but that the user could not take advantage
>> >> in a simple way of this overloading. Taking in account that
>> >> Boost.Conversion needs already a customization point to take
>> >> care of conversion of types in the standard library (using
>> >> partial specialization) the addition of the customization
>> >> point using overload doesn't make simpler the user code,
>> >> neither the developers customizing the class, as it would
>> >> need to choose between two customization points that doesn't
>> >> make any difference.
>> >>
>> >> If no one find that the additional customization (via
>> >> overloading) point add some benefit to the library, I will
>> >> prefer to remove it. This will have the advantage of making
>> >> the library quite more simple without limiting his
>> >> expression power.
>> >
>> > I have no idea to what you're referring.  I've long since lost any
(Continue reading)

Permalink | Reply | 0 comments |
headers
Klaim - Joël Lamotte | 1 Jun 2011 11:33
Picon
Gravatar

Re: Cross-platform process library?

Hi,

On Wed, Jun 1, 2011 at 00:02, Gregory Crosswhite <gcross <at> phys.washington.edu
> wrote:

> Hey everyone,
>
> Since there is not yet a Boost.Process library, does anyone have a
> suggestion for a lightweight cross-platform C++ library for launching and
> monitoring (i.e. being able to tell if they die) child processes?
>
>
One other (set of) libraries often cited as alternative for providing
process control (and other services not yet in boost like
modules/extensions) is Poco :
http://pocoproject.org/documentation/index.html

Joël Lamotte
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Stewart, Robert | 1 Jun 2011 13:12
Favicon

Re: [pimpl] Mini Review

Sean Chittenden wrote:

Don't snip attributions for quoted material, please.

> > I still don't think it is correct behavior for a library
> > implementing the Pimpl Idiom to modify the interface class'
> > (Book's) interface.  Consider a raw pointer Pimpl design:
> >
> > class Book
> > {
> >   // state
> > };
> >
> > becomes:
> >
> > class Book
> > {
> >   struct impl;
> >   impl pimpl_;
> > };
> >
> > struct Book::impl
> > {
> >   // state
> > };
> >
> > Adding a pimpl did nothing to Book's interface.  Why then
> > should Book's interface change when using your library?  That
> > seems to be an extension of the idiom into the territory of
> > the Bridge Pattern or something else entirely.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stewart, Robert | 1 Jun 2011 13:34
Favicon

Re: [conversion] ADL and templates

Vicente Botet wrote:
[with minor editing by me]
>
> Currently Boost.Conversion has two customization points:
>
> A- overloading of conversion::convert_to function
>
>     template <typename Target, typename Source>
>     Target  convert_to(
>        Source const& from,
>        dummy::type_tag<Target> const&);
>
> The dummy parameter is there to allows overloading on the
> return type.
>
> B- partial specialization of
> conversion::overload_workaround::convert_to
> struct.
>
>     namespace overload_workaround {
>       template
>       <
>          typename To
>          , typename From
>          , class Enable = void
>       >
>       struct convert_to {
>         static To apply(const From& val);
>       };
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Vicente Botet | 1 Jun 2011 13:42
Picon

Re: [Math and numerics] interest in Circular values math and statistics library ?


Lior Kogan wrote:
> 
> I built a C++0x circular-values math and statistics library, and posted it
> on CodeProject. See
> 
> http://www.codeproject.com/KB/recipes/Circular-Values.aspx
> 
> 
> I wonder if such library may be a welcomed addition to Boost.
> 
> 

Hi,

I'm interested too. An an integral/enumerated version will be also welcome.
I'm thinking for example to hours on a day, the days of the week, months, 

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/Math-and-numerics-interest-in-Circular-values-math-and-statistics-library-tp3553379p3565594.html
Sent from the Boost - Dev mailing list archive at Nabble.com.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Vicente Botet | 1 Jun 2011 13:56
Picon

Re: [conversion] ADL and templates


Stewart, Robert wrote:
> 
> Vicente Botet wrote:
> 
> 
> Having just one CP is better.  Sure, PTS is less obvious than overloading
> a function template, but having to know about both mechanisms and which is
> necessary in various circumstances, makes the whole mechanism more
> complicated than it should be.
> 

Glad to see that we agree here.

>> I suspect that after refactoring, I will rename the namespace
>> overload_workaround by something more positive. Any
>> suggestions?
> 
> namespace boost
> {
> namespace conversion
> {
>    template &lt;class Target, class Source, class Enable = void&gt;
>    struct converter
>    {
>       Target
>       operator (Source const &) const;
>    };
> }
> }
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeff Flinn | 1 Jun 2011 14:12
Picon

Re: Cross-platform process library?

Gregory Crosswhite wrote:
> Hey everyone,
> 
> Since there is not yet a Boost.Process library, does anyone have a 
> suggestion for a lightweight cross-platform C++ library for launching 
> and monitoring (i.e. being able to tell if they die) child processes?

I've put the code from the recent boostcon "boost process" presentation 
that Boris Schaeling and I gave at:

https://github.com/JeffFlinn/boost-process

Initial documentation is at:

https://docs.google.com/document/pub?id=1qdpxcJB51WMuNYlKYPkPcZZGuPj7zmeUPIpHCd-aetE

The intent is to get this completed and ask for review this summer. The 
areas needing work are:

- docs
- unit tests
- environment variables support (currently inherits)
- improve POSIX child unused handle closing
- asynchronous joining/waiting

I've been successfully using this in my company's product for about 6 
months on various flavors of Windows and Mac.

Your comments are appreciated.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane