Re: [boost] Re: Boost memory management guidelines
--- 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! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- 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 parameter, you customized
how STL allocate their memory as well.
>
> > 4. To construct/destroy objects, use boost::memory::construct/destroy.
>
> See below.
>
> > 5. Avoid using explicit references to allocators.
> >
> > ... Usage example:
> > ==
> > template< typename T, typename UserAllocator =
> > boost::default_user_allocator_new_delete >
> > class X
> > {
>
> What if you want X to use the same allocator as some other STL container
> constructed with a non-Boost allocator? That would be difficult unless
> you have [...]
Yes.
> > T* _p;
>
> How to pass arguments to T's constructor? Better just
>
>p = new(UserAllocator::malloc(sizeof T)) T(...)
>
> > }
> > ~X()
> > {
> > if( _p )
> > boost::memory::destroy( _p, 1 );
>
> In which case, why not just
>
>p->~T(), UserAllocator::free(p);
>
> ?
The boost::memory::construct/destroy are just convinience wrappers
that will do like just that.
They can also handle exceptions properly.
struct memory
{
template< typename T, typename A >
static void destroy( T* p )
{
try
{
p->~T();
A::free(p);
}
catch( ... )
{
A::free(p); //free memory even if the destructor crashes.
throw;
}
}
};
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- 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 adaptors both ways, so that
> one can get an allocator from an STL container and turn it in to one
> of our new things, or take one of our new things and turn it into an
> allocator to use in an STL container.
Am I right in trying to summarize your suggestion about UserAllocator?
If you want to parametrize how a boost class manages memory,
use UserAllocator parameter.
1. The allocator parameter should implement the UserAllocator interface.
2. All instances of UserAllocator must be equal and stateless.
3. If your class is using STL containers, use boost::memory::allocator
adapter (see bellow).
4. To construct/destroy objects, use boost::memory::construct/destroy.
5. Avoid using explicit references to allocators.
// boost standard implementation
namespace boost
{
struct memory
{
//UserAllocator to Standard Allocator adapter
temlate
struct allocator
{
... *** implement std::allocator interface using UserAllocator
};
//construct n objects of type T using UserAllocator
template
static T* construct( size_t n ) {...}
//destroy n objects of type T using UserAllocator
template
static void destroy( T* p, size_t n );
};
};
Usage example:
==
template< typename T, typename UserAllocator =
boost::default_user_allocator_new_delete >
class X
{
T* _p;
std::vector > _v;
X()
{
_p = boost::memory::construct( 1 )
}
~X()
{
if( _p )
boost::memory::destroy( _p, 1 );
}
};
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- 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 I assumed that construct/destroy
functions would be implemented in some 'memory' data type
(just to qualify it).
struct memory
{
static template< typename A >
typename A::pointer construct( A& a, size_t n ) {...}
static template< typename A >
void destroy( typename A::pointer ) {...}
};
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- 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 what's required for
> std::allocator but not including misplaced interface bits such as
> address/construct/destroy, and possibly max_size -- these can be added
> by a std::allocator facade wrapper if neccessary.
>
> I'm not sure we need a simple version and a complicated version.
>
I suggested something similar in one of my prev. posts here.
template< typename T >
struct generate_allocator
{
typedef some_allocator type;
};
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- 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 boost allocators won't include constuct/destroy, all boost developers will probably implement their own construct/destroy helper functions (outside allocators) to construct/destroy object using allocators. In such case, I suggested to include standard construct/destroy functions in boost (not in allocators). Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- 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 provide a
> >> point of customization for users, but you cannot/should not customize
> >> these.
[...]
> The class getting constructed/destroyed has full control over that or
> the language is utterly bustificated.
I think construct/destroy can be implemented as non-customizable
static functions in boost just for convinence.
static template< typename A >
typename A::pointer construct( A& a, size_t n )
{
typename A::pointer p = a.allocate(n)
try
{
p = new(p) A::value_type[n];
}
catch(...)
{
a.deallocate( p, n );
}
return p;
}
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- 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 offer: a potentially very efficient way > to allocate large numbers of small objects of known type, and/or a > way to access storage via proxied pointers. Perhaps the boost allocator requirements should just combine both, the UserAllocator and StandardAllocator requirements. In a way, StandardAllocators can be considered as an extension of UserAllocators. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost memory management guidelines
--- "E. Gladyshev" <[EMAIL PROTECTED]> wrote:
>
> --- 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 provide a
> > >> point of customization for users, but you cannot/should not customize
> > >> these.
> [...]
> > The class getting constructed/destroyed has full control over that or
> > the language is utterly bustificated.
>
> I think construct/destroy can be implemented as non-customizable
> static functions in boost just for convinence.
>
> static template< typename A >
> typename A::pointer construct( A& a, size_t n )
> {
>typename A::pointer p = a.allocate(n)
>try
>{
> p = new(p) A::value_type[n];
>}
>catch(...)
>{
> a.deallocate( p, n );
>}
>return p;
> }
>
> Eugene
Oops,
static template< typename A >
typename A::pointer construct( A& a, size_t n )
{
[...]
catch(...)
{
a.deallocate( p, n );
throw;
}
return p;
}
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost memory management guidelines
--- 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 you think twice before hiding > > boost::signal's allocator. > > An allocator parameter is not the only way to parameterize, here, nor it is > necessarily the most appropriate one. If I wanted to manage how > function/signals allocate their memory, I wouldn't want to do it on a > per-object basis - which, without the typedef templates, is pretty much the > only level the allocator template parameter would allow me to manage it on. > At least for these two libraries, a per-project parameterization seems more > appropriate to the real needs, and something as simple as a trait class > could provide the means. Right. When we say "consider parametrization", it doesn't necessarily mean a template parameter. Perhaps we should be more specific about it. I agree about trait/policy classes. Just for a note different trait classes could be used in one project I think that it is not really a per-project parameterization (if you need a per-project parameterization, you could as well overload global new/delete). In many cases, you do want to have different memory management strategies in one project depending on the execution context and/or data type. Trait classes don't always prevent it. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost memory management guidelines
--- 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 tradeoffs and make decisions. > > > ... > >> * parameterize only when there is a clear advantage to doing so > > > > I'd modify it to > > > > * Consider parametrization if your library is to be available > > for embedded or non-traditional platfroms. > > Even on "traditional" platforms there may reason to parameterize, and > there may be alternatives to parameterization even on embedded plaforms. OK, * 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 you think twice before hiding boost::signal's allocator. > > >> * use the standard parameterization mechanisms (Allocator) when > >>choosing to parameterize > > > > I'd add to it > > * Follow boost::allocator specification for allocator parameters > > Which specification is that? There are several here: > http://boost.org/libs/pool/doc/interfaces.html I'd vote for something compatible with STL allocators. So that they can be used with containers directly. Perhaps boost::allocator can extend it a bit wih additional realloc() method. IMO, it is another discussion. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost memory management guidelines
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 at this point, as my opinions > may not be suited to the needs of the many different libraries in > Boost. But I think it's generally reasonable to: > * not allocate memory unless it's really necessary $0.02 > * use the standard mechanisms (::operator new or std::allocator) >when it is necessary Boost already has boost::allocator. IMO other boost libaries should consider using boost::allocator instead of ::new and std::allocator. > * use custom allocation mechanisms only when there is a clear >advantage to doing so $.02 > * parameterize only when there is a clear advantage to doing so I'd modify it to * Consider parametrization if your library is to be available for embedded or non-traditional platfroms. > * use the standard parameterization mechanisms (Allocator) when >choosing to parameterize I'd add to it * Follow boost::allocator specification for allocator parameters > * use custom parameterization mechanisms only when there is a >clear advantage to doing so $.02 > * document whether and how a library allocates memory $.02 Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 opinions > may not be suited to the needs of the many different libraries in > Boost. But I think it's generally reasonable to: > * not allocate memory unless it's really necessary $0.02 > * use the standard mechanisms (::operator new or std::allocator) >when it is necessary Boost already has boost::allocator. IMO other boost libaries should consider using boost::allocator instead of ::new and std::allocator. > * use custom allocation mechanisms only when there is a clear >advantage to doing so $.02 > * parameterize only when there is a clear advantage to doing so I'd modify it to * Consider parametrization if your library is to be available for embedded or non-traditional platfroms. > * use the standard parameterization mechanisms (Allocator) when >choosing to parameterize I'd add to it * Follow boost::allocator specification for allocator parameters > * use custom parameterization mechanisms only when there is a >clear advantage to doing so $.02 > * document whether and how a library allocates memory $.02 Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 parameter. > > > > Bullshit: > > Please excuse my rude language. Don't worry about that. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 >not invoke undefined behavior, and must not throw exceptions. > >Effects: Constructs a shared_ptr that owns the pointer p and >the deleter d. > >Postconditions: use_count() == 1 && get() == p . > >Throws: std::bad_alloc or an implementation-defined exception >when a resource other than memory could not be obtained. > >Exception safety: If an exception is thrown, d(p) is called. > >Notes: When the time comes to delete the object pointed to by p, >the stored copy of d is invoked with the stored copy of p as an >argument. > > http://www.boost.org/libs/smart_ptr/shared_ptr.htm#constructors Well said. :) Sorry about that. I looked at the "Common Requirements" section and description of shared_ptr::reset(); - template void reset(Y * p, D d); Effects: Equivalent to shared_ptr(p, d).swap(*this). - Somehow I missed the constructor docs. Sorry again. Anyway like I said before several times it is not a big deal in my opinion. People are adopted to follow similar requirements for STL allocators anyway. I guess they can be recommended to all boost authors who wants to make memory management data types. Perhaps they can be added to the "Guidlines" section http://www.boost.org/more/lib_guide.htm#Guidelines Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 a problem. All I am trying to say is that shared_ptr doesn't specify any requirements on its Deleter parameter. shared_ptr's Deleter is not a C++ standard's allocator. shared_ptr *does* have a problem because it doesn't set any standards for the Deleter type like C++ does for Allocator. It is just one example of the inconsistent memory management concept in boost that should be sorted out eventually. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 references to allocator instances. In his solution, shared_ptr doesn't create an internal Allocator copy. Instead he binds a static function pointer to an Allocator instance and uses the pointer as Deleter. My sample stateful allocator will work just fine in Peter's code. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 broken or not should be discussed in a specific context. Anyway, my point was that the shared_ptr( Data* p, Deleter ) has a *potential* problem that was not obvious even to to some people here. (it may not be obivous to other developers). Like I said, I don't think that it is a big deal as soon as we state a set of requirements for boost "deleters"/allocators. (STL standard has). The "Common Requirements" section in the shared_ptr description doesn't seem to have them. Perhaps the established requirements will be used by other libraries as well. BTW. I am also concerned about the boost::signals library. It seems like this library could be very usefull for embedded (real-time?) development but it hides std::allocator. If we cannot come up with memory management policies for boost, perhaps we can define a set of no-so-strict guidlines for boost developers. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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()( T* d )
> >{
> > _heap.destroy(d);
> >}
> > };
> >
> > Now if I do something like the following code (that looks perfecly
> > fine).
> >
> > f()
> > {
> > my_allocator a;
> >
> > {
> > shared_ptr s( a.create(), a );
> > ...
> > int* n = a.create();
> > a(n);
> > }
> > }
> >
> > I got a problem, because by the time when 's' deletes my data
> > the heap state is changed while 's' still has an old copy
> > of the heap state.
> >
> > * If we state that boost allocators must be implemented
> > like statless policies not like real data types,
> > this problem is not a big deal.
>
> I am not understanding the above at all, maybe because I don't
> know what you mean by "heap control block" or "stateless policies"
> or "real data types".
I called "stateless policies" data types that define some actions
(policies) that never change the state of any of this data
type instances.
The "heap control block" is a data type that manages
the state of a memory heap. For instance it can keep
a list/directory of pointers to free block in the heap.
No imagine the the my_allocator has a list of pointers
to free memory blocks in some memory heap.
template< typename T >
sturct my_allocator
{
char** _freeblocks[100];
};
When you write
shared_ptr s( a.create(), a );
's' will create an internal copy of 'a'.
The internal copy will have a copy of _freeblocks[100];
Now we create a new object, that changes the state of _freeblocks[100]
int* n = a.create();
Next, 's' goes out scope and deallocates its object using
its own copy of _freeblocks[100] but this copy is already bad.
It doesn't represent the current configuration of free blocks
in the heap.
Does it make sense?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 forgot (or didn't know) that shared_ptr creates
a copy of Deleter.
I can technically create a local allocator class
that will keep the heap control block
as a data memeber.
*pseudo-code*
template< typename T >
sturct my_allocator
{
my_heap_control _heap;
T* create()
{
return _heap.create();
}
void operator()( T* d )
{
_heap.destroy(d);
}
};
Now if I do something like the following code (that looks perfecly fine).
f()
{
my_allocator a;
{
shared_ptr s( a.create(), a );
...
int* n = a.create();
a(n);
}
}
I got a problem, because by the time when 's' deletes my data
the heap state is changed while 's' still has an old copy
of the heap state.
* If we state that boost allocators must be implemented
like statless policies not like real data types,
this problem is not a big deal.
>
> > But I guess it is not big deal as soon as people understand it.
> > If are to use template template parameters,
>
> Yes, the template template parameter is a pain. Probably better to
> take an arbitrary allocator object and rebind it:
>
> template
> shared_ptr(T* p, D d, const A& a)
> : px(p), pn(p, d, A::rebind<
> >(a))
> {
> detail::sp_enable_shared_from_this(p, p, pn);
> }
>
> > it would be nice to be able to define one allocator
> > type for both counter and data.
> >
> > template
> > class Allocator>
> > shared_ptr(
> >Data*,
> >Allocator,
> >const Allocator > Deleter> >& );
>
> This constructor would conflict with the constructors that take a
> deleter, which must be a function pointer or function object, and
> which might not use an allocator.
Right, a new constructor is not needed.
> But for the purpose of creating shared objects using an allocator
> you could instead use a factory function something like:
>
> template
> shared_ptr
> allocate_shared_data(const Data& data, Allocator allocator)
> {
>struct deleter {
> Allocator a;
> deleter(const Allocator& a) : a(a) {}
> void operator()(Data* p) {
> a.deallocate(p,1);
> a.destroy(p);
> }
>};
>Data* p = allocator.allocate(1);
>allocator.construct(p,data);
>return shared_ptr(p,deleter(allocator),allocator);
> }
I like it.
Or you can add operator()(Data*) to your allocator
and use it directly in shared_ptr and STL.
template< typename T >
struct my_allocator : std::alocator
{
void operator()(T* d)
{
try
{
d->~T();
}
catch(...)
{
deallocate(d, 1);
throw std::runtime_error("");
}
deallocate(d, 1);
return;
}
};
shared_ptr s( p, my_allocator(), my_allocator() );
I am not sure how to specify the counter allocator in this case
What is legal syntax for template template parameters in functions?
Do you have to put the whole thing in.
shared_ptr s( p, my_allocator(), my_allocator >() );
or there is another way?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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. > See: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/boost/ > shared_ptr.hpp > > So you what you might want is to add something more like this to > shared_ptr: > > template > class Allocator> > shared_ptr( >Data*, >Deleter, >const Allocator Deleter> >& ); > > The idea being that you can use this constructor to get complete > control over how > a particular shared_ptr manages memory. In this solution, there are some issues with who controls the instances of the allocator that allocates Data and instances that delete the Data. But I guess it is not big deal as soon as people understand it. If are to use template template parameters, it would be nice to be able to define one allocator type for both counter and data. template class Allocator> shared_ptr( Data*, Allocator, const Allocator >& ); Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 with the authors of the documentation to
> >> make it sure it says what needs saying?
> >
> > Are the documentation authors monitoring this mailing list?
> >
> >> 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?
> >
> > How about
> >
> > template< typename T, typename Counter = int >
> > shared_ptr
> > {
> >typedef Counter counter; //counter type should be public
> >
> >template , typename
> > CounterAlloc=std::allocator
> >>
> >shared_ptr( const DataAlloc& da = DataAlloc(), const IntAlloc ia& =
> > CountAlloc() );
> > };
>
> 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.
> See:
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/boost/
> shared_ptr.hpp
>
> So you what you might want is to add something more like this to
> shared_ptr:
>
> template
> class Allocator>
> shared_ptr(
>Data*,
>Deleter,
>const Allocator Deleter> >& );
>
> The idea being that you can use this constructor to get complete
> control over how
> a particular shared_ptr manages memory.
There are some issues with ho
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 what is the submission procedure exactly? For example I believe that shared_ptr must absolutely have the counter type as a template parameter. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 doing the > > necessary work, just like everything else here at Boost. > > Moreover, it's not a matter of convincing certain people that a clear memory > management policy should be adopted by Boost and handed down for developers > to do the work. Boost doesn't work that way. Policies always come from the > bottom up: someone has a problem, so they fix it in the libraries that matter > most to them. With that knowledge of _how_ to fix the problem correctly, they > can approach other developers and say "hey, I think we should fix this > problem in library X; here's how we did it in library Y". Eventually, most of > the libraries will support it, and _then_ we can approve it as a Boost > "policy" so that future libraries will follow it. > > The most productive thing we could do right now would be to end this policy > discussion. Start with smart_ptr and address *specific* documentation and > *specific* implementation problems in this library, with resolutions specific > to that library. Is there a library that does it well? Reference that library > and state why it does it well, so that others may follow. I agree but there is a problem. It is very easy to put an STL allocator in the shared_ptr constructor. However I don't think that you'll be able to say "hey, I think we should fix this problem in library X; here's how we did it in library Y" The question is should we try to find a solution that can work for other libraries so that we could say "hey,..."? Do the library authors have some ideas? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 mailing list?
> 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?
How about
template< typename T, typename Counter = int >
shared_ptr
{
typedef Counter counter; //counter type should be public
template , typename
CounterAlloc=std::allocator
>
shared_ptr( const DataAlloc& da = DataAlloc(), const IntAlloc ia& = CountAlloc() );
};
>
> 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 doing the
> necessary work, just like everything else here at Boost.
I believe that the library authors should care about
memory management most.
If they don't understand something, they should ask people around,
but I am convinced that the boost authors are the best (honest).
I am sure that they can find a practical solution if they
only wanted to.
Actually this is probably what the whole thread is about
to get people to try to find the best practicle solution
for memory management in the modern C++ age.
I am not sure that STL style allocators is the best
possible solution.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 next time. However if Boost doesn't have a clear memory management concept, how can I guarantee that the next time around, intrusive_ptr or something else in boost won't start allocating memory under the covers. It is perfectly legal in Boost. How will I even know it, the documentation is completely ignorant on the memory issues. > You can also use Boost.Regex, it is completely allocator-enabled. ;-) I never said that I am a huge allocators fan but at least it seems that regex has one of the most consistent memory management concepts in the library. :) Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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% screwed since they can't change the > memory manager at all. Or at least, can't change the manager without > changing it everywhere. (Allocator policies allow mix-and-match.) I am glad that boost is not a Java library. :) Don't get me wrong, boost is an amazing library. I am learning from it every minute I look at it, great job guys thank you. However I was a bit shocked when I realized how ignorant boost is about memory policies. For instance boost::signals use std::vector<>, but it doesn't care to do anything about the allocator parameter. Some libraries would mix global new/delete calls with user defined memory policies and all that under the covers and the list goes on and on. I don't like the STL allocators too much but I'd like to see a modern C++ library that has consistent and clear memory policies. Instead of having an allocator template parameter for each class, perhaps we could design a global memory management class that can be scaled horizontally on the data type basis. It will require some way to associate a user defined allocator with data type. Then we would need to define STL-style allocators that will call the boost memory manager. The boost memory policy could be along the lines: 1. All boost classes have to use boost::allocator<> with STL allocators internally. std::vector >; 2. If a boost class needs to create an object it must call boost::mm. int *x = boost::getmm()->create(1); ... boost::getmm()->destroy(x,1); 3. The user can customize memory policies for her class by calling regmm boost::getmm()->regmm( MyAllocator() ); IMHO, in terms of memory management, this simple policy will make boost to look more like a C++ library not Java. It doesn't provide the flexibility of STL allocators but it does give the user some control over the memory. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 specific issues with > > how the DSP addresses the memory, I don't remember the details). > > > > This guy had to add his own new/delete operator to some of > > my internal classes to get about 10 times performance improvement. > > None of that indicates that he couldn't have replaced the native > allocator with a fast general-purpose allocator. > > > No, I really don't think that there is a hope for general purpose > > allocators. > > Why not? Sure he could have replaced the system allocator (I actually suggested it too) but why would he want to do it? The standard system allocator worked just fine for the rest of his program. Why would he want to implement a full blown memory manager. The problem was that my library had couple classes that get allocated/deleted very often it was the biggest performance hit. He just overloaded the new/delete in these classes and built a very simple fixed-size memory manager in a separate heap just for that. In fact a program might require different allocation strategies depending on the context. Replacing the global new/delete may not be an option. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 mean)? The culture is changing. :) > Are you sure that > there's no good general-purpose allocator which they can use? 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 specific issues with how the DSP addresses the memory, I don't remember the details). This guy had to add his own new/delete operator to some of my internal classes to get about 10 times performance improvement. No, I really don't think that there is a hope for general purpose allocators. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- "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 a solid
> > reason or not.
> > > I have to ship my class to someone else. She might have a solid reason, I
> > don't know.
> > > If I supply an allocator parameter, then I am covered and I can sleep
> > well. :)
> >
> > Well... if you ask me, it is better to not offer the functionality until
> > someone explicitly asks for it and gives a reasonable scenario as an
> > example. Features are easy to add, hard to remove, and there is always the
> > possibility that you "pre-included" the wrong feature.
>
> Peter, using your example I put together an allocator class that can be used in
> shared_ptr and
> STL
> at the same time. It is not too pretty but it works. If we could only customize
> the counter
> allocations, that would be it.
>
> namespace boostx
> {
> template< typename A >
> class allocator : public A
> {
> public:
> typedef A::value_type type;
> allocator() {}
>
> type* create()
> {
> type* p = allocate(1, 0);
> try
> {
> p = new(p) type;
> }
> catch(...)
> {
> deallocate( p, 1 );
> throw;
> }
> return p;
> }
>
> void operator()( type* p )
> {
> try
> {
> p->~T();
> }
> catch(...)
> {
> deallocate(p, 1);
> throw;
> }
> deallocate(p, 1);
> }
> };
> };
>
> template < class T, class A = boostx::allocator< std::allocator > >
> struct X
> {
> boost::shared_ptr _data;
> std::vector _list;
>
> X( const A& al = A() ) : _list(al)
> {
> A tmp(al);
> _data = boost::shared_ptr( tmp.create(), tmp );
> }
> };
>
> OR if you don't mind dropping the 'const' from the constructor
>
> template < typename T, class A = boostx::allocator< std::allocator > >
> struct X
> {
> boost::shared_ptr _data;
> std::vector _list;
>
> X( A& al = A() ) : _list(al), _data( al.create(), al )
> {
> }
> };
Sorry, disregard my prev e-mail. I should have said that 'A' must always be stateless.
But then, what is the point passing the A& thing around...
I guess my solution is a limited one. It is hard to get around it w/o
a built-in allocator support.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- "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 a solid
> > reason or not.
> > > I have to ship my class to someone else. She might have a solid reason, I
> > don't know.
> > > If I supply an allocator parameter, then I am covered and I can sleep
> > well. :)
> >
> > Well... if you ask me, it is better to not offer the functionality until
> > someone explicitly asks for it and gives a reasonable scenario as an
> > example. Features are easy to add, hard to remove, and there is always the
> > possibility that you "pre-included" the wrong feature.
>
> Peter, using your example I put together an allocator class that can be used in
> shared_ptr and
> STL
> at the same time. It is not too pretty but it works. If we could only customize
> the counter
> allocations, that would be it.
>
> namespace boostx
> {
> template< typename A >
> class allocator : public A
> {
> public:
> typedef A::value_type type;
> allocator() {}
>
> type* create()
> {
> type* p = allocate(1, 0);
> try
> {
> p = new(p) type;
> }
> catch(...)
> {
> deallocate( p, 1 );
> throw;
> }
> return p;
> }
>
> void operator()( type* p )
> {
> try
> {
> p->~T();
> }
> catch(...)
> {
> deallocate(p, 1);
> throw;
> }
> deallocate(p, 1);
> }
> };
> };
>
> template < class T, class A = boostx::allocator< std::allocator > >
> struct X
> {
> boost::shared_ptr _data;
> std::vector _list;
>
> X( const A& al = A() ) : _list(al)
> {
> A tmp(al);
> _data = boost::shared_ptr( tmp.create(), tmp );
> }
> };
>
> OR if you don't mind dropping the 'const' from the constructor
>
> template < typename T, class A = boostx::allocator< std::allocator > >
> struct X
> {
> boost::shared_ptr _data;
> std::vector _list;
>
> X( A& al = A() ) : _list(al), _data( al.create(), al )
> {
> }
> };
>
>
> Eugene
I forgot to mention, if the 'const' is dropped from the constructor, 'A' must be
stateless.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- 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 to someone else. She might have a solid reason, I
> don't know.
> > If I supply an allocator parameter, then I am covered and I can sleep
> well. :)
>
> Well... if you ask me, it is better to not offer the functionality until
> someone explicitly asks for it and gives a reasonable scenario as an
> example. Features are easy to add, hard to remove, and there is always the
> possibility that you "pre-included" the wrong feature.
Peter, using your example I put together an allocator class that can be used in
shared_ptr and STL
at the same time. It is not too pretty but it works. If we could only customize the
counter
allocations, that would be it.
namespace boostx
{
template< typename A >
class allocator : public A
{
public:
typedef A::value_type type;
allocator() {}
type* create()
{
type* p = allocate(1, 0);
try
{
p = new(p) type;
}
catch(...)
{
deallocate( p, 1 );
throw;
}
return p;
}
void operator()( type* p )
{
try
{
p->~T();
}
catch(...)
{
deallocate(p, 1);
throw;
}
deallocate(p, 1);
}
};
};
template < class T, class A = boostx::allocator< std::allocator > >
struct X
{
boost::shared_ptr _data;
std::vector _list;
X( const A& al = A() ) : _list(al)
{
A tmp(al);
_data = boost::shared_ptr( tmp.create(), tmp );
}
};
OR if you don't mind dropping the 'const' from the constructor
template < typename T, class A = boostx::allocator< std::allocator > >
struct X
{
boost::shared_ptr _data;
std::vector _list;
X( A& al = A() ) : _list(al), _data( al.create(), al )
{
}
};
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- 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 to someone else. She might have a solid reason, I > don't know. > > If I supply an allocator parameter, then I am covered and I can sleep > well. :) > > Well... if you ask me, it is better to not offer the functionality until > someone explicitly asks for it and gives a reasonable scenario as an > example. Features are easy to add, hard to remove, and there is always the > possibility that you "pre-included" the wrong feature. Ok, I'll let my users know who is to blame. :) I agree, if I am to use boost, providing an allocator parameter doesn't make much sense. shared_ptr news the ref counter and in general, boost doesn't allow a full memory management customization anyway. I agree that the STL allocators may not be the answer but then, what is. Counting on the standard allocator is certainly not an answer either. 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. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- 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(...)
> {
> a.deallocate(p, 1);
> throw;
> }
>
> return p;
> }
>
> static void destroy(A & a, T * p)
> {
> p->~T();
> a.deallocate(p, 1);
> }
> };
>
> The above doesn't respect A::pointer etc.
>
> Now you can _almost_ do the straightforward thing:
>
> template< class T, class A = std::allocator >
> struct Y
> {
>shared_ptr _data;
>std::list _list;
>Y(): _data( X::create(), X::destroy ) {...}
> };
I would change the definition of create/destroy in X<>:
static T * create(A & a = A() );
static void destroy(T * p, A & a= A());
Anyway it seems like a good solution, but it won't work pretty
for the reasons that you described later in your post.
shared_ptr should keep its own copy of A just like std::list does.
Then it'll be consistent with what people are used to in STL.
>
> except that X::create and ::destroy take a reference to an allocator.
> This should remind you that you forgot the allocator argument in the
> constructor:
Good point, I just ommitted it for simplicity sake.
>
> Y(A const & a = A()): ...
>
> Now _list will make itself a copy of that 'a'. This immediately hints at a
> potential problem:
>
> template< class T, class A = std::allocator > struct Z
> {
>std::list _list;
>std::list _list2;
> };
>
> where _list and _list2 will make their own copies and can't be made to share
> a single allocator instance. But let's ignore that (presumably the author of
> a stateful A will use a shared_ptr<> underneath so that copies
> use the same heap) and get back to our list+shared_ptr.
Yes, I am aware of this problem, shared_ptr or a static heap member will work.
>From my experience, it is exactly the case. Typically you don't want to
keep per-instance data in A.
> Now who should own the allocator that is used to construct or later destroy
> *_data? Should we use _list.get_allocator() for that? We can't since a copy
> of Y will copy _list but share _data, and the original may get destroyed
> along with the allocator. So we'll need to do something along the lines of:
>
> Y(A const & a = A()): _list(a), _data()
> {
> A a2(a); // original is const
> T * p = X::create(a2); // evaluation order
> _data.reset( p, bind(X::destroy, a2, _1) );
> }
>
> Not very pretty, but that's what you need to pay for being
> std::allocator-based; its interface is tailored for containers. For such a
Exactly, like I said before, shared_prt should keep its own copy of A.
> case I'd definitely consider going back to
>
> template< typename T > struct A
> {
>shared_ptr _data;
>std::list _list;
> };
>
> 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 to someone else. She might have a solid reason, I don't know.
If I supply an allocator parameter, then I am covered and I can sleep well. :)
>
> Or you can write your own alloc_ptr, of course, if you want to go the
> allocator route; it is quite a different beast compared to shared_ptr as it
> doesn't support polymorphism, for example, so it deserves its own name.
Perhaps, alloc_ptr should be included in boost. It'll give us a standard way to
integrate boost
and STL.
>
> But your code still looks somewhat artificial to me; why would you want to
> deep copy _list but shallow copy _data? It doesn't make much sense.
It is just an example. I agree, it does look artificial, but you can imaging
something along the
lines:
template< typename T, template A >
{
shared_ptr< T, A > _data;
shared_ptr< std::list< T,A >, A > > > _list;
};
It uses template template parameters and both _data and _list are shared.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- 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 think it would be great. However there is another problem. You have to new your object. shared_ptr s( new MyClass ); You cannot use allocator like you would expect: shared_ptr< MyClass, std::allocator > s; Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- 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, although many standard classes do allocate
> memory.
I agree. It means the STL is not consistent either.
So what are the boost recomendations for using STL containers and boost
in the same class?
I am using STL and trying to use boost in my daily
development. What can I do to implement consistent classes in terms
of memory management. For example, if I need to implement a class A
that has a container and pointer to a data type. I have two options:
template< typename T >
struct A
{
shared_ptr _data;
std::list _list;
};
template< typename T, template A = std::allocator >
struct A
{
shared_ptr _data;
std::list _list;
A : _data( new T() ) {...}
};
The problem with the first defenition is that I am limiting the built-in STL
functionality in
terms of memory management.
The problem with the second definition is that if I expose the allocator template
parameter, the
user of my class will expect that all memory allocations of type T are going to be
using her
allocator but boost::shared_ptr doesn't support it.
Could you please advise me?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: what happened to allocators in boost?
--- 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 boost::shared_ptr<>. I love boost::shared_ptr but because of the lack of the allocator<> concept, STL and boost just don't live together (including other boost libraries). I guess my question is that, is boost redefining the memory management concepts that have been established by STL? I am a bit suprised by small number of comments from boost developers on this issue. IMO, if boost is to become a C++ standard, we'd have to resolve this conflict. In the mean-time, what are the boost recomendations on how to use STL and boost together? I am really confused, am I missing something here? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: what happened to allocators in boost?
--- 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 deterministic allocator must inevitably have a separate heap for > each possible object size. The difficult part is reserving enough slots in > each heap at startup, before deterministic reaction is necessary. I don't > see how a system could do this automatically when memory is scarce. Depending on the requirements, you can try to overload new/delete for your data types and make it deterministic. I know it is not always an option. BTW: Having separate heaps is one of the reasons why I could not use boost::shared_ptr. I ended up writing my own. :( Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
> > --- 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 exactly the excuse I was talking about. "It is not
> practical to make a library that works out of the box, so users should be
> happy that they are getting a library that can be made to work with a
> "small" additional investment. Of course we'll gladly sell you the
> additional bits and pieces."
>
> It is interesting to compare the C++ approach with the Java approach to
> memory management in this context. C++ "pragmatically" accepts that the
> shipped malloc is often inadequate and provides several types of hooks that
> you can use to work around the problem. Java does not. If the JVM has a
> broken memory manager you lose and can do nothing about it. This gives C++ a
> short term advantage, but in the long term Java wins, since JVM implementors
> have no choice but to optimize their memory managers till they are blue in
> the face.
>
> Bugs that have no workarounds are always fixed first. :-)
It is an arguable position of course. I always thought that one of
the powers of a good C++ library is that it doesn't try to solve all
my problems but rather provide a convinient and efficient way to customize it.
I think that generic programming is all about that. In fact a generic
template library is compiled into a custom library for each application.
The developer provides data types and the library and C++ compiler do the rest.
The user data types are not hooks at all?
If you consider the memory as a data type and the memory management
as a policy then it is no different from any other template parameter in the library.
> So far my experience indicates that people only bother with allocators when
> std::allocator is inadequate, i.e. slow. Your case may, of course, be
> different. It happens sometimes.
It is not even an issue of an adequate malloc/free (they will never be
adequate for every case (another arguable statement :) ).
In one of my project, the standard malloc/free were quite adequate, but I had to use
a separate memory heap for some of my modules. Overloading
the global new/delete was not an option because the the rest of the code
need to be using the standard memory management. In this case,
the allocators proved to be very useful.
> A fairly aggressive way to state it, but I see your point. It is true that
> Boost does not impose any requirements on how the particular libraries
> obtain and manage their memory. But you need to realize that "do nothing"
> can be a conscious design decision. Lack of strict requirements means more
> freedom for the implementations to do what they consider best.
>
> As an example, consider a hypothetical std::vector that does not have an
> allocator argument and "has no idea how it manages its memory." Do you see
> the implications of that?
>
> 1. vector::resize and vector::reserve can now realloc in place since they
> can talk directly to the memory manager.
>
> 2. On many implementations, vector can now be made as efficient as new
> T[], since new T[] often stores the equivalent of size() and capacity()
> anyway to allow delete[] to do the right thing.
It is a problem with the STL allocator<> interface. An adequate allocator<>
interface should have realloc()/getsize() methods.
> > For example if a boost class X uses std::list, does it have to expose
> > the std::list<> allocator or should it use the standard
> > std::allocator<>.
> > template
> > struct X
> > {
> >std::list l;
> > };
> >
> > OR
> >
> > template >
> > struct X
> > {
> >std::list l;
> > };
> >
> > Which definition is more friendly to boost?
>
> The correct answer depends on X's interface. Your toy example is not a good
> illustration as this kind of "interface" is rarely seen.
How does it depend on the interface exactly? Is it possible to give
a good illustration?
> > Is it allowed for a boost libarary to use global new/delete? If so,
> > should it be documented?
>
> Boost libraries are allowed to use the C++ language without restrictions.
It means that I can never assume anything about memory calls in boost?
I understand your point about providing maximum flexibility to boost
developers but I am not sure it'll work well for some users.
Perhaps it'll be nice to the user to at least give her
some tips/notes on when a boost type makes use
of the standard memory manager.
The C++ developers have been spoiled by the STL allocator<> concept.
They may now be expecting too much... :)
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: what happened to allocators in boost?
--- 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 platforms, it is not practical
to make a
library that work out of the box. That is why STL has allocators. In one project, if
STL did not
have allocators, I would have to implement my own containers. I was so happy that I
didn't have
to do it.
At least a library should be consistent about memory management.
The issue is how consistent boost is about it (STL is very consistent)? It seems that
boost
doesn't have any idea about how it manages its memory.
For example if a boost class X uses std::list, does it have to expose the std::list<>
allocator or
should it use the standard std::allocator<>.
template
struct X
{
std::list l;
};
OR
template >
struct X
{
std::list l;
};
Which definition is more friendly to boost?
Is it allowed for a boost libarary to use global new/delete? If so, should it be
documented?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] xml library
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 in rather preliminary
> state (encodings support is missing, and also not all of XML constructs are
> supported). Anyway, I have used it in some projects for e.g. reading and
> writing configuration files. For reading, it uses an iterator, a little bit
> similar to istream_iterator. For writing, it uses interface similar to
> standard streams. Here you have a code presenting the interface of the
> library:
>
> void traverse(
> Â Â Â const xml::read_iterator& begin,
> Â Â Â const xml::read_iterator& end,
> Â Â Â const std::string& spaces)
> {
> Â Â Â for (xml::read_iterator it = begin; it != end; ++it)
> Â Â Â {
> Â Â Â if (it->type() == xml::element)
> Â Â Â {
> Â Â Â std::cout << spaces << it->str() << "\n";
> Â Â Â traverse(it->begin(),it->end(),spaces+" ");
> Â Â Â }
> Â Â Â }
> }
>
> int main()
> {
> Â Â Â // test read_iterator, the output is:
> Â Â Â // root
> Â Â Â //Â a
> Â Â Â std::istringstream iss(" b ");
> Â Â Â traverse(xml::read_iterator(iss),xml::read_iterator(),"");
>
> Â Â Â // test ostream, the output is:
> Â Â Â //
> Â Â Â //Â
> Â Â Â //
> Â Â Â xml::ostream xos(std::cout);
> Â Â Â xos << xml::tag("a") << xml::down <<
> Â Â Â xml::tag("b") << xml::attr("ee","f") <<
> Â Â Â xml::up;
> }
>
> If there will be an interest, I can submit the library code and extend it.
> Regards,
> Wojtek Surówka
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- 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 Template Lib). Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Re: Re: the boost::signal sample crashes
--- 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 my sample. > This means that they are > not portable to other OSes and boost::thread > has nothing to do with them. If i don't mind boost > main objective is portability. You just are not getting it :). My suggestion won't make boost unportable. It'll simply let the user to customize the class in a generic way. Do you see the difference? Generic customization is one of the main objectives of generic and template programming in modern C++. IMHO when a modern C++ library doesn't allow it (for no reasons practically), it looks crippled. > Anyway, if your implementation can't fix > link-to-correct-library > problems ... than what we are discussing ? :) > I was thinking that THIS was discussion subject. > Am i wrong ? Sorry, you are wrong. This discussion subjects were the link problem and be able to to use boost::thread with my toy OS and/or with different threading models without mocking with boost sources. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- 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 1 can call a library object in the > > context of an internal thread. > > > > What option do think is better? I think this > issuse > > will have a significant impact on our design. > > I think it would be too complicated to pass messages > across thread > boundaries. Is that what you were talking about? Sorry if I was not specific. My main point was that we'll need to specify a set of rules for the layer 1 API. Some of the rules will have to be concerned with how the layer 1 is expected (in terms of threads) to callback layer 2 functions. I think that there are 2 options (see above) on how it can be specified. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] how to use STL in boost
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_data;
};
If we do so, does it mean that all memory allocations
of type T inside class A have to use the provided
allocator?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
--- 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, STL has some implmentation specific .cpp files, is it a template library? I repeat the gui library itself will contain headers only (NO .cpp files). All the cpp files will be platform dependant that should be considered as customizations of the pure template library. The customizations could be even put in another namespace. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
--- 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 __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: UI++ [was: GUI sublanguage;Re: Re: Re: Re: GUI/GDI template library]
--- 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 > Port: 6667 > Channel: #vcf Thanks a lot! Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Re: Re: Re: the boost::signal samplecrashes
--- 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 system). Ahh, it is a truly portable solution... we are back into the last century. :) Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
--- 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 others away. > Which are the vast majority. Just for a peace of mind, Marcello. If you are doing a typical GUI programming on a standard platform, you wouldn't have to know about ImplTraits at all. It is like std::allocator<> many people who are successfully using STL don't even know much about it. On the other hand, it can give a lot of power to 'real' programmers (as you put it :)). For instance when I needed to build a module that had to use a custom memory heap (overloading the global delete/new was not an option), I was really glad that STL had the allocator template parameter, otherwise I would probably had to write my own containers. Anyway we are setting up a project on sf where we can discuss implementation details. It'll be up very soon. Stay turned, I'll post the project details to this list as soos as it is on-line. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- 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 of the current call. So I called it recursive design just for fun. :) Yes, it is iterative design. Thanks. > > (2) I'd say the library should be no less thread > safe than the > underlying API. Some APIs may be inherently > thread-unsafe (MFC for > instance). Does it mean that the library should be thread safe because an underlying API could be multi- threaded? I think there are two options. 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 1 can call a library object in the context of an internal thread. What option do think is better? I think this issuse will have a significant impact on our design. > (3) Use function objects ala boost::function<>? Sorry, I meant. Do we need to be able to send messages at layer 1/2 (ala SendMessage/PostMessage)? I don't think we need it at all, everything could be a function call? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI sublanguage ?
--- "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 own defaults and you should be > able to define new values > to subgroups or child containers (toolbars, iconic > view, etc.). > > A spacer could be used also to simulate an invisible > widget taking space. I > also agree that proportionnal dimension properties > of the layout manager > could be added, it would be really great to say: I > want to use 1/3 - 2/3 for > 2 widgets horizontally or 3/5 - 1/5 - 1/5 for my 3 > columns, etc. I think the library should be scaleable in respect to the space management. We can implment a set of predefined space managemenet strategies/polices, all the great stuff that we can come up with. However the user should be able to customize them in any way she likes. For instance the row/col management strategy can be just one of the predefined set. In general, I think that it is just an issues of clear definitions of space management basics that can be utilized by various specilized algorithms. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] ABI fixing and prefix/suffix headers (was theboost::signalsample crashes)
--- 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 lines of "Your library > doesn't work, it just > | crashes when I call anything", which almost always > turned out to be caused > | by ODR violations (either the user had changed an > ABI option, or had > linked > | to the wrong runtime-library-build variant), these > basically stopped > | overnight once I modified my code to stop those > (this was all in pre-boost > | days BTW). > > FWIW I do believe that automatic library selection > is a broken concept > in praxis. It causes no end of problems when there > is more than one > library that does it. In the end you end up with the > same situation as > before the user has to know about the different > runtime libraries and > how to handle them. > > Furthermore I do believe that dependencies should be > something that the > programmer is aware of and that they should be > actively managed by the > programmer. Automatic library selection hides > dependencies sometimes up > to the point that dll's aren't shipped to the > customer. > > Said that I can see your point John. I agree with John. I'd be much better if boost provided a clear description on how to build the library manually. I am having a bunch of problems with automatic boost builds especially when they include dlls. I also think that exporting C++ classes is a broken concept too. It is even worse than the automatic builds. Just my $0,02 Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- "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 ;) > What do you think about the name, > boost::SGTL > (Standrad GUI Template Library)? > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Re: the boost::signal sample crashes
--- 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 suggestion. I have put traits implemenations in cpp file in my proposal. #include are in cpp files as well. Sorry if my description was not clear. I hope you agree that in this case, there are not any performance issues? > link-to-correct-library problems again. We have it anyway. My solution didn't claim to resolve it completely, did it? However if I use thread_core.h directly and provide my own trait (my toy OS), it resolves the link-to-correct-library problems automatically, does it? > Let me guess ... part of application is using > threads > and part is woring as always in main thread ? > > "Models" term was wrong, sorry. > Under models i meant REALLY diffrent functionality > for threads. Like ToyOSThreads and Win32threads. > More correct is "Thread Implementation". Win32 has really different thread models. I have mentioned it several times in my posts. They have normal threads and fibers, do they? > I'm still trying. Hope you too. same here :) Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: the boost::signal sample crashes
--- 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 models aren't the only threading
> models out there, and one
> thing that Boost.Threads brings to the table is a
> threading model that is
> consistent across all platforms. How portable would
> a program that relies on
> two coexisting Win32 threading models be?
Well, how can I use boost::threads with my toy
operating system? Would it be possible to implement
the boost::threads core based on ImplTraits or polices
that users can customize? If so, then we could add
build options to use a set of wrappers for widely used
OS's. This way we'll solve all the compile time and
code size issues for "officially" supported platforms
and let users to scale/customize the core thread
functionality at the same time.
Everybody is happy!
Here is a simple example on how it could be done:
//
// thread_core.h
template
class thread_core
{
...
};
//end of thread_core.h
//=
//
//thread.h
#if defined WINDOWS
#define TRAITS WinThreadTraits
#elif defined VMS
#define TRAITS VmsThreadTraits
#elif defined OS2
#define TRAITS OS2ThreadTraits
#endif
template class thread;
//wrapper for the 'thread' class
class thread
{
public:
thread *m_pImpl;
};
//end of thread.h
//=
//==
//thread.cpp
#include "thread_core.h"
#include "thread.h"
//implement all the standard traits
//and the 'thread' wrapper functions
#if defined WINDOWS
struct WinThreadTraits
{
...
};
#elif defined VMS
struct VmsThreadTraits
{
...
};
#elif defined OS2
struct OS2ThreadTraits
{
};
#endif
thead::thread() : m_pImpl = new thread_core();
{
}
...
//end of thread.cpp
//==
In this sample thread_core.h has a complete code for
the thread_core class that can be scaled/customized by
using different traits. I could use it for my toy OS
directly.
The thread.h can be used for "official" platforms
only. It is just a thread_core wrapper.
thread.h doesn't include thread_core.h so there are
not any compilation time/code size issues.
The thread.cpp implements the "official" thread_core
wrappers.
thread.cpp can be build as a DLL/.lib for a specific
platform.
> I'm not opposed to providing an option to include
> all code into headers
> (e.g., a BOOST_SIGNALS_NO_LIB macro akin to the
> RegEx macro), and clearly
> where there are cases with problems stemming from
> the DLL/user code split
> (e.g., pointers allocated in the DLL and freed in
> user code)
BOOST_SIGNALS_NO_LIB would work just fine for me.
I agree with everything you said on the economics
issues. Fortunately there is a solution that can make
everybody happy. I'd suggest to consider the
architecture that I proposed above for both
boost::threads and boost::signals libraries.
> I'll fix the
> library, but I don't expect to see Boost moving
> toward putting more code
> into headers in the future.
IMHO we'll regret it later.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- 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 simplicity. > > Hmm of those I like Notus. > > Other ideas: > > Atlas > Hydra > Muse > MusE is a Linux music editor. > ... > > Eugene, you brought this whole thread up so I think > you should pick the > name :) I like Notus too (it is better when a namespace is short). I checked sourceforge, it is available. If there are not strong objections, let's use it as a codename for now. Hopefully the south wind will be good for the landscape of GUI development. :) I am going setup a sf project. Are there any guidelines on how to setup/structure sf projects that are intended to be submitted to boost? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- 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 elements of the layer 1 > API to implement > first. What do you think about: window, button, > edit, and static_text? > We can get a simple sub-language running on top of > those few controls > quickly enough. I think it'll be nice to include a container like control like list/tree control to demonstrate how they could be linked to STL iterators. I was thinking about starting to work on on the layer 2 design first. The idea is to design the layer 2 the way we'd like it to be first. It'll provide a set of natural requirements for layer 1. Using these requirement, we'll try to design the layer 1 traits/polices. Then we review it and decide whether it could be implemented on win32/X platform. If it doesn't work, we'll revisit the layer 2 design again and correct the layer 1 requirements. I'd suggest a recursive design procedure. :) I think we'll have to establish some basic design/implemntation polices/idioms. 1. For instance how we handle memory allocations, are we going to use std::allocator idiom or just new/delete. 2. Is the library thread-safe or not. 3. Event handling polices (send/post, etc.). Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- 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. > layer 1 - an abstraction of common GUI elements that > is at a lower level > than the 'domain specific sublanguage' of the > primary public interface, > but is implemented separately for each target GUI > API. > > layer 2 - The top level public interface is > implemented in terms of the > layer 1, platform independent API. There is only > one implementation of > the top level public interface. > > Does this sound better? It is exactly my preference... if, like you said before in your prev post, it is feasible to come with a nice layer one spec at all. I think it could be worth to try. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: UI++ [was: GUI sublanguage;Re: Re: Re: Re: GUI/GDI template library]
--- "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 issue. I am pretty much > convinced I know what I am > saying but it would be something else coding it in > details. I am in but I > can't affort every day development...! I can't afford it either. As for the timelines. Given the "work-at-spare-time" nature of this project, I would not spend any time trying to come up with a timeline. I think that our first objective is to get on the same page in terms of major design decisions (I am working on a proposal that hopefully we can use as the starting point for a detailed technical discussion). After the design is approved, we can subdivide the whole project and assign responsibilites. Then it is up to each developer to come up with a reasonable personal timeline (based on his/her personal schedule) for a part that she/he is going to be working on. What do you think? Feel free to e-mail me directly. Some people are complaining that we are taking too much of the boost's traffic. I have submitted a request for Notus to sf today. It takes up to 2 business days to get approved. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] UI++ [was: GUI sublanguage;Re: Re: Re: Re: GUI/GDI template library]
--- "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 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's site and we can discuss it there. I won't be able to pull it off by myself in a reasonable ammount of time. Hope you guys will join. Brock, Philippe, everyone interested, are we up to this challenge? Anyway, now is your last chance to change the project code name or convince me that the whole idea is just plain stupid. ;) Eugene 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 simplicity. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] what happened to allocators in boost?
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 to write something like this.
f()
{
shared_ptr< int, std::allocator > myptr;
myptr.allocate();
*myptr = 123;
}
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
--- 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? There is no policy anyway that forces us > to use > acronyms in boost. > > When Spirit was being reviewed, I was a bit afraid > that someone > would come out and suggest that it be named as BPL. > Akkk! > Fortunately, no one did. And after all, BPL already > stands for > boost python library. > > In the world of computers, it is already a sea of > acronyms. > IMO, acronyms are ugly! This is my opinion of > course. I > am entitled to my own opinion right? :-) Of course you are. ;) I'd like a normal name too. All these acronyms are just very easy to come up with. I've been lazy. ;) 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 simplicity. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: Re: [boost] boost and DLL's
--- 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 mangling 2. Using inline methods in the exported class. 3. Global class instanses in the DLL. How does boost ensure that inline methods don't conflict with the exported methods. The conflict can be platform specific. Is it allowed to have global instances of a class in boost's DLLs? Are there any development policies on how exported C++ classes should be implemented/tested in boost? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
--- 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 in increased > complexity to both the > implementation _and_ the interface? If decide to use method 1, I think the ability to use different layer1 implementations in the same program will come as a natural benefit w/o any additional complexity. Actually it is true for method 2 as well. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: the boost::signal sample crashes
--- 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 to > work for your OS. > 2. Edit build system to produce > boost::thread > library for your OS. > 3. Link your toy OS applications with THIS > library . > > Idea is simple : you are writing application for ONE > OS (toy or serious) hence you don't need > boost::thread > implementation for more than ONE OS in ONE > application. > IMO, it is true for GUI library :) > What is exactly wrong with my solution that doesn't have the ONE OS limitations, doesn't have any compilation time problems and supports my toy OS (or any other OS) directly (w/o editing the boost::thread implementation)? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI/GDI template library
--- 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 not sure. > > > I repeat the gui library itself will contain > headers > > only (NO .cpp files). > > ... Here you are telling NO CPP in your library. > > > All the cpp files will be > > platform dependant that should be considered as > > customizations of the pure template library. > > ... And here you are telling that there will be > some (platform dependant). > > Do you mean there will be two libraries/layers ? I suggest for you take a look at some other posts in this thread on the library layers. Let me know if you cann't fine them. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
--- 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 on real-life scenarios. > > Like, for a list_control that should show employees, > we would expect it to > show an array of employees. Therefore, have a > list_control_with_data< employee> employees_list; Thanks for taking a look at it. Good point. Actually your suggestion is not different from mine. Your code: list_control_with_data< employee> employees_list My code: edit tst; tst << 1; The confusion is that your interpretation (more traditional) of a modern GUI framework is a bit different from notus. We are not concerned with building low-level controls. The low-level implementation is basically proveded by the platform (Mac, win32, etc.). Notus is just going to be using it. Notus's objective is exaclty to connect the 'real-world' data (STL containers, etc) to the low-level GUI. In fact, the data-GUI connection and data/GUI management policies IS a low-level for notus, below is just a presentation layer. Traditional GUI toolkits are mostly concerned with the presentation level, notus is not! (well to a degree) Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
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 discussions. IMO, designing a scaleable notus core is a critical issue for the whole idea. We don't want notus to be just an another MFC or Qt with an endless fixed hierarchy of classes. I hope that we can come up with a truly innovative design using the ideas of generic programming. Anyone is welcome to join! Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Re: Re: [boost] GUI/GDI template library
--- 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 representation > scheme, but it might > become too complex. It's probably worth a try. In > the worst case, I > feel confident that we can make my brute-force > approach work. > I don't know much about other GUI systems but win32 and MFC. I think we can try to define the low-level layer using win32 and/or MFC as the starting point. If we cover these two, it'll be a good start and prove of concept. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Proposed smart_handle library
--- 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 particular case of handles, maybe there's not > a ton to wrap there, > but if you want to be generic as the original poster > suggested, you do need > to use parameterized types. > > Ah, one more point that was discussed... there was > much around operator-> > and operator* which don't make sense for certain > resources. With Loki's > SmartPtr, you can disable these two functions. > Granted, the error message > would be different, such as "get_reference not > found" as opposed to > "operator* not found". Would this be a major issue? > There is a discussion going on about a GUI/GDI template library. I think a smart handle library would be useful there. IMHO the policy/traits based approach is the way to go, actually not just for the smart_handle library, but for any boost library that needs to access platform specific features. Just my $.02. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
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's site and we can discuss it there. I won't be able to pull it off by myself in a reasonable ammount of time. Hope you guys will join. Brock, Philippe, everyone interested, are we up to this challenge? Anyway, now is your last chance to change the project code name or convince me that the whole idea is just plain stupid. ;) Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] what happened to allocators in boost?
--- 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 for components like shared_ptr that
> allocate one thing
I agree but there is a problem with classes that use
STL and boost components. Here is an example:
template < typename T, typename A = std::allocator
>
class node
{
public:
shared_ptr< T > m_data;
std::list m_children;
};
When the user writes
node< MyType, myallocator > node;
she will rightfully expect that all memory allocations
of type MyType will use the supplied allocator but
shared_ptr doesn't support it.
The fundamental problem here is that I don't see a
consistent (from the allocation standpoint) way to use
boost and STL components in one class.
>(and
> note that shared_ptr does not allocate the pointer
> it stores, although it
> does allocate a reference count).
How does the reference count get allocated? Do I have
any control over it except overloading the global
new/delete operators? I am writing a module that
needs to use a custom heap for some of my class
instances. The class has a shared_ptr. I guess that I
cannot use shared_ptr there?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
--- 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, usage patterns etc) > and for submissions > that have some code. I am already having problems > keeping up with the > list as is... I am sorry for plaguing your mail box. We are going to open a sourceforge project and move this discussion there. Please bear with us for couple more days, please... Basically we just need to agree on the name. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: GUI/GDI template library
--- 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 namespace will be boost::sgtl. I just wanted the name itself to be uniq w/o attaching boost:: to it. Eugene Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
--- 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 looking directly at Medusa, instead > looking only at her > reflection in the mirror of his polished shield. > > http://www.online-mythology.com/perseus_medusa/ Perseus is cool. Unfortunately it is taken on sourceforge and there are already a lot of s/w stuff with this name. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
--- 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 library itself. > What about simple boost::gui ? I would like to have an unique name without the boost prefix. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- 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, how about GTF (GUI Template Framework)? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- 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 implementations for > each GUI API? Do any > of you with cross platform development experience > have any opinions > about this? Good question! > > Here are the two possibilities as I see: > > Method 1 - common underlying representation method > > layer 1 - target GUI API > > layer 2 - low level GUI API interface wrapper. > There is one > implementation of this wrapper that compiles for all > target platforms, > using standard cross-platform development methods. > This layer may be > private to boost (in namespace detail). > > layer 3 - high level boost GUI API. This is the > public interface to our > GUI 'domain specific sublanguage'. It is > implemented on top of layer 2. > > > Method 2 - N implementations > > layer 1 - target GUI API > > layer 2 - high level boost GUI API. This is > implemented directly on top > of the target GUI API, for each target API, except > for the parts of the > sublanguage which can be implemented in terms of > other parts of the > sublanguage. > > > Method 1 pros > > - maintenance can be done in one place > - possible sharing of code amongst implementations > - layer 2 might eventually become another part of > the public interface > at a lower level (like phase (3) in Beman's first > post on this topic). To the method 1 pros list: - More user friendly. If the user implements the layer 1, she can use the library with her custom GUI platform. > > Method 1 cons > > - complexity. This is my main concern. I don't > know if we can > implement a low level API that works for all GUI > APIs. > - we have to implement all intended targets at once. > Adding new targets > affects code referring to existing targets Sorry why does adding new target affect code referring to existing targets? Could you give an example? > > Method 2 pros > > - implementation for each target is relatively > straightforward and self > contained > - we can add support for targets at leisure without > affecting existing > targets > > Method 2 cons > > - if changes need to be made they will have to be > made across N code > bases > - possible redundancy in various implementations to the the Method 2 cons list: - The user won't be able to use the library on top of a custom GUI (like some requested) unless she writes it from scratch. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- 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.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- 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 __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: the boost::signal sample crashes
--- 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 two diffrent >thread models will collaborate in one > application ? And why you may want this > mess ? They won't collaborate, you'll get a compile-time error, if you try. I don't think anybody requested a collaboration. > 2. A lot of implementation code will be > placed in headers, > which damages compile perfomance VERY > MUCH ... I hope you have already agreed > to this point. Do you ? Have you looked at my solution? It doesn't have compile performance problems for users. > 3. I haven't seen compiled application, > which is working with TWO OSes > or threading models at the same time. > Do you ? > Single/multi treaded is property > of whole application, but not of it's > part. > Current boost::thread design is just > reflection for this statement. Win32 already has two threading models that can be used in one app at the same time. They have put them there for a reason. I have seen applications that are using the both threading models. Sorry but it doesn't seem that you are making any effort at all to try to understand what I am proposing. Have you seen my proposal? Does it have any technical/peformance problems? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Re: Re: [boost] GUI/GDI template library
--- 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 scheme that could be implemented on top of an unknown number of platforms. The representation could be even expressed in terms of a C API, it doesn't matter. The modern C++ layer will use the single representation, and not worry about a specific platform at all. The C++ layer will reside in .h files completely. If we do something like this, then our library will support Rainer Deyke's requirements (see his post in this thread). Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Re: Re: [boost] GUI/GDI template library
--- 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. One layer is a low-level single interface specification that will be implemented independently for each target platform. This low-level interface can be designed in terms of pImpl or ImplTraits idioms (the design would have to be different depending on the idiom we choose). I favor the ImplTraits idiom. The higher layer it the actual gui::boost library that would be implement as a modern C++ library and reside in .h files completely. The boost::gui would always call the specified low-level interface to do the low-level stuff (like create_window, draw_text, etc.). Is it what you mean? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost and DLL's
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: the boost::signal sample crashes
--- 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, boost needs to get rid of any possibility of > > this to happen. Why does boost::signal() need a > > DLL/LIB in the first place? Would not be just the > .h > > file enough? > > > > It could be put in a .h, but there is a lot of code > in the library and > it makes sense to have it built as a .lib. I think that it doesn't make sense if we have all these problems that you are talking about below. If the user wants to speed the compile-time up, he/she can always create a simple wrapper around the standard signal.h. > Perhaps > another solution > would be for all the inlined code in the header to > be moved into the > .lib at a loss of performance. I would never do it. > I would just prefer a solution mentioned above where > the libs built by > boost have different name endings for debug/release > multi/single threaded. > > But this isn't the whole problem. The other problem > is compiler options > and such for the structures in the header files. > For example, data > alignment. boost builds with alignment of 8 for > Borland by default. If > your app uses another alignment option (we used to > use 4 for historic > reasons) then when you accessed objects returned > from the dll, you would > access the wrong offsets for the members because the > boost headers don't > force options such as this around there structures. > I have created a > duplicate set of headers for the parts of boost that > I use that force > compiler options using a #pragma push, then include > the boost header, > then pop those compiler options. I only ever > include my wrappers so > that I don't get caught by this and am free to use > whatever compiler > options I wish for the rest of the project. Forgive me but it seems insane to me that we make boost users to go through all this hell with .lib files. I am really worried about the road the boost comunity has choosen just to reduce the compile time. Please let the user to reduce the compile time (making his custom wrappers) any way he/she likes it. I want to be able to just include a .h file w/o having to verify that my program won't break from time to time because of some .lib/.h conflicts enforced on me by boost developers. On the side note: this boost road already lead to the fact that the boost::thread library is not up-to-date anymore. Win32 supports two threading models that can be used in one application at the same time. boost::thread doesn't allow it. I think if we continue down this road, boost will be in a big trouble becoming a true industry standard (at least for some of its components). IMHO boost::signals should be in a .h file completely. I can always reduce the compile time myself if I need to. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Re: [boost] GUI/GDI template library
--- 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 physhical layer (MFC) in the
template code. For example I am a bit worried about
defintions like this one:
namespace controls {
struct static_control :
controls::callback_cwnd {
enum { default_style = WS_CHILD | WS_VISIBLE |
SS_CENTERIMAGE };
void create(CWnd& parent,
const std::string& text = "",
unsigned int style = default_style,
const CRect& = CRect(0,0,0,0));
void create(CWnd& parent, unsigned int style);
};
}
It seems to me that it might not be very easy to clean
it up from all MFC references w/o a sustantial
architectural redesign.
As far as I remember you suggested to overwrite it
from scratch too. If we are to do it anyway, I think
we need to redesign it from scratch as well using your
library as a knowledge/experience base.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
--- 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 a look at the problem. IMO,
distributing objects between inlines and DLL functions
is not a very good idea. The classic example is:
//intended to be used as DLL.
class A
{
public:
char* m_data;
//compiled into application
inline ~A()
{
if(m_data) delete[] m_data;
}
//calls DLL
void init();
};
void A::init()
{
m_data = new char[10];
}
IMHO, boost needs to get rid of any possibility of
this to happen. Why does boost::signal() need a
DLL/LIB in the first place? Would not be just the .h
file enough?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI/GDI template library
--- 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 with this suggestion. I am wondering how realistic would it be? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
--- 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 strange to me, why are you willing to give up on your requirements. What is so unusual about them? I believe boost::gui must accomodate them and it can. Your requirements are very reasonable IMHO. > Nonetheless I also dislike the idea of > PhysicalGUILayer as a template > parameter to all GUI elements. PhysicalGUILayer is great for your requirements. Why do you dislike it? > It violates the > principle of Once and Only > Once. You can use a default template parameter for the PhysicalGUILayer and define it only once in your program. >(and > NativePhysicalGUILayer should be one of the > options). That way the actual structure of the GUI > does not depend on the > physical GUI layer, and the physical GUI layer can > even be selected at > runtime. > Exactly my point. Thanks for your post. Finally we have a set of requirements from someone who is doing custom GUI development. IMO boost::gui must be able to accomodate them. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: GUI/GDI template library
--- 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 windows.h Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI/GDI template library
--- 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... > > boost should be setting programming standards not > > laging behind trying to accomodate some specific > h/w > > requirements. > > You forgot one small thing ... development time > is very serious issue for programming. > If my work will be 10% coding/thinking and 90% > drinking coffee ... i prefer change my profession > to coffee taster :) Development speed is even > more important for developing GUI programs. > In most cases GUI program starts as something > small and can be developed/supported during > many years ... > Do you want to write excellent, > scalable, flexible, ... library that nobody wants > to use just because current computer-compiler > technology is not good enough for your lib ? >IMHO (not offensive) your ideas are too tied to > "new ideas" fashion in modern c++. They(ideas) are > good, very good unfortunately not always. > Please have mercy for people using > poor modern compilers :). > Cool, Bohdan! It is a great reply. I enjoyed it I really did. I agree, but we should be pushing these compiler guys a bit, should not we? :) Ok, I am going to get some beer... Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
--- 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++ programs/libraries. The h/w and compiler designers will have to deal with the compilation time issues. It is their job. When you are writing music the last thing that you should be thinking about is how these guys are going to play it :). > IMO it's nutty to think that people won't use every > bit of > compilation bandwidth they can stand, once they > start to do > computation at compile time. Why should it be any > different from > cycles at runtime? By people you mean developers. The developer's time is a tricky issue. If you have a better library with a long compilation time and not so good library with a better compilation performance, which one do you choose? If you choose the bad library, you can be saving on the compilation time but loosing on the development time. How do you count it? Do you care how much effort/time did it take to build you car? I don't. Personally I care about creating a beauty, not the compilation time. > In many ways, the more modern a C++ library is, the > more of a concern > compilation times have to be. I agree, but the other guys have to deal with it. However you still can be saving on the development time. By the development time, I mean the average development time of the industry. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: GUI/GDI template library
--- 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 same pImpl hiding effect. The user can just use a predefined ImplTraits class w/o any idea about its methods. > appeal for me. It makes the user of the class see > only what is relevant in > the class, The reason of hiding something from the user is not enough to throw away all the benefits of the ImptTraits idiom. See my discussion with Douglas Gregor about boost::thread library. I strongly believe that it needs to be overwritten. >while putting the implementation details > of the class interface > somewhere else. That it also speeds up compilation > by not having the class, > as the compiler sees it, change when the internal > class as represented by > its private pImpl pointer changes, is a side benefit > to it but not one I > consider overridingly important. I agree that it > achieves little other than > an aesthetic view of class internals and a speed up > in build times when a > class's implementation, as opposed to its end-user > interface, changes. As > such there is no pragmatic design reason why it is > necessary. These are the > major reasons, as I understand it, why the pImpl > idiom is generally used and > why I have used it. But there may be other reasons. Again see my discussin with DG. > I don't understand what this has to do with modern > C++ as you see it. But I > think that your view of modern C++, a term perhaps > taken from Mr. > Alexandrescu's fine book on template programming and > metaprogramming > techniques, It is a very good example or modern C++. > I only hope > that you don't get into > the habit of seeing all of modern C++ programming as > template programming > only, and view all other programming and design > idioms from that > perspective. In my view, modern C++ is template programming plus programming data types for these templates. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
--- 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 real job.
> > Did I get it right?
>
> Yes, and you're confused because I left part out.
> Sorry!
>
I personally don't see any significant benefits in
using pImpl here but there are lot of disadvantages.
For example you would have to make sure that all pImpl
functions use a set predefined data types. It means
that the pImpl functions will have to convert the data
between native format and pImpl.
In the case of ImplTraits you can use native data
types directly.
Example:
class win32
{
typedef WHND WinHnd;
};
template
class window
{
public:
ImplTraits::WinHnd m_hnd;
...
};
The bad list about pImpl goes on an on.
[...]
> They would typically all be part of (or a sub part
> of) the same gui
> object.
My personal preference is to have two kinds of
groupings.
1. Visual/behaviour grouping
2. Data groping.
Using the first the first option, you can group GUI
elements into one presentation group. The visual
grouping would be managed by gui managers.
The second option is similar to the MFC document/view
architecture. You could connect a data item in a list
control to an edit box (even in different dialogs) on
the data level. If one control changes the data, all
connected controls get updated automatically. This
kind of grouping will have to be independent from the
gui managers.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
--- 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 it?
The benefits are obvious. For instance if I had my
toy operating system, I could use boost::treads by
defining ImplTraits for my toy OS w/o going to the
boost sources. Another example is that Win32 already
has two different threading models, normal threads and
fibers that can be used at the same time in one
application. Theoritically boost::threads can be used
there as well.
thread thread;
thread fiber;
> Ah, so here's a question: what sort of relationship
> exists between
> myStandardDlg and myFancyDlg?
They can have a relationship on the data level only.
> Can I put a gui::button into a
> gui::dialog?
No, you cannot. The dialog class is just an example of
a high level object that manages lists of other
controls.
template
class dialog
{
std::list< control > m_contols;
//do stuff
};
NOTE: In my example, buttons in the
EllipticalShapeWin32Impl will look a behave the same
as in win32. Remember EllipticalShapeWin32Impl is
derived from win32 and overloads only edit box
functions. This is the beauty of ImplTraits you can
customize only a portion of it. Another big advantage
is that ImplTraits allows you to implement only stuff
you want to use. For example if all that you are
intending to use in your app is gui::window you don't
have to worry about contorl functions in your
ImplTraits. For example:
class MyTinyTraits
{
//simple window management
}
gui::window window;
ImplTraits is a very scaleable solution as well.
> 1) One communication system common to all GUI
> implementations?
> Then we are stuck translating every message into and
> out of this
> communication system. Not very clean, IMHO.
>
> 2) Communication through the ImplTraits? This seems
> the natural
> route, but now we have O(n^2) combinations of
> translations.
Good points, but I don't really think that we have to
go that far.
> What if I want
> to stick a Qt button into a Win32 dialog? Or a gtk+
> button into a Qt list
> box in a Motif dialog?
You can accomplish it at compile-time only by
overloading Qt traits for all buttons.
class MyQtTraits : public QtTraits
{
//overload button functions
};
dialog qtDlg;
dailog qtDlgWithGtkButtons;
> In a cross-platform framework, how deeply ingrained
> should our
> platform-specific decisions be?
It is a very good question. I think we should design
it based on our common sense and development
experience. I don't think that there is a simple rule
to answer this question.
> How does one write a
> truly portable GUI
> app: by starting with gui::dialog?
>
Actually gui::dialog<> is closer to the end, not the
start. It is a high level class that should have a lot
of policy/rules template parameters that will define
how the dialog behaves. The question of the
customization level and what type of polices it should
have, is related to you prev. question.
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
--- 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 > to the list. It's very hard to follow otherwise. Not > to mention somewhat > rude to the originator of the comments. > Sorry about that. It was Edward Diener. As you can see I am learning :). Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] GUI/GDI template library
> 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
> struct gui_wrapper :
> gui_wrapper_base {
>
> gui_wrapper(const Control& imp);
>
> //implements virtual functions by forwarding
> to Control
>
>private:
>
> Control imp;
>};
>
>template struct gui_application
> {
>
> template
> gui_application(const Control&
> control)
> : pimpl(new
> gui_wrapper(control) {
> }
>
> //also assignment operator, etc...
>
> //forward operations to pimpl
>
>private:
>
> boost::shared_ptr >
> pimpl;
>};
Something is confusing here. How does make_gui() get
used?
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 real job.
Did I get it right?
> I just learned aboutit today after my attachment was
> rejected for being
> too large and I gave up on the sandbox :) It's at:
>
> http://groups.yahoo.com/group/boost/files/
Thanks.
>
> you could connect two controls
> with my code like:
>
>set_manager( row( edit(&employee::name),
> edit(&employee::name)));
I don't think that it is exactly the same. If some
control changes the data, how do other connected
controls get updated in your code?
> I kind of like another poster's (Mr. Bouchard I
> think) idea of default
> control types. You might be able to simplify the
> above to:
>
>set_manager( row( &employee::name,
> &employee::name));
Agree, it sounds interesting.
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: GUI/GDI template library
> 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 specifications and generic (compile-time) programming. In modern C++, the program functionality can be customized by specifying custom data types and using them in a generic way (library). It is more like a type oriented programming not implementation driven. pImpl doesn't fit there. Don't get me wrong. I use pImpl myself but I try to avoid it as much as possible. 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... boost should be setting programming standards not laging behind trying to accomodate some specific h/w requirements. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
> 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 control to be an eleptical shape.
class ElepticalShapeWin32Impl : public gui::win32
{
//overload edit control stuff.
};
main()
{
gui::dialog myStandardDlg;
...
gui::dialog
myFancyDlg;
...
}
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
