[signals]question regarding header placement

I've started to look at the signals/slots libraries for a task I have to do and have found it interesting. I'm curious about the header placement of headers and namespaces used by this library. Specifically I find the following. boost/signal.hpp containing boost::signal boost/visit_each.hpp containing boost::visit_each boost/last_value.hpp containnig boost::last_value as these are part of the signals library, should they be in boost/signals/... with namespaces of boost/signal/signal ... etc.? This is especially confusing in the case of signal.hpp which is not at all were one would expect to find it. Are these things where they are due to some oversight? Or were they placed there for some special reason. Were their separate reviews of these things. They seem to be part of the signals/slots libraries. Robert Ramey

On Mar 2, 2008, at 6:01 PM, Robert Ramey wrote:
I'm curious about the header placement of headers and namespaces used by this library.
Specifically I find the following.
boost/signal.hpp containing boost::signal boost/visit_each.hpp containing boost::visit_each boost/last_value.hpp containnig boost::last_value
as these are part of the signals library, should they be in boost/signals/... with namespaces of boost/signal/signal ... etc.?
This is especially confusing in the case of signal.hpp which is not at all were one would expect to find it.
Are these things where they are due to some oversight? Or were they placed there for some special reason. Were their separate reviews of these things. They seem to be part of the signals/slots libraries.
We didn't think as carefully about header (or namespace) placement when the Signals library went into Boost, so there are some inconsistencies. visit_each and last_value were reviewed with Signals, but went into boost/ (and namespace boost) because they were considered to be general mechanisms that could be reused. visit_each, for example, needs to be supported by a few other libraries (like Bind) to be useful, so it didn't belong in Signals. As for boost/signal.hpp: it's in boost/ because boost::signal is in namespace boost. In retrospect, I should have put everything in namespace boost::signals (and headers in boost/signals), but back in 2002 we didn't have quite as much clutter in the top-level boost namespace/directory. - Doug

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 03 March 2008 09:09 am, Doug Gregor wrote:
We didn't think as carefully about header (or namespace) placement when the Signals library went into Boost, so there are some inconsistencies. visit_each and last_value were reviewed with Signals, but went into boost/ (and namespace boost) because they were considered to be general mechanisms that could be reused. visit_each, for example, needs to be supported by a few other libraries (like Bind) to be useful, so it didn't belong in Signals.
As for boost/signal.hpp: it's in boost/ because boost::signal is in namespace boost. In retrospect, I should have put everything in namespace boost::signals (and headers in boost/signals), but back in 2002 we didn't have quite as much clutter in the top-level boost namespace/directory.
thread_safe_signals has a similar header/namespace layout to boost.signals, since I figured staying as close to the original as possible would ease acceptance. But perhaps I should rearrange things to be more in line with current boost policies? And by the way, who do I need to send a campaign donation to in order to get a review manager? :) - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHzCtI5vihyNWuA4URAmvxAJsEUHlMkXAPqrq7WDBjhW5xly+JDACgrI1Y n3JObH1PkXwlr+tHwSQfh/Y= =w9+O -----END PGP SIGNATURE-----

Robert Ramey wrote:
I've started to look at the signals/slots libraries for a task I have to do and have found it interesting.
I'm curious about the header placement of headers and namespaces used by this library.
Specifically I find the following.
boost/signal.hpp containing boost::signal boost/visit_each.hpp containing boost::visit_each boost/last_value.hpp containnig boost::last_value
as these are part of the signals library, should they be in boost/signals/... with namespaces of boost/signal/signal ... etc.?
This is especially confusing in the case of signal.hpp which is not at all were one would expect to find it.
I do not know where you would expect to find signal.hpp but do not many libraries place their main header file directly in the boost directory ?
Are these things where they are due to some oversight? Or were they placed there for some special reason. Were their separate reviews of these things. They seem to be part of the signals/slots libraries.
Both visit_each.hpp and last_value.hpp seem to have been put directly in the boost directory because they may be used by other implementations, even if currently they may be only used by signals.

Edward Diener wrote:
Robert Ramey wrote:
I've started to look at the signals/slots libraries for a task I have to do and have found it interesting.
I'm curious about the header placement of headers and namespaces used by this library.
Specifically I find the following.
boost/signal.hpp containing boost::signal boost/visit_each.hpp containing boost::visit_each boost/last_value.hpp containnig boost::last_value
as these are part of the signals library, should they be in boost/signals/... with namespaces of boost/signal/signal ... etc.?
This is especially confusing in the case of signal.hpp which is not at all were one would expect to find it.
I do not know where you would expect to find signal.hpp but do not many libraries place their main header file directly in the boost directory ?
I would expect to find it in boost/signals/signal.hpp where all the rest of the signals include files are found. Did you look at the contents of this header? boost/signal.hpp is not a "convenience header" including all the other headers of the library. There is a boost/signals.hpp file in there for that purpose.
Are these things where they are due to some oversight? Or were they placed there for some special reason. Were their separate reviews of these things. They seem to be part of the signals/slots libraries.
Both visit_each.hpp and last_value.hpp seem to have been put directly in the boost directory because they may be used by other implementations, even if currently they may be only used by signals.
Hmmm - this identical to the circumstance of a few components of the serialization library. For this I was subjected to ridiculously disproportionate criticism a few months ago. I wondering if you will be prevailed upon to address this in the same manner. Hmmm, I see that a thread-safe version of the signals library has been placed in the review queue. Is this issue considered sufficiently important enough in this case to expect that be addressed in this upgrade. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Robert Ramey:
Edward Diener wrote: ...
Both visit_each.hpp and last_value.hpp seem to have been put directly in the boost directory because they may be used by other implementations, even if currently they may be only used by signals.
Hmmm - this identical to the circumstance of a few components of the serialization library.
This may be true for last_value.hpp, but it's not true for visit_each.hpp. visit_each.hpp specifies a generic visitation interface that is used by Signals and implemented by Bind.
participants (5)
-
Doug Gregor
-
Edward Diener
-
Frank Mori Hess
-
Peter Dimov
-
Robert Ramey