No there is no similar issue with Cairo. 

The idea is that memory is a map that associates an address with a value.

We mainly use Uint256 for composability purposes (using ERC20/ERC721). But as a felt is a 251 bits number and a native type of cairo, I prefer to use it in almost all situations. 


Here is an [article](https://mirror.xyz/0x845605C411132BAA06024a521a85B653F3C802dF/wfUO8KSz2IAt8yg4oslsc1HDsJqMJ6HpQAukhjwZUUU) to help you understand, felt and Uint256 in cairo.

Hey, I’m learning Cairo and I want to know more about Gas Optimization. In Solidity compiler, there is a difference between writing uint128 and uint256. Similarly to C and other languages, for example:

```solidity
contract ThisIsNotAnOptimizedContract{
	uint128 Zero;
	uint256 One;
	uint128 Two;
}

contract ThisIsAGasOptimizedContract{
	uint128 Zero;
	uint128 Two;
	uint256 One;
}

```

`uint128` variables each occupy a separate `uint256`just for themselves, wasting 128 bits for each slot (Like the first contract). The Solidity compiler puts 2 `uint128` in the one 256-bit memory slot when they are declared next to each other. 

I’m curious if there is any similar issue in Cairo. `Uint256` uses two felt objects for low/high bits of the value.

```python
struct Uint256 {
    // The low 128 bits of the value.
    low: felt,
    // The high 128 bits of the value.
    high: felt,
}
```

Is there any similar practice in Cairo to optimize `felt` and Uint256 objects to save some compiler steps?

Popular tags

Profile

Fricoben

Wallet address: 0x90Bc0b43fA89027B2f2df93fA7028357370a026a

Recent questions

Recent answers