September 2005 - Boost - lists.preview.boost.org

Re: [boost] [integer] Create (u)int_natural_t
by Martin Bonner 11 Oct '05

11 Oct '05

----Original Message---- From: Simon Buchan [mailto:simon@hand-multimedia.co.nz] Sent: 29 September 2005 10:21 To: boost(a)lists.boost.org Subject: Re: [boost] [integer] Create (u)int_natural_t > Daryle Walker wrote: >> The "int" type was supposed to match the processor's natural built-in >> integer processor. That was easy to maintain in the 16- and 32-bit >> eras, but got screwed up when we started 64-bit computing. The C >> and C++ communities decided to expand … [View More]

5 4

Request for technical notes
by John Calcote 08 Oct '05

08 Oct '05

I think it would be a good idea to provide some technical notes for various boost class implementations. For example, I have recently been studying smart pointers - I've ready Andrei Alexandrescu's discussion of the topic in his book, 'Modern C++ Design'. It's good, and fairly comprehensive, but doesn't cover all of the nuances of some of the boost smart pointer implementations. For those of us interested in learning more about the language, and more about boost classes and the rationale … [View More]

5 4

Re: [boost] Are there any interest in a pimpl library?
by Martin Bonner 04 Oct '05

04 Oct '05

----Original Message---- From: Asger Mangaard [mailto:tmb@tmbproductions.com] Sent: 27 September 2005 16:13 To: boost(a)lists.boost.org Subject: Re: [boost] Are there any interest in a pimpl library? >> Could you be more specific as to what functionality such a library >> would supply? If you already have an implementation then an example >> of it's use would be interesting. That was my immediate reaction too. >> It is my understanding that the pimpl idiom is fairly … [View More]

7 27

[relational] Relational Model Library
by Calum Grant 04 Oct '05

04 Oct '05

Hi all, I have recently completed a library for implementing relational models in C++. Using template metaprogramming, multi-index containers can be manipulated using SQL-style queries, while retaining type-safety and efficiency. The web page is http://visula.org/relational This might be an appropriate interface for the database library that was recently discussed. This is not the same as Relational Template Library, which uses an entirely different interface. Is there any interest in … [View More]

13 44

[mpl] bug in mpl::at?
by Geoffrey Romer 04 Oct '05

04 Oct '05

I asked this on boost-users with no luck, so I figured I'd kick it up to the experts: I'm trying to use the 3-argument version of the mpl::at metafunction, as described in the on-line manual, but I'm getting a compile error (using gcc 4.0.2): --- error: wrong number of template arguments (3, should be 2) /usr/include/boost/mpl/at_fwd.hpp:20: error: provided for 'template<class Sequence, class N> struct boost::mpl::at' --- Looking at at.hpp, at_fwd.hpp, and aux_/at_fwd.hpp, I don't see … [View More]

4 6

[scope_guard] New revision available + naming consideration
by Andrey Semashev 03 Oct '05

03 Oct '05

The new version is available in the Sandbox (I moved it into Function objects): http://boost-consulting.com/vault/index.php?action=downloadfile&filename=sc… Here is a shord summary about changes: - Various cosmetic changes, including macro and function names. - Exception support code (with_catcher policy) moved into a separate file. - Added a helper function "catching" to simplify use of with_catcher policy. - Unique names generating code moved into a separate file. By the way, maybe … [View More]this code should better be in Boost.Preprocessor? See boost/guard/unique_names.hpp. - Revised the guard_ptr class, moved it up to boost namespace. It is now resided in guard_ptr.hpp. - The actions_trace class was considered to be too specific and was eliminated. The new guard_adapter class is supposed to expand the functionality of holding scope guards in containers to every STL-compatible container (sequental or associative) and even to the standard container wrappers such as stack, queue or priority_queue. See guard_adapter.hpp for more details. - I hope I've fixed problems with VC6 (and even maybe BCB) I've been reported, but I can't tell for sure since I can't try it. At least the code that uses scope_guard.hpp should work (once again, I hope). Maybe I'll have a chance to test it on VC6 in a week or two, but now I'm walking blindly. As always, I've tried it on VC7.1, ICL9 and MinGW (GCC 3.4.4). Few words about what I'm concerned about: - The naming of arm/disarm methods of scope guard. They are used to change the activity status of the guard. Personally, I feel fine with them but the commonly used name for disabling the guard is "dismiss" and I just can't figure out its suitable counterpart in English. I wonder if anyone have a proposal about this. - The naming of the function make_guarded_call (in previous version it was make_transaction) is what I'm not sure of. This function in addition to a scope_guard creation calls some another functor. The semantic is grouping the "do" and "undo" actions in the user code. Does anyone have a better name? - I have received a proposal of ability to allocate space for several scope_guards on the stack. In current implementation when using guard_adapter and guard_ptr with some container the guard objects will be allocated in the heap which might be slightly slower than if it would be on the stack. So the most probable implementation of such proposal shall be a separate static container. Does anyone have any thoughts about this? How much would you need such functionality? I think, I've reached some point release (unless anyone have proposal about namings). At least, the main scope guard implementation seems to be stable. So I would like to check in this version to CVS (or, maybe, if someone do this for me) if there are no arguments against this. Once I have done this I could start making BoostBook docs (now there are only doxygen-like comments in the code) and make some unit tests. [View Less]

13 37

[mpl] sequence_wrapper change to handle enums
by Larry Evans 03 Oct '05

03 Oct '05

Would it be OK for me to copy: boost-sandbox/boost/mpl/aux_/sequence_wrapper.hpp to: boost/boost/mpl/aux_/sequence_wrapper.hpp for the reasons cited here: http://aspn.activestate.com/ASPN/Mail/Message/boost/2640803 ? Also, it would also help *nix developers if: boost-sandbox/libs/mpl/preprocessed/preprocess.py were similarly moved. OK to do that?

2 1

[fsm]
by Andy Little 02 Oct '05

02 Oct '05

Is fsm library not in boost 1.33.0 or have I lost it? regards Andy Little

2 5

A GUI decomposition
by Stefan Seefeld 01 Oct '05

01 Oct '05

Given the recurring interest this topic incites, I think it is important to start by clarifying what people really mean by 'C++ GUI'. For the more practically-minded, it is a means to portably and easily write Modern C++ (TM) applications that use a graphical interface, while for others it is an occasion to Do It Right This Time (TM). Can they both be satisfied with the same API ? I believe this should be possible by making educated use of abstraction and modularisation. I'm a little reminded … [View More]of the discussion around a socket / network / asyncio API, as I believe the situation is similar. This is because the methodological challenge is the same: what is needed is not a single monolithic API but in fact a set of interdependent APIs, and it is hard to draw a clear line between them. Therefor, I'd suggest we split 'GUI' into distinct modules and try to model each individually, keeping in mind that a) they all have to be able to collaborate and b) each may be implemented either in terms of a 'native' backend as well as in a OS-independent way. To get to the meat, here are the domains I think should be discussed individually: * Imaging Model =============== This module is concerned with low-level drawing primitives (2D at first, but may be extended into 3D). The associated vocabulary includes canvas, painter, graphic context ('GC'), path, pencil, etc., etc., you get the idea. * Event / Messaging Mechanism ============================= This module provides whatever it takes for individual parts of an application to exchange messages, both, graphical as well as other. Designing this module is particularly challenging if this is to be generic as some backends are rather constraining in terms of message types that can be sent / received. This module should be able to provide a uniform view on both input events ('button click', 'pointer move'), region management ('expose', 'resize'), as well as high level widget-related ('slider dragged'). * Region ('Window') Management ============================== This module is concerned with providing users with regions to draw to and receive events for, independently on what these regions actually contain. The associated vocabulary includes region, map / unmap, resize, stack, layout. While people may be inclined to think of these regions more in terms of windows, or even widgets, I believe there is good reason to keep these two concepts separate, even though in most cases there may be a one-to-one mapping between the two. (Imagine a situation where windows (which typically are screen-aligned rectangular regions) are not enough to represent regions, i.e. where you want to track stacked *shaped* graphics.) * Widgets ========= This is probably what most developers think of as 'GUI'. It's all those building blocks that have a certain style, behavior, and associated state, with more or less complex logic to keep 'view' (and possibly 'controller') separate from the 'model'. Again, I suggest this separation in the hope that it will facilitate and focus further discussion. I believe all existing GUIs support the above concepts, even though they may not be as clearly separate as I suggest here. In particular, depending on the architecture some of these aspects might be hidden, for example if the work is split into a display server and a client, where users only program the client application. As prior discussions suggest there are widely differing views on who should be in control of styling. Using different backends (or policies) developers / users can have more or less fine-grained control over these issues. A simple implementation of the high level APIs would be a slim wrapper around existing libraries, while for fine-grained control more work is needed. It would thus be an interesting exercise to see whether existing GUIs can be mapped back to the above modules I suggest. Regards, Stefan [View Less]

2 1

dummy
by Andy Little 01 Oct '05

01 Oct '05

1 3