On Thursday, 31 January 2013 at 07:34:52 UTC, d coder wrote:
To be honest deque can be implemented far better if random
access as in
indexing, removal and such is dropped.
As other people too pointed out, Deque is indeed a random access
range, so indexing operator is a must. Insert/Remove too are
good to
have. Array implementation in the std.container too implements
remove
and insert.
Another small issue is that this Deque implementation is a
Class.
std.container provides all the containers as structs. So for
sake of
consistency, we should implement Deque too as a struct.
Regards
- Puneet
Quite frankly, I'm bringing more and more into question the fact
that everything in phobos are structs, especially considering the
"no default constructor" problem.
The containers in std.container pretty much emulate final classes
via pointers to payloads anyways. Not doing it via classes only
brings problems.
And even if you succeed in coding the damn thing correctly
(Objects like DList had so many bugs I consider it virtually
unusable). The end result is subtle user bugs when passing
containers, if they have not been initialized yet. It creates an
ambiguity in behavior if or if not the container is initialized
(modification to the container inside the function may or may not
modify the outside container).
The only argument I see in favor of structs, is the possibility
of having a deterministic memory model (std.container.Array). I
don't think D's *generic* containers should do that though, IMO.
It also brings lots of problems, just for a specific use case.
Long story short, I'd say that unless you have a damn good reason
to stay with structs, use classes. It has easier user semantics
and much less room for implementation bugs.
(PS: Argument also applies to all the PRNGs.)
