- Boost - lists.boost.org

Happy marriage of std::vector and Python array?
by Nigel Stewart 15 May '06

15 May '06

Hi all, We're looking to share some heavy-weight numerical data in a mixed language C++/Python environment. boost::python::numeric::array provides a C++ binding for the Python numeric array. However, we'd prefer to have an STL compatible (std::vector compatible) interface to the data, rather than python-ising our C++. The underlying runtime issue is to store one copy of the contiguous 1D data in a way that both C++ and Python can read and write, that will follow the Python memory management scheme. Has anyone come across a std::vector compatible wrapper for PyArrayObject? Any thoughts? Cheers, Nigel Stewart

3 9

is_pointer bug with const function pointers
by Jordan Chavez 15 May '06

15 May '06

Hi, I was fiddling around with the type traits library today and I found that is_pointer<> is false for const function pointers: bool b = boost::is_pointer<void (*)()>::value; // true b = boost::is_pointer<void (*const)()>::value; // false I also tried with a variety of other function pointer signatures, all const versions were not considered pointers. The compiler I'm using is MSVC 7.1 and I haven't tested this on any other platforms. From reading the source I have no idea why this happens...is_pointer is explicitly specialized for const pointer types so maybe it's a compiler issue, but I haven't checked. Thanks, Jordan Chavez jchavez(a)vt.edu

2 2

vc8-stlport toolset support
by Wang Yun 15 May '06

15 May '06

Hi, VC2005's STL has a memory leak bug in it's std::basic_iostream, so I switch to use STLPort5.0.2, but I found there is no offical toolset support for vc8_stlport in boost_1_33_1, are there any plan to add this support in boost_1_34? Thanks, Wang Yun

2 2

Re: [boost] [filesystem][program_options][serialization][test]fromcomp.lang.c++.moderated
by bwood 15 May '06

15 May '06

David Abrahams wrote: >>"Le Chaud Lapin" <unoriginal_usern...(a)yahoo.com> writes: >>More than anything in programming, I depend on type to create form. >>Versioning implies that types are semi-weak. > > >If versioning in serialized form implies that, then so do revisions of >your type in a version control system. So, basically, once you design >a class, it never evolves? > Along the lines of what Lapin is thinking, I think B.Ser's "versioning" support is problematic. For example, consider wanting to move (or delete) a data member out of a type between versions 1.1 and 1.2. B.Ser needs that member to remain in the type in order to support 1.1. To answer the question: I make changes to types over time, but this sort of a change is thwarted by the B.Ser approach. An idea of how to better structure a component can't be implemented in a direct way because the approach taken by the library isn't able to cope with the fluidity of software development. If a server (version) has to support multiple versions of a type at the same time, conditional compilation wouldn't be helpful either. If members are simply being added to a type between version 1.1 and 1.2, there remains this blurring of types. Brian www.webEbenezer.net

2 1

Database library - SOCI 2.1.0 available
by Maciej Sobczak 15 May '06

15 May '06

Hi, (Looks like the activity of the SOCI library is the only factor driving the discussion of the potential Boost database library. ;-) ) I'm pleased to announce that the new release of the SOCI library is available for download: http://soci.sourceforge.net/ The new release (2.1.0) contains two new backends and now supports: - Oracle - PostgreSQL - MySQL - SQLite We are still inviting potential contributors with ODBC experience. Regards, -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

1 0

Re: [boost] [PATCH] Fix tools/wave compilation
by Richard Guenther 15 May '06

15 May '06

On Fri, 12 May 2006, Hartmut Kaiser wrote: > Richard Guenther wrote: > > > > Not yet, but I know that this problem was on linux/gcc systems only > > > and my main testing platform is Windows. I'll try to find a > > linux box > > > with gcc 4.1 istalled today. > > > > > > OTOH we had this problems on other gcc platforms earlier as > > well and > > > these went away after the fix I sent you yesterday. So I'm > > currently a > > > bit out of ideas. > > > > > > In the mean time, could you please set the > > > > > > #define BOOST_WAVE_BSIZE 196608 > > > > > > in the same file you fixed yesterday to something bigger as > > your file size? > > > Does the error still occur? > > > > Raising that to 262144 makes it work. That gives me another > > hint to where to look. > > Doh! Then there is something wrong with the code loading the next chunk of > data for large files. This should be reproducible for very small files with > > #define BOOST_WAVE_BSIZE 16 > > now. Is there a '\\n' backslash/newline in your file somewhere around the > 'magic' buffer size we had? > > I'll have a look at this later this weekend. > Regards Hartmut This patch fixes it for me (again against the 1.33.1 sources). The problem is that after doing the last buffer read with fill, s->lim is zeroed out by the subsequent RET (identifier) as limit was not updated after the call to fill. Richard. -- Richard Guenther <rguenther(a)suse.de> Novell / SUSE Labs --- cpp_re.cpp.orig 2006-05-15 13:29:00.000000000 +0200 +++ cpp_re.cpp 2006-05-15 13:31:59.000000000 +0200 @@ -51,7 +50,7 @@ #define YYCURSOR cursor #define YYLIMIT limit #define YYMARKER marker -#define YYFILL(n) {cursor = uchar_wrapper(fill(s, cursor), cursor.column);} +#define YYFILL(n) {cursor = uchar_wrapper(fill(s, cursor), cursor.column); limit = uchar_wrapper (s->lim); } //#define RET(i) {s->cur = cursor; return (i);} #define RET(i) \ @@ -187,7 +186,7 @@

1 0

[thread] 1.33.1 with vc71, links against msvcrt and msvcprt
by Andrew Finkenstadt 15 May '06

15 May '06

The goal: upgrade from boost 1.32 to 1.33.1. The gotcha: Somehow a programmer here managed to build a version of boost::thread version 1.32 whose .LIB file did not contain any directives to link against MSVCRT and MSVCPRT; there doesn't seem to be anything I do with bjam that causes version 1.33.1 to do the same. (He just handed me the .lib files to install into the right place, I knew I should have insisted he learn to do it himself. :) ) "dumpbin /directives /archivemembers libboost_thread-vc71-mt-s-1_33_1.lib" yields several Linker Directives ----------------- /DEFAULTLIB:"msvcprt" /DEFAULTLIB:"MSVCRT" commands. Which totally breaks my application (which requires the use of LIBCMT) by complaining of duplicate symbols defined in both. /NODEFAULTLIB: is not appropriate. The frustration: I can't seem to find where bjam's rules for specifying the CC Options *are*, much less know how to twiddle the Jamfile.v2 file for boost::threads. The steps I've taken: I had a similar problem with the regex library, but the vc71.mak file built perfect libraries. There's no corresponding vc71.mak file that I've found yet, for threads. So, to build threads, I basically go to the top level of boost_1_33_1 and run bjam with the vc71 toolset option. The reward: my eternal gratitude... and my sincerest thanks for help in answering this, no doubt, simple question. I've been reading the list for about a year, but don't remember seeing this specific issue discussed. Last year in http://lists.boost.org/boost-users/2005/05/11725.php was a discussion about whether boost::thread in 1.32 supported static runtime linking , and the answer appears to be yes, but like I said -- i have no idea how Junior Programmer got it done and working. Best regards, andy

4 4

[serialization] The trouble with BCB2006
by Nicola Musatti 15 May '06

15 May '06

Robert, I think I found the problem, but I'm not sure on how to code a workaround. Apparently BCB2006 introduced a bug which causes writes to a BOOST_STRONG_TYPEDEF to fail, just as if a temporary was updated. This is affecting specifically the reading of archive versions. The code below is an example of an effective workaround: version_type input_library_version; #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x582)) && __BORLANDC__ >= 0x580 unsigned int v; * this->This() >> v; input_library_version.t = v; #else * this->This() >> input_library_version; #endif Probably it would be sufficient to just pass input_library_version.t to operator>> . The real problem I have with this workaround is that it would be much better to factor it into BOOST_STRONG_TYPEDEF's definition, but I'm not sure about what is exactly causing the problem and I'm not very confident about my ability to add conditions to a macro definition. Cheers, Nicola Musatti

2 4

[Boost-bugs] [ boost-Bugs-1488660 ] Bug in xml_oarchive_impl<Archive>::save(const std::string&)
by SourceForge.net 15 May '06

15 May '06

Bugs item #1488660, was opened at 2006-05-15 07:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1488660&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: serialization Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexey Bash (alexey-b) Assigned to: Robert Ramey (ramey) Summary: Bug in xml_oarchive_impl<Archive>::save(const std::string&) Initial Comment: Bug in file "boost/archive/impl/xml_oarchive_impl.ipp" line 82 method: template<class Archive> BOOST_ARCHIVE_DECL(void) xml_oarchive_impl<Archive>::save(const std::string & s ). Second argument of call: std::copy( xml_escape_translator(BOOST_MAKE_PFTO_WRAPPER(s.data() )), xml_escape_translator(BOOST_MAKE_PFTO_WRAPPER(s.data()+ s.size())), boost::archive::iterators::ostream_iterator<char>(os)) is wrong: in constructor of xml_escape_translator the method template<class Base> char xml_escape<Base>::fill( const char * & bstart, const char * & bend) is called for after-last symbol!!! If this symbol is, e.g., '>' - we have error: iterators _First and _Last in call of std::copy (see above) are always not equal (members 'm_bnext' and 'm_bend' are always non-zero and comparation of these iterators in this case are return always 'false') and we have access violation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1488660&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Test: please ignore
by Douglas Gregor 15 May '06

15 May '06

Please ignore

1 0