- Boost - lists.boost.org

[lexical_cast][random] ADL problem with gcc c++11
by Joel de Guzman 25 Mar '12

25 Mar '12

Hi, I can't get this to compile on gcc-4.6.1 with -std=c++0x flag: #include <boost/random.hpp> int main() { return 0; } I'm getting an error in lexical_cast: C:\dev\boost/boost/lexical_cast.hpp:1323:120: error: there are no arguments to 'swprintf' that depend on a template parameter, so a declaration of 'swprintf' must be available [-fpermissive] Obviously, I can compile with -fpermissive, but I'd like to report this anyway. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com

5 7

Re: [boost] [git] Mercurial?
by David Greene 25 Mar '12

25 Mar '12

Edward Diener <eldiener(a)tropicsoft.com> writes: >> Also back to the point - DVCS are written to provide best possible >> support for merging. This makes 1) or 2) you propose above very >> efficient. In SVN or other centralized systems it is not so, just look >> up the bit I left from Joel's message above. > > I do not believe for even a second that any product can do merging of > the same source file automatically and flawlessly. This strawman keeps resurfacing. No one has claimed than any VCS can avoid manual merging at times. A centralized VCS needs to operate as you outlined: >> Bu how is this different from: >> >> 1) Creating a local SVN repository and importing some branches from >> another SVN repository. >> >> and/or >> >> 2) Having one's own branch of an SVN repository as one's own. #1 is a horribly manual operation. I don't know if you quite grasp how complicated it is. I've been doing it for years. Getting the history preserved correctly is not trivial. #2 has almost no support in SVN. Now that SVN has merge tracking it is marginally better but there are problems with this model. Foremost, the branch has to be in a centralized repository and everyone owkring on the project has to deal with it in some fashion. It's not private in any sense of the word. You can't work on it if you don't have 'net access. You can't back out changes that you realized later were bad and ensure no one else ever sees those changes. The difference with a DVCS is both #1 and #2 are natively supported in the tool. There is no difference between a private local branch, a remote branch in a _de_facto_ central repository and a remote branch in some other random repository. They all look and act the same. I admit it is a tough concept to grasp for someone not used to it. It took me some time to grok it. But now it is second-nature to me and there's no way I'm going back. -Dave

3 4

[config] Why does BOOST_NO_STD_LOCALE imply BOOST_NO_STD_WSTREAMBUF?
by Yechezkel Mett 25 Mar '12

25 Mar '12

I have found the following in config/suffix.hpp: // // We can't have a working std::wstreambuf if there is no std::locale: // # if defined(BOOST_NO_STD_LOCALE) && !defined(BOOST_NO_STD_WSTREAMBUF) # define BOOST_NO_STD_WSTREAMBUF # endif What is the reasoning behind this? My problem is that I am using Windows CE 6.0 with the supplied standard library, and it has no <locale>, yet still seems to provide a working wstreambuf. The effect is that I can't get boost::wformat, which is annoying, considering that the WinCE API uses only wide characters. I have checked that removing this line works. Is there any way to undefine BOOST_NO_STD_WSTREAMBUF without modifying the source? Yechezkel Mett

1 0

Re: [boost] [Boost-commit] svn:boost r77506 - in trunk: boost/property_map libs/property_map/doc libs/property_map/test
by Michel Morin 25 Mar '12

25 Mar '12

> Author: jewillco > Date: 2012-03-23 15:35:52 EDT (Fri, 23 Mar 2012) > New Revision: 77506 > URL: http://svn.boost.org/trac/boost/changeset/77506 […] > --- (empty file) > +++ trunk/boost/property_map/function_property_map.hpp 2012-03-23 […] > +#ifndef BOOST_PROPERTY_MAP_FUNCTION_PROPERTY_MAP_H > +#define BOOST_PROPERTY_MAP_FUNCTION_PROPERTY_MAP_H […] > +#endif /* BOOST_PROPERTY_MAP_FUNCTION_PROPERTY_MAP_H */ s/H/HPP > +template<typename Func, typename Key, typename Ret = typename boost::result_of<Func(Key)>::type> > +class function_property_map: public put_get_helper<Ret, function_property_map<Func, Key, Ret> > { […] > + typedef Ret reference; […] > + reference operator[](const Key& k) const { > + return f(k); > + } > + > + reference operator[](const Key& k) { > + return f(k); > + } […] > + private: > + Func f; > +}; In const version of the subscript operator, `f` is treated as `const Func`. So `reference` might not be appropriate for its return type. You can avoid this issue by making `f` mutable. Or, how about defining the default template argument of `Ret` as `boost::result_of<const Func(Key)>::type` and removing non-const version of the subscript operator? (Since property maps are often passed around by values, it makes less sense to allow stateful functors in `function_property_map`, IMHO.) Regards, Michel

2 2

Re: [boost] Please advise: Boost with LLVM Clang and 0x11 dialect ?
by Steve Ramsey 24 Mar '12

24 Mar '12

On Mar 21, 2012, at 1:35 AM, "John M. Dlugosz" <mpbecey7gu(a)snkmail.com> wrote: > Can someone please advise on how to get Boost headers to work when compiling using Clang (as found on Apple OSX/iOS development) when the 0x11 dialect is enabled? > > We're stuck at Boost 1.47 because 1.48 doesn't even work with the current settings (C++03 dialect). The Mac developers don't want to fiddle with 1.49 without knowing what the deal is. > > Is there someone who has used Boost on the Apple with Clang who can relate some tales of how it works and offer suggestions? I've had no luck on the Boost.Users mailing list, or a previous post here on Boost.Devel. Is there anyplace else I might ask? At this point, any scrap of wisdom would be appreciated. It's not an automatic process, but once the initial effort is spent, it works beautifully. I should point out that I use both C++11 and libc++, and I ended up making a number of changes to boost build files to get various features working. The biggest problem is the lack of support in tools/build/v2/tools/clang-darwin.jam for specifying the SDK/platform for cross-compiling. My solution since boost 1.47 has been to replace it with a modified copy of tools/build/v2/tools/darwin.jam; if I thought this was going to be an issue for anywhere near as long as it has, I would've sent in a patch half a year ago (aside: do any of the maintainers actually use boost on OS X?). An additional complication is that as of Xcode 4.3, variant toolchains are stored in a different location and use a slightly different directory structure; a nice solution would be to support a build feature to indicate this and respond accordingly; I just hardcode for Xcode 4.3+. I'm happy to send you diffs off-list if you're interested, but it's frankenhacks all the way down until I get around to making a clean patch file for clang-darwin.jam. Steve P.S. The only source/header file with a problem is libs/signals/src/named_slot_map.cpp, which is trivially fixable.

2 1

[filesystem] [svn] How to remove V2 files without loss of V3 history?
by Beman Dawes 24 Mar '12

24 Mar '12

The boost/filesystem directory currently looks like this: v2 config.hpp // actual header convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp v3 config.hpp // actual header convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp config.hpp // forwards to v2/config.hpp or v3/config.hpp convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp It is time to remove the dual version support. What I'd like to do is: * create a branch, * switch to it, * delete the top level forwarding headers, * move the v3 headers up to boost/filesystem, * delete the v2 and v3 directories, * modify the headers as needed, * merge back to trunk. At the completion of the merge, the history for the boost/filesystem headers should include the full history of what were the boost/filesystem/v3 headers. What are the svn commands to accomplish that? Thanks, --Beman

6 15

[utility] Adding noexcept to boost::declval
by Michel Morin 24 Mar '12

24 Mar '12

Now that we have BOOST_NOEXCEPT macro, it is reasonable to add noexcept to boost::declval (by means of BOOST_NOEXCEPT). As a note, std::declval is marked as noexcept. I made a ticket with a patch here: https://svn.boost.org/trac/boost/ticket/6570 If it looks sensible, could someone apply the patch? Regards, Michel

1 1

interprocess with unordered_map
by Joel Young 23 Mar '12

23 Mar '12

>> Folks, I've built a unordered_map in a memory mapped file. The map goes from: typedef boost::interprocess::allocator< char, boost::interprocess::managed_mapped_file::segment_manager > char_allocator_t; typedef boost::interprocess::basic_string< char, std::char_traits<char>, char_allocator_t > typedef std::pair< key_type, pay_type> val_type; typedef boost::interprocess::allocator< val_type, boost::interprocess::managed_mapped_file::segment_manager> allocator_t; typedef boost::unordered_map< key_type, pay_type, boost::hash<key_type>, std::equal_to<key_type>, allocator_t> map_type; Everything works fine on creation. But when I later go to read from the map in a different program where the mapped file is opened read only, I have to do gymcrackery like: // A temporary string that allocates from the mapped file struct shm_clean { // cleanup shared memory on stack-unwind shm_clean() { boost::interprocess::shared_memory_object::remove("StupidSharedMemory"); } ~shm_clean() { boost::interprocess::shared_memory_object::remove("StupidSharedMemory"); } } cleaner; boost::interprocess::managed_shared_memory stupid(boost::interprocess::create_only ,"StupidSharedMemory" ,500); key_type key_val(stupid.get_segment_manager()); to create a temporary to allow me to search since the maps find() method will only take a key_type and interprocess::basic_string WILL NOT implicitly construct from a std::string, nor will it implicitly construct from a char* to itself. Can the interprocess::basic_string be modified to allow these conversions? I hate having to do: key_val = "fruitcake"; db.find(key_val); Suggestions? Thanks! Joel

4 18

[config] PGI config file doesn't defines BOOST_HAS_THREADS
by Vicente J. Botet Escriba 23 Mar '12

23 Mar '12

There is an issue on Boost.Thread regression test for PGI compiler. See https://svn.boost.org/trac/boost/ticket/6354. "pgCC" -INLINE:none -Kieee -fpic -fPIC -gopt -Minform=warn -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -D__need_IOV_MAX -I".." -c -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/pgi-11.9/debug/threading-multi/test_barrier.o" "../libs/thread/test/test_barrier.cpp" "../boost/config/requires_threads.hpp", line 86: catastrophic error: #error directive: "Compiler threading support is not turned on. Please consult your compiler's documentation for the appropriate options to use" # error "Compiler threading support is not turned on. Please consult your compiler's documentation for the appropriate options to use" boost/config/compiler/pgi.hpp defines BOOST_HAS_PTHREADS but not BOOST_HAS_THREADS, resulting in failure in the requires_threads.hpp header. It seems that adding #define BOOST_HAS_THREADS inboost/config/compiler/pgi.hpp solves the issue. John, what do you think? Could I add it? Best, Vicente

3 5

Re: [boost] DCVS vs CVS: call for constructivism
by Gottlob Frege 23 Mar '12

23 Mar '12

I have a question for the git (or hg) people. Maybe the concrete situation will shed some light on some of the issues (or maybe I'll just get some help and stop pulling what's left of my hair out). I'm working on code.cpp and morecode.cpp. At the same time, I am writing scripts like review.sh (makes git work better with code collaborator) and, say, custom_make.bat. I am going back and forth on these as needed. In particular, as the cpp files get in shape I commit, and maybe post something for review. We leads me to change review.sh. Or as I get things working, I modify custom_build.bat. To me, once done, these are separate commits/branches/features/changelists (whatever you want to call them). But while working on them, I don't want to flip between branches - I find I'm always changing something in the wrong branch when I try separate branches. ie I change code.cpp while in the "scripts" branch. And it is often more than 2 things I am working on. And sometimes (not usually) they are at least somewhat related - ie code.cpp depends on yourstuff.h, and I need to make a small fix in yourstuff.h. In the end, that fix will be separate, but until i know it is correct, it tends to stay mixed with my other work. Now maybe the dependency case is different, I don't know. (obviously at the end of the day, the order of dependent changes needs to be pushed correctly). So basically, in something like perforce, I can group the files into changelists, and then forget about it until something is completely done and ready to commit. I understand I'm losing other features (small commits, being able to easily set it all aside, etc), but this is my common workflow. Should I do everything on a messy "work" branch and just sort it out when I am ready to push? Should I keep the features in separate branches, but pull from branch to branch all the time? (I don't think I want to spend that much time with the RCS. I like forgetting about it most of the time.) Am I just doing it wrong? (And did any of this make any sense?) Tony Sent from my portable Analytical Engine

5 4