October 2011 - Boost - lists.preview.boost.org

Re: [boost] [Tokenizer] Compile error with lots of missing binary operator statments
by Collin Day 31 Oct '11

31 Oct '11

Previously, I had posted what I thought was a bug. I did not think to do this originally, but I just tried a simple Hello World program that included boost/tokenizer.hpp. It compiled fine. I then looked at where the sample code was pulling headers from, and it appears that the download included old boost headers it was including instead of 1.47.0. I completley missed this. I apologize - and take back the error - there is none :) Thanks!

1 0

[Tokenizer] Compile error with lots of missing binary operator statments
by Collin Day 31 Oct '11

31 Oct '11

Hi all, make[1]: Entering directory `/home/collin/projects/Cpp/plugins/PluginFramework/projects/plugin_framework' mkdir -p build/Debug/GNU-Linux-x86 g++ -c -g -DPF_PLATFORM_LINUX -DAPR_DECLARE_STATIC -DAPU_DECLARE_STATIC -I../../include/ -I../../include/darwin86 -I.. -o build/Debug/GNU-Linux-x86/Path.o Path.cpp In file included from ../../include/boost/mpl/apply.hpp:23:0, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token "(" ../../include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/bind.hpp:27:0, from ../../include/boost/mpl/lambda.hpp:18, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply_wrap.hpp:81:31: error: missing binary operator before token "(" ../../include/boost/mpl/apply_wrap.hpp:173:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/lambda.hpp:18:0, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/bind.hpp:364:31: error: missing binary operator before token "(" ../../include/boost/mpl/bind.hpp:531:31: error: missing binary operator before token "(" In file included from ../../include/boost/mpl/lambda.hpp:22:0, from ../../include/boost/mpl/apply.hpp:25, from ../../include/boost/iterator/iterator_facade.hpp:34, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/aux_/full_lambda.hpp:230:31: error: missing binary operator before token "(" In file included from ../../include/boost/iterator/iterator_facade.hpp:34:0, from ../../include/boost/iterator/iterator_adaptor.hpp:15, from ../../include/boost/token_iterator.hpp:21, from ../../include/boost/tokenizer.hpp:20, from Path.cpp:4: ../../include/boost/mpl/apply.hpp:138:31: error: missing binary operator before token "(" make[1]: *** [build/Debug/GNU-Linux-x86/Path.o] Error 1 make[1]: Leaving directory `/home/collin/projects/Cpp/plugins/PluginFramework/projects/plugin_framework' make: *** [.build-impl] Error 2 I looked on the web, and everything that looks remotley like this said it was a problem with GCC > 4.4, but was fixed in boost 1.37. I have tried with both gcc 4.4.6 and 4.5.3. I don't think I am missing anything since it is just an include file, but I could be wrong. any help would be appreciated. I tried the boost users mailing list with no luck after a couple of days. This is a more detailed example - it looks as though the same problem repeats for many files. Would it be appropriate to file a bug if I can't find any answers here? Thanks!

1 1

[math][distributions] superfluous checking of parameters?
by Thijs (M.A.) van den Berg 31 Oct '11

31 Oct '11

The boost math distributions check validity of distribution the same parameters multiple times. E.g. in normal.hpp, class normal_distribution, the constructor, normal_distribution(RealType mean = 0, RealType sd = 1) : m_mean(mean), m_sd(sd) { // Default is a 'standard' normal distribution N01. static const char* function = "boost::math::normal_distribution<%1%>::normal_distribution"; RealType result; detail::check_scale(function, sd, &result, Policy()); detail::check_location(function, mean, &result, Policy()); } however, those are *again* checked in e.g. the pdf() non member function inline RealType pdf(const normal_distribution<RealType, Policy>& dist, const RealType& x) { ... if(false == detail::check_scale(function, sd, &result, Policy())) { return result; } ... } Why is that? It's done in a consistent way across all distributions. Can we remove the check inside the non member functions that are already checked in the constructor?

3 7

[proto] Recent (rvalue support) changes in proto causes a whole bunch of regressions in Spirit
by Joel de Guzman 31 Oct '11

31 Oct '11

Hi, This code: #include <boost/spirit/include/qi.hpp> int main() { namespace qi = boost::spirit::qi; qi::rule<char const*> r; r %= (+qi::char_); return 0; } no longer works as expected. r %= (+qi::char_) becomes a no-op. Before it calls either: template <typename Expr> friend rule& operator%=(rule& r, Expr const& expr); // non-const version needed to suppress proto's %= kicking in template <typename Expr> friend rule& operator%=(rule& r, Expr& expr); Both defined in the rule class. Correct me if I'm wrong, but it seems the changes in proto forces us to support rvalue refs, but we are not ready for that yet and it's too late in the release cycle. Thoughts? Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com

4 4

[c++1] BOOST_NOEXCEPT macros?
by Beman Dawes 31 Oct '11

31 Oct '11

Since Boost already has BOOST_NO_NOEXCEPT and at least one compiler (GCC) supports C++11 noexcept, I'd like to start using it in Boost code. So how about a <boost/detail/noexcept.hpp> header with the usual boilerplate and this: #ifndef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT # define BOOST_NOEXCEPT_IF(Predicate) #else # define BOOST_NOEXCEPT no_except # define BOOST_NOEXCEPT_IF(Predicate) no_except(Predicate) #endif As was pointed out in a previous thread, there isn't any reliable C++03 alternative for either of these two, so nothing is attempted, and that's OK in C++03 code. We could also define BOOST_NOEXCEPT_OPERATOR(Predicate), and have it fall back to true in C++03 code. I'm not expert enough to know if that is reliable or even useful, so am not proposing it. Comments? --Beman

12 37

[interprocess] native Windows cond_var + mutex
by Dan Brown 31 Oct '11

31 Oct '11

Hi, Attached is a patch to implement interprocess_condition and interprocess_mutex natively on Windows. Following are some detailed notes. I hope this isn't too awkward of a time for a submission like this - I realize there's a lot of 1.48 activity going on. One more note about the patch - IIRC, some patch utils won't create directories. This patch is intended to be applied to boost/interprocess and relies on a new directory boost/interprocess/sync/win32. Background I started out by looking at http://www.cs.wustl.edu/~schmidt/win32-cv-1.html. This appears to be from the late '90s and is the basis for ACE's cond_var implementation. The solution in section 3.4 is arguably the most correct implementation. However, this solution relies on the atomicity of SignalObjectAndWait(). SOAW() may have been atomic for unicore systems common at the time but from what I've read is not atomic for multicore (it prevents context switches on a single core but ignores concurrent threads on other cores), and win32 documentation backs this up. While the paper argues that this leads to unfairness, I don't think the solution is correct without this atomicity. Wait/signal/wait problem One problem that I came across is what I'll call the wait/signal/wait problem. Setting the state, thread 1 is waiting on a condition and thread 2 has just completed cond_signal. Without an atomic SOAW(), thread 1 may release the external mutex without obtaining the associated semaphore. Another thread, thread 3, may obtain the external lock and find the cond_var signaled and behave correspondingly. This I believe is incorrect - a waiter which obtains the external mutex after the signaler has exited signal()should not find cond_var signaled. This situation is unlikely but it makes assumptions about the scheduler that I am not comfortable with. If there's a flaw in my reasoning hopefully someone will point that out. This solution This solution is structurally somewhat similarly to the paper's solution. One point to note is that notify_one()/signal() blocks on an event in the same manner as notify_all()/broadcast(). There may be a solution which does not block the signaler while wake-processing is occurring, but I saw additional complexity on that path and decided to forgo it for the time being. I hope the solution is correct but have only testing to validate. I haven't used any formal methods to back it up. Maybe I'll construct a Petri net sometime. That's always .. fun. I throw this solution on the mercy of the court. External mutex I have yet to see production examples of cond_var use where signalers do not hold the external mutex while they signal, but this use case is allowed by POSIX. My original solution (if it is in fact a solution) relies on some particular external mutex being held by all waiters and signalers for some particular condition variable. I recently added two mutexes to solve that situation but I have only minimal testing experience with that recent addition. Use of these new locks is demarcated with WIN32_POSIX_SEMANTICS. Interprocess vs. Intraprocess I'm not sure if there is support for process-specific synchronization objects in boost.interprocess, but if support is present or was added at some future time this could help optimize things for win32. At the moment win32 interprocess mutexes rely on assigning random names to mutexes (only named mutexes can cross platform boundaries in win32), and all mutex operations have to look up the mutex by this name. Interprocess seems to have been designed primarily with pthreads in mind, and things get a little awkward on Windows in this regard. Similarly, it would be nice to be able to use the native condition variables that win32 added for Vista+, but these can't be used across processes according to the documentation, and so can't be used AFAICT for inteprocess_condition. Correspondingly, an intraprocess_mutex would be able to forgo the win32 mutex name lookups. Miscellaneous Not all interprocess tests currently pass. There are some additional variations of mutex like the upgradable/sharable, etc., that I haven't looked at in detail. I'm hoping that this patch goes far enough that it'll have some momentum. I'm happy to either complete this work in the future or help whoever undertakes the task, but I may not be able to justify much of my time to the task in the short term to my employer. I realized a little too late that I didn't keep formatting entirely consistent with the existing code. Apologies. Hopefully it's only the opening block curlies. Thanks. Dan

3 13

[C++ Now! 2012] Call for Submissions
by Brian Wood 30 Oct '11

30 Oct '11

Hartmut Kaiser: > The C++ Now! Conference is dedicated to discussion and education > about C++, an open and free language and standard. It costs a lot to buy a copy of the standard now! Hope conference goes well and maybe I can attend someday. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

[BGL] How to provide a vertex_index property for my graph
by ShNaYkHs ShNaYkHs 30 Oct '11

30 Oct '11

Hello, Since my graph use setS as a VertexList, I have to either provide a vertex_index property map for my graph to be able to use some functions requiring a vertex_index (e.g. write_graphviz). My graph is defined as: typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; Where NodeData and EdgeData are structures. Can you please give me a very simple example of how to provide a vertex_index property map for my graph ? I mean, since an adjacency_list that uses listS or setS as the vertex container does not automatically provide this vertex_id property, how can I add it to the code bellow ? I tried to use an associative_property_map to include index for vertices, but it doesn't work (errors): #include <boost/graph/iteration_macros. hpp> #include <boost/graph/adjacency_list.hpp> using namespace std; using namespace boost; struct NodeData { int label; float influance; /* etc ... */ }; struct EdgeData { int age; /* etc ... */ }; typedef map<vecS, size_t> IndexMap; IndexMap mapIndex; associative_property_map<IndexMap> propmapIndex(mapIndex); typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; typedef Graph::vertex_descriptor NodeID; typedef Graph::edge_descriptor EdgeID; int main() { Graph g; NodeID n0 = add_vertex(g); g[n0].label = -1; NodeID n1 = add_vertex(g); g[n1].label = -1; EdgeID edge; bool ok; tie(edge, ok) = boost::add_edge(n0, n1, g); if (ok) g[edge].age = 10; int i=0; BGL_FORALL_VERTICES(v, g, Graph) { put(propmapIndex, v, i++); } return 0; } Thanks for answer.

1 0

[C++ Now! 2012] Call for Submissions
by Hartmut Kaiser 30 Oct '11

30 Oct '11

INAUGURAL C++ NOW! CONFERENCE 2012 Aspen CO, USA, May 14-18, 2012, www.cppnow.org CALL FOR SUBMISSIONS We invite you to submit session proposals to the Inaugural C++ Now! Conference: C++Now! 2012 (Aspen CO, USA, May 14 - 18, 2012). Based on the successful traditions of 5 years of BoostCon, which was the main face-to-face event for all things C++ and Boost (www.boost.org) C++Now! 2012 will present leading speakers from the whole C++ community. The conference name is changing to C++ Now! to reflect the current value of the language, the focus on its new state (from the new Standard), and the need to continually look to the future so the language remains useful to the C++ community. The focus of this conference will be the new C++11 language Standard and as usual Boost: what's new in C++, its Standard library, and in the Boost libraries, how to write and maintain them, how to evangelize or to deploy Boost within your organization. The new C++ Standard, but also the infrastructure and process of Boost, its vision and mission - no matter what you are interested in, it all comes together in the C++Now! sessions. Meet the colleagues, and feel the inspiration to support your work with C++ and Boost for the next year. The C++ Now! Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++Now! have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. IMPORTANT DATES New proposal submissions due: January 10th, 2012. Proposals decisions sent (tentative program available): February 17th, 2012. Fully scheduled program available: February 25th, 2012. Session materials due: April 15th, 2012. BEST PRESENTATION AWARDS We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++Now! website for that year and a plaque containing all the C++Now! conference information. SESSION TOPICS Topics of interest include, but are not restricted to, the following: * C++11 and how it changes life for users and library writers * General tutorial sessions on C++11, the C++11 Standardslibrary, and one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to C++11, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 and Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific skills relevant to C++11 and Boost. Workshops Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner These were introduced at BoostCon 2008, and were a great Presentations success They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors We actively encourage tool vendors and ISP's to submit Presentations proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL Standard Sessions are 60 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 60 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10- 20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2012. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++Now! website and will be available to attendees. For general information on the C++Now! 2012 paper submission or the scope of technical papers solicited, please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2012(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to C++ Now!. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Dave Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

Re: [boost] Silly Boost.Locale default narrow string encoding in Windows
by Daniel James 29 Oct '11

29 Oct '11

On Saturday, 29 October 2011, Peter Dimov wrote: > > > The "dir" command has no problem displaying arbitrary file names directly > to the console (presumably via WriteConsoleW), but once it has to write to > a file, it needs to convert to narrow and no code page other than 65001 can > express the above file name. > This is not that relevant to the wider issue, but wide streams will work for console output if you first do this: if (_isatty(_fileno(stdout))) _setmode(_fileno(stdout), _O_U16TEXT); if (_isatty(_fileno(stderr))) _setmode(_fileno(stderr), _O_U16TEXT); i.e. set the output mode to UTF-16 when writing to the console. This only works for recent versions of Visual C++. Obviously doesn't fix piped output.

3 2