- Boost - lists.boost.org

[Boost-bugs] [ boost-Patches-1627420 ] [thread] MSVS: Allow use of thread headers with /Za
by SourceForge.net 04 Jan '07

04 Jan '07

Patches item #1627420, was opened at 2007-01-03 15:17 Message generated for change (Comment added) made by sohail_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: sohail (sohail_) Assigned to: Nobody/Anonymous (nobody) Summary: [thread] MSVS: Allow use of thread headers with /Za Initial Comment: The following code will not compile if built with /Za on Visual C++ 7.1+: #include <boost/thread/once.hpp> int main(){} It will fail with the following assertion: # error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" The reason is that the Boost.Config machinery realizes that you cannot use the Windows API unless you enable language extensions. As a result, threads cannot be available. This is correct behaviour when you are indeed *using* the Windows API. However, in the above case where you separately compile the threads library, you do not actually use the Windows API => language extensions are not necessary => no need to explicitly specify BOOST_DISABLE_WIN32. I therefore submit that there be some machinery/configuration variables to allow libraries to specify whether or not they require the Windows API. The proposed patch does not modify existing behaviour. That is, if the config machinery decides that the API is needed, it is required, unless explicitly disabled. The code to do this in library xyz would look something like this: #if defined(BOOST_BUILDING_WHATEVER) # define BOOST_NO_REQUIRE_WIN32 #endif #include <boost/config.hpp> I am uncertain of the exact name of the macro that is required but I am certain a macro is required. The attached patch is against 1.33.1. I don't think there is any rush to put this into 1.34. I'm pretty sure it would be nice, but people can manually patch it until 1.35 whenever that is released. Thanks, Sohail ---------------------------------------------------------------------- >Comment By: sohail (sohail_) Date: 2007-01-03 15:40 Message: Logged In: YES user_id=1682817 Originator: YES File Added: boost_no_require_win32.patch ---------------------------------------------------------------------- Comment By: sohail (sohail_) Date: 2007-01-03 15:25 Message: Logged In: YES user_id=1682817 Originator: YES That should be: #if !defined(BOOST_BUILDING_WHATEVER) :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1627420 ] [thread] MSVS: Allow use of thread headers with /Za
by SourceForge.net 04 Jan '07

04 Jan '07

Patches item #1627420, was opened at 2007-01-03 15:17 Message generated for change (Comment added) made by sohail_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: sohail (sohail_) Assigned to: Nobody/Anonymous (nobody) Summary: [thread] MSVS: Allow use of thread headers with /Za Initial Comment: The following code will not compile if built with /Za on Visual C++ 7.1+: #include <boost/thread/once.hpp> int main(){} It will fail with the following assertion: # error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" The reason is that the Boost.Config machinery realizes that you cannot use the Windows API unless you enable language extensions. As a result, threads cannot be available. This is correct behaviour when you are indeed *using* the Windows API. However, in the above case where you separately compile the threads library, you do not actually use the Windows API => language extensions are not necessary => no need to explicitly specify BOOST_DISABLE_WIN32. I therefore submit that there be some machinery/configuration variables to allow libraries to specify whether or not they require the Windows API. The proposed patch does not modify existing behaviour. That is, if the config machinery decides that the API is needed, it is required, unless explicitly disabled. The code to do this in library xyz would look something like this: #if defined(BOOST_BUILDING_WHATEVER) # define BOOST_NO_REQUIRE_WIN32 #endif #include <boost/config.hpp> I am uncertain of the exact name of the macro that is required but I am certain a macro is required. The attached patch is against 1.33.1. I don't think there is any rush to put this into 1.34. I'm pretty sure it would be nice, but people can manually patch it until 1.35 whenever that is released. Thanks, Sohail ---------------------------------------------------------------------- >Comment By: sohail (sohail_) Date: 2007-01-03 15:25 Message: Logged In: YES user_id=1682817 Originator: YES That should be: #if !defined(BOOST_BUILDING_WHATEVER) :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1627420 ] [thread] MSVS: Allow use of thread headers with /Za
by SourceForge.net 04 Jan '07

04 Jan '07

Patches item #1627420, was opened at 2007-01-03 15:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: sohail (sohail_) Assigned to: Nobody/Anonymous (nobody) Summary: [thread] MSVS: Allow use of thread headers with /Za Initial Comment: The following code will not compile if built with /Za on Visual C++ 7.1+: #include <boost/thread/once.hpp> int main(){} It will fail with the following assertion: # error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" The reason is that the Boost.Config machinery realizes that you cannot use the Windows API unless you enable language extensions. As a result, threads cannot be available. This is correct behaviour when you are indeed *using* the Windows API. However, in the above case where you separately compile the threads library, you do not actually use the Windows API => language extensions are not necessary => no need to explicitly specify BOOST_DISABLE_WIN32. I therefore submit that there be some machinery/configuration variables to allow libraries to specify whether or not they require the Windows API. The proposed patch does not modify existing behaviour. That is, if the config machinery decides that the API is needed, it is required, unless explicitly disabled. The code to do this in library xyz would look something like this: #if defined(BOOST_BUILDING_WHATEVER) # define BOOST_NO_REQUIRE_WIN32 #endif #include <boost/config.hpp> I am uncertain of the exact name of the macro that is required but I am certain a macro is required. The attached patch is against 1.33.1. I don't think there is any rush to put this into 1.34. I'm pretty sure it would be nice, but people can manually patch it until 1.35 whenever that is released. Thanks, Sohail ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1627420&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Now config macro : BOOST_NO_TWO_PHASE_NAME_LOOKUP
by AlisdairM 04 Jan '07

04 Jan '07

I have just supplied John with a new defect macro and test case to detect compilers that (do not) support 2-phase name lookup with templates, but it would be really helpful if someone who is more familiar with the problem (and access to conforming compilers!) can verify the test for us! The test case is in boost/libs/config/boost_no_two_phase_name_lookup.ipp and currently the code looks like: template< class T > struct base { int call() { return 1; } }; int call() { return 0; } template< class T > struct derived : base< T > { int call_test() { return call(); } }; int test() { derived< int > d; return d.call_test(); } I believe a conforming compiler should only find the 'free' function, where a broken compiler will typically call the function from its base class template. Also, beware of config test failures until the various compiler config headers are updated. This should also give us a good idea of whether the right compilers are being flagged! -- AlisdairM

4 4

Re: [boost] [Threads] Language extensions + MSVC (possible patch with new config)
by Sohail Somani 03 Jan '07

03 Jan '07

> I would appreciate any feedback towards a possible patch. I > am currently running the boost thread tests and hoping that > they don't fail ;) If all goes well, I will rebuild the rest > of boost as well and run tests there. FYI, I've tweaked the boost thread tests to disable language extensions with a modification of the patch I sent earlier. The tests compile and pass both with and without language extensions. Indeed, boost threads builds as it used to as well although the patch does alter this part of boost. If my jam-fu was any good, I'd figure out how to test both combinations automagically if it were necessary. The modification of the patch I sent earlier was basically to have thread/detail/config to say: if msvc && using thread library: // don't need windows api define BOOST_NO_REQUIRE_WIN32 else: // not msvc or building thread library pass Can I get some direction from someone who cares about this? Thank you! Sohail

1 0

Re: [boost] Boost threads + MSVSC + /Za + client code
by Sohail Somani 03 Jan '07

03 Jan '07

Hi John, Thank you for your response. > This may prove to be a tricky one: I think we can safely link > to the thread > lib when building with /Za, but I suspect that there are > other libraries > that depend on BOOST_HAS_THREADS as well: in fact a quick > search through the > headers showed rather a lot of uses, some relate to use of > Boost.Threads, > but many don't. Currently I'm of the (possibly misguided) opinion that the issue is not really whether or not one has the thread library, but whether or not language extensions are required to use header XYZ. That could be the easier solution, if it is indeed the right one. And it could be applied on a per-library basis as needed. > I guess we could invent a new macro BOOST_HAS_THREAD_LIB or > something, but > then to be consistent, we would have to change some but not > all uses of > BOOST_HAS_THREADS in other libraries to this new macro. > Tricky to get it > all right. > > Also, haven't some of the Boost.Thread components become > header only now? > Will these still work with /Za? I hope they do! Perhaps running tests should disallow language extensions (via /Za)? I can imagine a lot of boost users need to run on different compilers/platforms and having language extensions turned off will help. As a side note, it seems that MSVC 8 turns language extensions *on* by default. It has been jokingly said that /Za is deprecated ;) Sohail

2 1

[Boost.TypeTraits] is_virtual_base_of
by Javier Estrada 03 Jan '07

03 Jan '07

While going through the TR1 book from Pete Becker, I noticed that the type traits, which is based on Boost.TypeTraits, does not have a is_virtual_base_of traits, and I'm wondering whether such trait would be (a) possible (b) different from what is_base_of currently provides and (c) useful for any metaprogramming purposes. Regards, Javier

1 0

Review request: Boost.FSM
by Andrey Semashev 03 Jan '07

03 Jan '07

Hi, I would like to ask for a formal review of the Boost.FSM library proposed here not long ago. I've uploaded the implementation, test and documentation into Boost.Vault, it is accessible with this link: http://tinyurl.com/yjozfn There were several changes in the library since the proposal: - Integral constants tagged events support added - Transitions maps support improved. Each transition may now decide in run-time to which state to transit. The transition map itself may be broken into several pieces - the common part and state-specific parts. - Added an implementation of thread-locking state machine. It is quite equivalent to the "state_machine" class but adds a tiny synchronization layer between environment and the machine. - The library has been split into several headers and put into its own directory. - The documentation have been improved. -- Best regards, Andrey mailto:andysem@mail.ru PS: Happy New Year everyone!

4 4

Re: [boost] Boost threads + MSVSC + /Za + client code
by Sohail Somani 03 Jan '07

03 Jan '07

Hi Anthony, Thanks for your response. > if BOOST_DISABLE_WIN32 is > defined and > BOOST_HAS_PTHREADS is not; the implication is that if you > can't use the > Windows headers, then you can't use the Windows thread API, > so if we haven't > got pthread-win32 configured, you can't use Boost threads. This pretty much sums it up, yes. > I am not sure what we can do about this. One issue is that > currently the > thread lib requires windows.h, and therefore compiler > extensions, when the > library sources are built. I'm not sure whether it is safe to > link something > compiled with extensions on against something compiled with > extensions off --- > is the ABI the same? If it *is* safe, then we should remove > this define from > boost/config/suffix.hpp, since the boost thread headers don't > explicitly > include windows.h. I think this is correct but I think the restriction only makes sense if you are building the thread library. Atleast the 1.33.1 code appears to have been written such that headers don't require language extensions. My gut feeling is that a solution like this should work: // BOOST_BUILDING is defined whenever building a boost library #if defined(BOOST_BUILDING) && defined(BOOST_MSVC) # define BOOST_REQUIRE_MSVC_LANGUAGE_EXTENSIONS #endif #include <boost/config/requires_threads.hpp> #if defined(BOOST_REQUIRE_MSVC_LANGUAGE_EXTENSIONS) # undef BOOST_REQUIRE_MSVC_LANGUAGE_EXTENSIONS #endif > OTOH, someone put the restriction there for a reason, and I > wouldn't want to > remove it without careful thought. Of course. Thanks again, Sohail

1 0

Naming of Boost.Graph binary
by David Abrahams 03 Jan '07

03 Jan '07

The binary for Boost.Graph is named differently from all the other library binaries; in particular it is called libbgl-viz-xxx rather than libboost_graph-xxx. This is going to complicate the Getting Started Guide, and although I understand the desire to make it clear that the library is only needed for use with GraphViz, I wonder if this nonuniformity is really worth the price. Can we change the name? We can always install aliases on *nix to smooth the transition. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2