--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
Apropos of which, I now think that the Boost UserAllocator requirements
should be the default for components that parameterize how they use
memory, with the Standard Allocator requirements being used only for
components that need what they
--- David Abrahams [EMAIL PROTECTED] wrote:
But indeed allocate/construct/deallocate/destroy is more work than
^^^^
Oyeah. These two absolutely don't belong in allocator, period. Do
any implementations even use them? Allocators exist to
--- David Abrahams [EMAIL PROTECTED] wrote:
[...]
Just how do you propose to prevent people from writing their own
construct/destroy functions? And if they write an allocator from
scratch, but *don't* provide construct/destroy manually, where will
they come from?
What I meant is that if
--- David Abrahams [EMAIL PROTECTED] wrote:
[...]
I think construct/destroy can be implemented as non-customizable
static functions in boost just for convinence.
I think the word static is not what you meant, and is what led me
to challenge the suggestion.
I used word 'static' because
--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
3. If your class is using STL containers, use boost::memory::allocator
adapter (see bellow).
Why not just use std::allocator?
Because boost::memory::allocator will use UserAllocator under the covers.
So if you customized UserAllocator
--- Gregory Colvin [EMAIL PROTECTED] wrote:
[...]
T* _p;
Leading underscores are a no-no.
I didn't see it in boost naming convention docs.
Have I missed it?
Some STL implmentations use leading underscores for members.
Eugene
__
Do you Yahoo!?
Yahoo!
--- Gregory Colvin [EMAIL PROTECTED] wrote:
At the least, we could add the following bullet
* Discussion of memory management strategy.
to http://www.boost.org/more/lib_guide.htm#Documentation
I think it is a great start.
I'm reluctant to say very much more at this point, as my
I'd like to start a new thread with Gregory's suggestion
and my comments.
Gregory Colvin wrote:
At the least, we could add the following bullet
* Discussion of memory management strategy.
to http://www.boost.org/more/lib_guide.htm#Documentation
I'm reluctant to say very much more
--- Gregory Colvin [EMAIL PROTECTED] wrote:
On Friday, Aug 29, 2003, at 18:16 America/Denver, E. Gladyshev wrote:
There is a tradeoff between possibly better performance and possibly
unwanted dependancies.
This is why we call them guidelines for now.
It is up to the developer to consider
--- Gregory Colvin [EMAIL PROTECTED] wrote:
And I have no objection myself to adding an allocator parameter
to the shared_ptr constructor, or to making some other change that
serves the purpose. So if you need a change, why not just do it,
try it out, and submit a patch?
Just wondering
--- Gregory Colvin [EMAIL PROTECTED] wrote:
On Thursday, Aug 28, 2003, at 16:26 America/Denver, E. Gladyshev wrote:
--- Gregory Colvin [EMAIL PROTECTED] wrote:
How will I even know it, the documentation is completely
ignorant on the memory issues.
Perhaps because you work
--- Gregory Colvin [EMAIL PROTECTED] wrote:
shared_ptr doesn't allocate the data, it only deletes it, which is the
job of the
current deleter parameter. And the counter type is by design not part
of the
shared_ptr type, so it doesn't belong as parameter to the shared_ptr
template.
--- Gregory Colvin [EMAIL PROTECTED] wrote:
On Thursday, Aug 28, 2003, at 23:48 America/Denver, E. Gladyshev wrote:
*pseudo-code*
template typename T
sturct my_allocator
{
my_heap_control _heap;
T* create()
{
return _heap.create();
}
void operator
--- Gregory Colvin [EMAIL PROTECTED] wrote:
The C++ standard requires that a copy of an allocator is equivalent
to the original.
Right. If your allocators can't be copied safely then you have a
problem. Peter's approach is one way to fix the problem. But I
don't see that shared_ptr has
--- Gregory Colvin [EMAIL PROTECTED] wrote:
Bullshit:
templateclass Y, class D shared_ptr(Y * p, D d);
Requirements: p must be convertible to T *. D must be
CopyConstructible. The copy constructor and destructor of D
must not throw. The expression d(p) must be well-formed,
--- Gregory Colvin [EMAIL PROTECTED] wrote:
On Friday, Aug 29, 2003, at 13:57 America/Denver, Gregory Colvin wrote:
On Friday, Aug 29, 2003, at 13:34 America/Denver, E. Gladyshev wrote:
...
All I am trying to say is that shared_ptr doesn't specify
any requirements on its Deleter
--- Peter Dimov [EMAIL PROTECTED] wrote:
You can use all smart pointers except shared_ptr and shared_array as they do
not allocate any memory. In particular, intrusive_ptr is a good candidate if
memory is a concern as it has smaller memory footprint than shared_ptr.
Thanks, I'll consider it
--- Gregory Colvin [EMAIL PROTECTED] wrote:
How will I even know it, the documentation is completely
ignorant on the memory issues.
Perhaps because you work with the authors of the documentation to
make it sure it says what needs saying?
Are the documentation authors monitoring this
--- Douglas Gregor [EMAIL PROTECTED] wrote:
On Thursday 28 August 2003 04:40 pm, Gregory Colvin wrote:
I also have no objection, and much sympathy, for having a clear
memory management policy for Boost libraries. But again, it is a
matter of people who care about and understand the issue
--- Peter Dimov [EMAIL PROTECTED] wrote:
E. Gladyshev wrote:
--- Peter Dimov [EMAIL PROTECTED] wrote:
unless there are very solid reasons for the allocator parameter. ;-)
I agree, but the problme is that I don't know whether I have a solid
reason or not.
I have to ship my class
--- E. Gladyshev [EMAIL PROTECTED] wrote:
--- Peter Dimov [EMAIL PROTECTED] wrote:
E. Gladyshev wrote:
--- Peter Dimov [EMAIL PROTECTED] wrote:
unless there are very solid reasons for the allocator parameter. ;-)
I agree, but the problme is that I don't know whether I have
--- E. Gladyshev [EMAIL PROTECTED] wrote:
--- Peter Dimov [EMAIL PROTECTED] wrote:
E. Gladyshev wrote:
--- Peter Dimov [EMAIL PROTECTED] wrote:
unless there are very solid reasons for the allocator parameter. ;-)
I agree, but the problme is that I don't know whether I have
--- David Abrahams [EMAIL PROTECTED] wrote:
E. Gladyshev [EMAIL PROTECTED] writes:
I am afraid that some of the boost libraries (as they are now) won't
work for a big group of real time and embedded developers, where
customization is the key.
Is it really (other than culturally, I
--- David Abrahams [EMAIL PROTECTED] wrote:
E. Gladyshev [EMAIL PROTECTED] writes:
--- David Abrahams [EMAIL PROTECTED] wrote:
Yes, I am sure. I shipped one of my libraries to a guy who
works on various DSP chips. The native memory allocator
on one of the DSP was very slow (some
--- Daryle Walker [EMAIL PROTECTED] wrote:
On Monday, August 25, 2003, at 2:57 PM, Peter Dimov wrote:
has-bugs/is-slow/plain-old-sucks? There can be an orthogonal need for
a different allocator class, which no improvement on the default one
can fix.
In this case, the Java user is 100%
--- Peter Dimov [EMAIL PROTECTED] wrote:
E. Gladyshev wrote:
I guess my question is that, is boost redefining the
memory management concepts that have been established by STL?
Yes and no. The STL uses allocators for containers. Most non-containers do
not have an allocator parameter
--- Gregory Colvin [EMAIL PROTECTED] wrote:
For shared_ptr the count is allocated by the following line in the
shared_count
constructor:
new sp_counted_base_implP, D(p, d);
So it might be possible to make the allocation customizable by
specializing
sp_counted_base_impl.
I think
--- Peter Dimov [EMAIL PROTECTED] wrote:
[...]
templateclass A struct X
{
typedef typename A::value_type T;
static T * create(A a)
{
T * p = a.allocate(1);
try
{
new(p) T;
}
catch(...)
{
--- Peter Dimov [EMAIL PROTECTED] wrote:
E. Gladyshev wrote:
--- Peter Dimov [EMAIL PROTECTED] wrote:
unless there are very solid reasons for the allocator parameter. ;-)
I agree, but the problme is that I don't know whether I have a solid
reason or not.
I have to ship my class
--- Peter Dimov [EMAIL PROTECTED] wrote:
The danger in that statement is that it looks obvious, but it's not. It is
true in some sotuations (not as frequent as is generally believed) and false
in others, and when it doesn't really hold but is axiomatically accepted as
truth, it serves as
--- Andreas Huber [EMAIL PROTECTED] wrote:
[snip]
So far my experience indicates that people only bother with
allocators when std::allocator is inadequate, i.e. slow.
... or non-deterministic. Using such an allocator in a hard real-time system
is simply not an option.
AFAIK, a
--- Andreas Huber [EMAIL PROTECTED] wrote:
[...]
BTW: Having separate heaps is one of the reasons why I could not
use boost::shared_ptr. I ended up writing my own. :(
Yeah, I ended up using intrusive_ptr. Not always an option either ...
In fact it is not clear how to marry STL and
--- Peter Dimov [EMAIL PROTECTED] wrote:
In this context, an allocator parameter is only an excuse for implementors
to avoid doing the necessary work to make function useful out of the box.
You can always use a custom allocator, right?
Considering the variety of real life requirements and
I'd be interested in such library.
I think that boos::xml library should be using boost::spirit
for parsing XML streams.
Eugene
--- Wojtek Surowka [EMAIL PROTECTED] wrote:
I think that what is still missing in Boost is a library for reading and
writing XML files. I have such a library, though
I am wondering what happened to the allocator idiom in
boost. Was it left out intentially?
I can control all memory allocation details in STL
(orthogonally to data types) but not in boost.
It seems like a step backward comparing to STL.
How can I use allocators with shared_ptr? Is there any
way
--- Philippe A. Bouchard [EMAIL PROTECTED]
wrote:
Here are some of my postings on the name and project
issues.
Brock and I liked the Notus (god of the south wind)
name.
BTW Brock said that he is in!
I'll be working on setting up the Notus (code name)
project on sf
--- Brock Peabody [EMAIL PROTECTED]
wrote:
For an exaggerated example, imagine that we design
and implement layer
one knowing nothing about any GUI APIs besides
Win32. We'll probably
have to make a lot of revisions if we then want to
make that scheme fit
over a *nix GUI API.
I agree.
--- Brock Peabody [EMAIL PROTECTED]
wrote:
I think now we need to decide which
*nix GUI API to use
and get started on a proof of concept.
I am currently working with win32 only. I can take
care of this one. I think it'll be nice to have
support for X as well.
Maybe we should decide which
--- Brock Peabody [EMAIL PROTECTED]
wrote:
Don't know where to start...
Greek and Roman mythology?
'Aquilo' the north wind, the ruler of the winds.
'Notus' the south wind
'Flora' goddess of flowers and spring.
'Arcadia' a district of the Peloponnesus, the home
of
pastoral
--- Douglas Gregor [EMAIL PROTECTED] wrote:
The Boost.Threads library defines its own threading
model and implements it
on several platforms. If two distinct threading
models are useful with the
Boost.Threads model, then it can be extended to
support that model. Windows'
two threading
--- Philippe A. Bouchard [EMAIL PROTECTED]
wrote:
A visual interface is so slow sometimes when you
have to resize a button
group of 120 buttons, reorder the tab sequence, use
new fonts, redefine
standard margins, etc. This is too much technical.
Those caracteristics
should have their
--- Brock Peabody [EMAIL PROTECTED]
wrote:
cycle or two of our recursive (I thought they called
it iterative?)
They do call it iterative. However in the C++ world
iteration is like enumeration while recursion is a
process where typically the input for the next call is
derived from the result
--- Bohdan [EMAIL PROTECTED] wrote:
Now i see. I suppose 'link' question is closed ...
?
Yes, boost developers are working on how to solve it.
It won't be easy within the current design.
Additionaly it would be nice to add some guidelines
on
how to do port (patching files and build
--- E. Gladyshev [EMAIL PROTECTED] wrote:
--- Brock Peabody
[EMAIL PROTECTED]
We can get a simple sub-language running on top of
those few controls
quickly enough.
I agree. I was thinking about setting up a
sourcesafe
project.
Sorry, I meant sourceforge. Too much MS at work
--- Bohdan [EMAIL PROTECTED] wrote:
If you mean your threads snipped: Yes i've seen it.
IMO it is more complicated and YES it has compile
time problems, unless you put traits implementation
in cpp files and move #include OS headers to
cpp files, but in this case you have
Yes, it was my
--- Philippe A. Bouchard [EMAIL PROTECTED]
wrote:
Could you prepare a little schedule, I would like to
know more about the
timelines given to hypothesises abstractions,
Hello worlds
multi-platform issues. We are talking about hard
labours here time
management is a big issue. I am
--- Pietrobon Marcello [EMAIL PROTECTED] wrote:
I signalled this boost thread to the leader of the
VCF library.
He's available for giving you more informations if
you desire.
His contact informations are:
Jim Crafton [EMAIL PROTECTED]
or, in the evenings:
IRC server: irc.freenode.net
--- Pietrobon Marcello [EMAIL PROTECTED] wrote:
Also, IMHO, I would keep in mind that programmers
successfully use the templates
only after some experience with a more common
programming.
I wouldn't start to set up a standard keeping an eye
only to 'real' programmers
and scare all the
--- Thomas Witt [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Maddock wrote:
|
| One final point - there was a reason that I moved
regex to use automatic
| library selection and ABI fixing - without it I
was getting a tonne of
| support requests along the
--- Bohdan [EMAIL PROTECTED] wrote:
Under 'non-template' I mean that it is not
header-only
library. Generaly term 'template library' is used
for
Pure template-inline library which contains only
headers,
but not cpp.
Ex: spirit is template library, but boost::regex is
not.
Not exactly,
What is the boost policy (if any) on using STL in
boost classes in regards to the allocator template
parameter in STL?
For example if we'd like to use std::list in a boost
class A, do we expose the allocator parameter:
template typename T, typename A = std::allocatorT
class A
{
std::vectorT
--- Brock Peabody [EMAIL PROTECTED]
wrote:
1. The layer 1 must appear as one threaded API
that
has a message queue (ala win32). In other words
all
calls from layer 1 to a library object has to be
done
in the context of the thread that created the
object
(ala win32).
2. The layer
--- Brock Peabody [EMAIL PROTECTED]
It stands for 'standard'. Maybe that's a little
pretentious for us at
this early stage :)
I think they called it STL before it became a
standard.
gtl would probably be better.
I thought about this name, but I think it is already
taken, GTL (Graph
--- Joel de Guzman [EMAIL PROTECTED] wrote:
E. Gladyshev [EMAIL PROTECTED] wrote:
Since GTL is already taken, how about GTF (GUI
Template Framework)?
Can't we be more imaginative than that? Aren't we
all
already saturated with acronyms and acronyms and yet
more
acronyms
--- Bohdan [EMAIL PROTECTED] wrote:
E. Gladyshev [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Yes it is, but AFAIK it doesn't have cpp files.
std::streams really have cpp files and are part of
standart,
but if i don't mind they are not part of STL. Am i
wrong ?
Maybe, I am
--- Bohdan [EMAIL PROTECTED] wrote:
E. Gladyshev [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Well, how can I use boost::threads with my toy
operating system?
If you are writing application for your toy OS, you
should :
1. Edit boost::thread implementation
--- Brock Peabody [EMAIL PROTECTED]
wrote:
Oh, and I really want the ability to select layers
1 and 2 at runtime,
in
a
single place in my code, on a per top-level window
basis.
Let's just try to get it working first. I don't
doubt that we could do
this but is it worth the cost
--- Edward Diener [EMAIL PROTECTED] wrote:
Exporting/importing C++ classes is completely
implementation dependent, due
mainly to name mangling, and requires a DLL for a
particular
platform/compiler/release to be built.
There are several issues with DLL and C++, to name
few:
1. Name
--- Brock Peabody [EMAIL PROTECTED]
wrote:
That might be a better way to go. I just don't know
enough about GUI
systems other than MFC to be able to envision what a
scheme like that
would look like or if it would succeed. You might
save a lot of work
coming up with a single low-level
--- Andrei Alexandrescu [EMAIL PROTECTED]
wrote:
This approach is definitely sound, except that you
need to write quite some
scaffolding (ctors etc. etc.) for each handle
wrapped. With a policy you can
put the scaffolding in one place and then write only
the stuff that varies.
In the
--- Bohdan [EMAIL PROTECTED] wrote:
2. Finally your lib may become non-template ( i mean
cpp files) ...
If it becomes not-template, I'll stop working on it
:). cpp files are allowed for the layer 1 code and
compilation-time optimization wrappers only, that's
it! Both has little to do with the
--- Gregory Colvin [EMAIL PROTECTED] wrote:
Perhaps Perseus, who slew the Medusa, the
snake-haired monster of
so frightful an aspect that no living thing could
behold her without
being turned into stone.
Perseus avoid being turned to stone by clever use of
indirection --
he avoided
--- Brock Peabody [EMAIL PROTECTED]
wrote:
What about simple boost::gui ?
I would like to have an unique name without the
boost
prefix.
I think the boost namespace is a requirement for any
boost library.
Sorry, I didn't mean to put the library out of the
boost namespace. The
--- Drazen DOTLIC [EMAIL PROTECTED] wrote:
Now that the interest for this kind of library has
been shown (or not,
whatever) could the interested parties please
coordinate their efforts
using other means than boost mailing list? IIUC this
list is for issues
with existing code (problems,
--- Brock Peabody [EMAIL PROTECTED]
We can get a simple sub-language running on top of
those few controls
quickly enough.
I agree. I was thinking about setting up a sourcesafe
project. What do you think about the name, boost::SGTL
(Standrad GUI Template Library)?
Eugene
--- Brock Peabody [EMAIL PROTECTED]
wrote:
That sounds good. What if we called the lower layer
boost::gui and the
upper layer boost::sgtl?
Agreed.
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
--- Brock Peabody [EMAIL PROTECTED]
wrote:
I wonder how much we will have to redo when we add
in support for say
Mac Os X or another *nix API. Is it going to be too
complex to develop
a single underlying code base that works on all of
them? Would we be
better off developing separate
--- Bohdan [EMAIL PROTECTED] wrote:
Because :
1. traits causes more complicated and more
error prone interface. In this case
errors can
be caused by two incompatible thread
mechanicms used in one application.
BTW, have you any idea how
--- Russell Hind [EMAIL PROTECTED] wrote:
E. Gladyshev wrote:
You have
objects created inside the signals lib
(non-multi-threaded) so it
doesn't create/initialise the lock member variables.
There is then
header code which is compiled directly in your
application
Thanks for taking
--- Brock Peabody [EMAIL PROTECTED]
wrote:
http://groups.yahoo.com/group/boost/files/
The name is boost_gui.zip. There is a ton of code,
but the interface
I think, your library has a lot of good stuff. However
it does need a major redesign to cleanly remove all
direct references to the
--- Russell Hind [EMAIL PROTECTED] wrote:
E. Gladyshev wrote:
It can cause problems but if you are aware of it,
then you can work
around it quite easily.
IMO, I should be able to just use the library w/o this
kind of workarounds. It is hard to debug these .lib/.h
conflict issues.
IMHO
I was wondering, has the boost comunitiy had a
discussion about exporting/importing C++ classes from
a DLL?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
--- Brock Peabody [EMAIL PROTECTED]
wrote:
If we can keep our interface simple
it might be easiest
to just make the library an interface specification
which is implemented
totally independently for each target platform. Does
that seem
reasonable?
I agree.
I think we can have 2 layers.
--- Brock Peabody [EMAIL PROTECTED]
wrote:
This saves us from having to find a representational
scheme that will
fit on top of an unknown number of platforms which
might not have
anything in common.
I think this is where we disagree. I prefer to find a
single low-level represntation
--- David Abrahams [EMAIL PROTECTED] wrote:
E. Gladyshev [EMAIL PROTECTED] writes:
Is MPL a modern TEMPLATE library, in your opinion?
I ask because compilation time is a very serious
issue in the design
of MPL.
In my opinion MPL is a great example of a tool for
creating modern C
--- Bohdan [EMAIL PROTECTED] wrote:
E. Gladyshev [EMAIL PROTECTED] wrote in message
I think that any industry standard TEMPLATE
library
should be designed in terms of modern C++. The
compilation time should NOT be considred as an
issue.
Compilers are getting better, computers faster
--- Bohdan [EMAIL PROTECTED] wrote:
E. Gladyshev [EMAIL PROTECTED] wrote in message
but which approach is better for GUI lib.
I believe that I've made a strong case for ImplTraits
for GUI library. In the win32 case, the compilation
time penalties would be of the same order as including
--- Rainer Deyke [EMAIL PROTECTED] wrote:
For a GUI library to be useful to me, it would need
to support custom
physical GUI layers. I would then write my own
[...]
full-screen multimedia. I
realize that my needs are unusual, and boost::gui
may be unable to
accomodate them.
It seems
--- Edward Diener [EMAIL PROTECTED] wrote:
As you have pointed out in the rest of your post, it
may prove more
worthwhile to work with the developers which already
exist for a free
cross-platform framework like wxWindows, in order to
encourage them to use
more modern C++ idioms
I agree
Have you built the signals library multi-threaded or
single threaded and
Whatever the default build is.
are you building an application of the same sort?
The application is set to use multi-thread run-time
libraries and MFC.DLL.
Not seen this specific one, the most common problem
I
1) It buys us very little: generally template
parameters are useful when
more than one instantiation will be used within any
particular program. It
is highly unlikely that a program will support two
physical GUI layers
simultaneously,
I think that it is very likely. For examle you
--- Douglas Gregor [EMAIL PROTECTED] wrote:
template typename IT, typename PhysicalGuiLayer
class ListControl
I came with a name for this idiom, ImplTraits idiom.
template ... typename ImplTraits
class someclass
It is like the name of the pImpl idiom.
Eugene
Even if the implementation is parameterized by a
traits or other class,
we could still use a non template class in the
implementation to reduce
compile times, which is what I though the original
poster was trying to
say.
template ... typename ImplTraits class
some_edit_class :
Pimpl definitely has its place.
I agree, but boost::threads and boost::gui would be
much better of with ImplTraits, in my opinion.
If you buy Doug G.'s argument that no application
will use two
GUIs at once
No I don't buy Doug's argument at all.
Here is an example.
//customize the edit
Are you aware that the pImpl idiom is used for many
different things
It defenitly has its place but not in modern C++.
or have
you just decided its not modern C++ at all because
you don't use it for the
things you want to do ?
In my opinion modern C++ is more oriented toward
program
Here is a very simplified version of how this can
happen.
template typename Traits struct edit_imp {...};
struct edit {
template typename Traits edit_impTraits
make_gui() {...}
};
template typename Traits struct
gui_wrapper_base {
//some pure virtual
--- Rene Rivera [EMAIL PROTECTED]
wrote:
[2003-08-01] E. Gladyshev wrote:
Are you aware that the pImpl idiom is used for
many
different things
It defenitly has its place but not in modern C++.
Could you do us the courtesy of indicating who you
are quoting when you post
--- Douglas Paul Gregor [EMAIL PROTECTED] wrote:
On Fri, 1 Aug 2003, E. Gladyshev wrote:
Because one might use multiple threading models in a
single program? Since
we already have a boost::threads design to compare
against, could you
explain how the ImplTraits idiom would improve
--- Brock Peabody [EMAIL PROTECTED]
wrote:
Anyway I think I got the basic idea. The idea is
that
the GUI elements are classes defined on top of a
pImpl. Someone else creates the pImpl object and
passes it to the GUI elements classes. The GUI
elements then call pImpl methods do the
Anybody had problems with boost::signal? The following
sample code crashes on my Win2k/VC++6 system.
struct HelloWorld
{
void operator()() const
{
}
};
// Signal with no arguments and a void return value
boost::signal0void sig;
// Connect a HelloWorld slot
HelloWorld hello;
But localisation should be orthogonal to the GUI
library. By all means
let's have (eventually) a resource loading library
that understands
native resource files, but there's no reason for
that library to be on
intimate terms with the GUI library
Localization is not just changing a set
...[compile-time or run-time?] I don't know what
is the best way to go.
It is always hard to know the best way to go if you
don't know where you
are going.
A GUI/GDI library might fill one or more needs:
...
[Controlling the look-and-feel]
Setting aside the poster's philosophical
Every design will have both run-time and
compile-time aspects.
I agree. Where do you draw the boundary? What is the
correct mix of these two aspects? That's the tradeoff
I was talking about.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web
If a decision is based on information that cannot be
known at
compile-time then you must make that decision at
run-time.
How do you decide what information can and what cannot
be know at compile-time. For instance if you want to
use an external fullblown scripting definition of the
GUI
I believe that MS has. They have CDHtmlDialog in MFC.
You can script dialog layouts just like web pages.
Eugene
--- David Abrahams [EMAIL PROTECTED] wrote:
Has anyone given thought to the design of a
domain-specific
sublanguage for dialog layout specification?
--
Dave Abrahams
I really enjoyed discussing the library with you guys.
I think I am getting a bit close to what the library
should look like from my personal standpoint.
The main ideas come from the MFC's document/view
architecture, STL and present discussion.
The main building blocks of the libarary will be
Uh. I would not recommend inheriting from STL. I
think that template
policies would be rather more appropriate solution:
I agree with that.
myWindow.create_widgetmylistbox
(myapp::ENUM_ID_LIST_OF_ITEMS,
Just a note.
Ideally, the library won't have to deal with the
numeric control ID's.
I personnally prefer seeing something similar to:
typedef std::list boost::entrylineEdit,
std::string listbox;
I think the basic issue here is this.
Should we expose the gui structure as a set of direct
STL data types or should we define separate GUI data
types that will behave like the
typedef std::list boost::containerlistbox,
boost::gui::fast_signals
mylistbox;
As for the signals.
GUI objects generate events. What is the best design
for it? Should the events handlers be executed
asynchronously in the context of some internal thread
or should they be something like a
Sometimes you want your events to be called
instantaneously (clear
paintdevice before drawing on it) and sometimes you
will want to catch and
forward them elsewhere (i.e. keystrokes). You need
both.
I guess what I am trying to say is that I'd prefer a
single underlying event
1 - 100 of 110 matches
Mail list logo
