- Boost - lists.boost.org

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

FORMAL Review of "Output Formatter" library - 2 days left
by John Torjo 24 Sep '04

24 Sep '04

Dear boosters, For the FORMAL Review of "Output Formatter" - there are 2 days left. (it will end on this sunday) Author: Reece Dunn Description: The outfmt library provides means to write and read containers/ arrays/ ranges (pairs of iterators) to/from STL streams. It also provides means to customize formatting as your write to/read from a stream: std::list<int> l; // { 1, 4, 10 } std::cout << formatob(l); // output: [ 1, 4, 10 ] std::cout << formatob(l).format("<",">"); // output: <1, 4, 10> Download: You can get it from the boost sandbox: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/outf… http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/out… As a convenience (only for the period of the review), you can also get it from http://www.torjo.com/code/outfmt.zip (153Kb) Review process: Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. When doing the formal review, please answer the following questions: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And most important, 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. More on the formal review process: http://www.boost.org/more/formal_review_process.htm The Review Manager is: John Torjo john.lists(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/

1 0

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

24 Sep '04

> From: Reece Dunn [mailto:msclrhd@hotmail.com] > Sent: September 24, 2004 11:05 > There is also the issue of dynamically creating the GUI. If > you create a > docking/floating toolbar for example, which object stores the > toolbar? > The docked frame or the floating frame? > > Also, what if you have a large number of GUI components? > Storing them in > the frame class would just increase the size of the object to > the point > where it is unusable. > > Also, doing: > > frame.add( gui::button( "Boost!" )); > frame.add( gui::textbox( "Hello", 25, true )); > > would incur copy penalties. What if you want to share the same object > across multiple objects (e.g. the docking/floating frame) instead of > making a separate copy of it. Indeed. This question is much more than a simple matter of convenience. Some toolkits use a 'scene graph' - like approach, where 'outer' widgets wrap ('decorate') inner ones. Following this path further, widgets could be shared by multiple parents, i.e. they could be rendered at multiple positions on the screen (or multiple screens) at the same time. I'v been working on the fresco project (http://www.fresco.org) and there we push it even further: widgets are owned by the 'display server' which applications talk to remotely (fresco is, much as X, network transparent). So the object the application holds is just a proxy that will forward all requests to the display server. Regards, Stefan

1 0

[signals]: Making copies of a slot
by Jody Hagins 24 Sep '04

24 Sep '04

AFICT, the rationale for copying a slot is missing, hence the following questions... boost::signal<void (int)> some_signal; Some_Slot slot1; some_signal.connect(slot1); Some_Slot slot2(slot1); some_signal(42); The above code will only signal slot1. If slot2 is a copy of slot1, should it also get the signal? I know it does not work that way, but I was wondering why that decision was made. Also, if I *do* want the copy to receive the same signals, how can I do so? Thanks!

2 3

RE: [boost] [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 24 Sep '04

24 Sep '04

John Torjo <john.lists(a)torjo.com> wrote; > Hi Peter, > > I think there is a bug in your Interlocked* implementation of > shared_ptr > (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) > > In atomic_read you have: > inline long atomic_read(long volatile const & value) > { > return value; > } > > I don't believe this is thread-safe. > In order to make sure you're receiving the latest value, I don't believe that's actually important. What's important is that shared memory accesses are not reordered. The "volatile" should prevent the compiler from reordering the read with respect to other volatile access, but that leaves the question of whether the processor may reorder the read with respect to other shared memory access. I think the answer is that it cannot change the order of an atomic_read and an atomic update, assuming that the latter uses an Interlocked* operations which includes a full memory barrier, but unfortunately it would be able to change the order of two atomic_reads. (Unfortunately www.pdimov.com does not want to talk to me so I haven't been able to read the rest of the code.) > I assume you could do something like: > > inline long atomic_read(long volatile & value) > { > const int IMPOSSIBLE_VALUE = -100; > return InterlockedCompareExchange(&value, IMPOSSIBLE_VALUE, > IMPOSSIBLE_VALUE); > } > > Am I missing something? That looks reasonable, yet I feel that there should be a better way to do this! Note that InterlockedCompareExchange is not available in early Win32 implementations (NT 3.x and Win95).

2 2

tuples::for_each
by Maxim Yegorushkin 24 Sep '04

24 Sep '04

I was working on some code where I got some parameters as pairs of strings [name, value]. In my code I needed to convert those values to int's, doubles, etc (i.e. deserialize). And I wanted to convert them in bunch. I thought it was a great job for lexical_cast and tuple::tie. The only thing I missed was something like for_each for tuples. Is there going to be such a mechanism? Here is an example: template<class T, class F> inline void for_each(boost::tuples::cons<T, boost::tuples::null_type> const& tuple, F f) { f(tuple.get_head()); } template<class T, class U, class F> inline void for_each(boost::tuples::cons<T, U> const& tuple, F f) { f(tuple.get_head()); for_each(tuple.get_tail(), f); } struct printer { template<class T> void operator()(T& t) const { cout << typeid(t).name() << " (" << t << ")\n"; } }; typedef std::map<std::string, std::string> parameters; struct lexical_caster { parameters const* p; char const* name; template<class T> void operator()(T& t) { parameters::key_type const k(name); parameters::const_iterator i(p->find(k)); if(p->end() == i) throw std::runtime_error("a parameter is not found"); t = boost::lexical_cast<T>(i->second); name += 1 + k.size(); } }; int main() { bool b(1); char c('a'); int i(12345); double d(3.1428); for_each(boost::tie(b, c, i, d), printer()); parameters p; p["bool"] = "0"; p["char"] = "b"; p["int"] = "67890"; p["double"] = "1.6"; lexical_caster l = { &p, "bool\0char\0int\0double\0" }; for_each(boost::tie(b, c, i, d), l); for_each(boost::tie(b, c, i, d), printer()); } -- Maxim Yegorushkin

3 3