From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-08-17 22:58:05
On Friday 17 August 2001 07:17, you wrote:
> ----- Original Message -----
> From: Douglas Gregor <gregod_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Friday, August 17, 2001 6:47 PM
> Subject: Re: [boost] [Review] bind
> > On Friday 17 August 2001 05:19, you wrote:
> > > Aside from the conflicts with functional -which I'm not sure how could
> > > solved-, I vote for inclusion.
> > >
> > > I second the argument of replacing the _N notation for boost::argN.
> > I'll vote against boost::argN, because I think that the _N notation is
> > wonderfully terse and that it stands out well with syntax highlighting
> > available.
> > In any case, it isn't a latent error: if one uses 1 instead of _1
> > or vice-versa, it will result in a compiler error.
> The crucial potential conflict I see is not that you can forget to type the
> underscore, but that other identifiers or nasty macros might collide.
> In these cases syntax highlighting won't help, and compiler errors might be
> just too confusing.
I would guess that users are afraid to use leading underscores because
they're read/heard somewhere that they aren't always allowed, but don't know
the exact rules. I checked the systems I have access to (Linux, FreeBSD,
Irix, AIX, Solaris) and no headers anywhere had _1, _2, etc. as identifiers
or macros. I think the concern over _1, _2, etc. showing up as macros is
unfounded, but obviously I can only offer proof by example.
[snip visitor description]
> > - all function objects must be able to accomodate a visitor
> > - shouldn't place this requirement on all function objects (otherwise
> > it would annoy users).
> > All solutions so far that decouple bind libraries from the signals
> > library have been deemed too brittle :(.
> I see.
> It appears that a coupling mechanism is so important that even a hack is
> better than nothing.
> In that case, then, let's leave it the way it is.
> Fernando Cacciola
> Sierra s.r.l.
It's at the very least a step above only offering binding in a limited form
and including it in the signals library but no, I'm not overly happy with it.
If only we had reflection...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk