Как вернуть дополнительную информацию об отладке из метода?

Question

Допустим, у меня есть статический метод, который сравнивает два объекта для близкого соответствия и возвращает некоторый уровень достоверности [0,1].

class Foo 
{ 
    ... 
    static double Compare(const Foo& foo1, const Foo& foo2); 
    ... 
}; 

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

Я вижу, по крайней мере, три варианта:

1: Создать дополнительный CompareResult класса и хранить уверенность + опциональную информацию там. Не заполняйте дополнительную информацию, если вам это не нужно.

class CompareResult 
{ 
    ... 
private: 
    double confidence_; 
    CompareOptionalInfo compare_optional_info_; 
    ... 
}; 

... 

static CompareResult Compare(const Foo& foo1, const Foo& foo2); 

Это, кажется, самый чистый, но я не уверен, что я должен объединить результат возврата с дополнительной информацией.

2: Используйте выходной переменной (таким образом, нам не нужно, чтобы создать дополнительный класс, но наш метод подписи будет расти немного)

static double Compare(const Foo& foo1, const Foo& foo2, CompareOptionalInfo* out_compare_info = nullptr); 

3: Отдельный метод сравнения с опциональным-инфо метода извлечения ,

static double Compare(const Foo& foo1, const Foo& foo2); 
static CompareOptionalInfo GetCompareOptionalInfo(); 

Этот вариант был бы, вероятно, потребуется для хранения этого необязательного-инфо между вызовами методов и переход от статического сравнения метод экземпляра сравнить метод. Но опять же, я не уверен, что это уместно или нет.

Из вашего опыта, что подходит в мире ООП для возврата необязательной информации (которая будет в основном использоваться только в режиме отладки) из метода?

Answer 1

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

Примеры проблем:

double closest = std::max (Foo::compare (x, y), Foo::compare (y,z)); 
clog << Foo::GetCompareOptionalInfo(); // undefined which info since order of eval 
             // of function parameter is not guaranteed 

double d = Foo::compare (x, y); 
DoSomething();     // what if this one does an unexpected compare ? 
clog << Foo::GetCompareOptionalInfo(); 

---

Вариант 2 является жизнеспособным решением, но это не очень удобно: он заставляет вас создавать объекты информации, передать их по адресу и т.д.:

Foo::OptionalCompareInfo o1,o2; // cumbersome 
double closest = std::max (Foo::compare (x, y, &o1), Foo::compare (y,z, &o2)); 

Кроме того, вы должны создать эту дополнительную информацию и передать дополнительный аргумент в процессе производства, даже если вы больше не обновляете информацию там (если вы не ставите много дополнительных условных компиляций)!

---

Вариант 1 отлично! Действуй ! Это действительно использует парадигму ООП и использует чистый дизайн. Практически использовать и не налагать ограничений на свой код, чтобы использовать его.

Все, что вам нужно, чтобы обеспечить некоторую (неявный) функцию преобразования, чтобы использовать свой CompareResult почти как если бы это было double:

class CompareResult 
{ 
public: 
    CompareResult(double d=0.0) : confidence_(d) {}; 
    operator double() { return confidence_; } 
    operator bool() { return confidence_>0.5; } 
private: 
    double confidence_; 
    CompareOptionalInfo compare_optional_info_; 
}; 

online demo

Ваш код продукции будет не зависит от информации отладки , И вы могли бы в вашей отладки ВСЕГДА проследить объяснение того или иного результата сравнения, по крайней мере, если вы храните его:

Пример:

auto result = Foo::compare (x, y) 
if (result) ... // uses automatically the conversion 

auto closest = std::max (Foo::compare (x, y), Foo::compare (y,z)); 
// here you not only know the closest match but could explain it ! 

vector<CompareResult> v; 
... // populate the vector with 10 000 comparison results 
auto r = std::max_element(v.begin(), v.end()); 
    // you could still explain the compare info for the largest value 
    // if you're interested in the details of this single value 
    // how would you do this with option 3 or option 2 ?  

Ok, для самого последнего на работу вы бы также нужен оператор сравнения для вашего дополнительного класса. Но это одна строка кода больше (см. Онлайн-демонстрацию) ;-)

Наконец, может получиться, что ваша «дополнительная информация об отладке» может оказаться более полезной, чем ожидалось, например, чтобы предоставить пользователю дополнительные пояснения по требованию. Все, что вам нужно сделать, - это удалить условный #ifdef DEBUG, окружающий вычисление дополнительной информации.

Answer 2

Я бы использовал второй вариант для его совместимости с отладчиками.

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

class Foo 
{ 
    private: 
#ifndef NDEBUG 
    CompareOptionalInfo debug_out_compare_info_; 
#endif 

    ... 
    static double Compare(const Foo& foo1, const Foo& foo2, 
     CompareOptionalInfo* out_compare_info = nullptr); 
    ... 
}; 

#ifndef NDEBUG 
CompareOptionalInfo Foo::debug_out_compare_info_; 
#endif 

В БГД, в любой точке останова, вы можете использовать:

call Foo::Compare(foo1, foo2, &Foo::debug_out_compare_info_); 
print Foo::debug_out_compare_info_. ...