diff --git a/contracts/currency/currency.cpp b/contracts/currency/currency.cpp index 73f42b779b2932f8a1b27f7977df8a969afc2356..2e0dac4408dc65ccec2a46d4da0ec47facde395a 100644 --- a/contracts/currency/currency.cpp +++ b/contracts/currency/currency.cpp @@ -37,11 +37,11 @@ extern "C" { storeAccount( N(currency), Account( CurrencyTokens(1000ll*1000ll*1000ll) ) ); } - /// The apply method implements the dispatch of events to this contract - void apply( uint64_t code, uint64_t action ) { - if( code == N(currency) ) { - if( action == N(transfer) ) - currency::apply_currency_transfer( currentMessage< TOKEN_NAME::Transfer >() ); - } - } + /// The apply method implements the dispatch of events to this contract + void apply( uint64_t code, uint64_t action ) { + if( code == N(currency) ) { + if( action == N(transfer) ) + currency::apply_currency_transfer( currentMessage< TOKEN_NAME::Transfer >() ); + } + } } diff --git a/contracts/eoslib/contracts.dox b/contracts/eoslib/contracts.dox index 115478426a1988846843d8237f10567ab11ccb5c..b47d857ab05688767585a7395983cae81f3061a5 100644 --- a/contracts/eoslib/contracts.dox +++ b/contracts/eoslib/contracts.dox @@ -21,31 +21,22 @@ @subsection programentry Entry Points - EOS.IO applications have three potential starting points that behave like `main` in traditional applications: + EOS.IO applications have a `apply` which is like `main` in traditional applications: ``` extern "C" { - void validate( uint64_t code, uint64_t action ); - void precondition( uint64_t code, uint64_t action ); + void init(); void apply( uint64_t code, uint64_t action ); } ``` - Each of these entry points is give the arguments `code` and `action` which uniquely identify every event in - the system. For example, code could be a `currency` contract and action could be `transfer`. This event (code,action) + `main` is give the arguments `code` and `action` which uniquely identify every event in + the system. For example, `code` could be a *currency* contract and `action` could be *transfer*. This event (code,action) may be passed to several contracts including the `sender` and `receiver`. It is up to your application to figure out what to do in response to such an event. - Each handler has a different level of access to blockchain state: - - - **validate** can only access the data on the message itself - - **precondition** only has read access to the database and message - - **apply** has read/write access to the database - - These three different handlers enable EOS.IO to maximize the amount of potential parallelism possible and it may - make sense to move computationaly expensive validations to either precondition or validate. That said, most developers - can postpone learning about `validate` and `precondition` as anything that can be done in those entry points can also - be performed in `apply`. + `init` is another entry point that is called once immediately after loading the code. It is where you should perform + one-time initialization of state. ### Example Apply Entry Handler diff --git a/contracts/eoslib/rpc.dox b/contracts/eoslib/rpc.dox index 517e35a3174e49f94da6fa26a67da18a9c2c51cc..5078e37f418ffa180e89e1fba6a3685720e7be80 100644 --- a/contracts/eoslib/rpc.dox +++ b/contracts/eoslib/rpc.dox @@ -31,6 +31,7 @@ ``` { "head_block_num":449, + "last_irreversible_block_num": 434, "head_block_id":"000001c1a0f072a5ca76831ac6c6e2988efcf162e953eb40046ec2ceca817a9f", "head_block_time":"2017-07-18T21:02:24", "head_block_producer":"initd", diff --git a/docs/currency_8hpp.html b/docs/currency_8hpp.html index 76e2540add7acbb047e5841c9f565016ac2b167b..38b755aa90ca5ddc2639d2273a7792646d44ce3d 100644 --- a/docs/currency_8hpp.html +++ b/docs/currency_8hpp.html @@ -99,10 +99,10 @@ Macros
Typedefs | |
typedef eos::token< uint64_t, N(currency)> | TOKEN_NAME::CurrencyTokens |
using | TOKEN_NAME::Accounts = Table< N(currency), N(currency), N(account), Account, uint64_t > |
typedef eos::token< uint64_t, N(currency)> | TOKEN_NAME::CurrencyTokens |
using | TOKEN_NAME::Accounts = Table< N(currency), N(currency), N(account), Account, uint64_t > |
Functions | |
file | currency.hpp [code] |
file | currency.wast.hpp [code] |
file | currency.wast.hpp [code] |
As an application developer you get to decide what actions users can take and which handlers may or must be called in response to those events.
EOS.IO applications have three potential starting points that behave like main
in traditional applications:
Each of these entry points is give the arguments code
and action
which uniquely identify every event in the system. For example, code could be a currency
contract and action could be transfer
. This event (code,action) may be passed to several contracts including the sender
and receiver
. It is up to your application to figure out what to do in response to such an event.
Each handler has a different level of access to blockchain state:
-These three different handlers enable EOS.IO to maximize the amount of potential parallelism possible and it may make sense to move computationaly expensive validations to either precondition or validate. That said, most developers can postpone learning about validate
and precondition
as anything that can be done in those entry points can also be performed in apply
.
EOS.IO applications have a apply
which is like main
in traditional applications:
main
is give the arguments code
and action
which uniquely identify every event in the system. For example, code
could be a currency contract and action
could be transfer. This event (code,action) may be passed to several contracts including the sender
and receiver
. It is up to your application to figure out what to do in response to such an event.
init
is another entry point that is called once immediately after loading the code. It is where you should perform one-time initialization of state.
Generally speaking, you should use your entry handler to dispatch events to functions that implement the majority of your logic and optionally reject events that your contract is unable or unwilling to accept.
extern "C"
code block so that c++ name mangling does not get applied to the function. The get_info
RPC command can be found at:
And it should return something like:
And it should return something like:
Typedefs | |
typedef eos::token< uint64_t, N(currency)> | CurrencyTokens |
using | Accounts = Table< N(currency), N(currency), N(account), Account, uint64_t > |
typedef eos::token< uint64_t, N(currency)> | CurrencyTokens |
using | Accounts = Table< N(currency), N(currency), N(account), Account, uint64_t > |
Functions | |
using TOKEN_NAME::Accounts = typedef Table<N(currency),N(currency),N(account),Account,uint64_t> | +typedef Table< N(currency), N(currency), N(account), Account, uint64_t > TOKEN_NAME::Accounts |
typedef eos::token<uint64_t,N(currency)> TOKEN_NAME::CurrencyTokens | +typedef eos::token< uint64_t, N(currency)> TOKEN_NAME::CurrencyTokens |
token subtraction has underflow assertion
+token addition has overflow assertion
+token subtraction has underflow assertion
+token addition has overflow assertion
+token subtraction has underflow assertion
token addition has overflow assertion
Accounts information for owner is stored:
owner/TOKEN_NAME/account/account -> Account
This API is made available for 3rd parties wanting read access to the users balance. If the account doesn't exist a default constructed account will be returned.
+scope, record
+scope, record
scope, record
value, scope
+value, scope
+value, scope
+value, scope
+value, scope
value, scope
This is the complete list of members for TOKEN_NAME::Account, including all inherited members.
Account(CurrencyTokens b=CurrencyTokens()) | TOKEN_NAME::Account | inline |
balance | TOKEN_NAME::Account | |
Account(CurrencyTokens b=CurrencyTokens()) | TOKEN_NAME::Account | inline |
balance | TOKEN_NAME::Account | |
isEmpty() const | TOKEN_NAME::Account | inline |
isEmpty() const | TOKEN_NAME::Account | inline |
key | TOKEN_NAME::Account | |
key | TOKEN_NAME::Account |
Public Member Functions | |
Account (CurrencyTokens b=CurrencyTokens()) | |
Account (CurrencyTokens b=CurrencyTokens()) | |
bool | isEmpty () const |
Account (CurrencyTokens b=CurrencyTokens()) | |
bool | isEmpty () const |
Public Attributes | |
const uint64_t | key = N(account) |
CurrencyTokens | balance |
const uint64_t | key = N(account) |
CurrencyTokens | balance |
+
|
+ +inline | +
CurrencyTokens()
CurrencyTokens()
+
|
+ +inline | +
CurrencyTokens TOKEN_NAME::Account::balance | +CurrencyTokens Account::balance |
CurrencyTokens TOKEN_NAME::Transfer::quantity | +CurrencyTokens TOKEN_NAME::Transfer::quantity |