headers
Vladimir.Batov | 1 Apr 01:15
Picon
Favicon

Re: Review Request: Generalization of the Pimpl idiom

"vicente.botet" <vicente.botet <at> wanadoo.fr> wrote in message 
news:<014201c8937c$c1380180$0301a8c0 <at> viboes1>...
> Hello,
> 
> First of all, I think that a pimpl library should have a place in boost, 
but 
> I think that the pimpl idiom do not scale very well (see below).
> 
> Even if your library is usable in simple cases, I would like to see how 
it 
> can manage more complex cases. And if no satisfactory solution to this 
case 
> is possible, that the library states explicitly when it can not be used.

Would it be possible to elaborate that exactly you mean by "more complex 
cases"? Inheriting from a pimpl-based class? I think it covered. What 
else? Not like my own deployment experience is of any guidance but still 
I've been using this idiom in my every-day development for about a year 
and have not come across something that I felt was not a good fit for that 
idiom. I'd rather say that the pimpl idiom in general does not handle well 
simple (rather than complex) cases where the overhead of creating private 
implementation on the heap is not affordable.

> 
> Do you think to write the library documentation before the review? Even 
if 
> there is a tutorial in DDJ, IMHO,  you should spend some time on the 
> documentation of the library before the review.

In addition to the tutorial I have API documented in the header in the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Gottman | 1 Apr 01:30
Picon

1.35] Please remove \libs\filesystem\src\exception.cpp.


Instead of using bjam, I compile the boost libraries on my own.  I 
recently tried to compile the new version of boost::filesystem, and 
failed with exception.cpp.  I had a scary few minutes until I realized I 
no longer needed this file since filesystem now uses errors from the 
system library.

    With header files, especially ones that the user never uses 
directly, there is no problem with leaving them in the directory after 
they are no longer needed, since they will never be included.  However, 
users generally expect to have to compile source files, and so one that 
is included but no longer valid can cause major problems for people who 
compile without using bjam.  Therefore, I would appreciate it if you 
would remove \libs\filesystem\src\exception.cpp.

Joe Gottman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Sean Hunt | 1 Apr 02:21
Picon
Gravatar

Interest in static initialization library

Hi Boosters!

I was wondering if there is any interest for a static initialization 
library. The idea I currently have might look something like this:

#include <iostream>
#include <boost/init.hpp>
using namespace boost;
using namespace std;

class myType {
  myType(int i) { cout<<"myType constructed with parameter "<<i<<endl; }
};

void myFunc (int i) {
  cout<<"myFunc called with parameter "<<i<<endl;
}

extern init::variable<myType> myVar (42);
init::function<void (), myVar> myInitFunc (myFunc, 35);
init::variable<myType> myVar;

int main () {
  init::init();
}

The extern declaration of myVar simulates a global defined in a 
different translation unit - in this case, function is by the standard 
guaranteed to be initialized first, but if myVar is in a different TU, 
then the output is undefined. By passing myVar as a parameter to the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sohail Somani | 1 Apr 02:26
Gravatar

Re: Interest in static initialization library

On Mon, 31 Mar 2008 18:21:09 -0600, Sean Hunt wrote:

> Hi Boosters!
> 
> I was wondering if there is any interest for a static initialization
> library. The idea I currently have might look something like this:

+1 from me. Specific references to the standard would be helpful.

--

-- 
Sohail Somani
http://uint32t.blogspot.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Vladimir.Batov | 1 Apr 02:17
Picon
Favicon

Re: Review Request: Generalization of the Pimpl idiom

...skipped the beginning which appears to be duplication of the previous 
email

> Could you clarify if the base implementation pointer can or can not be 
> initialized with a pointer to the implementation of the derived class? 
There 
> is something wrong in
> 
>     Base::Base(int k) : base(new BaseImpl(k)){}
>     Derived1::Derived1(int k, int l) : Base(new Derived1Impl(k, l))

No, this initialization method is not allowed. One needs to use reset() 
instead as you show below. I considered the syntax above and rejected it 
on the grounds that it does not add new functionality (as reset() already 
does that) and it is not generic enough as it won't work for "Derived2 : 
public Derived1"

>     Base::Base(int k) : base(null())
>     {
>         reset(new BaseImpl(k));
>     }
> 
>     Derived1::Derived1(int k, int l) : Base(null<Base>())
>     {
>         reset(new Derived1Impl(k, l));
>     }
> 
> Could a class inherit privately from pimpl?
> 
> class A : private pimpl<A>::value_semantics {...}
(Continue reading)

Permalink | Reply | 1 comment |
headers
shunsuke | 1 Apr 03:03
Picon

Re: Giving names to formal parameters of lambda expressions: a named placeholder trick.

Giovanni Piero Deretta wrote:
> This is in fact the reason for my compose<> template idea: If you
> can't avoid writing a type expression, you might as well just write
> that.

BTW, Boost.Egg has the potential to implement your compose.

     typedef result_of_lazy<fold>::type fold_;
     typedef result_of_lazy<reverse>::type reverse_;
     typedef return_of<fold_(reverse_(T_bll_1), T_bll_2, T_bll_3)>::type reverse_fold;

A showstopper is that it is difficult to offer static-initialization way.

Regards,

--

-- 
Shunsuke Sogame

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 25 comments |
headers
Eric Niebler | 1 Apr 03:34
Picon
Favicon

Re: [Proto] Review

Dave,

Unless I hear otherwise, I'll resolve the technical issues with Proto 
you raised as follows:

1) The aliasing issue (proto::_left as a typedef for 
proto::transform::left) will be resolved by eliminating the "transform" 
namespace and everything in it.

2) The "functional" namespace will be renamed "functor".

3) "visitor" will be renamed "data"

4) I don't intend to rename the "call" transform or the "function" 
tag/metafunction. (If I renamed "call" to "apply" like I suggested, then 
I should also rename "is_callable" to "is_applicable" or some such, 
which is awful, IMO.)

5) You can override an expression's domain with 
"proto::as_expr<Domain>(expr)". This gives a way to mix expressions from 
different domains in the same expression.

If you object to any of these resolutions, holler.

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com

_______________________________________________
(Continue reading)

Permalink | Reply | 9 comments |
headers
Steven Watanabe | 1 Apr 03:58
Picon

Re: [Proto] Review

AMDG

Eric Niebler wrote:
> 5) You can override an expression's domain with 
> "proto::as_expr<Domain>(expr)". This gives a way to mix expressions from 
> different domains in the same expression.
>   

I'm not sure that's enough.  I can imagine wanting one domain
to treat expressions in another domain as terminals.  Specifically,
I am thinking of using lambda in another domain that expects
function objects.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 6 comments |
headers
Eric Niebler | 1 Apr 04:08
Picon
Favicon

Re: [Proto] Review

Steven Watanabe wrote:
> AMDG
> 
> Eric Niebler wrote:
>> 5) You can override an expression's domain with 
>> "proto::as_expr<Domain>(expr)". This gives a way to mix expressions from 
>> different domains in the same expression.
> 
> I'm not sure that's enough.  I can imagine wanting one domain
> to treat expressions in another domain as terminals.  Specifically,
> I am thinking of using lambda in another domain that expects
> function objects.

Could you show some pseudo-code for your DSEL? What support from Proto 
do you think you'll need?

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 5 comments |
headers
Steven Watanabe | 1 Apr 04:17
Picon

Re: [mp_math] a multi precision signed integer library

AMDG

Maarten Kronenburg wrote:
> In my opinion an unsigned integer is a, works like a and can be substituted
> as an integer, and so is a modular integer, and as far as I'm concerned also
> an allocated integer. This is why I choose for derivation, and then with the
> base pointer to derived object (as quoted above) to runtime polymorphism.
>   

I strongly disagree.

1)  An unsigned integer only works like an integer for non-mutating
operations.  If clients take parameters of const integer&, sure, 
unsigned_integer
will work fine in this context.  Treating non-const integers 
polymorphically is a very bad
idea, though.  Code that does so has to be very carefully designed to 
make sure that
it can handle all the combinations.  If you have to use inheritance, 
make both integer and
unsigned_integer inherit from a common base.

2) I would expect an integer class to be a value object. virtual 
functions don't play
well with value objects, because to prevent slicing, everything has to 
be held by
pointer.

3) unsigned_integer + unsigned_integer should return an 
unsigned_integer.  There
(Continue reading)

Permalink | Reply | 2 comments |

Gmane