- Boost - lists.boost.org

Reminder: Boost Logo Contest
by Joel de Guzman 02 Feb '05

02 Feb '05

Hi Y'all, This is to remind you about the ongoing Boost Logo Contest: http://www.boost.org/more/logo_contest.htm Entries will be accepted on or before February 15, 2005. Please email all entries to me (djowel at gmail dot com). I've posted the entries submitted so far in the page above. I decided not to continue with the wiki page because of problems and difficulties with it. Some things to note: 1) I'm limiting the image size to a width of 320 pix. This is for the sake of uniformity. Images that were rescaled to fit this limit might look jagged. If you are not satisfied, please re-submit. 2) Most entries have a title (italics). To those who wish to have a title (optional), please email me. This is optional because each entry has a corresponding number anyway. 3) Some entries have an annotation relating to the artwork. This is also optional but it might help if you annotate your work. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

1 1

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

02 Feb '05

Bugs item #1114831, was opened at 2005-02-02 16:06 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=1114831&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=1114831&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

[serialization]: 1.32/VC7.1:error C2039: 'serialize' : is not a member of 'std::vector<_Ty>'
by Francis ANDRE 02 Feb '05

02 Feb '05

Hi Robert I got the following error from the serialization access.cpp: : Schema.cpp c:\boost\boost\serialization\access.hpp(106) : error C2039: 'serialize' : is not a member of 'std::vector<_Ty>' with [ _Ty=GLOB::SUB::Key ] ... ... For sure, I have doubled checked that the "boost/serialization/vector.hpp" file is well included at the very beginning of Schema.cpp This error appears only with binary archive. With an XML archive, the source Schema.cpp does not produce any error. I am not able to reproduce it on a small case. Is there anyway to trace/or activate an helper that could show up be the underlying problem?? Regards Francis ANDRE

2 2

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