- Boost-users - lists.preview.boost.org

suggestion: harness destructor in scoped_ptr<>::reset
by jlehrer 02 Apr '02

02 Apr '02

Before I propose this to main boost mailing list, I wanted to see what others thought of this idea. I propose changing the following method on scoped_ptr<>: void reset(T* p=0) {if(ptr!=p) {checked_delete(ptr); ptr=p;}} to void reset(T* p=0) {if(ptr!=p) {scoped_ptr<T>(p).swap(*this);}} void swap(scoped_ptr<T>& other) {std::swap(ptr,other.ptr);} Of course, we would then have global methods for std::swap, as there are for the other smart pointers, to map to this method. Finally, the same change should be made to scoped_array<>. shared_ptr<> and shared_array<> already have these semantics. The idea is to harness the destructor of the scoped_ptr in order to delete the pointer, rather than calling checked_delete in two places. This has a few advantages over the old code: 1- destruction is handled in one place, the destructor. This seems natural, and gives developers one place to look to see what happens when a pointer is deleted 2- I have had occasion to specialize the destructor of the scoped_ptr<> class to do something other than delete. In that case, I needed to specialize the destructor AND the reset method. With this change, one would only need to specialize the destructor and reset would harness that specialization as well. Comments?

2 1

Fw: Boost.Threads thread_specific_ptr and more
by Philip Ashmore 02 Apr '02

02 Apr '02

Oops! I didn't know I had to join the group! Regards, Philip Ashmore ----- Original Message ----- From: "Philip Ashmore" <philip_ashmore(a)hotmail.com> To: "William Kempf" <williamkempf(a)hotmail.com> Cc: <Boost-Users(a)yahoogroups.com> Sent: Wednesday, March 20, 2002 12:29 PM Subject: Re: Boost.Threads thread_specific_ptr and more > Hi there. > > Rather than respond to your points directly, I've written a document > outlining my ideas on how static data could be managed more clearly. This > obviously relates to thread_specific_ptr as instances are global, hence > static, but is quite general and therefore hopefully more useful. > > Regards, > Philip Ashmore. > ----- Original Message ----- > From: "William Kempf" <williamkempf(a)hotmail.com> > To: <philip_ashmore(a)hotmail.com> > Sent: Friday, March 15, 2002 3:13 PM > Subject: Re: Boost.Threads thread_specific_ptr and more > > > > >From: "Philip Ashmore" <philip_ashmore(a)hotmail.com> > > >To: <williamkempf(a)hotmail.com> > > >Subject: Boost.Threads thread_specific_ptr and more > > >Date: Fri, 15 Mar 2002 14:37:39 -0000 > > > > > >Hi there. > > > > > >first of all, I'm assuming that it's appropriate to contact you directly > regarding some queries I have regarding the Boost.Threads > thread_specific_ptr<T>. > > > > Yes, though if you'd send it to the Boost Users list on Yahoo Groups > (Boost-Users(a)yahoogroups.com) instead others could benefit from the answer > as well. > > > > >As it happens I developed something similar before I became aware of > Boost.Threads thread_specific_ptr<T>, but with the following extra features > you might consider discussing or adding. > > > > > >1. Automatic construction of new instances of T as needed when > dereferenced. > > > > I considered this and rejected it, mostly because this behavior may be > surprising to users. Another issue is that this would require T to be > default constructable, which will limit the usefulness at least somewhat. > > > > >2. Assignment to thread_specific_ptr<T> of a local variable of type T. > This is basically already there with reset() but an explicit template class > could handle connection and disconnection, coping with exceptions. > > > > Could you elaborate? I'm not sure I understand why you think an > assignment operator would be better then reset(). > > > > >3. An optional Structor class template argument. Here the Structor would > know how to create and destroy instances of T, useful when T can be used in > different contexts. > > > > This sounds like an Allocator, and if it wasn't a standard Allocator then > it could be used to eliminate one of the problems I referred to in (1), but > beyond this I don't see any benefit. > > > > >4. Automatic cleanup of instances of T when the thread_specific_ptr<T> > goes out of scope. These would be useful when you aren't in control of the > thread creation or destruction. > > > > To be portable, thread_specific_ptr<> must be used only to instantiate > global variables (or the equivalent static variants). So, this one can't be > done (or more specifically adds 0 benefit). > > > > > This relates to static instance management. As you may know, some > compilers (or maybe it's C++ itself) have problems if you have static > instances of classes that have non-trivial static data members. The idiom of > clients and managers is one solution - manager lifetimes enclose client > lifetimes. I've implemented this and it works. > > > > I'm not sure that I'm aware of the problem you're alluding to. Can you > elaborate? > > > > >A more general idiom is a dependency tree, where wrapper objects declare > their dependency explicitly and a functor tree is created that is > independent of the order of static construction (a map would work here). > This tree is traversed during start-up and shutdown (using a scoping object) > to ensure correct instantiation and destruction. > > > > Are you referring to issues with the order of construction/destruction for > global data? If you are, there is no universal solution to this problem and > I'm not about to try and address it. > > > > >It takes over work that the compiler should do correctly but doesn't (at > least not on Visual C++ 6.0 sp5). > > >This would effectively solve all > static-object-dependency-across-libraries issues in a portable way. > > >Maybe this merits a file of its own in Boost.Utility. What do you think? > > > > I think I need more explanation and possibly code examples. > > > > Bill Kempf > > williamkempf(a)hotmail.com > > > > > [Non-text portions of this message have been removed]

2 2

How to build boost to get proper boost::regex configuration?
by rnicz 01 Apr '02

01 Apr '02

I've build boost on Windows NT4.0 with following settings: JAM_TOOLSET=VISUALC TOOLS=msvc and until now everything works fine. But when I tried to use boost::regex library I found that I got wrong libraries: I got libboost_regex.lib in four directories: 1) libs\regex\build\bin\libboost_regex.dll\msvc\debug 2) libs\regex\build\bin\libboost_regex.dll\msvc\release 3) libs\regex\build\bin\libboost_regex.lib\msvc\debug\runtime-link- dynamic 4) libs\regex\build\bin\libboost_regex.lib\msvc\debug\runtime-link- dynamic but now when I try to use boost::regex library file regex_library_include.hpp forecs linking against library with name like vc6-re300l.lib. Is there a way to get proper libraries when boost is built or to force compiler to use libboost_regex.lib during linking? Thank you in advance. Best regards Ryszard Niewisiewicz

3 5

Unable to compile boost_1_27_0 with Visual C++ .net - MORE...
by deep_thought_or_not 31 Mar '02

31 Mar '02

BTW I also had to update the Jamrules for msvc, such that I had to change the prog names "cl", "link" to "cl.exe" and "link.exe" respectively. For some reason, I have to specify the extension to run a program. Does not work without it. I am NOT doing this through a cygwin shell.

1 0

Unable to compile boost_1_27_0 with Visual C++ .net
by deep_thought_or_not 31 Mar '02

31 Mar '02

C:\downloads\boostlib\boost_1_27_0\libs\graph\build>jam.exe - sBOOST_ROOT=..\..\. . -sTOOLS="msvc" ...found 151 targets... ...updating 4 targets... msvc-C++-action ..\..\..\libs\graph\build\bin\libbgl- viz\msvc\debug\inlining-on\ runtime-link-dynamic\graphviz_graph_parser.obj graphviz_graph_parser.cpp ..\..\..\boost\type_traits\composite_traits.hpp(155) : fatal error C1001: INTERN AL COMPILER ERROR (compiler file 'msc1.cpp', line 2844) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information cl.exe /Zm750 -nologo -GX -c /Zi /Od /Ob1 /GX /GR /MDd - I"..\..\..\libs \graph\build" -I"." -I"..\..\.." -I"C:\Program\include" - I"Files\Microsoft\incl ude" -I"Visual\include" -I"Studio\include" -I".NET\VC7\include" - Fo"..\..\..\li bs\graph\build\bin\libbgl-viz\msvc\debug\inlining-on\runtime-link- dynamic\graphv iz_graph_parser.obj" -Tp"../src\graphviz_graph_parser.cpp" ...failed msvc-C++-action ..\..\..\libs\graph\build\bin\libbgl- viz\msvc\debug\in lining-on\runtime-link-dynamic\graphviz_graph_parser.obj ... msvc-C++-action ..\..\..\libs\graph\build\bin\libbgl- viz\msvc\debug\inlining-on\

1 0

Re: [Boost-Users] AmigaOS port of Boost 1.27.0
by Steven Solie 30 Mar '02

30 Mar '02

[My first attempt at replying seems to have failed... Try #2] > > #define BOOST_DISABLE_THREADS > > The BOOST_DISABLE_THREADS define shouldn't be set for a platform. If the > platform doesn't have threads, we just don't define BOOST_HAS_THREADS > for that platform. So you shouldn't need this line. If you do need it, > can you explain why? I set it because in the "User settable options" section it implies I should probably do that. AmigaOS doesn't support native multithreading but the GCC compiler might assume it does. I was just playing it safe. > > #define BOOST_NO_CWCHAR > > #define BOOST_NO_CWCTYPE > > #define BOOST_NO_SWPRINTF > > You only have to define BOOST_NO_CWCHAR. If it's defined, > BOOST_NO_CWCTYPE and BOOST_NO_SWPRINTF are both defined for you by > suffix.hpp. This should be in the documentation, but perhaps it's not. I was just going through the "Boost Macro Reference" and picking off the macros I thought applied. AmigaOS doesn't support wide characters (yet). I didn't see any docs saying they are related to each other. > > #define BOOST_NO_INTRINSIC_WCHAR_T > > This is usually a property of the compiler, not the platform, and so > it's the responsibility of the boost/config/compiler/xxx.hpp file to set > this. But I see that you're using GCC 2.95.3. I think that GCC 2.95.3 > does have an intrinsic wchar_t. What's going on here. The boost/integer_traits.hpp file spit out the error "No WCHAR_MIN and WCHAR_MAX present, please adjust integer_traits<> for your compiler." when I tried to compile the graph library regression test suite. I suspect the AmigaOS port of GCC 2.95.3 has turned off intrinsic wchar_t for some reason. I'll post a question to the Amiga GCC mailing list and see if anyone there knows anything about this. > > 3) libs/graph/test/isomorphism.cpp > > > > - inline bool verify_isomorphism(const Graph1& g1, const Graph2& g2, > > I'm not sure why you removed this function template. It's used in > test_isomorphism below. Could you elaborate? The function template is already defined in boost/graph/isomorphism.hpp. I suspect somebody has made a cut & paste error... > > + #include <cassert> > > Since <cassert> and <assert.h> are identical and some platforms lack > <cassert> we might want to use <assert.h> here even though it's a > deprecated feature. There are currently 25 files that use <cassert> and 3 files that use <assert.h>. Therefore, I think <cassert> is safe to use. You might want to hunt down those remaining <assert.h> includes and change them to <cassert> as well. NOTE: I used a simple grep to find this out so my numbers may not be 100% correct. Cheers, --Steven

3 2

linking with boost.threads on solaris 8 with gcc 3.0.3
by Dale Peakall 30 Mar '02

30 Mar '02

gcc version: 3.0.3 - thread model: posix ld version: GNU ld 2.11.2 (with BFD 2.11.2) boost: 1.27.0 I've applied the unclosed extern "C" fix to once.cpp, removed the unsupported -pthread option from gcc-tools.jam, and built the thread library using jam with no errors. Has anyone compiled anything using this environment that uses boost.threads? A v.simple (completely pointless) test fails for me: #include <exception> #include <iostream> #include <boost/thread/mutex.hpp> int main(int argc, char* argv[]) { try { boost::mutex m; boost::mutex::scoped_lock l(m); } catch(std::exception const& e) { std::cerr << "error: " << e.what() << "\n"; return 1; } } g++ -c -g -I/home/peakalld/boost_1_27_0 main.cpp g++ -o thread_test -L/home/peakalld/boost_1_27_0/libs/thread/build/bin/libboost_thr ead/gcc/debug/runtime-link-dynamic -lboost_thread -lpthread -lposix4 main.o main.o: In function `main': /home/peakalld/development/thread_test/main.cpp:10: undefined reference to `boost::mutex::mutex()' /home/peakalld/development/thread_test/main.cpp:11: undefined reference to `boost::mutex::~mutex()' /home/peakalld/development/thread_test/main.cpp:11: undefined reference to `boost::mutex::~mutex()' main.o: In function `boost::lock_error::~lock_error()': /home/peakalld/boost_1_27_0/boost/thread/detail/lock.hpp(.gnu.linkonce.t._ZN 5boost6detail6thread11scoped_lockINS_5mutexEE4lockEv+0x24): undefined reference to `boost::lock_error::lock_error()' /home/peakalld/boost_1_27_0/boost/thread/detail/lock.hpp(.gnu.linkonce.t._ZN 5boost6detail6thread11scoped_lockINS_5mutexEE6unlockEv+0x24): undefined reference to `boost::lock_error::lock_error()' /home/peakalld/boost_1_27_0/boost/thread/detail/lock.hpp(.gnu.linkonce.t._ZN 5boost6detail6thread8lock_opsINS_5mutexEE4lockERS3_+0x8): undefined reference to `boost::mutex::do_lock()' /home/peakalld/boost_1_27_0/boost/thread/detail/lock.hpp(.gnu.linkonce.t._ZN 5boost6detail6thread8lock_opsINS_5mutexEE6unlockERS3_+0x8): undefined reference to `boost::mutex::do_unlock()' collect2: ld returned 1 exit status make: *** [all] Error 1 Any thoughts appreciated. - Dale.

4 10

g++ error while compiling boost program on Dec Alpha (fwd)
by Jun Aishima 29 Mar '02

29 Mar '02

I got the following error while compiling a program using the boost graph library on a Dec Alpha, using g++ 3.0.3: mips-tfile, /tmp/ccC6RDPL.s:1457 String too big (4138 bytes) line: #.stabs "__comp_ctor::9664:_ZN5boost7details19compressed_pair_impISt17__normal_iteratorIPNS_6detail4sei_ImSt14_List_iteratorINS_9list_edgeImNS_8propertyINS_13edge_weight_tEdNS_11no_propertyEEEEERSB_PSB_ESA_EESt6vectorISF_SaISF_EEENS3_5oeip_ImEELi0EEC1ERKSK_RKSM_;2A.;__base_ctor::9665=#9657,24,9660,9348,24;:_ZN5boost7details19compressed_pair_impISt17__normal_iteratorIPNS_6detail4sei_ImSt14_List_iteratorINS_9list_edgeImNS_8propertyINS_13edge_weight_tEdNS_11no_propertyEEEEERSB_PSB_ESA_EESt6vectorISF_SaISF_EEENS3_5oeip_ImEELi0EEC2ERKSK_;2A.;__comp_ctor::9665:_ZN5boost7details19compressed_pair_impISt17__normal_iteratorIPNS_6detail4sei_ImSt14_List_iteratorINS_9list_edgeImNS_8propertyINS_13edge_weight_tEdNS_11no_propertyEEEEERSB_PSB_ESA_EESt6vectorISF_SaISF_EEENS3_5oeip_ImEELi0EEC1ERKSK_;2A.;__base_ctor::9666=#9657,24,9660,8435,24;:_ZN5boost7details19compressed_pair_impISt17__normal_iteratorIPNS_6detail4sei_ImSt14_List_iteratorINS_9list_edgeImNS_8propertyINS_13edge_weight_tEdNS_11no_proper! tyEEEEERSB_PSB_ESA_EESt6vectorISF_SaISF_EEENS3_5oeip_ImEELi0EEC2ERKSM_;2A.;__comp_ctor::9666:_ZN5boost7details19compressed_pair_impISt17__normal_iteratorIPNS_6detail4sei_ImSt14_List_iteratorINS_9list_edgeImNS_8propertyINS_13edge_weight_tEdNS_11no_propertyEEEEERSB_PSB_ESA_EESt6vectorISF_SaISF_EEENS3_5oeip_ImEELi0EEC1ERKSM_;2A.;first::9667=#9657,9346,9660,24;:_ZN5boost7details19compressed_pair_impISt17__normal_iteratorIPNS_6detail4sei_ImSt14_List_iteratorINS_9list_edgeImNS_8propertyINS_13edge_weight_tEdNS_11no_propertyEEEEERSB_PSB_ESA_EESt6vectorISF_SaISF_EEENS3_5oeip_ImEELi0EE5firstEv;2A.9668=#9657,9348,9669=*9657,24;:_ZNK5boost7details19compressed_pair_impISt17__normal_iteratorIPNS_6detail4sei_ImSt14_List_iteratorINS_9list_edgeImNS_8propertyINS_13edge_weight_tEdNS_11no_propertyEEEEERSB_PSB_ESA_EESt6vectorISF_SaISF_EEENS3_5oeip_ImEELi0EE5firstEv;2B.;second::9670=#9657,8433,9660,24;:_ZN5boost7details19compressed_pair_impISt17__normal_iteratorIPNS_6detail4sei_ImSt14_List_iterat! orINS_9list_edgeImNS_8propertyINS_13edge_weight_tEdNS_11no_pr! opertyEEEEERSB_PSB_ESA_EESt6vectorISF_SaISF_EEENS3_5oeip_ImEELi0EE6secondEv;2A.9671=#9657,8435,9669,24;:_ZNK5boost7details19compressed_pair_impISt17__normal_iteratorIPNS_6detail4sei_ImSt14_List_iteratorINS_9list_edgeImNS_8propertyINS_13edge_weight_tEdNS_11no_propertyEEEEERSB_PSB_ESA_EESt6vectorISF_SaISF_EEENS3_5oeip_ImEELi0EE6secondEv;2B.;swap::9672=#9657,24,9660,9673=&9674=xscompressed_pair<std::__normal_iterator<boost::detail::sei_<long unsigned int, std::_List_iterator<boost::list_edge<long unsigned int, boost::property<boost::edge_weight_t, double, boost::no_property> >, boost::list_edge<long unsigned int, boost::property<boost::edge_weight_t, double, boost::no_property> >&, boost::list_edge<long unsigned int, boost::property<boost::edge_weight_t, double, boost::no_property> >*>, boost::property<boost::edge_weight_t, double, boost::no_property> >*, std::vector<boost::detail::sei_<long unsigned int, std::_List_iterator<boost::list_edge<long unsigned int, boost::property<boost::edge_weight_t, double, boost::no_property> >, boost::list_edge<long unsigned int, boost::property<boost::edge_weight_t, double, boost::no_property> >&, boost::list_edge<long unsigned int, boost::property<boost::edge_weight_t, double, boost::no_property> >*>, boost::property<boost::edge_weight_t, double, boost::no_property> >, std::allocator<boost::detail::sei_<long unsigned int, std::_List_iterator<boost::list_edge<long unsigned int, boost::property<boost::edge_weight_t, double, boost::no_property> >, boost::list_edge<long unsigned int, boost::property<boost::edge_weight_t, double, boost::no_property> >&, boost::list_edge<long unsigned int, boost::property<boost::edge_weight_t, double, boost::no_property> >*>, boost::property<boost::edge_weight_t, double, boost::no_property> > > > >,boost::detail::oeip_<long unsigned int> >:,24;:_ZN5boost7details19compressed_pair_impISt17__normal_iteratorIPNS_6detail4sei_ImSt14_List_iteratorINS_9list_edgeImNS_8propertyINS_13edge_weight_tEdNS_11no_propertyEEEEERSB_PSB_ESA_EESt6vectorISF_SaISF_EEENS3_5oeip_ImEELi0EE4swapERNS_15compressed_pairISK_SM_EE;2A.;;",128,0,71,0 gmake: *** [alpha/debug.o/findbackbone.o] Error 1 Any idea what could be causing this or how this can be fixed? Thanks, Jun Aishima jaishima(a)lbl.gov

1 0

Compiling CRC
by David Brownell 29 Mar '02

29 Mar '02

I have the following code that doesn't compile using VC 7.0. I am getting many errors in crc.hpp. Am I missing something simple here? I have just glanced at the manual, so please be gentle with the RTFM responses :) TIA, David Brownell #include<iostream> #include "boost\crc.hpp" int main(void) { const unsigned char DATA[] = { 1, 2, 3, 4, 5 }; boost::crc_32_type crc; crc.reset(); crc.process_bytes(DATA, sizeof(DATA) / sizeof(*DATA)); std::cout << crc.checksum() << std::endl; return(true); }

1 0

RE: [Boost-Users] boost.bind usage
by Swatosh, Joe R NWP 29 Mar '02

29 Mar '02

> -----Original Message----- > From: markus_schoepflin > > Is it just me or is it my compiler (MSVC6SP5)? The following code > gives me an error. Whats wrong? > > #include <boost/bind.hpp> > #include <functional> > > using boost::bind; > > void main() > { > bind(std::greater<int>, _1, _2)(1, 2); > } > > main.cpp(8) : error C2275: 'std::greater<int>' : illegal use of this > type as an expression > > TIA, Markus I'm no expert, but your compiler is telling you exactly whats wrong: you need to create an object to pass to bind. bind(std::greater<int>(), _1, _2)(1, 2); ^^ Joe Swatosh | mailto:Joe.R.Swatosh@usace.army.mil nLink contract employee | mailto:jswatosh@n-link.net US Army Corps of Engineers | Northwestern Division, Portland District CENWP-HDC-P | Hydroelectric Design Center 220 NW 8th Ave | v:(503) 808-4032 Portland, OR 97209 | f:(503) 808-4029 [Non-text portions of this message have been removed]

1 0