April 2011 - Boost - lists.boost.org

Re: [boost] [Filesystem] Linking problem with 1_46_1
by Max Moorkamp 06 Apr '11

06 Apr '11

>> > Max Moorkamp wrote: >> > >>> >> Hi, >>> >> >>> >> I have recently upgraded to boost 1_46_1 and since then I am experience >>> >> linking problems with the filesystem library. >>> >> >>> >> I have performed a standard install using ./bootstrap.sh; bjam; bjam >>> >> install under Ubuntu 10.04 with the default gcc (4.4.3). >>> >> >> > > I had some issues in my early attempts. My problem was with my libs > location, then I installed this way: > > > - $ ./bootstrap.sh --with-toolset=gcc --prefix=/usr/local > --includedir=/usr/include --libdir=/usr/lib > --with-libraries=system,date_time,thread,filesystem > - $ ./bjam > - # ./bjam install > > Before to do it even linking lboost_system and lboost_filesystem didn't > work. Thanks for that. However, the linker does find the boost_filesystem library. If I just do g++ test.cpp -lboost_system then I get some additional linker errors /tmp/cc10fHYI.o: In function `boost::filesystem3::path::codecvt()': test.cpp:(.text._ZN5boost11filesystem34path7codecvtEv[boost::filesystem3::path::codecvt()]+0x5): undefined reference to `boost::filesystem3::path::wchar_t_codecvt_facet()' /tmp/cc10fHYI.o: In function `boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)': test.cpp:(.text._ZN5boost11filesystem39copy_fileERKNS0_4pathES3_[boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)]+0x2a): undefined reference to `boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option::enum_t, boost::system::error_code*)' collect2: ld returned 1 exit status so it seems that in the version I have just boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option::enum_t, boost::system::error_code*)' is missing. Actually I just found one clue. If I do nm -Ca /usr/local/lib/libboost_filesystem.so | grep boost::filesystem3::detail::copy_file I get boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option::enum_type, boost::system::error_code*) so the library uses boost::filesystem3::copy_option::enum_type, while the linker is looking for boost::filesystem3::copy_option::enum_t. This must have something to do with some preprocessor macro, but I can't figure out which one and why. Regards Max -- Max Moorkamp IFM-GEOMAR Wischhofstr. 1-3 24148 Kiel Tel.: Germany - 431 - 600 2570 FAX.: Germany - 431 - 600 2915

1 0

Re: [boost] [lexical cast] Performance improvements
by Vicente BOTET 05 Apr '11

05 Apr '11

> Message du 05/04/11 18:18 > De : "Antony Polukhin" > A : boost(a)lists.boost.org > Copie à : > Objet : Re: [boost] [lexical cast] Performance improvements > > >From Gruenke, Matt > > I`ve looked at Boost.Conversion library at sandbox/conversion/. The > idea is interesting, but: > > 1) > > char ch = '0'; > > std::cout << boost::lexical_cast(ch) << " " << > boost::numeric_cast(ch); > > This code will output "0 48" Good point. Thanks for this simple example. > We can not make your library output both values... There are some > tags, but in both cases it will be boost::dummy::type_tag (or > may be I didn`t get the idea) I have not tried that, but i guess that you could use different tags for different conversions. I'm not sure the following will compile (I will try soon) template struct lex { typedef T type; }; template struct num { typedef T type; }; template typename Target::type convert_to(Source const& v , boost::dummy::type_tag > const&) { return lexical_cast(v); } template typename Target::type convert_to(Source const& v , boost::dummy::type_tag > const&) { return numeric_cast(v); } Then you can use them as follows std::cout << boost::convert_to< lex >(ch) << " " << boost::convert_to< num >(ch); This code will output "0 48" This is a little bit artificial, but it could work in some contexts. Note that I'm not saying the library should be used in tis way. > 2) For each conversation user will need to write > convert_to function overload. It will be much better, > if user was required to write only one conversion function (to some > intermediate type), and the library will be able to convert to any > other type from intermediate type. There is already lexical_cast and Boost.StringConvert (to be reviewed soon) that use an intermediary type or mechanism. Boost.Conversion is intended to provide an interface for direct conversions which should be more efficient in most of the cases (as you have shown). If you know that two types are convertible using an intermediary type, you can use convert_to_via Target target = convert_to_via(source); > I use lexical_cast<>() a lot, so I`d better improve it first. I guess any improvement to lexical_cast that preserves the semantics will be welcome by the Boost comunity. Best, Vicente

1 0

Why Boost.Build?
by Gregory Crosswhite 05 Apr '11

05 Apr '11

Hey everyone, Is there a reason why Boost uses Boost.Jam/Boost.Build for reasons other than tradition? Does it have advantages over other build systems, in particular CMake (which I consider to be its main competitor)? Are there many people/projects who use Boost.Jam/Boost.Build outside of Boost? These questions are asked purely out of curiosity due to my ignorance of Boost.Jam/Boost.Build, not because I have an axe to grind. Cheers, Greg

23 43

std::tuple vs boost::tuple clashes in C++0x
by Christopher Jefferson 05 Apr '11

05 Apr '11

Just wanted to post a general comment, to boost library developers. There are lots of names which in C++0x occur in both boost:: and std::. The big ones are tuple, make_tuple and array, but there are others (for example locking functions from thread). I am fixing bugs which occur in the C++0x mode of clang/libc++, and the vast majority of these bugs are tests which write things like: ... using namespace boost; using namespace std; .... tuple<int,int> t; Even if you don't include <tuple>, a definition of tuple gets pulled in by <utility>, which almost everything includes. Please don't write "using namespace std; using namespace boost;" in boost tests. You probably shouldn't write it at all :) Chris

3 3

Re: [boost] GSoC Proposal Preparation For Encoding Awared String
by Artyom 05 Apr '11

05 Apr '11

> From: Soares Chen <crf(a)hypershell.org> > > Hi all, > > [snip] > > I think there are several options that I can choose for my project: > 1. To use Chad Nelson's code as base, try to incorporate other ideas > proposed in the mailing list, integrate with Boost.Locale, and make it > Boost quality to submit for review. If this option is chosen, I wish > that Chad Nelson can be my mentor. > 2. To start a new code base, gather and compile ideas suggested in > mailing list, final design decisions made by me and my mentor but not > the community (to keep the project going on fast), make it Boost > quality and submit for review. > 3. To start the boost::string project, where another better string is > reinvented and fix all the weaknesses of std::string. > 4. Adopt different proposal, and improve on existing project such as > Boost.Unicode [2] or Boost.Locale [3] such that it really solves the > encoding awareness problem. > 5. Any other suggestion? Hello, I want you to address several points: It would be very hard to get the consensus about the way to solve the problem. Probably the best and the most wishful thinking solution is to assume that all strings are UTF-8 based, however it is not the reality. The problem is actually not the string but rather the way you code. Even if you create a perfect UTF-8 string and then call fopen(your_perfect_string.c_str(),"r") Under windows... And it would not work <sigh... damn Windows> As you can see from multiple discussions, there are many contradicting requirements about how should string look like and what should it bring with. If you want to provide better Unicode awareness to Boost you don't need new cool utf-XYZ string, you need a policy. I think boost::filesystem v3 is a big step forward, it allows you to use UTF-8 strings on Windows which I think is a really good beginning. This is my opinion. Boost.Locale and several other my projects (CppCMS, CppDB) live happily with std::string. The problem is that in vast majority of cases you don't need encoding aware string, as so many operations you usually do on strings are encoding agnostic. But this is other story. Bottom line, if you want to improve Unicode awareness of Boost I think you need to adopt Boost.Filesystem v3 like policy all over the code base of Boost. 1. Use Wide API as native one in Boost everywhere under Windows 2. Use char * API as native one in Boost everywhere under non-Windows platforms 3. Use std::codecvt to handle this (after many tricks... ) The Unicode String/Encoding Aware String is the last thing to do not the first thing. Why? 1. Because you will never get the consensus about what is the "right-thing" to do (wide, narrow, utf-8, utf-16) etc. Project that are handled and directed by a single source or management like Qt, GTK(mm), Java, C#, Python or others may decide what is the right thing. This will never happen in Boost as it is too pluralistic even in cases where it does not always make sense, just because the way libraries are developed, reviewed and got in - based on public reviews that eventually encourages diversity. 2. Because you would not likely to be able to enforce users to actually use your string. As boost is more about collaboration then enforcement of specific style. 3. Even heavy discussions there hadn't got to any conclusion. So what would happen and final review of your library? My $0.02 Artyom

7 11

Re: [boost] [lexical-cast] version of lexical_cast in 1.46.1 is quite older than in trunk
by Antony Polukhin 05 Apr '11

05 Apr '11

Christopher Jefferson wrote: > On 4 Apr 2011, at 21:19, Antony Polukhin wrote: >> >> If there will be no active maintainer, I`d like to have at least >> commit permissions to lexical_cast library (if nobody has objections). >> I`ve got some ideas on implementing tags/ios flags and there are some >> more possible optimizations for float types and locales usage. > > If you are making modifications, there really needs to be someone who keeps an eye on the test results and bug reports to make sure nothing is broken. > > If you want to make some changes anyway,why not also be the maintainer? :) > > Chris I like your idea. But I need some information on how to maintain boost library and how to become a maintainer. - Antony

1 0

GSoC 2011(Weighted Voronoi Diagram)
by Sultana Rashid 05 Apr '11

05 Apr '11

Hello, I have mailed about some ideas on Boost Graph Librrary.I have gone through some libraries of Boost.I did not find Weighted Voronoi Diagram. I have studied and implemented it in C++.It might be interesting to you. Thanking You, Mariya

2 1

GSoC2011 proposal submitted : Community Detection Module
by Xu Sun 05 Apr '11

05 Apr '11

Hi, I have submitted the proposal about implementing a community detection module for BGL. Everyone is welcomed to give me a comment as the feedback. Details at: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/sunbow/1 Thanks, Xu Sun

1 0

Re: [boost] [lexical cast] Performance improvements
by Antony Polukhin 05 Apr '11

05 Apr '11

>From Gruenke, Matt >>From Vicente BOTET, on Mon 4/4/2011 5:59 PM: >> I think that it is better to improve my library that is there to manage with any conversion, and let lexical cast do what it did originally. >> Let me know what do you think. > >It didn't sound like he change the behavior of lexical_cast<>(), at all. I am very much in favor of these optimizations going in, since I have a large >amount of code which uses lexical_cast<>(). Yes, I did not changed the behavior of the library, but only added optimizations for some conversions, which sometimes occur when lexical_cast is used in generic programming. There are some more optimizations for lexical_cast in bug database (tickets #5417 and #5350) >From Vicente BOTET > Let me know what do you think. > > Best, > Vicente I`ve looked at Boost.Conversion library at sandbox/conversion/. The idea is interesting, but: 1) char ch = '0'; std::cout << boost::lexical_cast<int>(ch) << " " << boost::numeric_cast<int>(ch); This code will output "0 48" We can not make your library output both values... There are some tags, but in both cases it will be boost::dummy::type_tag<char> (or may be I didn`t get the idea) 2) For each conversation user will need to write convert_to<required_type> function overload. It will be much better, if user was required to write only one conversion function (to some intermediate type), and the library will be able to convert to any other type from intermediate type. I use lexical_cast<>() a lot, so I`d better improve it first.

1 0

[release][1.47] Release branch open + schedule
by Daniel James 05 Apr '11

05 Apr '11

Hello everyone, It's been over a week since the release, so it's time to open the release branch. Since we're running late, and we haven't discussed the changes to the schedule, and I think it helps people to pace their development, we should probably decide on a schedule for this release pretty quickly, and then discuss the schedule for future releases later. We discussed having longer betas, 4 weeks was suggested. If we do that this time, it'll leave a very small window for merging to release, so I think 3 weeks might be better. Something like: 4th April: Release branch closed for beta (bug fixes only). 11th April: Beta target date. 2nd May: Release target date. Note: That's just a proposal, not the actual schedule. It isn't up to me. That's still a tight schedule, maybe a shorter beta or a delayed release would be better. Any thoughts? Daniel

4 7