- Boost - lists.boost.org

[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

Interest in static initialization library
by Sean Hunt 01 Apr '08

01 Apr '08

Hi Boosters! I was wondering if there is any interest for a static initialization library. The idea I currently have might look something like this: #include <iostream> #include <boost/init.hpp> using namespace boost; using namespace std; class myType { myType(int i) { cout<<"myType constructed with parameter "<<i<<endl; } }; void myFunc (int i) { cout<<"myFunc called with parameter "<<i<<endl; } extern init::variable<myType> myVar (42); init::function<void (), myVar> myInitFunc (myFunc, 35); init::variable<myType> myVar; int main () { init::init(); } The extern declaration of myVar simulates a global defined in a different translation unit - in this case, function is by the standard guaranteed to be initialized first, but if myVar is in a different TU, then the output is undefined. By passing myVar as a parameter to the function template, the library will ensure that the function is called after the variable (I was originally considering using a before<myVar> and after<myVar> syntax, but it would be too difficult to implement an algorithm that would be guaranteed to get the order right, whereas it's quite easy like this). The idea would be to allow an easy relationship for static initialization. I'm thinking that the variable class should act as a near-transparent wrapper by overloading all the operators. Since operator . is not overloadable, I would probably allow it to act through ->, unless the member is a pointer-like type (the exact definition of pointer-like could be controlled using template specializations). A member function would obviously be provided for accessing the object directly (such as to call a smart pointer's functions). Another idea is to have two separate classes (say, variable and wrapper), and only one has the wrapping behavior - the other has to have explicit access each time. The init function serves as the trigger for all the static initialization to occur (earlier actual initializations serve only to add the initializer to the queue) Functors would be provided to defer a function call (to get a constructor or function parameter) until the time that the initialization of the object takes place, rather than the initializer. If an exception is thrown, the initialization library will remember its state and then a subsequent call would take it off where it stopped. (adding new objects to the queue once initialization has begun would be allowable, allowing the initializer to be reused). Someone will no doubt at some point argue that I should wrap the functionality in a class to handle the initialization in order for different code to simultaneously take advantage of the facility, but I will dismiss that because it would fall prey to static initialization order and not work as intended. Perhaps later I will add a system that allows user code to store the current initialization list/state, but I don't think it would be worth the effort. One last question: Should I write this using C++09 variadic templates or the standard boost preprocessor techniques? I think that code written for variadic templates is more easily convertible to the preprocessor than vice versa, but I don't know. Thanks for your comments! Sean Hunt

2 1

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

[serialization][1.36] ktmap contains extended_type_info with m_key == 0
by Felipe Magno de Almeida 31 Mar '08

31 Mar '08

Hi Robert, I'm hitting a assertion with m_key == 0. With my debugger I can find lots and lots of items with m_key == 0. None are one of my types, there are shared_ptr_1_32 with m_key == 0 and others. Do you have a newer 1.36 version? Am I doing something wrong? I'm using the 1.36 version for use with DLLs (export in a DLL and serialize/deserialize in another). Thanks, -- Felipe Magno de Almeida

3 18

[GSoC 2008] Deadline for student applications extended
by Hartmut Kaiser 31 Mar '08

31 Mar '08

FYI... > Hello everyone, > > This year, we experimented with the program timeline providing one > week for students to discuss project ideas with their mentors and then > a single week to submit applications. We have heard feedback from the > community that it would be beneficial to provide more time for > students to submit their applications, so we've done just that. > > > The new deadline for student applications is Monday, April 7, 2008. > > > For full details, you can check out the program timeline. Please note > that our engineers are working on the required updates to both > http://code.google.com/soc/2008/ and the FAQs to reflect the extended > deadline, and we will post to this list when the changes have gone > live. > > > In the meantime, get those applications in and nag your friends to > apply. :) > > > Cheers, > LH > > > Leslie Hawthorn > Program Manager - Open Source > Google Inc. > > > http://code.google.com/opensource/

1 0

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

31 Mar '08

"Mathias Gaunard" <mathias.gaunard(a)ens-lyon.org> wrote in message news:<fsptpe$peo$1(a)ger.gmane.org>... > > I have only quickly gone through your documentation on DDJ, so my > comments may be off. Feel free to correct me if I misunderstood something. > > Personally, I fail to see the advantage over a shared_ptr member. > The only differences I could notice are > - implementation class is not user-declared but rather is a > specialization of a template. Well, the pimpl idiom is certainly not a shared_ptr.as pimpl's main purpose is separation of interface and implementation and imlemetation hiding. shared_ptr does not provide the latter. I was hoping I covered all that in the article. > - the null pointer is called null (by the way, I think we shouldn't > allow a null value, the private implementation should always be > initialized somehow, if lazily) The private implementation is always initialized by default. Nowever, null() is certainly needed for many things. And Foo::null() is certainly not a pointer but a proper (but invalid :-)) Foo instance. > There doesn't seem to be any useful help for allocating the private > implementation. What exactly are your expectations? If you'd like private implementation to be allocated for you, then it's simply not possible as ity is called private for a reason. > Such potentially interesting allocation schemes, like stack allocation, > seem also to be impossible. I have not seen one single implementation of pimpl allocating private implementation on the stack and I do not believe it is possible as in order to allocate on the stack we/compiler have to know the size of the class (private implementation class) which is again private. > Being able to replace the private implementation of a base with the > private implementation of a derived class certainly is a necessity. > I have to admit, though, I do not understand your solution. > You're passing a null<Widget>() to the Widget constructor, but the > constructor wasn't written to take any kind of special argument. null<Widget>() is an instance of Widget. Therefore, the copy constructor is called. > I'm not really sure of the point (and validity) of having pointer > semantics. Do you really want your implementation details to be shared > by some of your different instances? (maybe there is a point in sharing > implementation details with all instances or all equivalent instances, > but some?) I am not sure about your usage patterns but my usage of pimpl::pointer_semantics vs. pimpl::value_semantics is 100:1. What is the point (and validity) of having shared_ptr<Foo>? Same is applicable to pimpl::pointer_semantics. > It seems more logical to me to have the same semantics for the object > and its private implementation. If the object itself has pointer > semantics, then you won't copy it. Using one or the other for the > implementation makes no difference, then. You might as well use the > value semantics, which would even be more lightweight in that case. I personally do not see logic the same semantics for the object and its private implementation because the object is the interface and its private implementation is implementation detail (which is private as well). They serve different purpose, have different visibilities et al. What is the advantage of them having the same semantics? Thanks, Vladimir.

1 0

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

31 Mar '08

"Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> wrote in message news:<47F12E07.4060205(a)aaronwl.com>... > Vladimir.Batov(a)wrsa.com.au wrote: > > The code is in the Boost Vault called Pimpl.zip > > I haven't looked at your library, but one thing you need to do to get > buy-in for this library is provide a comparison with the pimpl_ptr > library that was proposed and rejected. > > My perception of the primary reason the library failed is that, despite > being a basically sound library, it didn't work in the ways people > wanted it to. Yes, I looked at that proposed implementation. Unfortunately, the major deficiency of it IMHO was that it was sacrificing implementation hiding (the main pimpl property) for the sake of generalization. I think I cover that in the docs at http://www.ddj.com/cpp/205918714. > It would be useful if you could summarize the vital details of your > library, along with a comparison to the previous proposal, and other > similar libraries, in your announcement message. I hope I cover that at http://www.ddj.com/cpp/205918714 Thanks, Vladimir.

1 0

[gsoc2008] YAML archives for Boost.serialization
by Esteve Fernandez 31 Mar '08

31 Mar '08

Hi all, it seems that the period for student applications has been extended to April the 7th. Although I briefly discussed the idea for YAML archives following a message by Sohail, I would like to explain it in more detail, discuss some concerns and see if there's interest. We already talked about YAML not being a superset of JSON, however given the recent great news of the relicensing of TinyJSON, it still can be used as a basis to build YAML parser. My main concern is that YAML is sensitive to indentation, actually it uses indentation as a substitute for { block }. One can write YAML to look like JSON, use TinyJSON and everything will be fine, but it will not be able to parse documents that use spaces/tabs to delimit blocks, only those that use curly brackets. I guess it will have to be implemented at the scanner level in Boost.Spirit, but it becomes more complicated. Anyway, with more complications, comes more fun :-) I might be mistaken about where to implement this stuff so feel free to correct me, but I think it's the way to go, as I took a look at the source code for the Python interpreter and for LibYAML, and they implemented the indentation stuff in their scanner, not in the parser. The good thing about doing YAML instead of JSON is that all the concerns about object tracking and class versioning disappear, as they're already implemented in the official spec. JSPON might or not be added to the official JSON spec, although there are good chances that it will be, but it's still not officially accepted and may change in the future. Also, a parser needs to implement JSONPath (an XPath-like language for querying JSON documents), since a reference to the root object can be written as "$ref" : "$[0].child" A side advantage of implementing the YAML archives is that a C++ parser for YAML would be available for those who don't want to use the official LibYAML C parser. Anyway, what do you think? Is there interest for this project? Cheers.

1 0