Update libraries section for 0.6.0.

This commit is contained in:
chriseth 2019-12-12 10:31:14 +01:00
parent b9c35916e5
commit bbb8b88118

View File

@ -36,12 +36,12 @@ 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 types :ref:`stored in memory <data-location>` will be passed by reference and not copied.
To realize this in the EVM, code of internal library functions
and all functions called from therein will at compile time be pulled into the calling
and all functions called from therein will at compile time be included in the calling
contract, and a regular ``JUMP`` call will be used instead of a ``DELEGATECALL``.
.. index:: using for, set
The following example illustrates how to use libraries (but manual method
The following example illustrates how to use libraries (but using a manual method,
be sure to check out :ref:`using for <using-for>` for a
more advanced example to implement a set).
@ -50,11 +50,11 @@ more advanced example to implement a set).
pragma solidity >=0.4.22 <0.7.0;
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; }
// We define a new struct datatype that will be used to
// hold its data in the calling contract.
struct Data { mapping(uint => bool) flags; }
library Set {
// 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
@ -92,7 +92,7 @@ more advanced example to implement a set).
contract C {
Set.Data knownValues;
Data knownValues;
function register(uint value) public {
// The library functions can be called without a
@ -125,11 +125,11 @@ custom types without the overhead of external function calls:
pragma solidity >=0.4.16 <0.7.0;
library BigInt {
struct bigint {
uint[] limbs;
}
struct bigint {
uint[] limbs;
}
library BigInt {
function fromUint(uint x) internal pure returns (bigint memory r) {
r.limbs = new uint[](1);
r.limbs[0] = x;
@ -168,12 +168,12 @@ custom types without the overhead of external function calls:
}
contract C {
using BigInt for BigInt.bigint;
using BigInt for bigint;
function f() public pure {
BigInt.bigint memory x = BigInt.fromUint(7);
BigInt.bigint memory y = BigInt.fromUint(uint(-1));
BigInt.bigint memory z = x.add(y);
bigint memory x = BigInt.fromUint(7);
bigint memory y = BigInt.fromUint(uint(-1));
bigint memory z = x.add(y);
assert(z.limb(1) > 0);
}
}
@ -194,17 +194,18 @@ encoding of the address of the library contract.
.. note::
Manually linking libraries on the generated bytecode is discouraged, because
it is restricted to 36 characters.
in this way, the library name is restricted to 36 characters.
You should ask the compiler to link the libraries at the time
a contract is compiled by either using
the ``--libraries`` option of ``solc`` or the ``libraries`` key if you use
the standard-JSON interface to the compiler.
Restrictions for libraries in comparison to contracts:
In comparison to contracts, libraries are restricted in the following ways:
- No state variables
- Cannot inherit nor be inherited
- Cannot receive Ether
- they cannot have state variables
- they cannot inherit nor be inherited
- they cannot receive Ether
- they cannot be destroyed
(These might be lifted at a later point.)
@ -275,3 +276,7 @@ this causes the deploy time address to be the first
constant to be pushed onto the stack and the dispatcher
code compares the current address against this constant
for any non-view and non-pure function.
This means that the actual code stored on chain for a library
is different from the code reported by the compiler as
``deployedBytecode``.