- Boost - lists.boost.org

Graph_traits and Graph
by Jannel Rémi 02 Feb '05

02 Feb '05

Hello All, I started to use boost a few weeks ago and i still have got some problems with the graph_traits theory. In fact, it seems that you use a graph_traits to stock the type of the data used for the Graph (given as a template) such as vertex_descriptor or in_edge iterator. To keep this you use something like: typedef typename Graph::vertex_descriptor vertex_descriptor; which means that you get this type from Graph::vertex_descriptor. Now, if i want to wite an algorithm which will search for all the vertices for example, i'll have to use my Graph as a template and i'll get the vertex type for example using typedef typename graph_traits<Graph>::vertex_descriptor vertex_descriptor; That's why I wanted to ask you why this method is used instead of just typedef typename Graph::vertex_descriptor vertex_descriptor; used in the class graph_traits definition. I hope i made me understandable! Thanks a lot Koopajah

2 1

[Boost-bugs] [ boost-Bugs-1114732 ] boost 1.32 compile error with STLPort462 and boost/format
by SourceForge.net 02 Feb '05

02 Feb '05

Bugs item #1114732, was opened at 2005-02-02 13:37 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=1114732&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Glen Summers (glensummers) Assigned to: Nobody/Anonymous (nobody) Summary: boost 1.32 compile error with STLPort462 and boost/format Initial Comment: compile error using MSVC 7.1 STLPort4.6.2 Boost 1.32.0 Code: #include <iostream> #include <tchar.h> #include <boost/format.hpp> int _tmain(int argc, _TCHAR* argv[]) { return 0; } Fails with: \boost\format\format_implementation.hpp(216) : error C2244: 'boost::basic_format<Ch,Tr,Alloc>::size' : unable to match function definition to an existing declaration \boost\format\format_class.hpp(58) : see declaration of 'boost::basic_format<Ch,Tr,Alloc>::size' definition 'basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' existing declarations 'boost::basic_format<Ch,Tr,Alloc>::size_type boost::basic_format<Ch,Tr,Alloc>::size(void) const' Worked with boost 1.31.0 Regards, Glen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1114732&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Regression tests completely broken?
by Caleb Epstein 02 Feb '05

02 Feb '05

I reported an error yesterday that I thought stemmed from my trying to use a toolset variant. I changed my regression.py run to use the "stock" toolsets and I'm still getting an identical error (though now with the stock toolset name "sunpro"). Nothing is being built and no tests are being run as a result: http://article.gmane.org/gmane.comp.lib.boost.build/8071 -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

Status of BOOST_ASSERT?
by Beman Dawes 02 Feb '05

02 Feb '05

BOOST_ASSERT is documented at http://www.boost.org/libs/utility/assert.html, but it isn't mentioned or linked to in the library index, programmers guidelines, or utility index. If Boost libraries are really supposed to use BOOST_ASSERT, seems like we need to better integrate it into our docs by mentioning it and linking to its docs on the above pages. I looked at the archives a bit, but didn't see any definitive answer as to whether or not we had decided to use BOOST_ASSERT rather than plain assert. Comments? --Beman

3 2

[spirit][phoenix] operator[] hack for std::map
by Ronald Garcia 02 Feb '05

02 Feb '05

Howdy, I've been working on a parser in Spirit that uses Phoenix and came across an item that I needed to support: operator[] on std::map. Perhaps I overlooked this feature somewhere, but based on the code in operators.hpp, I crafted the following code for myself: namespace phoenix { // Workaround: std::map::operator[] uses a different return type than all // other standard containers. Phoenix doesn't account for that. template <typename TK, typename T0, typename T1> struct binary_operator<index_op, std::map<TK,T0>, T1> { typedef typename std::map<TK,T0>::mapped_type& result_type; static result_type eval(std::map<TK,T0>& container, T1 const& index) { return container[index]; } }; } // namespace phoenix I suspect that it would need generalizing to be added to Phoenix as it comes with Spirit, but I thought that it would be useful to alert others of the desire for this feature, if not supply a full implementation (I really don't have the time :( ). Cheers, ron

3 2

Re:[probing interest]AssocVector (and other parts of Loki)
by ION_G_M 02 Feb '05

02 Feb '05

>Since there are people working on a, b, d and e, I would like to ask >the following questions: >0) Are you interested in adding AssocVector to Boost? >(there seems to be at least _some_ interest[1]) Yes I would be, since I'm using it in Boost Shmem. >1) Is there interest in additional interfaces(set, multiset, multimap) >described in [1] or is std::map-like container enough? I would see this also very useful, since associative containers are normally developed as a single underlying class that can be, via traits, converted into multi* or *map/set. Since assoc_vector or the new container family will be based on a vector implementation, I would suggest providing a common vector-like class that uses the following: -> No raw pointers. Uses allocator::pointer instead -> No placement news or destructors. Uses allocator::construct/destroy -> To sum up: all memory operations done using allocator interface so that for example, can be used in shared memory using relative pointers. While doing some tests, I was able to modify slightly yasli_vector to provide this (allocator/pointer) != (new(ptr)/T*) approach. Maybe it could be a good start point. For a modified SGI vector implementation using this approach, please see shmem_vector in Boost Shmem library in Files Section. shmem_assoc_vector is basically the same as Loki AssocVector. If this vector is also developed for Boost to construct the AssocVector/flat_associative containers, I would be glad to drop the shmem_vector and shmem_assoc_vector classes from Boost Shmem, since they only modify SGI implementations to use the generic allocator approach. I would also point out that apart from set/map operations, the new family should have reserve/capacity methods to optimize memory usage and avoid reallocations if the user knows the number of elements to insert. Just a call to vector::reserve/capacity I've been also talking with Daniel James, who is responsible of Boost unordered associative family and he is also generously using this allocator::pointer/construct/destroy generic approach, so we will be able to use boost unordered family in shared memory, mapped in different base addresses, using relative smart pointers. Best regards, Ion

1 0

Extension Classes and the BIL
by christopher diggins 02 Feb '05

02 Feb '05

I notice that member functions for many classes can be divided up into a minimal set, and derivable functions. For instance: class MyClass { void Fu() { cout << "fu"; } void Bar() { cout << "bar"; } void FuBar() { Fu(); Bar(); } } Clearly a minimal interface for representing FuBar would be: BOOST_IDL_BEGIN(IMyInterface) BOOST_IDL_FN0(Fu, void) BOOST_IDL_FN1(Bar, void) BOOST_IDL_END(IMyInterface) Using IMyInterface in our code instead of IMyInterface is more generic, and reduces coupling, but we lose the syntactic pleasantries of FuBar(). In order to achieve this effect I am currently using an extension class (or veneer if you prefer): template<typename Base_T> class MyClass_ext : public Base_T { MyClass_ext() : T() { }; template<typename T> MyClass_ext(const T& x) : T(x) { }; void FuBar() { T::Fu(); T::Bar(); } // ... assignment operators etc. } I can then write a new extended interface as follows: typedef MyClass_ext<IMyInterface> IMyInterface2; And of course I would also rewrite the original class, to avoid code redundancy: class MyClass_base { void Fu() { cout << "fu"; } void Bar() { cout << "bar"; } } typedef MyClass_ext<MyClass_base> MyClass; I don't how solid this technique is for real code. My terminology and naming convention also leaves me disatisfied. Any comments or suggestions? Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0

RE: [boost] More on Serialization Link Issue
by Jared McIntyre 02 Feb '05

02 Feb '05

> This is almost surely an issue of the library build settings out of sync > with the program build settings. The included VC7 IDE projects might be out > of sync with the bjam builds. here are some other things to try > > a) from with in the serialization/test directory, invoke the batch file with > the argument vc-7_1 . This should build all the libraries, demos and tests > for the serialization libary with a consistent set of settings. > b) If the above works, move the libraries from where they are build > boostdir/bin/... etc to you favorite local spot and alter thid IDE projects > to point to them. > c) Note that I have found that the IDE projects with the VC 7.1 IDE often > report a non-sensical error when I try to bring them up. This can be fixed > by going to the build menu item and selecting configuration setup and > explictly selectinga configureuation. The problem then goes away for a > while. Its an VC IDE thing. I built out everything in test as suggested (there were a few that failed, but don't appear to be related). I then took the library built in libs\serialization\build\libboost_serialization.lib\vc-7_1\debug\threading-multi and moved it to my build location. I ended up getting the same failure. To make sure that my build was picking up the library at link, I added it as a resource to the project, and it continued to have the failure (so I'm sure my project is linking to the library). Is there any more information I could give you about my setup that might help? Jared

2 1

Re: [boost] Status of BOOST_ASSERT?
by JOAQUIN LOPEZ MU?Z 01 Feb '05

01 Feb '05

----- Mensaje original ----- De: Beman Dawes <bdawes(a)acm.org> Fecha: Martes, Febrero 1, 2005 11:36 pm Asunto: [boost] Status of BOOST_ASSERT? > BOOST_ASSERT is documented at > http://www.boost.org/libs/utility/assert.html, but it isn't > mentioned or > linked to in the library index, programmers guidelines, or utility > index. > If Boost libraries are really supposed to use BOOST_ASSERT, seems > like we > need to better integrate it into our docs by mentioning it and > linking to > its docs on the above pages. The utility section is kinda messed up. Some utilities like enable_if are included by boost/utility.hpp yet they're documented separately. Others, like result_of, are *not* included by boost/utility.hpp, though the docs seem to imply it is. in_place_factory has its own docs, but it lives in boost/utility. compare_pointees seem to be in a limbo, and so does aligned_storage... As for BOOST_ASSERT, I guess there is no objection against using it (at least, I hope there isn't --I'm using it :) It is just that somehow the docs got unlinked. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo > > I looked at the archives a bit, but didn't see any definitive > answer as to > whether or not we had decided to use BOOST_ASSERT rather than > plain assert. > > Comments? > > --Beman > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Threads in xcode
by Benjohn 01 Feb '05

01 Feb '05

We're building a multithreaded OS X application with xcode, that uses cocoa, objective c++, and makes a lot of use of shared_ptr and other parts of Boost. We're currently using boost 1_32_0 (I've just upgraded from boost-1.30.2). We're getting some crashes, and I've started to suspect that <boost/shared_ptr.hpp> isn't being compiled with multithread awareness. Acting on this hunch, if <boost/requires_threads.hpp> is included, it generates the compilation error: "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pthreads (Solaris) or -mthreads (Mingw32)" ...which seems to suggest that shared_ptrs (if they use the same config info) wouldn't be compiling in thread support. Are application also makes use of the pthread API, and cocoa's threads class, and these both seem to be working as expected. We've had a look at xcode's options, but have found no way to explicitly turn on thread support. Specifically, adding -pthread or -pthreads causes the compiler to issue an error. We have also looked for a configure script in the boost distribution, but can find nothing (except for the one in libs/config/ which doesn't seem to work, but I personally think we're using it wrong). If someone could suggest what we may be missing, I'd be terribly grateful. Thanks very much, and thanks for a great library! Cheers, Benjohn

1 0