- Boost - lists.boost.org

[filesystem] patch for path.hpp for "Duplicate symbol" problem on HP-UX and Tru64
by Boris Gubenko 19 Apr '07

19 Apr '07

Vladimir Prus wrote: > Boris, > since this a patch for boost.filesystem, I think you better post it > to Boost mailing list, not Boost.Build mailing list. We don't have > the authority to approve boost.filesystem patches here. Posting to the right list. Thanks, Vladimir! ---------------------------------------------------------------------------- On HP-UX and Tru64, when using CVS HEAD, linking of process_jam_log fails because of multiply defined symbol. From ld output on HP-UX, for example: ld: Duplicate symbol "boost::filesystem::basic_filesystem_error<boost:: filesystem::basic_path<std::basic_string<char,std::char_traits<char>, std::allocator<char> >,boost::filesystem::path_traits> >::what() const" The duplicate symbol is coming from the explicit specialization in boost/filesystem/path.hpp conditionalized for anything but gcc with the following comment: // TODO: Figure out why this specialization is causing problems with GCC #ifndef __GNUC__ ... With aCC (HP-UX) and cxx (Tru64), this specialization is causing linker's muldef if several modules include header file with the specialization. According to reproducer below, this is the same problem with gcc also, although I don't know what "problems with GCC" the comment above refers to. This specialization does not cause a problem with Intel compiler for Itanium: see output for intel_ecc and iVMS below. Attached patch fixes the problem on HP-UX/aCC and Tru64/cxx by extending condition under which the specialization is not provided (before the fix, it was not provided for gcc only). I verified that it fixes the problem on the aforementioned platforms. Ok to commit? Thanks, Boris path.hpp -------- class path; template<class T> class basic_filesystem_error { const char * what() const throw(); }; template<> const char * basic_filesystem_error<path>::what() const throw() { return 0; } x.cpp ----- #include "path.hpp" int main() {} y.cpp ----- #include "path.hpp" bash-2.03$ aCC -V aCC: HP C/aC++ B3910B A.06.14 [Feb 22 2007] bash-2.03$ aCC x.cpp y.cpp x.cpp: y.cpp: ld: Duplicate symbol "basic_filesystem_error<path>::what() const" in files x.o and y.o 1 errors. bash-2.03$ g++ x.cpp y.cpp ld: Duplicate symbol "basic_filesystem_error<path>::what() const" in files /var/tmp//ccvXAxka.o and /var/tmp//ccWe5Xga.o 1 errors. collect2: ld returned 1 exit status bash-2.03$ cxxosf.zko.hp.com> cxx -V Compaq C++ V7.1-006 for Compaq Tru64 UNIX V5.1B (Rev. 2650) Compiler Driver V7.1-006 (cxx) cxx Driver cxxosf.zko.hp.com> cxx x.cpp y.cpp x.cpp: y.cpp: ld (prelink): y.o compressed: basic_filesystem_error<path>::what(void) const : multiply defined ld: y.o compressed: basic_filesystem_error<path>::what(void) const : multiply defined cxxosf.zko.hp.com> icc.zko.hp.com> $DECC_BIN/intel_ecc -V Intel(R) C Itanium(R) Compiler for Itanium(R)-based applications Version 9.0 Build 20060221 Built Jun 19 2006 17:12:01 by cbldr on icc.zko.dec.com in /usr/proj/decc7/decc/intel_builds/latest/dev Copyright (C) 1985-2006 Intel Corporation. All rights reserved. icc.zko.hp.com> $DECC_BIN/intel_ecc x.cpp y.cpp icc.zko.hp.com> ICXX::_1> cxx/ver HP C++ X7.3-100 on OpenVMS IA64 V8.3 ICXX::_1> cxx x.cpp ICXX::_1> cxx y.cpp ICXX::_1> link x.obj, y.obj ICXX::_1> Index: path.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/filesystem/path.hpp,v retrieving revision 1.24 diff -u -d -r1.24 path.hpp --- path.hpp 3 Nov 2006 16:57:29 -0000 1.24 +++ path.hpp 18 Apr 2007 20:33:16 -0000 @@ -611,8 +611,8 @@ boost::shared_ptr<m_imp> m_imp_ptr; }; -// TODO: Figure out why this specialization is causing problems with GCC -#ifndef __GNUC__ +// This specialization is causing problems with GCC, aCC (HP-UX) and cxx on Alpha. +#if !(defined(__GNUC__) || defined(__HP_aCC) || (defined(__DECCXX) && defined(__alpha))) template<> const char * basic_filesystem_error<path>::what() const throw() { if ( !m_imp_ptr.get() ) return system_error::what();

1 0

Re: [boost] [decimal] non-N2198 implementations
by james.jones＠firstinvestors.com 19 Apr '07

19 Apr '07

From: Jeff Garland <jeff(a)crystalclearsoftware.com> >james.jones(a)firstinvestors.com wrote: >> So here's my question again: Is there any interest in a Boost library that implementated decimal >> arithmetic but didn't use N2198? >> >> What I have working now would use expression templates to implement context: >> >> context<decimal32> ctx; >> decimal32 x = ctx(9912), y = ctx("9e+4"); >> decimal32 z = ctx(x + y); >> z = ctx(x * y); >> z = ctx(x - (3 * z)); > >Expression templates are awesome...well, except for all the real world code >I've seen that does calculations reads data in from a db or file and then >crunches it. So ET just does nothing for these cases... I don't understand this - why can't I read in data from a file? ifstream f("data.txt"); context<decimal32> ctx; decimal32 x, y, z; ctx(f >> x >> y); // not implemented yet, but certainly could be z = ctx(x + y); >I'll also say that I don't find the above syntax natural...I just think > >decimal32 x(9912), y("9e+4"); >decimal32 z = x + y; > >would be more expected. I'm sure you have good reasons, but from my >perspective a number type should behave as much like a built-in type as possible. This I totally understand, and agree with, but I'm not sure what the perfect solution is. My idea is to provide a user-customizable context class for all operations, and a lot of design decisions derive from this. The binary operations essentially have become TRInary operations; it isn't +(x,y), but rather +(x,y,context). Context participates in the operation. So the question is, how do we implement this without forcing the user to do something really ugly like: z = add(x, y, context); My solution was to wrap the expression in an instance of context. I've also provided for a default context so that you actually can use the syntax you prefer, but you lose a little flexibility: z = x + y; // uses default context x = z * z; // still using default context z = ctx(x + y); // uses context instance ctx x = ctx2(z * z); // uses a new context instance ctx2 The default context is currently implemented using a singleton (I'm aware that there are some real-world usage concerns about singletons). >> 2. However, in the presence of exceptions I believe that my usage is simpler than what is required by >> N2198, which is going to result in hardware traps and/or signals, rather than nice C++ exceptions. >> With a context class you can throw exceptions or allow user-defined behavior. > >Didn't know that...yuck... Well, this does make some sense, especially considering the plan to move to a hardware implementation at some point. Also, N2198 explicitly states that they're going for some level of C compatibility; obviously exceptions wouldn't fit that mold. >> 3. N2198 restricts users to 3 decimal types, which presumably match the IEEE754r implementation of >> decimal types. These are great for memory usage, but not so hot for performance, at least when >> implemented in software - too much bit-twiddling. A straightforward implementation of decimals >> using arrays to store coefficients is much less space-efficient, but runs faster. (My very >> rudimentary testing indicates that the ratio is around 2.5:1 on my hardware, a Sun server.) > >Well, I guess my goal would be to see Boost.tr2 get started (even though we >don't really have boost.tr1 finished). So I'd like to see a decimal interface >that supports N2198 in software and can drop to hardware where it becomes >available. I don't see how the 3 type restriction stops you from an array >implementation under the hood (note that it's been at least 6 months since I >looked at it). I'd be fine with well justified extensions -- seems to me >these would serve as feedback to N2198. There's still a window to modify it I >think... The problem with the type restriction is that there are some cases where you want speed and some where you really care about memory. If I just say "decimal32" I can't distinguish the two. As you say, though, in a hardware implementation the distinction goes away, because all the bit-twiddling necessary to work with IEEE754r decimals is done fast in hardware. >Sorry, that's a complicated position for a yes/no question ;-) That's OK - thanks for your comments! - James Jones Administrative Data Mgmt. Webmaster 375 Raritan Center Pkwy, Suite A Data Architect Edison, NJ 08837

1 0

[multi-array] constructor bypass patch
by Neal Becker 19 Apr '07

19 Apr '07

This proposed patch allows bypassing of default constructors. This can be important for high performance computing. What this patch does: 1. Add an optional arg to 'allocate_space' to specify if element construction is wanted 2. Add 'default_do_init' static constant, which is false for POD and for std::complex<T> 3. Also bypass construction when the result is going to be immediately overwritten (copy_n) 4. Add to 'allocate_space' and optional init value, which default to T(). The purpose is to allow for a multi_array constructor that specifies an initial fill value. This is another optimization and consistent with STL containers. However, I haven't figured out how to use this yet.

1 0

[1.34.0] [iostreams] patch - boost_bzip2 contains the symbol "main"
by Takeshi Mouri 19 Apr '07

19 Apr '07

Hello, I found the symbol "main" in the boost_bzip2 libraries. The function main() is contained in the file "mk251.c". This is for testing, so we doesn't need it. The attachment is a trivial patch for this problem. Regards, Takeshi Mouri

1 0

[iostreams] file_descriptor::read bug?
by Xi Wang 19 Apr '07

19 Apr '07

In the source libs/iostreams/src/file_descriptor.cpp, file_descriptor::read, line 147, I think return static_cast<std::streamsize>(result); should be return static_cast<std::streamsize>(result == 0? -1: result); The Windows API ReadFile returns TRUE with result == 0 when it has come to end-of-file. Regards, Xi

1 1

[Boost-bugs] [ boost-Patches-1703358 ] patch for Visual Studio 8 + Windows x64 (AMD64)
by SourceForge.net 19 Apr '07

19 Apr '07

Patches item #1703358, was opened at 2007-04-18 20:23 Message generated for change (Comment added) made by grafik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1703358&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 Private: No Submitted By: Aleksey Sanin (lsh123) Assigned to: Nobody/Anonymous (nobody) Summary: patch for Visual Studio 8 + Windows x64 (AMD64) Initial Comment: This patch adds "vc8" build tool to jam and fixes several issues with building boost in Visual Studio 8 on AMD64 platform: * tools/build/jam_src/build.bat On Windows 64 the default location for Visual Studio is "C:\Program Files (x86)\...". The ( ) confuses the bat file big time and I had to workaround it by using quotes and DeQuote function. * tools/build/jam_src/build.jam and tools/build/jam_src/jambase.c Simply new "vc8" tool * tools/build/jam_src/pathunix.c Changed DWORD -> int because on VC8 DWORD is unsigned which causes problem when we have pos=0 (then prev_pos is a huge number and everything is screwed). * boost/config/abi/msvc_prefix.hpp Make alignment consistent with STLPort. * boost/config/abi/msvc_prefix.hpp It seems that this workaround is not needed in the final version of VC 8 * libs/thread/src/once.cpp This is a known issue (http://lists.boost.org/boost-users/2005/09/13765.php) Unfortunately, I can't figure out a better way to fix this. ---------------------------------------------------------------------- >Comment By: Rene Rivera (grafik) Date: 2007-04-18 21:47 Message: Logged In: YES user_id=33595 Originator: NO Boost.Jam in CVS already has many fixes to support both cross x64 and native x64 building. As for the rest, I would suggest posting separate library specific patches. ---------------------------------------------------------------------- Comment By: Aleksey Sanin (lsh123) Date: 2007-04-18 20:24 Message: Logged In: YES user_id=851494 Originator: YES forgot to add that the patch is done against boost 1_33_1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1703358&group_… ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[decimal] non-N2198 implementations
by james.jones＠firstinvestors.com 19 Apr '07

19 Apr '07

> From: Jeff Garland <jeff(a)crystalclearsoftware.com> > > Fixed Decimal > > > > Introduction: Fixed Decimal types provide an alternative to floating > > point types that are superior in their calculation properties. Robert > > Klarer of IBM has proposed adding these types to C++ [in n2198 (pdf)] > > and prior papers. This work is now on track to be included in C++0x. > > Robert has an implementation of these types with a restrained license. > > This project involves implementing the n2198 interfaces in a Boost library. > > I have done a lot of work on something very similar to this that I was hoping to > propose airly soon (next few weeks). The interface isn't quite N2198, but I'm not > crazy about N2198 anyway (it isn't threadsafe, for example, AFAICT). I've been > using the IEEE754r spec. Is it worthwhile at all to continue to work on a BOOST > library for fixed decimal arithmetic without making it N2198 compliant? I brought this up a couple of weeks ago but the discussion got sidetracked by my thread safety question. I'm reasonably satisfied that N2198 can be written in a threadsafe way using <cfenv> now (if the fenv implementation is threadsafe, that is), but I'm still not totally happy with the extremely restrictive N2198 interface. So here's my question again: Is there any interest in a Boost library that implementated decimal arithmetic but didn't use N2198? What I have working now would use expression templates to implement context: context<decimal32> ctx; decimal32 x = ctx(9912), y = ctx("9e+4"); decimal32 z = ctx(x + y); z = ctx(x * y); z = ctx(x - (3 * z)); The expressions (e.g. "x*y") are evaluated within a context<decimal32> instance, which does exception trapping, etc. This gives the library user a lot of control - it also would easily allow a user to derive from context to implement their own behaviors. There is also a facility for using a default singleton context as well for code that needs to be written in the form: z = x * y; There are several usage differences between my proposal and N2198: 1. N2198 is simpler to understand because it doesn't rely on expression templates. No question here. 2. However, in the presence of exceptions I believe that my usage is simpler than what is required by N2198, which is going to result in hardware traps and/or signals, rather than nice C++ exceptions. With a context class you can throw exceptions or allow user-defined behavior. 3. N2198 restricts users to 3 decimal types, which presumably match the IEEE754r implementation of decimal types. These are great for memory usage, but not so hot for performance, at least when implemented in software - too much bit-twiddling. A straightforward implementation of decimals using arrays to store coefficients is much less space-efficient, but runs faster. (My very rudimentary testing indicates that the ratio is around 2.5:1 on my hardware, a Sun server.) - James Jones Administrative Data Mgmt. Webmaster 375 Raritan Center Pkwy, Suite A Data Architect Edison, NJ 08837

2 1

[Boost-bugs] [ boost-Patches-1703358 ] patch for Visual Studio 8 + Windows x64 (AMD64)
by SourceForge.net 19 Apr '07

19 Apr '07

Patches item #1703358, was opened at 2007-04-18 18:23 Message generated for change (Comment added) made by lsh123 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1703358&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 Private: No Submitted By: Aleksey Sanin (lsh123) Assigned to: Nobody/Anonymous (nobody) Summary: patch for Visual Studio 8 + Windows x64 (AMD64) Initial Comment: This patch adds "vc8" build tool to jam and fixes several issues with building boost in Visual Studio 8 on AMD64 platform: * tools/build/jam_src/build.bat On Windows 64 the default location for Visual Studio is "C:\Program Files (x86)\...". The ( ) confuses the bat file big time and I had to workaround it by using quotes and DeQuote function. * tools/build/jam_src/build.jam and tools/build/jam_src/jambase.c Simply new "vc8" tool * tools/build/jam_src/pathunix.c Changed DWORD -> int because on VC8 DWORD is unsigned which causes problem when we have pos=0 (then prev_pos is a huge number and everything is screwed). * boost/config/abi/msvc_prefix.hpp Make alignment consistent with STLPort. * boost/config/abi/msvc_prefix.hpp It seems that this workaround is not needed in the final version of VC 8 * libs/thread/src/once.cpp This is a known issue (http://lists.boost.org/boost-users/2005/09/13765.php) Unfortunately, I can't figure out a better way to fix this. ---------------------------------------------------------------------- >Comment By: Aleksey Sanin (lsh123) Date: 2007-04-18 18:24 Message: Logged In: YES user_id=851494 Originator: YES forgot to add that the patch is done against boost 1_33_1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1703358&group_… ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Patches-1703358 ] patch for Visual Studio 8 + Windows x64 (AMD64)
by SourceForge.net 19 Apr '07

19 Apr '07

Patches item #1703358, was opened at 2007-04-18 18:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1703358&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 Private: No Submitted By: Aleksey Sanin (lsh123) Assigned to: Nobody/Anonymous (nobody) Summary: patch for Visual Studio 8 + Windows x64 (AMD64) Initial Comment: This patch adds "vc8" build tool to jam and fixes several issues with building boost in Visual Studio 8 on AMD64 platform: * tools/build/jam_src/build.bat On Windows 64 the default location for Visual Studio is "C:\Program Files (x86)\...". The ( ) confuses the bat file big time and I had to workaround it by using quotes and DeQuote function. * tools/build/jam_src/build.jam and tools/build/jam_src/jambase.c Simply new "vc8" tool * tools/build/jam_src/pathunix.c Changed DWORD -> int because on VC8 DWORD is unsigned which causes problem when we have pos=0 (then prev_pos is a huge number and everything is screwed). * boost/config/abi/msvc_prefix.hpp Make alignment consistent with STLPort. * boost/config/abi/msvc_prefix.hpp It seems that this workaround is not needed in the final version of VC 8 * libs/thread/src/once.cpp This is a known issue (http://lists.boost.org/boost-users/2005/09/13765.php) Unfortunately, I can't figure out a better way to fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1703358&group_… ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Report] 1 regressions on RC_1_34_0 (2007-04-18)
by Douglas Gregor 18 Apr '07

18 Apr '07

Boost Regression test failures Report time: 2007-04-18T03:04:03Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 1 failures in 1 libraries graph (1) |graph| adj_list_cc: gcc-cygwin-3.4.4

2 1