- Boost - lists.boost.org

Boost Threads - x86 Platforms / 64 bits compilation in Managed/Unmanaged Code / Visual Studio 2010 / Windows SDK 7.1 /clr
by Guillaume Rembert 07 May '12

07 May '12

As I had lots of issues to include boost thread libraries in a windows 64 bits code generated under Visual Studio 2010, here are the different steps to follow in order to get it compiling and executing quickly (mix of lots of the different specific posts). I could not find an easy, up to date procedure for this. This has been tested with Boost 1_49_0 release, Visual Studio 2010, Windows SDK 7.1 and Microsoft .NET 4. - Download 64 bits libraries, as binaries: http://boost.teeks99.com/ + unzip in a dedicated folder (for the example C:\boost\lib64) - Download boost headers and source code: http://sourceforge.net/projects/boost/files/boost/1.49.0/ + unzip in a dedicate folder (for the example C:\boost) - Set the project not to use precompiled headers + compilation with /clr to mix managed and unmanaged code - Add the headers path to the project additional include directories (in the example C:\boost) - Add the compiled libraries path to the linker additional library directories (in the example C:\boost\lib64) - Add to your project the following lines (force dynamic linking): #define BOOST_ALL_DYN_LINK #define BOOST_THREAD_USE_DLL #define BOOST_LIB_DIAGNOSTIC #include <boost/thread.hpp> --> Just compile and execute, it should not give any problems. The first line (#define BOOST_ALL_DYN_LINK) solves the following error I had: An unhandled exception of type 'System.TypeInitializationException' occurred in Unknown Module. Additional information: The type initializer for '<Module>' threw an exception.

2 1

[generic] status?
by lcaminiti 06 May '12

06 May '12

Hello all, What's the status of Matt Calabrese's Boost.Generic library? I was looking at the similarities between Boost.Generic and Boost.Contract syntax, and I think the following syntax can be implemented to define concepts, concepts_maps, axioms, etc CONTRACT_CONCEPT( concept (Iterator) ( typename X ) extends( Semiregular<X> ) ( typename(MoveConstructible) reference, as typename X::reference , typename(MoveConstructible) postinc_result , requires HasDereference<postinc_result> , (reference) operator(*)(deref) ( X& ) , (reference) operator(*)(deref) ( X&& ) , (X&) operator(++)(preinc) ( X& ) , (postinc_result) operator(++)(postinc) ( X&, int ) ) ) More examples here (auto concepts, concept maps, axioms, etc): http://contractpp.svn.sourceforge.net/viewvc/contractpp/trunk/doc/html/cont… If there was real interest using this syntax to define concepts, either the syntax could replace the on of Boost.Generic or Boost.Contract could provide the syntax and then use Boost.Generic behind the scene to actually define the concepts (same as Boost.Contract now does for Boost.Parameter). What do you think? Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-generic-status-tp4611363.html Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[concept] typenames vs. typedefs
by lcaminiti 06 May '12

06 May '12

Hello all, I have questions about concepts (it's related to Boost.ConceptCheckign and Boost.Generic, but it's really just about the concept syntax that was proposed and never adopted for C++11). What's the difference between typename new_type = old_type and typedef old_type new_type? Why are they both allowed? For example, what's the difference between this: auto concept HasFind < typename T > { typename key_type = typename T::key_type; // use typename typename mapped_type; std::pair<key_type, mapped_type> find ( T const&, key_type const& ); } And this: auto concept HasFind < typename T > { typedef typename T::key_type key_type; // use typedef typename mapped_type; std::pair<key_type, mapped_type> find ( T const&, key_type const& ); } Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-concept-typenames-vs-typedefs-tp46… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

question about C++11 guidelines
by Eric Niebler 06 May '12

06 May '12

Say I'm rewriting an existing Boost library and targeting C++11 users. I plan to ship C++03 and C++11 versions of my library side-by-side, so back-compat isn't an issue for the new code. Is there a reason to prefer using Boost's versions of utilities like enable_if, type traits, integral constant wrappers (e.g. mpl::int_), tuples, etc., over the now-standard ones? I'm leaning toward using std:: where I can, and falling back on Boost's versions only when there is a compelling reason. -- Eric Niebler BoostPro Computing http://www.boostpro.com

16 30

Latest version and status of lockfree
by Julien Nitard 06 May '12

06 May '12

Hi All, Where can I find the latest version of boost.lockfree ? There's nothing in the sandbox or the vault (it seems). The latest commit on Tim's public git repo was done more than 6 month ago. Now that atomic has been accepted, are there any roadblocks to have boost.lockfree released ? Many thanks, Julien

4 9

trac spam (was: [Boost C++ Libraries] #6866: affiliate revolution)
by Eric Niebler 06 May '12

06 May '12

Who maintains trac these days? Can we get this spammy ticket deleted? Thanks, Eric -------- Original Message -------- Subject: [Boost C++ Libraries] #6866: affiliate revolution Date: Fri, 04 May 2012 20:08:29 -0000 From: Boost C++ Libraries <noreply(a)lists.boost.org> CC: boost-bugs(a)lists.boost.org #6866: affiliate revolution ----------------------------------+----------------------------------------- Reporter: anonymous | Owner: eric_niebler Type: Tasks | Status: new Milestone: To Be Determined | Component: proto Version: Boost 1.37.0 | Severity: Cosmetic Keywords: affiliate revolution | ----------------------------------+----------------------------------------- [<link deleted> affiliate revolution] -- Ticket URL: <https://svn.boost.org/trac/boost/ticket/6866> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.

3 3

[polygon] Trunk write access
by Andrii Sydorchuk 05 May '12

05 May '12

I sent a message recently to the Boost owners list to get write access to the Boost trunk, but haven't got any response yet. I am going to merge lately discussed Voronoi library and some updates to the Boost.Polygon. Those are approved by the library owner: Simonson, Lucanus J. Sorry for the rush. Regards, Andrii

2 2

Red Hat Enterprise Linux Test Page
by Olaf van der Spek 05 May '12

05 May '12

Hi, This does not look right. ;) https://www.boost.org/ -- Olaf

3 2

[dynamic_bitset] Endianess and Adaption Vs Copying
by Joel 04 May '12

04 May '12

I've noticed that the dynamic_bitset seems to have endian issues. For masking out the ith bit in a block, it uses 1 shifted left by i. As a result, the bits are not consecutive. For example if the block_type is uint8_t, and we have 16 bits in the bitset, then bits are numbered: 00 01 02 03 04 05 06 07 15 14 13 12 11 10 09 08 in memory. That doesn't seem right---7th and 8th bits should be adjacent. Does anyone have suggestions for controlling this? Second, has anyone adapted dynamic_bitset to be an adaptor for an existing memory range to avoid copying? Thanks! Joel

4 9

[contract] syntax redesign
by Lorenzo Caminiti 04 May '12

04 May '12

Hello all, After a long time of inactivity for Boost.Contract, I am considering how to re-design its macro syntax to make it simpler. I can eliminate a large number of extra parenthesis based on a few pp tricks I've learned in processing Boost.Local's `const bind(type)& var`. Plus, I can provide (optional) support for variadics macros so to use comma-separated pp tuplets instead of parenthesized pp sequences on preprocessors with variadics. For example, I _think_ (but I've not implemented this yet) that I can simplify the syntax like this: #include <contract.hpp> #include <vector> #include "myvector/pushable.hpp" // Wrapper class that adds contracts to std::vector. CONTRACT_CLASS( template( typename T ) class (myvector) extends( public pushable<T> ) // Subcontracting. ) { CONTRACT_CLASS_INVARIANT( empty() == (size() == 0) // More invariants here (comma separated)... ) CONTRACT_FUNCTION( public void (push_back)( (const T&) element ) precondition( size() < max_size() // More preconditions here (comma separated)... ) postcondition( auto old_size = CONTRACT_OLDOF(size()), // Old value. size() == old_size + 1 // More postconditions here (comma separated)... ) ) { vector_.push_back(element); // Implementation. } // Rest of the class here (with more contracts if needed)... public: typedef typename std::vector<T>::size_type size_type; size_type size(void) const { return vector_.size(); } size_type max_size(void) const { return vector_.max_size(); } bool empty(void) const { return vector_.empty(); } const T& back(void) const { return vector_.back(); } private: std::vector<T> vector_; }; For a side-by-side comparison with N1962 syntax: http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/inde… For a comparison of the entire std::vector (plus Boost.ConceptCheck concepts): http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/cont… For a comparison for all Boost.Contract features (plus Boost.ConceptCheck concepts and Boost.Parameter named parameters): http://svn.boost.org/svn/boost/sandbox/contract/libs/contract/doc/html/cont… (Don't pay attention to the rest of the docs that are way out of date.) A few notes: * Extra parenthesis are still needed around class and function names. * Extra parenthesis are still needed around types (like for the parameter `(T) element`) but only if the type is not a C++ keyword (no parenthesis needed aournd int, double, void, etc) or it contains a symbol (parenthesis needed if & or * are used `(int&) x`, etc). * In postconditions, the `auto old_size = CONTRACT_OLDOF(size())` only copies the vector size (and not the entire vector :)) ). Similarly, `auto result = return` can be used to access the return value for non-void functions. (The `auto ...` is parsed by the pp and it's implemented using Boost.Typeof so no C++0x is required.) * Template declaration (but not instantiation) angular parenthesis <> are replaced by round parenthesis (). All of this _should_ be implementable in pure ISO C++. What do you think? Based on the discontent that the previous "parenthesized" syntax generated among Boosters, the key question is: Would you consider this new syntax usable?? Thanks, --Lorenzo

5 45