- Boost - lists.boost.org

[container] Issues with non-copyable mapped-types
by onlyone＠senet.com.au 15 Sep '11

15 Sep '11

Hi, I have been trying to use Boost.Container to make a map<copyable_but_not_moveable, moveable_but_not_copyable>. Unfortunately I have been unable to do this because the value_type of boost::container::map is std::pair, which does not support move semantics (in C++03). This causes problems for the moveable_but_not_copyable type. It means that, for example: myMap[copyable_but_not_moveable()]; does not compile. This behaviour is fully supported in C++11 mode, and I see no reason why a custom C++03 pair class would be unable to use the Boost.Move emulation to achieve the same effect. Regards, Evan Wallace

3 3

[boost/filesystem] Access to a shared folder on other computer
by Demetrio Car 15 Sep '11

15 Sep '11

Can someone send me a example of how to copy a file from a remote folder to other remote folder? For example: I am running MyProgram on MyComputer and this program has to copy a file from a folder inside OtherComputer. This folder need user and password to allow MyProgram to copy the file. I am using the following sample. The main point in this example is to make my program to work both in linux and windows, but locally. Now I want to do the same with a path like this: \\192.168.x.x\mySharedFolder\fileToBeCopied.text . Maybe I need another library but I don't know. //***http://www.ibm.com/developerworks/aix/library/au-boostfs/ #include <stdio.h> #include <boost/filesystem.hpp> int main() { boost::filesystem::path path("/usr/local/include"); bool result = boost::filesystem::is_directory(path); return 0; }

1 0

[Review] Boost.Endian Review
by joel falcou 15 Sep '11

15 Sep '11

A gentle reminder that the Boost.Endian review is scheduled to end today. Any participant that wish to submit review can do so before tonight Regards

1 0

[signals2] Problem compiling with Intel V12.1 (Windows)
by Hartmut Kaiser 15 Sep '11

15 Sep '11

Compiling code using Boost.Signals2 fails using Intel V12.1 on Windows. The reason is a forward declaration of std::weak_ptr and std::shared_ptr in the signals2 code which creates a problem as Intel seems to import std::tr1::weak_ptr into namespace std. This patch fixes the issue: --- forei-revBASE.svn002.tmp.hpp Wed Oct 07 15:56:56 2009 +++ boost/boost/signals2/detail/foreign_ptr.hpp Thu Sep 15 06:10:24 2011 @@ -12,16 +12,19 @@ #define BOOST_SIGNALS2_FOREIGN_PTR_HPP #include <algorithm> +#include <boost/config.hpp> #include <boost/assert.hpp> #include <boost/scoped_ptr.hpp> #include <boost/smart_ptr/bad_weak_ptr.hpp> #include <boost/utility/swap.hpp> +#if !defined(BOOST_INTEL_STDCXX0X) namespace std { template<typename T> class shared_ptr; template<typename T> class weak_ptr; } +#endif namespace boost { Ok to commit? Regards Hartmut --------------- http://boost-spirit.com

1 0

[phoenix] compile-time performance
by Eric Niebler 15 Sep '11

15 Sep '11

On 9/12/2011 4:06 AM, Thomas Heller wrote: > On Monday, September 12, 2011 02:57:21 PM Joel de Guzman wrote: >> For example, here is the current CT status of Phoenix2 vs Phoenix3 >> comparing the elapsed (CT) time for the phoenix2 vs. phoenix3 >> lambda_tests.cpp (**): >> >> MSVC 10: >> Phoenix2: 00:04.5 >> Phoenix3: 00:29.9 >> >> G++ 4.5: >> Phoenix2: 00:02.6 >> Phoenix3: 00:04.7 > > I wasn't aware that Phoenix3 was so bad under MSVC 10. Me neither. If that's the case, we have work to do. >> You all know that Phoenix2 uses Fusion exclusively. Phoenix3 uses >> proto, which according to Eric does not use Fusion, although IIRC >> the core of Phoenix3 uses some Fusion still (quick check: Thomas >> uses an optimized-PP version of fusion:: vector for phoenix3). >> >> Heller did a helluva perf-tweaks for Phx3 to get that number for >> g++ (alas, not MSVC). In fairness, I did absolutely no CT >> perf-tweaks for both Phoenix2 and Fusion. >> >> (** I made sure both tests have exactly the same code, so I removed >> the last test. I can post the exact code if need be) OK, I retract everything I said. Fusion rulez, and Proto needs help. Sorry for the blind accusation. Let's stop this and figure out what needs to be fixed. > FWIW, there are some unit tests that outperform the compile times of > Phoenix2 (with gcc), the current bad hit on compile times seem to > only occur with let, lambda and switch/case expressions. This /suggests/ to me that the core of Phx3 is sound, but that the implementation of let, lambda, and switch are heavy. But I'm not blaming Thomas. I'm just suggesting a logical place to begin an investigation. And regardless, we should point Steven's template profiler at the code and see what it says. Thomas, do you want to give that a shot? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 9

[concept] EqualityComparable metafunction
by Lorenzo Caminiti 14 Sep '11

14 Sep '11

Hello all, What is the best way to check if a type T is EqualityComparable? Essentially, I would need a is_equality_comparable<> metafunction: struct mytype {}; is_equality_comparable<int>::value // true is_equality_comparable<mytype>::value // false Can I re-use the boost::EqualityComparable concept to implement is_equality_comparable<>? Or, shall I just try to use introspection-SFINAE techniques? Thanks in advance. --Lorenzo

7 11

intrusive_ptr to a map containing intrusive_ptr object
by shri kumar 14 Sep '11

14 Sep '11

Hi, I am facing a problem while making the raw pointer to an intrusive_ptr inside a map whose pointer is already an intrusive pointer so typedef goes like: typedef boost::intrusive_ptr< protocolLibraryLoader> ProtocolLibraryLoaderPtr; typedef std::pair<ProtocolLibraryLoaderPtr, ProtocolRecognizer_type*> ProtocolLibEnginePair; typedef boost::intrusive_ptr<ProtocolLibEnginePair> ProtocolLibEnginePairPtr; Now inside code when I try creating map and assign with ptr as given in below: .. *boost::intrusive_ptr<protocolLibraryLoader> libraryLoader = getProtoLoader();* .. m_activeRecEnginePtr = ProtocolLibEnginePairPtr(libraryLoader,newRecognizer); .. I get the following error: ProtocolManager.cpp: In member function 'void ProtocolManager::InitializeProtocolsLibrary(ProtocolManager*)': ProtocolManager.cpp:234: error: no matching function for call to 'boost::intrusive_ptr<std::pair<boost::intrusive_ptr<protocolLibraryLoader>, ProtocolRecognizer_type*> >::intrusive_ptr(boost::intrusive_ptr<protocolLibraryLoader>&, ProtocolRecognizer_type*&)' ../../../include/boost/intrusive_ptr.hpp:94: note: candidates are: boost::intrusive_ptr<T>::intrusive_ptr(const boost::intrusive_ptr<T>&) [with T = std::pair<boost::intrusive_ptr<protocolLibraryLoader>, ProtocolRecognizer_type*>] ../../../include/boost/intrusive_ptr.hpp:70: note: boost::intrusive_ptr<T>::intrusive_ptr(T*, bool) [with T = std::pair<boost::intrusive_ptr<protocolLibraryLoader>, ProtocolRecognizer_type*>] ../../../include/boost/intrusive_ptr.hpp:66: note: boost::intrusive_ptr<T>::intrusive_ptr() [with T = std::pair<boost::intrusive_ptr<protocolLibraryLoader>, ProtocolRecognizer_type*>] ../../../include/boost/intrusive_ptr.hpp: In constructor 'boost::intrusive_ptr<T>::intrusive_ptr(T*, bool) [with T = protocolLibraryLoader]': ProtocolManager.cpp:225: instantiated from here ../../../include/boost/intrusive_ptr.hpp:72: error: cannot convert 'protocolLibraryLoader*' to 'Tracker*' for argument '1' to 'void intrusive_ptr_add_ref(Tracker*)' ../../../include/boost/intrusive_ptr.hpp: In destructor 'boost::intrusive_ptr<T>::~intrusive_ptr() [with T = protocolLibraryLoader]': ProtocolManager.cpp:225: instantiated from here ../../../include/boost/intrusive_ptr.hpp:101: error: cannot convert 'protocolLibraryLoader*' to 'Tracker*' for argument '1' to 'void intrusive_ptr_release(Tracker*)' ../../../include/boost/intrusive_ptr.hpp: In copy constructor 'boost::intrusive_ptr<T>::intrusive_ptr(const boost::intrusive_ptr<T>&) [with T = protocolLibraryLoader]': ProtocolManager.cpp:225: instantiated from here ../../../include/boost/intrusive_ptr.hpp:96: error: cannot convert 'protocolLibraryLoader*' to 'Tracker*' for argument '1' to 'void intrusive_ptr_add_ref(Tracker*)' make: *** [FREEBSD_6_i686/ProtocolManager.o] Error 1 Basically worrying part is "no matching function for call to 'boost::intrusive_ptr<std::pair<boost::intrusive_ptr<protocolLibraryLoader>, ProtocolRecognizer_type*> >::intrusive_ptr(boost::intrusive_ptr<protocolLibraryLoader>&, ProtocolRecognizer_type*&)' I wonder if it is kind of limitation or do I have to do something else to achieve? Actually I am dealing with legacy code so I don't want to remove the intrusiveness on the pair which actually increases/decreases ref_count of ProtocolRecognizer_type and not on protocolLibraryLoader. Please help me as I am kind of stuck with this. Thanks Shri

2 1

[endian] Review
by Stewart, Robert 14 Sep '11

14 Sep '11

Herewith is my review of Beman's Boost.Endian library. ____________________ ____________________ What is your evaluation of the design? _____ The two-argument overloads of the [un]conditional swapping functions seem awkward at first blush, but are really the best interface for those operations. Changing to value returning functions opens the door to mistakes like the following: uint32_t const in(123); int32_t const out(reorder(in)); There might be a warning, but many programmers routinely ignore such. As is, the compiler will complain about the conditional functions: uint32_t const in(123); int32_t out; native_to_big(in, out); // Error: ambiguous The unconditional functions do not provide that benefit because they aren't function templates: uint32_t const in(123); int32_t out; reorder(in, out); _____ An interesting variation that I've used in the past is a set of cast-style function templates that permit byte swapping one type and returning the result as a different type, after verifying that the resulting value is in range of the target type. Thus, uint32_t const in(std::numeric_limits<uint32_t>::max()); int32_t const out(to_host<int32_t>(in)); // throws TMP allows streamlining the range checks done, of course. _____ Another variation I've used is a checked, two-argument function template with each potentially having a different type: template <class T, class U> void to_host(T & _result, U _value); (I always prefer output parameters to be first because their position is consistent and it leaves open the possibility of defaulted parameters in the general case. I'd prefer that in Boost.Endian, but not everyone likes that convention.) There are two possibilities for dealing with the case when T and U are different. One is that they be required to have the same, supported size and that they are both signed or both unsigned. The other is to do a runtime check that the swapped value is within the range of the target type. _____ I like that the aligned integer types have the longer names because they incur padding and are non-portable. _____ The overhead implied by the comments in the "Comment on naming" section of the Endian Integer Types page is an excellent reason for splitting the endian class template into endian_buffer and endian_integer as previously suggested. For C++11, the latter can derive from the former. For C++03, if POD-ness is important, you'll need to duplicate the former's code in the latter, but it's worthwhile. ____________________ ____________________ What is your evaluation of the implementation? There's already been a good deal of discussion on efficiency and reuse during the review, so I won't rehash it. The 64b reorder(), for example, looks like a lot of code for an inline function. I haven't compiled it to inspect the resulting assembly to see how much or little results. My concern is for the possibility of code bloat arising from the desire to keep this a header-only library. If those were function templates, then the compiler can choose whether to inline or not, despite the definition being in a header. The implementation of class endian is uncommented, yet non-trivial. A future maintainer, even Beman, will benefit from some helpful information inserted now. The implementation of class endian would be simplified, it appears to me, by passing the endianness along to a detail::store() function template and letting it select the big/little endian store logic. ____________________ ____________________ What is your evaluation of the documentation? It's incomplete. There are no examples of the conversion functions. There is no tutorial. There is no guidance on selecting between the alternatives. There is no comparison with traditional htnol()-style code. __________ Endian Home _____ Introduction to endianness s/modern Apple, Linux, or Windows computer/computer/ (the OS doesn't matter) s|a[sic] Oracle/Sun Solaris computer| (the OS doesn't matter) s/CPU's/CPUs/ (plural, not possessive) _____ Introduction to the Boost.Endian library The first and last sentences should be merged: "Boost.Endian is a header only library providing facilities for managing integer endianness." Endian conversions for native integers: The last sentence makes both absolute and relative statements. The relative statements are, presumably, relative to endian integer types, but that's not made clear. I suggest rewording as, "This approach is simple and efficient, but when compared to endian integer types, is less flexible regarding size and alignment, can be harder to manage, is more error prone because of the need to apply endian conversions in unrelated logic paths, all of which can lead to logic errors that are difficult to debug." Endian integer types: The second sentence has a similar problem, and the last sentence could be combined to correspond with the list of the previous paragraph. Try this variation: "This approach is simple and, while it can be less efficient than endian conversions, it avoids strict alignment requirements allowing opportunities to pack data more tightly." I'd follow with this variation of the third sentence: "Furthermore, types of length from 1 to 8 bytes are supported, rather than just the usual 1, 2, 4, and 8 byte lengths." __________ Conversion Functions This page is odd. The synopsis does not include links to the description of the functions. When I first saw the page, I thought there simply was no documentation for using the various functions. That documentation does appear in the latter part of the page, but it isn't obvious. There should be information explaining why conditional and unconditional functions are useful and each should refer to its counterpart. That is, reorder(uint16_t &) should note that if the intent is not to reorder the bytes regardless of the platform, that bit_to_native(uint16_t &), for example, is appropriate. The unconditional nature or reorder() escaped me until I realized that these functions always swap bytes, unlike the htonl() family, which I'd never before encountered as necessary. Thus, use cases for unconditional byte swapping are warranted. __________ Endian Integer Types The Conversion Functions page links to the description of big and little endian on the Endian Home page, but the Integer Types page does not. The example shown on the Integer Types page should be recreated using the Conversion Functions to show the difference in usage. That example should use sizeof(h) rather than sizeof(header) since that is a safer practice. _____ Limitations This section, while important, should not appear so soon on the page. s/compilers do layout memory/compilers lay out memory/ s/C++0x/C++11/ s/it will be possible to specify the default constructor as trivial/the default constructor is marked as trivial/ s/will no longer disqualify/do not disqualify/ s/will no longer be relying/does not rely/ _____ Feature set s/Big endian | little endian | native endian byte ordering./Big, little, and native endian byte ordering/ s/Signed | unsigned/Signed and unsigned/ s/Unaligned | aligned/Data may be aligned or unaligned/ s/1-8 byte (unaligned) | 2, 4, 8 byte (aligned)/2, 4, and 8 byte aligned types and 1-8 byte unaligned types/ _____ Typedefs The column order should correspond with the order of information in the typedef names: alignment, sign, endianness, size. The discussion of the difference between aligned and unaligned types should not be "buried" in the Typedefs section. _____ Comment on naming s/these type grows/these types grows/ Why does "the realization creep in" that the endian integer types are lousy arithmetic integers? Only profiling would reveal that. Consequently, you should call that out, perhaps in a "Design Details" section along with the aligned/unaligned discussion, thereby explicitly stating rather than leaving to each library user the discovery of the overhead of these types. _____ Synopsis The link from "cover_operators" to a header is surprising. _____ Members The description of the default constructor fails to indicate whether the value is left uninitialized, which I presume to be the case. The description of the conversion operator mixes T and value_type. While those two are the same, one has to examine the class definition to see that. Either s/T/value_type/ or s/value_type/T/. _____ FAQ s/and both speed and/plus both speed and/ s/disk records/records/ (applies to networking, too) s/Yes, for sure, compared/There is overhead compared/ s/are usually be faster/are usually faster/ s/types POD's?/types POD?/ s/endian integer types not being POD's/of endian types not being POD/ s/data files are portable/data files that are portable/ The "These types are really just byte-holders" entry should not be a FAQ. That information, along with a discussion of the overhead of the simple syntax, should be part of the "Design Details" section suggested above. _____ Design considerations for Boost.Endian integers Only "Design" is underlined in the section heading. s/memcpyable/memcpy-able/ _____ Experience s/used very successful/used very successfully/ _____ Compilation s/This is ensures that , and/This ensures that class endian is POD, even in C++03, and/ s/POD's/POD/ ____________________ ____________________ What is your evaluation of the potential usefulness of the library? Highly useful, but could be more so. ____________________ ____________________ Did you try to use the library? No. Sorry. ____________________ ____________________ How much effort did you put into your evaluation? I spent about an hour reading the documentation plus a lot of time on the mailing list participating in endian discussions. ____________________ ____________________ Are you knowledgeable about the problem domain? Yes. I've used the old standby functions, htonl(), ntohl(), and friends over many years. I've created template functions to automatically select the right function based upon the size of the type being swapped, etc. ____________________ ____________________ Do you think the library should be accepted as a Boost library? There are issues that keep me from saying yes at this time. There are too many suggested variations and ideas under consideration to accept the library in its present state. However, a mini-review should be sufficient to evaluate the final form, once Beman determines a course of action, and determine whether to accept it or not. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

[proto] Looong compile times and other issues
by John Maddock 14 Sep '11

14 Sep '11

So.... I thought I had all the expression template stuff pretty much done, and then I tried some real world use cases (compiling all the students_t distribution functions with my extended-precision FP type) and everything fell apart: * VC10 wouldn't compile the code at all - more or less runs the system out of swap space (takes about 10 minutes or more!), then exits with an internal compiler error (if I break the code down into it's parts and instantiate each part separately it does compile though - that's not a solution though!). * GCC-4.4.x fails to compile the code due to clashes between boost::math::complement (a function) and boost::proto::complement (a class). I suspect this is an old gcc bug (finding structures via ADL) - I guess the solution is to not derive my number type from a proto-type so ADL can't find proto:: classes? Or will I hit this from some other unforeseen lookup? * GCC-4.5.0 Fails with an internal compiler error :-( * GCC-4.6.0 Builds the code OK, but takes a long time - though possibly just barely acceptable. I suspect this is a "triple template" problem: * proto is complex template library. * my number class is a fairly large/complex template in it's own right. * the code above gets instantiated from deep within Boost.Math's internals. Other than using proto::switch in the grammar (which I'm doing already), is there anything I can do to reduce the template load on the proto side of things? Otherwise since I'm only using a tiny fraction of proto's capabilities, the only other option I can see is to rip it out and replace with a mini-proto designed to minimalize template instantiations within this particular use case. Thanks in advance, John.

7 26

[C++11 Feature List]
by Sid Sacek 13 Sep '11

13 Sep '11

Does boost have a spec (document) where it mentions which new language features in C++11 are permitted to be used in new libraries? -Sid Sacek

2 2