August 2013 - Boost - lists.preview.boost.org

[gil::io] clang compiler error
by Christian Henning 31 Aug '13

31 Aug '13

Hi all, I'm trying to fix some compiler errors with clang and the new gil::io. The following trivial code just wont compile: extern "C" { #include <stdio.h> #include <jpeglib.h> } int main() { jpeg_create_compress(NULL); return 0; } The error is: undefined reference to `jpeg_CreateCompress' I guess it's a very simple solution but I'm not much experienced with clang and gcc. Thanks, Christian

2 3

[cpo-proposal] presentation of the idea
by Santiago Tapia 29 Aug '13

29 Aug '13

Hi everyone, I would like to make a proposal for a new library. I only have a draft without documentation but I would like to know people’s opinion about the idea before making a formal proposal. The library will be named CPO (containers for polymorphic objects) and it will provide containers to store dynamic allocated objects from a class hierarchy. I have drafted one container and I have two more in process. The cpo library could be an alternative solution for boost pointer container library or some other solutions that use pointers. In order to understand the idea, I think that the following example of the use of the library might be better than a long explanation: #include <boost/cpo/classifier.hpp> #include <iostream> using namespace boost::cpo; class base { public: virtual int do_something(int a) const = 0; }; class derived_A : public base { public: derived_A(int b) : data(b) {} virtual int do_something(int a) const { return a + data; } protected: int data; }; class derived_B : public base { public: derived_B(int b) : data(b) {} virtual int do_something(int a) const { return a - data; } protected: int data; }; int main(int argc, char** argv) { classifier<base, std::allocator> collection; collection.insert( derived_A(21) ); collection.insert( derived_B(40) ); classifier<base, std::allocator>::iterator i, e = collection.end(); for ( i = collection.begin(); i != e; ++i ) { const base& x = *i; std::cout << x.do_something(6) << std::endl; } return 0; } ---- Program output: 27 -34 ---- Some details and advantages must be remarked in the provided example: - There are not any pointers in the client code (the example). - The container's name is classifier because it classifies objects internally using the RTTI. - The container classifier is _not_ a sequence. - Any iterator of the classifier dereferences to the base class. - The allocator argument in the classifier will be applied to every object added to the classifier. Thus, the allocator is provided without its argument. The std::allocator is the default argument. - The classifier uses continuous storage in memory for objects of the same type, therefore it is expected to improve cache efficiency with respect to solutions that use pointers (and new to allocate objects), especially if the client code uses some cache-aware allocator. I think that the idea will be interesting and useful. Although I have registered a project in sourceforge, classifier_container, I must insist: the library is under development and without documentation. I look forward to your comments and I thank you for them in advance. Best Regards, Santiago Tapia CITEF CENTRO DE INVESTIGACIÓN EN TECNOLOGÍAS FERROVIARIAS | RAILWAY TECHNOLOGY RESEARCH CENTRE UNIVERSIDAD POLITÉCNICA DE MADRID ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Santiago Tapia Fernández José Gutiérrez Abascal, 2 | 28006 Madrid TEL + 34 91 336 4267 | FAX + 34 91 561 8618 E-MAIL stapia(a)etsii.upm.es; www.citef.industriales.upm.es

8 45

about serialization
by lz＠sina 29 Aug '13

29 Aug '13

hi! I'm wonding if I can change the in "interface_oarchive.hpp": template<class T> Archive & operator<<(T & t){ this->This()->save_override(t, 0); return * this->This(); } to template<class T> Archive & operator<<(const T & t){ this->This()->save_override(t, 0); return * this->This(); } and in "polymorphic_oarchive_route.hpp" template<class T> polymorphic_oarchive & operator<<(T & t){ return polymorphic_oarchive::operator<<(t); } to template<class T> polymorphic_oarchive & operator<<(const T & t){ return polymorphic_oarchive::operator<<(t); } , so I can write code like this: enum E {}; class C { private: E e; public: E getE() const; void setE(const E e); }; template<class Archive> inline void save_construct_data(Archive & ar, const C * t, const unsigned int file_version) { // save data required to construct instance ar << t->getE(); // without changing the liberary code, I'll have to write like this: //int x = t->getE(); //ar << x; } I'm not sure about the changes, can anybody verify it? -------------- lz@sina

1 0

FW: [cfe-dev] Documenting Clang: question about how best to deliver the doc
by Paul A. Bristow 29 Aug '13

29 Aug '13

I've copied the posting below because it shows that Doxygen comments syntax are being even more widely used to add documentation of code (as opposed to writing tutorial and other descriptive text). Doxygen comments are post-processed to produce a C++ Reference section in many Boost program docs prepared using Quickbook. I suggest that this is a good method for future proposed libraries. In case you are not familiar with Doxygen, http://www.stack.nl/~dimitri/doxygen/manual/index.html here is a silly example to give the flavour of the comments (they start with the backslash trip character and are within C/C++ comments with an added !). template <typename T> int donowt(int I, char j) { /*! The ! shows that this is a Doxygen-syntax comment. Non-member free function that does nowt useful at all describing the function. \tparam T unused template parameter. \param i is an argument that is ignored completely. \param j Another argument. \pre No preconditions. \post No side effects. \returns -1 always. \throws std::exception if the unthinkable happens. \sa See also another function. */ return -1; } // int donowt(int i) Of course, the value from all this comes from the quality of the *information provided as comments*, describing the use of the parameters, templates, pre and post conditions (documenting but not enforcing concepts) and returns... Doxygen also analyses the code (now optionally using the Clang compiler - it used to get confused by some code, especially code that didn't compile!) and provides many cross-referencing links automatically, a great benefit to the authors and the readers. Doxygen remains under active development thanks to <http://www.stack.nl/%7Edimitri/doxygen/index.html> Dimitri van Heesch. It is Open-Source and entirely free and very widely used for several languages. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com From: cfe-dev-bounces(a)cs.uiuc.edu [mailto:cfe-dev-bounces@cs.uiuc.edu] On Behalf Of Morrison, Michael Sent: Tuesday, August 27, 2013 10:40 PM To: cfe-dev(a)cs.uiuc.edu Subject: Re: [cfe-dev] Documenting Clang: question about how best to deliver the doc Thanks to everyone on this thread who replied to our query about what approach to take for our Clang documentation. Your thoughtful comments were very helpful to our understanding of the issues and of the preferences of the community. We’ve reviewed your responses to the options that we proposed, and we’ve decided to pursue the following option: > 1a) Maintain the documentation in Doxygen. Any other formats required (HTML, XML, reST/Sphynx, and so on) can be generated on-the-fly from the Doxygen comments as needed. We have a good idea about how to proceed with this option, and we expect that we can begin submitting our updated Doxygen documentation later this summer. Cheers, Michael

1 0

[voronoi]medial axis
by Louis Lavery 29 Aug '13

29 Aug '13

Hello, I'm hoping to use boost voronoi to construct the (internal) medial axis for closed shapes (with holes). I need to work out which vertices of the voronoi are inside, outside and on a boundary. So my first goal is to determine which vertices correspond to the ends of the input segments (boundary vertices). The way I do this at the moment, is to look at each edge and test if its source vertex, vertex0(), is equal to either end point of the segment contained by the edge's cell. (1) If it is then it's a boundary vertex otherwise it's not. Is that correct? (2) When comparing a vertex with an input point can I do an exact compare (==) or should I use a tolerance (epsilon)? Thanks, fuzzy.

1 0

[RPC] Boost.Asio to write *concurrency ready* code
by Niall Douglas 28 Aug '13

28 Aug '13

On 27 Aug 2013 at 12:00, boost-request(a)lists.boost.org wrote: > I am *not sure* if anyone else has made such discovery, anyway, > comment is welcomed. What you have discovered is well known I am afraid. Indeed, proposed Boost.AFIO from this year's GSoC implements an asynchronous chainable closure execution engine on ASIO, and you can read documentation on how AFIO is equivalent to Google's and Microsoft's WG21 closure execution engine proposals here: https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AF IO_Documentation/doc/html/afio/quickstart/closure_execution_engines/ho w_boost_afio_relates_to_exisit.html Paul did up a great matrix mapping APIs from those engines to AFIO equivalents at https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AF IO_Documentation/doc/html/afio/quickstart/closure_execution_engines/ho w_boost_afio_relates_to_exisit/comparison_of_afio_with_other_cl.html and https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AF IO_Documentation/doc/html/afio/quickstart/closure_execution_engines/ho w_boost_afio_relates_to_exisit/other_useful_comparisons.html. If we get time before GSoC closes, we may just go ahead and implement N3562 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3562.pdf) using AFIO as it would be incredibly trivial to do so. However, the Boost community only voted closure execution support as third most important - they ranked directory change monitoring as highest, so that's what me and Paul are implementing now. (FYI to those interested, we're going to deliver some *seriously* performant directory monitoring. Testing of our direct kernel syscall based implementation suggests watching a 1 million file entry directory for changes will actually work on Windows, albeit pegging a 3.5Ghz 4 core machine at 75-85% of all CPUs. Linux sadly lacks the syscalls to match Windows, but a 100,000 entry directory may well work just fine) Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

4 10

Problem with boost::function on BlackBerry10
by Jens Weller 28 Aug '13

28 Aug '13

Hi boost Community, I've got a little problem with getting boost::function to run on BlackBerry10. So far, I was able to compile, link and run successfully when I do comment out some stuff in boost. Surely not the right way to do it, but proves to me that those lines are the problem, I'm looking for a fix, maybe a define I need to add to let this compile without changing boost headers. In total its only 3 errors, where 2 boil down to the same macro: /home/jweller/cpp/libraries/boost_1_54_0/boost/type_traits/detail/cv_traits_impl.hpp:25: Parenthesis/brace mismatch between #if and #else branches; using #if branch /home/jweller/cpp/libraries/boost_1_54_0/boost/type_traits/detail/cv_traits_impl.hpp:93: Excess closing brace in C++ code (or abuse of the C++ preprocessor) /home/jweller/cpp/libraries/boost_1_54_0/boost/type_traits/msvc/typeof.hpp:43: Ignoring definition of undeclared qualified class These two are in cv_traits_impl.hpp in boost/type_traits/detail/, caused by this line: #if !(BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2)) This line is twice in this fiel, hence the 2 errors. qcc version is gcc 4.6.3. It looks to me like BOOST_WORKAROUND isn't doing the right thing here to me. The 2nd error is more strange. /home/jweller/cpp/libraries/boost_1_54_0/boost/type_traits/msvc/typeof.hpp:43: Ignoring definition of undeclared qualified class Somehow typeof.hpp of msvc is getting pulled in. I've tried also the from BlackBerry provided boost version from https://github.com/blackberry/Boost, which shows exact the same errors. And is the one I (cruely) patched currently. Commenting out the #if !(is < 3.2) resolves the problem, but msvc is still pulled in. Also commenting in this header the cause out lets it compile, but thats nothing then a bad workaround. Currently I have only build for the simulator, but the problem is most likely also existing for the device build chain. At least the first two errors might be caused by BOOST_WORKAROUND, maybe there is a value that isn't configured correctly on this platform. Also how do I get closer to the source of the msvc code being dragged in? So, question is, is there maybe a define to help boost getting digested by the qcc toolchain? kind regards, Jens Weller

2 4

Migrating lists.boost.org
by DongInn Kim 28 Aug '13

28 Aug '13

Dear Boost community, I think it is time to move mailing lists and mail archives of lists.boost.org to the new server (wowbagger.crest.iu.edu). If it is not a bad time, can we migrate the services at 9am (E.T.) on Aug 28th? Date: Wednesday, Aug 28th, 2013 Time: 6:00am-8:00am Pacific US time 7:00am-9:00am Mountain US time 8:00am-10:00am Central US time 9:00am-11:00am Eastern US time 1:00pm-3:00pm GMT The following services may not be available during the migration. - Web services (e.g., http://lists.boost.org/) - Mailing lists: boost boost-announce boost-bugs boost-build boost-cmake boost-commit boost-docs boost-interest boost-mpi boost-test boost-testing boost-users geometry glas proto threads-devel ublas Please let me know if you have any questions or concerns about this migration. Regards, -- - DongInn

2 2

Re: [boost] [cpo-proposal] presentation of the idea
by Santiago Tapia 28 Aug '13

28 Aug '13

>Date: Tue, 13 Aug 2013 07:42:03 -0500 >From: Larry Evans <cppljevans(a)suddenlink.net> >To: boost(a)lists.boost.org >Subject: Re: [boost] [cpo-proposal] presentation of the idea > > What if the class hierarchy is used to model a graph that > contains cycles. For example, something like a spirit grammar > where a non-terminal on the rhs of a non-terminals definition? I don't see any problem, as long as they fulfill the requirements of the classifier container, i.e. the objects to be inserted should be copyable and derived from the base class in the template argument of the classifier. > Wouldn't this require some sort of smart pointer or other > garbage collection method with the ability to collect cycles? > I don't think so, the classifier container should be able to replace any occurence of something like: vector< shared_ptr <base> > in almost in any circunstance. Beside, you could avoid virtual destructors because the classifier will destroy the object directly not from a base* pointer.

5 6

Seeking "lazy piranha fedora 19 64 intel C++11" tester's contact info
by Jim Bell 27 Aug '13

27 Aug '13

Over on the boost-testing list, we're seeking the regression tester for "lazy piranha fedora 19 64 intel C++11". Please reply directly to me (off-list) if you have contact information for this person. Thanks, -Jim

1 0