- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-952335 ] Build Boost.Python from minwg gcc
by SourceForge.net 12 May '04

12 May '04

Bugs item #952335, was opened at 2004-05-12 11:21 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=952335&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: Build Boost.Python from minwg gcc Initial Comment: I try compile Boost.Python from minwg, and i recive compile error. Boost: CVS HEAD 2004-05-12 Os: WinXP Compiler: gcc (GCC) 3.2.3 (mingw special 20030504-1) (MinGW-3.1.0-1.exe) bjam: Boost.Jam Version 3.1.9. OS=NT. command line: c:>boost\libs\python\build>bjam -sTOOLS=mingw - sPYTHON_ROOT=C:/Lang/Python23 - sPYTHON_VERSION=2.3 Full output in attached file. Some output lines: gcc-C++- action ..\..\..\bin\boost\libs\python\build\boost_python.dl l\mingw\release\slice.obj In file included from C:/Lang/sf.net/boost/libs/python/src/slice.cpp:1: C:/Lang/sf.net/boost/boost/python/slice.hpp:29: warning: `dllexport' attribute ignored C:/Lang/sf.net/boost/boost/python/slice.hpp:29: declaration does not declare anything C:/Lang/sf.net/boost/boost/python/slice.hpp:29: parse error before `)' token C:/Lang/sf.net/boost/libs/python/src/slice.cpp:18: prototype for ` boost::python::slice::slice()' does not match any in class ` boost::python::slice' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=952335&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

changing aCC-Link-action
by DY, JERRY U (SBCSI) 11 May '04

11 May '04

I would like to add options to the compile and link line used for building the threads library. I have added as follows but not sure if it's the proper place for it. With these changes, I'm able to cleanly compile and build the threads shared lib using aC++ 3.55 compiler. Credit to the HP aC++ team for their help on hpux.hpp changes. boost_1_31_0/tools/build/v1/acc-tools.jam:105 $(acc.bin-directory)$(CXX) -AA -mt +z -w -c +W823 -I$(BOOST_ROOT) -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDR S)" -I"$(STDHDRS)" -o "$(<)" "$(>)" boost_1_31_0/tools/build/v1/acc-tools.jam:82 $(acc.bin-directory)$(CXX) $(LINKFLAGS) -AA -mt -b -o "$(<[1])" -L$(LIBPATH) -L$(STDLIBPATH) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" -l$(FINDLIBS) boost_1_31_0/boost/config/platform/hpux.hpp:63 #define BOOST_HAS_PTHREADS -Jerry

2 1

serialization/shared_ptr load memory leak.
by Jeff Flinn 11 May '04

11 May '04

Ok, I've determined that the memory leak I was seeing is real, atleast in vc7.1. The boost::detail::sp_counted_base_impl<P,D> held by a serialization loaded shared_ptr never gets deleted. This is due to boost::serialization::load_construct_data setting weak_count to 0. When the sp_counted_base::weak_release() gets called new_weak_count is -1 so destruct is not called. A fix that works for my application, is to comment out the line: shared_ptr_access::weak_count(*t) = 0; in template<class Archive, class P, class D> inline void load_construct_data( Archive & ar, boost::detail::sp_counted_base_impl<P, D> * t, const unsigned int /* file_version */ The following was used to reproduce the problem in vc7.1. // SerializationSharedPtrTest.cpp : Defines the entry point for the console application. // #define CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> struct Checker { Checker() { _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_CHECK_ALWAYS_DF | _CRTDBG_LEAK_CHECK_DF ); } }; Checker lChecker; #include <boost/serialization/shared_ptr.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <fstream> typedef std::string tName; class PointedToClass { int mInt; friend class boost::serialization::access; template< class Archive > void serialize( Archive &ar, unsigned int version ) { ar & boost::serialization::make_nvp( "Int", mInt ); } public: ~PointedToClass(){} PointedToClass():mInt(123){} PointedToClass( int aInt ):mInt( aInt){} PointedToClass( const PointedToClass& aRhs ):mInt(aRhs.mInt){} }; typedef boost::shared_ptr< PointedToClass > tPtr; int main( int argc, char* argv[] ) { { std::ofstream lOut( "SomeClass.archive", std::ios_base::out | std::ios_base::trunc ); if( lOut.good() ) { boost::archive::text_oarchive oa( lOut ); tPtr lPtr( new PointedToClass(456) ); oa << boost::serialization::make_nvp( "Ptr" , lPtr ); } } { std::ifstream lIn( "SomeClass.archive" ); tPtr lPtr; if( lIn.good() ) { boost::archive::text_iarchive ia( lIn ); ia >> boost::serialization::make_nvp( "Ptr" , lPtr ); } } return 0; }

1 0

RE: [boost] Re: Request for small test in VC7.1
by Ferdinand Prantl 11 May '04

11 May '04

> From: Joaquín Ma López Munoz [mailto:joaquin@tid.es] > > Maxim Yegorushkin ha escrito: > > > JOAQUIN LOPEZ MU?Z wrote: > > > > > I'd appreciate if someone on the list could try the following in > > > VC7.1 and report the results: > > > > [] > > > > If you have a Windows machine you can try it yourself as > Microsoft has > > released free Visual C++ 2003 Toolkit - > > http://msdn.microsoft.com/visualc/vctoolkit2003/ > > > > Ummm... do you know whether it clashes with a preexisting > VC++ 6.0 installation? (that I don't want to loose). Nope; I have all VC++ 6.0, 7.0, 7.1 and 8.0-preview on a one machine happily working (installed in this order: 7.0, 6.0, 7.1, 8.0). I did not register them in the environment (INCLUDE, LIB, ...) and use vcvars32 in a command-line to build. Ferda > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo

1 0

[filesystem] directory iterator operator++ patch
by Vladimir Prus 11 May '04

11 May '04

Beman, the attached patch enables the operator++(int) in directory_iterator. To summarize our discussion with Dave: 1. New single pass iterator requirements did not meants to outlaw returning proxy from operator++(int) 2. Even if proxy is automatically generated by iterator_facade, this might take some time to be implemented. In fact, I no longer believe it's really desired. So, implementing operator++(int) is directory_iterator makes sense. The attached patch basically uncomments your code, adds one using declaration to bring preincrement operator++ into the scope and changes the tests. Okay to commit? - Volodya

1 0

Metacomm BoostBook-generated documentation not updated?
by Douglas Gregor 11 May '04

11 May '04

It looks like the Metacomm BoostBook documentation hasn't been regenerated in a few days. Is there a problem of some sort? Doug

2 1

Boost Array Documentation
by Stephan T. Lavavej 11 May '04

11 May '04

See http://boost.org/doc/html/array.issues.html : g++ 3.3.3 accepts array<int, 5> a = { 0, 1, 2, 3, 4 }; without complaint when using -Wall -W. Assuming that other modern compilers do too, then this Open Issue should be removed, and the documentation updated accordingly. (Also, the Lambda Doc Bug I pointed out has not yet been addressed; see http://lists.boost.org/MailArchives/boost/msg64450.php .) Stephan T. Lavavej http://nuwen.net

1 0

typeof
by Arkadiy Vertleyb 10 May '04

10 May '04

Hello everybody, A couple of weeks ago I initiated the discussion about simple typeof emulation, and provided an example on how it can be done with the help of MPL vector of integral constants. I then used MS-specific __COUNTER__ macro to spare the user from specifying the unique integer for each registered class/template. I hoped to find a way to do something similar in standard C++, and asked preprocessor experts for help. Indeed, Paul Mensonides suggested such a way. At first I thought that it will not be good enough replacement for the __COUNTER__, but then I realized that I was wrong. So I re-worked my implementation of typeof, and now offerring it to your attention. Besides removing __COUNTER__, I used the Boost.Preprocessor library to cleanup the implementation. Also, after the discussion with Jody Hagins, I put the encoding/decoding classes inside anonimous namespace to avoid collisions between translation units. The provided example shows what registration needs to be done to calculate the type of a lambda functor: #include BOOST_TYPEOF_BEGIN_REGISTRATION() BOOST_TYPEOF_REGISTER_TEMPLATE(tuples::tuple, 2); BOOST_TYPEOF_REGISTER_TEMPLATE(lambda_functor, 1); BOOST_TYPEOF_REGISTER_TEMPLATE(lambda_functor_base, 2); BOOST_TYPEOF_REGISTER_TEMPLATE(relational_action, 1); BOOST_TYPEOF_REGISTER_TEMPLATE(logical_action, 1); BOOST_TYPEOF_REGISTER_TYPE(greater_action); BOOST_TYPEOF_REGISTER_TYPE(less_action); BOOST_TYPEOF_REGISTER_TYPE(and_action); BOOST_TYPEOF_REGISTER_TYPE(placeholder<1>); BOOST_TYPEOF_REGISTER_TYPE(placeholder<2>); #include BOOST_TYPEOF_END_REGISTRATION() main() { BOOST_TYPEOF_ALLOCATE(fun, _1 > 15 && _2 < 20); // <unspecified> fun(_1 > 15 && _2 < 20); int n = 19; assert(fun(n, n)); } One of remaining problems is inability to process top-level consts and references, that get eatten up at the function level, before the partial template specialization gets involved... Although I believe that I don't do anything non-standard now, unfortunately I can't prove it myself. The only compiler I have besides MSVC is GCC, and it gives me "sorry not implemented" on something as simple as mpl::int_<sizeof(foo(...))>... Besides, GCC already has a typeof. Would anybody be so kind as to try the "typeof" with some other compiler? I would really apprciate this... Here is the link: http://groups.yahoo.com/group/boost/files/typeof.zip Any comments are greatly appreciated. Thanks, Arkadiy

10 39

RE: [boost] Re: static sized strings
by Reece Dunn 10 May '04

10 May '04

John Nagle wrote: > There are fundamental issues with string size that have to be >resolved. > > STL strings are variable-sized, with no limit. When you >add characters, "size()" increases. Should fixed-size >strings be similar? If the STL string operations are >to be meaningful, they have to be. The way I see it, size() relates to the current size of the string, and capacity() relates to the current storage size, thus you have: -- null-terminated, fixed size (char_string< n > s) size() = strlen( s.c_str()); capacity() = n; string manipulations guaranteed such that size() < capacity() in order to cope with null character null character is always added fixed size (fixed_string< n > s) size() = capacity() = n; > In STL strings, "size" doesn't include a trailing null. >Using "c_str" can result in expanding the string to add a >trailing null. With fixed-size strings, we don't have that >option. size() will not include the trailing null; c_str() will return the character buffer; null character is added by the string operations, thus there is no need to add it on the c_str() operation. > If c_str is provided, there must always be space >for a trailing null. So you can't use char_string >when you need a specific fixed length, as for Macintosh >4-character file signatures. Perhaps "boost::array<char>" >is the way to go for that sort of thing. Trying to do >both null-terminated and non-null-terminated strings >in the same class will get ugly. I don't think it will be that ugly. In a previous post that contained the updated char_string class, I had an implementation of it as a boolean template parameter (null-terminate). > Top priority, I think, is a size policy. Do you mean how to handle size() and capacity()? If so, see above. > Is Dunn's version in the Boost sandbox? Where? I have not yet added it to the sandbox, but will in the next few days. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

c.l.c++.m post
by David Abrahams 10 May '04

10 May '04

Hi, The enclosed post showed up on c.l.c++.m; AFAICT it has little or nothing to do with MPL, but it does contain several boost-related issues. The best answer isn't really clear to me; we could detect dereferenceability, use a hack involving get_pointer, or maybe something else would be appropriate. Would anyone like to tackle this one? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1