patrick, thanx for the suggestion. i am actually a fan of ace myself and i have happily used it before the problem is: nowadays it is becoming more and more common for non-cs depts. to try and write reusable, near-commercial quality code. this is true at least for some major private universities that i know of. that typically happens because companies who supply research funds expect to see software that is immediately useful, not just proof of concept coding. in other words, we are supposed to deliver quality scientific c++ libraries and software that implements all the research that's going on in the dept. given that, sticking with a single 3rd party library for such fundamental tools makes sense for several reasons: (1) when a new student arrives, you tell him/her to go to boost.org and start reading and that's the only burden. you don't also say, "oh, also read about ace, etc.". these people do not need to be very fluent in c++ ( remember, we are talking about non-cs engineering students ) so it's only confusing to force them to use different interface styles. boost interfaces sometimes vary to but at least the overall 'feel' of them is unified and in sync with the standard library (2) when a company wants to use the code, they only need to download and compile boost and our code and nothing else. the less 3rd party dependency, the better (3) and, finally, it is much easier to justify the use of boost than any other library out there. i can simply say "some of their sub-libraries are gonna make it to the next standard" and "they have c++ standards committee members on board" and will persuade even the biggest anti-open-source zealot for the above reasons, we prefer to use a boost sub-library whenever we can rather than using some other 3rd party library regardless of how high quality it might be. 'hope this explains the situation ... everyone, thanks for the responses. i guess, this means, i can start using the lib and then incorporating the changes is not gonna be a big problem. great! one question, though: i understand thread cancellation is gonna be one of the topics to work on. to be honest, it is gonna be quite important for us in the future. do you think it will be safe to say at least an alpha level work on this issue will be available within the next 6 months? although i don't consider myself a threading guru, as i mentioned before, i'll help out as much as i can towards such a goal burch Bennett, Patrick <Patrick.Bennett <at> inin.com> writes:
Honestly, I'd suggest you just use ACE for threading/synchronization primitives. It's available for a large number of platforms and is heavily used and frequently updated. I like Boost a lot, but I think some people are trying to make Boost more than (IMO) it should be. People discussing efficient io dispatch techniques for example would be better served to just use ACE, which already does many of these things extremely well. (http://www.cs.wustl.edu/~schmidt/ACE.html)
Just my (possibly unwanted) $.02.
Patrick
If I have a vc7.1 source file with nothing but: #include "stdafx.h" #include <boost/bind.hpp> #include <boost/variant.hpp> I get the following errors: c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\mpl\less.hpp(39) : error C2760: syntax error : expected ',' not ';' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\mpl\less.hpp(51) : see reference to class template instantiation 'boost::mpl::less<T1,T2>' being compiled c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\mpl\less.hpp(39) : error C2144: syntax error : 'const bool' should be preceded by '}' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\mpl\less.hpp(39) : error C2062: type 'const bool' unexpected c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\mpl\less.hpp(39) : error C2238: unexpected token(s) preceding ';' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\mpl\less.hpp(42) : error C2065: 'value' : undeclared identifier The problems go away if I include variant.hpp first. Any ideas? Thanks, Brock
Brock Peabody wrote:
If I have a vc7.1 source file with nothing but:
#include "stdafx.h"
#include <boost/bind.hpp> #include <boost/variant.hpp>
I get the following errors:
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\mpl\less.hpp(39) : error C2760: syntax error : expected ',' not ';'
Nice bug. I think that it's triggered by the "value<" sequence in the code below: enum { msvc71_wknd_ = ( BOOST_MPL_AUX_VALUE_WKND(T1)::value < BOOST_MPL_AUX_VALUE_WKND(T2)::value ) }; when the compiler has already seen a template class named "value" (it tries to keep track of class templates in order to not require typename). You can work around the problem by replacing the above with enum { msvc71_wknd_ = ( BOOST_MPL_AUX_VALUE_WKND(T2)::value > BOOST_MPL_AUX_VALUE_WKND(T1)::value ) }; I've commited the fix to the CVS HEAD as it seems fairly harmless (he said before breaking all other compilers). ;-)
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov
Nice bug. I think that it's triggered by the "value<" sequence in the code below:
enum { msvc71_wknd_ = ( BOOST_MPL_AUX_VALUE_WKND(T1)::value < BOOST_MPL_AUX_VALUE_WKND(T2)::value ) };
when the compiler has already seen a template class named "value" (it tries to keep track of class templates in order to not require typename).
Wild!
You can work around the problem by replacing the above with
enum { msvc71_wknd_ = ( BOOST_MPL_AUX_VALUE_WKND(T2)::value > BOOST_MPL_AUX_VALUE_WKND(T1)::value ) };
I've commited the fix to the CVS HEAD as it seems fairly harmless (he said before breaking all other compilers). ;-)
It worked for me, thanks!
Brock Peabody wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov
Nice bug. I think that it's triggered by the "value<" sequence in the code below:
enum { msvc71_wknd_ = ( BOOST_MPL_AUX_VALUE_WKND(T1)::value < BOOST_MPL_AUX_VALUE_WKND(T2)::value ) };
You can work around the problem by replacing the above with
enum { msvc71_wknd_ = ( BOOST_MPL_AUX_VALUE_WKND(T2)::value > BOOST_MPL_AUX_VALUE_WKND(T1)::value ) };
I've commited the fix to the CVS HEAD as it seems fairly harmless (he said before breaking all other compilers). ;-)
Shouldn't that be ">=" ??? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
--- Peter Dimov <pdimov@mmltd.net> wrote: [...]
enum { msvc71_wknd_ = ( BOOST_MPL_AUX_VALUE_WKND(T1)::value < BOOST_MPL_AUX_VALUE_WKND(T2)::value ) };
when the compiler has already seen a template class named "value" (it tries to keep track of class templates in order to not require typename).
You can work around the problem by replacing the above with
enum { msvc71_wknd_ = ( BOOST_MPL_AUX_VALUE_WKND(T2)::value > BOOST_MPL_AUX_VALUE_WKND(T1)::value ) };
Another workaround is to replace it with enum { msvc71_wknd_ = BOOST_MPL_AUX_VALUE_WKND(T1)::value < BOOST_MPL_AUX_VALUE_WKND(T2)::value }; Somehow the parenthesis make the difference... weird. I submitted a bug report last night. Eugene __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html
Brock "Brock Peabody" <brock.peabody@npcinternational.com> wrote in message news:004701c3ecea$d06eca90$360010ac@npci.com...
If I have a vc7.1 source file with nothing but:
#include "stdafx.h"
#include <boost/bind.hpp> #include <boost/variant.hpp>
I get the following errors:
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\boost\mpl\less.hpp(39) : error C2760: syntax error : expected ',' not ';'
[snip]
The problems go away if I include variant.hpp first. Any ideas?
Do you mean: #include <boost/variant.hpp> #include "stdafx.h" #include <boost/bind.hpp> If so and you are using precompiled headers, then #include <boost/variant.hpp> will be ignored. Otherwise, I've not used variant yet. :( Jeff F
"Burc Arpat" <burch@stanford.edu> wrote in message news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAuNR7Z88Qb0eVToFdSB8PXsKAAAAQAAAA/KlPjPzPXkmxgDUd2Qd6sgEAAAAA@stanford.edu...
one question, though: i understand thread cancellation is gonna be one of the topics to work on. to be honest, it is gonna be quite important for us in the future. do you think it will be safe to say at least an alpha level work on this issue will be available within the next 6 months?
Thread cancellation in C++ is a difficult and often contentious topic, so I don't think it would be safe to say that. However, there is at least the beginning of a thread cancellation implementation in the thread_dev branch in CVS. I haven't looked at it yet to see how (in)complete it is.
although i don't consider myself a threading guru, as i mentioned before, i'll help out as much as i can towards such a goal
burch
Boost library, in general, is often appreciated for its minimal, yet complete and portable implementations of various concepts. Considering that thread cancellation, along with other thread control methods such as stop, resume, suspend etc, is either purposefully not supported or made deprecated in other libraries, including Java threads (forgive me for daring to leave C++ realm), wouldn't it be wise not to include such feature at all? Slawomir Lisznianski; [ www.rhapsodia.org ] Michael Glassford wrote:
"Burc Arpat" <burch@stanford.edu> wrote in message news:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAuNR7Z88Qb0eVToFdSB8PXsKAAAAQAAAA/KlPjPzPXkmxgDUd2Qd6sgEAAAAA@stanford.edu...
one question, though: i understand thread cancellation is gonna be
one of
the topics to work on. to be honest, it is gonna be quite important
for us
in the future. do you think it will be safe to say at least an
Thread cancellation in C++ is a difficult and often contentious topic, so I don't think it would be safe to say that. However, there is at least the beginning of a thread cancellation implementation in the thread_dev branch in CVS. I haven't looked at it yet to see how (in)complete it is.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Behalf Of Slawomir Lisznianski Subject: [boost] thread cancellation
Boost library, in general, is often appreciated for its minimal, yet complete and portable implementations of various concepts. Considering that thread cancellation, along with other thread control methods such as stop, resume, suspend etc, is either purposefully not supported or made deprecated in other libraries, including Java threads (forgive me for daring to leave C++ realm), wouldn't it be wise not to include such feature at all?
Slawomir Lisznianski; [ www.rhapsodia.org ]
I think I agree, but I'm uncertain. Overcoming problem with cancellation and exceptions is a big issue. David Abrahams is rightfully very pedantic about this and once he is happy with the exception model and others are happy with the cancellation mechanism I think there might be a way forward. Meanwhile, just think of cancellation as poor design ;-) I haven't written a program that cancels a thread for quite a while, though I would have liked to, but have always preferred a different design to the problem. I do need to set thread priorities however. This is more important to me than cancellation. Matt Hurd.
Kind of unrelated but I thought I'd ask here as the original author of this thread lib is among the missing. I'd like to create a basic condvar implementation for the (windows version of the) D programming language and obviously don't want to have to invent one from scratch. Is there another good implementation in the public domain or is the boost version it? And if I used the boost implementation as a template, would it be necessary and sufficient for me to include the copyright notice? It would be a total rewrite, but I'd still consider it a derivative work of whatever it was based on. Sean
Sean Kelly wrote:
Kind of unrelated but I thought I'd ask here as the original author of this thread lib is among the missing. I'd like to create a basic condvar implementation for the (windows version of the) D programming language and obviously don't want to have to invent one from scratch. Is there another good implementation in the public domain or is the boost version it? And if I used the boost implementation as a template, would it be necessary and sufficient for me to include the copyright notice? It would be a total rewrite, but I'd still consider it a derivative work of whatever it was based on.
http://sources.redhat.com/ml/pthreads-win32/2004/msg00005.html http://sources.redhat.com/ml/pthreads-win32/2004/msg00007.html http://sources.redhat.com/ml/pthreads-win32/2004/msg00008.html regards, alexander.
On Behalf Of Sean Kelly Subject: [boost] Re: future of boost.threads
Kind of unrelated but I thought I'd ask here as the original author of this thread lib is among the missing. I'd like to create a basic condvar implementation for the (windows version of the) D programming language and obviously don't want to have to invent one from scratch. Is there another good implementation in the public domain or is the boost version it? And if I used the boost implementation as a template, would it be necessary and sufficient for me to include the copyright notice? It would be a total rewrite, but I'd still consider it a derivative work of whatever it was based on.
Sean
Sean, See no reason why you can't use the boost implementation with acknowledgement. The ACE license is pretty close to public domain and it has a condition variable that has been around for many years: <quote> Detailed Description template<class MUTEX> class ACE_Condition< MUTEX > ACE_Condition variable wrapper, which allows threads to block until shared data changes state. A condition variable enables threads to atomically block and test the condition under the protection of a mutual exclu- sion lock (mutex) until the condition is satisfied. That is, the mutex must have been held by the thread before calling wait or signal on the condition. If the condition is false, a thread blocks on a condition variable and atomically releases the mutex that is waiting for the condition to change. If another thread changes the condition, it may wake up waiting threads by signaling the associated condition variable. The waiting threads, upon awakening, reacquire the mutex and re-evaluate the condition. Note, you can only parameterize <ACE_Condition> with ACE_Thread_Mutex, ACE_Recursive_Thread_Mutex, or ACE_Null_Mutex. </quote> It is a good idea to be familiar with ACE if you are approaching this. ACE is an excellent library for concurrency, however its C++ is showing both its age and many compromises to support an amazing number of platforms. ACE categories are here: http://www.cs.wustl.edu/~schmidt/ACE_wrappers/docs/ACE-categories.html ACE home is: http://www.cs.wustl.edu/~schmidt/ACE-documentation.html Regards, Matt Hurd.
On Fri, 6 Feb 2004, Burc Arpat wrote:
(3) and, finally, it is much easier to justify the use of boost than any other library out there. i can simply say "some of their sub-libraries are gonna make it to the next standard" and "they have c++ standards committee members on board" and will persuade even the biggest anti-open-source zealot
Consider yourself lucky. My current employer won't have anything to do with Boost because of the very open licensing scheme. The argument seems to be that they won't use any product lacking a legally assailable entity, I assume in case the code is stolen and they are sued for copyright infringement. I had to fight tooth and nail in order to use zlib for a project not too long ago, and they mostly agreed because I couldn't find a gzip capable library that was for sale. I suspect there are many other companies out there just like mine, who don't care about what is "standard" so much as about liability. And while I have major issues with this mindset, I think it's an important one to be aware of. Sean
participants (11)
-
Alexander Terekhov -
Brock Peabody -
Burc Arpat -
E. Gladyshev -
Jeff Flinn -
Matthew Hurd -
Michael Glassford -
Peter Dimov -
Rene Rivera -
Sean Kelly -
Slawomir Lisznianski