参数此时，挪用者1不知道下一个读取位置。
function lastItem() public view returns (uint256)
等智能合约平台增加了一些重要的思量因素。可以运行多年的代码赋予术语“无限制”一个全新的寄义。
在大大都应用中，利用列表相当简朴。大大都语言都提供用于处理惩罚列表的库，我们不必担忧利用细节。可是，智能合约差异于“大大都应用措施”，我们需要出格留意施加的设计限制。
列表读取
列表的特性
挪用者1>read(4,3) Returns: ([Item4, Item5, Item6], 7)压入仓库
function update(uint256 id, address addr) external
假设挪用者批量一次读取3个元素，以下是最原始的列表重要的是默认地点值（即零值）的影响。我的代码包括一个很是利便的假设，即任何地点为零都是无效的。我们可以办理此限制。可是，在所有环境下，我们都需要某种要领来识别无效（未初始化）的元素。
挪用者1> read(4,3) Returns:([Item4, Item5, Item6], 7)
([Item4, Item5, Item6],4)
function totalItems() public view returns (uint256)
预留的零编号
挪用者1可以利用仓库来办理此问题。对付每次乐成的挪用，挪用者1会将读取开始参数和返回的项目数组压入仓库。失败时，c挪用者1通过从仓库中弹出功效并反复读取操纵。让我们看一个例子：
通过这两个值的直接引用可以帮我们读取和添加元素。
列表相当于编号和ListElement布局体的映射干系mapping(uint256 => ListElement) private items;
我们来看下函数签名function read(uint256 start, uint256 toRead) external viewreturns (address[] memory addrList, uint256 next)
挪用者1>read(4,3) Returns: ([Item4, Item5, Item6], 8)压入仓库:
([Item1, Item2, Item3], 0)
在github中可以找到文中涉及的完整代码[5]
为了制止此类问题，我们实现了双向链接列表。利用此办理方案，添加/删除元素耗损gas量与列表巨细无关。添加元素将新条目附加到列表的末端。删除元素只需要更新已删除元素之前和之后的元素的指针。最重要的是，删除元素不会发生“间隙”。
要留意的另一个小细节是保存ID为零的映射项。因此，永远不能通过合约接口建设/删除它。
遍历列表来统计列表元素的个数会导致gas的耗损跟着列表长度差异而差异。
[8]function pagedRead in 02_read_stack.js: https://github.com/kaxxa123/BlockchainThings/blob/master/UnboundedList/test/02_read_stack.js
在我设计的列表中，要留意有一个特定于该应用措施的假设。这里我们有一个地点列表，因此数据被生存在ListElement addr中。虽然，你可以用任何其他变量取代。
([Item1, Item2, Item3], 0)
uint256 prev;
零元素是无效的
totalItems储存着列表中总元素的个数。利用这个变量的原因也是按照应用而定的。实际上我们此刻这个合约中并非必然需要，我们可以删除来节减gas，然而我这里利用是为了防备其他应用中需要。
映射可以视作哈希表 它们在实际的初始化进程中建设每个大概的key， 并将其映射到字节形式全是零的值：一个范例的默认值
挪用者2>remove(7)
挪用者1>read(<span 0,3) Returns: ([Item1, Item2, Item3], 4)压入仓库
([Item4, Item5, Item6], 4)
最后一次返回0，，暗示已经读取完毕。
可是为了简朴起见，我在这里不做。请记着，利用映射可以辅佐我们确定哪些是我们本身生成的元素。
function remove(uint256 id) external
通过查察function pagedRead in 02_read_stack.js[8] 进修如何应用列表举办分页阅读
我们来看看这个[6]智能合约代码,尤其是用于储存的状态变量。每一个列表元素由3部门信息，一个指向前一个元素，一个指向后一个元素，再加上元素数据自己。
[9]Alexander Zammit: http://www.blockchainthings.io/author.aspx?i=1编号为零的元素储存着第一次和最后一个列表元素的指针。第一个元素为：items[0].next
nextItem储存着下一个元素的编号，可以担保编号的独一性，以及删除的编号不再被利用。
因为这个原因，将列表存储在简朴数组中不是个好的选择。简朴数组的主要问题是跟着开始删除元素，需要打点好元素之间的”间隙“。添加/删除的元素越多，简朴数组的会变得更碎片化，需要举办某种压缩。我们很容易可以利用一个函数举办压缩，该函数gas耗损取决于所列元素的数量。譬喻，移位操纵取决于已删除元素后头的元素数量：
列表状态变量储存布局[3]learnblockchain.cn/article…: https://learnblockchain.cn/article/1425
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
