- Boost - lists.boost.org

[iostreams] Version of Iostreams compatible with 1.32 available
by Jonathan Turkanis 11 Jan '05

11 Jan '05

Hi All, A version of the Iostreams library designed to work with release 1.32 is now available: http://home.comcast.net/~jturkanis/iostreams/ This version does not incorporate all the changes decided on during the review, but most of the name changes have been applied. In particular, - The library is now contained entirely in the iostreams subdirectories of <boost> and <libs>. - Resources are now called Devices - The i/o mode Inout has been renamed Bidirectional - The concept Buffered has been renamed Multi-Character - Filters are now located in the directory boost/iostreams/filter - Devices are now located in the directory boost/iostreams/device The library has been tested on VC7.1, Intel 7.1-8.0 for Windows, Codewarrior 8.3 and GCC 3.2 (mingw). Unfortunately, I have noticed some regressions of GCC 3.3-4, but am working to correct them. I am confident that the library will eventually work on GCC 3.3+ and Borland 5.6.4. In addition, I may be able to provide limited support for VC6-7.0. I'm hoping to get a version into CVS soon. Also, several of the fixes that people sent me during the review have been removed because they caused regressions. They have not been forgotten -- they will be incorporated in to the final version in modified form. -- Jonathan Turkanis technews(a)kangaroologic.com

10 35

RE: [boost] Re: Interesting Boost Implementation Details?
by Brian Braatz 11 Jan '05

11 Jan '05

> [ David Abrahams] > 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? More thoughts to add to this thread. Background: * I have attended presentations from folks that they have taken VERY interesting material and made it EXTREMELY boring * I have also attended presentations from folks and it has been exciting and thrilling to watch the information unfold. I was kept on the edge of my seat waiting to see what was going to happen next * I have noticed that the crowd's at the shows are not always the "Type A" programmers, and frequently don't seem to engage or have the background information necessary to really understand the topic being presented * With complex subjects, for myself, I have noticed that once I know how to "think about something" and then I "get it". I can than think about any aspect of that, because I understand the concepts necessary to process the information. * if one can find the "sweet spot" early in the presentation for getting the crowd to "think" the right way to grasp the rest of the presentation, then you have a much better chance of ending the talk with everyone excited. (because you have taught them something and then took them along for a ride where you showed how to USE that new way of thinking) * I spent *A LOT* of time with Boost.Lamda. Writing sample code, re-reading the documentation, over and over and over and over again. It took me many passes to "get it". This is an excellent library, and the document IS well done. I think this is just the classic problem of really smart people having a hard time figuring out how to present something to someone who does not "know how to think about it". I took a look at the phoenix v2 docs. What is cool is THIS PAGE: http://tinyurl.com/3khbu What stood out about it was THIS ONE PAGE would have saved me many many hours had it been in the original Lambda docs. Because it describes for me, how to "think" about the currying. My advice to you is to find a way, in your presentation of the boost internals, to make sure that you thread it such that the people watching "can think about it". If you establish this early on, you will have an excited audience and you will (hopefully) get more people to use boost. Detailed Suggestions: * the pics in the above link are conceptually excellent for describing how to think about currying. If you can accomplish something along the same lines with the techniques you are going to show, then you will really knock em dead. * Boost internals is an excellent subject matter, I think if you first hit common concepts- and THEN delve into those concepts and how the internals of the library(ies) use that concept you will give people something they can use. * in a previous mail I made the suggestion, which I will make again. Try to think of the most important techniques the boost libraries depend on, get them in peoples heads, and then delve into the internals. * a technique I have seen used in the mags, is to decompose the templates, I.e. show what the code looks like after the compiler has gone through the generation steps. * hopefully my suggestions, though not exactly what you asked for, will be of some use to you. :) Brian

4 7

Re: boost.test covered in testing frameworks rundown
by Noel Llopis 11 Jan '05

11 Jan '05

Gennadiy Rozental wrote: > Actually Boost.Test doesn't impose that many dependencies (in other > case it wouldn't be able to use it for boost internal testing). > It does depend config subsystem and some other core part of boost (like > smart_ptr for example), which are mostly targeted for TR1. But namely > due to this dependencies (not in spite of) Boost.Test achieve > it's portability. That's something that in general, I would love to see for every Boost library: A list of what other libraries it depends on. Ideally, I'd love to see a dependency graph between all the libraries. That way I can use a library without the fear of pulling in tons of other libraries (or having to wade through tons of headers). I'm glad to hear that Boost.Test doesn't pull in too many other libraries. When I saw the shared_ptr I feared the worst. By the way, why is it using shared_ptr? Sure, it's convenient, but wouldn't it be better to minimize dependencies completely from other parts of Boost? > TEST ( MyFixture, TestCase1) > { > BOOST_CHECK_CLOSE ( someValue, 2.0f, 0.005f); > } > > If you find it generally useful I could add this helper macro into > framework. That would be truly excellent! Please go ahead and add it to the framework. > Boost.Test supply 2 predefined log formats (human readable and XML, which > you could select by command-line) and unit_test_log_formatter interface > you could implement for you own formats. What else do you need? One that we would need right off the bat is the ability to output the log to DebugOutputString() when running in Windows doing development in Visual Studio. What would be necessary to do that? Write a new unit_test_log? > Adding test_suites usually means only something like this: > > test_suite* test = BOOST_TEST_SUITE( "Master test suite" ); > > test_suite* ct = BOOST_TEST_SUITE( "Constructors test" ); > test->add( ct ); Right. The problem is that suites will be spread across multiple cpp files. So for each suite not only do need to put it together in each cpp file, but then I have to go to main.cpp and add it to the master suite. After looking at it some more, I was able to simplify it further to something like this: test_suite * GetSuite1() { test_suite * suite = BOOST_TEST_SUITE("my_test_suite"); boost::shared_ptr<MyTest> instance( new MyTest() ); suite->add (BOOST_CLASS_TEST_CASE( &MyTest::TestCase1, instance )); suite->add (BOOST_CLASS_TEST_CASE( &MyTest::TestCase2, instance )); return suite; } It still requires me to explicitly call GetSuiteX() from main for every suite though, which is unfortunate. I will look at the method you suggested for making suite registration more streamlined. > Did you really mean that Boost.Test is only PC oriented? Or it's actually > something different? Like: "If you aren't doing embedded development..." I meant it from the point of view of game development. If you're not doing PC development, you're doing something close to embedded systems development (game consoles, handhelds, etc). Thanks again for the discussion. The more we discuss Boost.Test, the closest it's getting to my ideal test framework. Thanks :-) --Noel

2 1

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