- Boost - lists.boost.org

Google SoC 2007 - Plotting Graphs from C++ Containers in Scalable Vector Graphics (SVG) Format
by Kasun Rodrigo 23 Mar '07

23 Mar '07

Hello, I am a level 4 undergraduate of University of Moratuwa, Sri Lanka, following a Computer Science & Engineering Major. I'm very much interested in the above project idea. I have already developed a 2D and 3D graph plotting application in Visual Basic. I was dreaming of developing a graph plotting library in C++ that has the similar plotting features like famous application called MATLAB. * 2D plots * 3D plots (Mesh & Surface) * Pie charts, Bar Charts, etc.. * Axis labels, Scale, Grid, Legend * Multiple Graphs on the same figure. (Subplots) I would like to develop the solution in the following way. - Generic SVG library that exposes the primitive operations on SVG DOM - Graph plotting library - Generic plotting interface that exposes high level plotting operations to plot graphs from functions & C++ containers - A specific plotting implementation derived from generic one that uses the SVG library to carry out plotting operations. By doing it in above way I wish to improve the re-usability and theflexibilityof the code. 1. We can re-use the generic SVG library 2. Someone can derive different plotting libraries from generic one and use without changing the client code. (Eg:- Plot to screen, Plot to a document etc..) Can you please comment on above ideas. I'm looking forward for your kind comments. Thanks Kasun

3 4

[Boost-bugs] [ boost-Patches-1686705 ] [thread] thread_specific_ptr::element_type ?
by SourceForge.net 23 Mar '07

23 Mar '07

Patches item #1686705, was opened at 2007-03-23 12:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1686705&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gareth Sylvester-Bradley (gmsb) Assigned to: Nobody/Anonymous (nobody) Summary: [thread] thread_specific_ptr::element_type ? Initial Comment: Would the following patch be useful? --- /boost_1_33_1/boost/thread/tss.hpp 2007-03-23 12:21:33.000000000 +0000 +++ /boost_1_33_1/boost/thread/tss.hpp.patched 2007-03-23 12:21:20.000000000 +0000 @@ -73,6 +73,8 @@ class thread_specific_ptr : private noncopyable { public: + typedef T element_type; + thread_specific_ptr() : m_tss(new boost::function1<void, void*>( boost::detail::tss_adapter<T>( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1686705&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Google SOC 2007, Boost.Test Frontend
by Younes M 23 Mar '07

23 Mar '07

Hi, I recently came across a suggestion for a Boost.Test frontend on the Google Summer of Code 2007 front page. As someone who uses Boost.Test a fair bit I think I would be very interested in persuing this. I have some early ideas about what I would like to see in a frontend, but would also love to get some ideas from others. I've emailed Thorsten Ottosen and he suggested I try here, so here I am. Along with the idea of having the frontend running in the systray and automatically capturing detecting and reporting on any unit tests that are run (as suggested on the Ideas page), I think being shown a list of failures and being jump to one such failure would be very handy. By "jump to" I mean having the source file open up in an editor and possibly even having the editor scroll to/highlight the line in question, or at the very least using a source-view widget in the front-end itself that could perform that function. If anyone has any other suggestions on functionality, information to include in generated reports, user interface, aesthetics, coupling between unit tests and the frontend, coupling between the frontend and editors, or on any other topic, I would love to hear it. Thank you for your time, Younes

13 29

[iostreams regressions] patches to fix msvc issues
by David Deakins 23 Mar '07

23 Mar '07

Since it seems like Jonathan Turkanis is not currently available to work on maintaining the iostreams library, perhaps someone else with CVS write access might apply the attached jamfile patches related to that library to RC_1_34_0 (if the release manager approves) and to HEAD. The description of the patches is below. These, along with the mentioned modification to the bzip2 DEF file, should resolve the remaining iostreams regressions. Once the jamfile patches are applied, I'll ping RudbekAssociates to delete their current test results, since I believe they run the regression tests incrementally and I don't think jamfile changes trigger a rebuild. Thanks, -Dave David Deakins wrote: > Douglas Gregor wrote: >> |iostreams| >> bzip2_test: msvc-7.1 msvc-8.0 >> gzip_test: msvc-7.1 msvc-8.0 >> zlib_test: msvc-7.1 msvc-8.0 >> > > I spent a little bit of time looking into the msvc-7.1 and msvc-8.0 > regressions for this library. It looks like the zlib and bzip2 > libraries used in these tests are being built from source files and it > appears that there are some omissions in the iostreams jamfile for > properly building them as DLLs in Windows. > > For zlib, there just needs to be a <link>shared:<define>ZLIB_DLL in > its build requirements so that the zlib source files use the > __declspec keyword on functions that should be exported. Without > this, no functions are exported and the import library file is not > created (thus the link errors). > > With bzip2, the basic problem is the same but its sources use a .DEF > file rather than __declspec (at least in the 1.0.4 sources that I > looked at). Adding <link>shared:<def-file>$(BZIP2_SOURCE)/libbz2.def > properly included the DEF file that gives the exports, but revealed > another problem. The DEF file has a 'LIBRARY LIBBZ2' line in it which > wants to give the DLL the name libbz2.DLL. Unfortunately the > iostreams jam file typically calls the library something like > boost_bzip2-vc80-mt-gd-1_34.DLL and specifies an /OUT directive to the > linker to ask for this name. At least on my machine with VC8, the > /OUT directive overrides the LIBRARY rule enough to make the intended > boost_bzip2-vc80-mt-gd-1_34.DLL file, but not enough to get this name > into the import .LIB file that boost_iostreams links to. As a result, > the iostreams library will compile and link, but will fail trying > locate libbz2.DLL (instead of the correct > boost_bzip2-vc80-mt-gd-1_34.DLL). The only way I could easily resolve > this was to comment out the LIBRARY rule in the libbz2.DEF file in the > bzip2 sources like so: > > ; LIBRARY LIBBZ2 > > With this change and the patches to the iostreams jamfile, building > zlib and bzip2 from sources works correctly and the 3 tests pass. I > attached a patch for jamfile.v2 in libs\iostream\build with my > changes. It might be good to put a note about the bzip2 .DEF file > change in the iostreams documentation. > > Incidently, using <def-file> revealed a small issue in msvc.jam > related to DEF file paths that have spaces in them. The linker > command does not put quotes around the DEF path like it does with most > of the other parameters, and as a result DEF paths with spaces will > cause the link to fail. I also included a patch to msvc.jam to add > quotes around DEF file paths. > > Thanks, > -Dave >

4 6

[atomic_count] Different behaviour on different platforms
by Hartmut Kaiser 23 Mar '07

23 Mar '07

Hi all, Is there a rational for the different behavior (signature) of the atomic_count::operator++()? This operator returns long (the new value) on Win32 and Solaris, but has no return type (void) on pthread and gcc based systems. Regards Hartmut

2 1

[sorting] Small error in multikey quicksort file
by Sam Schetterer 22 Mar '07

22 Mar '07

I just discovered that all of the functions in mkqsort.hpp are prefixed with callingcov, but at the top of the file, callingcov is accidentally defined as callingconv. When that is fixed, all code will compile nicely. Sorry.

1 0

Re: [boost] Boost.Threads, N2178, N2184, et al
by Emil Dotchevski 22 Mar '07

22 Mar '07

> <snip> > OK. But that doesn't really address my initial point: implementing call_once> in terms of the POSIX pthread_once is a bit pointless if you need to implement> pthread_once separately anyway. If you don't have pthread_once, I would write> call_once (or, equivalently pthread_once2_np), and implement pthread_once in> terms of that. Pthread is a C interface that has been implemented on many platforms already and I don't see why you think anyone would implement it over std::thread. It just won't happen. On the other hand, if a particular platform implements pthread (virtually all do, and we have Windows port of pthread which is a proof of concept at least), implementing the C++ portion of N2178 is a breeze. Pthread is there, standardized, proven in practice, so why not make use of it? In addition, there is a lot of legacy pthread code which N2178 makes compatible with future C++ <thread> based code. I consider both to be Good Things. Emil Dotchevski _________________________________________________________________ It’s tax season, make sure to follow these few simple tips http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.…

4 4

[sorting] Is there still interest?
by Sam Schetterer 22 Mar '07

22 Mar '07

Hi. I am just wondering if there is still interest in the library, because I have not recieved any comments on the library in the last two days, no posts at all, while I have made multiple posts, some with very important ideas in them.

5 8

[utility] result_of and lambda patch
by Daniel Walker 22 Mar '07

22 Mar '07

Hello, I noticed that result_of doesn't handle functors created by the Boost Lambda Library. For example, $ g++ -dumpversion 4.1.2 $ cat result_of_error.cpp #include <boost/lambda/lambda.hpp> #include <boost/utility/result_of.hpp> using namespace boost; template<class Functor, class Arg1, class Arg2> void f(Functor const&, Arg1 const&, Arg2 const&) { typedef typename result_of< Functor(Arg1, Arg2) >::type result_type; } int main() { using namespace lambda; int x = 0, y = 0; f(ret<int>(_1 + _2), x, y); } $ g++ -I./boost result_of_error.cpp 2>&1 | perl gSTLFilt.pl ./boost/boost/utility/result_of.hpp:68: error: no class template named 'result' in 'class boost::lambda::lambda_functor< ... >' ... $ Among Boost libraries, there are at least two ways for function objects to expose return types that are dependent on the types of their arguments. 1) result_of instructs users to expose a template result<F(ARG1, ..., ARGN)>. 2) Boost.Lambda instructs users to expose a template sig<tuple<ARG1, ..., ARGN>, and it also uses this convention internally. It might be nice to unify these two approaches one day or perhaps simplify the matter by implementing result_of in terms of the Boost Typeof Library along the lines of Douglas Gregor's "Looking Ahead" section in his 2003 paper, http://tinyurl.com/2nf5ym. But I figure in the mean time why not have result_of support both of the current approaches? If the functor has a nested sig template use that, otherwise try to use a nested result template. There's one additional caveat for supporting lambda expressions. A zero arity lambda functor expose its result type through the typedef nullary_return_type. This can be handle in result_of by providing a partial specialization of result_of_void_impl for the template class lambda::lambda_functor. The attached patch adds support for sig in functors and nullary lambda functors. Apply with 'patch -p0 < djw_result_of.patch' from the boost root directory. It depends on the has_template_xxx patch I submitted previously (http://tinyurl.com/35x5z5) Also, if has_template_xxx is unsupported for a particular compiler the patch supplies a partial specialization of result_of_nested_result for lambda::lambda_functor. That way at least lambda expressions can be supported if not user defined functors that employ the Boost Lambda Library's convention of specifying result types. I ran the Boost Utility Library test suite and everthing passed. Let me know and I can provide documentation and tests. Thanks! Daniel Walker

6 23

Re: [boost] [Boost-announce] Review of Intrusive library begins today
by brangdon＠cix.compulink.co.uk 22 Mar '07

22 Mar '07

In-Reply-To: <46001891.5080209(a)gmail.com> igaztanaga(a)gmail.com (=?ISO-8859-1?Q?Ion_Gazta=F1aga?=) wrote (abridged): > Sink sounds good but now I need a name for operations: I would be tempted by: clear_and() erase_and() leaving open what the passed functor was expected to do. Alternatively: clear_and_dispose() erase_and_dispose() because for me "dispose" is a less committed word than "destroy". It still has the connotation that the container is getting rid of them, but leaves it more open as to what that entails. "Dispose" does have a more specific meaning in garbage collection circles; I don't know if that would be a problem here. > > Could remove_and_destroy take a default Destroyer argument that > > deleted the value? > > Well, functions can't have default template parameters Ah, OK. (Sometimes these language restrictions take me by surprise.) > I understand that maybe replacing code using list<value*> is not an > easy task, but I prefer to stick to the STL interface. You would still do that, but instead of instantiating ilist<T> you would instantiate ilist<T*>. To me there is a fairly strong sense in which the list does not contain values, but only pointers to them, because of the lifetime issues. I see myself creating objects and then adding them to the collection, rather than adding copies of them, so the semantics are closer to std::list<T*> than to std::list<T>. Where there are differences they are restrictions (no NULLs, no putting items in multiple lists etc) rather than changes. The main drawback I see to my suggestion is that a signature like: void push_back( T * ); suggests that we can pass NULL, where-as your current signature makes it clear we can't (because it takes a T reference argument). And we would have the usual std inconvenience of having to use things like (*i)->member instead of i->member for iterators. I don't know; it's just something which surprised me. Do other people think ilist is closer to list<T> or list<T*>? > Well, comparing sizes of STL containers is a bit misleading, because > how many bytes are we supposed to use in memory bookeeping if we use > standard allocators? I'd say none. For example, I believe the overhead for a std::slist<T*> node is 2 pointers, half that of ilist<T>. (And that is the comparison I would make, because I see ilist<T> as a replacement for std::list<T*> rather than for std::list<T>, but maybe I am unusual in that.) -- Dave Harris, Nottingham, UK.

2 1