Solidity++ retains most syntax of Solidity. However, Solidity++ is still a different language. The difference mainly lies in asynchronous design.
# Syntax Removed in Solidity++
Below syntax has been removed from Solidity
Syntax related to
ripemd160 has been disabled
DELEGATECALL is not available in Solidity++ at this moment
Syntax of inline assembly in Solidity is temporarily unavailable
# Syntax Added/Modified in Solidity++
Below syntax has been added in Solidity++
fromhash()returns request transaction's hash
accountheight()returns latest block height of an account
prevhash()returns latest block hash of an account
random64()returns a random number in
uint64. This function will return the same random number in one transaction
nextrandom()returns a random number in
uint64. This function can be called multiple times to obtain different random numbers in one transaction
tokenId are redefined in Solidity++:
Obtain transfer value in Solidity:
Obtain transfer value in Solidity++(
value has been changed to
Obtain transfer token id(Solidity doesn't have the feature):
Obtain account balance in Solidity:
Obtain account balance in Solidity++(a parameter of tokenId is required):
In Solidity, send ETH to an address:
In Solidity++, send specific token to an address:
Unit of ETH in Solidity: wei/szabo/finney/ether
1 ether = 1000 finney, 1 finney = 1000 szabo, 1 szabo = 1000000000000 wei
Unit of VITE in Solidity++: attov/vite
1 vite = 1000000000000000000 attov
In Solidity++, all syntax related to
sha3 is replaced by
# Asynchronous Syntax in Solidity++
Unlike Solidity, in-contract communication in Solidity++ is not done through function calls, but by message passing
publicfunctions cannot be accessed from outside of the contract
functioncannot be declared as
functioncan only be declared as
publicstatic variable is not visible from outside of the contract
message: keyword, declaring a message, including message name and passed-in parameter. In above example,
message sum(uint result)declares message "sum" accepting a
onMessage: keyword, declaring a message listener, including message name, passed-in parameter and business logic that handles the message. In above example,
onMessage add(uint a, uint b)declares message listener "add" accepting two
send: keyword, sending a message, accepting two parameters including message receiving address and message body
Message can be declared in contract and can only be sent out from the exact contract who declares it. If a message should be processed by another contract, the name and passed-in parameters of the message rely on how message listener is defined in the other contract.
In other words, if contract A would like to send a message to contract B, A must define the message in a format that complies to the listener defined in contract B.
Message listener is defined in contract. A message listener specifies a certain type of message that can be processed by the contract. Unrecognized messages will not be handled but discarded.
Message listeners cannot be called directly as normal functions.
In above example,
Contract A defines a message listener
add(uint a, uint b) while contract B defines
sum(uint result), indicating the messages that can be processed by contract A or contract B.
Here contract B sends message to contract A. For this purpose, contract B must declare "add" message which complies to
add(uint a, uint b) defined in contract A.
Similarly, contract A should declare "sum" message matching message listener
sum(uint result) of contract B, since contract A will send such a message to contract B in return.
getter in Solidity++
In Solidity++, because interactions between contracts are carried out through asynchronous messaging, the
public fields cannot be accessed directly from outside of the contract.
To address this problem, Solidity++ provides a solution.
As shown in above example, a "getter" method
getMagic() is defined to access public field
magic. In general, "getter" in Solidity++ has the following characteristics:
getteris used to declare such a method.
- Method name, input parameters and return value are required. As query method, it is only used to obtain the specific field's value and cannot modify it.
- The compiled code of "getter" is not stored on chain, so it is not allowed to access transaction related information, such as
msg.tokenid, within "getter".
- "getter" cannot send transactions or send messages. It cannot call
- "getter" can call functions, which should be defined as
# Example of Solidity++ Contract
Below contract defines a batch transfer which accepts a list of addresses and amounts and then transfers specified amount to specified address in the list