Version 1.6

eosiolib

Partitioning

In eosio.cdt v1.6.0, eosiolib will now be partitioned into 3 groups. These allow for finer grained allowance for particular modes of compilation.

CAPI
Contracts
Core
The CAPI will only be available to contract writers using eosio-cc and purely for C smart contracts.
The Contracts will be available to eosio-cpp for smart contract writing.
Core will be available to eosio-cpp for any of the modes (present and future).
eosio-cpp in fnative mode will have access to all of these groups.

To access these new partitioned header files, use <eosio/header_file.hpp> instead of <eosiolib/header_file.hpp>. Please note that all the old header files are still available at the old eosiolib directory, but these are deprecated and will be removed in v1.7.0. Also, once you change one header file from eosiolib to eosio you will need to do so for all other occurrences at that point, because of some conflicts with the auto generated dispatcher.

eosiolib C API

action.h
chain.h
crypto.h
db.h
permission.h
print.h
privileged.h
system.h
transaction.h
types.h

This entire API is now only available to C developers (i.e. using eosio-cc), and all internal uses in Core and Contracts have been guarded behind the namespace eosio::internal_use_do_not_use.

eosiolib Contracts API

action.hpp
- added C++ wrappers for
  - publication_time -> time_point publication_time()
  - current_receiver -> name current_receiver()
  - read_action_data -> uint32_t read_action_data(void* msg, uint32_t len)
  - action_data_size -> uint32_t action_data_size()
contract.hpp
- renamed receiver to self
- renamed code to first_receiver
- moved CONTRACT, ACTION and TABLE macros here.
- added get_first_receiver()
- deprecated get_code() instead use get_first_receiver
dispatcher.hpp
- no changes
eosio.hpp
- removed CONTRACT, ACTION and TABLE macros from here.
multi_index.hpp
- no changes
permission.hpp
- added C++ wrappers for
  - check_transaction_authorization
  - check_permission_authorization
  - get_permission_last_used
  - get_account_creation_time
privileged.hpp
- added C++ wrappers for
  - get_resource_limits
  - set_resource_limits
  - set_proposed_producers
  - is_privileged
  - set_privileged
producer_schedule.hpp
- moved producer_key struct here.
- added C++ wrapper for get_active_producers
singleton.hpp
- no changes
system.hpp
- removed check functions from here.
- added C++ wrappers for
  - eosio_exit
  - current_time_point
  - current_block_time
transaction.hpp
- added C++ wrappers for
  - send_deferred
  - cancel_deferred
  - transaction_size
  - tapos_block_num
  - tapos_block_prefix
  - expiration
  - get_context_free_data

eosiolib Core API

asset.hpp
- no changes
binary_extension.hpp
- moved datastream operators here.
check.hpp
- new file
- moved check functions to here.
crypto.hpp
- moved datastream operators here.
datastream.hpp
- removed datastream operators from here for
  - symbol
  - ignore
  - ignore_wrapper
  - public_key
  - signature
  - fixed_bytes
fixed_bytes.hpp
- moved datastream operators here.
ignore.hpp
- moved datastream operators here.
name.hpp
- added print method
print.hpp
- added C++ wrappers printhex and printl (which replaces prints_l)
- removed explicit print overloads for eosio::symbol_code, eosio::fixed_bytes<T> from here.
rope.hpp
- new file
- houses a thin data structure for fast string concatenations.
serialize.hpp
- no changes
symbol.hpp
- moved datastream operators here.
time.hpp
- no changes
varint.hpp
- no changes

Auto Code Generation

There is no more need to add the EOSIO_DISPATCH macro to your smart contracts. The compiler/linker will now automatically generate a dispatcher for you the proper eosio::contract, eosio::action and eosio::on_notify attributes are used. Of course, if you don't have these attributes then you will still need to either use the old macro or hand write the apply function yourself.

How the auto dispatcher will work

Given that you have marked your classes with the eosio::contract macro and any sub-contracts with the macro with the same given name (i.e. eosio::contract("<contract name>")) then any actions and notify handlers that are contained within these will be dispatchable by your smart contract. This will allow for aggregate patterns for smart contract development and better separation of concerns.

In addition to actions and notification handlers, two new "hooks" are available.

bool pre_dispatch(name self, name first_receiver, name action)
void post_dispatch(name self, name first_receiver, name action)

The pre_dispatch hook will fire when the dispatcher is run and allow the smart contract to do some pre-validation and exit early if need be by returning false. If the function returns true then the dispatcher continues to dispatching the actions or notification handlers.

The post_dispatch hook will only fire when the dispatcher has failed to match any notification handlers, this allows the user to do some meaningful last ditch validation.

If the dispatcher fails to find a suitable action to dispatch, then the new pattern is to fail assert with an error code. This will keep your smart contracts from being used as a sink by other users by accident (they inputted the wrong action name). This will give them clear direction at that point that the action they tried doesn't exist on your contract.

If the dispatcher is in notification handling mode and if your contract receives an eosio::onerror notification, then the contract will assert with an error code. You can circumvent this check if you explicitly supply an error handler for it ([[eosio::on_notify("eosio::onerror")]]).

For a real world example of this new style of contract in use see tests/unit/test_contracts/simple_test.cpp.

License

MIT