- Boost - lists.boost.org

[Boost-bugs] [ boost-Patches-1002538 ] name injection before definition
by SourceForge.net 09 Jan '06

09 Jan '06

Patches item #1002538, was opened at 2004-08-03 04:21 Message generated for change (Settings changed) made by mclow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1002538&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Francois Dumont (dums) >Assigned to: Beman Dawes (beman_dawes) Summary: name injection before definition Initial Comment: In operations_posix_windows.cpp within the filesystem library strcmp, remove and rename symbols are injected within namespace std before being defined by the inclusion of cstdio header. This bug has been revealed by a test with the latest STLport 5.0 RC1. It makes the code standard library implementation dependent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1002538&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1202693 ] a simple patch about boost::format (for MSVC7.1)
by SourceForge.net 09 Jan '06

09 Jan '06

Patches item #1202693, was opened at 2005-05-16 00:30 Message generated for change (Settings changed) made by mclow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1202693&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lim Hwan Cheol (whitecrw) >Assigned to: Samuel Krempp (samuel_k) Summary: a simple patch about boost::format (for MSVC7.1) Initial Comment: It seems to be a bug on MSVC7.1 compiler. that foolish compiler has some conflict on matching signature... 'basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' and 'boost::basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' i think this is ultimately same signature. but, msvc71 doesn't.. for this, i used some #if tricks. :) attached patchfile contains my modifications. may the code be with you~ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1202693&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1273960 ] spirit/symbols.ipp pragma warning fix
by SourceForge.net 09 Jan '06

09 Jan '06

Patches item #1273960, was opened at 2005-08-26 04:34 Message generated for change (Settings changed) made by mclow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1273960&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: jmihalicza (jmihalicza) >Assigned to: joel de guzman (djowel) Summary: spirit/symbols.ipp pragma warning fix Initial Comment: The original version sets the default setting back at the end of the file so the following code doesn't work as expected: #pragma warning (disable:4355) #include <boost/spirit/....> // some file that includes symbols.ipp // here 4355 may be enabled according to the default settings (warning level) The fix uses push/pop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1273960&group_… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-966723 ] function.hpp missing include guard patch
by SourceForge.net 09 Jan '06

09 Jan '06

Patches item #966723, was opened at 2004-06-04 11:24 Message generated for change (Settings changed) made by mclow You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=966723&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: function.hpp missing include guard patch Initial Comment: function.hpp does not have an #ifndef/#endif include guard. This patch adds #ifndef BOOST_FUNCTION_HPP at the top of the file and #endif at the bottom. -- nicolas.desjardins(a)orthosoft.ca ---------------------------------------------------------------------- >Comment By: Marshall Clow (mclow) Date: 2006-01-09 14:18 Message: Logged In: YES user_id=131412 In <http://lists.boost.org/Archives/boost/2004/06/66443.php>, Doug wrote: function.hpp isn't actually supposed to have include guards. The code it contains will never actually be included twice, but you can include function.hpp with BOOST_FUNCTION_MAX_ARGS set to different values to create support for greater numbers of arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=966723&group_i… ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Linker error using Boost.Test on Windows
by Hartmut Kaiser 09 Jan '06

09 Jan '06

Hi all, Using the Boost.Test library on Windows (VC7.1) gives me the following error: libboost_unit_test_framework-vc71-mt-sgd-1_34.lib(exception_safety.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in libcpmtd.lib(newop.obj) The same occurs when I use te /MDd memory model: libboost_unit_test_framework-vc71-mt-gd-1_34.lib(exception_safety.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in msvcprtd.lib(newop_s.obj) Any clues? Regards Hartmut

3 5

Filesystem breaking change?
by John Maddock 09 Jan '06

09 Jan '06

Beman, The recent update to Boost.Filesystem has broken bcp in a way I'm not sure how to fix. The problem is that while scanning for header dependencies it comes across some platform dependent names ( :sys:stat.h ) and then checks for the existence of that name in various places such as <tools/build/jam_src/:sys:stat.h>. Obviously such checks should fail, but rather than just saying "no the file doesn't exist" the function exists is throwing an exception. IMO there's no real need for an exception in this case is there? Many thanks, John.

2 3

mpl and pqs (physical quantities library)
by Andy Little 09 Jan '06

09 Jan '06

Hi, Having now spent some time porting my pqs library http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html over to boost, I am currently of the opinion that using mpl is not really practical for use with the pqs library. The main issue is regarding the large amount of types created behind the scenes by the mpl library. This is not acceptable in pqs because pqs uses a large number of parameters per quantity. The VC7.1 compiler is now frequently coming up with an fatal error message 'out of keys' during compilation of tests. For comparison this wasnt a noiceable problem in the non-boost version Obviously for the library to be remotely useable I need to be as sparing as possible with compiler resouces, allowing the user as much room to work as possible. In order for the pqs library to be practical I need to use a family of types for the dimension parameters that is designed with great care with respect to the total number of types created behind the scenes. Even then I need to acknowledge the issue of use of compiler resources by the library in the documentation. An example niggle regarding the mpl arithmetic operations , that they each use 5 parameters for e.g. addition whereas minimally only 2 are required. This also adds to the bloat for example. This is a particlar problem in the pqs library. Another issue with mpl concerns the fact that mpl doesnt deal in types. This is a problem when trying to register types in conjunction with BoostTypeof . .. What types to register ? (This is only a problem because the lack of an inbuilt typeof operator in C++). I'll certainly leave the current version of boost::pqs around (pqs_3_0_1 now in the vault in Physical Quantities Units directory) . I am aware that the situation could be improved slighltly for example by not allowing conversions from rational types to integral types, though the problem would still remain in lesser form) I hope that pqs-3-0-1 will answer the question why I have opted not to use mpl in the implementation in the next version. regards Andy Little

3 3

[iostreams] [RC_1_33_1] Currently broken on Tru64/CXX and Como 4.3.3
by Markus Schöpflin 09 Jan '06

09 Jan '06

What happened to the iostreams library? It worked fine for those compilers in 1.33.0 as can be seen on http://tinyurl.com/76dqz, but now most tests fail with the following error message: cxx -c -std strict_ansi -nopure_cname -noimplicit_include -timplicit_local -ptr "/house/schoepf/boost/regression/results/bin/boost/libs/iostreams/test/auto_close_test.test/tru64cxx71-006/debug/cxx_repository" -msg_display_number -msg_disable 186,450,1115 -DBOOST_IOSTREAMS_NO_LIB -g3 -O0 -inline none -version V7.1-006 -ieee -gall -D__CNAME_OVERLOADS -model ansi -I"/house/schoepf/boost/regression/results/bin/boost/libs/iostreams/test" -I"/house/schoepf/boost/regression/boost" -o "/house/schoepf/boost/regression/results/bin/boost/libs/iostreams/test/auto_close_test.test/tru64cxx71-006/debug/auto_close_test.o" "/house/schoepf/boost/regression/boost/libs/iostreams/test/auto_close_test.cpp" cxx: Error: /house/schoepf/boost/regression/boost/boost/iostreams/chain.hpp, line 427: #29 expected an expression { return chain_->component_type<N>(); } ---------------------------------------^ cxx: Error: /house/schoepf/boost/regression/boost/boost/iostreams/chain.hpp, line 431: #254 type name is not allowed { return chain_->component<T>(n); } -------------------------------^ cxx: Error: /house/schoepf/boost/regression/boost/boost/iostreams/chain.hpp, line 436: #254 type name is not allowed { return chain_->component<N, T>(); } ----------------------------------^ cxx: Error: /house/schoepf/boost/regression/boost/boost/iostreams/chain.hpp, line 436: #29 expected an expression { return chain_->component<N, T>(); } -------------------------------------^ cxx: Info: 4 errors detected in the compilation of "/house/schoepf/boost/regression/boost/libs/iostreams/test/auto_close_test.cpp". Does this ring a bell with anyone? Markus

3 7

Re: [boost] [Boost-build] bug in boost.build?
by Oliver.Kowalke＠infineon.com 09 Jan '06

09 Jan '06

>> bjam --prefix=/opt/boost "-sTOOLS=gcc" "-sSUFDLL=.sl" "-sBUILD=debug >> release <runtime-link>dynamik <threading>multi <cxxflags>-D_REENTRANT >> <cxxflags>-fpic <release><optimization>speed" install >> But I get only libboost__<xxx>-gcc-mt-1_33_1.a and >> libboost_<xxx>-gcc-mt-d-1_33_1.a libraries. No >> libboost__<xxx>-gcc-mt-1_33_1.sl libboost__<xxx>-gcc-mt-d-1_33_1.sl? >Perhaps because of the typo in "dynamik"? It should be spelled "dynamic". Oh yes - it was a typo! But anyway: command 'bjam --prefix=/opt/boost "-sTOOLS=gcc" "-sSUFDLL=.sl" "-sBUILD=release <threading>multi <cxxflags>-fpic" install' produces: - an segmentation fault while loading the signals library! (see my previous email '[boost] bug in signals library? - segmentation fault(onlylinked) -> exit(11) called') - libraries iostreams and wave have only extension *.a (no *.sl) command 'bjam --prefix=/opt/boost "-sTOOLS=gcc" "-sBUILD=release <threading>multi <cxxflags>-fpic" install' - segmentation fault disappears - library wave is build with *.a extension only (no *.so) It seams that boost build system has some problems! Please don't ignore this as you did before! Regards, Oliver

2 1

[program_options] Bug: "ambiguous" option shouldn't be
by Braden McDaniel 09 Jan '06

09 Jan '06

When the attached test program is run as $ program-options-test --foo program_options in Boost 1.33.1 thinks the option is ambiguous; apparently because there is another option that starts with "foo" followed by a dash. This is a regression with respect to 1.32.0. -- Braden McDaniel e-mail: <braden(a)endoframe.com> <http://endoframe.com> Jabber: <braden(a)jabber.org>

2 1