Все-таки нет, в данном случае если ты объявляешь функцию как interrupt, то ты ожидаешь от компилятора всех необходимых действий. Контекст задач в операционке тут не при чем. И производители этот баг подтвердили по ссылке выше.
Ну так приведите пример статического анализатора с открытым кодом (или хотя бы просто бесплатного), который бы РАБОТАЛ и работал ЭФФЕКТИВНО, раз это так легко сделать, по-вашему.
Еще один миф, из-за которого, возможно, чаще всего отказываются использовать статический анализатор — слишком дорого. При этом все доводы о возможных потерях из-за невыловленных вовремя ошибках не принимаются во внимание…
Подумалось — а вдруг чудо возможно, и, установив брейкпоинт внутри «int memento()», удастся увидеть стек вызовов? При этом указывающий на причину, конечно же. Попробовал — увы, нет :( Стек-то виден, но — бесполезный, «fall()» в нем не упоминается даже.
По поводу учета эффективности — очень часто одно только наличие учета весьма эту самую эффективность повышает. Главное — не перегибать с этим учетом палку, отслеживая время каждого похода в туалет, например :)
Замечания принимаются. Я согласен, что в моем упрощении многое остается за кадром. Но когда на проекте всего 2-3 человека работают полгода-год, «полноценное» управление добавит слишком много эффорта, мало что дав в замен.
Безусловно, для проекта человек в 100 мое упрощение уже не сработает. Но и противоположное, мне кажется, будет верно — система, оптимальная для управления проектом из 100 человек, не будет лучшим выбором для управления проектом, где работают только двое.
Упрощенная реализация этого видения «вручную» мне реально помогала увидеть моменты, когда дата релиза отодвигалась. Также было полезным увидеть наиболее проблемные места по завершению, чтобы сделать выводы, где, что и почему пошло не так.
Время окончания — как максимум по завершению всех задач всеми людьми, исходя из remaining time по каждой задаче и предположению, что каждый человек работает по х часов в день.
Для множества небольших проектов, в которых задачи достаточно хорошо разделяемы, их порядок выполнения не является чем-то предопределенным и уж тем более чем-то жестко заданным. А если даже и требуется определенный порядок, то он часто является очевидным и не требует явного прописывания — предполагается, что имея две связанные друг с другом задачи, разработчик сам выберет правильный порядок их выполнения.
Диаграмма Ганта (да и много из управления качеством) пришли в ИТ из материального мира. В котором действительно нельзя покрасить стены до их возведения. В ИТ многие из ограничений реального мира снимаются. Отсюда, думаю, и растут все современные тенденции вроде agile development и т.п.
Так в том то и дело, что отчетность я хочу видеть предельно простой: в конце дня открыл форму, выбрал задачу из списка, внес, сколько сегодня на нее потратил часов, поправил remaining при необходимости. Именно с целью избежать «отбирает кучу времени впустую, на заполнение тупой отчётности по которой уходит больше времени, чем на саму работу».
Подумалось — а вдруг чудо возможно, и, установив брейкпоинт внутри «int memento()», удастся увидеть стек вызовов? При этом указывающий на причину, конечно же. Попробовал — увы, нет :( Стек-то виден, но — бесполезный, «fall()» в нем не упоминается даже.
Возможно ли решение в принципе?
Правда, иногда все же новые языки удаются, хоть тот же Python взять :)
Безусловно, для проекта человек в 100 мое упрощение уже не сработает. Но и противоположное, мне кажется, будет верно — система, оптимальная для управления проектом из 100 человек, не будет лучшим выбором для управления проектом, где работают только двое.
Для множества небольших проектов, в которых задачи достаточно хорошо разделяемы, их порядок выполнения не является чем-то предопределенным и уж тем более чем-то жестко заданным. А если даже и требуется определенный порядок, то он часто является очевидным и не требует явного прописывания — предполагается, что имея две связанные друг с другом задачи, разработчик сам выберет правильный порядок их выполнения.
Диаграмма Ганта (да и много из управления качеством) пришли в ИТ из материального мира. В котором действительно нельзя покрасить стены до их возведения. В ИТ многие из ограничений реального мира снимаются. Отсюда, думаю, и растут все современные тенденции вроде agile development и т.п.