19

Data storage and representation in the EVM The address and address payable types both store a 160-bit Ethereum address. The concept of payable and non-payable addresses only exists in the Solidity type system at compile-time. The difference between payable and non-payable addresses is gone in the compiled contract code. Built-in methods You can use ....


16

Problem is 4 & 5 fit in less that 256 bits (each). You end up with tiny uints in the constant expression, and then those aren't easily converted to the uint256, so ... cast the type explicitly. uint x = uint(4)/uint(5); Takeaway is caution with constants because they may be cast in unexpected types. A sketchy idea: contract Divide { function ...


10

Since solidity@0.4.22, you can use abi.encodePacked() for this, which returns bytes. For example ; contract C { function toBytes(bytes32 _data) public pure returns (bytes) { return abi.encodePacked(_data); } }


8

You currently cannot return structs in Soldity as the answer to the question that you linked correctly outlines. But you can take your struct apart and return the individual elements (Solidity does support multiple return values): function getAssetStructById(uint256 assetId) constant returns ( uint256 assetId, uint256 next, uint256 prev, uint256 ...


6

Update: See here. We can return structs but only for internal calls. Returning structs in new version in Solidity In this snippet, function tryIt() returns true after a successful compile. It's just making an internal call (success). getAssetStructById() fails when called from outside. pragma solidity 0.4.17; contract Test { enum assetState{...


6

UPDATE: Solidity 0.6.x now have explicit conversions to payable: paybale(userAddress) And for smart contracts: payable(address(smartContract)) Old answer for Solidity 0.5.x: Here is how to cast address to address payable: address(uint160(userAddress)) And contract cast to address payable (thx to @Cyril): address(uint160(address(smartContract)));


5

Here is a totally inefficient method of converting bytes32 to bytes (while removing extra zeros bytes to the right). function bytes32ToBytes(bytes32 data) internal pure returns (bytes) { uint i = 0; while (i < 32 && uint(data[i]) != 0) { ++i; } bytes memory result = new bytes(i); i = 0; while (i < 32 && ...


5

For the transfer you can specify the amount in wei, which would be 1250000000000000000 for 1.25 ETH. For that you can use unsigned integer. No need for decimals. In most cases (not only for ETH) you can avoid using decimals by scaling the value to the desired precision.


5

It's unusual to need negative numbers. If you don't need negative numbers, there is no reason to use an int, and it's (slightly) easier to write secure code for positive numbers if you don't have to worry about what happens if they're negative. (I say "slightly" because in Solidity you still have to worry about uints overflowing.) For most practical ...


5

Here's a simple example to demonstrate casting msg.value to a uint248 value using Browser Solidity with the following code: pragma solidity ^0.4.8; contract Test { uint248 public value; function Test() { value = 123; } function () payable { value = uint248(msg.value); } } The screen below shows the deployment of the ...


4

For now, it's not possible to pass strings between contracts. I would consider chopping the string up into two bytes32 chunks. It would be more gas-efficient. Web3 clients are better suited to pack/unpack/convert. In my opinion, it's usually best to transfer the burden of data type conversion to clients. Hope it helps.


4

For casting, use value = uint248(msg.value); Casting to save 8 bits in this case is not worth it and will probably cost more gas due to unpacking: see Why does uint8 cost more gas than uint256? Even when using a struct of uint248 and uint8, it is best to actually test whether you are getting some gas savings.


4

Try this: value = uint248(msg.value);


4

I tested this simple contract: pragma solidity 0.4.20; contract Test { struct Example { bool v1; bool v2; bool v3; bool v4; bool v5; bool v6; bool v7; bool v8; } Example example; function test() public { Example memory ex = Example({ v1: true, v2: true, v3: true, v4: true, v5: true, v6: true, v7: ...


3

NOTE: This answer includes only experimental data Please read @medvedev1088's answer before, because my answer is only the addition and some data from tests. From my tests in remix I got this data: Creating 8-true-bool struct costs 58211 gas; 20k + 7 * 5k = 55k gas; Creating 16-true-bool struct costs 100807 gas; 20k + 15 * 5k = 95k gas; Creating 32-true-...


3

as an addition to @rob's answer you can use : function calcul(uint a, uint b, uint precision) view returns ( uint) { return a*(10**precision)/b; } If we divide using the function above 7/3 with a precision of 5 it will output 233333 which means 7/3=2.33333. The conversion to float can be done in the front-end.


3

Here's a function to do it: function getHexString(bytes4 value) pure public returns (string) { bytes memory result = new bytes(8); string memory characterString = "0123456789abcdef"; bytes memory characters = bytes(characterString); for (uint8 i = 0; i < 4; i++) { result[i * 2] = characters[uint256((value[i] & 0xF0) >> 4)...


3

You are using soliditySha3, which produces a 256-bit (32 bytes) hash, because of that your code works with bytes32. As you can see in the docs, the output of soliditySha3 is something like the following, with a length of 66, 64 without 0x. Check that one byte corresponds to two chars, so the result is 32 bytes. var x = web3.utils.soliditySha3('234'); // ...


3

This is possible, but not advised. If you do this, you should cast the int32 to an int256 in order to be explicit. int32 a = 1; int256 b = 3; int256 c = int256(a) + b; However, using types smaller than 32 bytes may actually be more expensive than using types that are 32 bytes exactly (such as int256, uint256, etc.). The reason for this is that the EVM ...


2

You cannot use mapping if you need to access “all” the data stored. Mapping aim is to find in a fast and quick way THE record you are looking for by means of a fast research in the hash table. The only practical iterable item could be an array in which the single record is your struct previously stored, but you should push that record in the array when ...


2

Why do you need currentPerson at all? The following code seems to work: pragma solidity ^0.4.13; contract People { Person[] public people; struct Person { bytes32 firstName; bytes32 lastName; uint age; } function addPerson(bytes32 _firstName, bytes32 _lastName, uint _age) returns (bool success) { Person memory newPerson; newPerson....


2

I just wrote a blog post about doubly linked lists that should help: https://programtheblockchain.com/posts/2018/03/30/storage-patterns-doubly-linked-list/. You can't have recursive structs, and there are no pointers, so you sort of have to make your own. Add each node to an array and use the index in the array as a "pointer." Something like this: struct ...


2

One possible solution is to use the eq instruction in inline assembly: uint256[] memory a = new uint256[](256); uint256[] memory b = a; bool aEqualsB; assembly { aEqualsB := eq(a, b) } // aEqualsB now contains the value: true b = new uint256[](256); assembly { aEqualsB := eq(a, b) } // aEqualsB now contains the value: false


2

How do I pass true or false in general via web3.js to a smart contract, as a string String(true)? In web3 you can use booleans true and false to pass true or false values for arguments to a contract. Is true and false NOT the same as 1 and 0 for web3 and/or solidity? In solidity you can pass 1 or 0 to refer to true and false respectively. However, in ...


2

A storage slot is 256 bits, as are hashes, ETH amounts etc, so it's simpler to standardize on returning a 256-bit number. However, if you need a timestamp in your contract you are under no obligation to store 256 bits: It's simple to cast it to a smaller size. This will often provide a gas saving if you're storing other small pieces of data at the same ...


2

Yes, they store the same data, that is a valid ethereum address. The difference is that the compiler (at compile time) when encounter an “address payable” is ready to allow (if required in the following code) that address to access primitives useful to manage ethers (namely call, transfer, send). In that sense, after a declaration like: address payable ...


2

keccak256 takes bytes as input, use: bytes32 hashedinput = keccak256(bytes(input)); hope it helps.


2

Is that correct? If yes, why do we do this and where can I find some further documentation? Yes, you are correct. Transactions are encoded based on the Contract ABI Specification. It is hard to get through, but these docs have all the answers to your question. The transaction in question is passing in a dynamic parameter (bytes) as opposed to a static one ...


2

This is a library for organizing an unordered key set with delete capability. https://github.com/rob-Hitchens/UnorderedKeySet It is an implementation of the Mapped Structs with Delete-enabled Index technique in the SE page Richard linked to. The library deals with the keys only. Store structs in a mapping to handle additional fields. Hope it helps.


1

I do not think it means what you think it means. The problem is that you're creating a new Foo in run test, then passing it into one(), then passing it into two(), then changing it in two() returning it to one(), where you assign it into foobar, then proceed to return not even foobar's, but the original foo's stayFalse (not that it would have helped any). ...


Only top voted, non community-wiki answers of a minimum length are eligible