mirror of
https://github.com/ethereum/solidity
synced 2023-10-03 13:03:40 +00:00
Modified frequently-asked-questions.rst
Changed inline code syntax
This commit is contained in:
parent
80600a5a42
commit
ef6dc52801
@ -32,7 +32,7 @@ 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
|
||||
You can also use the :code:`solc` binary which comes with cpp-ethereum to compile
|
||||
contracts or an emerging option is to use Mix, the IDE.
|
||||
|
||||
|
||||
@ -89,22 +89,22 @@ If you want to deactivate your contracts, it is preferable to **disable** them b
|
||||
internal state which causes all functions to throw. This will make it impossible
|
||||
to use the contract and ether sent to the contract will be returned automatically.
|
||||
|
||||
Now to answering the question: Inside a constructor, `msg.sender` is the
|
||||
creator. Save it. Then `selfdestruct(creator);` to kill and return funds.
|
||||
Now to answering the question: Inside a constructor, :code:`msg.sender` is the
|
||||
creator. Save it. Then :code:`selfdestruct(creator);` to kill and return funds.
|
||||
|
||||
`example <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/05_greeter.sol>`_
|
||||
|
||||
Note that if you `import "mortal"` at the top of your contracts and declare
|
||||
`contract SomeContract is mortal { ...` and compile with a compiler that already
|
||||
Note that if you :code:`import "mortal"` at the top of your contracts and declare
|
||||
:code:`contract SomeContract is mortal { ...` and compile with a compiler that already
|
||||
has it (which includes `browser-solidity <https://ethereum.github.io/browser-solidity/>`_), then
|
||||
`kill()` is taken care of for you. Once a contract is "mortal", then you can
|
||||
`contractname.kill.sendTransaction({from:eth.coinbase})`, just the same as my
|
||||
:code:`kill()` is taken care of for you. Once a contract is "mortal", then you can
|
||||
:code:`contractname.kill.sendTransaction({from:eth.coinbase})`, just the same as my
|
||||
examples.
|
||||
|
||||
Store Ether in a contract
|
||||
=========================
|
||||
|
||||
The trick is to create the contract with `{from:someaddress, value: web3.toWei(3,"ether")...}`
|
||||
The trick is to create the contract with :code:`{from:someaddress, value: web3.toWei(3,"ether")...}`
|
||||
|
||||
See `endowment_retriever.sol <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/30_endowment_retriever.sol>`_.
|
||||
|
||||
@ -116,26 +116,26 @@ See `value_incrementer.sol <https://github.com/fivedogit/solidity-baby-steps/blo
|
||||
Get contract address in Solidity
|
||||
================================
|
||||
|
||||
Short answer: The global variable `this` is the contract address.
|
||||
Short answer: The global variable :code:`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.
|
||||
Long answer: :code:`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
|
||||
:code:`address` type, :code:`this` is always convertible to :code:`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
|
||||
:code:`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
|
||||
blockchain. These functions are called using :code:`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});`
|
||||
"non-constant" functions (those lacking the :code:`constant` specifier) must be called
|
||||
with :code:`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.
|
||||
|
||||
@ -150,8 +150,8 @@ 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"]`.
|
||||
If you have a state variable of type :code:`mapping (string -> uint) x;`, then you can
|
||||
access the value by :code:`x["somekeystring"]`.
|
||||
|
||||
How can I get the length of a mapping?
|
||||
======================================
|
||||
@ -161,7 +161,7 @@ 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.
|
||||
In this sense, the attribute :code:`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.
|
||||
@ -198,7 +198,7 @@ Can you return an array or a string from a solidity function call?
|
||||
Yes. See `array_receiver_and_returner.sol <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/60_array_receiver_and_returner.sol>`_.
|
||||
|
||||
What is problematic, though, is returning any variably-sized data (e.g. a
|
||||
variably-sized array like `uint[]`) from a fuction **called from within Solidity**.
|
||||
variably-sized array like :code:`uint[]`) from a fuction **called from within Solidity**.
|
||||
This is a limitation of the EVM and will be solved with the next protocol update.
|
||||
|
||||
Returning variably-sized data as part of an external transaction or call is fine.
|
||||
@ -239,8 +239,8 @@ 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.
|
||||
is done if you just use :code:`f(1,2)`. If you use :code:`this.f(1,2)`
|
||||
or :code:`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
|
||||
@ -288,12 +288,12 @@ Unless someone really messes up the blockchain or the clock on
|
||||
your computer, you can make the following assumptions:
|
||||
|
||||
You publish a transaction at a time X, this transaction contains same
|
||||
code that calls `now` and is included in a block whose timestamp is Y
|
||||
code that calls :code:`now` and is included in a block whose timestamp is Y
|
||||
and this block is included into the canonical chain (published) at a time Z.
|
||||
|
||||
The value of `now` will be identical to Y and X <= Y <= Z.
|
||||
The value of :code:`now` will be identical to Y and X <= Y <= Z.
|
||||
|
||||
Never use `now` or `block.hash` as a source of randomness, unless you know
|
||||
Never use :code:`now` or :code:`block.hash` as a source of randomness, unless you know
|
||||
what you are doing!
|
||||
|
||||
Can a contract function return a struct?
|
||||
@ -324,7 +324,7 @@ a way to pull out Ether from a contract.
|
||||
If the contract is not meant to receive Ether with simple transfers, you
|
||||
should implement the fallback function as
|
||||
|
||||
`function() { throw; }`
|
||||
:code:`function() { throw; }`
|
||||
|
||||
this will cause all transactions to this contract that do not call an
|
||||
existing function to be reverted, so that all Ether is sent back.
|
||||
@ -333,7 +333,7 @@ Another use of the fallback function is to e.g. register that your
|
||||
contract received ether by using an event.
|
||||
|
||||
*Attention*: If you implement the fallback function take care that it uses as
|
||||
little gas as possible, because `send()` will only supply a limited amount.
|
||||
little gas as possible, because :code:`send()` will only supply a limited amount.
|
||||
|
||||
Is it possible to pass arguments to the fallback function?
|
||||
==========================================================
|
||||
@ -342,7 +342,7 @@ The fallback function cannot take parameters.
|
||||
|
||||
Under special circumstances, you can send data. If you take care
|
||||
that none of the other functions is invoked, you can access the data
|
||||
by `msg.data`.
|
||||
by :code:`msg.data`.
|
||||
|
||||
Can state variables be initialized in-line?
|
||||
===========================================
|
||||
@ -386,12 +386,12 @@ How do for loops work?
|
||||
|
||||
Very similar to JavaScript. There is one point to watch out for, though:
|
||||
|
||||
If you use `for (var i = 0; i < a.length; i ++) { a[i] = i; }`, then
|
||||
the type of `i` will be inferred only from `0`, whose type is `uint8`.
|
||||
This means that if `a` has more than `255` elements, your loop will
|
||||
not terminate because `i` can only hold values up to `255`.
|
||||
If you use :code:`for (var i = 0; i < a.length; i ++) { a[i] = i; }`, then
|
||||
the type of :code:`i` will be inferred only from :code:`0`, whose type is :code:`uint8`.
|
||||
This means that if :code:`a` has more than :code:`255` elements, your loop will
|
||||
not terminate because :code:`i` can only hold values up to :code:`255`.
|
||||
|
||||
Better use `for (uint i = 0; i < a.length...`
|
||||
Better use :code:`for (uint i = 0; i < a.length...`
|
||||
|
||||
See `struct_and_for_loop_tester.sol <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/65_struct_and_for_loop_tester.sol>`_.
|
||||
|
||||
@ -409,7 +409,7 @@ There are some string utility functions at `stringUtils.sol <https://github.com/
|
||||
which will be extended in the future.
|
||||
|
||||
For now, if you want to modify a string (even when you only want to know its length),
|
||||
you should always convert it to a `bytes` first::
|
||||
you should always convert it to a :code:`bytes` first::
|
||||
|
||||
contract C {
|
||||
string s;
|
||||
@ -450,7 +450,7 @@ When returning a value of say "uint" type, is it possible to return an "undefine
|
||||
|
||||
This is not possible, because all types use up the full value range.
|
||||
|
||||
You have the option to `throw` on error, which will also revert the whole
|
||||
You have the option to :code:`throw` on error, which will also revert the whole
|
||||
transaction, which might be a good idea if you ran into an unexpected
|
||||
situation.
|
||||
|
||||
@ -545,14 +545,14 @@ Example::
|
||||
}
|
||||
}
|
||||
|
||||
The function `append` can work both on `data1` and `data2` and its modifications will be
|
||||
stored permanently. If you remove the `storage` keyword, the default
|
||||
is to use `memory` for function arguments. This has the effect that
|
||||
at the point where `append(data1)` or `append(data2)` is called, an
|
||||
The function :code:`append` can work both on :code:`data1` and :code:`data2` and its modifications will be
|
||||
stored permanently. If you remove the :code:`storage` keyword, the default
|
||||
is to use :code:`memory` for function arguments. This has the effect that
|
||||
at the point where :code:`append(data1)` or :code:`append(data2)` is called, an
|
||||
independent copy of the state variable is created in memory and
|
||||
`append` operates on this copy (which does not support `.push` - but that
|
||||
:code:`append` operates on this copy (which does not support :code:`.push` - but that
|
||||
is another issue). The modifications to this independent copy do not
|
||||
carry back to `data1` or `data2`.
|
||||
carry back to :code:`data1` or :code:`data2`.
|
||||
|
||||
A common mistake is to declare a local variable and assume that it will
|
||||
be created in memory, although it will be created in storage::
|
||||
@ -569,16 +569,16 @@ be created in memory, although it will be created in storage::
|
||||
}
|
||||
}
|
||||
|
||||
The type of the local variable `x` is `uint[] storage`, but since
|
||||
The type of the local variable :code:`x` is :code:`uint[] storage`, but since
|
||||
storage is not dynamically allocated, it has to be assigned from
|
||||
a state variable before it can be used. So no space in storage will be
|
||||
allocated for `x`, but instead it functions only as an alias for
|
||||
allocated for :code:`x`, but instead it functions only as an alias for
|
||||
a pre-existing variable in storage.
|
||||
|
||||
What will happen is that the compiler interprets `x` as a storage
|
||||
pointer and will make it point to the storage slot `0` by default.
|
||||
This has the effect that `someVariable` (which resides at storage
|
||||
slot `0`) is modified by `x.push(2)`.
|
||||
What will happen is that the compiler interprets :code:`x` as a storage
|
||||
pointer and will make it point to the storage slot :code:`0` by default.
|
||||
This has the effect that :code:`someVariable` (which resides at storage
|
||||
slot :code:`0`) is modified by :code:`x.push(2)`.
|
||||
|
||||
The correct way to do this is the following::
|
||||
|
||||
@ -598,11 +598,11 @@ Can a regular (i.e. non-contract) ethereum account be closed permanently like a
|
||||
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[]`?
|
||||
====================================================
|
||||
What is the difference between :code:`bytes` and :code:`byte[]`?
|
||||
================================================================
|
||||
|
||||
`bytes` is usually more efficient: When used as arguments to functions (i.e. in
|
||||
CALLDATA) or in memory, every single element of a `byte[]` is padded to 32
|
||||
:code:`bytes` is usually more efficient: When used as arguments to functions (i.e. in
|
||||
CALLDATA) or in memory, every single element of a :code:`byte[]` is padded to 32
|
||||
bytes which wastes 31 bytes per element.
|
||||
|
||||
Is it possible to send a value while calling an overloaded function?
|
||||
@ -658,15 +658,15 @@ How do you create 2-dimensional arrays?
|
||||
|
||||
See `2D_array.sol <https://github.com/fivedogit/solidity-baby-steps/blob/master/contracts/55_2D_array.sol>`_.
|
||||
|
||||
Note that filling a 10x10 square of `uint8` + contract creation took more than `800,000`
|
||||
gas at the time of this writing. 17x17 took `2,000,000` gas. With the limit at
|
||||
Note that filling a 10x10 square of :code:`uint8` + contract creation took more than :code:`800,000`
|
||||
gas at the time of this writing. 17x17 took :code:`2,000,000` gas. With the limit at
|
||||
3.14 million... well, there’s a pretty low ceiling for what you can create right
|
||||
now.
|
||||
|
||||
Note that merely "creating" the array is free, the costs are in filling it.
|
||||
|
||||
Note2: Optimizing storage access can pull the gas costs down considerably, because
|
||||
32 `uint8` values can be stored in a single slot. The problem is that these optimizations
|
||||
32 :code:`uint8` values can be stored in a single slot. The problem is that these optimizations
|
||||
currently do not work across loops and also have a problem with bounds checking.
|
||||
You might get much better results in the future, though.
|
||||
|
||||
@ -680,12 +680,12 @@ Every external function call in Solidity can be modified in two ways:
|
||||
|
||||
This is done by "calling a function on the function":
|
||||
|
||||
`f.gas(2).value(20)()` calls the modified function `f` and thereby sending 20
|
||||
:code:`f.gas(2).value(20)()` calls the modified function :code:`f` and thereby sending 20
|
||||
Wei and limiting the gas to 2 (so this function call will most likely go out of
|
||||
gas and return your 20 Wei).
|
||||
|
||||
In the above example, the low-level function `call` is used to invoke another
|
||||
contract with `p.data` as payload and `p.amount` Wei is sent with that call.
|
||||
In the above example, the low-level function :code:`call` is used to invoke another
|
||||
contract with :code:`p.data` as payload and :code:`p.amount` Wei is sent with that call.
|
||||
|
||||
What happens to a struct's mapping when copying over a struct?
|
||||
==============================================================
|
||||
@ -709,8 +709,8 @@ How do I initialize a contract with only a specific amount of wei?
|
||||
==================================================================
|
||||
|
||||
Currently the approach is a little ugly, but there is little that can be done to improve it.
|
||||
In the case of a `contract A` calling a new instance of `contract B`, parentheses have to be used around
|
||||
`new B` because `B.value` would refer to a member of `B` called `value`.
|
||||
In the case of a :code:`contract A` calling a new instance of :code:`contract B`, parentheses have to be used around
|
||||
:code:`new B` because :code:`B.value` would refer to a member of :code:`B` called :code:`value`.
|
||||
You will need to make sure that you have both contracts aware of each other's presence.
|
||||
In this example::
|
||||
|
||||
@ -734,20 +734,20 @@ you can only use one level of dynamic arrays.
|
||||
What is the relationship between bytes32 and string? Why is it that ‘bytes32 somevar = "stringliteral";’ works and what does the saved 32-byte hex value mean?
|
||||
==============================================================================================================================================================
|
||||
|
||||
The type `bytes32` can hold 32 (raw) bytes. In the assignment `bytes32 samevar = "stringliteral";`,
|
||||
the string literal is interpreted in its raw byte form and if you inspect `somevar` and
|
||||
see a 32-byte hex value, this is just `"stringliteral"` in hex.
|
||||
The type :code:`bytes32` can hold 32 (raw) bytes. In the assignment :code:`bytes32 samevar = "stringliteral";`,
|
||||
the string literal is interpreted in its raw byte form and if you inspect :code:`somevar` and
|
||||
see a 32-byte hex value, this is just :code:`"stringliteral"` in hex.
|
||||
|
||||
The type `bytes` is similar, only that it can change its length.
|
||||
The type :code:`bytes` is similar, only that it can change its length.
|
||||
|
||||
Finally, `string` is basically identical to `bytes` only that it is assumed
|
||||
to hold the utf-8 encoding of a real string. Since `string` stores the
|
||||
Finally, :code:`string` is basically identical to :code:`bytes` only that it is assumed
|
||||
to hold the utf-8 encoding of a real string. Since :code:`string` stores the
|
||||
data in utf-8 encoding it is quite expensive to compute the number of
|
||||
characters in the string (the encoding of some characters takes more
|
||||
than a single byte). Because of that, `string s; s.length` is not yet
|
||||
supported and not even index access `s[2]`. But if you want to access
|
||||
than a single byte). Because of that, :code:`string s; s.length` is not yet
|
||||
supported and not even index access :code:`s[2]`. But if you want to access
|
||||
the low-level byte encoding of the string, you can use
|
||||
`bytes(s).length` and `bytes(s)[2]` which will result in the number
|
||||
:code:`bytes(s).length` and :code:`bytes(s)[2]` which will result in the number
|
||||
of bytes in the utf-8 encoding of the string (not the number of
|
||||
characters) and the second byte (not character) of the utf-8 encoded
|
||||
string, respectively.
|
||||
@ -776,17 +776,17 @@ independent copies will be created::
|
||||
}
|
||||
}
|
||||
|
||||
The call to `g(x)` will not have an effect on `x` because it needs
|
||||
The call to :code:`g(x)` will not have an effect on :code:`x` because it needs
|
||||
to create an independent copy of the storage value in memory
|
||||
(the default storage location is memory). On the other hand,
|
||||
`h(x)` successfully modifies `x` because only a reference
|
||||
:code:`h(x)` successfully modifies :code:`x` because only a reference
|
||||
and not a copy is passed.
|
||||
|
||||
Sometimes, when I try to change the length of an array with ex: "arrayname.length = 7;" I get a compiler error "Value must be an lvalue". Why?
|
||||
==============================================================================================================================================
|
||||
|
||||
You can resize a dynamic array in storage (i.e. an array declared at the
|
||||
contract level) with `arrayname.length = <some new length>;`. If you get the
|
||||
contract level) with :code:`arrayname.length = <some new length>;`. If you get the
|
||||
"lvalue" error, you are probably doing one of two things wrong.
|
||||
|
||||
1. You might be trying to resize an array in "memory", or
|
||||
@ -806,16 +806,16 @@ contract level) with `arrayname.length = <some new length>;`. If you get the
|
||||
might be used to declaring them in C or Java, but they are access as in
|
||||
C or Java.
|
||||
|
||||
For example, `int8[][5] somearray;` are 5 dynamic `int8` arrays.
|
||||
For example, :code:`int8[][5] somearray;` are 5 dynamic :code:`int8` arrays.
|
||||
|
||||
The reason for this is that `T[5]` is always an array of 5 `T`s,
|
||||
no matter whether `T` itself is an array or not (this is not the
|
||||
The reason for this is that :code:`T[5]` is always an array of 5 :code:`T`'s,
|
||||
no matter whether :code:`T` itself is an array or not (this is not the
|
||||
case in C or Java).
|
||||
|
||||
Is it possible to return an array of strings ( string[] ) from a Solidity function?
|
||||
===================================================================================
|
||||
|
||||
Not yet, as this requires two levels of dynamic arrays (`string` is a dynamic array itself).
|
||||
Not yet, as this requires two levels of dynamic arrays (:code:`string` is a dynamic array itself).
|
||||
|
||||
If you issue a call for an array, it is possible to retrieve the whole array? Or must you write a helper function for that?
|
||||
===========================================================================================================================
|
||||
@ -842,9 +842,9 @@ After a successful CREATE operation's sub-execution, if the operation returns x,
|
||||
How do I use .send()?
|
||||
=====================
|
||||
|
||||
If you want to send 20 Ether from a contract to the address `x`, you use `x.send(20 ether);`.
|
||||
Here, `x` can be a plain address or a contract. If the contract already explicitly defines
|
||||
a function `send` (and thus overwrites the special function), you can use `address(x).send(20 ether);`.
|
||||
If you want to send 20 Ether from a contract to the address :code:`x`, you use :code:`x.send(20 ether);`.
|
||||
Here, :code:`x` can be a plain address or a contract. If the contract already explicitly defines
|
||||
a function :code:`send` (and thus overwrites the special function), you can use :code:`address(x).send(20 ether);`.
|
||||
|
||||
What does the following strange check do in the Custom Token contract?
|
||||
======================================================================
|
||||
@ -855,7 +855,7 @@ What does the following strange check do in the Custom Token contract?
|
||||
throw;
|
||||
|
||||
Integers in Solidity (and most other machine-related programming languages) are restricted to a certain range.
|
||||
For `uint256`, this is `0` up to `2**256 - 1`. If the result of some operation on those numbers
|
||||
For :code:`uint256`, this is :code:`0` up to :code:`2**256 - 1`. If the result of some operation on those numbers
|
||||
does not fit inside this range, it is truncated. These truncations can have
|
||||
`serious consequences <https://en.bitcoin.it/wiki/Value_overflow_incident>`_, so code like the one
|
||||
above is necessary to avoid certain attacks.
|
||||
|
Loading…
Reference in New Issue
Block a user