May 2013 - Boost - lists.preview.boost.org

[Interprocess] Named Pipe status
by Geoff Shannon 17 May '13

17 May '13

Hi, I'm interested in writing a named pipe implementation for Boost.Interprocess (mostly since I would like to use it myself!). I was curious if anyone knew if there has already been design work done on a desired interface, or if there is actual work underway (I wasn't able to find any evidence of either but I'm normally just a boost user). Also, any comments/suggestions on what would be desired out of such a feature are much appreciated. thanks, -- Geoff Nothing is ever easy.

2 1

[string_ref] Add an equality operator between string_ref and char*
by Nicola Bizzoca 17 May '13

17 May '13

Hi, string_ref currently lacks of a simple and efficient way to compare a string_ref data to a C style string The current way that string_ref promotes is: string_ref_data.compare("boost(a)lists.boost.org") == 0 It's error prone (always checking for 0, < 0, > 0) and involves a series of implicit casting (from char* to string, and from string to string view) The same it's valid for comparing string_ref to string, but is this case an implicit casting from string to string_ref is much less expensive

1 0

[tti] Will TTI be in 1.54?
by Jeremiah Willcock 17 May '13

17 May '13

Is TTI planned to be in the next release? I have some changes to Boost.Graph that have been in the trunk for a while but depend on TTI to enable backwards compatibility, and it would be nice to have them in a release. Will that be available in the release branch soon so I can test against it? Thank you. -- Jeremiah Willcock

3 5

[config] BOOST_FORCEINLINE for clang
by Vicente J. Botet Escriba 16 May '13

16 May '13

Hi, I would like to add the definition of BOOST_FORCEINLINE for clang when __has_attribute(always_inline) // BOOST_FORCEINLINE ---------------------------------------------// #if !defined(BOOST_FORCEINLINE) # if defined(_MSC_VER) # define BOOST_FORCEINLINE __forceinline +# elif defined(__clang__) +# if __has_attribute(always_inline) +# define BOOST_FORCEINLINE inline __attribute__((always_inline)) +# endif # elif defined(__GNUC__) && __GNUC__ > 3 # define BOOST_FORCEINLINE inline __attribute__ ((always_inline)) # else Could I commit it? Best, Vicente

7 11

determine first arg of callable
by Oliver Kowalke 16 May '13

16 May '13

I need some help to extract the type of a callable which is passed as argument to the ctor of X. struct X { template< typename Fn > X( Fn fn) { ... code which evaluates Fn and extracts the type of the first arg of Fn } }; void f( int) {...} struct A { void operator()( char) {...} void g( string) {... } }; The code should evaluate in the ctor to the arguments of the callables: A a; X x1( f); -> int X x2( a); -> char X x3( bind( & A::g, a, _1) ); -> string I could overload the ctor of X for function pointers: template< typename Arg > X( void(*fn)( Y< Arg > &) ) {...} but how to deal with the other two callable types? result_of and function_traits did not work for me. Oliver

7 25

[Proposal] A little reasonable modification of boost::bind_t
by Arthur Athrun 16 May '13

16 May '13

Hi, everyone, I'd like to propose a little modification of boost:: bind to expose more information in boost:: _bi:: bind_t. Here is my motivation problem. Suppose this is a function which takes boost: :_bi::bind_t as a parameter. But at the same time, I'd like to enumerate all binded parameters and do something for specific types, like the following pseudo code shows. template< class F> void foo(F & f) { foreach(T& arg, f.arguments()) { if(boost::is_same<T, ID_t>::value) //here ID_t is a user specific type //do something for arg. } } I found that all binded arguments are stored in a listN object. But unfortunately, the list object (L _l in boost::_bi::bind_t) is set to private access and there is no method to boost::_bi::bind_t to access the listN object and the type of listN. I don't know why you developers didn't provide a method to access the listN object. But it seems reasonable to provide a public method in <boost\bind\bind_template.hpp>, like this typedef L argu_type; const L & arguments() const {return l_;} Also, the class "template<class T> class value" in <boost\bind.hpp> doesn't provide any access to T. It will be reasonable to add access of type T, like this public: typedef T val_type; With such modifications, we can access all binded arguments in the boost::_bi::bind_t. Here is a showcase. template<class T, class VT>void Test(VT t, T * p = 0) { //This parameter is not binded, so ignore it! }template<class T, class VT>void Test(VT t, typename T::val_type * p = 0) { //T::val_type is the parameter's type， //and can use boost::is_same<T::val_type, ID_t>::value to check it! std::cout<<"great! we get a value here!"<<t.get()<<std::endl; } template <class R, class F, class A1, class A2>void retrive_args(boost::_bi::bind_t<R, F, boost::_bi::list2<A1, A2> > & f) { Test<A1>(f.arguments()[_1]); Test<A2>(f.arguments()[_2]); } int f(int a, double b) { std::cout<<a<<std::endl; return a; } int main(int argc, char * argv[]) { double t = 1.0; retrive_args(boost::bind(f, _1, 0.2)); //Here will retrive the second parameters only. return 0; } I don't know if I get the right way to implement it. Please let me know if you have another implementation. Any comments or ideas will be appreciated. Thanks. -- Athrun Arthur Cluster and Grid Computing Lab (CGCL) Services Computing Technology and System Lab (SCTS) School of Computer Science and Technology (CS) Huazhong University of Science and Technology (HUST) Wuhan, 430074, China EMail:athrunarthur@gmail.com

4 3

[spirit][lex] remove_referece necessary for lex::less
by Andreas Pokorny 14 May '13

14 May '13

Hi, Can I apply that patch? Index: boost/spirit/home/lex/lexer/support_functions.hpp =================================================================== --- boost/spirit/home/lex/lexer/support_functions.hpp (revision 84231) +++ boost/spirit/home/lex/lexer/support_functions.hpp (working copy) @@ -47,11 +47,13 @@ template <typename Env> struct result { - typedef typename - remove_const< - typename mpl::at_c<typename Env::args_type, 4>::type - >::type - context_type; + typedef + typename remove_reference< + typename remove_const< + typename mpl::at_c<typename Env::args_type, 4>::type + >::type + >::type + context_type; typedef typename context_type::base_iterator_type type; };

2 3

Re: [boost] Embedding manifest into the regression tests (was: [testers] [log] Problems with tests)
by Holger Grund 14 May '13

14 May '13

VC++ 10 and 11 dont use sxs isolation for runtime libs any more. IOW, you dont need a manifest for the CRT in VS2010&2012. Regards -hg Sent from Samsung MobileAndrey Semashev <andrey.semashev(a)gmail.com> wrote:On Monday 13 May 2013 20:39:21 Daniela Engert wrote: > Am 13.05.2013 19:50, schrieb Andrey Semashev: > > On Monday 13 May 2013 16:06:01 Sergey Cheban wrote: > >> [snip] > >> The bjam scripts embed the manifest into the executable if it was > >> generated by the linker. And the linker generates the manifest by > >> default if the /manifestdependency option was specified. > >> > >> May be, it is reasonable to add the "/MANIFEST" to the linker options > >> explicitly. > > > > I know little about Windows manifests, but if I'm not mistaken, > > /manifestdependency describes the dependency to be put in the manifest and > > /MANIFEST only tells the linker to generate the .manifest file. If MSVC 10 > > and 11 removed their /manifestdependency then what should be put into the > > manifest? > > Is this really about dependency? In Visual Studio, MSBuild is configured > to insert this into .exe link options by default: > > /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed From MSDN ([1], [2]) this seems to be the default, if manifest is generated. I'm not sure what is the problem with manifests as it seems it should be generated by default. So either it is not generated when there are no /manifestdependency entries or I'm missing something. I hope someone with more experience can comment on this. [1] http://msdn.microsoft.com/en-us/library/f2c0w594.aspx [2] http://msdn.microsoft.com/en-us/library/bb384691.aspx _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 3

[smart_ptr] lost doc link to enable_shared_from_this
by Kim Barrett 14 May '13

14 May '13

In boost 1.53 I can't find any reference to the documentation forenable_shared_from_this. The documentation page exists: http://www.boost.org/doc/libs/1_53_0/libs/smart_ptr/enable_shared_from_this… but I can't find any reference to it from anywhere in the smart_ptr / shared_ptr documentation. As late as boost 1.52 there was a reference to it in a note for the template<class Y> explicit shared_ptr(Y * p); constructor, but that note was removed in boost 1.53, and there doesn't seem to be any other reference to enable_shared_from_this. One of the places I expected to find a reference to enable_shared_from_this was the "Programming Techniques" page's entry "Obtaining a shared_ptr from a raw pointer", but I found no mention of it there through boost 1.53.

1 1

[endian] Boost licensed detail/endian.hpp [was: [1.54.0][release] Provisional schedule]
by Beman Dawes 14 May '13

14 May '13

>On Mon, May 6, 2013 at 9:06 AM, Daniel James <daniel(a)calamity.org.uk> wrote: > >> On 6 May 2013 14:15, Philip Bennefall <philip(a)blastbay.com> wrote: >> > I was just wondering if it is possible to get a modified, Boost licensed >> > version of detail/endian.hpp into this next release? It'd be great to get >> > this licensing issue resolved in this next Boost version, if at all >> > possible. >> >> I don't know. I haven't been following that. Did anyone take >> responsibility for it? >> > >It's highly unlikely. There is al alternative implementation in Boost >Predef. But that isn't even fully accepted as a library. I could attempt to >do a standalone port from Predef into detail/endian.hpp but I doubt I could >both get it done and tested to a point that it would be safe to merge into >release. I'm restarting work on the boost endian library, so I'd be willing to take this on. If you send me your Predef port of detail/endian.hpp, I'll see if I can move it along. No promises until I see what you have, however. Thanks, --Beman

3 4