COMP: Remove circular include dependency

[hjmjohnson]

Reduce the number of files that need to be read by the pre-processor and remove the circular include dependancies.

The itkExceptionObject.h file was allowed to be included only by itkMacro.h which always included the file.

Moving the contents of itkExceptionObject.h to
itkMacro.h simplifies the dependency complexity.

itk::ExceptionObject is different from other classes because it depends on macros at the top of itkMacro.h for it's definition, but also is needed for many macros at the bottom of itkMacro.h.

ITK/Modules/Core/Common/include/itkExceptionObject.h:22:12: warning: circular header file dependency detected while including 'itkMacro.h', please check the include path [misc-header-include-cycle]
22 | # include "itkMacro.h"
| ^

PR Checklist

• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)

[blowekamp]

I think smashing the file into Macro.h will make it less manageable. The circular dependency had been addresses with preprocessor commands. I am not clear what issue this is trying to address. What effect will it have on Doxygen documentation?

[hjmjohnson]

@blowekamp I respectfully disagree. I have fought with those header guards and managed the convoluted circular many times. They break static analysis tools that just give up when the circular dependency is encountered. IDE's can fail to identify the circular inclusions, or how to handle them.

It's probably not much of a speed increase, but it requires 3 file reads by the pre-processor rather than 1. (for every object file compilation that uses itkMacro.h).

To me this is the better choice.

[hjmjohnson]

@blowekamp I will try a different approach, but I think it will likely not work out.

[blowekamp]

I have fought with those header guards and managed the convoluted circular many times. They break static analysis tools that just give up when the circular dependency is encountered. IDE's can fail to identify the circular inclusions, or how to handle them.

OK, those seem like reasonable reasons. Performance... not so much :)

But I think there are alternatives. Although I am not sure how the static analysis tools behave.

Perhaps the Macro.h include can be removed from itkExceptionObject, since it is already guarded to ensure itkMacro.h is included? Or add a ifndef itkMacro_h around it.

The macro them selves in itkMacro.h don't require a declaration of ExceptionObject, but I the template function itkDynamicCastInDebugMode does. Perhaps template functions should go some place else? This one could be hacked to the end of itkExceptionObject.h ( so creating another itkTemplateFunctions.h may impact performance 🤣 )?

Perhaps a forward declaration of "itk::ExceptionObject" and a function "ExeceptionObject MakeExceptionObject(Args&&... args)" could be done?

I hacked #1 and #2 in the following patch. I'd would have made a PR to share but don't want to burden the CI.

blowekamp/ITK@354d67e

[blowekamp]

@blowekamp I will try a different approach, but I think it will likely not work out.

I just did. Please see above and give it a try with your tools.

[dzenanz]

Looks reasonable to me.

[dzenanz]

blowekamp@354d67e

This could still have circular dependency, if someone includes itkExceptionObject.h instead of itkMacro.

[hjmjohnson]

@blowekamp Your solution was what I thought about last night! I've take your patch and modified to remove the circular dependency.

I think the old code was overly complicated because:

1. the include was in the middle of the itkMacro.h file
2. the header guards tried to use itkExceptionMacro_h for 2 purposes (header guard and include control.

The current patch builds on macos-14 with python turned on. It builds without errors, and it removes circular dependencies.

[blowekamp]

Thanks for taking a second stab the improvement.