- Boost - lists.boost.org

boost.sourceforge.net hacked?
by Joaquín Mª López Muñoz 22 Dec '04

22 Dec '04

Please take a look at http://boost.sourceforge.net/regression-logs/ ??? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 6

RE: [boost] Unzipping the Boost distro
by Stefan Seefeld 22 Dec '04

22 Dec '04

> From: Richard Peters [mailto:r.a.peters@student.tue.nl] > If some boost authority certifies the released packages, and > users correctly > verify that the certificate is issued by the boost authority, and the > certificate is valid on the package, then certified executables can be > trusted as well. You are right, providing certificates is one thing. Whether or not to distribute executable self-extracting packages is different question. Regards, Stefan

1 0

RE: [boost] Unzipping the Boost distro
by Stefan Seefeld 22 Dec '04

22 Dec '04

> From: Richard Peters [mailto:r.a.peters@student.tue.nl] > Another argument that I thought of this morning: suppose we > do not publish a > self-extracting executable. What is going to stop an attacker from not > uploading his own self-extracting look-alike? If he can > change existing > archives, he probably can add other archives as well. right, but if some boost authority certifies its released packages, everybody is free to ignore such look-alikes. Isn't that the whole point of certification ? Regards, Stefan

2 1

automatic garbage collecting algorithm and its implementation in c++
by yilin yang 22 Dec '04

22 Dec '04

hi, everybody i've just designed and coded a garbage collecting infrastructure named u_canforget. it was uploaded onto the news group at boost.yahoo. the main idea is that we count the reference to track the life-cycle of the given object. as the new operator was overloaded to statisfy this requirement. the other important concept was the reference object. with the syntax represented by the redefined macros, the codes may be written in a very simple way with relationships automatically constructed, objects are freed without delete operater can be realized as well. i would keep tracking this thread, if there are any thought about this algorithm. thx for your advices. your's yilin. --------------------------------- Do You Yahoo!? 注册世界一流品质的雅虎免费电邮

1 0

[gui] Representation of graphical objects
by Reece Dunn 22 Dec '04

22 Dec '04

Hi All, A GUI library can be thought of as having two distinct, but related, units: components (GUI widgets) and graphical objects/operations. A GUI component consists of data and events (e.g. a push button has a title and an onpressed() event). The question is: how do we represent the graphics unit? There are clearly two views: high level and low level. You can represent a graphics library as a series of objects (lines, circles, polygons, images, text, etc.) each of which having a set of properties (color, background/fill color, etc.). This is a high-level view and is based on the vector graphics model. Consider you are writing an application that draws a fractal object on the screen such as a Hilbert curve. You decide to represent it as a list of line objects. What happens when you redraw the curve? For large numbers of lines (easy when you have a fractal depth of 5+), the redrawing process is going to be slowed down. This is because you will be changing the colour on each line drawing operation. This becomes more apparent if you are using images to fill polygons and are using the same fill pattern across several objects. There are various graphics primitives (font, pen, fill (i.e. brush), etc.). Each primitive operates on a canvas and some can be used to query information on a device (e.g. the area occupied by a text string). In Windows a device and canvas are represented the same (as a HDC), but it makes sense to distinguish between them: you draw to a canvas and query information about a device. These graphical primitives should form the core of the graphics unit, with the high-level graphical objects being viewed as an extended unit. With the discussion on using CSS and Andy Little's comment about what difference is there between GUI components and graphical objects in terms of them both being objects that have position information and are drawn onto a canvas, it makes sense to allow both types to share a common interface. The main question is really what happens on the redraw phase? Ideally, components should not be drawn on the ondraw event, but rather be controlled by the behaviour of the operating system. For owner drawn components, do we handle the drawing event here or on the request of the OS (I think the latter is best). What about lightweight components (i.e. components that do not take up OS resources w.r.t. component representation, but that do support an event model)? Should we treat lightweight controls as graphical objects with an event model? Do graphical objects support an event model? Should graphical objects be treated as lightweight components? Regards, Reece

1 0

Unzipping the Boost distro
by David Abrahams 22 Dec '04

22 Dec '04

I just downloaded boost-1.32.0 and started to unzip it with the built-in facilities in Windows XP; the OS reported it was going to take 50 minutes and it was *crawling*. Using cygwin's unzip tool it was done in under a minute. I'm thinking we should stop distributing raw .zip files without an extractor... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

11 24

regex library design (was: any interest in finite automata-based regex engine?)
by Vladimir Pozdyayev 22 Dec '04

22 Dec '04

John Maddock wrote: > This is an area I want to explore though, if I can get this next lot of code > out the door, then I'll create a cvs branch to experiment with this, if you > want to suggest / experiment with a design for the abstract creator in the > meantime, then go for it. Finally I got down to refactoring the ANFA code. Take a look at http://groups.yahoo.com/group/boost/files/anfa-regex/anfa091.zip (once again, this is not a fullscale regex library... yet) The DESIGN file content is appended to this message. -- Best regards, Vladimir Pozdyayev. ---------------------------------------------------------------------- -= Regex Design Issues =- The core classes. * charset Provides "bool operator( character )". Nothing much to say apart from that, but do see the Charset Issues section. * charset creator Supports arbitrary charset expressions (within the limits of a given set of possible operations). Implementations, however, are not required to provide _all_ the declared functionality; calls for unsupported features should result in appropriate exceptions. Also provides the "void create( charset & )" function which is used to initialize a charset newly created by "matcher creator". The "abstract_charset_creator" class provides stubs for all expression elements possibly to be requested by regex parsers. Implementations with limited functionality can inherit them and redefine only those functions that should actually do something useful. * matcher Provides the low-level matching functionality, say, finding the first occurrence of bla-bla-bla. On the other hand, replacing all occurrences is a high-level action, for it consists of (1) finding them and (2) creating a modified string---so it should go into the "regex" class. (On the other other hand, if it is possible to do replacement on the fly while searching, this becomes a low-level action. I don't know if it can be done in a sufficiently general way, however.) * matcher creator Like charset creator, only for matchers. * parser The syntax parser. Takes the input string in the form of begin-end iterators, and issues a sequence of charset/matcher creator calls ending with "matcher_creator::create" (or an exception). In essence, simply provides the function "void parse( matcher &m, iterator begin, iterator end )". A parser must be consistent with the properties of "creator" classes. * regex A wrapper for the "matcher" class. Provides the high-level creation & utilization routines. How they are connected. A sample from "regex.cpp": typedef basic_regex< basic_simple_parser< basic_charset_creator< wchar_t >, basic_anfa_matcher_creator< basic_charset< wchar_t > >, basic_anfa_matcher< basic_charset< wchar_t > > >, basic_anfa_matcher< basic_charset< wchar_t > > > regex; On "creators" and "create" functions. The name is somewhat misleading, since they fill target objects with compiled data rather than create them. Still, "charset compiler" sounds a bit weird... or does it? Anyway. The "creators" are subject to the following uses and requirements. They must be able to destruct themselves gracefully even if the expression they are being feeded with is only halfway done (in case someone has thrown an "unsupported" exception). The "create" function must do an implicit "pop" from the expression stack, so that the "creator" object could be reused. The "create" function can assume there's only one top-level expression tree node on the stack. -= Charset Issues =- (Should I rename them to "character sets" for consistency with the full-names style?) All the above templates have quite a freedom in intermixing different character types, let alone different character encodings. E.g., the sample program has all regex templates instantiated with wide characters, but the regex string itself is char-typed. This clearly needs to be controlled.

1 0

Retry: merging all utf8 files
by Vladimir Prus 22 Dec '04

22 Dec '04

Seems like the discussion about how to merge copies of utf8 code used by serialization and program_options has died. I'd like to revive it again, given that I've recieved yet another patch for that code, and the longer we have two versions, the harder it will be to merge them later. The basic question is whether to have a new compiled library in libs/detail, or just source files which will be included by serialization and program_options. The problem with compiled library is that users will have to know that in addition of -lboost_program_options they'll have to add -lboost_utf8, which is inconvenience. I've mentioned this in http://article.gmane.org/gmane.comp.lib.boost.devel/106047/ The proposed course of action is documented in: http://article.gmane.org/gmane.comp.lib.boost.devel/106122 Now: 1. Are there any objections? 2. Who does it? I can do it soon. Robert, what do you think? - Volodya

3 8

Re: [boost] Re: thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 21 Dec '04

21 Dec '04

In-Reply-To: <cpsv4p$foa$1(a)sea.gmane.org> michaeltoksvig(a)yahoo.com (michael toksvig) wrote (abridged): > you might consider adding operator[] to point and size > > also, consider defining area in terms of 2 points, and adding > operator[] to that, too I was about to say the same thing :-) I'd go further, and expose the array. class box { point data_[2]; public: point *data() { return data_; } static size_t size() { return 2; } point &operator[]( size_t i ) { assert(i < 2); return data_[i]; } // Maybe begin/end too. const point &top_left() { return data_[0]; } const point &bottom_right() { return data_[1]; } float top() { return data_[0][1]; } float left() { return data_[0][0]; } float bottom() { return data_[1][1]; } float right() { return data_[1][0]; } size extent() const { return bottom_right() - top_left(); } float width() const { return right() - left(); } float height() const { return bottom() - top(); } point centre() const { return top_right() + extent()/2; } // ... void set_top_left( const point &p ); void set_top( float f ); void set_centre( const point &p ); // ... }; This is because you will almost certainly want transforms that act on arrays of points, and it will sometimes be convenient if they can act on rectangles too. I would provide get/set methods which are independent of representation. I'd consider allowing things like ++box.top() too. Currently I think the convenience is not worth the loss of purity. ++box[0][1] should work, though. On naming... I think "area" is the wrong name. To me an area can be any shape, or alternatively, every shape has an area. I would expect circle.area() to return pi*r*r. "Rectangle" is better, but what we actually have here is a special kind of rectangle which is aligned with the axis. A rotated rectangle needs more than 2 points. So conceptually we need two rectangle types. I suggest "rectangle" is reserved for the general case, and the aligned one is called "box". As in "bounding box". It has the benefit of being short. I see no benefit in using "position" instead of the usual "point". "Point" is shorter. It's hard to improve on "size" :-) I would seriously consider replacing float with a typedef, perhaps with another typedef for distances and offsets. Even without type checking, I think using more exact type names helps to clarify thought. [Later...] I've looked at the code in the zip file now. I see it doesn't match the email. It uses a different representation and adds several member functions, although not as many as me. I am surprised to see things like size*size and size/size. I see the design is being driven by the needs of a windowing system, when I am being driven by the needs of a graphics/drawing system. That has led to different results, which I suspect is a bad thing. At any rate, it has convinced me that exposing raw member variables (like area.pos) is a mistake. -- Dave Harris, Nottingham, UK

4 4

Re: [boost] Re: thoughts on a GUI component library
by brangdon＠cix.compulink.co.uk 21 Dec '04

21 Dec '04

In-Reply-To: <cq90bq$r7v$1(a)sea.gmane.org> msclrhd(a)hotmail.com (Reece Dunn) wrote (abridged): > > This is because you will almost certainly want transforms that act on > > arrays of points, and it will sometimes be convenient if they can act > > on rectangles too. > > Translation: a.pos += gui::size( 5, 7 ); > Scaling: a.size += gui::size( 10, 20 ); > Rotation: n/a since you are assuming that each side has an angle of 90 > degrees (allowing for two point representations). I'd expect to have a family of transform objects, and in particular a general 2d affine transform represented by a matrix of 6 numbers, along the lines of: x' = x * a + y * b + c; y' = x * d + y * e * e; which can represent scales, shears, rotations, translations or any combination of them. Rotations come into play even for axis-aligned rectangles, although they may be constrained to 90 degree angles. For example, if I want to print a card that will be folded in half horizontally, the top half must be drawn upside-down relative to the bottom half. We probably want to treat it as 2 pages, draw both pages right-way-up and side-by-side in the UI, and then draw the second page upside-down and above the first one to the printer. This kind of thing is useful for 2D graphics. General affine transforms are powerful abstraction. This is an area where I have experience; my only doubt is whether the windowing system can or should use different conventions to the graphics system. And I think you will eventually want everything to be consistent and uniform. > If you have point high, low; then which corner is "high"? Likewise, > using top_left, bottom_right is bad. The same issue arises using (point, size). Which point? It could reasonably be any of the four corners, or the middle. > Having a (point, size) notation, similar to the Cocoa representation, > you remove the need for platform dependancy (except when mapping > between the native type and the independant type). You still need to know whether: r.pos += gui::size( 0, 1 ); moves the rectangle up or down. So you still need to know whether (0,0) is top-left or bottom-left. You have to pick a convention for axis orientation and stick with it, and translate where the native model differs. The orientation of rectangles drops out of the orientation of the axis. Actually, you can sometimes allow a rectangle to be specified by any pair of (diagonally opposite) points, in effect taking their bounding box. This is what PDF does. Usually, though, you normalise the rectangle so that the first point contains the smaller values and the other the larger. Incidently, the conversion from top-left to bottom-left axis orientation is an example of a general transform. It involves both a scale and a translate. > Also, this representation simplifies translation and scaling > (see above). Not really. You have some transforms applied to one member and other transforms to other members. You have to know whether a transform is a scale or a translate before you can apply it. It's not a regular, uniform system; not simple. Also, the code you show for scaling doesn't actually scale. Let's say I have two rectangles side by side: rect a( point(10, 10), size(10, 10) ); rect b( point(20, 10), size(20, 10) ); I want to scale this to double the size. What do I do? gui::size scale( 10, 10 ); a.size += scale; b.size += scale; But that didn't do the job. It made the rectangles overlap, and b's size didn't double. If we actually want that operation, the (point[2]) code is just as simple; you increment the second point. For most operations it makes no difference; neither representation has an advantage. There are probably operations for which (point,size) is slightly easier, and there are other operations for which (point[2]) is easier. I believe (point[2]) is easier for more of the important ones. Testing for point inclusion, and rectangle union, intersection etc, for example. rect intersection( const rect &lhs, const rect &rhs ) { double x0 = max( lhs.point[0].x, rhs.point[0].x ); double y0 = max( lhs.point[0].y, rhs.point[0].y ); double x1 = min( lhs.point[1].x, rhs.point[1].x ); double y1 = min( lhs.point[1].y, rhs.point[1].y ); return rect( x0, y0, x1, y1 ); } versus: rect intersection( const rect &lhs, const rect &rhs ) { double x0 = max( lhs.pos.x, rhs.pos.x ); double y0 = max( lhs.pos.y, rhs.pos.y ); double x1 = min( lhs.pos.x+lhs.size.dx, rhs.pos.x+rhs.size.dx ); double y1 = min( lhs.pos.y+lhs.size.dy, rhs.pos.y+rhs.size.dy ); return rect( x0, y0, x1-x0, y1-y0 ); } The (point,size) version has 6 extra additions or subtractions. > On review, I have removed size/size, size*size. As for the > representation change: this is an evolving library, but the essence > remains the same, so discussion here is still valid. I do not intend on > posting the full member function list as these e-mails are long enough > already! If you are interested, take a look at the code (as you have > done). I appreciate the feedback. The big questions are, should the underlying representation be exposed in the form of public member variables at all? And, does a windowing library need to pay any attention to the needs of a hypothetical drawing library? My answers are "no" and "yes". -- Dave Harris, Nottingham, UK

1 0