--- 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!?
Ya
--- 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 UserAll
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
> Yep. I still think UserAllocator is a good default, and that where it
> doesn't suffice there is some value to playing nicely with STL.
>
> So even when we come up with some beautiful new thing to do the
> allocation job better, we will still need
--- 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
--- David Abrahams <[EMAIL PROTECTED]> wrote:
[...]
> Something like:
>
> some_allocator<_1>
>
> or
>
> struct select_allocator
> {
> template
> struct apply
> {
> typedef some_allocator type;
> };
> };
>
> with some_allocator's interface being like
--- 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 i
--- 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? Allocator
--- 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 the
--- "E. Gladyshev" <[EMAIL PROTECTED]> wrote:
>
> --- David Abrahams <[EMAIL PROTECTED]> wrote:
> > >>> But indeed allocate/construct/deallocate/destroy is more work than
> > >> ^^^^
> &
--- Aleksey Gurtovoy <[EMAIL PROTECTED]> wrote:
> E. Gladyshev wrote:
> > > * Consider parametrization, especialy if your library is to be available
> > > for embedded or non-traditional (like DSP, etc.) platfroms.
> >
> > I think this item will make
--- 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 t
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
--- 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, a
--- 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'
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
> Bullshit:
>
>template 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, must
>
--- 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_pt
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
[...]
> It's still not obvious to me. But I suspect I have yet to understand
> your example.
Perhaps Peter can help me here. In his sample solution before, in this thread,
he addresses this problem nicely by using static functions
that take reference
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
[...]
> > Does it make sense?
>
> Not to me. Sounds like a very broken allocator design.
>
If I assume that I going to have a full control over my allocator
instances (not a very unusual assumption), there is nothing
broken here. Whether it is bro
--- 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;
> >
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
[...]
> > In this solution, there are some issues with who
> > controls the instances of the allocator that allocates
> > Data and instances that delete the Data.
>
> Which issues concern you?
The potential problem is this. Let's assume that
I forgo
--- 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
> te
--- 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
--- 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 wonder
--- 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 th
--- 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 t
--- 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 conside
--- 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
--- 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. T
--- 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
> > cust
--- "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 a
--- "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 a
--- 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
--- 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
--- Peter Dimov <[EMAIL PROTECTED]> wrote:
[...]
> template struct X
> {
> typedef typename A::value_type T;
>
> static T * create(A & a)
> {
> T * p = a.allocate(1);
>
> try
> {
> new(p) T;
> }
> catch(...)
> {
>
--- 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_impl(p, d);
>
> So it might be possible to make the allocation customizable by
> specializing
> sp_counted_base_impl.
I t
--- 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-cont
--- 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
--- 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,
> > --- 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 serv
--- 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 requirement
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, tho
--- 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 (Gr
--- Bohdan <[EMAIL PROTECTED]> wrote:
> Not really. Example:
> Link to static or dynamic (i mean import lib)
> thread library problem. This decision can be made
> only by linker option or by #pragma comment.
> IMHO, traits can't help here.
Traits have nothing to do with the lib-link problem it
in
--- 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).
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::allocator >
class A
{
std::vector m_da
--- 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.
N
--- Joel de Guzman <[EMAIL PROTECTED]> wrote:
> No mailing list? IMO, I would highly suggest a
> mailing
> list instead of a web based forum. Easier to
> post-to,
> maintain, archive, etc.
Good point! The Design mailing list has been setup.
It'll take up to 24 hours to be activated.
Eugene
___
--- 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.fre
--- 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
--- 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 a
--- 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 resu
--- "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 hav
--- 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
--- "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 sett
--- 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 to
> cpp files, but in this case you have
Yes, it was my sugges
--- 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 thread
--- 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
> > pa
--- 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 whi
--- 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 a
--- "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 world"s &
> multi-platform issues. We are talking about hard
> labours here & time
> management is a big i
--- "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 tom
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 t
--- 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 sa
--- 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 m
--- 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
--- 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 O
--- 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&
--- John Torjo <[EMAIL PROTECTED]> wrote:
> Basically, I don't think you should be concerned
> about data at such a low
> level.
>
> I think there should be a layer that represents gui
> objects (windows, views,
> controls, dcs, etc.), and ON TOP OF THIS, have
> representations of data,
> based
The notus project has been setup on sf.
http://sourceforge.net/projects/notus
It has several public forums including the Design
forum.
Please feel free to move this discussion there.
I'll be posting a detailed proposal of basic design
ideas soon which we can hopefully use as a starting
point for d
--- 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-
--- 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
I'll be working on setting up the Notus (code name)
project on sf tomorrow. I think that I've got some
solid ideas on the basic design (I have been thinking
on the design for a while before I posted the idea to
the boost list and this discussion helped me
immensely). I'll present it on the project'
--- Douglas Gregor <[EMAIL PROTECTED]> wrote:
> The allocator design focused on the benefits one
> could get from specialized
> allocators for containers, e.g., data structures
> that may allocate large
> chunks of memory that are expected to be used
> together. They don't really
> give us much f
--- 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 (probl
--- 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 n
--- 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
--- 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
--- Brock Peabody <[EMAIL PROTECTED]>
wrote:
> It stands for 'standard'. Maybe that's a little
> pretentious for us at
> this early stage :) gtl would probably be better.
> I suspect that if we
> get to a review some people may request something
> more verbose.
>
Since GTL is already taken,
--- 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 separ
--- 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
http://sitebuilder.yah
--- 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
--- 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 i
--- 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 represnt
--- 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 la
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
_
--- 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/
--- 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
--- 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
--- 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
--- 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 s
--- 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
--- 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 considre
--- 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 gre
--- Edward Diener <[EMAIL PROTECTED]> wrote:
> E. Gladyshev wrote:
> The pImpl technique is an idiom for hiding the
> private methods and data
> members of a class from the view of the user of that
> class.
By using a predefined ImplTraits you are actually
achiving the sam
--- 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 meth
--- 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 ImplTrait
--- 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 th
> Here is a very simplified version of how this can
> happen.
>
> template struct edit_imp {...};
>
>struct edit {
>
> template edit_imp
> make_gui() {...}
>};
>
>template struct
> gui_wrapper_base {
>
> //some pure virtual functions
>};
>
>template
> str
> 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
> 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
1 - 100 of 127 matches
Mail list logo
