[thread/exception] trivial compile fix
the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1]. as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it? tim [1] https://svn.boost.org/trac/boost/changeset/75902
the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1].
as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it?
with the recent trunk, also typeof requires a fix, which is trivial as the others ... tim
Le 30/06/12 11:59, Tim Blechmann a écrit :
the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1].
as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it?
Hi, can I know more about the problem you have found? Best, Vicente
the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1].
as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it?
Hi,
can I know more about the problem you have found?
the general pattern seems to be something like this: namespace boost { namespace foo { [..] enable_if [..] }} while the fix is: namespace boost { namespace foo { [..] boost::enable_if [..] }} not sure, why enable_if is not resolved, but came across the issue before in boost.parameter, when i added boost.heap into trunk. the fix is trivial, as it just specifies the scope of enable_if ... no idea, why i triggered this issue with both boost.heap and boost.lockfree ... tim
On Sat, Jun 30, 2012 at 3:37 AM, Tim Blechmann <tim@klingt.org> wrote:
the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1].
as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it?
Hi,
can I know more about the problem you have found?
the general pattern seems to be something like this:
namespace boost { namespace foo { [..] enable_if [..]
}}
while the fix is:
namespace boost { namespace foo { [..] boost::enable_if [..]
}}
This doesn't seem to be the case in Boost Exception. All enable_if uses are in namespace boost, not in another nested namespace.
not sure, why enable_if is not resolved, but came across the issue before in boost.parameter, when i added boost.heap into trunk. the fix is trivial, as it just specifies the scope of enable_if ...
no idea, why i triggered this issue with both boost.heap and boost.lockfree ...
I suggest we first figure out why and then make changes. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
(adding test to the subject line)
not sure, why enable_if is not resolved, but came across the issue before in boost.parameter, when i added boost.heap into trunk. the fix is trivial, as it just specifies the scope of enable_if ...
no idea, why i triggered this issue with both boost.heap and boost.lockfree ...
I suggest we first figure out why and then make changes. :)
frankly, i *really* don't care, about this issue, especially as it is trivial to solve with the patch that i have posted. iac, including the headers that trigger the issue (like boost/thread.hpp) before including boost/test/unit_test.hpp works around this bug.
Le 01/07/12 09:48, Tim Blechmann a écrit :
(adding test to the subject line)
not sure, why enable_if is not resolved, but came across the issue before in boost.parameter, when i added boost.heap into trunk. the fix is trivial, as it just specifies the scope of enable_if ...
no idea, why i triggered this issue with both boost.heap and boost.lockfree ...
I suggest we first figure out why and then make changes. :) frankly, i *really* don't care, about this issue, especially as it is trivial to solve with the patch that i have posted. Even if trivial, it is better to understand what is the cause, and correct it. iac, including the headers that trigger the issue (like boost/thread.hpp) before including boost/test/unit_test.hpp works around this bug.
This is all what I wanted to know. Best, Vicente
On Sat, Jun 30, 2012 at 2:59 AM, Tim Blechmann <tim@klingt.org> wrote:
the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1].
as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it?
Maybe I'm missing something but what's the relevance to Boost Exception here? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1].
as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it?
Maybe I'm missing something but what's the relevance to Boost Exception here?
it is a fix/workaround for boost.thread and boost.exception. all it changes is to use boost::enable_if instead of enable_if tim
On 30/06/2012 23:48, Tim Blechmann wrote:
the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1].
as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it?
Maybe I'm missing something but what's the relevance to Boost Exception here?
it is a fix/workaround for boost.thread and boost.exception. all it changes is to use boost::enable_if instead of enable_if
Isn't better to understand why ? It's not normal that enable_if inside a nested namespace needs to have boost:: specified and while we are at it why boost::enable_if and not ::boost::enable_if ? Regards Gaetano
the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1].
as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it?
Maybe I'm missing something but what's the relevance to Boost Exception here?
it is a fix/workaround for boost.thread and boost.exception. all it changes is to use boost::enable_if instead of enable_if
Isn't better to understand why ? It's not normal that enable_if inside a nested namespace needs to have boost:: specified and while we are at it why boost::enable_if and not ::boost::enable_if ?
feel free to look into it: * check out trunk * go to libs/lockfree/tests * change the files: move the inclusion of boost/test/unit_test.hpp to the front of the file (or apply attached patch) * compile the testsuite * get a deeper understanding of the situation i'm not planning to dig deeper into these libraries, myself good luck, tim
Le 01/07/12 20:00, Tim Blechmann a écrit :
the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1].
as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it?
Maybe I'm missing something but what's the relevance to Boost Exception here? it is a fix/workaround for boost.thread and boost.exception. all it changes is to use boost::enable_if instead of enable_if Isn't better to understand why ? It's not normal that enable_if inside a nested namespace needs to have boost:: specified and while we are at it why boost::enable_if and not ::boost::enable_if ? feel free to look into it:
* check out trunk * go to libs/lockfree/tests * change the files: move the inclusion of boost/test/unit_test.hpp to the front of the file (or apply attached patch) * compile the testsuite * get a deeper understanding of the situation
i'm not planning to dig deeper into these libraries, myself
As I said, there is already an issue reported on this ML http://boost.2283326.n4.nabble.com/Boost-Test-g-compilation-error-due-to-amb... Best, Vicente
it is a fix/workaround for boost.thread and boost.exception. all it changes is to use boost::enable_if instead of enable_if Isn't better to understand why ? It's not normal that enable_if inside a nested namespace needs to have boost:: specified and while we are at it why boost::enable_if and not ::boost::enable_if ? feel free to look into it:
* check out trunk * go to libs/lockfree/tests * change the files: move the inclusion of boost/test/unit_test.hpp to the front of the file (or apply attached patch) * compile the testsuite * get a deeper understanding of the situation
i'm not planning to dig deeper into these libraries, myself
As I said, there is already an issue reported on this ML
http://boost.2283326.n4.nabble.com/Boost-Test-g-compilation-error-due-to-amb...
great to see that it is a known issue. not so great to see that the bug is in the tracker for several months without activity ...
On Sun, Jul 1, 2012 at 10:21 AM, Gaetano Mendola <mendola@gmail.com> wrote:
On 30/06/2012 23:48, Tim Blechmann wrote:
the boost.lockfree testsuite requires the following trivial patch, which
specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1].
as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it?
Maybe I'm missing something but what's the relevance to Boost Exception here?
it is a fix/workaround for boost.thread and boost.exception. all it changes is to use boost::enable_if instead of enable_if
Isn't better to understand why ? It's not normal that enable_if inside a nested namespace needs to have boost:: specified and while we are at it why boost::enable_if and not ::boost::enable_if ?
Also Boost Exception calls enable_if from namespace boost, not from a nested namespace. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (4)
-
Emil Dotchevski -
Gaetano Mendola -
Tim Blechmann -
Vicente J. Botet Escriba