В целом согласен, но все-таки можно подкопаться —
1. компиляторы при оптимизации могут менять порядок операций. Как — зависит от версии и ключей.
2. не смотря на то, что чтение-запись volatile выглядит, как 1 команда, это не равносильно атомарной операции. Объяснения со ссылками уже приводились в этом треде. Хотя в этом примере возможные значение только 0 и 1, так что данный факт частично маскируется.
В этом примере используется конкурентное чтение-запись одного участка памяти без использования lock'ов или atomic операций. Это — неопределенное поведение. Дальше практического смысла исследовать код нет. Можно только проанализировать его на конкретной машине разобрав по косточкам конкретную ситуацию. Еще одно применение — показывать упорным юниорам, которые уверены, что синхронизировать разделяемую переменную типа bool или даже int не надо :)
Примерно так бы и ответил бы на собеседовании, кстати ;)
фишка в том, что нету тут решения! код будет работать по-разному в зависимости от компилятора/процессора. Как именно — поможет дизассемблирование скомпилированного кода.
Задача напомнила мне совсем недавнее обращение коллеги — после перехода с VS 6.0 на VS 2005 код
func(a[++cnt], a[++cnt], a[++cnt]) стал работать по-другому :)
Вопрос коллеги был такой же — «почему?».
Правда, эта проблема относится к C++ и имеет формальное объяснение.
В этой задаче нет особенностей языка «C++», т.к. Стандарт насколько я помню не говорит ничего о потоках (мы не говорим об C++0x ?).
Решение этой задачи нужно искать в плоскости исследования оптимизации компиляции (грубо говоря, Debug/Release будут давать разные результаты), особенности работы кешей 1 уровня на различных процессорах.
Так как эти условия (компилятор, его ключи, процессор) не указаны, то краткий ответ — неопределенное поведение.
Это да, если есть определенный кредит доверия от кастомера этим пользуемся.
Но
1. суровым людям приходится работать и через remote desktop или даже webex.
2. чаще всего все их действия трекаются местными инженерами чтобы в случае чего повторить их гениальный полет мыслей в похожих ситуациях, или наоборот, восстановить систему после неудачных попыток :)
3. Такой кредит доверия еще нужно заработать )
Солидарен с крутостью TC, но такой пример есть :(
Это то, что он не входит, в отличие от проводника, в поставку windows.
Когда это важно? Если ты саппорт-инженер и должен ковыряться на компах кастомеров. Поставить свой софт нельзя, запустить с флешки тоже. Поэтому эти суровые люди тренируются не пользоваться сторонними файловыми менеджерами (tc, far).
Нечестный ход со стороны проводника, но он такой ;)
не пробовал, но имхо если блюром пройтись, OCR должно нормально понять.
опять же, думаю что сама идея статических капч уже давно устарела.
придумывайте анимационные, что ли )
Не планируется ли следующая фича: поле обязательного (но анонимного) комментария для плюсующих/минусующих карму.
А если еще была бы информация с какого хабратопика/комментария был переход при этом в хабрацентр, было бы вообще здорово.
Для начинающих юзеров, думаю, было бы очень востребовано.
Нечто подобное есть на форуме cosmostv.by.
Такая тактика в первом приближении используется в менеджере памяти .NET:
Вначале ресурсы откушиваются с хорошим запасом, сборщик мусора нетороплив и избирателен )
При уменьшении размера доступной памяти менеджер «затягивает ремень» и трудится более эффективно )
А на уровне ОС такая стратегия реализована с помощью свопа. А у приложения существует возможность объявить часть выделенной памяти «несвопабильной» :), т.е. запретить скидывать ее в своп.
> Стартовая зарплата инженера-программиста начинается от порядка 30 тыс. Евро в год и растет до уровня без ограничений, средняя в области составляет порядка 60-70 тыс. Евро в год.
Это «грязная», до налогов/соцсборов и т.д.
Чистая на 30%-50% меньше.
1. компиляторы при оптимизации могут менять порядок операций. Как — зависит от версии и ключей.
2. не смотря на то, что чтение-запись volatile выглядит, как 1 команда, это не равносильно атомарной операции. Объяснения со ссылками уже приводились в этом треде. Хотя в этом примере возможные значение только 0 и 1, так что данный факт частично маскируется.
В этом примере используется конкурентное чтение-запись одного участка памяти без использования lock'ов или atomic операций. Это — неопределенное поведение. Дальше практического смысла исследовать код нет. Можно только проанализировать его на конкретной машине разобрав по косточкам конкретную ситуацию. Еще одно применение — показывать упорным юниорам, которые уверены, что синхронизировать разделяемую переменную типа bool или даже int не надо :)
Примерно так бы и ответил бы на собеседовании, кстати ;)
Задача напомнила мне совсем недавнее обращение коллеги — после перехода с VS 6.0 на VS 2005 код
func(a[++cnt], a[++cnt], a[++cnt]) стал работать по-другому :)
Вопрос коллеги был такой же — «почему?».
Правда, эта проблема относится к C++ и имеет формальное объяснение.
Решение этой задачи нужно искать в плоскости исследования оптимизации компиляции (грубо говоря, Debug/Release будут давать разные результаты), особенности работы кешей 1 уровня на различных процессорах.
Так как эти условия (компилятор, его ключи, процессор) не указаны, то краткий ответ — неопределенное поведение.
но где аргументация?
что-то типа шагов для начинающих
Но
1. суровым людям приходится работать и через remote desktop или даже webex.
2. чаще всего все их действия трекаются местными инженерами чтобы в случае чего повторить их гениальный полет мыслей в похожих ситуациях, или наоборот, восстановить систему после неудачных попыток :)
3. Такой кредит доверия еще нужно заработать )
Это то, что он не входит, в отличие от проводника, в поставку windows.
Когда это важно? Если ты саппорт-инженер и должен ковыряться на компах кастомеров. Поставить свой софт нельзя, запустить с флешки тоже. Поэтому эти суровые люди тренируются не пользоваться сторонними файловыми менеджерами (tc, far).
Нечестный ход со стороны проводника, но он такой ;)
т.е. мозилла хостит его в закладке
Простейший например, черезстрочная развертка
тогда уже предлагать дополнить русские пословицы/анекдоты — индусы 100% в пролете )
опять же, думаю что сама идея статических капч уже давно устарела.
придумывайте анимационные, что ли )
А если еще была бы информация с какого хабратопика/комментария был переход при этом в хабрацентр, было бы вообще здорово.
Для начинающих юзеров, думаю, было бы очень востребовано.
Нечто подобное есть на форуме cosmostv.by.
Вначале ресурсы откушиваются с хорошим запасом, сборщик мусора нетороплив и избирателен )
При уменьшении размера доступной памяти менеджер «затягивает ремень» и трудится более эффективно )
А на уровне ОС такая стратегия реализована с помощью свопа. А у приложения существует возможность объявить часть выделенной памяти «несвопабильной» :), т.е. запретить скидывать ее в своп.
Это «грязная», до налогов/соцсборов и т.д.
Чистая на 30%-50% меньше.