Конструктор и лог

[m_ax]

При чём здесь спагетти в коде при парсинге кода? Нам дано, что дано и все варианты нужно отработать.

Ну как причём:

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

Ладно, забейте)
Сегодня всё-таки праздник 

[Igors]

Слишком, слишком сложно.
Ведь это не основной код, вспомогательный.

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

Агаг. Проблема начинает вылазить, когда нам нужно решать, в какой класс записывать лог, в какой нет.
Т.е. именно проблема в наследовании и проявляется. При создании класса (далее я под созданием класса имею в виду создание объекта класса) выводить нам нужно имя базового класса? Нет конечно.

А почему это нет? С какой стати это скрывать? Не вижу для этого никаких оснований, лог должен содержать полную инфу

А вот интересно как определить логируемый класс или нет - учитывая что он может наследоваться от логируемого? Сходу не сообразю, m_ax, как там с "магией"? 

[AzazelloAV]

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

Этот вариант я и принял.

Агаг. Проблема начинает вылазить, когда нам нужно решать, в какой класс записывать лог, в какой нет.
Т.е. именно проблема в наследовании и проявляется. При создании класса (далее я под созданием класса имею в виду создание объекта класса) выводить нам нужно имя базового класса? Нет конечно.

А почему это нет? С какой стати это скрывать? Не вижу для этого никаких оснований, лог должен содержать полную инфу

Потому что не будет разницы, между наследованием и вызовов класса.
Я уже об этом писал выше. Повторюсь - "Enter  to class Name1" и "Enter to class Name2".
Вопрос - класс Name1 вызван наследуюемым конструктором (Name2) или класс Name1 вызвал Name2?

А вот интересно как определить логируемый класс или нет - учитывая что он может наследоваться от логируемого? Сходу не сообразю, m_ax, как там с "магией"?  
[/quote]

[m_ax]

А вот интересно как определить логируемый класс или нет - учитывая что он может наследоваться от логируемого? Сходу не сообразю, m_ax, как там с "магией"?

Ну я бы курил в сторону SFINE http://habrahabr.ru/post/205772/

[AzazelloAV]

А вот интересно как определить логируемый класс или нет - учитывая что он может наследоваться от логируемого? Сходу не сообразю, m_ax, как там с "магией"?

Ну я бы курил в сторону SFINE http://habrahabr.ru/post/205772/

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

[m_ax]

Вместо одной проблемы создаются десяток других.

Ну дык я и не вам это предлагаю)

[Igors]

Потому что не будет разницы, между наследованием и вызовов класса.
Я уже об этом писал выше. Повторюсь - "Enter  to class Name1" и "Enter to class Name2".
Вопрос - класс Name1 вызван наследуюемым конструктором (Name2) или класс Name1 вызвал Name2?

По правилам языка нельзя обойти конструктор базового класса, поэтому последовательность Name1, Name2 всегда означает конструктор Name2.

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

Ну а нервничать зачем? Ах, не оказалось быстрого, удобного решения (как из ассыстента), расстроился  Так это нормально. А задумка совсем неплохая. Вот только как бы ее "расширить". Печать в конструкторе (кстати почему и не в деструкторе тоже?) - ну иногда полезна, но может и засыпать консоль (если будут контейнеры). Есть смысл печатать (по запросу) число "живых" объектов такого-то типа, отслеживая порядковый номер и.т.д. Ну да ладно, не хотите обсуждать - не надо.

[AzazelloAV]

По правилам языка нельзя обойти конструктор базового класса, поэтому последовательность Name1, Name2 всегда означает конструктор Name2.

Нельзя, но это не будет обозначать, что это наследуемый вызов. Это может быть вызов конструктора из конструктора (не наследуемого, а new что-то новое), что введёт в заблуждение при исследовании лога. Тут только один выход - промежуточные (базовые) классы не должны ничего выводить, что уже определенныё на нас ограничения накладывает - нельзя использовать непосредственно базовый класс, все вызывающие классы должны быть "листьями дерева".

Ну а нервничать зачем? Ах, не оказалось быстрого, удобного решения (как из ассыстента), расстроился   Так это нормально. А задумка совсем неплохая. Вот только как бы ее "расширить". Печать в конструкторе (кстати почему и не в деструкторе тоже?) - ну иногда полезна, но может и засыпать консоль (если будут контейнеры). Есть смысл печатать (по запросу) число "живых" объектов такого-то типа, отслеживая порядковый номер и.т.д. Ну да ладно, не хотите обсуждать - не надо.

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

Нет, я хочу обсуждать, почему, просто был в отпуске, вот и всё.

Также про оверхед Q_OBJECT (спрашивали выше) - нету тут оверхеда, потому как есть логи, которые могут анализировать пользователи, а есть логи, которые только для дебага. Поэтому наследование от QObject + макрос Q_OBJECT как оверхед для дебажной версии (пусть хоть в 10 раз) меня не очень беспокоит.

Есть смысл печатать (по запросу) число "живых" объектов такого-то типа, отслеживая порядковый номер и.т.д. Ну да ладно, не хотите обсуждать - не надо.

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

Также хочу отбросить инсинуации "тут что-то не так и ты не правильно проектируешь классы". Это синтаксический разбор файла, и иерархия классов (наследование), и иерархия объектов (принадлежность) может быть какой угодной и пересекаться по сотни раз с друг другом во всех случаях.

Для меня лично выход из этой ситуации (если использовать системный подход) - это Q_OBJECT, где мы можем наворотить что угодно - и про забывчивость и все остальное. Но пока очень лениво, может когда будет уровень ошибки такой, что займусь этой задачей. Пока не буду распыляться. Тем более, чтобы сделать это решение универсальным, для будущих решений, нужно потратить не мало времени (ну неделю точно с тестированием всяким), чего не хочется. Только не говорите, что неделя много.