[boost] Re: Re: Boost MPL problem
It could be an instantiation depth issue. Maybe the OP's code needs more of our loop unrolling technique to avoid deep instantiations. I think that can be controlled by #defining BOOST_MPL_UNROLLING_LIMIT to some number greater than 4 before mpl files are #included. Thanks, I already managed to fix it. It turned out to be a classic case of Effective MPL- item 5.13 with some added recursion issues. It was just weird, because before the 1.30.0 release everything was working fine, so it was some combination of my old code with new mpl code that triggered this error. Luckily, after a nice and long debug session, I managed to track the problem down to an inner-most loop, and then I simply had to rewrite it to make it work. Thanks for your help, Jaap Suter ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] bad_lexical_cast
Yes. Since type_info objects can't be copied, one might instead store pointers or references to them. Pointers would be better because, for better or for worse (mostly for worse), standard exceptions support assignment as part of their interface. Why should boost exception classes behave like std:: exception classes in this regard? Since you advocate elsewhere that exception classes be derived from std::exception, the answer is because otherwise LSP would be violated. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sat, 22 Mar 2003 20:11:23 +, Kevlin Henney
[EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED], Terje Slettebø
[EMAIL PROTECTED] writes
Regarding the other MSVC 6 warning given in the original report, Gennaro
Prota has suggested using an explicit !=, rather than relying on the
implicit conversion from pointer to bool. This also avoids using a cast,
instead.
Or one could use stream input true ;-) However, I think if one
is going to twist the expression of the code to satisfy the misplaced
oversensitivity of VC, it may be better to be more explicit than subtle,
ie !(stream input).fail().
That's fine too. Of course these are style/personal-taste issues. I'm
sure there's someone claiming that !! is clearer :-) More to the
point, I just suggested the way I *generally* use to shut up VC in
such cases; it' obvious that !(expr).fail() is something rather
stream-specific, whereas an explicit compare with != works any time
you have a boolean conversion.
The typical case where that warning appears with VC++ is when you
attempt to return directly the result of an API call that returns a
BOOL from a function that returns bool; e.g.:
bool IsThereAMouseHere() {
return ::GetSystemMetrics(SM_MOUSEPRESENT);
}
In that case an explicit compare with FALSE seems reasonable.
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sat, 22 Mar 2003 09:38:49 -0500, David Abrahams [EMAIL PROTECTED] wrote: David Abrahams [EMAIL PROTECTED] writes: Damn, maybe I need to update more/error_handling.html Done. Just some notes: - Don't embed a std::string object or any other data member or base class whose copy constructor could throw an exception. That could lead to termination during stack unwinding. I think you meant *before* (any) stack unwinding (unless you are thinking to catch by value, but that's highly unlikely) - Similarly, it's a bad idea to use a base or member whose ordinary constructor might throw, because, though not fatal, you will report a different exception Of course it *may* be fatal as well; it's just /not necessarily/ so. It may not lead you straight to terminate (if you have a handler for the different exception) but can in practice put the program in a disastrous state. Minor: - In section What About Programmer Errors? there's a little typo: neccessary (two 'C's) - at the beginning of the paper, there's a link to 'Generic Programming, Proc. of a Dagstuhl Seminar...' I was about to report the error in the date (1766) :-) Maybe it would be better to write Volume 1766? Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Boost MPL problem
Jaap Suter [EMAIL PROTECTED] writes:
It could be an instantiation depth issue. Maybe the OP's code needs
more of our loop unrolling technique to avoid deep instantiations. I
think that can be controlled by #defining BOOST_MPL_UNROLLING_LIMIT
to some number greater than 4 before mpl files are #included.
Thanks, I already managed to fix it.
It turned out to be a classic case of Effective MPL- item 5.13 with some
added recursion issues.
It was just weird, because before the 1.30.0 release everything was working
fine, so it was some combination of my old code with new mpl code that
triggered this error.
Luckily, after a nice and long debug session, I managed to track the problem
down to an inner-most loop, and then I simply had to rewrite it to make it
work.
Thanks for your help,
Jaap, I was just looking over the EMPL Wiki page (which continues to
be a great thing), and noticed that item 5.2 is not really a good
example of MPL style. In fact, you apply equal_to to an integral
constant and access its ::value_type member so I think it won't even
compile. Make that thing a true MPL metafunction (i.e. operate on
types only) and you get something much simpler:
template class N, class Result = int_0
struct num_bits_set
: apply_if
equal_to
N
, integral_c typename N::value_type, 0
, Result
, num_bits_set
integral_c size_t, bitand_N, argprevN
, nextResult
{};
That arg template is something that Aleksey and I have discussed
which causes a nullary metafunction to be evaluated in a lambda
expression. It may have another name in the current MPL sources; I'm
not absolutely sure (Aleksey?)
I also think it would be a great idea to have zero and one
metafunctions (which also satisfy the integral constant wrapper
requirements) so that we could write the above as:
template class N, class Result = int_0
struct num_bits_set
: apply_if
equal_toN, zeroN
, Result
, num_bits_set
integral_c size_t, bitand_N, argprevN
, nextResult
{};
If we wanted to get funky we could make it so zeroint_3 and
zerolong both work.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
Gennaro Prota [EMAIL PROTECTED] writes: On Sat, 22 Mar 2003 09:38:49 -0500, David Abrahams [EMAIL PROTECTED] wrote: David Abrahams [EMAIL PROTECTED] writes: Damn, maybe I need to update more/error_handling.html Done. Just some notes: - Don't embed a std::string object or any other data member or base class whose copy constructor could throw an exception. That could lead to termination during stack unwinding. I think you meant *before* (any) stack unwinding (unless you are thinking to catch by value, but that's highly unlikely) I don't actually know whether it's before or after, but it's at the stage described by 15.1/3, so I'll clarify that. - Similarly, it's a bad idea to use a base or member whose ordinary constructor might throw, because, though not fatal, you will report a different exception Of course it *may* be fatal as well; it's just /not necessarily/ so. It may not lead you straight to terminate (if you have a handler for the different exception) but can in practice put the program in a disastrous state. OK, I guess. In general a well-written program won't enter a disastrous state if you throw exception A instead of exception B at any given point. That's part of the reason exception-specifications aren't worth the trouble. I can change it to though it may not be fatal without feeling like a fraud. Minor: - In section What About Programmer Errors? there's a little typo: neccessary (two 'C's) - at the beginning of the paper, there's a link to 'Generic Programming, Proc. of a Dagstuhl Seminar...' I was about to report the error in the date (1766) :-) Maybe it would be better to write Volume 1766? I just copied the official reference text, and never knew where that number came from. Is it really a volume number? Thanks for your remarks! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ASPN improvements!
I don't know if anyone else noticed, but the performance, UI, and reliability of the ASPN archives seems to have undergone a radical improvement recently. It still mis-threads some messages, but otherwise it feels entirely usable. Gracious thanks to everyone at ActiveState for this overhaul! I now know of several ways to search our mailing list: http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/boost/ http://news.gmane.org/thread.php?group=gmane.comp.lib.boost.devel http://www.mail-archive.com/boost%40lists.boost.org/ and of course you can use the Google search field at http://www.boost.org/ -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] random and intel v7
Hi, random and intels compiler v7 does not work together. Does anyone know what it would take to make it work? regards -Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
On Sun, 23 Mar 2003 08:11:02 -0500, David Abrahams [EMAIL PROTECTED] wrote: Gennaro Prota [EMAIL PROTECTED] writes: - Don't embed a std::string object or any other data member or base class whose copy constructor could throw an exception. That could lead to termination during stack unwinding. I think you meant *before* (any) stack unwinding (unless you are thinking to catch by value, but that's highly unlikely) I don't actually know whether it's before or after, but it's at the stage described by 15.1/3, so I'll clarify that. Hmmm... let's ignore the possibility to omit the copy for a moment: the standard defines 'stack unwinding' as (15.2/3) The process of calling destructors for automatic objects constructed on the path from a try block to a throw-expression Does this include the 'argument' of the call expression? throw A() Certainly the expression A() is part of the throw-expression, however the quote above isn't particularly clear at saying whether to a throw-expression is inclusive or not. I'm inclined to think that it is inclusive, in principle. Maybe you know something, from the committee meetings or from the standard, that contradicts this view? [...] I just copied the official reference text, and never knew where that number came from. Is it really a volume number? So I guess :-) The linked to page has, at its bottom, the following Series: Lecture Notes in Computer Science. Volume. 1766 That's itself a link and if you follow it you find a long list with one of the entries being Volume. 1766: Jazayeri, M.; Loos, R. G.K.; Musser, D. R., (Eds.) Generic Programming Thanks for your remarks! Thanks to you :-) Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] random and intel v7
Thorsten Ottosen [EMAIL PROTECTED] writes: Hi, random and intels compiler v7 does not work together. Does anyone know what it would take to make it work? An active maintainer for the Boost.Random library ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: random and intel v7
random and intels compiler v7 does not work together. Does anyone know what it would take to make it work? An active maintainer for the Boost.Random library ;-) I was more thinking about what compiler features that are prohibiting the intel compiler from working with the library. Since I'm not really an expert in random number theory, I cannot be a maintainer. Anyway, If somebody knows what's needed for a fix, but doesn't have time, I might give some of it a look (since I might need it for my ongoing project). regards Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::any feature request
Title:
I think it would be great to make boost::any's
memory allocation strategy for value holder customizable. It would allow to use
not only global new operator, but any other special fast allocators like, for
example, Loki::SmallObject.
The changes are minor and would not break
existing code.
All it takes is to change class name
and:
code
struct use_default_allocator
{};
//class any
templateclass A = use_default_allocator
class any_ex
{
// ...
// class placeholder
class placeholder : public A // derive
operators new() and delete()
// ...
};
typedef any_ex any; // for not breaking
existing code
/code
And change any_cast functions
appropriately.
I've measured performance using Intel VTune.
The any_exLoki::SmallObject was about twice as fast as any_ex
with MS VC++ 7 and Intel C++ 7.
There is sure a possibility to write a faster
allocator than Loki::SmallObject.
So, the hardcoded memory allocation strategy
makes more harm then good to boost::any. Changes would make boost::any
more extensible and reusable.
[boost] Re: Re: Re: Boost MPL problem
Jaap, I was just looking over the EMPL Wiki page (which continues to be a great thing), and noticed that item 5.2 is not really a good example of MPL style. The original intention was to focus on the default-template-parameter technique, and keep the rest simple. The 'operate-on-types-only' is introduced in a later item, so I wanted to keep this item simple. Looking back, I agree with you, so I've changed the code. In fact, you apply equal_to to an integral constant and access its ::value_type member so I think it won't even compile. That was of course completely wrong. That arg template is something that Aleksey and I have discussed which causes a nullary metafunction to be evaluated in a lambda expression. It may have another name in the current MPL sources; I'm not absolutely sure (Aleksey?) I've done it somewhat differently in the new code. I also think it would be a great idea to have zero and one metafunctions (which also satisfy the integral constant wrapper requirements) If we wanted to get funky we could make it so zeroint_3 and zerolong both work. Those would be greatly appreciated, and very useful. On a side note, I've ran into a few situations where I ended up using code like this: typedef list_c some_type, 0, 1, 2, 3, 4 some_list; typedef integral_c front some_list ::type::value_type, 5 some_element; See what I'm trying to do? I need to get the type of the integral constants inside a list, so I just get it through the first element in the list. This doesn't work with empty list though, and it feels too complicated to do this. Is there a simpler method? Something like: typedef integral_c some_list::element_type::value_type, 5 some_element; Notice the 'element_type'. All sequences would then have such a member-type defined. Perhaps there is already something like this in the MPL (STL has it too, probably under a different name), but I couldn't find it. Regards, Jaap Suter ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Boost MPL problem
Jaap Suter [EMAIL PROTECTED] writes:
Jaap, I was just looking over the EMPL Wiki page (which continues to
be a great thing), and noticed that item 5.2 is not really a good
example of MPL style.
The original intention was to focus on the default-template-parameter
technique, and keep the rest simple. The 'operate-on-types-only' is
introduced in a later item, so I wanted to keep this item simple.
Looking back, I agree with you, so I've changed the code.
Good. I think a few more of those examples bear changing in the same
way. TMP of any complexity really is simpler if you just give up on
direct handling of integral constants.
In fact, you apply equal_to to an integral
constant and access its ::value_type member so I think it won't even
compile.
That was of course completely wrong.
That arg template is something that Aleksey and I have discussed
which causes a nullary metafunction to be evaluated in a lambda
expression. It may have another name in the current MPL sources; I'm
not absolutely sure (Aleksey?)
I've done it somewhat differently in the new code.
Eh, whoops; your template invokes num_bits_set_impl, which isn't
defined. Also, next is spelled netxt. I also think you may have a
problem with eager evaluation or one too many ::type s. I think you
should test these.
Why aren't you at least using forwarding? You already introduced it
in an earlier item; there's no reason to make it more complicated
than it needs to be. Off the top of my head:
template class N, class Result = integral_c size_t, 0
struct num_bits_set
: apply_if
equal_to N, integral_c typename N::value_type, 0
, Result
, num_bits_set
mpl::bitand_N, typename N::prior, typename Result::next
{};
I want to suggest also that personal preferences aside, your choice
of enline layout in your formatting may cause enough of the structure
of the calculation to be obscured that you missed the errors.
I also think it would be a great idea to have zero and one
metafunctions (which also satisfy the integral constant wrapper
requirements) If we wanted to get funky we could make it so
zeroint_3 and zerolong both work.
Those would be greatly appreciated, and very useful.
Care to submit some files? This seems like a super-easy job.
On a side note, I've ran into a few situations where I ended up using code
like this:
typedef list_c some_type, 0, 1, 2, 3, 4 some_list;
typedef integral_c front some_list ::type::value_type, 5 some_element;
See what I'm trying to do? I need to get the type of the integral constants
inside a list, so I just get it through the first element in the list.
This doesn't work with empty list though, and it feels too complicated to do
this. Is there a simpler method?
Not yet, AFAICT.
Something like:
typedef integral_c some_list::element_type::value_type, 5 some_element;
Notice the 'element_type'. All sequences would then have such a member-type
defined.
That won't work for generalized type sequences, of course:
listint, double, std::string
I think the integral sequence wrappers might be able to have a
::value_type directly, but that could also complicate algorithms which
have to produce new sequences, since to be useful they'd need to
transfer the ::value_type to the new sequence iff it existed in the
original one. We could give sequences a ::value_type of mpl::void_ by
default I guess, but all of these ideas feel conceptually pretty hairy
to me. Remember that the integral sequences are conceptually just
convenient front-ends for regular type sequences.
Perhaps there is already something like this in the MPL (STL has it too,
probably under a different name), but I couldn't find it.
STL calls it value_type.
I understand the need you have, but I am really unsure of the best
way to address it.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] More EMPL Wiki nits (was: Boost MPL problem)
A. int_c et al are now int_ et al.
B. In item 5.3 you should probably suggest:
template class N
struct square
: integral_c typename N::value_type, N::value * N::value
{};
and later,
template long N
struct square_c : squarelong_N {};
Not only is it simpler, but it allows:
squareint_5 ::value
and:
greatersquare_1, 32
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: random and intel v7
Thorsten Ottosen [EMAIL PROTECTED] writes: random and intels compiler v7 does not work together. Does anyone know what it would take to make it work? An active maintainer for the Boost.Random library ;-) I was more thinking about what compiler features that are prohibiting the intel compiler from working with the library. I know. The library is failing with a number of compilers at the moment. Since I'm not really an expert in random number theory, I cannot be a maintainer. Wasn't suggesting it. However, the kind of maintenance it needs is really organizational more than theoretical. As a side note, at the Santa Cruz committee meeting Jens and I worked out a new design for the library based on some feedback he'd gotten from heavy users, which he was planning to bring forward as a proposal for the TR. I'm guessing that he's been unable to pursue it, which would be a shame because I thought it had real potential. Anyway, If somebody knows what's needed for a fix, but doesn't have time, I might give some of it a look (since I might need it for my ongoing project). Good luck! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
Gennaro Prota [EMAIL PROTECTED] writes: On Sun, 23 Mar 2003 17:17:03 +0100, Gennaro Prota [EMAIL PROTECTED] wrote: the standard defines 'stack unwinding' as (15.2/3) The process of calling destructors for automatic objects constructed on the path from a try block to a throw-expression Does this include the 'argument' of the call expression? throw A() Certainly the expression A() is part of the throw-expression, however the quote above isn't particularly clear at saying whether to a throw-expression is inclusive or not. Now that I think about it, I believe the initial copy of the exception object must logically be seen as a *part* of the evaluation of the throw-expression. Otherwise, i.e. if you make it a separate step, you either have to say that the temporary A() is not destroyed at the end of its full expression (the throw) or say that it is destroyed before you get a chance to copy it to a safe place. Don't you agree? That sounds right. Would you like to post a proposed replacement (or patch) for the page as written which addresses your points? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem with KAI C++ and boost::type_traits
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: Sounds reasonable. Which makes me wonder if we shouldn't change the naming of branches a bit: We should have a branch for the development of new versions (1.30.x), let's call it DEVELOP_1_30_x. On this branch, we can now add several tags: Version_1_30_0_RC_1, Version_1_30_0_RC_2, Version_1_30_0, Version_1_30_1_RC_1, Version_1_30_1_RC_2, Version_1_30_1_RC_3, Version_1_30_1, etc. I'd prefer shorter names: v1_30-branch v1_30_0rc1 v1_30_0rc2 v1_30 ... The last one you showed is hopefully a typo. And I'd prefer to have a separator for the non-releases like the '-' anywhere: v1_30-branch v1_30_0-rc1 v1_30_0 v1_30_1-rc1 v1_30_1-rc2 v1_30_1 It's just an internal naming change that's not hugely exposed even to developers, so I don't feel strongly about it. I think it's up to Beman to decide what's best as he obviously has the most trouble with it anyway. :) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problem with KAI C++ and boost::type_traits
Daniel Frey [EMAIL PROTECTED] writes: David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: Sounds reasonable. Which makes me wonder if we shouldn't change the naming of branches a bit: We should have a branch for the development of new versions (1.30.x), let's call it DEVELOP_1_30_x. On this branch, we can now add several tags: Version_1_30_0_RC_1, Version_1_30_0_RC_2, Version_1_30_0, Version_1_30_1_RC_1, Version_1_30_1_RC_2, Version_1_30_1_RC_3, Version_1_30_1, etc. I'd prefer shorter names: v1_30-branch v1_30_0rc1 v1_30_0rc2 v1_30 ... The last one you showed is hopefully a typo. Yes. And I'd prefer to have a separator for the non-releases like the '-' anywhere: v1_30-branch v1_30_0-rc1 v1_30_0 v1_30_1-rc1 v1_30_1-rc2 v1_30_1 Why? -branch signifies that the tag acts differently, but rc1, rc2 et al are part of the version number. The only reason to use the underscores at all is that version numbers will eventually become ambiguous otherwise. It's just an internal naming change that's not hugely exposed even to developers, so I don't feel strongly about it. I think it's up to Beman to decide what's best as he obviously has the most trouble with it anyway. :) I'm sure the choice of names is not an obstacle for him. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: More EMPL Wiki nits (was: Boost MPL problem)
A. int_c et al are now int_ et al.
From previous post:
The quality of the Effective MPL (especially after the new MPL changes) is
not very good anyway. I would like to make a major overhaul, testing all
code examples, changing the code layout (moving it to docbook perhaps), and
making it 1.30.0 MPL conformant), but I won't have any time for at least
another three weeks. If somebody wants to beat me to it (Dirk?) great, but
otherwise it'll have to wait.
B. In item 5.3 you should probably suggest:
template class N
struct square
: integral_c typename N::value_type, N::value * N::value
{};
and later,
template long N
struct square_c : squarelong_N {};
Not only is it simpler, but it allows:
squareint_5 ::value
and:
greatersquare_1, 32
Agreed. Will make the change eventually.
Regards,
Jaap Suter
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Boost MPL problem
I've done it somewhat differently in the new code. Eh, whoops; your template invokes num_bits_set_impl, which isn't defined. Also, next is spelled netxt. I also think you may have a problem with eager evaluation or one too many ::type s. I think you should test these. Woops. I just woke up, read your message and changed it right away. Sounds like a case of get some coffee before you code. The quality of the Effective MPL (especially after the new MPL changes) is not very good anyway. I would like to make a major overhaul, testing all code examples, changing the code layout (moving it to docbook perhaps), and making it 1.30.0 MPL conformant), but I won't have any time for at least another three weeks. If somebody wants to beat me to it (Dirk?) great, but otherwise it'll have to wait. I also think it would be a great idea to have zero and one metafunctions (which also satisfy the integral constant wrapper requirements) If we wanted to get funky we could make it so zeroint_3 and zerolong both work. Those would be greatly appreciated, and very useful. Care to submit some files? This seems like a super-easy job. Sure thing. Done by next friday. but all of these ideas feel conceptually pretty hairy to me. Remember that the integral sequences are conceptually just convenient front-ends for regular type sequences. Yes, I tend to forget this because I never use type-lists directly, I only have a use for lists of compile-time constants at the moment. I ran into this exact same thing when I was trying to implement an mpl::set sequence. It worked fine for lists of constants. Types, however, aren't sortable, so it becomes really hard to implement for generic type sequences. One could implement a set that does not 'duplicate' values, but the following is harder because insertion order matters: typedef mpl::set float, int, bool set_0; typedef mpl::set bool, int, float, set_1; mpl::is_equal set_0, set_1 ::type // M, hard. I guess we could specialize algorithms for sets, but that defeats the purpose of having an iterator abstraction, etc. Oh well, I'm probably just overlooking something. I understand the need you have, but I am really unsure of the best way to address it. Well, I guess taking the value_type of the front isn't that bad then. Thanks for your help, Jaap Suter ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Boost MPL problem
Jaap Suter [EMAIL PROTECTED] writes:
One could implement a set that does not 'duplicate' values, but the
following is harder because insertion order matters:
typedef mpl::set float, int, bool set_0;
typedef mpl::set bool, int, float, set_1;
mpl::is_equal set_0, set_1 ::type // M, hard.
I think a set would have to be based on something like this:
struct set_base
{
typedef void_ type;
template class T struct apply : false_ {};
};
template class T, class B = set_base
struct set_node : B
{
typedef T type;
template class U struct apply : B::template applyU {};
};
// specialization for T
template class T, class B
struct set_nodeT,B::applyT : true_ {};
Now any set
set_nodeA, set_nodeB, set_nodeC
is a metafunction class which you can use to test membership.
s::applyint::type
And set equality can be tested in O(N) by iterating the first sequence
of nodes and asking whether each one's ::type is a member of the
other one.
**Note that determining that it's O(N) is an inexact science. It may
be strictly speaking O(N^2) but since the process of testing set
membership happens entirely within the compiler without causing new
instantiations, the constant is presumably tiny and we normally
treat that operation as O(1).
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problem with KAI C++ and boost::type_traits
David Abrahams [EMAIL PROTECTED] writes: signifies that the tag acts differently, but rc1, rc2 et al are part of the version number. The only reason to use the underscores at all is that version numbers will eventually become ambiguous otherwise. I'm even inclined to do as other projects do and kill all the underscores, waiting to deal with ambiguity until it arises. It's going to be a *long* time before we have numbers that could conflict. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 Random fails to compile on MSVC 6
Lapshin, Kirill [EMAIL PROTECTED] writes:
Hi All,
I posted this question on boost.users list but did not get any response.
My first attempt to switch my project from boost 1.29 to 1.30 failed
miserably due to compilation errors in random library.
Simple
#include boost/random/mersenne_twister.hpp
#include boost/random/normal_distribution.hpp
int main() {return 0;}
Fails with lots of error messages:
Nobody's been maintaining Boost.Random, so I think it has suffered
some code rot (not just on that compiler). We need someone to
volunteer to pay attention to its health.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Boost MPL problem
David Abrahams [EMAIL PROTECTED] writes: And set equality can be tested in O(N) by iterating the first sequence of nodes and asking whether each one's ::type is a member of the other one. Of course, that only tests for a subset relation. You need to do that twice to test a = b and b = a, where = means is subset. Still O(N). -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] A generic tree manipulation library
I'm very interested in having tree container concepts in Boost. The tree_node_map class provides an implementation to a basic tree node of variable branching size. The implementation here uses the std::map to implement the children, but this could equally be a std::list, std::vector or any suitable container; it could even be a low-level implementation (for performance) or a fixed-size array (for n-ary nodes). I've been implementing a tree class recently where each node has: Node* first_child; Node* next_sibling; I'm using new/delete currently, but was planning to use boost.Pool once my design has settled down. A std::map would be too much overhead for my particular application (which tends to have deep trees with few branches). I briefly played with one block of memory per branch and doing away with the first_child pointer, but decided to come back to that idea later. It has a problem with identifying the last node; either you need to store branch length, or a flag to mark the end (in which case you've saved no memory; still may have a speed advantage however). Finding the previous sibling or parent in my tree requires starting from the root node (or keeping a stack of nodes visited). The tree class is just a wrapper around a tree node that provides access to a root element. This would need some major work and additional support (e.g. post/pre/in-order traversal iterators) if it were to be useful. Do you have any example usage? I wonder if it would be better to approach this from the algorithms/iterators side and come to the containers later? I.e. what operations do you need to do on the trees? As a couple of examples I need: 1. for_each() of first child at each node. 2. display all node values in the tree on stdout. I'm not yet clear what I want from the second option there. Some kind of indenting I guess. BTW, I'm new to Boost. Is it normal to include all the Allocator stuff early on when discussing designs? I thought it would be grafted on at the end. Darren ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Lock Classes: FINAL POST
This is my final repost of my Lock Classes. If I do not get any
constructive feedback this time I am going to give up.
These classes have the following features:
1) The ability to acquire a lock and release it when the object
goes out of scope effectively implementing the Monitor concept.
2) Avoid the need for recursive locks by careful and efficient
book keeping with the out the use of global thread specific
data.
3) Document and enforce guaranteed lock behavior for functions
which take a lock class as a parameter.
Recursive locks may avoid the need for the bookkeeping. However recursive
looks are more expensive. Also, with recursive locks, as far as I know,
it is imposable to temporally release the lock. For example when calling
a network function I don't want to keep the lock as the object is in a
consistent state and holding the lock while waiting for a reply will
greatly reduce concurrency. My lock classes makes this possible to do
efficiently and safely as it is not possible to accentually call a
function that will release a lock without giving it permission to do so.
The only downside is that you have to explicit pass the lock around to
each function as a parameter. My recommendation is to use the lock
classes as parameters to private methods or functions which may call each
other and thus need to avoid acquiring a non recursive lock more than
once. Public members can than call the private members by simply
providing the function with the appropriate lock.
I have not seen anything quite like it so I thought I would share it here
and see what other people think.
Feedback on the idea or implementation welcome. This code, at the moment,
does not follow boost standards. If people think it is a worthy addition
to boost I will be willing to being it up to boost standards. But for
right now please refrain from making comments on coding style or the
like.
---
http://kevin.atkinson.dhs.org
// File: example.cpp
//
// Copyright (c) 2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without
// fee, provided that the above copyright notice appear in all copies
// and that both that copyright notice and this permission notice
// appear in supporting documentation. Kevin Atkinson makes no
// representations about the suitability of this software for any
// purpose. It is provided as is without express or implied
// warranty.
//
// Lock Example
#include lock.hpp
using namespace distribnet;
class MultithreadedObject
{
public:
void init();
void sync();
private:
void setup(LockState);
void modify1(WillOnlyLock);
void modify2(WillOnlyLock);
void modify3(WillOnlyLock);
void synchronize(WillLock);
void network_function(WillUnlock);
MultithreadedObject()
: counter(0), var1(10), var2(20) {}
int counter;
int var1;
int var2;
Mutex lock;
};
void MultithreadedObject::init()
{
{
Lock l(lock); // will automaticlly unlock at the end of the scope
counter = 0;
var1 = var2 = 99;
setup(l);
}
// now do things that don't need the lock
}
void MultithreadedObject::sync()
{
synchronize(lock); // simply passing in the lock. The lock classes will
// take care of the rest
}
void MultithreadedObject::setup(LockState l)
// will simply pass the lock state around to other functions that may
// lock or unlock
{
modify1(l);
synchronize(l);
}
void MultithreadedObject::modify1(WillOnlyLock)
// If not locked will lock when the function is called and unlock
// when the function returns. Will not unlock otherwise.
{
var1 = 111;
}
void MultithreadedObject::modify2(WillOnlyLock)
{
var2 = 222;
}
void MultithreadedObject::modify3(WillOnlyLock)
{
var2 = 333;
}
void MultithreadedObject::synchronize(WillLock l)
// If not locked will lock when the function is called and unlock
// when the function returns. But is allowed to also Unlock the
// mutex inside the function.
{
modify2(l);
network_function(l); // this is ok becuase I am allowed to unlock
modify3(l);
}
void MultithreadedObject::network_function(WillUnlock)
// If locked will unlock when the function is called and lock when the
// function returns. Also allowed to lock in the middle of the
// function.
{
// use network functions which may block for a long time
}
// File: lock.hpp
//
// Copyright (c) 2002,2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without
// fee, provided that the above copyright notice appear in all copies
// and that both that copyright notice and this permission notice
// appear in
[boost] Lock Classes: FINAL POST (fixed attch)
[The attachment got messed up in the last post. Hopefully, it will be OK
this time]
This is my final repost of my Lock Classes. If I do not get any
constructive feedback this time I am going to give up.
These classes have the following features:
1) The ability to acquire a lock and release it when the object
goes out of scope effectively implementing the Monitor concept.
2) Avoid the need for recursive locks by careful and efficient
book keeping with the out the use of global thread specific
data.
3) Document and enforce guaranteed lock behavior for functions
which take a lock class as a parameter.
Recursive locks may avoid the need for the bookkeeping. However recursive
looks are more expensive. Also, with recursive locks, as far as I know,
it is imposable to temporally release the lock. For example when calling
a network function I don't want to keep the lock as the object is in a
consistent state and holding the lock while waiting for a reply will
greatly reduce concurrency. My lock classes makes this possible to do
efficiently and safely as it is not possible to accentually call a
function that will release a lock without giving it permission to do so.
The only downside is that you have to explicit pass the lock around to
each function as a parameter. My recommendation is to use the lock
classes as parameters to private methods or functions which may call each
other and thus need to avoid acquiring a non recursive lock more than
once. Public members can than call the private members by simply
providing the function with the appropriate lock.
I have not seen anything quite like it so I thought I would share it here
and see what other people think.
Feedback on the idea or implementation welcome. This code, at the moment,
does not follow boost standards. If people think it is a worthy addition
to boost I will be willing to being it up to boost standards. But for
right now please refrain from making comments on coding style or the
like.
---
http://kevin.atkinson.dhs.org
// File: lock.hpp
//
// Copyright (c) 2002,2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without
// fee, provided that the above copyright notice appear in all copies
// and that both that copyright notice and this permission notice
// appear in supporting documentation. Kevin Atkinson makes no
// representations about the suitability of this software for any
// purpose. It is provided as is without express or implied
// warranty.
#ifndef DISTRIBNET_LOCK__HPP
#define DISTRIBNET_LOCK__HPP
namespace distribnet {
// These lock classes serve three functions:
//
// 1) The ability to aquire a lock and release it when the object
//goes out of scope effectvly implemented the Monitor concept.
//
// 2) Avoid the need for recursive locks by careful and efficient
//book keeping with the out the use of global thread specific
//data.
//
// 3) Document and enforce guaranteed lock behavior for functions
//which take a lock class as a parameter.
//
// The global lock used to initialize the lock classes.
class Mutex;
// The scoped lock classes:
class LockOnly; // If the lock is not already aquire it will do so
// and then release it at the end of the scope.
// It will not release it under any other
// circumstances.
class Lock; // Will aquire the lock if necessary but may also
// release it at any time. Do not call a function
// with this type of lock while in an inconsistent
// state.
class UnlockOnly; // If the lock is already aquired it will be
// released and then reaquire at the end of the
// scope. If will not aquire a lock under any
// other circumstances.
class Unlock; // If locked is it will be released it, however
// it may reaquire at any time. Do not call a
// function with this type of lock if it is
// unexceptable to wait for the lock to be
// reaquired.
// These locks should never be passed by value to functions.
// Instead use the following typedef to pass by reference:
typedef const LockOnlyWillOnlyLock;
typedef const LockWillLock;
typedef const UnlockOnly WillOnlyUnlock;
typedef const Unlock WillUnlock;
// The following lock states are also provided. When a functions
// takes one of these lock states as a parameter it may change the
// lock state at any time but then again it might not.
class MightLockUnlock; // Might aquire or release the lock or both.
typedef MightLockUnlock LockState; // alternate name
class MightLock; // Might aquire a lock but will not release it
[boost] Re: bad_lexical_cast
Since you advocate elsewhere that exception classes be derived from std::exception, the answer is because otherwise LSP would be violated. You can't access the derived class' assignment operator through a pointer/reference to a polymorphic base, so that point is moot. Well, you're the expert on this. (I thought you could catch a reference to an exception, dynamic_cast it downwards, then use the assignment operator. Sure, this would be a stupid thing to do, but if possible I certainly can imagine some few misguided souls who haven't yet grokked C++ exception handling doing so.) LSP is weird anyway. What's the point of polymorphism if you're not going to change the behavior of the class in some observable way? If the derived class were transparently substitutable for the base class it wouldn't be much good, would it? I disagree here; transparently substitutable != observable behaviour is identical. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] support for lookbehind assertions
Does anybody know if regex++ has support for lookbehind assertions, or if there is a way of achieving the same result with other expressions. Example lookbehind assertion: (?!\\), - match a [,] only when it is not preceeded by a [\] character ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [build system] Documentation error for Variant Descriptions
Firstly my thanks to everyone who worked so hard on boost 1_30_0.
Particularly all the that regression testing that went on.
On to the next release... One quick fix for the documentation for
Variant descriptions used in the build system
The syntax for defining parents (see features.jam) is missing. At the
moment the syntax descirbed in build_system.htm reads
variant name : [toolset-name]featurevalue... ;
The corrected syntax description (see boost-base.jam:757) is:
variant name : [parent-name : ] [toolset-name]featurevalue... ;
The descriptive text looks to be correct. It may be worth adding an
additional simple example so it reads:
Properties may be optionally qualified with a toolset name, which
specifies that the property applies only to that toolset.
variant my-debug-pedantic-gxx : debug : gcccxxflags-pedantic
One or .
At the moment I am also test driving Boost.build version 2. The design
is very attractive! I not sure were the best place to discuss issues
with v2 are? However just one quick pointer to a problem I am working on
but don't have a solution to as yet.
Problem: Build.v2 fails if any parent directory (above build point)
contains regex special charaters.
Reason: The directory path is itself used as a regex's template.
Location: rule all-parents (path.jam)
# Leave only directory names below 'upper_limits'
# Assure pruned_path[2] will have no leading '/'
local pruned_path = [ regex.match ($(upper_limit))/*(.*) :
$(rpath) : 1 2 ] ;
if ! $(pruned_path) {
I don't have a fix as am unsure of the Jam syntax for a simple (non
regex) match to do this job.
Any ideas of best solution?
Michael Stevens
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::any feature request
Hi Maxim,
I think it would be great to make boost::any's memory allocation
strategy for value holder customizable. It would allow to use not only
global new operator, but any other special fast allocators like, for
example, Loki::SmallObject.
The changes are minor and would not break existing code.
All it takes is to change class name and:
struct use_default_allocator {};
//class any
templateclass A = use_default_allocator class any_ex
And change any_cast functions appropriately.
Say, I have
std::mapstd::string, boost::any values;
Will I be able to write:
anyfast_allocator a;
values[10] = a;
?
IOW, I don't think your proposal provides any means to convert between 'any'
with different allocators. And I'm not sure you can easily achieve that
I've measured performance using Intel VTune. The
any_exLoki::SmallObject was about twice as fast as any_ex with MS
VC++ 7 and Intel C++ 7.
On what testcase?
So, the hardcoded memory allocation strategy makes more harm then good
to boost::any. Changes would make boost::any more extensible and
reusable.
Unless there's a way to convert between different any's, the idea is
questionable. Say, a library uses 'any' in interface. It certainly uses
default allocator, and without conversion, will impose that default allocator
on client code. IOW, you cannot write
anyfast_allocator a = some_lib::get_value(foo);
- Volodya
P.S. And, BTW, it would be great to see the complete code that you propose (or
a diff to CVS HEAD).
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::any feature request
Maxim Egorushkin wrote: I think it would be great to make boost::any's memory allocation strategy for value holder customizable. It would allow to use not only global new operator, but any other special fast allocators like, for example, Loki::SmallObject. I can add it to dynamic_any. All that I need is just an allocator interface. It would be also nice not to use dynamic allocations at all for built-in types. -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
