-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DOC: Adjust initialization rule for padding data, smart pointers, etc. #192
DOC: Adjust initialization rule for padding data, smart pointers, etc. #192
Conversation
Looks like the following part is incorrect, and should be removed, right? ITKSoftwareGuide/SoftwareGuide/Latex/Appendices/CodingStyleGuide.tex Lines 1624 to 1635 in 905c9bb
Even when a constructor would call |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay.
initialization through the corresponding \code{Set##name} or
\code{##nameOn}/\code{##nameOff} method is recommended instead of directly
manipulating the data member.
Yes, not sure which were the reasons for this. There were probably some that were discussed in a PR when some issue was discovered.
Even when a constructor would call Set##name for some of its data members, it should still "directly manipulate" those data member as well, by initializing each of them before calling the Set member function. As @jhlegarreta proposes with InsightSoftwareConsortium/ITK#3845
As surfaced by InsightSoftwareConsortium/ITK#3845 (comment), there maybe (especialized/exceptional) cases where grouping some initializations may be wise: e.g. in cases where a group of variables may be (re-)initialized by calling an Initialize
-like method (regardless of whether the method is private/protected/public). So I am unsure of how we should put this.
Not really sure how to continue with this PR now. First of all, it has a build error. Any suggestion how to fix it? Secondly, shall I basically keep it as it is now? Or further extend it to include a new paragraph about data members of a smart pointer type? And then, shall I remove the old section about I'm asking especially because it appears hard for me to get PRs merged into ITKSoftwareGuide, either because of build errors or ongoing discussions. |
Retriggering the build may fix the failures; successful builds also report warnings similar to those reported until the build was stopped: As for going forward, Dženan has approved so if he/others are comfortable with the edition, then I do not want my comments to prevent this from being merged. |
🤷 No idea why the build fails. Do not see any cue in the logs. |
Maybe this has to do with it: the line needs to be wrapped at 79 chars, and the proposed addition has a line length of 99 or 100. |
9df1974
to
992149c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Dismissing stale reviews is not rude, it is rather normal. At least in my opinion. |
@N-Dekker Could you please rebase on |
992149c
to
a4ee812
Compare
a4ee812
to
c8120a5
Compare
c8120a5
to
7ce934a
Compare
7ce934a
to
42a53a1
Compare
Excluded padding data, `std::unique_ptr`, `itk::SmartPointer` and low level utility classes from the guideline that says that "all member variables must be initialized when they are declared". `std::unique_ptr` and `itk::SmartPointer` are excluded because of some GCC compile errors, which were addressed in ITK by Simon Rit: - pull request InsightSoftwareConsortium/ITK#3877 commit InsightSoftwareConsortium/ITK@eac289d "COMP: Remove in-class {} member initializers of unique_ptr" - pull request InsightSoftwareConsortium/ITK#3927 commit InsightSoftwareConsortium/ITK@f5f8367 "COMP: Remove in class init of SmartPointer of forward declaration"
42a53a1
to
6d5f5b5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for documenting this!
Excluded padding data,
std::unique_ptr
,itk::SmartPointer
and low levelutility classes from the guideline that says that "all member variables must be
initialized when they are declared".
std::unique_ptr
anditk::SmartPointer
are excluded because of some GCCcompile errors, which were addressed in ITK by Simon Rit (@SimonRit):
commit InsightSoftwareConsortium/ITK@eac289d
"COMP: Remove in-class {} member initializers of unique_ptr"
commit InsightSoftwareConsortium/ITK@f5f8367
"COMP: Remove in class init of SmartPointer of forward declaration"