Re[30]: Собеседования в Яндекс++
От: so5team https://stiffstream.com
Дата: 04.06.19 20:16
Оценка: +2
Здравствуйте, smeeld, Вы писали:

S>Будет, так как после одного вызова shared_descriptor_count() следующий обязательно вернёт не 0, если только не вызовется секция после else.


Глаза разуйте: у вас нет ничего после else. Ваш while имеет вот такой вид:
while(some-condition) {
   if(another-condition) {
      break;
   }
   else {
      ...
      continue;
   }
}

Нет ничего больше внутри этого while. Но поскольку вы вместо нормального кода написали простыню нечитаемого потока создания, то и заблудились в трех соснах.

Ну или у вас при копировании вашего фрагмента скобки поплыли.

S>>Попробуйте сперва.


S>Чо там пробовать? Лямбды вообще уродливы.


Было очевидно, что вы не пробовали. Пропробовали бы, то увидели бы, что ваш основной код внутри первого while сократился бы раза в 1.5. Что сделало бы его понятнее.

S>Да вообще как хотите, хотите бла-бла, хотите ещё что. Мне параллельно Ваше мнение. Уровень его кометентности оценил сразу по первым двум сообщениям и по тому последнему, про обязательное отсутсвие разницы с continue и без него. Вы писали всегда простейший код и думаете что всё везде так же просто или может быть сделано просто. Ничего подобного.


Давайте сперва разберемся с тем, понимаете ли вы вообще свой код.

S>>Кстати, понять, почему вот это имеет смысл:

S>>
node_descp->set_current_storage_chunk(node_descp->get_current_storage_chunk());

S>>тоже очень не просто.

S>Догадайтесь с двух раз, ладно, c трёх раз. Вы видите где-нибудь инкремент текущего storage_chunk? А он происходит. По вашему, что происходит когда делается его get, и что происходит когда делается его set? get простая операция, но set-это уже другая история. Скажу по секрету, там несколькими функциями, минимально возможным количеством кода и количеством данных, описана достаточно массивная логика. Любители простоты вроде Вас наплодили бы раз в десять-двадцать больше кода и больше данных, со всеми вытекающими последствиями для производительности кеша CPU.


Если у вас get_current_storage_chunk() не является идемпотентной операцией, т.е. get_current_storage_chunk() каждый раз возвращает разное значение, то у этого кода есть смысл. Но тогда код пованивает еще больше.

А если же у вас get идемпотентен, то вызывать set_current_storage_chunk для того, чтобы еще раз назначить значение для current_storage_chunk... Ну как-то странно это.

В общем, куда не ткни, запашок какой-то подозрительный начинает доноситься.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.