- Boost - lists.boost.org

Re: Singleton
by Dave Handley 10 Jan '05

10 Jan '05

Scott Woods wrote: <long snip> > > Sometimes the type-equals-only-instance is a royal pain? > > Cheers, > Scott > My view is that you should keep the singleton as a singleton, but write some code in the singleton to manage N instances. This way your access to PBX number 1 would be something like: PBX::GetInstance().GetPBX( 1 ); and so on. It keeps the design of the singleton clean, but allows the flexibility of "exactly N" instances of a class. I have to say that I do like Jason's solution using an int template parameter on the singleton itself - although that has the weakness that every single function that uses the PBX would probably need to be templatised by type - where as a solution like I discuss above means that you PBX (or Important) class would always have the same type. Dave

1 0

[multi_array] Undocumented boost::copy_n in multi_array/algorithm.hpp
by Eelis van der Weegen 10 Jan '05

10 Jan '05

In a project of mine I use a (global) copy_n function template (that copies the first n elements of one sequence to another). When I tried using my copy_n with an iterator returned by multi_array<..>::begin, I got some unexpected argument mismatches. It turned out that multi_array/algorithm.hpp defines an undocumented boost::copy_n function template (with a different argument order than my own copy_n), which was selected instead of my own copy_n due to ADL. I'm not sure this is a "bug", but it seems to me that this boost::copy_n should either be documented, or placed in boost::detail so it won't conflict with user defined copy_n's (like it did in my case). Regards, Eelis

2 1

[gui] The Big Picture
by Reece Dunn 10 Jan '05

10 Jan '05

Hi All, We have different people with different needs and ideas as to what constitutes a UI system. The general concensus is that the resulting library should be designed independant of any target implementation and should support general platforms such as text-based systems. It is also advisable to allow interaction with a target platform to allow for platform-specific user code if required. There are several layers to a (G)UI library: [1] The platform independant layer. [2] The geometry layer - unit type, point, size, rect. [3] The base graphics layer - fonts, canvas, pens, images, etc. [4] The event handling layer - event loop, events, event handlers. [5] The UI object layer - frames, forms, widgets, lightweight objects, etc. Each of these layers is conceptually independant, but builds on top of the other. Should there be a separate library for each of these layers (Boost.Platform, Boost.Geometry, Boost.Graphics, Boost.Events and Boost.UIObject)? The design for the UI object layer must be able to support: * native-based UI objects that are dynamically constructed. * native-based UI objects taken from pre-built elements, e.g. objects on a form. * lightweight UI objects that are not native-based. * custom drawn native-based UI objects (either dynamically constructed or from pre-constructed objects), in essence a hybrid of native-based and lightweight UI objects. All of these UI object forms need to be supported, including bindings to different platforms/APIs. I see the basic UI object heirarchy as: ui::object ui::frame ui::form ui::main_frame ui::popup ... ui::widget ui::textfield ui::textarea ui::button ui::grid ui::table ... ui::layout_manager ui::flow_layout ... Here, I want to keep the UI object heirarchy as simple as possible. That is, the heirarchy is not dependant on platform specifics, but the UI object group to which the object belongs. A UI object consists of event processing and sizing/positioning. A frame is a UI object that has border (frame) decoration, with a main frame being a top-level frame, a form being a frame that is defined by an external resource and a popup is a frame that hosts components (e.g. a list of menu items for a specific menu item). A widget is a UI object that has specific events and data associated with it. A layout manager is a lightweight UI object that aids the positioning of widgets. The question is how to make it easy to specify both lightweight and native UI objects. Using a component< render_as< Renderer > > structure does not allow for an easy implementation -- how do you map the implementation details for a specific component and how do you make it extensible? I do not yet see an easy approach. I am thinking of a PIMPL-style implementation, but using templates to simplify allocation does not allow for easy construction of UI objects. Consider: ui::button ok( "OK", ui::button::push ); ui::button_impl< ui::lightweight_button > cancel( "Cancel" ); Likewise, having a constructor that takes an implementation, how do we construct the generic interface that allows this implementation. Consider: ui::button cancel( "Cancel", new ui::lightweight_button()); Also, having a shallow interface (i.e. each UI object is a top-level object), you would need duplicate code to handle common things like event handling and move/resize operations. All of these approaches has their own advantages and disadvantages. Regards, Reece

21 45

Interesting Boost Implementation Details?
by David Abrahams 10 Jan '05

10 Jan '05

Hi All, I'll be giving two talks at SD West in March, one about template metaprogramming, and another called "Inside the Boost Libraries," where I plan to discuss some of the more interesting Boost internals. You can see a synopsis at http://www.cmpevents.com/SDw5/a.asp?option=G&V=3&id=271893 I'm trying to decide exactly what to cover there. I've listed some of my ideas below, but I'm obviously not familiar with the entire Boost codebase, so I thought I'd solicit suggestions. Thoughts, anyone? My ideas: * Discuss the design of shared_ptr/weak_ptr. While not exactly an implementation technique, the design is fiendishly clever and worth exploring. * The use of template-generated polymorphism in Boost.Function to combat virtual function bloat * The way that Boost.MPL uses partial specialization on template template parameters to peel apart lambda expressions and turn them into metafunction classes. * Something Boost.Python does to avoid doing dynamic lookup of argument converters based on parameter types for each wrapped call. * Something Boost.Python does to dynamically build a chain of exception handlers. * ... your ideas here ... :) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

8 15

Boost Logo Contest
by Joel 10 Jan '05

10 Jan '05

<< I've already posted this to other lists and newsgroups, for some reason, I am having some difficulty in posting this here through gmane, so I'm trying again. Pardon me if this is a duplicate >> Hello, Boost (www.boost.org) is an open, collaborative effort that includes thousands of programmers from the C++ community at large. Boost is hoping to retire the existing logo (http://www.boost.org/boost.png) and adopt a new one. We are now launching a competition for the creation of a new logo. The competition is open to all designers, both professional and non- professional. The final design must be submitted as a scalable vector format, preferably SVG or EPS. A free, open source, scalable vector graphics editor can be found here: http://inkscape.org/. Alternative bitmap versions (small, medium and large icons, web graphics, etc.) of the logo may also be submitted to augment the main vector format. A JPEG or PNG version, to be placed in a web page, must also be submitted for judging. The Boost community will vote on submitted entries. Voting shall be based on Instant Runoff Voting (http://www.fairvote.org/irv/whatis2.htm) meaning that each individual voter shall choose 5 favorites, in order of preference. In addition to proper acknowledgement, the winning designer will receive: + the Boost Logo Designer T-shirt (printed with the winning logo design), plus, + a signed copy of the MPL book by David Abrahams and Aleksey Gurtovoy, C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond (http://www.awprofessional.com/titles/0321227255) Entries will be accepted on or before February 15, 2005. I will act as the logo contest manager. Please email all entries to me (djowel at gmail dot com). I shall post all submitted entries to Boost's web site. The competition will close on March 1, 2005 and the winning entry will be announced soon thereafter. + The logo must be immediately identifiable with the spirit of Boost. + The logo's concept must be simple and clear and should have relevance to the organization. + The logo should not be too detailed and should work in low resolution. + Any logo submission that is blatantly racist, sexist, obscene, or otherwise discriminatory will be rejected. + The logo must be the original work of the submitter. + The logo must be free of any copyright or other intellectual property claims. + The winning logo shall be distributed under the Boost Software License, Version 1.0. (www.boost.org/LICENSE_1_0.txt) Regards, Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

3 3

Re Singleton
by Dave Handley 10 Jan '05

10 Jan '05

Jason Hise wrote: > > I realize now that there is little interest in considering my library > for Boost over an adaptation of the Loki library... however, even if my > implementation is not under consideration, would someone be willing to > explain what advantages Loki offers over it? > The key thing that Loki does is use modern C++ design methods to allow a policy driven choice of a number of design questions. These are: 1) The Creation Policy - this can mean creation from new, malloc, or create statically. 2) The Lifetime Policy - this can mean that you use a Phoenix Singleton, Longevity managed singleton, or just using normal C++ rules. 3) The threading policy - single or multi-threaded. The key disadvantage of your implementation (in my view) is that it forces the use of a single creation policy (create statically), a single lifetime policy (dependencies), and a single threading policy (single-threaded). Whilst it would be relatively easy to change any of these, it would involve re-writing the class, which moves away from the concept of generic, re-usable code. > Dave Handley wrote: > >> 1) Wouldn't it be better to use CRTP than the rather strange usage >> syntax that Loki uses with a typedef and a requirement to make the >> constructors/destructors private? It is remarkably easy if you are >> not familiar with the Singleton implementation in Loki to make your >> constructors/destructors public by mistake and then use them, whereas >> a CRTP solution could make the base constructors/destructors protected. > > With my implementation it is perfectly safe for client code to make > public constructors and destructors and not have to worry about the > class being used the wrong way, because the inheritance method I used > makes it pure virtual. > I agree - and that is why I have stated the usage syntax in Loki is something I don't like - I would much prefer to see the curiously recurring template pattern (CRTP) being used. For your info, if you are not familiar with CRTP then you would have a new singleton called MySingleton that looked something like: class MySingleton : public generic_singleton<MySingleton> etc. The generic_singleton class can then enforce protected constructors/destructors and private copy constructors/equals operators. This has a few advantages over the model used in your code. The main thing is that it is a little more readable. Your version: Singleton<MySingleton>::GetInst() gets the singleton pointer whereas with CRTP: MySingleton::GetInst() would get the singleton pointer. >> >> 2) There are probably some more options that need to be included, >> for example making a Singleton be capable of destroying/recreating >> during the run of a program. Consider a singleton that is managing a >> print queue. For some reason all the printers go off-line, there is a >> potential for memory optimisation by closing down the print queue. If >> printers come back on line the print queue could come back on line - >> but that isn't possible (as far as I know) with Loki. >> > With my revised usage of dependencies, the singleton would be destroyed > when there were no dependencies left and recreated when new ones were > added. If client code wants to ensure that the singleton's life is not > interrupted, they could add a dependency in main, or even add a > static/global dependency to ensure that the lifetime extends beyond main > if that feature is desired. Using dependencies also can ensure that > singletons which rely on each other are always created and destroyed in > the right order. Dependencies are certainly one way of managing the lifetime of a singleton, but in a large project you would need to be aware of some potential flaws which your implementation would not pick up. Specifically, if you accidentally created a cycle of dependencies, the Singletons will never be destroyed. This is an easy thing to pick up in a small project, but in a large project maintained with lots of programmers over a number of years, I can guarantee that this will happen at some point. This is one of the reasons for a longevity based system in Loki - it doesn't matter if you get 2 singletons with the same longevity since they will just be deleted in reverse order of creation. > > Again, I am unfamiliar with Loki, so I am sure that there are > considerations that it handles of which I am unaware. I would just like > to learn what these considerations are so that I might grow as a > programmer, and learn through improving my own implementation. Thanks > in advance. > A final point which I'm pretty sure someone mentioned on a previous post. Your implementation includes a virtual function in the SingletonBase. A singleton is a simple object that doesn't necessarily need a v-table. By having a virtual function in the base, you can never create a singleton that doesn't have a v-table. Also as an aside, whilst both SingletonBase and Singleton contain virtual functions, they do not declare the destructor virtual but probably should! Using CRTP, you should get rid of the need for any virtual functions. Remember that Singletons should be pretty simple - look at the code in the GoF book and you see what I mean: // Declaration class Singleton { public: static Singleton* Instance(); protected: Singleton(); private: static Singleton* _instance; } Your solution isn't wrong, its just that Loki does a whole lot more that makes it a better library. The point I am making with my posts is that if Boost is going to create a library with a singleton in it, it should, as a minimum, do everything that Loki does. It should also try to fix some of the problems with Loki as well along the way... Dave

3 4

[Date-time] Borland 5.6.4 / GCC 2.95 Linux regressions
by Aleksey Gurtovoy 09 Jan '05

09 Jan '05

See http://tinyurl.com/4y6tx. -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

Determining interest for a thread library extension to handle blocking situations
by Roland Schwarz 09 Jan '05

09 Jan '05

Currently the threading library does not support for handling situations where a thread might be blocked on IO, in a platform independant way. While it is possible to write (low level) IO such as networking code that has the ability to be unblockable, the lack of an uniform interface seems unfortunate. Say thread B currently is blocking on a (third party) IO library. Now thread A needs to abandon thread B. How should this be done? Possible options are: 1) A schedules a cancel request to B 2) A calls a certain function of the IO library that, given a thread ID is able to unblock the current operation. Ad 1) this is currently not supported by boost thread, and given the rather controversial discussion about correct semantics in the past, it is unlikely to happen soon. Ad 2) This puts a lot of burden onto the user of the library. Interfaces also are likely to be different for various IO libs. Desirable would be a (free) function, say "alert(thread-id)" that is given the thread-id of B. When called by thread A, whatever is necessary to wake up the thread B will be done. The point is that my proposed library does not do the real actions, but only supply a framework that will allow the IO library to register a function to be called when it is time to break out of IO. To find out whether this is feasible I wrote a prototype implementation and an example to demonstrate the use of the interface. (Altough currently only available for MSVC.) My approach is two step. The first of which even might be interesting for a library on its own. 1) A "thdmbrptr" thread member pointer lib The intent of this library is to allow two threads to establish a shared memory space, without requiring the user code to pass any information. This basically does work like a thread local storage from inside the thread: boost::thread_member_ptr<myclass> pmyclass; All functions known from thread_specific_ptr are available, and so is semantics from inside the thread. Besides this another thread can get access to the data by: pmyclass[th]->foo(); where "th" is a thread id (or boost::thread*) and "foo()" is a function of "myclass". The lifetime of the myclass instance is managed by a shared_ptr. One reference is held by the thread (by means of a tss), a second is held by the boost::thread object that created the thread, and additional references might be held by other threads that obtained it by "*pmyclass[th]". 2) An "alert" lib The alert lib has two functions and a class object. alert(boost::thread* th) . . . to alert a thread bool alerted() . . . to find out (and reset) the alerted state of a thread class alerter . . . a class that will be instantiated on the stack. The constructor registers a (IO - ) lib defined function, The destructor unregisters this function. Some additional notes: I have been able to write a prototype implementation that 1) does not need any change to the current boost::thread 2) does not contain platform dependant code since it is built entirely on top of other boost libs. Altough it would by surely desirable to modify boost::thread to give a cleaner interface and improve performance. (Given the alert-ability of threads, a cancellation might later be built on top of it.) If it turns out, that there is interest in my proposal I will upload my files into the "vault". Thank you for your attention, Roland

2 2

[oopsla-results] Discussion of changes to submission process
by Jeff Garland 09 Jan '05

09 Jan '05

All - Since the base write-up of the OOPSLA results failed to spur really any discussion, I've written up a small proposal to tweak the submission process to include a mentor and to require a 'wiki under construction' page for each library. I've posted this on the Wiki and included it here for discussion. There are certainly more details to develop, but hopefully this email will start the process ;-) Jeff ---- http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Proposed_Cha… The intent of this page is to serve as a focal point for disucssion of potential changes submissions process (http://www.boost.org/more/submission_process.htm) === Overview Of Proposed Process === * Learn about Boost. * Determine interest. * Add a Wiki Under Construction Page ('''new step''') * Preliminary submission. * Request Mentor ('''new step''') * Refinement. * Submission for review. * Formal Review. * Web site posting. * People page. * Lifecycle. === How Mentoring Might Work === The development of a boost library typically takes months/years from conception to finally becoming part of boost. To sucessfully navigate the obsticles requires lots of knowledge about how boost works. The basic role of a boost development mentor is to guide a new library developer thru the boost process. In essence to provide someone to help give new submitters a helping hand. The expectation is that a library mentor might spend a couple hours a month answering email questions to fulfill this role (if it exceeds this then it this process will not be practical. Almost all the boost developers are very busy people and we are now adding another thing to do). Some specific functions include: * Be a first reviewer / sounding board for the library developer * Answer questions about boost processes * Answer questions about boost build and other practices * Make sure the new developer is following the submission process Note that a new library developer is not restricted to using the mentor for asking questions -- in fact, they should be encouraged to use the mailing lists where a the larger group can help. === Wiki Under Construction Pages === One of the issues with the current Boost web structure is that it is quite difficult to find out about libraries that are in progress and it is difficult to others with similar interests. It was suggested that we formally add Wiki pages to track and organize this progress better. While this already exists to some extent in the LibrariesUnderConstruction Wiki page (http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?LibrariesUnd…) this page would be linked from the Boost mainpage and each library under construction would maintain it's own 'under construction page'. I've prototyped a new version of the under construction page (http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?LibrariesUnd…) The idea is to keep the information on the main page small so that it can be rapidly scanned. Details will go on the page associated with each individual library. The page will have categories of development status as follows: Review Pending Stable but Evolving -- Not Yet Submitted for Review Preliminary On Hold Abandoned === New Boost Vault === There is a new file storage area that new boost developers can use to share their library with the world. http://boost-sandbox.sourceforge.net/vault/

6 20

Re: Singleton
by Dave Handley 09 Jan '05

09 Jan '05

Mikhail Glushenkov wrote: > What about adapting Loki's Singleton? It's the best Singleton > I know about and (probably) the most widely-known one. I agree that it is probably one of the best ones around. My only issues are: 1) Wouldn't it be better to use CRTP than the rather strange usage syntax that Loki uses with a typedef and a requirement to make the constructors/destructors private? It is remarkably easy if you are not familiar with the Singleton implementation in Loki to make your constructors/destructors public by mistake and then use them, whereas a CRTP solution could make the base constructors/destructors protected. 2) There are probably some more options that need to be included, for example making a Singleton be capable of destroying/recreating during the run of a program. Consider a singleton that is managing a print queue. For some reason all the printers go off-line, there is a potential for memory optimisation by closing down the print queue. If printers come back on line the print queue could come back on line - but that isn't possible (as far as I know) with Loki. 3) What issues are there with the licensing of Loki? David Greene wrote: > I think that's a good place to start. What other patterns should > we be looking at. We ought to start a wiki page. > > I would prefer to put the files in the sandbox so they are > versioned, have history, etc. The yahoo files section is > inconvenient due to the registration requirement. I would be happy to submit what I have to the sandbox - who do I contact to get on the sandbox as a developer, and is there a set of submission guidelines? Where would the wiki page be? I also notice from a quick browse of the sandbox that there is a set of classes for visitors, and that they haven't really been touched for 2 years. Did these ever make it into boost? Is there any documentation for them? And could we perhaps look there for a starting point for the visitor side of things? In my view, the best start for a list of patterns to look at is probably the GoF book! I have written generic code in the past for: 1) Flyweights 2) Composites 3) Visitors 4) Singletons 5) Bridge (just to link the 2 classes easily) There is certainly scope to include: 1) Factory Method 2) Abstract Factory 3) Decorator 4) Chain of responsibility However, if we are to have a go at a project like this, I would suggest keeping the initial submission list quite short, and then if there is some interest further down track, follow on with more patterns. Dave

5 4