41개 문서가 "AntelopeIO/cdt" 태그에 분류되었습니다

- Understanding ABI Files

ABI variants give the flexibility of using more than one type for a defined variable or data member.

The new ABI generator tool uses C++11 or GNU style attributes to mark actions and tables.

The cdt-abidiff tool is used to diff two ABI files to flag and output differences.

To manually compile the source code, use cdt-cc and cdt-ld as if it were clang and lld. All the includes and options specific to Antelope and CDT are baked in.

To manually compile the source code, use cdt-cpp and cdt-ld as if it were clang and lld. All the includes and options specific to Antelope and CDT are baked in.

This tool is used to generate a skeleton smart contract and directory structure.

The cdt-ld tool is a the custom web assembly linker for Antelope framework smart contracts.

Overview

Antelope based blockchains allow developers to easily update their smart contract code. However, a few things need to be considered when it comes to data updates and/or migration. The multi-index table API is one of the mechanisms (Key-Value API being the other) for storing and updating blockchain state. The multi-index table API creates and uses data structures in RAM. Once created and deployed on the blockchain there are limitations if you want to update these structures. Below you will find a few approaches to your smart contract data design, updates to this design, and for data migration.

In order to be able to debug your smart contract, you will need to setup a local nodeos node. This local nodeos node can be run as separate private testnet or as an extension of a public testnet. This local node also needs to be run with the contracts-console option on, either --contracts-console via the command line or contracts-console = true via the config.ini and/or by setting up logging on your running nodeos node and checking the output logs. See below for details on logging.

Deferred communication conceptually takes the form of action notifications sent to a peer transaction. Deferred actions get scheduled to run, at best, at a later time, at the producer's discretion. There is no guarantee that a deferred action will be executed.

You can find the implementation of eosio::binaryextension within the CDT repository in the file binaryextension.hpp.

For this release all of the naming of namespaces and file paths will remain as eosio, so there is no need to migrate away from that with this release.

Contracts can use uint64t error codes as an alternative (and shorter) means of signaling error conditions, as opposed to string error messages. However, Antelope and CDT reserve certain ranges of the uint64t value space for their own purposes. Contract developers must be aware of the following ranges and restrictions:

Overview

Overview

Overview

Overview

Overview

Overview

Overview

Overview

Overview

Overview

Overview

Overview

Overview

Overview

Overview

See README of https://github.com/AntelopeIO/cdt for instructions on how to build and install CDT.

- Advanced features of the newest version of the ABI will require manual construction of the ABI, and odd and advanced C++ patterns could capsize the generator's type deductions. So having a good knowledge of how to write an ABI should be an essential piece of knowledge of a smart contract writer.

When implementing Antelope smart contracts and when storing data in an Antelope blockchain, it is important to follow the established Antelope conventions for naming accounts, actions, tables, etc.

As of v1.5.0 native compilation can be performed and a new set of libraries to facilitate native testing and native "scratch pad" compilation. cdt-cc, cdt-cpp and cdt-ld now support building "smart contracts" and unit tests natively for quick tests to help facilitate faster development (note the default implementations of a lot of the Antelope intrinsics (aka host functions) are currently asserts that state they are unavailable, these are user definable.)

How much RAM do I need? This is not an easy question to answer, and there's really no perfect answer for it. You need to find out by measuring your contracts' actions and by planning accordingly based on your predictions on how fast and how much your blockchain application will grow. If your blockchain application growth is requiring more storage capacity you'll need to buy more RAM. If it requires more actions to be executed in the 3 day window (the staking time) you need to stake more tokens for CPU bandwidth. If your blockchain application growth means more actions will be stored on the blockchain then you also will need to expand your NET bandwidth maximum limit by staking more tokens for NET bandwidth.

Overview

Basic Recommendations

Let's fully explain what the eosio::binary_extension type is, what it does, and why we need it for contract upgrades in certain situations.

When sending an action to the blockchain you get the error below

- Binary Extension

Introduction