December 2010 - Boost-users - lists.preview.boost.org

boost::regex_search upgrade from 1_36 to 1_45
by EricB 15 Dec '10

15 Dec '10

Hi I have upgraded my boost to 1_45 (it was 1_36) and since then I have an error on boost::regex_search here is the code std::string regexp = "\\^:\\([^;^]*\\);\\([^;^]*\\);\\([^^]*\\)\\^:"; boost::regex expression( regexp.c_str() , boost::regex::basic|boost::regex::icase ); std::string::const_iterator it_prev = str.begin(); std::string::const_iterator it_end = str.end(); std::string tmp; while (boost::regex_search(it_prev, what, expression)) { res = true; tmp.assign(it_prev,what[0].first); ... tmp.assign(what[2].first, what[2].second); ... reading the html doc I can not find how to rewrite this while loop. I'm not a boost expert, any help would be appreciated. Thank you

2 2

metaprogramming help
by John Dlugosz 14 Dec '10

14 Dec '10

A couple of times I've run into the situation where a "new" C++ class is written to exactly match "legacy" C structures. At the edges where old code meets new code, you can cast one to the other in-place. For example, given a huge mess of data that includes oldstruct s1; you could write the line newclass& s2= reinterpret_cast<newclass&>(s1); because s2 is designed to exactly overlay s1. It might even derive from it, and just add member functions and friendlier accessors. Another example I've seen is a class that contains nothing but a char* pointer member, that contains overloaded operators to replace the ancient str* functions. In particular, it has an operator==, so casting an array of char* to an array of that class allowed std::find to be used! I don't like the wild and unchecked use of reinterpret_cast, but I can see the point for these and think the idiom can be tamed. Basically, I want to write a cisam_cast that behaves like a reinterpret_cast but only for those conversions I've explicitly nominated as being cisam's. CISAM is "compatible in structure and meaning", and I avoid calling it "upgrade" because it works in either direction or sideways between different code bases' definitions of the same wire data. I'm thinking that I should be able to declare something like template<> cisam<xxx,yyy> : std::tr1::true_type {}; to enable cisam_cast<xxx>(a_yyy) to have the same meaning as reinterpret_cast<xxx&>(a_yyy), etc. (foreshadowing hard question...) Since it would be common to make a new class to wrap a primitive type or old struct, a shortcut would be to include a typedef yyy cisam; as a member of xxx. Now I get around to my actual question: the "etc." part above. Given that xxx and yyy are cisam-mates, I want to enable not only xxx to yyy and vice versa, but handle const and volatile qualified forms with correct cv-modifier carry-through, and handle pointers to them to any depth, which is complicated by the fact that there could be cv-qualifiers at any level. In the earlier example, the original code was something like: char* A[7]; char* val; //... Str* SA= reinterpret_cast<Str*>((char**)A); and I would want Str* SA= cisam_cast<Str*>(A); to be accepted. Note that the cisam-ness is between (char*) and (Str), so there are a different number of stars on the before and the after. So, how might I write the cisam_cast machinery to elaborate the basic cisam definitions into the full set of allowed casts? Thanks, --John =====Begin Corporate Footer That I Can't Do Anything About===== TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

5 10

[mpl, enable_if] "Failed to specialize function template"
by Igor R 14 Dec '10

14 Dec '10

Hello, The following code fails to compile (MSVC10, Boost 1.45) with "error C2893: Failed to specialize function template..." It seems that the compiler tries to evaluate mpl::apply, doesn't it? #include <boost/mpl/apply.hpp> #include <boost/mpl/bool.hpp> #include <boost/mpl/or.hpp> #include <boost/mpl/and.hpp> #include <boost/mpl/always.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/utility/enable_if.hpp> using namespace boost::mpl; using boost::is_same; template<typename Type> void test(Type, typename boost::enable_if < and_ < not_<boost::is_same<Type, int> >, apply<always<true_>, typename Type::my_type> > >::type* dummy = 0) { } template<typename Type> void test(Type, typename boost::disable_if < and_ < not_<boost::is_same<Type, int> >, apply<always<true_>, typename Type::my_type> > >::type* dummy = 0) { } int main(int argc, char* argv[]) { test(int()); return 0; }

2 6

Re: [Boost-users] [Units] derived units of SI system (newbie)
by André Berthe 14 Dec '10

14 Dec '10

Thank you very much, Steve! From your reply I learned: - to think twice; not in physical values but actually in units - that supplements on existing systems are not bad - errors related to conversion factors indicate that I should check my own units (formulas) The body of the main function simplifies to: bu::quantity<SI::frequency> WSR_x(100*SI::hertz); bu::quantity<SI::dynamic_viscosity> eta(4.6*(SI::kilograms/(SI::meter*SI::second))); bu::quantity<SI::stress> WSS_x(WSR_x*eta); Best regards, Andre

1 0

Re: [Boost-users] Using lambda expressions in stl algorithms
by przemyslaw.sliwa＠uk.bnpparibas.com 14 Dec '10

14 Dec '10

Hello, EventTypeis a string and CurrencyEventPtr is just shared_ptr. CurrencyCouple is just a class, nothing special. typdef std::string EventType; typedef boost::shared_ptr<CurrencyEvent> CurrencyEventPtr; Thanks for help ___________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited. Please refer to http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-… for additional disclosures.

1 0

Using lambda expressions in stl algorithms
by przemyslaw.sliwa＠uk.bnpparibas.com 14 Dec '10

14 Dec '10

Hello, Could someone tell me why this code does not compile? Can it be modified in order to compile? struct CcyCplEventKey { CurrencyCouple CcyCpl; EventType Event; } typedef std::map<CurrencyEventKey, CurrencyEventPtr> mapType; mapType ccyOut; std::for_each(ccyOut.begin(), ccyOut.end(), (&*boost::lambda::_1)->*&CcyCplEventKey::Event); Cheers ___________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited. Please refer to http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-… for additional disclosures.

3 2

Variant pointer and bool
by Philipp Hamann 14 Dec '10

14 Dec '10

Hi all, I have a class, call it "Property", containing a value, which can be of many different types, like int, string, bool, but also a pointer to binary data. So I decided to use boost::variant. The problem is that when I assign a pointer to the variant, it is implicitly casted to a bool. So I do not get the pointer out of the variant again. Is boost::variant not suitable for my needs or is there a recommended workaround? I will post some code to make my problem more clear. boost::variant<void*, bool, int, std::string> value; void* p; value = p; bool b = boost::get<bool>(value); //OK void* p2 = boost::get<void*>(value); //Error Thanks for your help Philipp

3 4

file creation/append mapping/unmapping
by Brian Budge 14 Dec '10

14 Dec '10

Hi all - I'm aware of two separate mechanisms for mapping files in boost: file_mapping combined with mapped_region from interprocess, and mapped_file from iostreams. I need to write a portable library (linux, windows, mac, 32/64 bit) which performs mappings of files. I will be creating flatfile archives consisting of many pieces of data, and this data may be operated on in a multi-threaded fashion. I was thinking of a mechanism where I'd atomically "allocate" space in a file, map that allocated region, and then memcpy the data into the region. I do not know the size of the completed file in advance. I also may be creating files > 4 GB in rare cases, and I still need this to work on 32-bit systems. I also need to be able to read (again multi-threaded) sections from one of these archives, and I need to be able to map and unmap these regions of the file. In 64-bit land, I might keep all mappings open during a process lifetime, and only close the mappings when the process shuts down, allowing the filesystem/file cache to swap out as necessary, but in 32-bit land, address space may be constrained, and I will require the map/unmap potentially many times during a process lifetime. Recommendations for which way to go on this? It seems from my little tests and reading of the existing docs that the interprocess stuff may fit the bill better than the stuff from iostreams. Also, I hope to pack my "sections" together, and not necessarily at page-aligned boundaries. I know this may incur extra state management on my part. I also found a class called managed_file_mapping. Can this help me at all? I couldn't find any example code using this class. Thanks, Brian

1 0

Re: [Boost-users] mpi: sending/receiving different types
by Hicham Mouline 13 Dec '10

13 Dec '10

-----Original Message----- From: "Riccardo Murri" [riccardo.murri(a)gmail.com] Date: 09/12/2010 11:58 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] mpi: sending/receiving different types >Hi Hicham, ><snip> >>> 3. I just thought of using boost::variant<> over all the possible types. >>> >I think this is the way to go; I'm attaching a sample program. Not >sure this is exactly what you need, but could be enough to get you >started. >Best regards, >Riccardo It's exactly what I was gonna do, thanks very much. The bit I am missing now is my question here: http://lists.boost.org/boost-users/2010/12/64797.php I don't know how to assign the most derived type to the variant at creation in the sender. In your code snippet, you explicitly construct c, then assign it to v. For me, I get given const Base& and I need to store the actual type. This seems to be what some of the boost libraries have to do themselves, but I can't remember which one exactly. I could intrusively add virtual functions to the classes but I don't want that, thanks Riccardo,

4 4

Re: [Boost-users] mpi/serialization: broadcast function and the value argument
by Hicham Mouline 13 Dec '10

13 Dec '10

>-----Original Message----- >From: "Matthias Troyer" [troyer_at_[hidden]] >Date: 09/12/2010 02:39 PM >To: boost-users_at_[hidden] >Subject: Re: [Boost-users] mpi/serialization: broadcast function and the value argument >>On Dec 8, 2010, at 5:50 PM, Hicham Mouline wrote: >>> Following a suggestion from another thread, I have tried broadcasting in a polymorphic way. >>> >>> I have a hierarchy of polymorphic struct (they have 2 virtual functions). I was wondering if it was possible/allowed to >>> >>> root process: >>> base* b; /// b points to an actual derived struct but may also point the base struct (not abstract) >>> broadcast( ..., b, ...); >>> >>> slave processes: >>> base* b; >>> broadcast( ..., b, ...); /// broadcast constructs the appropriate struct and makes b point to where it did that >>> >>> assuming all the conditions for pointer to class conditions are satisfied for the serialization library. >>> >>If serialization works on your polymorphic class then this should work as well. >>Matthias >It appears the implementation of mpi::broadcast(), according to this post, >http://lists.boost.org/boost-users/2010/12/64802.php >and I confirm that expects an already built object to call the >(de)serialization procedure on. >Therefore, this seems a specific issue that mpi::broadcast() may want to handle differently, >could you confirm/correct? >thanks, I would very much appreciate extra opinions about this issue and the route I have taken to solve it. Let me sum up: mpi::broadcast() appears to be incapable of sending the argument "value" in a polymorphic way, ie: sender------------------- Base* base; If I call boost::mpi::broadcast(..., base, ...) receiver----------------- Base* base; boost::mpi::broadcast(..., base, ...) This does not construct the most derived type of base on the heap and make base point there, as serialization would do. I therefore used a variant made of all the classes of the hierarchy and broadcast it instead. sender------------------- variant<...> v; boost::mpi::broadcast(..., v, ...) receiver----------------- variant<...> v; boost::mpi::broadcast(..., v, ...) This works but before I replicate it in other parts of the code, I would appreciate your opinions about this solution provided by Riccardo. Regards,

2 1