> > --- 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<T> 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<T> 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<typename T>
> > struct X
> > {
> > std::list<T> l;
> > };
> >
> > OR
> >
> > template<typename T, typename A=stl::allocator<T> >
> > struct X
> > {
> > std::list<T, A> 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
