Andre Poenitz wrote:
On Sun, Nov 25, 2007 at 06:57:15PM +0100, Abdelrazak Younes wrote:
In theory, the implementation could use boost::signal without changing
the interface, but that would still leave us vulnerable to the fragile
destruction order. And not using boost::signal would allow us to r
Edwin Leuven wrote:
perhaps you can rename fire() to something a bit less combustible?
trigger() perhaps?
emit()
perhaps you can rename fire() to something a bit less combustible?
trigger() perhaps?
On Sun, Nov 25, 2007 at 06:57:15PM +0100, Abdelrazak Younes wrote:
>> In theory, the implementation could use boost::signal without changing
>> the interface, but that would still leave us vulnerable to the fragile
>> destruction order. And not using boost::signal would allow us to remove
>> ~2500-
Abdelrazak Younes wrote:
Actually, I think we don't use boost::iostreams nor boost::filesystem
nowadays so we could already remove both compilations from the makefiles.
filesystem is still in use. But I've removed iostream from the cmake build.
--
Peter Kümmel
Andre Poenitz wrote:
I was looking for a way out of the dilemma given by the following
restrictions:
- signals and slots are a very powerful concepts leading to simple code,
- boost/signals.hpp is very expensive at compile time (+6 lines
per compilation unit) and fragile wrt to object cons
