Re: Getting some code into container classes
On Sunday, 6 April 2014 08:11:43 UTC+3, woodb...@gmail.com wrote:
On Saturday, April 5, 2014 9:01:15 PM UTC-5, =D6=F6 Tiib wrote:
I am writing (third time perhaps?):
typedef std::deque<std::string> Stuff;
typedef BufIterator<Stuff> StuffIn;
std::vector<Stuff> Thing(StuffIn(buf), StuffIn());
Thanks for putting that into my terms. It helps a
little. In the original post I called reserve() on
the vector after getting the number of elements.
That looks like an optimization that's lost here.
You either have cheap way to predict the end of
sequence and distance before-hand or not. If you
have it then use it, if you don't have it then you
can't use it. If you want some static 'maybe' to work
here then you use templates; if you want dynamic
'maybe' to work then you use dynamic polymorphism. You
can maybe want to read up on SCARY iterators and why
those are good.
Also you can use the second form that I also wrote
about already:
template<typename Stuff,typename Alloc>
Buf& operator>>(Buf& in, std::vector<Stuff,Alloc>& p)
{ /* ... */ }
Usage of 'reserve' can anyway happen only in 3-step
initialization:
Something something;
// next two steps can be done by 'operator>>'
something.reserve( predictSize() );
fillItSomehow( something );
That works at the top level, but it doesn't work at
the next level for the deques. (I know deque has a
ctor that takes iterators, but there's no place to
supply the iterators.)
Why can't 'BufIterator<std::deque<std::string>>'
supply 'SomeIterator<std::string>' to deque?
Or why can't 'BufIterator<std::deque<std::string>>' use
that Buf& operator>>(Buf& in, std::deque<std::string>& p)
for something if you feel that it does what you want?
Part of the difficulty has to do with the two parameters.
If containers took a "range" object it would be easier.
I remember some discussion of that subject a few years
ago, but I don't know where that stands.
What difficulty? Your description of issues is a bit
like FUD.
I'm not sure ranges are the answer though either.
I think they'd force me to deal with items one by one.
If an array<double, 1000000> is expected, there's no
way to use an optimization?
What optimization? How can a constructor of standard
library container access your "buf" more optimally than
special "buf_iterator" made by you?
Using copy/memcpy on a block of data. Maybe the
optimization is possible with what you are saying,
but I haven't understood how it would be done.
Uhh ... you got me started. :D
Code of standard containers won't be required to
contain 'memcpy' *ever*. You either have to write it
explicitly somewhere or learn what loops particular
compiler optimizes into 'memcpy'. 'std::array' won't
*ever* have any written constructors; all will be
compiler-generated. 'array' is required to be
aggregate. If 'array's contents come from dynamic
source then you have to fill it with your function
(say 'operator>>'). Function is yours and so the
possible 'memcpy' is yours.
Dynamic container of standard library may use
'memcpy' (again written by you) during construction
and other usages. It is because elements of such
containers are usually required to be copied, moved
or otherwise constructed by calling
'allocator_traits<allocator_type>::construct'
and allocator may be any class given by you and its
traits may be specialized by you and so there are
lot of places for 'memcpy' written by you.
Currently most powerful optimization with dynamic
containers is move (not memcpy). Move means that if
the 'allocator' is same then the ownership of internals
is transferred, otherwise elements are move-constructed
one-by-one. Needlessly copying too lot of crap around
in huge and slow memory-space of modern hardware
(regardless if with that error-prone 'memcpy' or
otherwise) is typical cause of performance issues.
For my taste there are already too lot of alternative
ways to inject ones will into behavior of standard
containers. It is lot to learn so people don't. It is
impossible to micromanage and improve work of standard
library without knowing what it does. However people
are humans with their FUD about things they sense their
extent of ignorance about.
Strange result is that people ask for some yet another
"magic" way. It is even *more* impossible that standard
library will extend itself with something that knows
what to do with yet another strange "buf" that "Give"s
and uses opportunity to "memcpy" it.
Learn what standard library does. Both 'vector' and
'deque' have already 6 constructors one of what is
template. Then if some other container you want to
extend (say Leigh wrote it or you took it from boost)
is not so over-abundantly flexible then you can
contact the authors with improvement requests that
make sense.