1972 – Dennis Ritchie invents a powerful gun that shoots both forward and backward simultaneously. Not satisfied with the number of deaths and permanent maimings from that invention he invents C and Unix.

По синим таблицам Far Manager на экране, как же еще.

У непосвященных местных эти таблицы вызывают нечто вроде пещерного ужаса. У посвященных, но ниасиливших, кстати, возникает недоумение “как они ЭТИМ пользуются”. Асиливших пока не встречал.

Иногда мне кажется, что дядька, рисующий Дилберта, незаметно сидит за соседним с моим столом

Езь код

std::map<int, bool> myMap;

// Map is filled in with some data here

void SetValue(int key, bool newValue)
{
myMap[key] = newValue;
}

Небольшие ограничения: мап заполняется значениями только один раз, при запуске программы, гарантированно однопоточно. После инициализации SetValue может вызываться из разных потоков для разных ключей (то есть гонок по одному ключу быть не может). Кроме того, вызов SetValue с ключом, которого в мапе нет, исключен (т.е. невозможен).

С моей точки зрения, с данными допущениями код SetValue можно считать потокобезопасным (присвоение bool считаем атомарной операцией, не углубляясь особенно в детали). Конечно, во всех этих допущениях просвечивает некоторое джидайство (к примеру, operator[] у мапа вообще-то для вставки используется), но если их принять, то никакого криминала в подобном грубом обращении с этим STL контейнером не будет.

Моя аргументация тут такова – SetValue() модифицирует только значения, не изменяя состояние контейнера, поэтому для обеспечения потокобезопасности кода в данном конкретном случае необходимо и достаточно обеспечить потокобезопасность оператора присвоения для типа значения. Контр-аргумент коллеги тоже имеет под собой все основания, ведь нигде прямо не написано, что присвоение элементу мапа нового значения – операция потокобезопасное. Я парировал тем, что в MSDN четко описаны случаи инвалидации итераторов, в число которых изменение уже хранимого значения без вставки или удаления нового ключа никаким боком не входит.

Впрочем, мы джедаи опытные и на личности не переходим. Но в итоге трехчасовой беседы с отсылкой к исходникам STL в коде SetValue появился таки появился лок с моим каментом “Меня заставили”.

Я не отрицаю, что в общем случае так делать не надо. Бо и правда, первый же залетевший дятел завтра заменит мап на какую другую неведому зверюшку и все развалится при первом же неосторожном чихе. Или какой юный падаван проигнорирует жЫрные ворнинги в каментах (а ворнинги там знатные – я, в отличие от, код без комментариев не пишу) выкорчует код и без изменений применит там, где не надо, в результате чего и огребет как тумаков от обладателей синего меча, так и поджопников – от владельцев красного, плюс еще щелбанов от юзверей на закуску.

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

Вопрос  – я и правда провафлил какое-нибудь условие или мне стоило стоять на своем до конца?

Вот такой вот безтрансформаторный БП.

Уже неделю не могу найти ни одной причины, по которой оно работать не будет. Все вроде бы очень просто – суровые сибирские мужики заряжают 16-вольтовый электролит (C1) прямо из розетки огрызками полупериодов. Однако сама идея заряжать электролитический конденсатор прямо из розетки вызывает у меня труднопреодолимое желание забраться под плинтус и не вылезать оттудова.

И главное, совершенно бесплатно.

Это, доложу вам, полный пиздец.  Кажется, удельная масса кретинов в гугле, как и в большинстве крупных компаний, перевалила критическую.

Ну и как дальше жыдь, я вас спрашиваю?

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

class MyCoolClass
{
private:
BigFatObject* m_pOtherObject;
public:
MyCoolClass(BigFatObject* _pPtr):
m_pOtherObject(_pPtr)
{
}

void DoSmth()
{
std::string sName = m_pOtherObject->GetName();
// do smth
}

void DoMoreThings()
{
std::string sName = m_pOtherObject->GetName();
// do smth
}

// and other methods. All like this.

}

Вот такого вот горбатого лепят сплошь и рядом. И даже искры сомнения о том, что тут что-то не так, не проскакивает. Зато другим людям, которым посчастливится изменять BigFatObject или которые захотят переиспользовать код класса в другом месте, придется метать гром и молнии.

Вот объясните мне, они действительно просто не понимают, что тут нужно было передать в конструктор строку, вместо того, чтобы пихать указатель, вводя совершенно ненужные зависимости, делая при этом юнит-тестирование пыткой и превращая будущий рефакторинг в ходьбу по минному полю, заодно добавляя вопрос в времени жизни объектов?  Или же это банальное вредительство?

Знаете что? Единственное, что можно сказать о человеке, успешно решающем сферические головоломки в вакуууме это то, что он умеет решать сферические головоломки в вакууме.

Не говоря уже о том, что считающиеся правильными линии рассуждений при поиске решения задач являются как минимум неправильными. А как максимум – опасными.

Возьмем уже не очень популярную задачу о взвешивании Боинга без весов. Не очень популярную потому, что “правильные ответы” уже разве что на заборах не написаны.

Итак, посмотрим, чего пишут в интернетах.  А пишут в интернетах всякий кошмар. Например, предлагают “приземлиться на баржу и по водоизмещению вычислить вес”. Логично, в задаче ведь не указано, что число самолетов ограничено, самолетов через сто-сто двадцать можно разработать технику посадки Боингов на баржи одним куском.

Другие варианты не менее веселые. Например, предлагается где-то добыть конструкторскую документацию или каталоги поставщиков и просто сложить массы всех винтиков. Ну, вы знаете, есть еще такой крайне эффективный способ точного определения количества голов в стаде – посчитать все ноги и поделить на четыре. Мысль о том, что если им посчастливится достать подобную документацию, то где-нибудь на две тысячи триста пятнадцатой странице наверняка найдется сводная таблица основных характеристик самолета, которая будет включать разблюдовку его масс, никому в голову не приходит.

Есть еще и деструктивные варианты, которые я по понятным причинам упоминать не буду.

Впрочем, правильного ответа в интернетах нет. Правильный ответ вообще сам по себе односложен и является в свою очередь вопросом:

“А зачем Вам нужно знать вес Боинга?”.

Это единственный правильный ответ.  Потому что если у Вас нет ни самолета, ни весов и Вам просто интересно, то Вам прямая дорога на сайт производителя. Если у Вас по какой-то причине самолет есть, а весов нет, и вам просто позарез знать массу вашего конкретного самолета, то я бы посоветовал Вам не компостировать людям моск и не рисковать жизнями пассажиров, а приобрести соответствующие весы, если, конечно, весь Ваш интерес не ограничивается всего лишь оценкой потенциального дохода от сдачи алюминия, из которого он построен, во вторсырье. Впрочем, даже в этом случае я тоже посоветовал бы не заниматься фигней, а обратиться за информацией к производителю: не забывайте, что современные самолеты строятся из композитных материалов и алюминия в них может оказаться неожиданно мало.

Я бы мог понять, если бы подобные вопросы задавались при наборе на абстрактные должности решателей задач в вакууме. Я могу даже представить, что умение оценить количество настройщиков пианино в деревне Большие Васюки может быть очень полезно для каких-нибудь бизнес-аналитиков. Но ведь их задают при найме инженеров!

Дело в том, что инженеры решают задачи реального мира. В реальном мире нет абстрактной необходимости взвешивать абстрактные Боинги. В реальном мире может возникнуть потребность построить весы для самолета из  говна и палок (такая потребность подразумевает, что водоемов с баржами поблизости нет).  В реальном мире есть реальная необходимость обеспечивать оптимальную загрузку самолета и не допустить его перегрузки. Эта задача, на самом деле, на пару порядков сложнее. Инженер же такую задачу решит. Причем, прошу заметить, без разбора самолета до винтика или погрузки его на баржу. Далее, я вполне могу представить, что в реальном мире может потребоваться интегрировать весы собственно в сам самолет и я могу сходу предложить пару-тройку вариантов решения такой задачи, не требующих серьезной модификации самолета. Кстати, я сильно удивлюсь, если подобное решение нигде не используется.

Очевидно, что во всех этих случаях решения будут абсолютно разными, и определяться с решением инженер будет именно исходя из конкретной задачи. И именно поэтому вопрос “зачем” является самым правильным ответом для такой фудзиямовской задачи.

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