mirror of
https://github.com/ethereum/solidity
synced 2023-10-03 13:03:40 +00:00
Merge pull request #5246 from ethereum/abi-type-array
Updates arrays section to improve order and clarify concepts
This commit is contained in:
commit
c60ec958ab
@ -811,40 +811,50 @@ Data locations are not only relevant for persistency of data, but also for the s
|
|||||||
Arrays
|
Arrays
|
||||||
------
|
------
|
||||||
|
|
||||||
Arrays can have a compile-time fixed size or they can be dynamic.
|
Arrays can have a compile-time fixed size, or they can have a dynamic size.
|
||||||
The are few restrictions for the element, it can also be
|
|
||||||
another array, a mapping or a struct. The general restrictions for
|
|
||||||
types apply, though, in that mappings can only be used in storage
|
|
||||||
and publicly-visible functions need parameters that are :ref:`ABI types <ABI>`.
|
|
||||||
|
|
||||||
An array of fixed size ``k`` and element type ``T`` is written as ``T[k]``,
|
The type of an array of fixed size ``k`` and element type ``T`` is written as ``T[k]``,
|
||||||
an array of dynamic size as ``T[]``. As an example, an array of 5 dynamic
|
and an array of dynamic size as ``T[]``.
|
||||||
arrays of ``uint`` is ``uint[][5]`` (note that the notation is reversed when
|
|
||||||
compared to some other languages). To access the second uint in the
|
|
||||||
third dynamic array, you use ``x[2][1]`` (indices are zero-based and
|
|
||||||
access works in the opposite way of the declaration, i.e. ``x[2]``
|
|
||||||
shaves off one level in the type from the right).
|
|
||||||
|
|
||||||
Accessing an array past its end causes a revert. If you want to add
|
For example, an array of 5 dynamic arrays of ``uint`` is written as
|
||||||
new elements, you have to use ``.push()`` or increase the ``.length``
|
``uint[][5]``. The notation is reversed compared to some other languages. In
|
||||||
member (see below).
|
Solidity, ``X[3]`` is always an array containing three elements of type ``X``,
|
||||||
|
even if ``X`` is itself an array. This is not the case in other languages such
|
||||||
|
as C.
|
||||||
|
|
||||||
|
Indices are zero-based, and access is in the opposite direction of the
|
||||||
|
declaration.
|
||||||
|
|
||||||
|
For example, if you have a variable ``uint[][5] x memory``, you access the
|
||||||
|
second ``uint`` in the third dynamic array using ``x[2][1]``, and to access the
|
||||||
|
third dynamic array, use ``x[2]``. Again,
|
||||||
|
if you have an array ``T[5] a`` for a type ``T`` that can also be an array,
|
||||||
|
then ``a[2]`` always has type ``T``.
|
||||||
|
|
||||||
|
Array elements can be of any type, including mapping or struct. The general
|
||||||
|
restrictions for types apply, in that mappings can only be stored in the
|
||||||
|
``storage`` data location and publicly-visible functions need parameters that are :ref:`ABI types <ABI>`.
|
||||||
|
|
||||||
|
Accessing an array past its end causes a failing assertion. You can use the ``.push()`` method to append a new element at the end or assign to the ``.length`` :ref:`member <array-members>` to change the size (see below for caveats).
|
||||||
|
method or increase the ``.length`` :ref:`member <array-members>` to add elements.
|
||||||
|
|
||||||
Variables of type ``bytes`` and ``string`` are special arrays. A ``bytes`` is similar to ``byte[]``,
|
Variables of type ``bytes`` and ``string`` are special arrays. A ``bytes`` is similar to ``byte[]``,
|
||||||
but it is packed tightly in calldata and memory. ``string`` is equal to ``bytes`` but does not allow
|
but it is packed tightly in calldata and memory. ``string`` is equal to ``bytes`` but does not allow
|
||||||
length or index access.
|
length or index access.
|
||||||
So ``bytes`` should always be preferred over ``byte[]`` because it is cheaper.
|
|
||||||
As a rule of thumb, use ``bytes`` for arbitrary-length raw byte data and ``string``
|
You should use ``bytes`` over ``byte[]`` because it is cheaper, since ``byte[]`` adds 31 padding bytes between the elements. As a general rule,
|
||||||
for arbitrary-length string (UTF-8) data. If you can limit the length to a certain
|
use ``bytes`` for arbitrary-length raw byte data and ``string`` for arbitrary-length
|
||||||
number of bytes, always use one of ``bytes1`` to ``bytes32`` because they are much cheaper.
|
string (UTF-8) data. If you can limit the length to a certain number of bytes,
|
||||||
|
always use one of the value types ``bytes1`` to ``bytes32`` because they are much cheaper.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
If you want to access the byte-representation of a string ``s``, use
|
If you want to access the byte-representation of a string ``s``, use
|
||||||
``bytes(s).length`` / ``bytes(s)[7] = 'x';``. Keep in mind
|
``bytes(s).length`` / ``bytes(s)[7] = 'x';``. Keep in mind
|
||||||
that you are accessing the low-level bytes of the UTF-8 representation,
|
that you are accessing the low-level bytes of the UTF-8 representation,
|
||||||
and not the individual characters!
|
and not the individual characters.
|
||||||
|
|
||||||
It is possible to mark arrays ``public`` and have Solidity create a :ref:`getter <visibility-and-getters>`.
|
It is possible to mark arrays ``public`` and have Solidity create a :ref:`getter <visibility-and-getters>`.
|
||||||
The numeric index will become a required parameter for the getter.
|
The numeric index becomes a required parameter for the getter.
|
||||||
|
|
||||||
.. index:: ! array;allocating, new
|
.. index:: ! array;allocating, new
|
||||||
|
|
||||||
@ -918,8 +928,10 @@ complications because of how arrays are passed in the ABI.
|
|||||||
|
|
||||||
.. index:: ! array;length, length, push, pop, !array;push, !array;pop
|
.. index:: ! array;length, length, push, pop, !array;push, !array;pop
|
||||||
|
|
||||||
Members
|
.. _array-members:
|
||||||
^^^^^^^
|
|
||||||
|
Array Members
|
||||||
|
^^^^^^^^^^^^^
|
||||||
|
|
||||||
**length**:
|
**length**:
|
||||||
Arrays have a ``length`` member that contains their number of elements.
|
Arrays have a ``length`` member that contains their number of elements.
|
||||||
|
Loading…
Reference in New Issue
Block a user