From Deque to Std::stack,std::queue, to iOS Nsarray (Cfarray)

From Deque to Std::stack,std::queue, to iOS Nsarray (cfarray) deque

The deque double-ended queue, segmented continuous spatial data structure, is controlled by a central-controlled map (rather than a map, rather than an array), and each slot in the map points to a fixed-size buffer (continuous linear space).
The deque iterator, the key four pointers:

Cur     // refers to the current element in the buffer    First //the     end of the head in the referred buffer node    // point to central control slot

Start points to the first element in buffer that controls the first slot, and finish points to the last element in the buffer that the last slot in the control points to.
Each time you create a new deque, the central control map and nodes are created, and the start slot nstart and nfinish are calculated based on the initial number of elements.

21;

The reason for this is that the average performance is best when double-ended push or pop.

, if the push_back is required, just finish points to the buffer will be full, will be the map in a slot after the completion of a new buffer node, the corresponding Push_front will be in the map in the previous slot to create a new buffer node , if the map is not enough space, also want to reallocate_map, redistribute map space to migrate existing data, release old data.

Std::stack,std::queue

• Stack is filo data structure, only one export, if the above-mentioned deque implementation, sealing deque the head end of the opening, easy to achieve stack,stack often not be classified as container, and is classified as container adapter, the source is very short, The underlying container is deque (of course you can use list: Stack<int, List >)

class Sequence = deque<t>

• Queue is a FIFO data structure, sealed back exit and front entrance can be easily implemented, code with stack, is also considered container adapter.

Nsarray (Cfarray in CF-1151.16 source code)

Why isn't an adapter such as Stack,queue implemented in iOS? Should be Cfarray bottom is similar to the double-ended queue such data structure, can easily implement Filo or FIFO function, there is no need to superfluous again.
Just in the cfarray.c source code defines the __cfarraydeque, and various deque related operations methods.

struct __cfarraydeque {    uintptr_t _leftidx;    uintptr_t _capacity;     /* */};

But Apple's nsarray real realization who does not know, may also be the ring queue , this looks like the performance is higher, see this article;
and the implementation of other containers.

Summary

about why iOS does not implement Std::stack and std::queue, it may be that Apple feels nsmutablearray can be easily achieved by deque nature Filo or FIFO features, and then the implementation is superfluous it.
PS:CF source I have not finished reading, continue to chew it.

Reference

• "STL Source Code Analysis"
• http://blog.ibireme.com/2014/02/17/cfarray/
• Https://github.com/ibireme/yy_music_base/tree/master/yy_music_base

From Deque to Std::stack,std::queue, to iOS Nsarray (Cfarray)