$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-04-10 14:34:31
So what about 1?
> > 2. Forwarding problem
> > This library is affected by forwarding problem. I do not know how
> important
> > it is, but may be we should use by-value scheme used by boost::bind?
>
> won't boost::ref <> "solve" this. (don't bind use &?)
No and no.
> > 3. Library doesn't allow to create const collections.
> > Well, I am not sure whether or not it's doable but currently it's not
> > supported
>
> It has already been suggested to support
>
> const vector<int> v = init( v )(1)(2).
How you plan to implement this? init( v ) wouldn't be able to modify v since
it is declared const.
> > 1. insert_assigner( C& c, const value_type& v )
> (a)
> >as well as
> > fixed_size_assigner( const iterator& begin, const iterator& end, const
> > value_type& v ) are unnecessary
> (b)
>
> (a) is used with operator+=()
You don't need it
template< typename C >
inline insert_assigner<C>
operator+=( C& c, const typename C::value_type& v )
{
return insert_assigner<C>( c ), v;
}
The same idea with second guy.
> (b) is used with operator<<(). If this goes away, it will sill eb used in
eg
>
> assign_all( array ) = 1,2,3;
Why?
> > 2. Should we use Boost::pp to implement insert_assigner,
> fixed_size_assigner
> > e.t.c. and have configurable limit?
>
> Some have wanted this. I have no problems with it besides I can't see what
> its good for.
> Having a function/constructor with more than X arguments (x small) is
hardly
> good practice.
Why 6 then? Why not 4?
> > 4. ~fixed_size_assigner
> > This method may throw an exception. Does it always safe to rely on
> > uncaught_exception call?
>
> No, it is not always safe, but the unsafe stuff happens if you use it in a
> destructor; not very
> likely. Sutter has an article about it.
Where?
> > 5. No function template ordering handling
> > Why not use usual trick with extra long parameter?
>
> Sure. What's the trick and what's the issue?
template< typename C, typename V >
inline void make_insertion( C& c, const V& v, long )
{
c.insert( c.end(), v );
}
...
void insert_( const value_type& v )
{
make_insertion( c_, v, 0 ); // 0 is of type int
}
Now you could use generic version even for compilers that does not support
partial ordering and you could remove all repetition from stl.hpp
Gennadiy.