Re: [sigc] Proposal for standardization in C++ Library TR2
- From: Murray Cumming <murrayc murrayc com>
- To: Doug Gregor <dgregor cs indiana edu>
- Cc: libsigc++ list <libsigc-list gnome org>
- Subject: Re: [sigc] Proposal for standardization in C++ Library TR2
- Date: Tue, 26 Jul 2005 13:37:08 +0200
On Fri, 2005-07-22 at 16:46 -0500, Doug Gregor wrote:
> Back in April, the C++ standards committee met in Lillehammer, Norway
> to discuss extensions to the C++ language and library. The Library
> Working Group portion of the committee decided to create a second
> library technical report (called TR2) containing additional libraries
> for C++. Technical reports are not official standards, but it is likely
> that they will become standards and that vendors will implement them.
> For reference, the list of proposals that became TR1 is here:
> I am the author of another signals & slots library (Boost.Signals),
> which shares much of its interface with libsigc++ 2. At the
> aforementioned committee meeting I asked if there was any interest in
> including signals & slots in TR2 and receiving and overwhelmingly
> positive response.
> I propose that the developers of libsigc++ 2 and Boost.Signals
> collaboratively write a proposal to include signals & slots
> functionality in TR2. The deadline for this proposal will be
> mid-September, before the next C++ committee meeting. I've been through
> the proposal process and regularly attend committee meetings, and I can
> confidently say that work on this proposal will be gladly accepted by
> the library working group for TR2.
> We've discussed this previously, but I think it's time to buckle down
> and get it done. Our previous discussions resulted in a comparison
> between the current states of the libraries, here:
> We can definitely start by writing up the common parts of the
> interfaces (which should be quite large!) and then hammer out the
> little details in the end. The proposal will likely differ slightly
> from both libraries, but that's fine. However, we should avoid major
> deviations from existing, working code because those tend to make
> committees nervous.
> What say you?
This sounds great to me. Hopefully you can get the document started, as
someone who's experienced with this?
Personally, I don't see anything in the boost::bind API that I dislike,
though the "disconnecting all signals of a certain group" on that page
is a little odd.
Do you know what platforms boost::bind currently runs on? That might be
a practical consideration for the API. I've managed to port libsigc++ to
just about every compiler (latest versions) except HP-UX and the very
latest SUN Forte (though I expect them to fix those bugs soon).
murrayc murrayc com
] [Thread Prev