Re: bind placeholders/tuples ignore and BCB pch

From: ysapir (ysapir_at_[hidden])
Date: 2002-03-07 18:23:33

Hi.  I had suggested the use of function pointers.  See:

http://groups.yahoo.com/group/boost/message/24241

This is better than just _1() since you can write code that looks as 
if it uses the original bind: bind(some_func, _1, _2).

Peter Dimov didn't like this idea and since it's his library, it's 
his decision.  I also was concerned about the portability of such a 
construct, that is, if I pass a function pointer to a function 
returning X and there is a function pointer that returns X and 
another that returns Y, how can I be sure that the compiler would 
choose correctly, especially given the templated nature of the 
entire library.  Besides being possibly non-standard, it's probably 
much harder to maintain, and perhaps conflicts with its use by the 
lambda/tuple libraries.

If the static trick now implemented wouldn't have been available, 
though, I probably would have maintained my own separate "msc6_bind" 
making use of this function pointer trick since it _did_ work on 
MSVC6 and so that I could use it in the precompiled header (sort of 
a requirement imposed on my code) while still being able to write 
portable code (portable in the sense that it uses the published 
interface of the original bind).  

Perhaps doing this would work for Borland and whatever need you have 
now.  You do have to rewrite the code though and take maintenance, 
compatibility with the boost constructs, and any possible run-time 
changes upon yourself.  (It may be simpler now -- maybe you just 
have to rewrite one of the template headers).

Yitzhak

--- In boost_at_y..., "Fernando Cacciola" <fcacciola_at_g...> wrote:
> 
> ----- Original Message -----
> From: "Jaakko Jarvi" <jajarvi_at_c...>
> To: <boost_at_y...>
> Sent: Thursday, March 07, 2002 6:36 PM
> Subject: Re: [boost] bind placeholders/tuples ignore and BCB pch
> 
> 
> > > Another alternative which I also suggested is to get rid a the
> 'variable'
> > > and use an inline function: _1()
> >
> > The _1 could be a macro that expanded to _1(), or whatever ???
> >
> > Jaakko
> >
> Hmm... The macro would have to be named '_1'... but that as a 
preprocessor
> symbol, this is likely to create a big mess.
> 
> Fernando Cacciola
> Sierra s.r.l.
> fcacciola_at_g...
> www.gosierra.com