- Boost - lists.boost.org

[logo] Abstract
by Rene Rivera 02 Dec '04

02 Dec '04

-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

Slow boost.org!
by David Abrahams 02 Dec '04

02 Dec '04

Has anyone else noticed the website being exceedingly slow? Maybe it's time, after all, to move its hosting to osl.iu.edu. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 5

[logo] Boost/++ stripes
by Rene Rivera 02 Dec '04

02 Dec '04

-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

[gui] (Was GUI validation (was GUI Library Proposal for a Proposal))
by Andy Little 02 Dec '04

02 Dec '04

"Eugene Lazutkin" <eugene(a)yymap.com> wrote > Just to revive discussion about GUI allow me to offer my 2c worth. (Sorry > for big post). > > Let's split GUI into two parts: G (2D graphics) and UI (user interface). > :-) > G can be used without UI: printing, generation of metafiles (e.g., > Postscript, SVG) or pixmaps/bitmaps. UI can be used without G, if only > stock > components are used: simple dialog boxes. The idea of separating GUI into various conceptual areas seems good to me, However I would have thought that the graphics primitives part must be designed first. Graphically a window should be part of a graphical system that deals with graphical transforms, which also opens the way for non window elements to be manipulated generically... From the point of view of instantiating a graphical entity it should be possible to know where and how big it is required and in relation to what, IOW a coordinate system. > Now we want to make all these components as light-weight as possible for > performance reasons. Ideally they should be mapped 1-to-1 to facilities of > underlying platform, while preserving platform independence. I don't think > it is productive to walk original Java way and implement all widgets in > terms of graphics primitives, Drawing the various parts of a window, eg its border is fundamentally a graphics operation too. Should it not be possible to implement a gui on a simple operating system such as DOS or other simple embedded os that has no concept of high level graphics operations? There needs to be some underlying abstraction which does not rely on an operating system for its existence. > First order of business is 2D geometry. Following stuff is required: > > 1) Point. Simple 2D entity with X and Y components. In real life at least > two versions are required: integral (screen coordinates are integral) and > floating point (for precise calculations). I agree that this humble 2D entity or family is the first graphics primitive that needs some resolution. Because they are used in so many ways a general purpose xy_pair type is the option I have currently been using. ( Being the 2D equivalent of an int or a float) Operations addition, subtraction, multiplication and division by a numeric. Perhaps this whole point/size issue shows a lack of clarity regarding the overall coordinate-system. A 'point' describes a relationship between one entity IN another, suggesting a graph edge relation. A 'size' is a property OF an entity only. The observation that the difference between a 'Point' and a 'Size' could be used to discriminate functions is valid, but when used in a context ( ie by finding the best model of the system)there is less need for pivotting (overload resolution) on particular types. As another example... if screen units were one type and window units were some other type eg millimeters or whatever, then conversion between these types could be achieved automatically rather than requiring a LPtoDp function etc. However this again may not be necessary if the framework fits correctly eg using a transform matrix as a edge property of a graph of the relationship between graphical entities. > Additional consideration: point should play well with native > platform-dependent coordinate. I dont view things quite this way. This is surely a classic case where the concept (the What) should be considered before any particular implementation . My criticism of current libraries in this discussion is that they have basically started with a particular implementation and tried to abstract from that. IOW each implementation should be a 'workaround' for the ideal approach which provides the standard from which to work. > Additional consideration: region should play well with native > platform-dependent regions. Because region is relatively complex object, > which is used mostly in specific context, it may make sense to implement > it > as a wrapper around native region. I also think it would be necessary to work out the mechanics of regions first, else one gets into implementation problems again. If the goal is platform independence then as well as reuse, it would need to be possible to build the mechanics from scratch. > 5) Transformation matrix. In 2D case it can be implemented as 3x3 matrix > or > (to conserve cycles and spaces) as 2x2 matrix + offset vector (6 values > total). Usually it doesn't make any sense to use integer matrix. > Algorithms > to be implemented: addition, multiplication. It is beneficial to have > construction from offset vector, rotation angle, mapping from rectangle to > rectangle (with and without preserving aspect ratio) and so on. More > complex > algorithms are practical as well like "zoom around given point". This relates to the overall coordinate system. The overall graph of spatial relationships between windows also can benefit by using transform matrix 'edges'. This also provides a clearer framework. IOW when 'moving' or 'sizing' a graphics entity (eg window) there is a more obvious answer to the question " in relation to what?" Objects representing transforms seem to be a good way to go. > Well, what are your thoughts? Discussions of UI are recurrent event in > Boost. I saw several proposals for 2D geometry in this mail list. Authors > of > several GUI toolkits are frequent visitors here. Are we ripe already? Thanks... There is a lot more interesting stuff in your post and I like the overall tone.Would it be an idea to use the boost wiki to further the discussion? regards Andy Little

1 0

RE: [boost] Re: Logo design
by Stefan Seefeld 02 Dec '04

02 Dec '04

> From: David Abrahams [mailto:dave@boost-consulting.com] > "Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> writes: > > > David Abrahams wrote: > > > >> http://www.luannocracy.com/logo.ppt > > > > I don't have PowerPoint. Is there a free reader availible? > > Alternately, would it be possible to rewrite this document > as a PDF or > > something? > > I tried, but it doesn't render quite the same (the vapor trails in > slides 2,3,4 and 6 are off). Anyway, here's what you get: > > http://www.luannocracy.com/logo.pdf FWIW, a wonderful free tool to draw vector graphics is inkscape (http://inkscape.org/) It can save as (scalable) vector graphic or export to raster formats. You may give it a try. Regards, Stefan

2 1

[logo] boost/c++
by Rene Rivera 02 Dec '04

02 Dec '04

-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

4 5

RE: [boost] Thread: Why is my prog aborting after 283 or so threads?
by Tim Laplaca 02 Dec '04

02 Dec '04

Caleb Epstein wrote: > You can make a thread non-joinable, in which case it will > automatically clean up after itself, by deleting the heap-allocated > thread objects you create. The thread will continue to run, but it > will become "detached" and you won't face this resource issue on > thread exit. I would have never thought of that, sounds dangerous! I tried it and it seems to work though. Is that pretty safe? Specifically, I'm spawning my threads like this: boost::thread *ptr = thrds.create_thread(boost::bind (threadfunc, totalthreads, xx+1)); delete ptr; (where thrds is a thread group) My sample prog has made over 300,000 threads so far with this method, so it seems pretty stable. Tim

3 2

Suggested extension to the preprocessor library
by Ryan Saunders 02 Dec '04

02 Dec '04

Hi, I've been using the preprocessor library quite extensively in my code, and have a suggested addition to it. I use the BOOST_PP_ENUM_XXX macros for rapidly creating lists of identical template parameters. For example, instead of template <typename T0, typename T1, typename T2, typename T3> I can just use template <ENUM_PARAMS(3, typename T)> I notice that there's also a "binary" version that takes two parts and suffixes the count onto each part. The problem I'm faced with is that I'm trying to construct parameter lists to other templates, but the actual parameters are embedded typedefs in the enumerated parameters. I know that was dense -- here's an example: typedef typename meta_func< typename T0::inner_type, typename T1::inner_type, typename T2::inner_type>::type; I don't see a way to do this with any of the ENUM_XXX macros. Maybe something like ENUM_SPLIT_PARAMS(COUNT, PREF, SUFF) that would generate PREF ## n ## SUFF? Thanks, Ryan

3 2

Re: [boost] Re: Re: [multi_index] announce: serialization support
by JOAQUIN LOPEZ MU?Z 01 Dec '04

01 Dec '04

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Miércoles, Diciembre 1, 2004 10:15 pm Asunto: [boost] Re: Re: [multi_index] announce: serialization support [snip] > If you guarentee that the container itself is always serialized > before your > indices, then de-serialization of the indices would automatically > be reduced > to providing the original (tracked) pointer. In such a case, I > would think > the whole isse would never appear and that the implementation > would be very > straight forward. > I think this is not correct (but I'd like to be proven wrong, that'd mean I could simplify my code.) Consider this: struct foo { std::list<std::string> cont; std::string* pos; // pos points to an element of cont private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int) { ar&cont; // before pos, as you suggest ar&pos; } }; My thesis is that loading a foo will get it wrong --pos won't be pointing to an element of cont, but rather to some random address in stack memory. I'll check it out on my compiler tomorrow, but I was already through this when designing multi_index serialization. See my point now? Am I missing something? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[multi_index] announce: serialization support
by Joaquín Mª López Muñoz 01 Dec '04

01 Dec '04

Hi, I've just uploaded an upgrade of Boost.MultiIndex that provides serialization support at: http://groups.yahoo.com/group/boost/files/multi_index_120104.zip Docs are not yet fully upgraded, but there's some material on serialization support on the advanced topics page, plus a test case. I'd be grateful if those interested in Boost.MultiIndex can give this a try, and report about problems, missing features, improvements, etc. The implementation is a little complex, so some source code reviewing would be appreciated. If no major objections are risen, I'll commit this to the CVS in a few days. Oh, and kudos to Robert for bringing in such a powerful library as Boost.Serialization! Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 7