Solidity и смарт-контракты Ethereum, урок #20 | Ещё 50 вопросов на собеседовании (ч. 2, посложнее)

[@cryptoghost2]

Спасибо за видео, заполнил некоторые пробелы в моих знаниях! Небольшая придирка, в 11 речь идёт о переопределении, а не о перегрузке. А ещё я бы дополнил в ответе на 41 про то, что вызов pure функции из другого смарт-контракта на самом деле в байткоде такой же, как и вызов view. А это значит, что вы можете думать, что вызываете pure, а в вызываемом контракте на самом деле view, и отсюда могут быть всякие махинации с возвращением разного при одинаковых параметрах (с помощью gasleft).

[@IlyaBodrovKrukowski]

Да я тоже потом подумал, что перегрузка-то это про другое: в духе того, что в Elixir делается. Пардон. Спасибо за дополнения!

[@terra8603]

Искренне удивлён, что так мало просмотров. Вы очень хороший лектор!

[@IlyaBodrovKrukowski]

Спасибо! Ну, в других видео побольше

[@Nevybralnick]

Лектор супер!

[@0x0xxx08]

11. Как выполняется перегрузка функций? Вот так)) uint index = 0; uint public count; function stuckRemix () public { while (index == 0) { count++;} }

[@ramin777777]

вопрос 4, можно и так писать: // SPDX-License-Identifier: GPL-3.0 pragma solidity ^0.8.0; contract Sample { struct Person { string name; mapping(address => uint) request; } Person[] public persons; function test() external { persons.push(); persons[0].name = "Ramin"; } }

[@vadym468]

огромное спасибо за Ваш труд, Илья! 💪

[@IlyaBodrovKrukowski]

[@Anonimus_13]

Очепятка в 11 вопросе) это не перегрузка (overload), а переопределение (override)

[@IlyaBodrovKrukowski]

Да, в закреплённом комменте про это упомянуто. Я потом уже когда рендерил понял, что напортачил

[@GennadiiKotov]

Спасибо за видео! Кажется, в 11 вопросе речь идет все же о перегрузке, а не о переопределении. То есть здесь нужно говорить о разных наборах аргументов, перегружая функцию разными реализациями в зависимости от набора передаваемых аргументов, что в свою очередь и реализует разные сигнатуры.

[@GennadiiKotov]

Увидел с опозданием, что на это уже обращено внимание

[@404piano]

Спасибо!!!

[@IlyaBodrovKrukowski]

[@hachipoli822]

👍👍👍👍👍👍👍🔥🔥🔥🔥🔥🔥

[@Nevybralnick]

7:13. А зачем так сложно? uint[] memory arr = new uint[](3); эквивалентно uint[3] memory arr; При этом второе гораздо проще.

[@satoshisumoto1945]

Посмотрел по reentrence и у меня вопрос еще более усугубился. Есть 2 котракта C1, C2. В видео показан ход логики выполнения: 1) C2 вызывает refund() у С1 2) С1 переводит деньги, но не доходит до require(), и обнуления баланса, а переключается на функцию receive() контракта С2 3) receive() контракта С2 снова вызывает refund и так по циклу. Т.е. делаем выводы: 1) в показанной схеме до обнуления мы никогда не доходим (точнее доходим лишь на самой последней итерации когда денег уже нет и то, доходим лишь до require после чего вылетаем, а до обнуление так и не доходим) и 2) из этого делаем вывод что 2 контракта работают не как 2 независимые программы у каждой из которой свой рантайм, а как по сути 1 программа где есть код из 2х контрактов. Ок, если это так, то тогда возникает другой вопрос: В показанном примере решения проблемы через модификатор код выглядит как: 1) изменить значение булевой переменной 2) _; 3) изменить значение булевой переменной И вот тут логическая проблема на втором шаге (маркирован как _): мы не заканчиваем нормально функцию потому как по прежднему скачем с С1 на С2 и обратно пока не переведутся деньги и лишь на последней итерации когда денег уже нет и require выплюнет эксепшен мы наконец завершаем функцию, так и не добравшись до операции обнуления и лишь после этого модификатор меняет логическую переменную.Получается что этот модификатор бесполезен. По крайней мере такой вывод получаем после предложенной в видео логики работы.

[@xolaider6061]

спасибо! тут уже стоит проблема чтобы попасть на собеседование, у всех требования опыт работы, где взять его)

[@IlyaBodrovKrukowski]

Есть варианты стажировки. Я не скажу, какие именно, но точно знаю, что студенты находят, хотя и не сразу. Ну, конечно, ещё зависит от страны, увы

[@alihanurumov186]

нарисовать

[@CoinsGold]

Спасибо за видео! Такой вопрос к Вам: при запуске контракта в блокчейн bep20 ему присваивается адрес. Но этот адрес (публичный) - не принадлежит, как я понимаю, владельцу смартконтракта. Или это не так? Что прозойдёт, если на адрес контракта переведут BNB? Сможет ли владелец контракта извлечь эти средства?

[@IlyaBodrovKrukowski]

Деньги можно вывести, если контракт имеет функцию вывода денег. Если такой функции нет, то не вполне ясно, как их выводить

[@CoinsGold]

@@IlyaBodrovKrukowski , спасибо, ясно!

[@БекзодОлимов-я4ц]

Здравствуйте, у меня вопрос, а можно как-то конвертировать из типа string в тип bytes16?

[@IlyaBodrovKrukowski]

По-простому - никак, потому что строка потенциально безразмерна и может произойти "обрезка" части байтов с полезной информацией (если строка длинее 16 байт)

[@IlyaBodrovKrukowski]

ethereum.stackexchange.com/questions/9142/how-to-convert-a-string-to-bytes32 - тут что-то подобное. То есть строку можно легко конвертировать просто в bytes (безразмерный массив), в других случаях возможны варианты

[@БекзодОлимов-я4ц]

@@IlyaBodrovKrukowski , вот у меня есть контракт в котором несколько голосовалок и каждая со свои названием (string), чтобы можно было выбрать какую-то и делать там свои действия(проголосовать, добавить кандидата, закончить голосование) я сделал такую логику. Юзер в любой функции указывает название голосования, потом я беру хэш от этого стринга(название голосования) и ищу в мапинге голосовалок (bytes32 -> ballot(структура))

[@БекзодОлимов-я4ц]

@@IlyaBodrovKrukowski я подумал, что можно использовать мапинг(bytes16 -> ballot), чтобы оптимизировать контракт. Это глупая оптимизация или это нормальное решение?

[@IlyaBodrovKrukowski]

@@БекзодОлимов-я4ц Это немного странно, тк вы потеряете часть полезной информации и могут быть коллизии этих хэшей. Я думаю, лучше оставить bytes32, либо хэшировать как-то иначе (не keccak256)