- Boost - lists.boost.org

[mirror] a question
by Matus Chochlik 26 Apr '08

26 Apr '08

Hi, I would also like to hear your opinions on one thing, concerning the implementation of mirror. Mirror currently uses several typedefined types like bchar (char/wchar_t) bstring (string/wstring) and global variables like bcin (cin/wcin), bcout (cout/wcout), etc. Which form is used, depends on the definition of the PP symbol BOOST_USE_WIDE_CHARS. If this symbol is defined then wchar_t/wstring/wcout/... are used otherwise char/string/cout/.. are used. I use this approach because I know from my experience that it can save a great deal of trouble when switching from chars to wchars and vice versa, mainly on Windows where a similar approach is used by the WinAPI. Since bchar is always the same type as the TCHAR type defined by WinAPI, you can use the 'recomended versions' of the winapi functions, like LoadLibrary with bchar vs. the char-type-specific versions like LoadLibraryA with ascii chars and LoadLibraryW with wchars. When testing the library and the examples I always compile them with both chars and wchar_ts to check whether everthing works as expected. BUT, currently all the types and global variables like bchar, bstring, bcout, bcin, etc. are defined in the scope of the boost namespace and all the preprocessor symbols have only the BOOST_ prefix. The sources related to this char type switching are placed in a separate directory called [boost/]char_type_switch/ . I am aware that boost library authors, maintainers and users could object against this. So I would like to ask: Does this approach sound reasonable to You and is it Ok for You that the symbols are defined in the boost namespace and the files placed in a separate folder ? Would You even like to use this or similar approach in Your library ? Or, is it NOT OK and do You want me to place them into the mirror namespace and prefix all the preprocessor symbols with BOOST_MIRROR_ ? I would like to have this issue resolved ASAP in order to avoid to have rewrite everything in case this library is officialy proposed in the (distant) future and there are objections against this. Thanks in advance for your opinions. -- matus

1 0

[mirror] new version
by Matus Chochlik 26 Apr '08

26 Apr '08

Hello, I would like to announce that a new version of 'mirror' library is available in the sandbox, at http://svn.boost.org/svn/boost/sandbox/mirror/ with several new features, including: - full_name() getter (returns the type or namespace name with nested name specifier), which works even for types like pointers etc. - meta-type for std::pair<> (a meta-class allowing to inspect the attributes will be comming soon) // this means that you can now define a type T like this: using namespace ::std; using namespace ::boost; using namespace ::boost::mirror; // typedef pair<const int*, double [321]> T1; typedef pair<float, const long&> T2; typedef pair<T1 const volatile, T2 volatile const> T3; typedef pair<T2, T1 volatile> T4; typedef pair<T3 const * volatile, const T4&> T; // get the meta data typedef BOOST_MIRROR_REFLECT_TYPE(T) meta_T; // and query the base name (without nested type specifiers) cout << meta_T::base_name(); /** printing out (newlines added): * pair< pair< pair< int const *, double [321] > const volatile, pair< float, long const & > const volatile > const * volatile, pair< pair< float, long const & >, pair< int const *, double [321] > volatile > const & > */ // or the full name cout << meta_T::full_name(); /** printing out (newlines added): * ::std::pair< ::std::pair< ::std::pair< int const *, double [321] > const volatile, ::std::pair< float, long const & > const volatile > const * volatile, ::std::pair< ::std::pair< float, long const & >, ::std::pair < int const *, double [321] > volatile > const & > */ Please see http://svn.boost.org/svn/boost/sandbox/mirror/libs/examples/special/std_pai… for a complete example. Since it has been tested only with MSVC++ 2008 there may be some problems compiling the samples with other compilers (mainly missing typename keywords here and there). Next week I'm going to fix this. There are still no jamfiles nor makefiles so you'll have to write some yourselves if you want to try the examples. Sorry, I hope this'll be fixed soon, too. Some of the other examples have been updated to show the using of the full_name() function. See http://svn.boost.org/svn/boost/sandbox/mirror/libs/examples/registering/ For those interested, there is also an example, showing how to use mirror with Boost.Serialization at: http://svn.boost.org/svn/boost/sandbox/mirror/libs/examples/serialization/c… It is rather clumsy and currently it can't be compiled with gcc (I couldn't find the reason why yet). Note that it's just a first shot and most of the code ensuring the cooperation with Boost.Serialization will be rewritten and hidden in a header file in the future. Best, -- matus

1 0

What plans to handle _SCEURE_SCL in the boost build system?
by James Talbut 25 Apr '08

25 Apr '08

Hi, There have been various discussions on here about the problems caused by _SECURE_SCL, but I haven't seen any concrete plans for changes to boost build to handle it. At a minimum the build system should be changed to enable those users wanting _SECURE_SCL=0 to do so easily - ideally by providing an argument to bjam. Is someone working on this? Thanks. Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________

5 6

[gil] [announcement] New IO lib
by Christian Henning 25 Apr '08

25 Apr '08

John, > > I really think that all of the other formats are important. Hopefully > Lubomir does make them an official part of gil, or an official extension > that can be part of the boost svn. I'll discuss it with Lubomir. I rather believe that we should divide gil into seperate modules. One for the core part, meaning the infrastructure code without specific code for color spaces, etc. And then, there should be extensions for all the color spaces, io, image variants, algorithms, etc. Also, gil might consider having it's own review procedure. This might fasten up inclusion of new extensions and also takes burden away from boost. After all the extensions are gil-specific and don't impact boost very much. What do you think? > > > > Can you try to compile again? > > I fixed some parts, but it still fails. > > g++ is really picky about dependant names. When a base class is > dependant on a template parameter, I think you need to use 'this->' in > order to let the compiler know that the symbol comes from a base class > instead of the global scope. I attached a patch, which was created > inside the io_new folder. I'll change the code, asap. > > Also, there are references to deail::read_and_no_convert used in > read_image.hpp. I can not find a declaration for read_and_no_convert, > did you forget to add a file to svn? read_and _no_convert is defined in conversion_policies.hpp. > > > > Are you planning on using the lib? > > I will probably use the library, but I am not ready to switch yet > (timing issues). > Is it possible to have read_image deduce the file format from the file / > filename itself? That feature would make a gil io lib. perfect for me. I was thinking of adding that, as well. But it would introduce the dependency to boost::filesystem. Not sure if that's advisable since the io lib wouldn't be header only anymore. Thanks for your effort, Christian

2 1

Boost.Thread [1.35.0] building problems.
by Andreas Haberstroh 25 Apr '08

25 Apr '08

Hey folks, I know there is an ongoing thread about build failure with Windows XP and cygwin, but I believe the problem goes beyond that platform. I'm building on several different platforms and have run into a similar problem with the <threadapi> parameter. I build on FreeBSD 6.2, Ubuntu 7 (Intel), Ubuntu 6 (PPC) and lastly, Win32. I have NOT tested this out on a win32 platform yet. Using FreeBSD with gcc 3.4.2 and Linux with gcc 4.2 you can reproduce the problem very quickly from the current trunk. In your boost directory, simply enter the following: *bjam --with-wave*. You'll have something like the following: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: No best alternative for libs/thread/build/thread_sources next alternative: required properties: <threadapi>win32 <threading>multi not matched next alternative: required properties: <threadapi>pthread <threading>multi not matched /root/boost/tools/build/v2/build/generators.jam:859: in try-one-generator-really *** argument error * rule object(gcc-linking-generator)(a)33.run ( project name ? : property-set : sources + ) * called with: ( object(project-target)@388 boost_thread : object(property-set)@411 : ) * missing argument sources /root/boost/tools/build/v2/tools/gcc.jam:405:see definition of rule 'run' being called /root/boost/tools/build/v2/build/generators.jam:920: in try-one-generator /root/boost/tools/build/v2/build/generators.jam:1131: in construct-really /root/boost/tools/build/v2/build/generators.jam:1204: in generators.construct /root/boost/tools/build/v2/tools/builtin.jam:502: in object(lib-generator)(a)5.run /root/boost/tools/build/v2/build/generators.jam:859: in try-one-generator-really /root/boost/tools/build/v2/build/generators.jam:920: in try-one-generator /root/boost/tools/build/v2/build/generators.jam:1131: in construct-really /root/boost/tools/build/v2/build/generators.jam:1204: in generators.construct /root/boost/tools/build/v2/build/targets.jam:1368: in construct /root/boost/tools/build/v2/build/targets.jam:1206: in object(typed-target)(a)404.generate /root/boost/tools/build/v2/build/targets.jam:742: in generate-really /root/boost/tools/build/v2/build/targets.jam:715: in object(main-target)(a)406.generate /root/boost/tools/build/v2/build/targets.jam:858: in targets.generate-from-reference /root/boost/tools/build/v2/build/targets.jam:1129: in generate-dependencies /root/boost/tools/build/v2/build/targets.jam:1179: in object(typed-target)(a)134.generate /root/boost/tools/build/v2/build/targets.jam:742: in generate-really /root/boost/tools/build/v2/build/targets.jam:715: in object(main-target)(a)206.generate /root/boost/tools/build/v2/build/targets.jam:254: in object(project-target)(a)130.generate /root/boost/tools/build/v2/build/targets.jam:858: in targets.generate-from-reference /root/boost/tools/build/v2/build/targets.jam:1129: in generate-dependencies /root/boost/tools/build/v2/build/targets.jam:1179: in object(alias-target-class)(a)128.generate /root/boost/tools/build/v2/build/targets.jam:742: in generate-really /root/boost/tools/build/v2/build/targets.jam:715: in object(main-target)(a)196.generate /root/boost/tools/build/v2/build/targets.jam:254: in object(project-target)(a)84.generate /root/boost/tools/build/v2/build-system.jam:663: in load /root/boost/tools/build/v2/kernel/modules.jam:267: in import /root/boost/tools/build/v2/kernel/bootstrap.jam:134: in boost-build /root/boost/boost-build.jam:11: in module scope ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Using the suggestions from the mail list thread titled: /[boost] [1.35.0] Threads - build failure using gcc on Win XP,/ I tried the following: *bjam --with-wave threadapi=pthread * You will then have something as follows: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/boost/tools/build/v2/build/property.jam:285: in validate1 from module property error: Invalid property '<threadapi>pthread': unknown feature 'threadapi'. /root/boost/tools/build/v2/build/property.jam:294: in property.validate from module property /root/boost/tools/build/v2/build/build-request.jam:193: in convert-command-line-element from module build-request /root/boost/tools/build/v2/build/build-request.jam:148: in build-request.from-command-line from module build-request /root/boost/tools/build/v2/build-system.jam:559: in load from module build-system /root/boost/tools/build/v2/kernel/modules.jam:267: in import from module modules /root/boost/tools/build/v2/kernel/bootstrap.jam:134: in boost-build from module /root/boost/boost-build.jam:11: in module scope from module ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Most of my projects are multi-threaded in nature, and thus can not use the Boost 1.35.0 release since this problem doesn't allow me to build. Interesting enough, the Boost.Thread examples do build without a problem. I'm not a bjam Jamfile expert, so I don't even know where to begin trying to fix the Boost.Thread Jamfile.

3 6

Trac open bugs - by assignee
by Marshall Clow 25 Apr '08

25 Apr '08

[ 295 open bugs today, 289 yesterday ] If you are maintaining a library, and have not logged into the trac system at <http://svn.boost.org/trac/boost/>, please do so ASAP. Until you do that, no tickets can be assigned to you, and will remain under "None". Instructions on working with tickets can be found at: <http://svn.boost.org/trac/boost/wiki/TicketWorkflow> and a mapping of user names to "real names" can be found at: <http://svn.boost.org/trac/boost/report/16> Bug summary 28 djowel 24 az_sw_dude 22 grafik 16 vladimir_prus 16 dave 15 bemandawes 13 dgregor 13 anthonyw 12 no-maintainer 12 doug_gregor 11 ramey 11 agurtovoy 9 jsiek 8 turkanis 8 nesotto 7 rogeeff 6 igaztanaga 6 danieljames 4 witt 4 pavol_droba 4 nasonov 4 matias 4 johnmaddock 4 ebf 4 danielw 3 samuel_krempp 3 kaalus 2 troyer 2 shammah 2 marshall 2 jmaurer 2 hkaiser 2 garcia 1 urzuga 1 t_schwinger 1 speedsnail 1 pdimov 1 jano_gaspar 1 guwi17 1 fcacciola 1 eric_niebler 1 dlwalker 1 aaron_windsor 1 None 1 <Blank> <Blank> 1750 Autolink library name not in sync with actually build lib None 1736 Headers containing non ASCII characters cause MS VC to issue warning 4819 in some locales aaron_windsor 1622 Adjacency list needs to handle self-edges correctly agurtovoy 1001 gcc 4.1.2 segfaults on mpl/test/apply.cpp agurtovoy 1051 MPL header ordering triggers bug agurtovoy 1099 unable to iterate through a "non-explicitly-declared" mpl::set agurtovoy 1215 Boost 1.34.1_ mpl: Wrong workaround detection using MinGW32 (or.hpp_ line #33) agurtovoy 1317 has_xxx randomly broken in msvc agurtovoy 1469 [mpl] nested typedef of set has two different meanings agurtovoy 1476 always<> is not nullary. agurtovoy 1528 g++ 4.3.0 reports error because of redeclaration of next agurtovoy 1549 Boost.MPL: 'index_of' algorithm is not documented agurtovoy 1568 duplicate include guards agurtovoy 588 mpl::remove compile error with gcc 4.1.0 anthonyw 1154 tss destruction segfaults in conjunction with dlopen/dlclose anthonyw 1168 [thread] tss crashes randomly anthonyw 1268 xtime_cmp changes to deal with overflow were reverted anthonyw 1470 Boost.Thread: Compilation errors with non-__cdecl calling convention anthonyw 1805 thread creation crashes with /Zp1 switch in VS2005 compiler anthonyw 1813 Signed/Unsigned warning in win32/condition_variable anthonyw 1825 thread.hpp injects windows.h and breaks user application. anthonyw 1826 Auto detection of threadapi and target-os broken under cygwin gcc anthonyw 1834 boost::condition drops signals with notify_one() anthonyw 1835 boost::thread equality operator bogus in 1.35 ? anthonyw 1848 Boost.Thread is incompatible with UPX anthonyw 876 xtime documentation incomplete anthonyw 881 errors when build with Apache stdcxx az_sw_dude 1028 typo in boost header: date_time/time_defs.hpp az_sw_dude 1078 from_iso_string cannot read the output from to_iso_string az_sw_dude 1098 Urgent libboost-date-time1.33.1 : bugs on ia64 ? az_sw_dude 1147 date_time library contains global #define ERROR az_sw_dude 1160 warning: month_format shadows a member of this az_sw_dude 1162 warning: ticks shadows a member of this az_sw_dude 1289 posix_time::time_facet forgets to pass a_ref argument to base class az_sw_dude 1299 change in typedef stringstream_type in format_date_parser.hpp causing compilation error az_sw_dude 1306 invalid docbook in date_period.xml az_sw_dude 1384 Linking problem with date_time library on Visual C++ 2008 Express az_sw_dude 1524 format_date_parser.hpp(221) : cannot convert parameter 1 az_sw_dude 1574 operator<< for boost::posix_time::ptime ignores ostream flags az_sw_dude 1674 date_time::date_formatting.hpp: incorrectly formats year using global locale az_sw_dude 1695 add correct namespace to class to fix compilation bug az_sw_dude 1726 boost/date_time/posix_time/time_formatters.hpp incorrectly formats fractional seconds using global locale az_sw_dude 1740 date_time includes <windows.h> az_sw_dude 1788 local_time::local_time_period streaming operators not implemented az_sw_dude 1859 boost::gregorian::to_tm() doesn't fill in tm_zone on Mac OS X az_sw_dude 287 wrong usage of ios_base::narrow az_sw_dude 316 date_time type conversion warning az_sw_dude 604 from_ftime incorrectly processes FILETIME filled with zeros az_sw_dude 642 operator<< for gregorian::date_duration not found az_sw_dude 889 Insane Dependencies az_sw_dude 890 date_time library supports only the current dst rule bemandawes 1378 filesystem path invalid name for hidden files (LINUX) bemandawes 1389 filesystem::ostream << boost::format generates operator ambigious error (in MSVC++) bemandawes 1458 Darwin Tiger throws std::runtime_error: locale::facet::_S_create_c_locale name not valid bemandawes 1578 bug in readdir_r_simulator() in a multi-threaded environment bemandawes 1583 Serious flaw in boost::filesystem filename handling (opensuse) bemandawes 1589 [filesystem] 'mbstate_t' : is not a member of 'std' bemandawes 1606 filesystem/src/exception.cpp doesn't build with gcc bemandawes 1613 Link Errors against file_system on OS X with Intel Version 10.1 C++ compilers bemandawes 1682 path_traits needs imbue() bemandawes 1701 boost::filesystem::remove_all - segmentation fault with wpath on Linux bemandawes 1711 Boost Serialization export facility broken on gcc 4.1_ 4.2 bemandawes 1767 missing file: boost/filesystem/cerrno.hpp bemandawes 1768 system: error_code.cpp #defines macros without checking whether already defined bemandawes 1840 name check functions have different behavior wrt empty string bemandawes 752 directory_iterator doesn't work with catch danieljames 1554 When BOOST_HASH_NO_EXTENSIONS is defined hash doesn't support new string types. danieljames 1555 When BOOST_HASH_NO_EXTENSIONS is defined hash doesn't support boost::system::error_code danieljames 1705 [boostbook] Spaces in reference file names for types like 'long long' danieljames 1742 Some bugs in http://www.boost.org/doc/libs/1_35_0 danieljames 1743 Documentation has incorrect Build & Link settings for some libraries danieljames 1818 The tables in status reports jump all over the place. danielw 1044 Argument pack inaccessable in a functions return type danielw 1054 Parameter takes an "infinite" amount of time to compile with the Intel compiler. danielw 1097 keyword.hpp generates many warnings C4180: qualifier applied to function type has no meaning; ignored danielw 1784 [parameter] missing include dave 1010 linking boost.python on freebsd dave 1019 iterator_facade::pointer should be the return type of operator-> (DR 445) dave 1085 Python rules for compiling in Mac OS X dave 1179 [boost.python] can not export a union in VC2005sp1 dave 1181 [boost.python] can modify enum value dave 1387 Review / update docs to reflect changes dave 1460 Python classes with multiple bases are convertible only to the first class in the lists dave 1482 boost::python::throw_error_already_set should be marked noreturn dave 1516 [python] Failing VC9 regression tests dave 1599 [python] '_set_se_translator': identifier not found dave 1697 [utility][noncopyable] ADL barrier broken by msvc-9.0 dave 1730 No debug libs on Windows by default dave 1851 Issue with proxies and rvalues dave 1860 zip_iterator::value_type should not be reference dave 865 Use of C++0x keyword as identifier dave 910 gcc strict-aliasing problems with python dgregor 1009 Improper overflow handling in shortest paths algorithms dgregor 1164 Floyd Warshall broken with unsigned edge weights dgregor 1192 [boostbook] problem when two files have the same name dgregor 1199 configure doesn't work with path containing whitespaces (MacOS X) dgregor 1310 [result_of] const-qualified function pointer doesn't work dgregor 1326 Unable to check graph isomorphism using LEDA adapter dgregor 1391 dominator_tree_test on Borland/CodeGear outputs overly long line dgregor 1395 Write Tests for Python Bindings dgregor 1630 gcc-4.3: adjacency_list.hpp includes deprecated header dgregor 1832 unused parameter warning in dijkstra_shortest_paths.hpp dgregor 556 Bundled graph properties dgregor 732 Johnson All-Pairs needs better "no path" information dgregor 736 Const correctness violation djowel 1170 Emit Warnings instead of # symbols in the syntax highlighter djowel 1171 Quickbook title output djowel 1172 non-utf djowel 1176 Space after inline code djowel 1206 Escaping from within code? djowel 1273 CR+LF newlines in position_iterator djowel 1276 spirit problem with _GLIBCXX_DEBUG djowel 1277 Closing section like [pre with } causes Quickbok to crash djowel 1280 sections in imported source files get put inside <para> elements in docbook output djowel 1281 Quickbook produces invalid BoostBook/DocBook XML djowel 1324 tuple should have a swap() that operates element-by-element djowel 1396 wrong result_of invocation around transform_view djowel 1436 [quickbook] inline code inside headings djowel 1484 Quickbook produces illegal docbook for some docinfo fields. djowel 1500 [Spirit/Phoenix] C4512 Compiler warnings from VC8 djowel 1570 Some boost headers aren't ready for gcc 4.3 djowel 1600 duplicate include guard djowel 1601 distane of boost::tuple djowel 1607 Tuple Library Documentation Changes djowel 1610 [MSVC/STLport] [tree/common.hpp] Standard library requirements violation(incomplete type as vector parameter) djowel 1614 vector workaround needed for MSVC9 djowel 1617 spirit gcc-4.3 fix djowel 1619 [Fusion] C4512 warnings from VC9 (Visual Studio 2008) djowel 1651 incorrect typedefs in examples djowel 1763 wrong AST when parser_tag==0 djowel 1764 wrong AST when parser_tag==0 djowel 1844 Quickbook matches forward slashes (for italics) with slashes in links djowel 1864 [Documentation]There is no documentation for repetivive_view dlwalker 613 boost/crc.hpp uses non-standard conforming syntax doug_gregor 1021 [Graph][reverse_graph] Problem using reverse_graph adapter with an adapted user defined graph doug_gregor 1076 compile error: disconnecting struct with operator()() doesn't work in VS2005 SP1 doug_gregor 375 LEDA graph adaptors do not handle hidden nodes properly doug_gregor 402 random_vertex/random_edge are unnecessarily inefficient doug_gregor 403 Document copy_component doug_gregor 447 reverse_graph and constness of property maps doug_gregor 708 Dijkstra no_init version should not require VertexListGraph doug_gregor 733 Numbered headers don't work with "preferred" syntax doug_gregor 735 Fruchterman-Reingold grid performance can be improved doug_gregor 738 Memory leaks with signal::connect? doug_gregor 829 Implicit graph not implement doug_gregor 852 Problem with Boost and GCC 4.1 ebf 1507 [variant] C4512 warnings from VC8.0 ebf 1548 [variant][docs]typo: formal arg_ operand_ should be v in times_two arglist ebf 1654 recursive variants do not handle nested variants correctly. ebf 993 Variant should use least common multiple of alignments_ rather than maximum eric_niebler 1796 compile error when SDL_syswm.h (from sdl library) is included before foreach.hpp fcacciola 1666 Visualizer for boost::optional garcia 1581 Boost.MultiArray: Resizing bug if the index is not 0-based garcia 1741 Review schedule out of date grafik 1041 Cygwin requires PATH setting. grafik 1322 trac rejects patch attachment as spam grafik 1406 Understanding the Tables outdated grafik 1417 Regresson tests hang in Darwin (Tiger) grafik 1430 Regression fails under Cygwin grafik 1433 Trac's spam detection rejects too many valid messages grafik 1512 Broken link to vacpp in bjam docs. grafik 1513 Broken link to bcpp in bjam docs. grafik 1576 cannot read non-ASCII output messages grafik 1577 Some commands don't work because hStdInput == 0 grafik 1663 build.bat cannot set/reset ERRORLEVEL grafik 1733 Website layout overlays on IE7 grafik 1735 [website] Wrong HTML on main documentation page. grafik 1738 Boost Jam details and download link grafik 1739 Search box and Google link grafik 1753 Python docs: bad link to the Jamroot grafik 1771 Statechart TOC mangled. grafik 1775 website bugs for 1.35.0 docs grafik 1776 Documentation page renders incorrectly in Safari 3.1 on OS X grafik 616 Boost Jam_ and non english directorys grafik 959 linking fails when Boost is compiled with STLport 5.1.* on Linux (names mismatch) grafik 986 Problem building Python modules on boost 1.34.0 guwi17 1829 norm_2 may return QNAN if BOOST_UBLAS_SCALED_NORM is defined hkaiser 1079 boost-1.34.0 fails to compile. concept checks not satisfied. hkaiser 1670 wave almost unusably slow on real-world input igaztanaga 1080 boost::interprocess win32 global file mapping issue igaztanaga 1210 interprocess::barrier hangs during second use under linux (boost 1.33.1) igaztanaga 1390 Interpocess: managed shared memory failing completely under OS X igaztanaga 1634 boost::interprocess::vector cannot contain volatile int igaztanaga 1635 Incomplete include guard in boost/intrusive igaztanaga 1862 file_lock.hpp will not compile - at least under MSVC8 jano_gaspar 1852 copy constructor does not copy capacity jmaurer 351 Diff in state of mersenne_twister gen between GCC3.41 & CW9 jmaurer 599 uniform_01 copies engine instead of using a reference johnmaddock 1081 Empty string rejected as perl-style regex johnmaddock 1446 POSIX API doesn't use C locale johnmaddock 1451 error: use of C99 long long integer constant johnmaddock 1863 Boost.Regex unstable with Borland Turbo C++ 2006 jsiek 1531 segfault in dynamic_bitset::reference assign operator jsiek 1540 Poisson distribution very slow for large mean (and may also overflow). jsiek 1755 Boost.tokenizer is broken for wide characters - patch attached jsiek 1798 met an error using boost::tokenizer in multi-times in vs2005_ unicode jsiek 575 Calling subgraph::global_to_local on a root graph jsiek 636 strange compiling problem for transitive_closure jsiek 815 remove_edge core dumps on self-circle jsiek 875 No iterator based constructor for adjacency_matrix jsiek 900 graphml reader namespace handling is broken kaalus 1184 property_tree assignment (operator) bug kaalus 1604 property_tree xml parser doesn't compile with gcc kaalus 1678 Boost.property_tree::read_xml does not parse UNICODE file with BOMs marshall 1252 [pool] severe overhead with unaligned sizes. marshall 1854 Interval is not available as a component in the SVN system matias 1744 No information on building static libraries with bjam under Windows matias 1822 header dependency in boost/serialization/map.hpp matias 1853 Typo in interval documentation matias 1855 Typo in lambda documentation (online) nasonov 1220 lexical_cast requires RTTI nasonov 1704 [any] 4512 warning from VC8/9 on warning level 4 nasonov 1847 Can't compile without <locale> header_ boost::lexical_cast problem nasonov 754 boost::any - typeid comparison across shared boundaries nesotto 1629 range/iterator_range.hpp bug nesotto 1675 [range] VC8 - compiler warnings when including range/array headers nesotto 1694 NDEBUG vs. BOOST_ASSERT in iterator_range.hpp nesotto 1748 [ptr_container] compiler warnings from VC9 nesotto 1754 Illegal HTML in range docs. nesotto 1785 assign::list_of works poorly with class constructors nesotto 1795 [ptr_container] minor documentation typo nesotto 1842 boost::sub_rage::front error no-maintainer 1068 Mersenne twister disables streaming for Visual C++ no-maintainer 1222 lambda::ret<T> should declare result_type. no-maintainer 1270 uniform_smallint doesn't compile with lagged_fibonacci random number generators no-maintainer 1515 [lambda] C4512 warnings from VC8.0 no-maintainer 1544 uniform_01 w/ref template param causes ref to ref error no-maintainer 1546 Method boost::random::uniform_int::operator()(engine_ value) is missing no-maintainer 1572 [lambda] smart pointer const-ness affects its contents no-maintainer 1632 Default Interval rounding policies incomplete no-maintainer 1691 [Random] Brokem MSVC workaround no-maintainer 1856 minstd_rand returning different values in 1.35.0 than in 1.34.1 no-maintainer 781 Lambda: (_1 + "y")(string("x")) Doesn't Compile no-maintainer 819 uniform_int<> with type's maximum availaible range error pavol_droba 1152 rle_example fails pavol_droba 1385 begin must be boost-qualified pavol_droba 1761 StringAlgo: Error in an example pavol_droba 1827 String algorithm composite header doesn't include join pdimov 1106 shared_ptr<T> should not convert to shared_ptr<U> when T* doesn't convert to U* ramey 1708 Can't serialize class with private destructor ramey 1734 BOOST_STATIC_WARNING can't be passed a dependent expression ramey 1747 [serialization] unreferenced formal parameter warnings from VC9 ramey 1807 boost::archive::xml_archive_exception does not store error code and reports wrong message text ramey 1812 Boost.Serialization fails to build on Cygwin ramey 1823 Archive concept: Incomplete description? ramey 1824 serialization keeps using wchar_t if BOOST_NO_STD_WSTRING is set ramey 1836 bug in serializing wide character strings ramey 1837 Base class missed in binary_wiarchive ramey 1849 Deserialization of std::string overwrites non-copied contents. ramey 1857 IA64_ GCC 4.3_ redefinition of 'struct boost::serialization::implementation_level<std::vector<long int_ std::allocator<long int> > >' rogeeff 1383 signal.h features not found on Mac OS rogeeff 1542 [test] compiler errors when building with stdcxx library rogeeff 1644 Boost.Test missing documentation file BOOST_CHECK_CLOSE_FRACTION.html rogeeff 1676 Dead links on Boost.Test example documentation. rogeeff 1723 No subprocess can be started in init_unit_test_suite rogeeff 1746 Online documentation for 1.35.0 is out of date for current lib version rogeeff 1839 Test fails if child process exits with non-zero code samuel_krempp 1699 Compile warning about initialization order. samuel_krempp 1801 Typo in documentation. samuel_krempp 859 boost::format ignores a user defined locale shammah 290 perfomance: memory cleanup for pool takes too long shammah 386 boost::pool_allocator breaks with vector of vectors speedsnail 1138 Problems with TSS and static thread library t_schwinger 1653 wave executable erroneously required for build of function_types lib troyer 1774 serialization: file written with 1.34.1 can't be read in with 1.35 troyer 1778 Possible regression in 1.35 serialization of 2D arrays turkanis 1523 [iostreams] VC8/VC9 compiler warnings turkanis 1545 [boost/rational.hpp] 'noskipws' is not a member of 'std' turkanis 1579 gzip compressor should model DualUseFilter turkanis 1580 Add static assert to prohibit instantiating a chain with mode dual_use turkanis 1649 Fix definition of JavaScript menu to avoid long chains of functions turkanis 1656 Consider implementing flush() for symmetric filters turkanis 1671 type mismatch of buffer size parameter causes overload resolution to fail turkanis 1727 Sample code in documentation does not compile_ has namespace errors. urzuga 574 [boost::lambda] Compile error with libstdc++ debug mode vladimir_prus 1132 program_options documentation error. vladimir_prus 1165 more quoting problems vladimir_prus 1274 Useless error message vladimir_prus 1527 [program_options] Second (and subsequent) lines in tabbed text not aligned correctly vladimir_prus 1530 Program options documentation - Overview - Syntactic Information example typo vladimir_prus 1537 no value given in 'mysql_password =' vladimir_prus 1584 cryptic bbv2 error building quickbook vladimir_prus 1587 [program_options] crashes if value part missing in external configuration file vladimir_prus 1588 [program_options] crashes if value part missing in external configuration file vladimir_prus 1645 Invalid unicode support for default_value vladimir_prus 1679 added 4-way universal binary support from mac osx (ppc_ ppc64_ i386_ x86_64) vladimir_prus 1809 Allow empty values in conf file vladimir_prus 1816 --build-type=complete broken in current svn vladimir_prus 469 multitoken broken vladimir_prus 689 [program_options] Endless loop with long default arguments vladimir_prus 850 program_options strips off escaped quotes in some situations witt 583 Fixes for build on IBM pSeries for AIX and Linux witt 834 Homepage regression links witt 957 The "Getting Started" page does not mention the stdlib option witt 973 zip_iterator has value_type == reference -- -- Marshall Marshall Clow Qualcomm, Inc. <mailto:mclow@qualcomm.com> The famous British scientist, Lord Kelvin, said: "When you measure what you are speaking about and express it in numbers, you know something about it, but when you cannot (or do not) measure it, when you cannot (or do not) express it in numbers, then your knowledge is of a meagre and unsatisfactory kind."

1 0

ABI and API compatibility
by Vladimir Prus 25 Apr '08

25 Apr '08

Right now, Boost provides not guarantees whatsoever about API and ABI compatibility between any two versions. This might be OK for major releases, but the question is if we really want 1.35.1 to be incompatible to 1.35.0 in any way? If 1.35.1 is a bugfix release, then I would hope that: 1. Applications using 1.35.0 need not be changed at all. 2. If application link to 1.35.0 as dynamic library, then switching them to use 1.35.1 should not break anything. Does this make sense, and if so, can we officially document such a policy? - Volodya

10 16

[Boost-config] Intel on MacOS (add no two phase name lookup macro)
by K. Noel Belcourt 25 Apr '08

25 Apr '08

Hi John, It seems that I need to add this patch to intel.hpp to get the intel- darwin config tests to pass. I've also attached the user.hpp generated when I ran the configure script. Does this patch look reasonable and do you see any other changes that need to be made based on the output in user.hpp? Thanks. -- Noel

2 3

quick GTL exmaple code
by Simonson, Lucanus J 24 Apr '08

24 Apr '08

My submission to the vault included the library itself, but no example code or applications that illustrate how to use it. The following code snippet compiles warning and error free (in linux gcc 3.4.2). You should have good luck with more recent versions of gcc, icc and VC as well since we build against those regularly. #include "gtl.h" int main(int argc, char **argv) { { using namespace gtl; PolygonSet ps; ps.insert(Rectangle(0, 0, 10, 10)); //rectangle with lower left corner 0,0 and upper right corner 10,10 ps.insert(Rectangle(5, 5, 15, 15)); std::vector<Polygon> result; ps.getPolygons(result); if(result.size() != 1) return 1; std::cout << result[0] << std::endl; } return 0; } Output: Polygon 5 10 0 0 10 5 15 15 The format of the output polygon is what I call the "compact" representation of a manhattan polygon. In this case the polygon returned has the following vertices: 5,10 0,10 0,0 10,0 10,5 15,5 15,15 5,15 and is the OR of the two input rectangles (note CC winding convention.) There are API on the Polygon to get an iterator over vertices as Point objects, of course, but the << >> operators are used to serialize its compact representation. There are also quite a few alternatives for constructing rectangles and adding geometry data to a PolygonSet. PolygonSet.h is a good place to start looking at the gtl source code. Luke

1 0

Re: [boost] [Boost-build] [1.35.0] Threads - build failure using gcc on Win XP
by Mat Marcus 24 Apr '08

24 Apr '08

On Tue, Apr 22, 2008 at 3:27 PM, Roland Schwarz <roland.schwarz(a)chello.at> wrote: > > > Vladimir Prus wrote: > > You can use cygwin gcc in both cygwin mode and -mno-cygwin mode. What > > default threading api do you expect for the latter case, and can it be > > inferred in any way from output of -dumpmachine? > > The default api possibly should be win32 in the latter case. In > principle it could be infered from -dumpmachine by evaluating > the flavor which would be in that case: > i686_pc_mingw32 When building gcc from sources under cygwin, one begins with a call to configure. I recently used the following invocation: configure --enable-threads=posix --disable-bootstrap --prefix=/opt/gcc-4.3.0 --enable-languages=c++ Actually, at first I mistakenly forgot to pass an --enable-threads parameter. I was made aware of this when I tried to build boost and found that the BOOST_DISABLE_THREADS was being #defined (good auto-detection work by the boost/config machinery I presume). After starting over by configuring gcc with --enable-threads=posix before building it all was well. Now I haven't tried this, but preliminary googling tells me that it is also possible to configure gcc with --enable-threads=win32. My first questions are: 1) Does setting --enable-threads=win32 affect the eventual output of -dumpmachine? 2) If not, how could such a gcc fit into the flavor scheme? You may tell me that --enable-threads=win32 cannot be made to work without also setting other flags until one ends up with what is essentially a mingw compiler, but I haven't studied things carefully enough yet to see whether this is true. Stepping back a little, a more fundamental question occurs to me: 3) Why does the thread Jamfile.v2 need to know the default threading model? Here's why I ask: (What follows may be wrong, since I don't know all the corners of the build system.) Today, for example, if I compile on a powerpc mac without specifically selecting the architecture or address-model, I get no mention of either in my paths or in my mangled library names. The build system will silently use the architecture of the host machine. If I compile the same code on an Intel mac, the build system uses the same folder and library names IIUC, but the generated code will use x86 instructions. I believe one has to parse the output from a tool that lives outside of the build system, such as arch, to determine what the resulting instruction set will be in this scenario. That is, I'm not aware of a way to treat the default architecture as a property that can be used in conditionals, except in the case where the user specifically asks for, say, architecture=x86. Am I correct here? Maybe this isn't just a mac issue. If the user doesn't explicitly mention target-os I am unaware of how to successfully add library usage-requirements like: <toolset>gcc,<architecture>x86: <instruction-set>i486 ## require intrinsic support for patched cygwin compatible Intel TBB 4) If I'm wrong here, how do I do this? This is actually coming up in our code base today Ideally I'd like to be able to narrow this to a conditional that implements: IF (toolset = gcc and target-os = cygwin and architecture = x86) then ensure that instruction-set is at least i486 but I'm unaware as to how to do it. In any case, the point of all this is that, from what I can gather, the build system really doesn't have all of this information at present. This leads me to ask: 5) Would it be possible or desirable to give up a little 'safety' in return for a simpler thread Jamfile? Such a Jamfile would only add the state of the threadapi feature (different from none) to the path in the case when the user explicitly sets threadapi. This way it wouldn't have to try to (imperfectly) duplicate the logic in the boost/config headers, but it could still offer a way for the user to manually override them when necessary. I can see several benefits if the answer to question 5 turns out to be yes. A) Thread's Jamfile's dependence on who compiled the bjam.exe tool would go away B) Maybe some of the need for enhanced flavor support is lessened (I have no idea whether this is true) C) Paths could be made somewhat shorter and shell independent I would like to digress for a moment to relate a small anecdote about how long paths are not simply an aestehetic nuisance, but can increase development costs. Currently to be able to use 1.35.0 threads from an msvc-compiled bjam under from bash, I have to have my users add toolset.add-requirements <toolset>gcc:<target-os>cygwin <toolset>gcc:<threadapi>pthread ; to their user-config.jam While allowing threads to build, in our environment this has the side-effect of producing paths like the following: C:\opensource\sanbox\joeuser\sandbox\built_artifacts\test\ unit_tests\copy_on_write\copy_on_write_test.test\gcc-4.3.0\debug\ architecture-x86\asl-dev\instruction-set-i486\link-static\ target-os-cygwin\threadapi-pthread\threading-multi\ copy_on_write_test.exe Yesterday this bit us. Apparently, on some users' machines the full path length exceeds the cygwin/XP limits and the executable can not be run! So the tests in our Jamfile were mysteriously failing. One remedy here seems to be to use shorter paths for our own features, directories and project names. Another is to try to pass --abbreviate-paths to bjam to drop a few vowels from the paths. A third is to perhaps use a cygwin-built bjam. For various reasons none of these have much appeal, though I'll do what I can. Ideally, though, I'd like target-os-cygwin and threadapi-pthread to disappear from the path, since they don't add much value for me. In fact, I argue that they remove value, since they are not present in the paths that I get if I happen to choose a cygwin-compiled bjam.exe, so I end up with two needlessly incompatible trees of artifacts. This has been a long email with several different kinds of questions, and a number of guesses about the behavior of the build system. Some of my assumptions are undoubtedly wrong. But, if there is interest, I'd like hear several other people's thoughts on these issues. And of course answers to any of my questions are most welcome. -Mat

1 0