有什么理由不使用
uint[2**160-1] addressIndex;而不是
mapping(address => uint) addressIndex;?
发布于 2020-01-08 04:15:59
下面的答案指的是以下几个方面的区别:
mapping(address => uint)struct {address key; uint value;}元素数组这不是这里要问的。
我把它留在这里是因为我觉得它在这个问题上仍然有所贡献.
我希望这张桌子能回答你的问题:
|----------------|---------|-------|
| | Mapping | Array |
|----------------|---------|-------|
| Add an item | O(1) | O(1) |
|----------------|---------|-------|
| Remove an item | O(1) | O(n) |
|----------------|---------|-------|
| Find an item | O(1) | O(n) |
|----------------|---------|-------|只有在给出下列任何限制的情况下,才应选择数组而不是映射:
发布于 2020-01-08 12:30:43
它们大致相同。
您的固定大小的数组布局一个非常大的地址空间,其中每个可能的地址等效有一个插槽。这在逻辑上相当于mapping所做的工作,尽管布局不同(见下面Ismael的评论),因此在汽油成本方面略有不同。
为了提高可读性,我会倾向于映射。坚固性要求对惯用的、可读的代码有很强的偏好,因此有一个反对冗长的论点。
在这个小小的例子中,数组有一个轻微的、几乎微不足道的气体效率优势(为了从Remix获得一些气体计算,视图被有意删除)。
pragma solidity 0.5.12;
contract ArrayMapping {
uint[2**160-1] addressIndex;
mapping(address => uint) mapped;
function getArray(uint row) public returns (uint) { // <== 1128 gas
return addressIndex[row];
}
function getMap(address a) public returns (uint) { // <== 1174 gas
return mapped[a];
}
}如果有用的话,本教程将介绍一些将数组和映射放在一起的方法。https://medium.com/robhitchens/solidity-crud-part-1-824ffa69509a
或者,您可能感兴趣:是否有妥善解决的和简单的存储模式的坚固性?
此外,您的意图是明确的,但它可能是一个好主意,明确的类型设置,以确保您的表达式做了您认为它做的。IIRC已经改变了隐式铸造,但是为什么不显式呢?
uint(uint(2)**uint(160)-uint(1)) addressIndex;这是为了确保你不会陷入这样的陷阱:实心指数算子中的意料之外隐式投射
希望能帮上忙。
https://ethereum.stackexchange.com/questions/78790
复制相似问题