Even though the initial idea of this assignment is to update the existing balance by replacing it with the new one, I actually think that it makes more sense to do what you have done, and add an amount to the existing balance using the addition assignment operator += (instead of the assignment operator = ). However, if you add to, instead of replacing, the existing balance, I think your code would be clearer and more readable if you also change the name of the balance parameter to amount , because you are adding an amount to the balance, rather than replacing it with a new balance.
Hey Thanks, @jon_m Happy accident that I misinterpreted the assignment then I guess. No questions for you now, your response makes total sense and has been dutifully noted. I appreciate your time.
the issue with the original code is that the balance was stored in memory, i.e. as a temporary data type because the ‘balance’ amount was set to a memory data type, not a permanent data type, i.e. not the storage data type.
Thank you so much for the code review @jon_m. Incredible insight and valuable information on what are the thought process of a much more proficient Solidity programmer when it comes to generating a smart contract. Really appreciate the reply and all the constructive criticism. Looking forward from more guidance from you.
Nice solution @Unknowncode
… and good to see you back here in the forum I hope you’re enjoying the course!
Even though the initial idea of this assignment is to update the existing balance by replacing it with the new one, I actually think that it makes more sense to do what you have done, and add an amount to the existing balance using the addition assignment operator += (instead of the assignment operator = ). However, if you add to, instead of replacing, the existing balance, I think your code would be clearer and more readable if you also change the name of the balance parameter to amount , because you are adding an amount to the balance, rather than replacing it with a new balance .
Just be careful with the term data type. This refers to whether data is defined as uint, int, address, bool, string etc. Here you are highlighting differences in the duration data is stored for (either temporarily, or persistently). This is a result of data location (memory, or storage), and not data type.
Correct… although not very efficient in terms of gas cost or conciseness of code.
This solution makes the updateBalance function exactly the same as the addUser function.
While this does still work…
This is incorrect: the first line generates a red compiler error. The error message tells you what the specific nature of the error is: the data location for this complex data type (a User instance based on the User strut) must be explicitly declared for local variables.
Have you now found out what the 2 most efficient solutions are? If not, you will find them in other students’ solutions posted in this discussion topic.
Let us know if anything is unclear, or if you have any questions
Hi guys, I figured that the problem in the starter code was that it was using a memory located temporary variable to assign the new balance value, so the fix was just simply using dot notation to directly access the users mapping (located in storage) and change the balance value of the user permanently.
pragma solidity 0.7.5;
contract MemoryAndStorage {
mapping(uint => User) users;
struct User{
uint id;
uint balance;
}
function addUser(uint id, uint balance) public {
users[id] = User(id, balance);
}
function updateBalance(uint id, uint balance) public {
users[id].balance = balance;
}
function getBalance(uint id) view public returns (uint) {
return users[id].balance;
}
}