- Boost - lists.preview.boost.org

Re: [boost] [range] for_each and std::map of std::list
by Thorsten Ottosen 07 Apr '11

07 Apr '11

Den 07-04-2011 11:37, Mathias Gaunard skrev: > On 06/04/2011 19:55, Thorsten Ottosen wrote: >> I suggest the syntax >> >> rngOfContainers | boost::adaptors::flattened >> >> and the underlying iterator should be up to bidirectional (if the >> underlying two container types support it). >> >> Anyone interested in implementing this? > > I have an implementation of this somewhere. > > One annoying thing is that you cannot detect that a type is a range > reliably. Well, that is only a problem if you want to avoid manually applying the adaptor twice (or more), right? If so, I think that is a limitation we can live with. A simple solution covers most cases IMO. -Thorsten

1 0

mismatched versions of Boost.Build engine and core
by Paul A. Bristow 07 Apr '11

07 Apr '11

I've got this message after running a bjam warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (bjam) is 03.1.19 warning: Boost.Build core (at I:/boost-trunk/tools/build/v2) is 2011.04-svn Should I worry about this? I've tried to re-build using I:\boost-trunk\tools\build\v2\engine>bjam --toolset=msvc >build_bat.log but it still complains ### No toolset specified. Please use --toolset option. Is this supposed to be --toolset=msvc or --toolset msvc Suggestions? Thanks Paul PS This bit of the doc didn't seem right be me "For the Boost.Jam source included with the Boost distribution the jam source location is BOOST_ROOT/tools/jam/src." and was suggesting running build.bat I:\boost_1_46_0\tools\build\v2\engine\src contained build.bat and build.jam --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 4

Re: [boost] [shifted_ptr] Review Request
by Olaf van der Spek 07 Apr '11

07 Apr '11

On Wed, Apr 6, 2011 at 7:22 PM, Phil Bouchard <phil(a)fornux.com> wrote: > > > On 4/6/2011 9:58 AM, Olaf van der Spek wrote: >> >> What version of Boost was used? > > 1.34.1 > >> Does it use make_shared? > > No. Not very meaningful either, I'm afraid.

3 2

[shifted_ptr] Review Request
by Phil Bouchard 06 Apr '11

06 Apr '11

Greetings, For those who are not aware in 2008 I wrote a memory manager running in real-time so that heap objects are being destructed instantly. A quick introduction can be found here: https://svn.boost.org/svn/boost/sandbox/shifted_ptr/libs/smart_ptr/doc/Shif… The library still needs more documentation but we can see the simplicity of its usage in its examples found in the sandbox. Here's a quick copy & paste compilation of the examples: $ svn co http://svn.boost.org/svn/boost/sandbox/shifted_ptr $ cd shifted_ptr/libs/smart_ptr/example $ make shifted_ptr_test1 $ make t100_test1 $ ./shifted_ptr_test1 $ ./t100_test1 "shifted_ptr_test1" shows its versatility and simplicity while "t100_test1" shows a more complicated application on a neural network. I would like to request a review while I add the necessary documentation for a better support. Thanks, -Phil

8 30

Re: [boost] Python 3.2: convert convert PyObject* to PyUnicodeObject*?
by Ralf W. Grosse-Kunstleve 06 Apr '11

06 Apr '11

Thanks for the patch and the pointer. I just checked in the fix and closed the ticket. Ralf ----- Original Message ----- > From:Matthew Bradbury <matt-bradbury(a)live.co.uk> > To:boost@lists.boost.org > Cc: > Sent:Wednesday, April 6, 2011 3:43 AM > Subject:Re: [boost] Python 3.2: convert convert PyObject* to PyUnicodeObject*? > > Steve M. Robbins <steve <at> sumost.ca> writes: > > > > > Hi, > > > > Boost 1.46.1 fails to build with Python 3.2 on linux (Debian). The > > build fails with: > > > > error: cannot convert -F�PyObject*� to �PyUnicodeObject*� for argument �1� > to > �Py_ssize_t > > PyUnicodeUCS4_AsWideChar(PyUnicodeObject*, wchar_t*, Py_ssize_t)�-A > > > > at this code: > snip > > > > Is there an easy fix? > > > > Thanks, > > -Steve > > > Yes, I submitted a bug and a patch some time ago. > > https://svn.boost.org/trac/boost/ticket/4994 > > Matt > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [range] for_each and std::map of std::list
by Thorsten Ottosen 06 Apr '11

06 Apr '11

Den 06-04-2011 16:03, Mark Snelling skrev: > Hi, > > Consider a map defined as... > > std::map< int, std::list< std::string > > my_map; > > I'm wondering if/how it's possible to use Boost.Range to call a function > on each std::string in each of the lists contained in the map. I have an > implementation below which works using a C++0x lambda function but am > curious if this can be done purely using Boost.Range? > > boost::for_each( > boost::adaptors::values( my_map), > []( const std::list< std::string >& my_list ) { boost::for_each( > my_list, some_func ); } ); > > ideas anyone? What we need is a generic range adaptor that can make a container of containers look like a "flat" sequence. I suggest the syntax rngOfContainers | boost::adaptors::flattened and the underlying iterator should be up to bidirectional (if the underlying two container types support it). Anyone interested in implementing this? -Thorsten

2 2

Python 3.2: convert convert PyObject* to PyUnicodeObject*?
by Steve M. Robbins 06 Apr '11

06 Apr '11

Hi, Boost 1.46.1 fails to build with Python 3.2 on linux (Debian). The build fails with: error: cannot convert -F�PyObject*� to �PyUnicodeObject*� for argument �1� to �Py_ssize_t PyUnicodeUCS4_AsWideChar(PyUnicodeObject*, wchar_t*, Py_ssize_t)�-A at this code: static std::wstring extract(PyObject* intermediate) { std::wstring result(::PyObject_Length(intermediate), L' '); if (!result.empty()) { int err = PyUnicode_AsWideChar( intermediate , &result[0] , result.size()); if (err == -1) throw_error_already_set(); } return result; } Is there an easy fix? Thanks, -Steve

3 2

[config] Boost PP and variadic macros
by Edward Diener 06 Apr '11

06 Apr '11

This is largely directed to John Maddock, the maintainer of config, but of course anyone else can respond who is interested. I have been working to integrate my VMD library, and essentially variadic macro support, into Boost PP, with help and discussion offline of Paul Mensonides. I am now at the testing phase and all is now going well. This is currently being done in a separate library but when Paul and I are satisfied we intend to update the trunk with our changes. The library is at https://svn.boost.org/svn/boost/branches/pplib/variadics. One problem that I have can be explained by the fact that Boost PP currently does not depend on any other Boost library, not even Boost config. The reason for this is that Boost PP has been designed to work with C compilers ( or C++ compilers in C mode ) as well as C++ compilers. This means that the code to detect variadic macro support in Boost is duplicated in two places, both in config, which I basically started with the blessing of John Maddock with the BOOST_NO_VARIADIC_MACROS macro, and in Boost PP in a configuration file which I have coded and essentially duplicates the code in config for variadic macro support. I do not like this. Duplicating functionality in two different places, even as simple as determining variadic macro support for compilers, is error prone and a maintenance problem. Changes in one place have to be done in the other, and this would need to constantly be tracked. My initial thought was to see if config could work with C compilers, but all investigation there has led me to believe that it would be too many unnecessary changes to config, would complicate config greatly, would need extensive testing against all compilers, and that since config is central to all of Boost such a potential massive change to it it is a bad idea. So my current thought is to remove the code in config which tests for variadic macro support for a given compiler, to determine if BOOST_NO_VARIADIC_MACROS should be set, into a separate header file for each compiler which might set BOOST_NO_VARIADIC_MACROS, and then #include that header file in the compiler's header file, at the place where currently the setting of BOOST_NO_VARIADIC_MACROS exists ( or possible at the end ). The separate header file itself for testing variadic macro support is easily C compatible and I could use it in my Boost PP configuration file. This would eliminate duplication of the code to test for variadic macro support in config and Boost PP while keeping the goal of allowing Boost PP to still work with C compilers. Is this possible/desirable as far as config goes ? It would only affect the current code for setting BOOST_NO_VARIADIC_MACROS, hardly a Boost world-shaking event, and can easily be done by me and tested in regression tests. If it is, one further consideration is that the code in the Boost PP configuration file still would have to internally duplicate the checking and order of each compiler in the 'select_compiler_config.h' in config, but this is at least much better, and much less of a maintenance problem for Boost PP, than having to duplicate the code for checking for variadic macro support itself. Even this could be worked around, with a probably undesirable change to 'select_compiler_config.h', which I will proceed to suggest nonetheless. If we could add to that file another set of #defines for the corresponding variadic macro checking header file for each compiler that needs it. Something like: #define BOOST_COMPILER_CONFIG_NVM "boost/config/compiler/somecompiler_nvm.hpp" then in my Boost PP config header file I could go: #include <boost/config/select_compiler_config.hpp> #ifdef BOOST_COMPILER_CONFIG_NVM #include BOOST_COMPILER_CONFIG_NVM #endif and I could then check BOOST_NO_VARIADIC_MACROS and this will work for C compilers ( 'select_compiler_config.hpp' itself has nothing related to C++ and should work with any C compiler AFAICS ). But I would understand that littering 'select_compiler_config.hpp' with another set of #defines just to satisfy my need in Boost PP may not be acceptable to the clean design of that file, even if it would eliminate my need to reduplicate its logic in the Boost PP configuration file for variadic macro support in Boost PP which I have created.

5 17

archive_exception causes Link failure serialization
by Paul A. Bristow 06 Apr '11

06 Apr '11

I am trying to rebuild an existing demo program for Johan Rade's nonfinite facets from François Mauger The program was previously tested with Boost 1.44, gcc 4.4.1, Linux/i686 (32bits) Using MSVC 10, it compiles OK, but fails to link. Can anyone gives me any clues what I am doing wrong? Thanks! Paul ------ Rebuild All started: Project: nonfinite_num_serialization, Configuration: Release Win32 ------ nonfinite_num_facet_serialization.cpp Searching libraries Searching C:\Program Files\Microsoft SDKs\Windows\v7.0A\lib\kernel32.lib: <snip> Searching C:\Program Files\Microsoft Visual Studio 10.0\VC\lib\libcpmt.lib: Searching I:\boost-trunk\stage\lib\libboost_serialization-vc100-mt-s-1_47.lib: Finished searching libraries Creating library J:\Cpp\MathToolkit\test\Math_test\Release\nonfinite_num_serialization.lib and object J:\Cpp\MathToolkit\test\Math_test\Release\nonfinite_num_serialization.exp Searching libraries Searching C:\Program Files\Microsoft SDKs\Windows\v7.0A\lib\kernel32.lib: <snip> Searching C:\Program Files\Microsoft Visual Studio 10.0\VC\lib\libcpmt.lib: Searching I:\boost-trunk\stage\lib\libboost_serialization-vc100-mt-s-1_47.lib: Searching C:\Program Files\Microsoft Visual Studio 10.0\VC\lib\LIBCMT.lib: Searching C:\Program Files\Microsoft Visual Studio 10.0\VC\lib\OLDNAMES.lib: Finished searching libraries nonfinite_num_facet_serialization.obj : error LNK2001: unresolved external symbol "public: __thiscall boost::archive::archive_exception::archive_exception( enum boost::archive::archive_exception::exception_code,char const *,char const *)" (??0archive_exception@archive@boost@@QAE@W4exception_code@012@PBD1@Z) J:\Cpp\MathToolkit\test\Math_test\Release\nonfinite_num_serialization.exe : fatal error LNK1120: 1 unresolved externals I have just rebuilt this library I:\boost-trunk\stage\lib\libboost_serialization-vc100-mt-s-1_47.lib. Library directory is I:\boost-trunk\stage\lib;$(LibraryPath) and appears to searching in the right lib file. Runtime library is /MT for release (I have also tried debug with similar results). The following includes are used in the demo program #include <boost/cstdint.hpp> #include <boost/serialization/nvp.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/codecvt_null.hpp> Is there anywhere I should have told serialization/archive not to use exceptions?

1 0

[chrono] Interoperability with ICL and common concepts
by Joachim Faulhaber 06 Apr '11

06 Apr '11

Hi Vicente and Boost Chronoists, thank you for implementing Boost.Chrono! It's a very fine piece of software :) Currently I'm checking out the usage of chrono types with icl::intervals and interval containers. Obviously, using intervals of chrono::time_points or chrono::durations can be an important use case. Also ICL already works well with other date and time data types from boost data_time, so chrono's interoperability should be at least as easy. A problem here is, that Icl, while working instantly with built in data types (e.g. int, short, double or even int*), for other numeric types (e.g. boost::rational) or types "based on integral types" (e.g. data_time::ptime) I needed to provide adapter code. I think it'd be ideal, if boost libraries interoperated with each other just out of the box, of course. To achive this, we have to find a common understanding of those concepts, that make a seamless interoperability work. I think, this is important work to be done, because it widens the view from one's own library perspective to a broader horizon of generic interplay. The problem: There is a minimal set of requirements that Icl expects for the domain types of intervals and interval containers (1) A zero element, more precisely an identity element w.r.t. the type's composition operation, which usually is +. An assumption that works well for all built in types and many STL-types is, that we get this element by the default constructor T(). (2) A strict weak ordering < (3) For all discrete types and for continuous numeric types: Operators ++, -- (Only pre-variants needed e.g. ++x) (3.1) For discrete types ++/-- increments/decrements by a *least step* (3.2) For continuous numeric types ++/-- increments/decrements by a *unit step*. Most of the functionality of Icl works if requirements (1) through (3) are met. In addition, there are some functions that require a distance type, but only for more specific types, namely for numeric types that use varying interpretations of the origin (zero), like epoch based date and time and pointer-addresses. BTW, do we already have a name for this type of concept? origin_based_equidistant_scalar origin_based_equidifferential_scalar because they are based to an arbitrary origin, but have comparable differences or distances. Or shorter equidistant_scalar equidifferential_scalar because if we emphasize, that by "comparable differences or distances", it is implied that the origin is choosable. May favorite is "equidistant_scalar". This concept reminds me of "Levels of measurement" http://en.wikipedia.org/wiki/Level_of_measurement (4) For such equidistant scalar types D the ICL assumes, that the type of the difference values of D is D::difference_type. To summarize, for a domain type Dom, Icl expects Dom(), <, ++, -- and if dom is a equidistant scalar type we expect an associated type Dom::difference_type to be defined. Now boost::chrono::duration (D1*) Has a default ctor that leaves the type undefined. (D2) Has <, Ok. (D3) Has ++, --, Ok. boost::chrono::time_point (T1) Has a default ctor that implements the semantics assumed by the ICL, Ok. (T2) Has <, Ok. (T3*) Does not have ++, --. (T4*) Does not have difference_type So I end up with 3 of my requirements not met (D1, T3, T4) D1: Default ctor for chrono::duration leaves objects undefined. I assume this is due to efficiency considerations, nevertheless unfavorable from the view point of my library. For all built in types and most of the STL there has been something like an intuitive maybe unconscious may be conscious agreement to assign the identity element w.r.t. the fundamental composing operation of the constructed object's type as the semantics of the default ctor. From an algebraic, generic and interoprability point of view (and IMHO) this is the best choice. This choice has not been taken for chrono::durations, which is a little inconsistent also, because interestingly for its chrono::time_point type the semantic is just the desired one. The possibility of default ctor customization is no remedy, because ICL should ideally be completely "chrono agnostic" and still interoperable. For the same reason duration::zero() is not an option. T3: chrono::time_point does not implement ++ and --. I assume this is because of the specific maths that is designed for chrono::time_points (P) and durations (D) where - : P x P -> D + : P x D -> P + : D x P -> P but + : P x P -> P //verboten But this should not be an argument against ++ and -- because the "least steppable unit" for integral rep types as well as the "unit" for floating point rep types, that is processed by ++ and -- is the same for time_points and durations. T4: Finally, difference_type as the associated type for time_point is not defined. IMO, it should be, because from a concept point of view, chrono::time_point falls in the same equidistant scalar concept that other types are in (e.g. T*, random_access_iterator<T>) and those associate a difference_type. These are the main problems of Icl/Chrono interoperability. There are a few minor ones as well. Let's discuss these first. I hope we can arrive at a solution, where Icl can be chrono agnostic and vica versa and still everything works well together. Based on that, we could fix similar issues for other libs like data_time. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

5 38

more details on the project idea Boost.Polygon edge, polyline and edge set concepts for GSOC 2011
by arunesh vikram 06 Apr '11

06 Apr '11

can i get more details on what topic you want me to emphasize on.... for this project like what should i know or requirements for this project. eagerly waiting for your reply...... Arunesh vikram

2 1

Re: [boost] Student introduction - GSOC
by George Lucian CORLACIU 06 Apr '11

06 Apr '11

> > Hello, > > I hope is not too late to make my introduction and to express my interest > in 2 of the proposed ideas. > > 1. SIMD library > > 2. ConcepTraits library > > Please tell me if I can still apply, and if I can what should I do to > demonstrate my capabilities in order to get one of your slots in GSOC. > > > Short description: > > *About me* > > Name: George Lucian CORLACIU > > University: Universidad Politécnica de Madrid, Madrid, Spain > > Master: European Master on Software Engineering (Erasmus Mundus Programme > on Software Engineering) – 1st year > > Bachelor: University of Sibiu “Lucian Blaga”; Faculty of Engineering > “Hermann Oberth”, Computer Science Department (thesis - Designing and > developing a hardware + software system for creating panoramic pictures - > Grade 9.86) > > *Work experience* > > I have over three years work experience, almost one year as a Software > Tester for an automotive company where I used C and more than two years as a > Software Developer in a company where I was developing a Laboratory > information management system (LIMS), a web application in Asp.NET Ajax + > C#. > > *Coding ++* > > My coding skills, ordered by proficiency are: C#, C++, C, Asp.NET, Java, > ASM etc. > > Tools proficiency: Visual Studio, Builder, Eclipse etc. > > Taking some of the courses in the bachelor degree and master improved my > skills a lot in domains like: computer vision, compression, image > processing/compression, cryptography etc. > > > Regards, > > George Lucian CORLACIU >

1 0

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

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

05 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 can boil the problem down to this test program: >> > >> > #include<boost/filesystem.hpp> >> > #define BOOST_FILESYSTEM_VERSION 3 >> > #define BOOST_FILESYSTEM_NO_DEPRECATED >> > >> > int main() >> > { >> > boost::filesystem::copy_file("a", "b"); >> > } >> > >> > compiling this with >> > >> > g++ test.cpp -lboost_system -lboost_filesystem >> > > It might be as simple as the order you link to the libraries. The boost > filesystem library depends on the boost system library, so you should > probably put "-lboost_system" after "-lboost_filesystem" on the command > line to link your program. That was my first thought, but the linking error does not come from boost_system, plus all of g++ test.cpp -lboost_filesystem -lboost_system g++ test.cpp -lboost_system -lboost_filesystem g++ test.cpp -lboost_filesystem give the same /tmp/cc9OO6P2.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 Regards Max -- Max Moorkamp IFM-GEOMAR Wischhofstr. 1-3 24148 Kiel Tel.: Germany - 431 - 600 2570 FAX.: Germany - 431 - 600 2915

1 0

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

05 Apr '11

Working with Boost Lexical Cast library found that some casts are working really slow. For example, cast from short to int is done via cast from short to char[], and cast from char[] to int. Cast from char* to string is done via string() constructor call and string`s append function call (instead of string constructor call with char array as a parameter). So I wrote patch to Boost Lexical Cast library, that returns Target directly constructed from Source in cases, when: 1) Source and Target are arithmetics (and not char or wchar_t), and all values of Source are in range of Target 2) Source and Target are both char or both wchar_t 3) Source is array of CharT and Target is std::basic_string<CharT, ...> 4) Source and Target are std::basic_string with same template parameters It gives performance boost more than 10 times in case 1) , about 7 times in case 2), and about 1.5 times in cases 3) and 4). Existing tests for Boost Lexical Cast library cover considered cases. Patch was successfully tested on Intel 11.1.072, g++-4.4.5, VC++9 compilers. P.S.: I`m a newbie here, so where shall I send this patch? Shall I test it on other compilers?

5 5

[Filesystem] Linking problem with 1_46_1
by Max Moorkamp 05 Apr '11

05 Apr '11

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 can boil the problem down to this test program: #include <boost/filesystem.hpp> #define BOOST_FILESYSTEM_VERSION 3 #define BOOST_FILESYSTEM_NO_DEPRECATED int main() { boost::filesystem::copy_file("a", "b"); } compiling this with g++ test.cpp -lboost_system -lboost_filesystem results in this error message /tmp/ccBuSw7s.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 I had a look at this thread http://boost.2283326.n4.nabble.com/Filesystem-problems-with-g-std-c-0x-td26… but adding or removing -std=c++0x does not change anything. I also tried to see whether any special compiler options were used during the build of boost, so here is the line for operations.hpp "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/filesystem/build/gcc-4.4.3/release/link-static/threading-multi/v3/src/operations.o" "libs/filesystem/v3/src/operations.cpp" There is nothing there that strikes me as special, any ideas anyone. Regards Max -- Max Moorkamp IFM-GEOMAR Wischhofstr. 1-3 24148 Kiel Tel.: Germany - 431 - 600 2570 FAX.: Germany - 431 - 600 2915

3 2