Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2004-03-03 12:18:06

> Many C++ people like shallow copy things to explicitly have a
> pointer-like
> syntax. I, personally, can happily tolerate either.
> For an apples to apples comparison,
> window w("Example window");
> should be compared with
> window w = create_window("Example window");

Shrug. I'm not a GUI person, in large part because every time I look
into it,
I end up deciding that it's far more work to learn how to use than the
would justify. A boost-supported cross platform GUI would definitely
go far in
addressing the issue of not wanting to invest time learning something
which is
largely tied to a single platform. But what I'd really like to see is
a system that allows
one to accomplish conceptually simple things in a correspondingly
simple way, with
sensible default behavior of any aspects which aren't explicitly
specified and a minimum
of exposed implementation details to contend with. While window may
very well be implemented
as a pointer, I don't see how that fact should be relevant to the user
of the library (other
than, I suspect, historical antecedents). Of course, I understand that
I'm an atypical
programmer in that the bulk of my code is written solely for my own use
or the use of
other scientists rather than end users, and a GUI would be nice but is

> w.wait_for( delete_signal() );
> just introduces a redundant top-level tag class and a corresponding
> redundant window_base overload.

I would be willing to sacrifice added complexity of implementation to
have a more
intuitive syntax. Unless I'm reading this wrong, what


is trying to say is that w should wait for a generic delete signal -
that is, delete_signal isn't
really something that belongs to the window type but is instead an
abstract directive to a
window (or button or widget or whatever) to delete itself. What it
actually says to me, on
reading it, is that the main program is waiting for a signal from w to
quit running. Anyway,
bear in mind that this is all coming from a computational physicist
with no real experience
in GUI programming who'd love to see something simple and intuitive

Matthias Schabel, Ph.D.
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT 84108
801-587-9413 (work)
801-585-3592 (fax)
801-706-5760 (cell)
801-484-0811 (home)
mschabel at ucair med utah edu

Boost list run by bdawes at, gregod at, cpdaniel at, john at