- Boost - lists.boost.org

[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

[1.48.0.beta 1][interprocess] detail namespace
by Jan Boehme 28 Oct '11

28 Oct '11

Hi, is the change of the name of the namespace 'detail' to 'ipcdetail' intended to be in the release? Isn't it over-qualified as it is located in the the namespace 'boost::interproces' anyway?. Btw it breaks our code and should mentioned in the release notes of the library. Thanks for reading, Jan.

4 6

[filesystem and beyond] Narrow strings be UTF-8
by Yakov Galka 28 Oct '11

28 Oct '11

On Wed, Oct 26, 2011 at 22:13, Beman Dawes <bdawes(a)acm.org> wrote: > (2) V3 may work OK with the Microsoft 65001 UTF-8 codepage, although > I've never used it myself and you would have to pass in a UTF-8 > encoded narrow character name. > If it had been possible, it would simplify everything. Unfortunately, you cannot set UTF-8 codepage for windows API functions (you can for the console though). Microsoft isn't interested in making portability easier, so I don't see them adding the support in the nearest future. But they could. UTF-8 should be considered as the only default narrow encoding on windows, because all other ANSI encodings are not unicode-aware. On Wed, Oct 26, 2011 at 22:47, Beman Dawes <bdawes(a)acm.org> wrote: > On Wed, Oct 26, 2011 at 6:24 AM, Yakov Galka <ybungalobill(a)gmail.com> > wrote: > > [...] > > Even if you fix the Unicode problems, > > What Unicode problems are you running into? Although there are some > locale related tickets outstanding, I'm not aware of any Unicode > issues. > 1) The one that was brought up in the previous thread. 2) The complexity of writing portable unicode-aware code: currently you're forcing me to a) use wstring on windows, or if I prefer to use my favorite portable UTF-8 encoded strings b) write all the boilerplate code that passes codecvt everywhere as a parameter (see below why ¬imbue()). In both cases you're shifting the complexity to the higher-level code. It's not a kind thing for you as a low-level library developer to do, The library is expected to ℍ𝕚𝕕𝕖 the platform differences by providing a uniform interface. ⇒ Myth: Using the native encoding on each platform results in portable code. ‽ In some definition of 'portable' definitely yes. But not when things are shared among different platforms. It starts with files transferred between different systems and ends with the source code itself (there is a different between "" and L""). Uniformity == simplicity. Consider a simple case of loading a path from some project file and loading the referenced file: The project file is encoded in UTF-8 making it portable among all systems with CHAR_BIT == 8. // Option a) #include "codecvt_implementation.h" std::basic_ifstream<native_char> fin("project.file"); std::basic_string<native_char> str; fin.imbue(locale(fin.getloc(), new utf8_to_native_codecvt())); getline(fin, str); fs::ifstream fin2(project_path/str); // Option b) #include "codecvt_implementation.h" std::ifstream fin("project.file"); std::string str; getline(fin, str); fs::ifstream fin2(fs::path(project_path).append(str, utf8_to_native_codecvt())); // c) How it could be done std::ifstream fin("project.file"); std::string str; getline(fin, str); fs::ifstream fin2(project_path/str); ⇒ Use boost⸬filesystem⸬imbue to convert b to c. ‽ Who is responsible for calling imbue()? I'm writing library code. I'm not allowed to change the global-state. ⇒ This code will break: int main(int argc, char* argv[]) { fs::ifstream fin(argv[1]); } ‽ It works fine for ASCII characters on all sane platform. For non-ASCII, I don't care. It's already not unicode-aware if the native encoding is not UTF-8 (which can't be so on Windows). If the writer of this code really cares about internationalization, she can use boost⸬program_options (assuming it's also changed to follow the UTF-8 convention). Otherwise she's a hypocrite. ⇒ UTF-8 is slow. ‽ Compared to what? You haven't measured this. On windows: we must do complicated operations on paths before we pass them to the OS anyway (system_complete, prepend \\?\). Most of the strings contain ASCII characters so std::strings take less memory, thus decreasing cache thrashing in other parts of the program. On other OSes: the encoding is already almost always UTF-8. Experience shows that the small overhead (if it's an overhead at all) is not the bottleneck. Many cross-platform libraries already switched to UTF-8 for narrow-chars (see one of the previous discussion for a list), and I don't see a reason why boost can't be the next. -- Yakov

2 1

Making Boost.Filesystem work with GENERAL filenames with g++ in Windows (a solution)
by Alf P. Steinbach 28 Oct '11

28 Oct '11

First, apologies if I'm posting to the wrong group/list; if so then please redirect me. IMHO access to files is a crucial part of Boost.Filesystem. However, with Boost 1.47, and using g++ 4.4.1 in Windows 7, boost::filesystem::ifstream etc. fail to open or create files with non-ANSI characters. It works fine with Visual C++; it FAILS with g++ 4.4.1, which is the one bundled with the Code::Blocks IDE. The failure probably has nothing to do with the g++ version: it's due to g++ not offering the Visual C++ wchar_t oriented extensions to the standard iostreams (Boost.Filesystem uses these Visual C++ extensions). I stumbled onto this while I was writing about using Unicode in C++ programming in Windows. I wrote up a technical solution in section 5, starting on page 16, of that work-in-progress document, available on Google Docs at: https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B2oiI2re… Essentially, the fix I ended up with, full source code given in the above doc, uses Windows short file names if (1) there is no wide character support and if furthermore (2) the filename can't be perfectly translated to ANSI. The C++ implementation's support for wide chars is automatically detected using C++98-compatible code. I do not know what to do with this. But considering that Boost.Filesystem is slated for later inclusion in the C++ standard library (or at least into TR2), I think it would be nice if it is able to give access to all accessible files in Windows, also with g++, so that we don't end up with a file handling part of the standard library that can't handle files in general; hence this posting and plea for advice -- what more should I do, if anything? Cheers, - Alf

10 24

Re: [boost] [1.48.0] Beta 1 is now available from SourceForge
by Martin Elzen 28 Oct '11

28 Oct '11

Okay, I gave compiling the beta 1 another shot, as follows: ./bootstrap.sh --prefix=/home/martin/app/boost/installation --with-icu=/home/martin/app/icu/installation ./b2 -sICU_PATH=/home/martin/app/icu/installation install >out.b2.install 2>&1 & the b2 output then does start as follows: Performing configuration checks - has_icu builds : yes warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - iconv (libc) : yes - icu : yes ... but then later on there are compilation errors in Boost.Locale, such as: > In file included from libs/locale/src/icu/formatter.cpp:25:0: > libs/locale/src/icu/predefined_formatters.hpp: In member function ‘icu_48::NumberFormat* boost::locale::impl_icu::icu_formatters_cache::number_format(boost::locale::impl_icu::icu_formatters_cache::fmt_type) const’: > libs/locale/src/icu/predefined_formatters.hpp:127:61: error: ‘URBNF_SPELLOUT’ was not declared in this scope > libs/locale/src/icu/predefined_formatters.hpp:127:61: note: suggested alternative: > /home/martin/app/icu/installation/include/unicode/rbnf.h:49:5: note: ‘icu_48::URBNF_SPELLOUT’ > libs/locale/src/icu/predefined_formatters.hpp:130:61: error: ‘URBNF_ORDINAL’ was not declared in this scope > libs/locale/src/icu/predefined_formatters.hpp:130:61: note: suggested alternative: > /home/martin/app/icu/installation/include/unicode/rbnf.h:50:5: note: ‘icu_48::URBNF_ORDINAL’ > > "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_LOCALE_DYN_LINK=1 -DBOOST_LOCALE_NO_WINAPI_BACKEND=1 -DBOOST_LOCALE_WITH_ICONV=1 -DBOOST_LOCALE_WITH_ICU=1 -DBOOST_THREAD_NO_LIB=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I"." -I"/home/martin/app/icu/installation/include" -c -o "bin.v2/libs/locale/build/gcc-4.6.1/release/threading-multi/icu/formatter.o" "libs/locale/src/icu/formatter.cpp" The above errors are probably caused because I did what ICU recommends you do (for the first time ever), which is: -# define U_USING_ICU_NAMESPACE 1 + // Set to 0 to force namespace declarations in ICU usage. +# define U_USING_ICU_NAMESPACE 0in the ICU unicode/uversion.h file The above is advised in ICU 's readme.html in the How To Build And Install ICU / Recommended Build Options section... Has that advice become incorrect in recent ICU versions, perhaps?

1 0

[1.48.0] Beta 1 is now available from SourceForge
by Beman Dawes 27 Oct '11

27 Oct '11

Boost release 1.48.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.48.0.beta.1/ This release includes 3 new libraries (Container, Locale and Move), an extension to TypeTraits to support operator detection as well as updates to many existing libraries. For partial details of what's in the release, see http://beta.boost.org/users/history/version_1_48_0.html. This page is still in process of being updated, and there are some known issues with links. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

4 5

[1.48.0] Beta 1 release candidates available
by Martin Elzen 27 Oct '11

27 Oct '11

Beman Dawes <bdawes(a)acm.org> wrote: > Release candidate files for 1.48.0 beta 1 are available at > http://boost.cowic.de/rc/ > > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. On Ubuntu 11.10 amd64 with g++ (and gcc) 4.6.1, I built ICU 4.8.1 with almost all default options except for specifying a non-default installation dir. Then I created the LD_LIBRARY_PATH environment variable and set it to the lib dir of that new ICU installation *but did not* also create an ICU_PATH environment variable. Then I ran the boost bootstrap.sh script with a '--with-icu=/home/martin/app/icu/installation' parameter. The output of the b2 contained (among other things) the following bits about ICU: - has_icu builds : yes ... - icu : no - icu (lib64) : no Which led me to expect that the boost regex libs would end up referencing the Ubuntu default ICU libs (which was not what I wanted to do). But they didn't, instead they *did* correctly reference the newly built ICU libraries (or at least that's how I'm interpreting the output of ldd against libboost_regex.so ). Which is nice, but doesn't that also mean that the docs in Boost regex about the ICU_PATH environment variable might need some revision? Or did I just luck out somehow?

4 3