mirror of
https://github.com/ethereum/solidity
synced 2023-10-03 13:03:40 +00:00
Merge pull request #1220 from ethereum/doc-updates
Documentation updates
This commit is contained in:
commit
3bcf0909af
@ -20,6 +20,9 @@ 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.
|
||||
|
||||
A constructor is optional. Only one constructor is allowed and this means
|
||||
overloading is not supported.
|
||||
|
||||
From ``web3.js``, i.e. the JavaScript
|
||||
API, this is done as follows::
|
||||
|
||||
@ -421,9 +424,9 @@ change by overriding).
|
||||
|
||||
.. index:: ! constant
|
||||
|
||||
**********
|
||||
Constants
|
||||
**********
|
||||
************************
|
||||
Constant State Variables
|
||||
************************
|
||||
|
||||
State variables can be declared as constant (this is not yet implemented
|
||||
for array and struct types and not possible for mapping types).
|
||||
@ -442,6 +445,27 @@ for these variables and every occurrence is replaced by their constant value.
|
||||
|
||||
The value expression can only contain integer arithmetics.
|
||||
|
||||
******************
|
||||
Constant Functions
|
||||
******************
|
||||
|
||||
Functions can be declared constant. These functions promise not to modify the state.
|
||||
|
||||
::
|
||||
|
||||
pragma solidity ^0.4.0;
|
||||
|
||||
contract C {
|
||||
function f(uint a, uint b) constant returns (uint) {
|
||||
return a * (b + 42);
|
||||
}
|
||||
}
|
||||
|
||||
.. note::
|
||||
Accessor methods are marked constant.
|
||||
|
||||
.. warning::
|
||||
The compiler does not enforce yet that a constant method is not modifying state.
|
||||
|
||||
.. index:: ! fallback function, function;fallback
|
||||
|
||||
@ -976,7 +1000,7 @@ are all compiled as calls (``DELEGATECALL``) to an external
|
||||
contract/library. If you use libraries, take care that an
|
||||
actual external function call is performed.
|
||||
``msg.sender``, ``msg.value`` and ``this`` will retain their values
|
||||
in this call, though (prior to Homestead, ``msg.sender`` and
|
||||
in this call, though (prior to Homestead, because of the use of `CALLCODE`, ``msg.sender`` and
|
||||
``msg.value`` changed, though).
|
||||
|
||||
The following example shows how to use memory types and
|
||||
|
@ -7,7 +7,7 @@ Expressions and Control Structures
|
||||
Control Structures
|
||||
===================
|
||||
|
||||
Most of the control structures from C/JavaScript are available in Solidity
|
||||
Most of the control structures from C or JavaScript are available in Solidity
|
||||
except for ``switch`` and ``goto``. So
|
||||
there is: ``if``, ``else``, ``while``, ``for``, ``break``, ``continue``, ``return``, ``? :``, with
|
||||
the usual semantics known from C or JavaScript.
|
||||
@ -785,7 +785,7 @@ Conventions in Solidity
|
||||
|
||||
In contrast to EVM assembly, Solidity knows types which are narrower than 256 bits,
|
||||
e.g. ``uint24``. In order to make them more efficient, most arithmetic operations just
|
||||
treat them as 256 bit numbers and the higher-order bits are only cleaned at the
|
||||
treat them as 256-bit numbers and the higher-order bits are only cleaned at the
|
||||
point where it is necessary, i.e. just shortly before they are written to memory
|
||||
or before comparisons are performed. This means that if you access such a variable
|
||||
from within inline assembly, you might have to manually clean the higher order bits
|
||||
|
@ -9,33 +9,12 @@ This list was originally compiled by `fivedogit <mailto:fivedogit@gmail.com>`_.
|
||||
Basic Questions
|
||||
***************
|
||||
|
||||
What is Solidity?
|
||||
Example contracts
|
||||
=================
|
||||
|
||||
Solidity is the DEV-created (i.e. Ethereum Foundation-created),
|
||||
Javascript-inspired language that can be used to create smart contracts
|
||||
on the Ethereum blockchain. There are other
|
||||
languages you can use as well (LLL, Serpent, etc). The main points in
|
||||
favour of Solidity is that it is statically typed and offers many
|
||||
advanced features like inheritance, libraries, complex
|
||||
user-defined types and a bytecode optimizer.
|
||||
|
||||
Solidity contracts can be compiled a few different ways (see below) and the
|
||||
resulting output can be cut/pasted into a geth console to deploy them to the
|
||||
Ethereum blockchain.
|
||||
|
||||
There are some `contract examples <https://github.com/fivedogit/solidity-baby-steps/tree/master/contracts/>`_ by fivedogit and
|
||||
there should be a `test contract <https://github.com/ethereum/solidity/blob/develop/test/libsolidity/SolidityEndToEndTest.cpp>`_ for every single feature of Solidity.
|
||||
|
||||
How do I compile contracts?
|
||||
===========================
|
||||
|
||||
Probably the fastest way is the `online compiler <https://ethereum.github.io/browser-solidity/>`_.
|
||||
|
||||
You can also use the ``solc`` binary which comes with cpp-ethereum to compile
|
||||
contracts or an emerging option is to use Mix, the IDE.
|
||||
|
||||
|
||||
Create and publish the most basic contract possible
|
||||
===================================================
|
||||
|
||||
@ -71,13 +50,6 @@ several blockchain explorers.
|
||||
Contracts on the blockchain should have their original source
|
||||
code published if they are to be used by third parties.
|
||||
|
||||
Does ``selfdestruct()`` free up space in the blockchain?
|
||||
========================================================
|
||||
|
||||
It removes the contract bytecode and storage from the current block
|
||||
into the future, but since the blockchain stores every single block (i.e.
|
||||
all history), this will not actually free up space on full/archive nodes.
|
||||
|
||||
Create a contract that can be killed and return funds
|
||||
=====================================================
|
||||
|
||||
@ -113,32 +85,6 @@ Use a non-constant function (req ``sendTransaction``) to increment a variable in
|
||||
|
||||
See `value_incrementer.sol <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/20_value_incrementer.sol>`_.
|
||||
|
||||
Get contract address in Solidity
|
||||
================================
|
||||
|
||||
Short answer: The global variable ``this`` is the contract address.
|
||||
|
||||
See `basic_info_getter <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/15_basic_info_getter.sol>`_.
|
||||
|
||||
Long answer: ``this`` is a variable representing the current contract.
|
||||
Its type is the type of the contract. Since any contract type basically inherits from the
|
||||
``address`` type, ``this`` is always convertible to ``address`` and in this case contains
|
||||
its own address.
|
||||
|
||||
What is the difference between a function marked ``constant`` and one that is not?
|
||||
==================================================================================
|
||||
|
||||
``constant`` functions can perform some action and return a value, but cannot
|
||||
change state (this is not yet enforced by the compiler). In other words, a
|
||||
constant function cannot save or update any variables within the contract or wider
|
||||
blockchain. These functions are called using ``c.someFunction(...)`` from
|
||||
geth or any other web3.js environment.
|
||||
|
||||
"non-constant" functions (those lacking the ``constant`` specifier) must be called
|
||||
with ``c.someMethod.sendTransaction({from:eth.accounts[x], gas: 1000000});``
|
||||
That is, because they can change state, they have to have a gas
|
||||
payment sent along to get the work done.
|
||||
|
||||
Get a contract to return its funds to you (not using ``selfdestruct(...)``).
|
||||
============================================================================
|
||||
|
||||
@ -146,52 +92,6 @@ This example demonstrates how to send funds from a contract to an address.
|
||||
|
||||
See `endowment_retriever <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/30_endowment_retriever.sol>`_.
|
||||
|
||||
What is a ``mapping`` and how do we use them?
|
||||
=============================================
|
||||
|
||||
A mapping is very similar to a K->V hashmap.
|
||||
If you have a state variable of type ``mapping (string -> uint) x;``, then you can
|
||||
access the value by ``x["somekeystring"]``.
|
||||
|
||||
How can I get the length of a ``mapping``?
|
||||
==========================================
|
||||
|
||||
Mappings are a rather low-level data structure. It does not store the keys
|
||||
and it is not possible to know which or how many values are "set". Actually,
|
||||
all values to all possible keys are set by default, they are just
|
||||
initialised with the zero value.
|
||||
|
||||
In this sense, the attribute ``length`` for a mapping does not really apply.
|
||||
|
||||
If you want to have a "sized mapping", you can use the iterable mapping
|
||||
(see below) or just a dynamically-sized array of structs.
|
||||
|
||||
Are ``mapping``'s iterable?
|
||||
===========================
|
||||
|
||||
Mappings themselves are not iterable, but you can use a higher-level
|
||||
datastructure on top of it, for example the `iterable mapping <https://github.com/ethereum/dapp-bin/blob/master/library/iterable_mapping.sol>`_.
|
||||
|
||||
Can I put arrays inside of a ``mapping``? How do I make a ``mapping`` of a ``mapping``?
|
||||
=======================================================================================
|
||||
|
||||
Mappings are already syntactically similar to arrays as they are, therefore it doesn't make much sense to store an array in them. Rather what you should do is create a mapping of a mapping.
|
||||
|
||||
An example of this would be::
|
||||
|
||||
contract C {
|
||||
struct myStruct {
|
||||
uint someNumber;
|
||||
string someString;
|
||||
}
|
||||
|
||||
mapping(uint => mapping(string => myStruct)) myDynamicMapping;
|
||||
|
||||
function storeInMapping() {
|
||||
myDynamicMapping[1]["Foo"] = myStruct(2, "Bar");
|
||||
}
|
||||
}
|
||||
|
||||
Can you return an array or a ``string`` from a solidity function call?
|
||||
======================================================================
|
||||
|
||||
@ -223,61 +123,6 @@ Example::
|
||||
}
|
||||
}
|
||||
|
||||
What are ``event``'s and why do we need them?
|
||||
=============================================
|
||||
|
||||
Let us suppose that you need a contract to alert the outside world when
|
||||
something happens. The contract can fire an event, which can be listened to
|
||||
from web3 (inside geth or a web application). The main advantage of events
|
||||
is that they are stored in a special way on the blockchain so that it
|
||||
is very easy to search for them.
|
||||
|
||||
What are the different function visibilities?
|
||||
=============================================
|
||||
|
||||
The visibility specifiers do not only change the visibility but also
|
||||
the way functions can be called. In general, functions in the
|
||||
same contract can also be called internally (which is cheaper
|
||||
and allows for memory types to be passed by reference). This
|
||||
is done if you just use ``f(1,2)``. If you use ``this.f(1,2)``
|
||||
or ``otherContract.f(1,2)``, the function is called externally.
|
||||
|
||||
Internal function calls have the advantage that you can use
|
||||
all Solidity types as parameters, but you have to stick to the
|
||||
simpler ABI types for external calls.
|
||||
|
||||
* ``external``: all, only externally
|
||||
|
||||
* ``public``: all (this is the default), externally and internally
|
||||
|
||||
* ``internal``: only this contract and contracts deriving from it, only internally
|
||||
|
||||
* ``private``: only this contract, only internally
|
||||
|
||||
|
||||
Do contract constructors have to be publicly visible?
|
||||
=====================================================
|
||||
|
||||
You can use the visibility specifiers, but they do not yet have any effect.
|
||||
The constructor is removed from the contract code once it is deployed,
|
||||
|
||||
Can a contract have multiple constructors?
|
||||
==========================================
|
||||
|
||||
No, a contract can have only one constructor.
|
||||
|
||||
More specifically, it can only have one function whose name matches
|
||||
that of the constructor.
|
||||
|
||||
Having multiple constructors with different number of arguments
|
||||
or argument types, as it is possible in other languages
|
||||
is not allowed in Solidity.
|
||||
|
||||
Is a constructor required?
|
||||
==========================
|
||||
|
||||
No. If there is no constructor, a generic one without arguments and no actions will be used.
|
||||
|
||||
Are timestamps (``now,`` ``block.timestamp``) reliable?
|
||||
=======================================================
|
||||
|
||||
@ -363,14 +208,6 @@ Examples::
|
||||
C c = new C();
|
||||
}
|
||||
|
||||
What is the ``modifier`` keyword?
|
||||
=================================
|
||||
|
||||
Modifiers are a way to prepend or append code to a function in order
|
||||
to add guards, initialisation or cleanup functionality in a concise way.
|
||||
|
||||
For examples, see the `features.sol <https://github.com/ethereum/dapp-bin/blob/master/library/features.sol>`_.
|
||||
|
||||
How do structs work?
|
||||
====================
|
||||
|
||||
@ -590,12 +427,6 @@ The correct way to do this is the following::
|
||||
}
|
||||
}
|
||||
|
||||
Can a regular (i.e. non-contract) ethereum account be closed permanently like a contract can?
|
||||
=============================================================================================
|
||||
|
||||
No. Non-contract accounts "exist" as long as the private key is known by
|
||||
someone or can be generated in some way.
|
||||
|
||||
What is the difference between ``bytes`` and ``byte[]``?
|
||||
========================================================
|
||||
|
||||
@ -641,16 +472,6 @@ Use the constructor. Anything inside it will be executed when the contract is fi
|
||||
|
||||
See `replicator.sol <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/50_replicator.sol>`_.
|
||||
|
||||
Can a contract create another contract?
|
||||
=======================================
|
||||
|
||||
Yes, see `replicator.sol <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/50_replicator.sol>`_.
|
||||
|
||||
Note that the full code of the created contract has to be included in the creator contract.
|
||||
This also means that cyclic creations are not possible (because the contract would have
|
||||
to contain its own code) - at least not in a general way.
|
||||
|
||||
|
||||
How do you create 2-dimensional arrays?
|
||||
=======================================
|
||||
|
||||
|
@ -1,8 +1,12 @@
|
||||
Solidity
|
||||
========
|
||||
|
||||
Solidity is a high-level language whose syntax is similar to that of JavaScript
|
||||
and it is designed to compile to code for the Ethereum Virtual Machine.
|
||||
Solidity is a contract-oriented, high-level language whose syntax is similar to that of JavaScript
|
||||
and it is designed to target the Ethereum Virtual Machine.
|
||||
|
||||
Solidity is statically typed, supports inheritance, libraries and complex
|
||||
user-defines types among other features.
|
||||
|
||||
As you will see, it is possible to create contracts for voting,
|
||||
crowdfunding, blind auctions, multi-signature wallets and more.
|
||||
|
||||
@ -16,7 +20,7 @@ Useful links
|
||||
|
||||
* `Ethereum <https://ethereum.org>`_
|
||||
|
||||
* `Changelog <https://github.com/ethereum/wiki/wiki/Solidity-Changelog>`_
|
||||
* `Changelog <https://github.com/ethereum/solidity/blob/develop/Changelog.md>`_
|
||||
|
||||
* `Story Backlog <https://www.pivotaltracker.com/n/projects/1189488>`_
|
||||
|
||||
|
@ -9,7 +9,7 @@ Installing Solidity
|
||||
Versioning
|
||||
==========
|
||||
|
||||
Solidity versions follow `semantic versioning <https://semver.org>` and in addition to
|
||||
Solidity versions follow `semantic versioning <https://semver.org>`_ and in addition to
|
||||
releases, **nightly development builds** are also made available. The nightly builds
|
||||
are not guaranteed to be working and despite best efforts they might contain undocumented
|
||||
and/or broken changes. We recommend to use the latest release. Package installers below
|
||||
|
@ -455,13 +455,19 @@ receives the address of the new contract on the stack.
|
||||
|
||||
.. index:: selfdestruct
|
||||
|
||||
``selfdestruct``
|
||||
================
|
||||
Self-destruct
|
||||
=============
|
||||
|
||||
The only possibility that code is removed from the blockchain is
|
||||
when a contract at that address performs the ``selfdestruct`` operation.
|
||||
The remaining Ether stored at that address is sent to a designated
|
||||
target and then the storage and code is removed.
|
||||
target and then the storage and code is removed from the state.
|
||||
|
||||
Note that even if a contract's code does not contain a call to ``selfdestruct``,
|
||||
it can still perform that operation using ``delegatecall`` or ``callcode``.
|
||||
.. warning:: Even if a contract's code does not contain a call to ``selfdestruct``,
|
||||
it can still perform that operation using ``delegatecall`` or ``callcode``.
|
||||
|
||||
.. note:: The pruning of old contracts may or may not be implemented by Ethereum
|
||||
clients. Additionally, archive nodes could choose to keep the contract storage
|
||||
and code indefinitely.
|
||||
|
||||
.. note:: Currently **external accounts** cannot be removed from the state.
|
||||
|
@ -61,6 +61,7 @@ Layout in Memory
|
||||
****************
|
||||
|
||||
Solidity reserves three 256-bit slots:
|
||||
|
||||
- 0 - 64: scratch space for hashing methods
|
||||
- 64 - 96: currently allocated memory size (aka. free memory pointer)
|
||||
|
||||
|
@ -371,6 +371,9 @@ So ``bytes`` should always be preferred over ``byte[]`` because it is cheaper.
|
||||
that you are accessing the low-level bytes of the UTF-8 representation,
|
||||
and not the individual characters!
|
||||
|
||||
It is possible to mark arrays ``public`` and have Solidity create an accessor.
|
||||
The numeric index will become a required parameter for the accessor.
|
||||
|
||||
.. index:: ! array;allocating, new
|
||||
|
||||
Allocating Memory Arrays
|
||||
@ -617,6 +620,36 @@ Because of this, mappings do not have a length or a concept of a key or value be
|
||||
Mappings are only allowed for state variables (or as storage reference types
|
||||
in internal functions).
|
||||
|
||||
It is possible to mark mappings ``public`` and have Solidity create an accessor.
|
||||
The ``_KeyType`` will become a required parameter for the accessor and it will
|
||||
return ``_ValueType``.
|
||||
|
||||
The ``_ValueType`` can be a mapping too. The accessor will have one parameter
|
||||
for each ``_KeyType``, recursively.
|
||||
|
||||
::
|
||||
|
||||
pragma solidity ^0.4.0;
|
||||
|
||||
contract MappingExample {
|
||||
mapping(address => uint) public balances;
|
||||
|
||||
function update(uint newBalance) {
|
||||
balances[msg.sender] = newBalance;
|
||||
}
|
||||
}
|
||||
|
||||
contract MappingUser {
|
||||
function f() returns (uint) {
|
||||
return MappingExample(<address>).balances(this);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
.. note::
|
||||
Mappings are not iterable, but it is possible to implement a data structure on top of them.
|
||||
For an example, see `iterable mapping <https://github.com/ethereum/dapp-bin/blob/master/library/iterable_mapping.sol>`_.
|
||||
|
||||
.. index:: assignment, ! delete, lvalue
|
||||
|
||||
Operators Involving LValues
|
||||
|
Loading…
Reference in New Issue
Block a user