2015-12-07 20:16:25 +00:00
|
|
|
.. index:: ! contract
|
|
|
|
|
|
|
|
##########
|
|
|
|
Contracts
|
|
|
|
##########
|
|
|
|
|
2016-09-05 14:29:08 +00:00
|
|
|
Contracts in Solidity are similar to classes in object-oriented languages. They
|
2016-03-10 19:53:13 +00:00
|
|
|
contain persistent data in state variables and functions that can modify these
|
|
|
|
variables. Calling a function on a different contract (instance) will perform
|
|
|
|
an EVM function call and thus switch the context such that state variables are
|
|
|
|
inaccessible.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
.. index:: ! contract;creation
|
|
|
|
|
|
|
|
******************
|
|
|
|
Creating Contracts
|
|
|
|
******************
|
|
|
|
|
|
|
|
Contracts can be created "from outside" or from Solidity contracts.
|
|
|
|
When a contract is created, its constructor (a function with the same
|
|
|
|
name as the contract) is executed once.
|
|
|
|
|
2017-05-03 17:24:00 +00:00
|
|
|
A constructor is optional. Only one constructor is allowed, and this means
|
2016-10-15 22:04:01 +00:00
|
|
|
overloading is not supported.
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
From ``web3.js``, i.e. the JavaScript
|
2015-12-07 20:16:25 +00:00
|
|
|
API, this is done as follows::
|
|
|
|
|
2016-08-01 10:14:17 +00:00
|
|
|
// Need to specify some source including contract name for the data param below
|
2017-04-18 01:41:28 +00:00
|
|
|
var source = "contract CONTRACT_NAME { function CONTRACT_NAME(uint a, uint b) {} }";
|
2016-08-11 20:50:27 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
// The json abi array generated by the compiler
|
|
|
|
var abiArray = [
|
2016-05-18 15:05:28 +00:00
|
|
|
{
|
|
|
|
"inputs":[
|
|
|
|
{"name":"x","type":"uint256"},
|
|
|
|
{"name":"y","type":"uint256"}
|
|
|
|
],
|
|
|
|
"type":"constructor"
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"constant":true,
|
|
|
|
"inputs":[],
|
|
|
|
"name":"x",
|
|
|
|
"outputs":[{"name":"","type":"bytes32"}],
|
|
|
|
"type":"function"
|
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
];
|
|
|
|
|
2016-05-30 20:27:02 +00:00
|
|
|
var MyContract_ = web3.eth.contract(source);
|
|
|
|
MyContract = web3.eth.contract(MyContract_.CONTRACT_NAME.info.abiDefinition);
|
2015-12-07 20:16:25 +00:00
|
|
|
// deploy new contract
|
|
|
|
var contractInstance = MyContract.new(
|
2016-05-18 15:05:28 +00:00
|
|
|
10,
|
|
|
|
11,
|
2016-08-01 10:14:17 +00:00
|
|
|
{from: myAccount, gas: 1000000}
|
2015-12-07 20:16:25 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
.. index:: constructor;arguments
|
|
|
|
|
|
|
|
Internally, constructor arguments are passed after the code of
|
|
|
|
the contract itself, but you do not have to care about this
|
2016-05-24 17:57:36 +00:00
|
|
|
if you use ``web3.js``.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
If a contract wants to create another contract, the source code
|
|
|
|
(and the binary) of the created contract has to be known to the creator.
|
|
|
|
This means that cyclic creation dependencies are impossible.
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2016-09-05 11:54:54 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract OwnedToken {
|
2015-12-30 09:53:41 +00:00
|
|
|
// TokenCreator is a contract type that is defined below.
|
|
|
|
// It is fine to reference it as long as it is not used
|
|
|
|
// to create a new contract.
|
|
|
|
TokenCreator creator;
|
|
|
|
address owner;
|
|
|
|
bytes32 name;
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-30 09:53:41 +00:00
|
|
|
// This is the constructor which registers the
|
|
|
|
// creator and the assigned name.
|
|
|
|
function OwnedToken(bytes32 _name) {
|
2016-09-05 14:29:08 +00:00
|
|
|
// State variables are accessed via their name
|
|
|
|
// and not via e.g. this.owner. This also applies
|
|
|
|
// to functions and especially in the constructors,
|
|
|
|
// you can only call them like that ("internall"),
|
|
|
|
// because the contract itself does not exist yet.
|
2015-12-30 09:53:41 +00:00
|
|
|
owner = msg.sender;
|
|
|
|
// We do an explicit type conversion from `address`
|
|
|
|
// to `TokenCreator` and assume that the type of
|
|
|
|
// the calling contract is TokenCreator, there is
|
|
|
|
// no real way to check that.
|
|
|
|
creator = TokenCreator(msg.sender);
|
|
|
|
name = _name;
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-30 09:53:41 +00:00
|
|
|
function changeName(bytes32 newName) {
|
|
|
|
// Only the creator can alter the name --
|
|
|
|
// the comparison is possible since contracts
|
|
|
|
// are implicitly convertible to addresses.
|
2016-07-27 07:27:56 +00:00
|
|
|
if (msg.sender == address(creator))
|
2016-05-11 19:30:31 +00:00
|
|
|
name = newName;
|
2015-12-30 09:53:41 +00:00
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-30 09:53:41 +00:00
|
|
|
function transfer(address newOwner) {
|
|
|
|
// Only the current owner can transfer the token.
|
|
|
|
if (msg.sender != owner) return;
|
|
|
|
// We also want to ask the creator if the transfer
|
|
|
|
// is fine. Note that this calls a function of the
|
|
|
|
// contract defined below. If the call fails (e.g.
|
|
|
|
// due to out-of-gas), the execution here stops
|
|
|
|
// immediately.
|
|
|
|
if (creator.isTokenTransferOK(owner, newOwner))
|
|
|
|
owner = newOwner;
|
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
contract TokenCreator {
|
2015-12-30 09:53:41 +00:00
|
|
|
function createToken(bytes32 name)
|
2015-12-07 20:16:25 +00:00
|
|
|
returns (OwnedToken tokenAddress)
|
2015-12-30 09:53:41 +00:00
|
|
|
{
|
|
|
|
// Create a new Token contract and return its address.
|
|
|
|
// From the JavaScript side, the return type is simply
|
|
|
|
// "address", as this is the closest type available in
|
|
|
|
// the ABI.
|
|
|
|
return new OwnedToken(name);
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-30 09:53:41 +00:00
|
|
|
function changeName(OwnedToken tokenAddress, bytes32 name) {
|
|
|
|
// Again, the external type of "tokenAddress" is
|
|
|
|
// simply "address".
|
|
|
|
tokenAddress.changeName(name);
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-30 09:53:41 +00:00
|
|
|
function isTokenTransferOK(
|
|
|
|
address currentOwner,
|
|
|
|
address newOwner
|
|
|
|
) returns (bool ok) {
|
|
|
|
// Check some arbitrary condition.
|
|
|
|
address tokenAddress = msg.sender;
|
2016-10-06 12:24:36 +00:00
|
|
|
return (keccak256(newOwner) & 0xff) == (bytes20(tokenAddress) & 0xff);
|
2015-12-30 09:53:41 +00:00
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
.. index:: ! visibility, external, public, private, internal
|
|
|
|
|
2017-02-02 23:52:34 +00:00
|
|
|
.. _visibility-and-getters:
|
2015-12-21 15:54:32 +00:00
|
|
|
|
2017-02-02 23:52:34 +00:00
|
|
|
**********************
|
|
|
|
Visibility and Getters
|
|
|
|
**********************
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
Since Solidity knows two kinds of function calls (internal
|
|
|
|
ones that do not create an actual EVM call (also called
|
|
|
|
a "message call") and external
|
|
|
|
ones that do), there are four types of visibilities for
|
|
|
|
functions and state variables.
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
Functions can be specified as being ``external``,
|
|
|
|
``public``, ``internal`` or ``private``, where the default is
|
|
|
|
``public``. For state variables, ``external`` is not possible
|
|
|
|
and the default is ``internal``.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
``external``:
|
2015-12-07 20:16:25 +00:00
|
|
|
External functions are part of the contract
|
|
|
|
interface, which means they can be called from other contracts and
|
2016-05-24 17:57:36 +00:00
|
|
|
via transactions. An external function ``f`` cannot be called
|
|
|
|
internally (i.e. ``f()`` does not work, but ``this.f()`` works).
|
2015-12-07 20:16:25 +00:00
|
|
|
External functions are sometimes more efficient when
|
|
|
|
they receive large arrays of data.
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
``public``:
|
2015-12-07 20:16:25 +00:00
|
|
|
Public functions are part of the contract
|
|
|
|
interface and can be either called internally or via
|
2017-02-02 23:52:34 +00:00
|
|
|
messages. For public state variables, an automatic getter
|
2015-12-07 20:16:25 +00:00
|
|
|
function (see below) is generated.
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
``internal``:
|
2015-12-07 20:16:25 +00:00
|
|
|
Those functions and state variables can only be
|
|
|
|
accessed internally (i.e. from within the current contract
|
2016-05-24 17:57:36 +00:00
|
|
|
or contracts deriving from it), without using ``this``.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
``private``:
|
2015-12-07 20:16:25 +00:00
|
|
|
Private functions and state variables are only
|
|
|
|
visible for the contract they are defined in and not in
|
|
|
|
derived contracts.
|
|
|
|
|
2015-12-14 15:22:32 +00:00
|
|
|
.. note::
|
|
|
|
Everything that is inside a contract is visible to
|
2016-05-24 17:57:36 +00:00
|
|
|
all external observers. Making something ``private``
|
2016-08-18 11:16:01 +00:00
|
|
|
only prevents other contracts from accessing and modifying
|
2015-12-14 15:22:32 +00:00
|
|
|
the information, but it will still be visible to the
|
|
|
|
whole world outside of the blockchain.
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
The visibility specifier is given after the type for
|
|
|
|
state variables and between parameter list and
|
|
|
|
return parameter list for functions.
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2016-09-05 11:54:54 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2016-05-18 15:11:39 +00:00
|
|
|
contract C {
|
2015-12-30 09:53:41 +00:00
|
|
|
function f(uint a) private returns (uint b) { return a + 1; }
|
|
|
|
function setData(uint a) internal { data = a; }
|
|
|
|
uint public data;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
2016-08-25 17:57:56 +00:00
|
|
|
In the following example, ``D``, can call ``c.getData()`` to retrieve the value of
|
|
|
|
``data`` in state storage, but is not able to call ``f``. Contract ``E`` is derived from
|
|
|
|
``C`` and, thus, can call ``compute``.
|
2016-08-25 08:43:17 +00:00
|
|
|
|
|
|
|
::
|
|
|
|
|
2017-07-10 22:07:27 +00:00
|
|
|
// This will not compile
|
|
|
|
|
2016-09-05 11:54:54 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2016-08-25 08:43:17 +00:00
|
|
|
contract C {
|
2016-08-25 17:57:56 +00:00
|
|
|
uint private data;
|
|
|
|
|
2016-08-25 08:43:17 +00:00
|
|
|
function f(uint a) private returns(uint b) { return a + 1; }
|
|
|
|
function setData(uint a) { data = a; }
|
2016-08-25 17:57:56 +00:00
|
|
|
function getData() public returns(uint) { return data; }
|
|
|
|
function compute(uint a, uint b) internal returns (uint) { return a+b; }
|
2016-08-25 08:43:17 +00:00
|
|
|
}
|
|
|
|
|
2016-08-25 17:57:56 +00:00
|
|
|
|
2016-08-19 14:47:57 +00:00
|
|
|
contract D {
|
2016-08-25 08:43:17 +00:00
|
|
|
function readData() {
|
2016-08-25 19:44:16 +00:00
|
|
|
C c = new C();
|
2016-08-25 17:57:56 +00:00
|
|
|
uint local = c.f(7); // error: member "f" is not visible
|
2016-08-25 19:44:16 +00:00
|
|
|
c.setData(3);
|
2016-08-25 17:57:56 +00:00
|
|
|
local = c.getData();
|
|
|
|
local = c.compute(3, 5); // error: member "compute" is not visible
|
2016-08-25 19:44:16 +00:00
|
|
|
}
|
2016-08-25 08:43:17 +00:00
|
|
|
}
|
|
|
|
|
2016-08-25 17:57:56 +00:00
|
|
|
|
2016-08-25 08:43:17 +00:00
|
|
|
contract E is C {
|
|
|
|
function g() {
|
2016-08-25 19:44:16 +00:00
|
|
|
C c = new C();
|
2016-08-25 17:57:56 +00:00
|
|
|
uint val = compute(3, 5); // acces to internal member (from derivated to parent contract)
|
2016-08-18 11:16:01 +00:00
|
|
|
}
|
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2017-02-02 23:52:34 +00:00
|
|
|
.. index:: ! getter;function, ! function;getter
|
2017-07-01 03:29:20 +00:00
|
|
|
.. _getter_functions:
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2017-02-02 23:52:34 +00:00
|
|
|
Getter Functions
|
|
|
|
================
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2017-02-02 23:52:34 +00:00
|
|
|
The compiler automatically creates getter functions for
|
2016-09-05 14:29:08 +00:00
|
|
|
all **public** state variables. For the contract given below, the compiler will
|
2016-08-18 11:16:01 +00:00
|
|
|
generate a function called ``data`` that does not take any
|
|
|
|
arguments and returns a ``uint``, the value of the state
|
2016-05-24 17:57:36 +00:00
|
|
|
variable ``data``. The initialization of state variables can
|
2015-12-07 20:16:25 +00:00
|
|
|
be done at declaration.
|
|
|
|
|
2016-08-25 08:43:17 +00:00
|
|
|
::
|
|
|
|
|
2016-09-05 11:54:54 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2016-08-25 08:43:17 +00:00
|
|
|
contract C {
|
|
|
|
uint public data = 42;
|
|
|
|
}
|
2016-08-25 19:44:16 +00:00
|
|
|
|
2016-08-25 17:57:56 +00:00
|
|
|
|
2016-08-25 08:43:17 +00:00
|
|
|
contract Caller {
|
2016-08-25 19:44:16 +00:00
|
|
|
C c = new C();
|
|
|
|
function f() {
|
|
|
|
uint local = c.data();
|
|
|
|
}
|
2016-08-25 08:43:17 +00:00
|
|
|
}
|
|
|
|
|
2017-02-02 23:52:34 +00:00
|
|
|
The getter functions have external visibility. If the
|
2016-05-24 17:57:36 +00:00
|
|
|
symbol is accessed internally (i.e. without ``this.``),
|
2017-05-03 17:24:00 +00:00
|
|
|
it is evaluated as a state variable. If it is accessed externally
|
2016-08-25 17:57:56 +00:00
|
|
|
(i.e. with ``this.``), it is evaluated as a function.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
::
|
|
|
|
|
2016-09-05 11:54:54 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2016-08-25 08:43:17 +00:00
|
|
|
contract C {
|
2016-08-25 19:44:16 +00:00
|
|
|
uint public data;
|
|
|
|
function x() {
|
|
|
|
data = 3; // internal access
|
|
|
|
uint val = this.data(); // external access
|
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
The next example is a bit more complex:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2016-09-05 11:54:54 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2016-05-18 15:11:39 +00:00
|
|
|
contract Complex {
|
2016-05-11 19:30:31 +00:00
|
|
|
struct Data {
|
|
|
|
uint a;
|
|
|
|
bytes3 b;
|
|
|
|
mapping (uint => uint) map;
|
|
|
|
}
|
|
|
|
mapping (uint => mapping(bool => Data[])) public data;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
It will generate a function of the following form::
|
|
|
|
|
2016-05-05 18:58:02 +00:00
|
|
|
function data(uint arg1, bool arg2, uint arg3) returns (uint a, bytes3 b) {
|
2015-12-30 09:53:41 +00:00
|
|
|
a = data[arg1][arg2][arg3].a;
|
|
|
|
b = data[arg1][arg2][arg3].b;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Note that the mapping in the struct is omitted because there
|
|
|
|
is no good way to provide the key for the mapping.
|
|
|
|
|
|
|
|
.. index:: ! function;modifier
|
|
|
|
|
2015-12-21 15:54:32 +00:00
|
|
|
.. _modifiers:
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
******************
|
|
|
|
Function Modifiers
|
|
|
|
******************
|
|
|
|
|
2017-05-03 17:24:00 +00:00
|
|
|
Modifiers can be used to easily change the behaviour of functions. For example,
|
|
|
|
they can automatically check a condition prior to executing the function. Modifiers are
|
2015-12-07 20:16:25 +00:00
|
|
|
inheritable properties of contracts and may be overridden by derived contracts.
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2017-04-19 18:12:45 +00:00
|
|
|
pragma solidity ^0.4.11;
|
2016-09-05 11:54:54 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract owned {
|
2015-12-30 09:53:41 +00:00
|
|
|
function owned() { owner = msg.sender; }
|
|
|
|
address owner;
|
|
|
|
|
|
|
|
// This contract only defines a modifier but does not use
|
|
|
|
// it - it will be used in derived contracts.
|
|
|
|
// The function body is inserted where the special symbol
|
2016-09-05 14:29:08 +00:00
|
|
|
// "_;" in the definition of a modifier appears.
|
2015-12-30 09:53:41 +00:00
|
|
|
// This means that if the owner calls this function, the
|
|
|
|
// function is executed and otherwise, an exception is
|
|
|
|
// thrown.
|
2016-05-18 15:11:39 +00:00
|
|
|
modifier onlyOwner {
|
2017-04-19 18:12:45 +00:00
|
|
|
require(msg.sender == owner);
|
2016-09-05 12:54:50 +00:00
|
|
|
_;
|
2016-05-11 19:30:31 +00:00
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract mortal is owned {
|
2016-05-18 15:11:39 +00:00
|
|
|
// This contract inherits the "onlyOwner"-modifier from
|
2015-12-30 09:53:41 +00:00
|
|
|
// "owned" and applies it to the "close"-function, which
|
|
|
|
// causes that calls to "close" only have an effect if
|
|
|
|
// they are made by the stored owner.
|
2016-05-18 15:11:39 +00:00
|
|
|
function close() onlyOwner {
|
2015-12-30 09:53:41 +00:00
|
|
|
selfdestruct(owner);
|
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract priced {
|
2015-12-30 09:53:41 +00:00
|
|
|
// Modifiers can receive arguments:
|
2016-05-11 19:30:31 +00:00
|
|
|
modifier costs(uint price) {
|
|
|
|
if (msg.value >= price) {
|
2016-09-05 12:54:50 +00:00
|
|
|
_;
|
2016-05-11 19:30:31 +00:00
|
|
|
}
|
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract Register is priced, owned {
|
2015-12-30 09:53:41 +00:00
|
|
|
mapping (address => bool) registeredAddresses;
|
|
|
|
uint price;
|
2016-05-11 19:30:31 +00:00
|
|
|
|
2015-12-30 09:53:41 +00:00
|
|
|
function Register(uint initialPrice) { price = initialPrice; }
|
2016-05-11 19:30:31 +00:00
|
|
|
|
2016-09-05 14:29:08 +00:00
|
|
|
// It is important to also provide the
|
|
|
|
// "payable" keyword here, otherwise the function will
|
|
|
|
// automatically reject all Ether sent to it.
|
|
|
|
function register() payable costs(price) {
|
2015-12-30 09:53:41 +00:00
|
|
|
registeredAddresses[msg.sender] = true;
|
|
|
|
}
|
2016-05-11 19:30:31 +00:00
|
|
|
|
2016-05-18 15:11:39 +00:00
|
|
|
function changePrice(uint _price) onlyOwner {
|
2015-12-30 09:53:41 +00:00
|
|
|
price = _price;
|
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
2016-08-06 12:48:59 +00:00
|
|
|
contract Mutex {
|
|
|
|
bool locked;
|
|
|
|
modifier noReentrancy() {
|
2017-04-19 18:12:45 +00:00
|
|
|
require(!locked);
|
2016-08-06 12:48:59 +00:00
|
|
|
locked = true;
|
2016-09-05 12:54:50 +00:00
|
|
|
_;
|
2016-08-06 12:48:59 +00:00
|
|
|
locked = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// This function is protected by a mutex, which means that
|
|
|
|
/// reentrant calls from within msg.sender.call cannot call f again.
|
|
|
|
/// The `return 7` statement assigns 7 to the return value but still
|
|
|
|
/// executes the statement `locked = false` in the modifier.
|
|
|
|
function f() noReentrancy returns (uint) {
|
2017-04-19 18:12:45 +00:00
|
|
|
require(msg.sender.call());
|
2016-08-06 12:48:59 +00:00
|
|
|
return 7;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-03 17:24:00 +00:00
|
|
|
Multiple modifiers are applied to a function by specifying them in a
|
|
|
|
whitespace-separated list and are evaluated in the order presented.
|
2016-08-06 12:48:59 +00:00
|
|
|
|
|
|
|
.. warning::
|
|
|
|
In an earlier version of Solidity, ``return`` statements in functions
|
|
|
|
having modifiers behaved differently.
|
|
|
|
|
|
|
|
Explicit returns from a modifier or function body only leave the current
|
|
|
|
modifier or function body. Return variables are assigned and
|
|
|
|
control flow continues after the "_" in the preceding modifier.
|
|
|
|
|
|
|
|
Arbitrary expressions are allowed for modifier arguments and in this context,
|
|
|
|
all symbols visible from the function are visible in the modifier. Symbols
|
|
|
|
introduced in the modifier are not visible in the function (as they might
|
|
|
|
change by overriding).
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
.. index:: ! constant
|
|
|
|
|
2016-10-15 21:34:35 +00:00
|
|
|
************************
|
|
|
|
Constant State Variables
|
|
|
|
************************
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2017-03-13 12:29:34 +00:00
|
|
|
State variables can be declared as ``constant``. In this case, they have to be
|
|
|
|
assigned from an expression which is a constant at compile time. Any expression
|
|
|
|
that accesses storage, blockchain data (e.g. ``now``, ``this.balance`` or
|
|
|
|
``block.number``) or
|
|
|
|
execution data (``msg.gas``) or make calls to external contracts are disallowed. Expressions
|
2017-03-09 13:39:30 +00:00
|
|
|
that might have a side-effect on memory allocation are allowed, but those that
|
2017-03-13 12:29:34 +00:00
|
|
|
might have a side-effect on other memory objects are not. The built-in functions
|
|
|
|
``keccak256``, ``sha256``, ``ripemd160``, ``ecrecover``, ``addmod`` and ``mulmod``
|
2017-03-27 04:19:08 +00:00
|
|
|
are allowed (even though they do call external contracts).
|
2017-03-13 12:29:34 +00:00
|
|
|
|
|
|
|
The reason behind allowing side-effects on the memory allocator is that it
|
|
|
|
should be possible to construct complex objects like e.g. lookup-tables.
|
|
|
|
This feature is not yet fully usable.
|
2017-03-09 13:39:30 +00:00
|
|
|
|
2017-05-03 17:24:00 +00:00
|
|
|
The compiler does not reserve a storage slot for these variables, and every occurrence is
|
2017-03-13 12:29:34 +00:00
|
|
|
replaced by the respective constant expression (which might be computed to a single value by the optimizer).
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2017-03-03 18:26:54 +00:00
|
|
|
Not all types for constants are implemented at this time. The only supported types are
|
|
|
|
value types and strings.
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
::
|
|
|
|
|
2016-09-05 11:54:54 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract C {
|
2015-12-30 09:53:41 +00:00
|
|
|
uint constant x = 32**22 + 8;
|
|
|
|
string constant text = "abc";
|
2017-03-02 13:41:51 +00:00
|
|
|
bytes32 constant myHash = keccak256("abc");
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-06-12 16:33:23 +00:00
|
|
|
.. _constant-functions:
|
|
|
|
|
2016-10-15 21:34:35 +00:00
|
|
|
******************
|
|
|
|
Constant Functions
|
|
|
|
******************
|
|
|
|
|
2017-05-03 17:24:00 +00:00
|
|
|
Functions can be declared constant in which case they promise not to modify the state.
|
2016-10-15 21:34:35 +00:00
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
|
|
|
contract C {
|
|
|
|
function f(uint a, uint b) constant returns (uint) {
|
|
|
|
return a * (b + 42);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
.. note::
|
2017-02-02 23:52:34 +00:00
|
|
|
Getter methods are marked constant.
|
2016-10-15 21:34:35 +00:00
|
|
|
|
|
|
|
.. warning::
|
|
|
|
The compiler does not enforce yet that a constant method is not modifying state.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
.. index:: ! fallback function, function;fallback
|
|
|
|
|
|
|
|
.. _fallback-function:
|
|
|
|
|
|
|
|
*****************
|
|
|
|
Fallback Function
|
|
|
|
*****************
|
|
|
|
|
|
|
|
A contract can have exactly one unnamed function. This function cannot have
|
2016-08-25 11:25:30 +00:00
|
|
|
arguments and cannot return anything.
|
|
|
|
It is executed on a call to the contract if none of the other
|
2017-05-03 17:24:00 +00:00
|
|
|
functions match the given function identifier (or if no data was supplied at
|
2015-12-07 20:16:25 +00:00
|
|
|
all).
|
|
|
|
|
|
|
|
Furthermore, this function is executed whenever the contract receives plain
|
2016-09-05 14:29:08 +00:00
|
|
|
Ether (without data). In such a context, there is usually very little gas available to
|
2016-06-28 15:29:08 +00:00
|
|
|
the function call (to be precise, 2300 gas), so it is important to make fallback functions as cheap as
|
2015-12-07 20:16:25 +00:00
|
|
|
possible.
|
|
|
|
|
2016-08-25 19:43:04 +00:00
|
|
|
In particular, the following operations will consume more gas than the stipend provided to a fallback function:
|
|
|
|
|
|
|
|
- Writing to storage
|
|
|
|
- Creating a contract
|
|
|
|
- Calling an external function which consumes a large amount of gas
|
2016-08-26 14:31:57 +00:00
|
|
|
- Sending Ether
|
2016-08-25 19:43:04 +00:00
|
|
|
|
|
|
|
Please ensure you test your fallback function thoroughly to ensure the execution cost is less than 2300 gas before deploying a contract.
|
|
|
|
|
2016-08-26 15:00:26 +00:00
|
|
|
.. warning::
|
2017-06-13 17:08:13 +00:00
|
|
|
Contracts that receive Ether directly (without a function call, i.e. using ``send`` or ``transfer``)
|
|
|
|
but do not define a fallback function
|
2016-08-30 13:37:10 +00:00
|
|
|
throw an exception, sending back the Ether (this was different
|
|
|
|
before Solidity v0.4.0). So if you want your contract to receive Ether,
|
2016-08-26 15:00:26 +00:00
|
|
|
you have to implement a fallback function.
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
::
|
|
|
|
|
2016-09-05 11:54:54 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract Test {
|
2016-09-05 14:29:08 +00:00
|
|
|
// This function is called for all messages sent to
|
|
|
|
// this contract (there is no other function).
|
|
|
|
// Sending Ether to this contract will cause an exception,
|
|
|
|
// because the fallback function does not have the "payable"
|
|
|
|
// modifier.
|
2015-12-30 09:53:41 +00:00
|
|
|
function() { x = 1; }
|
|
|
|
uint x;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2016-09-05 14:29:08 +00:00
|
|
|
// This contract keeps all Ether sent to it with no way
|
|
|
|
// to get it back.
|
|
|
|
contract Sink {
|
|
|
|
function() payable { }
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract Caller {
|
2016-09-05 14:29:08 +00:00
|
|
|
function callTest(Test test) {
|
|
|
|
test.call(0xabcdef01); // hash does not exist
|
|
|
|
// results in test.x becoming == 1.
|
|
|
|
|
2017-07-10 22:07:27 +00:00
|
|
|
// The following will not compile, but even
|
|
|
|
// if someone sends ether to that contract,
|
|
|
|
// the transaction will fail and reject the
|
|
|
|
// Ether.
|
|
|
|
//test.send(2 ether);
|
2016-05-18 15:05:28 +00:00
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
.. index:: ! event
|
|
|
|
|
2016-02-19 11:05:56 +00:00
|
|
|
.. _events:
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
******
|
|
|
|
Events
|
|
|
|
******
|
|
|
|
|
|
|
|
Events allow the convenient usage of the EVM logging facilities,
|
|
|
|
which in turn can be used to "call" JavaScript callbacks in the user interface
|
|
|
|
of a dapp, which listen for these events.
|
|
|
|
|
|
|
|
Events are
|
|
|
|
inheritable members of contracts. When they are called, they cause the
|
|
|
|
arguments to be stored in the transaction's log - a special data structure
|
|
|
|
in the blockchain. These logs are associated with the address of
|
|
|
|
the contract and will be incorporated into the blockchain
|
|
|
|
and stay there as long as a block is accessible (forever as of
|
|
|
|
Frontier and Homestead, but this might change with Serenity). Log and
|
|
|
|
event data is not accessible from within contracts (not even from
|
2017-05-03 17:24:00 +00:00
|
|
|
the contract that created them).
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
SPV proofs for logs are possible, so if an external entity supplies
|
|
|
|
a contract with such a proof, it can check that the log actually
|
2017-05-03 17:24:00 +00:00
|
|
|
exists inside the blockchain. But be aware that block headers have to be supplied because
|
|
|
|
the contract can only see the last 256 block hashes.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
Up to three parameters can
|
2016-05-24 17:57:36 +00:00
|
|
|
receive the attribute ``indexed`` which will cause the respective arguments
|
2015-12-07 20:16:25 +00:00
|
|
|
to be searched for: It is possible to filter for specific values of
|
|
|
|
indexed arguments in the user interface.
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
If arrays (including ``string`` and ``bytes``) are used as indexed arguments, the
|
2016-10-06 12:24:36 +00:00
|
|
|
Keccak-256 hash of it is stored as topic instead.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
The hash of the signature of the event is one of the topics except if you
|
2016-05-24 17:57:36 +00:00
|
|
|
declared the event with ``anonymous`` specifier. This means that it is
|
2015-12-07 20:16:25 +00:00
|
|
|
not possible to filter for specific anonymous events by name.
|
|
|
|
|
|
|
|
All non-indexed arguments will be stored in the data part of the log.
|
|
|
|
|
2016-09-05 14:29:08 +00:00
|
|
|
.. note::
|
2017-05-03 17:24:00 +00:00
|
|
|
Indexed arguments will not be stored themselves. You can only
|
2016-09-05 14:29:08 +00:00
|
|
|
search for the values, but it is impossible to retrieve the
|
|
|
|
values themselves.
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
::
|
|
|
|
|
2016-09-05 11:54:54 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract ClientReceipt {
|
2015-12-30 09:53:41 +00:00
|
|
|
event Deposit(
|
|
|
|
address indexed _from,
|
|
|
|
bytes32 indexed _id,
|
|
|
|
uint _value
|
|
|
|
);
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2017-05-17 09:30:45 +00:00
|
|
|
function deposit(bytes32 _id) payable {
|
2015-12-30 09:53:41 +00:00
|
|
|
// Any call to this function (even deeply nested) can
|
|
|
|
// be detected from the JavaScript API by filtering
|
|
|
|
// for `Deposit` to be called.
|
|
|
|
Deposit(msg.sender, _id, msg.value);
|
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
The use in the JavaScript API would be as follows:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
var abi = /* abi as generated by the compiler */;
|
|
|
|
var ClientReceipt = web3.eth.contract(abi);
|
|
|
|
var clientReceipt = ClientReceipt.at(0x123 /* address */);
|
|
|
|
|
|
|
|
var event = clientReceipt.Deposit();
|
|
|
|
|
|
|
|
// watch for changes
|
|
|
|
event.watch(function(error, result){
|
2015-12-30 09:53:41 +00:00
|
|
|
// result will contain various information
|
|
|
|
// including the argumets given to the Deposit
|
|
|
|
// call.
|
|
|
|
if (!error)
|
|
|
|
console.log(result);
|
2015-12-07 20:16:25 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
// Or pass a callback to start watching immediately
|
|
|
|
var event = clientReceipt.Deposit(function(error, result) {
|
2015-12-30 09:53:41 +00:00
|
|
|
if (!error)
|
|
|
|
console.log(result);
|
2015-12-07 20:16:25 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
.. index:: ! log
|
|
|
|
|
|
|
|
Low-Level Interface to Logs
|
|
|
|
===========================
|
|
|
|
|
|
|
|
It is also possible to access the low-level interface to the logging
|
2016-05-24 17:57:36 +00:00
|
|
|
mechanism via the functions ``log0``, ``log1``, ``log2``, ``log3`` and ``log4``.
|
|
|
|
``logi`` takes ``i + 1`` parameter of type ``bytes32``, where the first
|
2015-12-07 20:16:25 +00:00
|
|
|
argument will be used for the data part of the log and the others
|
|
|
|
as topics. The event call above can be performed in the same way as
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
log3(
|
2015-12-30 09:53:41 +00:00
|
|
|
msg.value,
|
|
|
|
0x50cb9fe53daa9737b786ab3646f04d0150dc50ef4e75f59509d83667ad5adb20,
|
|
|
|
msg.sender,
|
|
|
|
_id
|
2015-12-07 20:16:25 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
where the long hexadecimal number is equal to
|
2016-10-06 12:24:36 +00:00
|
|
|
``keccak256("Deposit(address,hash256,uint256)")``, the signature of the event.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
Additional Resources for Understanding Events
|
|
|
|
==============================================
|
|
|
|
|
|
|
|
- `Javascript documentation <https://github.com/ethereum/wiki/wiki/JavaScript-API#contract-events>`_
|
|
|
|
- `Example usage of events <https://github.com/debris/smart-exchange/blob/master/lib/contracts/SmartExchange.sol>`_
|
|
|
|
- `How to access them in js <https://github.com/debris/smart-exchange/blob/master/lib/exchange_transactions.js>`_
|
|
|
|
|
|
|
|
.. index:: ! inheritance, ! base class, ! contract;base, ! deriving
|
|
|
|
|
|
|
|
***********
|
|
|
|
Inheritance
|
|
|
|
***********
|
|
|
|
|
|
|
|
Solidity supports multiple inheritance by copying code including polymorphism.
|
|
|
|
|
|
|
|
All function calls are virtual, which means that the most derived function
|
2016-09-05 14:29:08 +00:00
|
|
|
is called, except when the contract name is explicitly given.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2017-05-03 17:24:00 +00:00
|
|
|
When a contract inherits from multiple contracts, only a single
|
|
|
|
contract is created on the blockchain, and the code from all the base contracts
|
|
|
|
is copied into the created contract.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
The general inheritance system is very similar to
|
|
|
|
`Python's <https://docs.python.org/3/tutorial/classes.html#inheritance>`_,
|
|
|
|
especially concerning multiple inheritance.
|
|
|
|
|
|
|
|
Details are given in the following example.
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2016-09-05 14:29:08 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract owned {
|
|
|
|
function owned() { owner = msg.sender; }
|
|
|
|
address owner;
|
|
|
|
}
|
|
|
|
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
// Use "is" to derive from another contract. Derived
|
|
|
|
// contracts can access all non-private members including
|
|
|
|
// internal functions and state variables. These cannot be
|
|
|
|
// accessed externally via `this`, though.
|
|
|
|
contract mortal is owned {
|
|
|
|
function kill() {
|
2015-12-30 09:53:41 +00:00
|
|
|
if (msg.sender == owner) selfdestruct(owner);
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
// These abstract contracts are only provided to make the
|
|
|
|
// interface known to the compiler. Note the function
|
|
|
|
// without body. If a contract does not implement all
|
|
|
|
// functions it can only be used as an interface.
|
|
|
|
contract Config {
|
|
|
|
function lookup(uint id) returns (address adr);
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract NameReg {
|
|
|
|
function register(bytes32 name);
|
|
|
|
function unregister();
|
|
|
|
}
|
|
|
|
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
// Multiple inheritance is possible. Note that "owned" is
|
|
|
|
// also a base class of "mortal", yet there is only a single
|
|
|
|
// instance of "owned" (as for virtual inheritance in C++).
|
|
|
|
contract named is owned, mortal {
|
|
|
|
function named(bytes32 name) {
|
|
|
|
Config config = Config(0xd5f9d8d94886e70b06e474c3fb14fd43e2f23970);
|
|
|
|
NameReg(config.lookup(1)).register(name);
|
|
|
|
}
|
|
|
|
|
2016-11-23 15:40:57 +00:00
|
|
|
// Functions can be overridden by another function with the same name and
|
|
|
|
// the same number/types of inputs. If the overriding function has different
|
|
|
|
// types of output parameters, that causes an error.
|
|
|
|
// Both local and message-based function calls take these overrides
|
2015-12-07 20:16:25 +00:00
|
|
|
// into account.
|
|
|
|
function kill() {
|
|
|
|
if (msg.sender == owner) {
|
|
|
|
Config config = Config(0xd5f9d8d94886e70b06e474c3fb14fd43e2f23970);
|
|
|
|
NameReg(config.lookup(1)).unregister();
|
|
|
|
// It is still possible to call a specific
|
|
|
|
// overridden function.
|
|
|
|
mortal.kill();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
// If a constructor takes an argument, it needs to be
|
|
|
|
// provided in the header (or modifier-invocation-style at
|
|
|
|
// the constructor of the derived contract (see below)).
|
|
|
|
contract PriceFeed is owned, mortal, named("GoldFeed") {
|
|
|
|
function updateInfo(uint newInfo) {
|
|
|
|
if (msg.sender == owner) info = newInfo;
|
|
|
|
}
|
|
|
|
|
|
|
|
function get() constant returns(uint r) { return info; }
|
|
|
|
|
|
|
|
uint info;
|
|
|
|
}
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
Note that above, we call ``mortal.kill()`` to "forward" the
|
2015-12-07 20:16:25 +00:00
|
|
|
destruction request. The way this is done is problematic, as
|
|
|
|
seen in the following example::
|
|
|
|
|
2016-09-05 14:29:08 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2017-07-10 22:07:27 +00:00
|
|
|
contract owned {
|
|
|
|
function owned() { owner = msg.sender; }
|
|
|
|
address owner;
|
|
|
|
}
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract mortal is owned {
|
|
|
|
function kill() {
|
|
|
|
if (msg.sender == owner) selfdestruct(owner);
|
|
|
|
}
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract Base1 is mortal {
|
|
|
|
function kill() { /* do cleanup 1 */ mortal.kill(); }
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract Base2 is mortal {
|
|
|
|
function kill() { /* do cleanup 2 */ mortal.kill(); }
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract Final is Base1, Base2 {
|
|
|
|
}
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
A call to ``Final.kill()`` will call ``Base2.kill`` as the most
|
2015-12-07 20:16:25 +00:00
|
|
|
derived override, but this function will bypass
|
2016-05-24 17:57:36 +00:00
|
|
|
``Base1.kill``, basically because it does not even know about
|
|
|
|
``Base1``. The way around this is to use ``super``::
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2016-09-05 14:29:08 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2017-07-10 22:07:27 +00:00
|
|
|
contract owned {
|
|
|
|
function owned() { owner = msg.sender; }
|
|
|
|
address owner;
|
|
|
|
}
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract mortal is owned {
|
|
|
|
function kill() {
|
|
|
|
if (msg.sender == owner) selfdestruct(owner);
|
|
|
|
}
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract Base1 is mortal {
|
|
|
|
function kill() { /* do cleanup 1 */ super.kill(); }
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract Base2 is mortal {
|
|
|
|
function kill() { /* do cleanup 2 */ super.kill(); }
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract Final is Base2, Base1 {
|
|
|
|
}
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
If ``Base1`` calls a function of ``super``, it does not simply
|
2017-05-03 17:24:00 +00:00
|
|
|
call this function on one of its base contracts. Rather, it
|
2015-12-07 20:16:25 +00:00
|
|
|
calls this function on the next base contract in the final
|
2016-05-24 17:57:36 +00:00
|
|
|
inheritance graph, so it will call ``Base2.kill()`` (note that
|
2015-12-07 20:16:25 +00:00
|
|
|
the final inheritance sequence is -- starting with the most
|
|
|
|
derived contract: Final, Base1, Base2, mortal, owned).
|
|
|
|
The actual function that is called when using super is
|
|
|
|
not known in the context of the class where it is used,
|
|
|
|
although its type is known. This is similar for ordinary
|
|
|
|
virtual method lookup.
|
|
|
|
|
|
|
|
.. index:: ! base;constructor
|
|
|
|
|
|
|
|
Arguments for Base Constructors
|
|
|
|
===============================
|
|
|
|
|
|
|
|
Derived contracts need to provide all arguments needed for
|
2017-05-03 17:24:00 +00:00
|
|
|
the base constructors. This can be done in two ways::
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2017-05-03 19:07:14 +00:00
|
|
|
pragma solidity ^0.4.0;
|
2016-09-05 14:29:08 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract Base {
|
2015-12-30 09:53:41 +00:00
|
|
|
uint x;
|
|
|
|
function Base(uint _x) { x = _x; }
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract Derived is Base(7) {
|
2015-12-30 09:53:41 +00:00
|
|
|
function Derived(uint _y) Base(_y * _y) {
|
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
2017-05-03 17:24:00 +00:00
|
|
|
One way is directly in the inheritance list (``is Base(7)``). The other is in
|
2015-12-07 20:16:25 +00:00
|
|
|
the way a modifier would be invoked as part of the header of
|
2016-05-24 17:57:36 +00:00
|
|
|
the derived constructor (``Base(_y * _y)``). The first way to
|
2015-12-07 20:16:25 +00:00
|
|
|
do it is more convenient if the constructor argument is a
|
|
|
|
constant and defines the behaviour of the contract or
|
|
|
|
describes it. The second way has to be used if the
|
|
|
|
constructor arguments of the base depend on those of the
|
|
|
|
derived contract. If, as in this silly example, both places
|
|
|
|
are used, the modifier-style argument takes precedence.
|
|
|
|
|
|
|
|
.. index:: ! inheritance;multiple, ! linearization, ! C3 linearization
|
|
|
|
|
|
|
|
Multiple Inheritance and Linearization
|
|
|
|
======================================
|
|
|
|
|
|
|
|
Languages that allow multiple inheritance have to deal with
|
2017-05-03 17:24:00 +00:00
|
|
|
several problems. One is the `Diamond Problem <https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem>`_.
|
2015-12-07 20:16:25 +00:00
|
|
|
Solidity follows the path of Python and uses "`C3 Linearization <https://en.wikipedia.org/wiki/C3_linearization>`_"
|
|
|
|
to force a specific order in the DAG of base classes. This
|
|
|
|
results in the desirable property of monotonicity but
|
|
|
|
disallows some inheritance graphs. Especially, the order in
|
2016-05-24 17:57:36 +00:00
|
|
|
which the base classes are given in the ``is`` directive is
|
2015-12-07 20:16:25 +00:00
|
|
|
important. In the following code, Solidity will give the
|
|
|
|
error "Linearization of inheritance graph impossible".
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2017-07-10 22:07:27 +00:00
|
|
|
// This will not compile
|
|
|
|
|
2016-09-05 11:54:54 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract X {}
|
|
|
|
contract A is X {}
|
|
|
|
contract C is A, X {}
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
The reason for this is that ``C`` requests ``X`` to override ``A``
|
|
|
|
(by specifying ``A, X`` in this order), but ``A`` itself
|
|
|
|
requests to override ``X``, which is a contradiction that
|
2015-12-07 20:16:25 +00:00
|
|
|
cannot be resolved.
|
|
|
|
|
|
|
|
A simple rule to remember is to specify the base classes in
|
|
|
|
the order from "most base-like" to "most derived".
|
|
|
|
|
2017-01-03 18:40:50 +00:00
|
|
|
Inheriting Different Kinds of Members of the Same Name
|
|
|
|
======================================================
|
|
|
|
|
|
|
|
When the inheritance results in a contract with a function and a modifier of the same name, it is considered as an error.
|
|
|
|
This error is produced also by an event and a modifier of the same name, and a function and an event of the same name.
|
2017-02-02 23:52:34 +00:00
|
|
|
As an exception, a state variable getter can override a public function.
|
2017-01-03 18:40:50 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
.. index:: ! contract;abstract, ! abstract contract
|
|
|
|
|
|
|
|
******************
|
|
|
|
Abstract Contracts
|
|
|
|
******************
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
Contract functions can lack an implementation as in the following example (note that the function declaration header is terminated by ``;``)::
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2016-09-05 14:29:08 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2016-05-18 15:11:39 +00:00
|
|
|
contract Feline {
|
2015-12-30 09:53:41 +00:00
|
|
|
function utterance() returns (bytes32);
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
2017-07-10 22:07:27 +00:00
|
|
|
Such contracts cannot be compiled (even if they contain
|
|
|
|
implemented functions alongside non-implemented functions),
|
|
|
|
but they can be used as base contracts::
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2016-09-05 14:29:08 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2017-07-10 22:07:27 +00:00
|
|
|
contract Feline {
|
|
|
|
function utterance() returns (bytes32);
|
|
|
|
}
|
|
|
|
|
2016-05-18 15:11:39 +00:00
|
|
|
contract Cat is Feline {
|
2015-12-30 09:53:41 +00:00
|
|
|
function utterance() returns (bytes32) { return "miaow"; }
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
If a contract inherits from an abstract contract and does not implement all non-implemented functions by overriding, it will itself be abstract.
|
|
|
|
|
2017-02-12 15:21:32 +00:00
|
|
|
.. index:: ! contract;interface, ! interface contract
|
|
|
|
|
|
|
|
**********
|
|
|
|
Interfaces
|
|
|
|
**********
|
|
|
|
|
|
|
|
Interfaces are similar to abstract contracts, but they cannot have any functions implemented. There are further restrictions:
|
|
|
|
|
|
|
|
#. Cannot inherit other contracts or interfaces.
|
2017-03-17 16:37:02 +00:00
|
|
|
#. Cannot define constructor.
|
2017-02-12 15:21:32 +00:00
|
|
|
#. Cannot define variables.
|
|
|
|
#. Cannot define structs.
|
2017-03-15 22:12:31 +00:00
|
|
|
#. Cannot define enums.
|
2017-02-12 15:21:32 +00:00
|
|
|
|
|
|
|
Some of these restrictions might be lifted in the future.
|
|
|
|
|
2017-05-03 17:24:00 +00:00
|
|
|
Interfaces are basically limited to what the Contract ABI can represent, and the conversion between the ABI and
|
2017-02-12 15:21:32 +00:00
|
|
|
an Interface should be possible without any information loss.
|
|
|
|
|
|
|
|
Interfaces are denoted by their own keyword:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
interface Token {
|
|
|
|
function transfer(address recipient, uint amount);
|
|
|
|
}
|
|
|
|
|
|
|
|
Contracts can inherit interfaces as they would inherit other contracts.
|
|
|
|
|
2016-03-10 14:56:25 +00:00
|
|
|
.. index:: ! library, callcode, delegatecall
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
.. _libraries:
|
|
|
|
|
|
|
|
************
|
|
|
|
Libraries
|
|
|
|
************
|
|
|
|
|
|
|
|
Libraries are similar to contracts, but their purpose is that they are deployed
|
2016-05-24 17:57:36 +00:00
|
|
|
only once at a specific address and their code is reused using the ``DELEGATECALL``
|
|
|
|
(``CALLCODE`` until Homestead)
|
2015-12-07 20:16:25 +00:00
|
|
|
feature of the EVM. This means that if library functions are called, their code
|
2016-05-24 17:57:36 +00:00
|
|
|
is executed in the context of the calling contract, i.e. ``this`` points to the
|
2016-06-17 21:13:03 +00:00
|
|
|
calling contract, and especially the storage from the calling contract can be
|
2015-12-07 20:16:25 +00:00
|
|
|
accessed. As a library is an isolated piece of source code, it can only access
|
|
|
|
state variables of the calling contract if they are explicitly supplied (it
|
2016-06-20 00:41:46 +00:00
|
|
|
would have no way to name them, otherwise).
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2016-05-04 18:41:39 +00:00
|
|
|
Libraries can be seen as implicit base contracts of the contracts that use them.
|
|
|
|
They will not be explicitly visible in the inheritance hierarchy, but calls
|
|
|
|
to library functions look just like calls to functions of explicit base
|
2016-05-24 17:57:36 +00:00
|
|
|
contracts (``L.f()`` if ``L`` is the name of the library). Furthermore,
|
|
|
|
``internal`` functions of libraries are visible in all contracts, just as
|
2016-05-04 18:41:39 +00:00
|
|
|
if the library were a base contract. Of course, calls to internal functions
|
|
|
|
use the internal calling convention, which means that all internal types
|
|
|
|
can be passed and memory types will be passed by reference and not copied.
|
2017-05-03 17:24:00 +00:00
|
|
|
To realize this in the EVM, code of internal library functions
|
|
|
|
and all functions called from therein will be pulled into the calling
|
|
|
|
contract, and a regular ``JUMP`` call will be used instead of a ``DELEGATECALL``.
|
2016-05-04 18:41:39 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
.. index:: using for, set
|
|
|
|
|
|
|
|
The following example illustrates how to use libraries (but
|
|
|
|
be sure to check out :ref:`using for <using-for>` for a
|
|
|
|
more advanced example to implement a set).
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2017-04-19 18:12:45 +00:00
|
|
|
pragma solidity ^0.4.11;
|
2016-09-05 11:54:54 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
library Set {
|
|
|
|
// We define a new struct datatype that will be used to
|
|
|
|
// hold its data in the calling contract.
|
|
|
|
struct Data { mapping(uint => bool) flags; }
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
// Note that the first parameter is of type "storage
|
|
|
|
// reference" and thus only its storage address and not
|
|
|
|
// its contents is passed as part of the call. This is a
|
|
|
|
// special feature of library functions. It is idiomatic
|
|
|
|
// to call the first parameter 'self', if the function can
|
|
|
|
// be seen as a method of that object.
|
|
|
|
function insert(Data storage self, uint value)
|
|
|
|
returns (bool)
|
|
|
|
{
|
2015-12-30 09:53:41 +00:00
|
|
|
if (self.flags[value])
|
|
|
|
return false; // already there
|
|
|
|
self.flags[value] = true;
|
|
|
|
return true;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
function remove(Data storage self, uint value)
|
2015-12-30 09:53:41 +00:00
|
|
|
returns (bool)
|
2015-12-07 20:16:25 +00:00
|
|
|
{
|
2015-12-30 09:53:41 +00:00
|
|
|
if (!self.flags[value])
|
|
|
|
return false; // not there
|
|
|
|
self.flags[value] = false;
|
|
|
|
return true;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
function contains(Data storage self, uint value)
|
2015-12-30 09:53:41 +00:00
|
|
|
returns (bool)
|
2015-12-07 20:16:25 +00:00
|
|
|
{
|
2015-12-30 09:53:41 +00:00
|
|
|
return self.flags[value];
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract C {
|
2015-12-30 09:53:41 +00:00
|
|
|
Set.Data knownValues;
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-30 09:53:41 +00:00
|
|
|
function register(uint value) {
|
|
|
|
// The library functions can be called without a
|
|
|
|
// specific instance of the library, since the
|
|
|
|
// "instance" will be the current contract.
|
2017-05-02 12:12:25 +00:00
|
|
|
require(Set.insert(knownValues, value));
|
2015-12-30 09:53:41 +00:00
|
|
|
}
|
|
|
|
// In this contract, we can also directly access knownValues.flags, if we want.
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Of course, you do not have to follow this way to use
|
|
|
|
libraries - they can also be used without defining struct
|
2017-05-03 17:24:00 +00:00
|
|
|
data types. Functions also work without any storage
|
|
|
|
reference parameters, and they can have multiple storage reference
|
2015-12-07 20:16:25 +00:00
|
|
|
parameters and in any position.
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
The calls to ``Set.contains``, ``Set.insert`` and ``Set.remove``
|
|
|
|
are all compiled as calls (``DELEGATECALL``) to an external
|
2015-12-07 20:16:25 +00:00
|
|
|
contract/library. If you use libraries, take care that an
|
2016-03-10 14:56:25 +00:00
|
|
|
actual external function call is performed.
|
2016-05-24 17:57:36 +00:00
|
|
|
``msg.sender``, ``msg.value`` and ``this`` will retain their values
|
2016-10-15 21:56:52 +00:00
|
|
|
in this call, though (prior to Homestead, because of the use of `CALLCODE`, ``msg.sender`` and
|
2016-05-24 17:57:36 +00:00
|
|
|
``msg.value`` changed, though).
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2016-05-04 18:41:39 +00:00
|
|
|
The following example shows how to use memory types and
|
|
|
|
internal functions in libraries in order to implement
|
|
|
|
custom types without the overhead of external function calls:
|
|
|
|
|
|
|
|
::
|
|
|
|
|
2016-09-05 11:54:54 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2016-05-18 15:11:39 +00:00
|
|
|
library BigInt {
|
2016-05-11 19:31:02 +00:00
|
|
|
struct bigint {
|
|
|
|
uint[] limbs;
|
|
|
|
}
|
|
|
|
|
|
|
|
function fromUint(uint x) internal returns (bigint r) {
|
|
|
|
r.limbs = new uint[](1);
|
|
|
|
r.limbs[0] = x;
|
|
|
|
}
|
|
|
|
|
|
|
|
function add(bigint _a, bigint _b) internal returns (bigint r) {
|
|
|
|
r.limbs = new uint[](max(_a.limbs.length, _b.limbs.length));
|
|
|
|
uint carry = 0;
|
|
|
|
for (uint i = 0; i < r.limbs.length; ++i) {
|
|
|
|
uint a = limb(_a, i);
|
|
|
|
uint b = limb(_b, i);
|
|
|
|
r.limbs[i] = a + b + carry;
|
|
|
|
if (a + b < a || (a + b == uint(-1) && carry > 0))
|
|
|
|
carry = 1;
|
|
|
|
else
|
|
|
|
carry = 0;
|
|
|
|
}
|
|
|
|
if (carry > 0) {
|
|
|
|
// too bad, we have to add a limb
|
|
|
|
uint[] memory newLimbs = new uint[](r.limbs.length + 1);
|
|
|
|
for (i = 0; i < r.limbs.length; ++i)
|
|
|
|
newLimbs[i] = r.limbs[i];
|
|
|
|
newLimbs[i] = carry;
|
|
|
|
r.limbs = newLimbs;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
function limb(bigint _a, uint _limb) internal returns (uint) {
|
|
|
|
return _limb < _a.limbs.length ? _a.limbs[_limb] : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
function max(uint a, uint b) private returns (uint) {
|
|
|
|
return a > b ? a : b;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
contract C {
|
2016-05-18 15:11:39 +00:00
|
|
|
using BigInt for BigInt.bigint;
|
|
|
|
|
2016-05-11 19:31:02 +00:00
|
|
|
function f() {
|
2016-06-25 12:11:45 +00:00
|
|
|
var x = BigInt.fromUint(7);
|
|
|
|
var y = BigInt.fromUint(uint(-1));
|
2016-05-11 19:31:02 +00:00
|
|
|
var z = x.add(y);
|
|
|
|
}
|
|
|
|
}
|
2016-05-04 18:41:39 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
As the compiler cannot know where the library will be
|
|
|
|
deployed at, these addresses have to be filled into the
|
2016-05-18 15:18:39 +00:00
|
|
|
final bytecode by a linker
|
2016-08-24 03:53:30 +00:00
|
|
|
(see :ref:`commandline-compiler` for how to use the
|
2015-12-07 20:16:25 +00:00
|
|
|
commandline compiler for linking). If the addresses are not
|
|
|
|
given as arguments to the compiler, the compiled hex code
|
2016-05-24 17:57:36 +00:00
|
|
|
will contain placeholders of the form ``__Set______`` (where
|
|
|
|
``Set`` is the name of the library). The address can be filled
|
2015-12-07 20:16:25 +00:00
|
|
|
manually by replacing all those 40 symbols by the hex
|
|
|
|
encoding of the address of the library contract.
|
|
|
|
|
|
|
|
Restrictions for libraries in comparison to contracts:
|
|
|
|
|
2016-08-12 20:29:17 +00:00
|
|
|
- No state variables
|
|
|
|
- Cannot inherit nor be inherited
|
2017-03-16 11:20:39 +00:00
|
|
|
- Cannot receive Ether
|
2015-12-07 20:16:25 +00:00
|
|
|
|
2016-08-12 20:29:17 +00:00
|
|
|
(These might be lifted at a later point.)
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
.. index:: ! using for, library
|
|
|
|
|
|
|
|
.. _using-for:
|
|
|
|
|
|
|
|
*********
|
|
|
|
Using For
|
|
|
|
*********
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
The directive ``using A for B;`` can be used to attach library
|
|
|
|
functions (from the library ``A``) to any type (``B``).
|
2015-12-07 20:16:25 +00:00
|
|
|
These functions will receive the object they are called on
|
2016-05-24 17:57:36 +00:00
|
|
|
as their first parameter (like the ``self`` variable in
|
2015-12-07 20:16:25 +00:00
|
|
|
Python).
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
The effect of ``using A for *;`` is that the functions from
|
|
|
|
the library ``A`` are attached to any type.
|
2015-12-07 20:16:25 +00:00
|
|
|
|
|
|
|
In both situations, all functions, even those where the
|
|
|
|
type of the first parameter does not match the type of
|
|
|
|
the object, are attached. The type is checked at the
|
|
|
|
point the function is called and function overload
|
|
|
|
resolution is performed.
|
|
|
|
|
2016-05-24 17:57:36 +00:00
|
|
|
The ``using A for B;`` directive is active for the current
|
2015-12-07 20:16:25 +00:00
|
|
|
scope, which is limited to a contract for now but will
|
|
|
|
be lifted to the global scope later, so that by including
|
|
|
|
a module, its data types including library functions are
|
|
|
|
available without having to add further code.
|
|
|
|
|
|
|
|
Let us rewrite the set example from the
|
|
|
|
:ref:`libraries` in this way::
|
|
|
|
|
2017-04-19 18:12:45 +00:00
|
|
|
pragma solidity ^0.4.11;
|
2016-09-05 14:29:08 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
// This is the same code as before, just without comments
|
|
|
|
library Set {
|
|
|
|
struct Data { mapping(uint => bool) flags; }
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
function insert(Data storage self, uint value)
|
|
|
|
returns (bool)
|
|
|
|
{
|
2015-12-30 09:53:41 +00:00
|
|
|
if (self.flags[value])
|
|
|
|
return false; // already there
|
|
|
|
self.flags[value] = true;
|
|
|
|
return true;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
function remove(Data storage self, uint value)
|
2015-12-30 09:53:41 +00:00
|
|
|
returns (bool)
|
2015-12-07 20:16:25 +00:00
|
|
|
{
|
2015-12-30 09:53:41 +00:00
|
|
|
if (!self.flags[value])
|
|
|
|
return false; // not there
|
|
|
|
self.flags[value] = false;
|
|
|
|
return true;
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
function contains(Data storage self, uint value)
|
2015-12-30 09:53:41 +00:00
|
|
|
returns (bool)
|
2015-12-07 20:16:25 +00:00
|
|
|
{
|
2015-12-30 09:53:41 +00:00
|
|
|
return self.flags[value];
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract C {
|
2015-12-30 09:53:41 +00:00
|
|
|
using Set for Set.Data; // this is the crucial change
|
|
|
|
Set.Data knownValues;
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-30 09:53:41 +00:00
|
|
|
function register(uint value) {
|
|
|
|
// Here, all variables of type Set.Data have
|
|
|
|
// corresponding member functions.
|
|
|
|
// The following function call is identical to
|
|
|
|
// Set.insert(knownValues, value)
|
2017-04-19 18:12:45 +00:00
|
|
|
require(knownValues.insert(value));
|
2015-12-30 09:53:41 +00:00
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
It is also possible to extend elementary types in that way::
|
|
|
|
|
2016-09-05 14:29:08 +00:00
|
|
|
pragma solidity ^0.4.0;
|
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
library Search {
|
2016-06-25 12:11:45 +00:00
|
|
|
function indexOf(uint[] storage self, uint value) returns (uint) {
|
2015-12-30 09:53:41 +00:00
|
|
|
for (uint i = 0; i < self.length; i++)
|
|
|
|
if (self[i] == value) return i;
|
|
|
|
return uint(-1);
|
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-07 20:16:25 +00:00
|
|
|
contract C {
|
2015-12-30 09:53:41 +00:00
|
|
|
using Search for uint[];
|
|
|
|
uint[] data;
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-30 09:53:41 +00:00
|
|
|
function append(uint value) {
|
|
|
|
data.push(value);
|
|
|
|
}
|
2016-05-05 18:58:02 +00:00
|
|
|
|
2015-12-30 09:53:41 +00:00
|
|
|
function replace(uint _old, uint _new) {
|
|
|
|
// This performs the library function call
|
2016-06-25 12:11:45 +00:00
|
|
|
uint index = data.indexOf(_old);
|
|
|
|
if (index == uint(-1))
|
2015-12-30 09:53:41 +00:00
|
|
|
data.push(_new);
|
|
|
|
else
|
|
|
|
data[index] = _new;
|
|
|
|
}
|
2015-12-07 20:16:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Note that all library calls are actual EVM function calls. This means that
|
|
|
|
if you pass memory or value types, a copy will be performed, even of the
|
2016-05-24 17:57:36 +00:00
|
|
|
``self`` variable. The only situation where no copy will be performed
|
2015-12-07 20:16:25 +00:00
|
|
|
is when storage reference variables are used.
|