September 2005 - Boost - lists.boost.org

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

12 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 its integer types by keeping >> the current types at their 32-bit-era sizes and extended the type >> system with a "long long" instead of moving "int" and "long" up and >> adding a "short short". Now we don't have a convenient way to name >> the best integer type in a portable fashion. I suggest we add a >> "int_natural_t" typedef to <boost/cstdint.hpp> to name the best >> integer type (and a corresponding "uint_natural_t"). We would have >> to research what that type is for each compiler and/or platform >> combination and use #conditionals. I don't think it's worth it. The performance difference between a 16-bit integer and 32-bit integer on a PDP-11 was pretty significant. Is there any noticable difference between a 32-bit and 64-bit integer on any of the 64-bit processors? > Isn't int the 'natural' integer type, by definition? Depends what you mean by "natural", but for a normal English meaning, probably not. > I never understood why long didn't become the 64-bit type. It seems > pointless to have int and long the same size on 32-bit. Oh god no! The thread that would not die! This has been argued to death on comp.std.c. The reason long didn't become the 64-bit type is that most commercial C compiler vendors wanted to continue to support code their customers had written that assumed long was exactly four eight-bit bytes. You can argue as long as you like that the problem is in that code (and I would agree with you). It won't change the fact that telling your customers they are wrong is not usually the route to commercial success. > Who still writes 16-bit code on desktop, anyway? :D Nobody ... but who still writes for the desktop? Think about the number of car radios (as just one example) compared to the number of PCs. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

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 behind the implementation - and for those of us who simply don't have the technical background to "just know" the answer at a glance, as I'm sure some of you contributors do - why not provide a simple rationale for adding a particular member function to a particular class? I'm all for sharing, but I would like to know the reason for half the implementation. I believe this would give something new to the C++ community in a simpler way than has been done in the past - information generally gathered individually and painfully over years of study. Thanks, John Calcote Novell, Inc.

5 4

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

05 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 simple yet >> also class specific. I currently implement it like this: [snip classic pimpl idiom] > The only thing my library does is to initialize the forward declared > class, using heap or static memory through policies. Also, provides an > easy way of accessing the data. > > Eg. > > .hpp > > boost::pimpl<struct CMyData> m_MyData; > > .cpp > > struct CMyData > { > CMyData() > : m_Integer(0) > { > } > int m_Integer; > }; > > /// Data access > m_MyData->m_Integer = 2341; > > The CMyData will be initialized the first time its data members are > accessed. That means each use of m_MyData operator ->() has got to check whether the structure is initialized or not, and initialize it if so. Isn't it much easier to initialize the pimpl struct in the constructor of the outer class? I also don't see how much easier it can get to access the data than to write: pimpl->m_Integer -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

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 providing relational containers in Boost? Are there any features/improvements you can suggest for RML? Many thanks, Calum

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 any sign of a 3-argument version of at; everything seems to be defined in terms of a 2-argument template. Am I doing something wrong, or is this a bug?

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 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.

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 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

2 1

dummy
by Andy Little 01 Oct '05

01 Oct '05

1 3