March 2008 - Boost - lists.preview.boost.org

Bug in 1.35: header inclusion order dependency introduced between recursive_mutex.hpp and asio.hpp on Windows
by James Talbut 01 Apr '08

01 Apr '08

recursive_mutex.hpp include windows.h, which includes winsock.h. asio.hpp barfs if winsock.h has been included. Clearly it's not boost's fault that windows.h and winsock2.h have inclusion order problems, but this change will break code that currently uses them both. Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________

7 8

Re: [boost] [gsoc 2008] A C++ Remote Method Invocation Framework using Boost.Asio
by salinda h 01 Apr '08

01 Apr '08

Hi, Thaks for your replies. > Interesting. Have you checked that there isn't something available already on > asio...not sure, but I think someone might have already done something like > this. That said, AFAIK it's not in Boost so this would be a nice extension. Thanks to Paolo Coletta's reply, I found the CodeProject article by Jarl Lindrud "RCF - Interprocess communication for C++". It is similar to what I suggested. Since it is not in a Boost library form Paulo suggests possible integration between this library and boost.interface. > Have a look at Boost.Interface http://www.cdiggins.com/bil.html > This library was never fully proposed for Boost, but it has alot of the same > ideas/needs as you do w.r.t. binding with C++ interfaces. Thanks for making my attention on this. After looking at the article, I understood that the Boost.Interface library will releive me from the burden of writing a custom Macro library. However I couldn't find a link on that page to get the source code of that library. Please tell me where can I get the source code. > Also, a totally different way to go would be to support an IDL like language > and write a tool to generate the needed C++. Yes. Internet Communication Engine (http://www.zeroc.com/ice.html) (Where I got the inspiration for this project.) uses an IDL. Since this is a C++ only project I thought I can avoid the additional step of code generation by using Macros. ( I likek the macro bindings in boost.python. It is so simple & smart than SWIG.) > What do you have in mind for the transport protocol? Both TCP and UDP. (Option is given to the user.) Thanks! Salinda

2 2

[Proto] Review
by David Abrahams 01 Apr '08

01 Apr '08

First, let me say that I enthusiastically vote for acceptance! - What is your evaluation of the design? Excellent. I would change some names here and there. - What is your evaluation of the implementation? I didn't look at the implementation much, but I am familiar with Eric's work and I have no doubt that it's stellar. - What is your evaluation of the documentation? A valiant effort, but still needs work. This is a difficult domain to explain, but I hope that Eric will keep trying :-) - What is your evaluation of the potential usefulness of the library? Extremely useful. I'm already looking forward to using it in at least two projects. - Did you try to use the library? With what compiler? Did you have any problems? I tried out a few of the early examples with G++ 4.1.3. The only problem I had is noted in the attached user guide walkthrough, and I very much doubt it was a compiler dependency. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 12 hours of careful reading through the user guide. - Are you knowledgeable about the problem domain? Reasonably knowledgeable. I have lots of experience with expression templates but very little with the domain of generalized ET libraries. The attached document contains many more comments. -- Dave Abrahams Boost Consulting http://boost-consulting.com

6 31

[1.35.0] Going live with the new web site
by Beman Dawes 01 Apr '08

01 Apr '08

What has to be done to go live with the new web site? I assume this should happen as soon as the release packages go up on Sourceforge. Thanks, --Beman

7 28

[mp_math] a multi precision signed integer library
by Kevin Sopp 01 Apr '08

01 Apr '08

Hi all, I've been busy with porting the public domain C library libtommath to C++. The code is quite usable as it is and some simple documentation exists in the libs/mp_math/doc/html subfolder. I've implemented all C++ operators for the mp_int<> type and it can thus be used just like a built-in integer type. Some things like random number generation and primality testing have not been documented yet. Please have a look, I'm looking for feedback at the moment so that I can plan on how to proceed. http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… alternatively go to boost vault /math - numerics subfolder and download mp_math_v01.zip Kevin

7 19

[gsoc 2008] JSON Archives for Boost.serialization
by Esteve Fernandez 01 Apr '08

01 Apr '08

Hi all, I'm new to this list but have been tracking Boost development for a long time. Never thought I could contribute something new to Boost, but after seeing this year's GSoC Boost proposal, I changed my mind and decided to take a deeper look at the JSON proposal. I've used the Boost.serialization library extensively and always end up needing something more portable than the binary archive and less heavyweight than the XML archive. Also, I spend a lot of time developing with Boost.Python and a format already supported by Python would be great, so seeing there was interest in a JSON archive was the perfect opportunity to join. Anyway, I've some points regarding this project before I apply, don't know if I should send them to Jeff (who suggested the idea) or to Robert (who implemented Boost.serialization). Instead of just bothering them, I'll bother all the subscribers to boost(a)lists.boost.org :-) - the JSON spec is quite simple, but given that it's a subset of YAML (actually Syck parses JSON as well), should it support it in the future as well? - what about Unicode? I know that Boost.Regex supports Unicode if compiled against ICU and the JSON spec states that everything must be in Unicode (correct me if I'm wrong) - TinyJSON and JSON.Spirit both use a MIT-like license (JSON.Spirit is licensed under CPOL). The Boost license is compatible with them but, could it pose a problem? There's JSONcpp [1] as well, which is public domain. - wading through the Boost mailing list archives, I found a message [2] by Daryle Walker in which he expressed interest in a JSON serializer some while ago (2005), but I think it wasn't discussed any further. Eric Newhuis wrote again about having a JSON archive just a few weeks ago [3] - which platforms must be supported? I can only provide support to GCC under Linux, but I guess it has to support MSVC and some other platforms. Will it have to be available for all the platforms supported by Boost at the end of the summer or is it more of a process? That is, given that one of the purposes of GSoC is to involve more people into free software/open source projects, whoever (I hope it's me :-)) implements the JSON serializer, will become its maintainer too and will take care of all the tasks related to accept patches, track bugs, add support for future/incomplete platforms, etc. - I thought of adding JSON support to Boost.Spirit as well. Currently it has support for printing ASTs in XML (see tree_to_xml). A JSON dumper would be quite useful for manipulating ASTs in a high level language, such as Python through Boost.Python Cheers. 1 - http://jsoncpp.sourceforge.net/ 2 - http://lists.boost.org/Archives/boost/2005/09/94438.php 3 - http://lists.boost.org/boost-users/2008/03/34336.php

5 6

[shifted_ptr] Now supports <void>, multithread roots & preprocessor code
by Phil Bouchard 01 Apr '08

01 Apr '08

Greetings: Ok, this a nice feature that just got added to the pointer. I just added support for "void" pointers and works perfectly. We can see the object being deleted correctly after the shifted_ptr<void> is destructed. Furthermore a very nice property shifted_ptr_base has is that it can be casted to a regular pointer and back again to a shifted_ptr_base and the pointee will still be correctly deallocated. I never saw any production code using perfect C++ coding and sometimes it happens we rely on "working undefined behaviors". Multithreaded support has been added but unfortunately I didn't see any function returning the current thread id. Was this disregarded? Finally I am using cleaner preprocessor coding for variadic function templates: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Thanks, -Phil

3 8

1.35] Please remove \libs\filesystem\src\exception.cpp.
by Joe Gottman 31 Mar '08

31 Mar '08

Instead of using bjam, I compile the boost libraries on my own. I recently tried to compile the new version of boost::filesystem, and failed with exception.cpp. I had a scary few minutes until I realized I no longer needed this file since filesystem now uses errors from the system library. With header files, especially ones that the user never uses directly, there is no problem with leaving them in the directory after they are no longer needed, since they will never be included. However, users generally expect to have to compile source files, and so one that is included but no longer valid can cause major problems for people who compile without using bjam. Therefore, I would appreciate it if you would remove \libs\filesystem\src\exception.cpp. Joe Gottman

1 0

Re: [boost] Review Request: Generalization of the Pimpl idiom
by Vladimir.Batov＠wrsa.com.au 31 Mar '08

31 Mar '08

"vicente.botet" <vicente.botet(a)wanadoo.fr> wrote in message news:<014201c8937c$c1380180$0301a8c0@viboes1>... > Hello, > > First of all, I think that a pimpl library should have a place in boost, but > I think that the pimpl idiom do not scale very well (see below). > > Even if your library is usable in simple cases, I would like to see how it > can manage more complex cases. And if no satisfactory solution to this case > is possible, that the library states explicitly when it can not be used. Would it be possible to elaborate that exactly you mean by "more complex cases"? Inheriting from a pimpl-based class? I think it covered. What else? Not like my own deployment experience is of any guidance but still I've been using this idiom in my every-day development for about a year and have not come across something that I felt was not a good fit for that idiom. I'd rather say that the pimpl idiom in general does not handle well simple (rather than complex) cases where the overhead of creating private implementation on the heap is not affordable. > > Do you think to write the library documentation before the review? Even if > there is a tutorial in DDJ, IMHO, you should spend some time on the > documentation of the library before the review. In addition to the tutorial I have API documented in the header in the format for doxygen. Although I have to confess when I did run it through doxygen it did not seem to produce anything I saw valuable so I did not include that doxygen-generated file. Will look into it again though. Thanks, Vladimir.

1 0

Re: [boost] GSoC Ideas
by Cristianno Martins 31 Mar '08

31 Mar '08

Thanks for comments and advices, Doug. I really appreciate it. On Sun, 2008-03-30 at 21:14 -0300, Cristianno Martins wrote: > I'm Cristianno Martins, I'm starting master degree at State University of > Campinas (Brazil), and I'm very interested in participate of a Google Summer > of Code Project. Welcome! > This is the first time that I'm intending to develop some open source code. > There are many projects listed in GSoC home page, and I almost read all of > them, choosing two or three to write a propose. Usually, it is best to focus your energy on a single project that you're very interested in. Take the time to write a detailed proposal for that project to give it the best chance of success. > So, I really liked two ideas between the boost potential projects: > - safe integer -> basically, a creation of a template class to safely access > values in the memory; > - parallelizing Boost.Math -> using OpenMP to enable the source of > Boost.Math to run in multicore systems. > > I actually believe that I can do anyone of them, and I wanna propose a > project to each one. I only needed to know if anything is being done about > some of those. I also wanna know if someone have ideas to be done in these > projects and aren't listed at the Boost projects list. We often receive several applications for projects listed on the Boost projects list. That's why it is best to write a solid proposal that makes you stand out. - Doug -- Cristianno Martins Mastering in Computer Science State University of Campinas cristianno.martins(a)students.ic.unicamp.br skype:cristiannomartins g-Talk: cristiannomartins msn: cristiannomartins(a)hotmail.com

1 0