- Boost - lists.boost.org

typeof: what to register?
by Arkadiy Vertleyb 23 Dec '04

23 Dec '04

Hi all, Here is a question: besides primitive types, which types/templates should be registered as a part of typeof library? The first candidate is STL. The containers, functors, binders, etc. The STL iterators is a separate question. In most STL implementations they are typedefs, and therefore their template names are non-standard and different. In Dinkumware they are nested classes, and so are the subject to non-deduced context, which prevents them from being registered in a trivial way. Peder does have a solution for this, based on a bug in VC7.1 that allows to work-around non-deduced context (I am personally against using this, although I have to admit that it does the job). So, if we decide to put #ifdefs, based on STL implementation, and *if* we decide to use Peder's solution, it looks like we can take care of all the standard library (including iterators) on the typeof lib level. I have to note here that, if we decide against iterator registration, iterator instantiations can be always registered as needed, by the end user: BOOST_TYPEOF_REGISTER_TYPE(MyClass) BOOST_TYPEOF_REGISTER_TYPE(std::vector<MyClass>::iterator) I think if other libraries want to be supported by typeof (like Spirit, for example), those libraries should register their types/templates themselves (just because of synchronisation issue). Any help would be provided, of course. I would greatly appreciate any opinions on the subject. Regards, Arkadiy

2 2

boost::noncopyable and DLL usage
by Roland Schwarz 23 Dec '04

23 Dec '04

The thread class derives from boost::noncopyable. While this works for static library builds, there are some ugly warnings when compiling user programs that use the DLL version of the threading lib. I suspect noncopyable not having the appropriate __declspec(export) in a DLL being the culprit. I suspect any library will show this behaviour when doing a DLL build. Is this effect known? Are the warnings avoidable? Thank you, Roland

2 5

Status of VC++.NET 2005 Beta
by Loïc Joly 23 Dec '04

23 Dec '04

Hello all, I would like to know if anybody has successfully built boost with VC++.NET 2005 beta version ? I tried to look the regression tests, but the links from boost web site are broken (This site is defaced!!! NeverEverNoSanity WebWorm generation 25.). By the way, is there any document that explains how to create a new toolset for boost::bjam ? Regards, -- Loïc

3 3

Re: [boost] [gui] rectangles and the CSS box model
by brangdon＠cix.compulink.co.uk 23 Dec '04

23 Dec '04

In-Reply-To: <cqbhda$lq7$1(a)sea.gmane.org> msclrhd(a)hotmail.com (Reece Dunn) wrote (abridged): > However, for efficiency, it is a good idea to expose the > members of point and size. Is that because your compiler cannot inline member functions? -- Dave Harris, Nottingham, UK

1 0

X-Platforming Boost GUI
by Alan Gutierrez 22 Dec '04

22 Dec '04

I've spent quite a bit of time getting this Boost GUI code to build anywhere, but now it builds on both OS X and W2K. I'm using XCode to build on OS X, Jamboost is working on W2K. I'm feeling like I might as well add Linux to the mix, and work toward having an early integeration across these three platforms. It would teach me a lot about Boost and bjam. -- Alan Gutierrez - alan(a)engrm.com

3 3

[gui] rectangles and the CSS box model
by Reece Dunn 22 Dec '04

22 Dec '04

Hi All, In the "thoughts on a GUI component library" thread there have been various discussions about the layout of a rectangle and come relating to CSS. Note that point and size are stable. The CSS3 Values and Units module (http://www.w3.org/TR/2001/WD-css3-values-20010713/) defines various units (e.g. inches, picas and em). This is a good basis for a GUI library metric type. The type should store the values as a floating point to allow things like 2.71cm and also to support platforms that store coordinates as floating points (e.g. Cocoa). The CSS3 relative values (em and ex) are dependant on the inherited font-size property, so it is difficult to use these units as there is no associated font-size property. Another issue relating to this is how to resolve metric values between units that are not directly convertable. I have suggested using a device::resolve method that takes metric, point, size and rect types, but it may not always be possible to get access to a device. A further complication is the location of the origin. If we treat the origin as being in the top left corner (which is true for Windows, HTML/CSS and other document models such as text editors) this will simplify the design and for platforms that have a different model (e.g. Mac) then the implementation on that platform will need to map between the different representations. I personally like the CSS box model (http://www.w3.org/TR/css3-box/) which can be defined as: struct css::box_model { rect margin; rect border; rect padding; size dimensions; // width and height // T content; }; The problem with supporting it by default is that we would need: class component: public css::box_model; class graphics::object: public css::box_model; This clearly violates the don't pay for what you don't need rule of C++, so for a css_block_layout, it needs to contain the box model properties and a pointer to the component/graphical object. Obviously some level of support for the CSS box model should be provided, allowing an implementation of it to be written. There has been some discussion and disagreement as to what representation a rectangle takes. It is a good idea to hide the representation of a rectangle and provide accessors to the various values. This is because different people will want different things from it. However, for efficiency, it is a good idea to expose the members of point and size. In supporting the CSS box model and adoption of top-left as (0, 0) the representation becomes: class rect { point tl; point br; }; with: top() = tl.y; left() = tl.x; bottom() = br.y; right() = br.x; width() = br.x - tl.x; width( w ): br.x = tl.x + w; size() = ::size( width(), height()) center() = tl + ( size() / 2 ) An issue with this is: do we keep the width of the rectangle when setting left/right? In order to keep things simple, the answer has to be no. Construction of a rect should have the following variants: rect() = rect( 0, 0, 0, 0 ) rect( n ) = rect( n, n, n, n ) // This models the CSS "margin: 2px;" behaviour. rect( t, r, b, l ): tl( t, l ), br( b, r ) // This models "margin: 1pt 2pt 3pt 4pt;" rect( point p, size s ) = rect( p.x, p.y, p.x + s.dx, p.y + s.dy ) // This allows for support for traditional GUI representations Note that this model will change the nature of a program that uses the current model. We also have inflate/deflate operations that should take size *and* rect variants. This will allow easier box-model calculations: rect disp( point( 0, 0 ), size( 500, 700 )); rect margin( 1, 2, 3, 4 ); rect box = disp; box.deflate( margin ); // apply margin adjustments // ... Regards, Reece

3 8

Re: [boost] mailing lists archives stuck
by JOAQUIN LOPEZ MU?Z 22 Dec '04

22 Dec '04

----- Mensaje original ----- De: Douglas Gregor <dgregor(a)cs.indiana.edu> Fecha: Miércoles, Diciembre 22, 2004 9:02 pm Asunto: Re: [boost] mailing lists archives stuck > On Dec 22, 2004, at 7:22 AM, Joaquín Mª López Muñoz wrote: > > To whom it may concern, the archives of the mailing lists, > > (for instance, http://lists.boost.org/MailArchives/boost/bydate.php) > > have stopped collecting messages since almost a week. > > The archives should be working again now. Thanks for the report! > Thanks for fixing the thing :) BTW, the *users* mailing list is also stuck :( As for the announce list, ist' hard to know, because its volume is so low. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

mailing lists archives stuck
by Joaquín Mª López Muñoz 22 Dec '04

22 Dec '04

To whom it may concern, the archives of the mailing lists, (for instance, http://lists.boost.org/MailArchives/boost/bydate.php) have stopped collecting messages since almost a week. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Add conversion op doc to scoped_ptr
by cliffg＠codewrangler.net 22 Dec '04

22 Dec '04

This may already be known / in the queue / in CVS, but in case not ... The scoped_ptr synopsis and members does not document the unspecified-bool-type conversion operator that scoped_ptr provides (I didn't check scoped_array to see if the same issue is present or not.) I found this when a couple members of my team converted code from shared_ptr to scoped_ptr, with the original code relying on the conversion operator, and I was surprised when everything compiled cleanly (without adding the appropriate get() calls). Cliff

1 0

Help \ Advice requested on getting the return type from a Lambda fctor
by Brian Braatz 22 Dec '04

22 Dec '04

I wrote up the simple example that shows what I am trying to figure out Basically, I am trying to pull the deduced return type (or explicitly passed as a template param in lambda bind()) in my template. If I have a function that is receiving a functor, I would like to be able to take that functor and pull the RETURN TYPE out of it. Lets say I have a function that returns a string: std::string ReturnAString() { return "this is a string"; } And then here is my template function (code below does not compile) template < typename TFUNCTOR> TFUNCTOR::result_type CallFctorDeduceRet( TFUNCTOR & functor) { return functor(); } Now here is my bind call std::cout << ( bind<std::string>(&ReturnAString)); Is there a way to GET to the return type in the Lambda fctor that was generated with a BIND call? I would like to be able to pull the <std::string> from the bind call and use it in the template function. It is not a problem for my template function to be dependant upon lambda bind. I have been going through the lambda code. And while it is brilliant, I am having a bit of difficulty figuring out what I am looking at (grin). Any help or direction is greatly appreciated FULL SAMPLE CODE HERE: template <typename CURRIEDTYPE> // Id class for currying type without creating the object class Id { public: typedef CURRIEDTYPE TYPE; }; // Explictly pass IN a return type template < typename TFUNCTOR, typename TRET> TRET CallFctorPassInRet ( TFUNCTOR & functor, Id<TRET> & ) { Id<TRET>::TYPE TRet; TRet = functor(); return TRet; } std::string ReturnAString() { return "this is a string"; } // try to get return type from the lambda fctor // Below does not compile- but it is along the lines of what I // WANT to do- note that I am trying to get from the Lambda functor the deduced return type template < typename TFUNCTOR> TFUNCTOR::result_type CallFctorDeduceRet( TFUNCTOR & functor) { return functor(); } void Test_LambdaRetDeduction() { std::cout << "CallFctorPassInRet returns [" << CallFctorPassInRet( bind(&ReturnAString), Id<std::string>()) << "]" << std::endl; // below is what I want to make work std::cout << "CallFctorDeduceRet returns [" << CallFctorDeduceRet( bind<std::string>(&ReturnAString)) << "]" << std::endl; }

1 0