- Boost - lists.boost.org

[iostreams] #5904: Patch to suppress "unreachable code" warning from Visual Studio 2008/2010 (VC90/VC100)
by Sylvester-Bradley, Gareth 16 Sep '11

16 Sep '11

I've added ticket #5904 with a patch to suppress a warning in Boost.Iostreams. Please would someone apply this for Boost 1.48.0? Ticket URL: <https://svn.boost.org/trac/boost/ticket/5904> Many thanks, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

1 0

utility-container_gen in the sandbox
by Cromwell Enage 16 Sep '11

16 Sep '11

Hi, all. After a bit of a programming hiatus, I've managed to follow through on the container_gen discussion we had last May. I've created a branch in the sandbox called utility-container_gen that places the metafunction in Boost.Utility, changes detail::is_random_access to is_random_access_selector, provides an is_unique_associative_selector metafunction, and changes adjacency_list and parallel_edge_traits to use said utilities. Plus, there's Quickbook documentation. I've tested a few example programs in the BGL to make sure they still work, but I feel that's far from being thorough. No selectors for Boost.Intrusive have been implemented, yet. Feedback welcome! Cromwell D. Enage

1 0

[Review] Boost.Endian by BEman Dawes starts today
by Joel Falcou 15 Sep '11

15 Sep '11

According to the schedule, the review of the Boost.Endian library by Beman Dawes starts today. =========== What is it? =========== Boost.Endian provides facilities to manipulate the byte ordering of integers. * The primary use case is binary I/O of integers for portable exchange with other systems, via either file or network transmission. * A secondary use case is to minimizing storage size via integers of sizes and/or alignments not supported by the built-in types. Integers 1, 2, 3, 4, 5, 6, 7, and 8 bytes in length are supported. * Two distinct approaches to byte ordering are provided. Each approach has a long history of successful use, and each approach has use cases where it is superior to the other approach. * The explicit approach provides explicit functions to reorder bytes. All four combinations of non-modifying or modifying, and unconditional or conditional, functions are provided. * The implicit approach provides integer classes that mimic the built-in integers, implicitly handling all byte reordering. =================== Getting the Library =================== Docs are available at http://boost.cowic.de/rc/endian/doc/index.html A zip file is available at http://boost.cowic.de/rc/endian/endian-rc1.zip INSTALL instructions at http://boost.cowic.de/rc/endian/INSTALL Alternately, the whole library can be checked out of the sandbox: svn co http://svn.boost.org/svn/boost/sandbox/endian endian ================ Writing a Review ================ The reviews and all comments should be submitted to the developers list, and the email should have "[Endian] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.

4 6

[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