- Boost - lists.boost.org

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

test - please ignore
by Peter Dimov 24 Sep '04

24 Sep '04

My mail server is down, and gmane posts I made didn't seem to appear, now trying with the alternate address. Apologies for the wasted bandwidth. -- Peter Dimov http://www.pdimov.com

1 0

[boost.config] mipspro
by Thorsten Ottosen 24 Sep '04

24 Sep '04

Hi, In the range regression I get errors like cc-1282 CC: ERROR File = /txusr/rwgrosse/boost_regression/boost/boost/range/empty.hpp, Line = 38 More than one instance of overloaded function "boost::begin" matches the argument list. Function symbol function template "boost::begin(T &)" is ambiguous by inheritance. Function symbol function template "boost::begin(const T &)" is ambiguous by inheritance. The argument types are: (const std::pair<std::vector<int, std::allocator<int>>::iterator, std::vector<int, std::allocator<int>>::iterator>). return boost::begin( c ) == boost::end( c ); I don't know this compiler, but could it be that it does not configures BOOST_NO_FUNCTION_TEMPLATE_ORDERING properly? (I assume by the error above mipspro should define the macro to 1) If so, can somebody fix it? Thanks Thorsten

3 8

[Thread] TSS + static linking status
by Aleksey Gurtovoy 24 Sep '04

24 Sep '04

What's the status of TSS cleanup issue in static library configuration for the following compilers: CodeWarrior 8.3 MinGW GCC 3.x Borland 5.6.4 Intel C++ 7.1 (for Windows) ? Should the corresponding test's failures (e.g. http://tinyurl.com/6v6sd) be marked as expected? -- Aleksey Gurtovoy MetaCommunications Engineering

4 13

[Thread] Read-write mutex failures with CodeWarrior/Intel 7.1
by Aleksey Gurtovoy 24 Sep '04

24 Sep '04

"test_read_write_mutex" fails with a similar output at run time on CodeWarrior 8.3 and Intel 7.1 (both Windows and Linux): http://tinyurl.com/62dwn, http://tinyurl.com/46dsp http://tinyurl.com/5h66a http://tinyurl.com/7287k Are these expected failures? -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

RE: [boost] OutFmt library implementation questions
by Rozental, Gennadiy 24 Sep '04

24 Sep '04

> > > Use the ex< DelimiterType > variant on the innermost construct. > > > >This is unacceptable and does not follow standard practice. > > The new version templates that are templatized on character > type are also templatized on the format object that they use (to render > their elements). You keep repeating that you have some completely reworked version. Well let's see it next time. Then I will be able to comment on it. > > > >7. What deducer is supposed to deduce? I couldn't get > >IMO all that you needed is function overloading. I don't see a place > >for > >all > >these deduce/trats staff. > > Consider the pair format object (pair renderer): how do you > render each pair > type. Using function overloading, you would have: > > class basic_pair > { > public: > OutStream & write( OutStream & os, const std::pair< > T1, T2 > & p ){ > ... } > OutStream & write( OutStream & os, const > boost::compact_pair< T1, > T2 > & p ){ ... } > OutStream & write( OutStream & os, const > std::complex< T > & p ){ > ... } > OutStream & write( OutStream & os, const > boost::math::interval< T > > & p ){ ... } > }; > > But this would add dependencies on those libraries. Also, it is not > extensible: how do you add support for boost::rational< T >, > for instance? I am not sure I understand what you writing here. What I meant is something trivial like this: Template<typename C> ContanerFormatter<C> Foo( C const& ); // this together with ContanerFormatter is defined in pair general header Template<...> PairFormatter<..> Foo( pair<...> const& ); // this together with PairFormatter is defined in pair specific header Template<...> RationalFormatter<..> Foo( pair<...> const& ); // this together with RationalFormatter is defined in boost:: specific header And so on. Why wouldn't it work? > Using the deduction mechanism, I implement the output using > boost::io::detail::getval< n >( pair_type ). Input is more > complex because > you need to distinguish between types that you can get the elements > separately (e.g. std::pair) and types that you need to set > both values > together (e.g. boost::math::rational): the former uses > refval< n >( type ) > and the latter uses assignval( type, first, second ). > > How would function overloading solve this? (Note, function > overloading is > used for getval, refval and assignval). > > For containers, you need to use a different function/function > arguments to > insert an element depending on whether the container is sequential, > associative or a set. If you need to handle input then in addition you would add Template<typename T> VectorFormatter<T> Foo( std::vector<T> const& ); // this together with VectorFormatter is defined in vector specific header > My library provides a description of the types that it can > render (e.g. > separable pairs, 4-ary types, associative containers) without > saying what > these types are. The stl and boost directories in my library > then tell my > library that a std::vector is a sequential container. My > library then knows > how to handle a std::vector. Doing this, I can separate the > dependencies on > external libraries and allow it to be extended to support > other sequential > containers, pairs, etc. I don't see ANY need for all this complex staff when simple overloading/partial ordering will do the trick. > formatob_t::format returns *this because the FormatObject > (Renderer) that it > inherits returns a value of type FormatObject. Thus, if you > didn't have > these overloads, then: > > std::cout << formatob( vec ).format( " + " ); > > would not work, since it will try to output a containerfmt() type. Your code : inline formatob_t & format( format_type s) { FormatObject::format( s ); return( *this ); } formatob( vec ).format( " + " ) has the same type as formatob( vec ) What are you talking about? Why would you bother what FormatObject::format is returning? > Regards, > Reece Gennadiy.

4 5

RE: [boost] Re: Re: C++ GUI - another view
by Brian Braatz 24 Sep '04

24 Sep '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Noah Stein [Brian Braatz] (Snip)_ > > Yes..As I have touched in in a previous post this should be accessible > at > > the 'device layer'. OTOH Another way to look at a pixel is as a > > rectangular > > box that is *currently*, *on this device*, (say) 0.25 mm wide and 0.25 > mm > > high or whatever, the next layer up. > > What does "accessible at the device layer" mean in this context? A pixel > is > a fundamental unit in any graphics context. I don't think that an > application programmer should be forced to jump through hoops to get at > it. > [Brian Braatz] I have been watching this one for a bit now and it is time for me to weigh in. I have 2 perspectives to share: ** Encapsulation of common functionality in UI frameworks*** I am working on a framework that sits on top of boost for the purpose of making Thick Client DB apps. One of the things that I am going to be needing is a *light* layer over the various windowing libraries out there. What I need is about 20% of the common functionality between MFC\ Winforms\ Qt\ WxWindows in standard wrapper classes. This will allow me to write "most" of my applications to that interface and select the underlying platform\ framework as a build target. I mention my problem domain, because I believe it to be a rather common one. I also agree with the notion that it takes *alot* of effort to fully encapsulate a GUI. What I would LIKE would be a simple windowing system that I can use, maybe it is not the most robust, but it is "boost standard". This would then allow me to write portable Gui applications. In so far as paradigm, this would mean choosing between the common model features of the above libraries. I will be developing this, and may eventually submit it to boost, but if someone does before me, all the better. I just eventually want something that is "standard" in some way that gives me platform \framework isolation. *** Simple windowing layer needed for Boost ** I would like to also develop some GUI tools that do things like allow one to: * "step through" bjam files interactively \ debug * Show a "report" of my command line configuration outlining what appears to be set correctly (i.e. doxygen will not work in your config because variable XX is not set to a valid path) (maybe even a little cartoon dog that wags his tail if your vars are set properly) (<< JUST KIDDING) I believe simple gui tools along those lines would help the usage and spread of boost in general, and would help those who use boost on a day to day basis. To support that concept- I suggest something along the lines of the TinyXML library buried somewhere in boost. It is a bare bones lib that gets the job done. If we were to have: * Ability to create dialogs * make buttons and respond to them * make edit controls and read and write to them * make list boxes and manipulate them * make a tree control and manipulate it As a *very* simple and light library, this would allow me to make simple GUI apps that were "boost standard". The above functionality should be simple enough to do with Raw API calls on the various platforms. I would ask that those considering GUI libs take my perspective seriously, as the greatest value that can be had is "having something simple that is standard", more than it is in making something do everything. This would also provide a small incremental step to address many of the interesting ideas that have been put forth on this thread. :) (my 2 cents) Brian Braatz

2 1