- Boost - lists.boost.org

Re: [boost] [multi_index + mpl + bind] Regression?
by JOAQUIN LOPEZ MU?Z 25 Sep '04

25 Sep '04

Vladimir, I don't have my compiler handy right now, but I think this is due to an overlook when doing the adaptation to the new MPL. In particular, the line 50 in boost/multi_index/detail/node_type.hpp: typedef typename IndexSpecifierIterator::type index_specifier; should be changed to typedef typename mpl::deref<IndexSpecifierIterator>::type index_specifier; (also, the corresponginf #include <boost/mp/defer.hpp> must be inserted) Could you please try this locally and report the results? If the problem is solved, I'll commit something along this line next Monday. I don't know the rationale for having to use deref, since I thought these two expressions are equivalent, but there must be some difference, for Alexsey changed some of the code in multi_index to do that when mergien the new MPL. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ----- Mensaje original ----- De: Vladimir Prus <ghost(a)cs.msu.su> Fecha: Sábado, Septiembre 25, 2004 2:41 pm Asunto: [boost] [multi_index + mpl + bind] Regression? > > The attached code, which use the multi_index library, produces > screens of > errors from mpl. The STLfilted log is attached too. > > Commenting out #include <boost/bind/arg.hpp> makes the error go > away, as well > as including it after multi_index. > > This happens with: > gcc version 3.3.4 (Debian 1:3.3.4-6sarge1) > gcc version 3.4.1 (Debian 3.4.1-4sarge1) > > The code used to work some time ago, but I can't give the exact date. > > I've tried too look at the problem, but got lost in MPL internals. > > - Volodya > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[multi_index + mpl + bind] Regression?
by Vladimir Prus 25 Sep '04

25 Sep '04

The attached code, which use the multi_index library, produces screens of errors from mpl. The STLfilted log is attached too. Commenting out #include <boost/bind/arg.hpp> makes the error go away, as well as including it after multi_index. This happens with: gcc version 3.3.4 (Debian 1:3.3.4-6sarge1) gcc version 3.4.1 (Debian 3.4.1-4sarge1) The code used to work some time ago, but I can't give the exact date. I've tried too look at the problem, but got lost in MPL internals. - Volodya

1 0

[serialization] scoped_ptr.hpp broken
by Vladimir Prus 25 Sep '04

25 Sep '04

Hello, I'm getting this error: ......./boost/boost/serialization/scoped_ptr.hpp:36: error: `make_nvp' undeclared (first use this function) The attached patch fixes the problem. BTW, Robert, this problem was introduce when you moved the content of the header from boost::serialization to just boost::. What was the rationale? The log only says: fixes for cw/comeau implement ADL - Volodya

1 0

RE: [boost] Re: GUI Windowing Framework in C++
by Brian Braatz 25 Sep '04

25 Sep '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Thomas Witt > Sent: Friday, September 24, 2004 7:21 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: GUI Windowing Framework in C++ > > David Abrahams wrote: > > Reece Dunn <msclrhd(a)hotmail.com> writes: > > > >>[1] Support constructor-based window creation, e.g.: > >> > >> frame.add( new gui::button( "Boost!" )); > > > > > > Get rid of the new operator, though. IMO there's no excuse for a GUI > > framework to expose users to unmanaged resources. > > Hmm, do you know of a C++ GUI framework that gets this right? > > Just curious [Brian Braatz] The problem is handling the "dual lifetimes" of "system" GUI objects and C++ objects. BeOS is the only system I know that does not have this issue, because they extended C++ in such a way so that when you "create" a C++ window object- you now have a window. In frameworks like MFC, they have to internally track a windows resources "object" that the system understands as the gui object. You will always need a dynamic nature to things, but one could take a Rogue Wave approach here and hide all those new's behind accessor type objects which pass around by value and internally hold something like a boost::shared_ptr<> (my 2 cents) Brian

2 1

RE: [boost] C++ GUI - another view
by Reece Dunn 25 Sep '04

25 Sep '04

Andy Little wrote: >Recent discussions on boost have talked about GUI's in quite technical >terms, windowing etc. Another part of the abstraction is simply that of >providing an area for drawing on. The code below is a simple example of >what >I mean. The "drawFunction" is meant to be like a graphics version of a >main() function .( Note that there should ideally be no DeviceHandle >visible >to the "drawFunction". The DeviceHandle should be wrapped in the GX object, >passed to the function so some of the impl is poking through here in form >of >the gx.line_to etc functions 'hdc' argument. Its early days.) Your code looks good, but here are a few comments: [1] The general impression from users of a GUI library is that they are against using a template-based library. [2] The DeviceHandle should be hidden via an interface and have an implementation for *nix, mac, Windows and others. [3] I strongly recommend that the graphical side (devices, pens, brushes, images, fonts, etc.) be separate from the GUI (windows/widgets, events, etc.). The GUI framework will make use of the graphics framework for drawing to a window's client area. [4] I like how you specify independant coordinates. Is this customizable (i.e. can you change between pixels, cm, inches, etc.) and can you convert between coordinate systems (e.g. when implementing a web browser, CSS units can be percentages, cm, pc, pt, etc.)? [5] Can you get the width and height of the drawing rectangle? Is it possible to create a scrolling view of a larger drawing area? Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

11 28

Addition for shared_ptr
by Michael Rutman 25 Sep '04

25 Sep '04

I'd like to propose adding a template function to shared_ptr to allow the automatic testing of a shared_ptr to its raw ptr. The template is as simple as template <class T> bool operator==(boost::shared_ptr<T> const & a, T * const & b) { return a.get() == b; } Here is the case where I need it. I have a vector<Foo> myFoo. In a method of Foo I need to see if this instance is in the vector. I want to do this vector<Foo>::iterator iter = find( myFoo.begin(), myFoo.end(), this );

4 9

[Pointer Containers] [Indexed Set]
by Bruno Martínez Aguerre 24 Sep '04

24 Sep '04

Hi. I was wondering if these two libs work together. That is, can Indexed Sets take ownership of my pointers? Also, I couldn't find the docs for neither of the two libs. I looked here http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/libraries.h… for Indexed Set, and here http://boost-consulting.com/boost/more/formal_review_schedule.html for Pointer Containers. I think these two are the best places for it. Bruno Martinez

2 1

Re: CW 9.3 results (or lack thereof) - current state
by Michael Stevens 24 Sep '04

24 Sep '04

Stefan, > After one day and one night of investigation, I think (!) I've finally > managed to make bjam report correct results for my regressions. Your perseverance is much appreciated. > The results for CW-9.3 seem to be correct now and thus there should be > some more failing test cases for this toolset now. I have fixed the compilation problem with uBLAS you reported. So I was looking forward to seeing the results. Now I see the runtime errors so there is still work to be done! Thanks, Michael

2 1

RE: [boost] Re: GUI Windowing Framework in C++
by Ben Hutchings 24 Sep '04

24 Sep '04

Brian Braatz <brianb(a)rmtg.com> wrote: [Thomas Witt wrote:] > > David Abrahams wrote: > > > Reece Dunn <msclrhd(a)hotmail.com> writes: > > > > > >>[1] Support constructor-based window creation, e.g.: > > >> > > >> frame.add( new gui::button( "Boost!" )); > > > > > > > > > Get rid of the new operator, though. IMO there's no excuse for a > > > GUI framework to expose users to unmanaged resources. > > > > Hmm, do you know of a C++ GUI framework that gets this right? > > > > Just curious > [Brian Braatz] > The problem is handling the "dual lifetimes" of "system" GUI objects > and C++ objects. > > BeOS is the only system I know that does not have this issue, because > they extended C++ in such a way so that when you "create" a C++ window > object- you now have a window. Be didn't extend C++; they just decided to use C++ for most of the system APIs rather than providing C APIs and C++ wrappers for them. (A problem with this approach is that it's difficult to preserve binary compatibility in C++ interfaces while extending them; also, language changes have forced ABI changes in some compilers over the past few years.) > In frameworks like MFC, they have to internally track a windows > resources "object" that the system understands as the gui object. Even in BeOS there is some kind of handle underneath, because windows are managed by a separate process called the application server. It seems to me that the annoyance of mismatched lifetimes in MFC is due to its design as a thin wrapper over the Windows API at a time when the language (or at least the MS implementation) did not have exceptions. This resulted in the evils of two-phase construction. Qt seems to have managed to avoid this, despite not using exceptions, by being a more heavyweight wrapper. > You will always need a dynamic nature to things, but one could take a > Rogue Wave approach here and hide all those new's behind accessor type > objects which pass around by value and internally hold > something like a > boost::shared_ptr<> That may well be a good approach.

2 1

Re:Re: [boost] [program_options] cw9.3 failures
by Robert Ramey 24 Sep '04

24 Sep '04

Howard Hinnant wrote: >How are clients (who can view only parsers.hpp) to know that: >template<> > basic_parsed_options<char> > parse_config_file(std::basic_istream<char>& is, > const options_description& desc); >is a function to be imported from a DLL? Does adding to parsers.hpp >something like: >template<> __declspec(dllimport) > basic_parsed_options<char> > parse_config_file(std::basic_istream<char>& is, > const options_description& desc); >help? I believe that most of the failures of the serialization library with toolset are due to similar problems. There we have Template<class T> Struct A : public Abase { A(const char * name){ //register this instance in a global table Register(this, name); } // static instance to be created at pre-runtime Static A instance; do_something(); }; Template<class T> Static A A::instance("T"); So that later when // lookup T Abase *ab = std::find("T") Ab->do_something(); It seems that the compiler optimizes away the code since its never explicitly called. An attempt to find the class through its name fails, the code isn't found, and the test fails. I've attempted to force instantiation of the code through various means such as dllexport and others. This solved the problem for other compilers but I've been unable to get it to work for Metrowerks. Alas my, 15 trial license expired so it will have to remain as it is until someone with an interest in this compiler decides they want to spend some time on this. Robert Ramey

1 0