March 2002 - Boost-users - lists.stage.boost.cppalliance.org

Association Library?
by rzako23 07 May '02

07 May '02

Are there any generic components in Boost (or elsewhere) for *directly* representing associations between classes? Generalization, composition, aggregation and association are major ideas in the object model. Generalization can be implemented fairly directly in C++ using inheritance. Composition and aggregation can be represented directly in C++ using data members (when the number of parts in each whole is small and fixed), or using STL containers (when the number of parts in each whole is large or variable). But Standard C++ (including the STL) provides no *direct* support for representing associations, i.e., collections of links between objects in two or more classes. (David Papurt makes this point in "Inside the Object Model: The Sensible Use of C++.") For example, the STL does not offer a way to *directly* represent the 1-to-many "Supervises" association from the Manager class to the Employee class. One would like to have links in both directions: forward links forthe employees a manager supervises and a back link to the manager each employee is supervised by. Of course, one could code this all "by hand" using a container of pointers to employees for each manager and a back pointer for each employee. But the implementation details really have little to do with managers and employees and would be pretty much the same for parents and children or teachers and students. Moreover, while not difficult, managing the forward and back links correctly (and in an exception-safe manner) is tedious. It would be nice to have templates that can be instantiated to implement specific associations. In brief, STL containers directly support composition and aggregation but not association. I am new to the Boost library, but was not able to find this capability in Boost. If an association library is available in Boost (or elsewhere), I would be happy to know so. If not, is an association library something that would be worth looking into? Thanks, Rob Zako

11 24

Detect derivation from e.g. addable
by whastingsnj 10 Apr '02

10 Apr '02

Is there a way to detect that a class has been derived from boost::addable<T>, for example? I would like to be able to write something like this: template <typename T> void foo() { //if T derived from boost::addable<T,...> // . . . } The problem, of course, is the base class chaining feature. I do not see how to use boost::is_base_and_derived in this case.

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