MantisBT - Open CASCADE
View Issue Details
0029828Open CASCADE[OCCT] OCCT:Codingpublic2018-05-31 10:542019-09-04 18:37
kgv 
kgv 
normalintegration request 
feedbackopen 
 
[OCCT] 7.5.0* 
0029828: Coding Rules - specify preferred style for declaring OCCT RTTI elements in class definition
Currently, different OCCT classes follow different style while declaring RTTI elements like DEFINE_STANDARD_RTTIEXT, DEFINE_STANDARD_HANDLE, DEFINE_STANDARD_ALLOC and the list of friend classes.

Most headers have been generated from CDL files by WOK in past and inherits multiple ugliness (like empty "protected: " sections) and obsolete elements (like DEFINE_STANDARD_HANDLE at the beginning of the file with redundant forward declared class; DEFINE_STANDARD_RTTIEXT put in the middle of class methods), while C++ headers created without CDL legacy (before/after WOK removal) follow different style.

It is desired determining the common style for these elements to avoid confusion.
No tags attached.
related to 0029814closed bugmaster Modeling Data - add method TopoDS_Shape::NbChildren() for simple check of sub-shapes number 
Issue History
2018-05-31 10:54kgvNew Issue
2018-05-31 10:54kgvAssigned To => kgv
2018-05-31 11:50kgvDescription Updatedbug_revision_view_page.php?rev_id=19198#r19198
2018-05-31 12:10gitNote Added: 0076474
2018-05-31 12:11kgvNote Added: 0076475
2018-05-31 12:11kgvAssigned Tokgv => abv
2018-05-31 12:11kgvStatusnew => resolved
2018-05-31 12:11kgvRelationship addedrelated to 0029814
2018-06-03 11:22gitNote Added: 0076552
2018-06-03 11:27abvNote Added: 0076553
2018-06-03 11:27abvAssigned Toabv => kgv
2018-06-03 11:27abvStatusresolved => feedback
2018-06-03 11:28abvNote Edited: 0076553bug_revision_view_page.php?bugnote_id=76553#r19215
2018-06-03 11:45kgvNote Added: 0076554
2019-09-04 18:37kgvTarget Version7.4.0 => 7.5.0*

Notes
(0076474)
git   
2018-05-31 12:10   
Branch CR29828 has been created by kgv.

SHA-1: 9a02338d89337eea683cedc5d68cfa968057b171


Detailed log of new commits:

Author: kgv
Date: Thu May 31 12:10:44 2018 +0300

    0029828: Coding Rules - specify preferred style for declaring OCCT RTTI elements in class definition
    
    Coding Rules has been extended with a section declaring a preferred style
    for OCCT RTTI element (DEFINE_STANDARD_RTTIEXT, DEFINE_STANDARD_HANDLE, DEFINE_STANDARD_ALLOC)
    in class definition.
(0076475)
kgv   
2018-05-31 12:11   
Patch is ready for review.
(0076552)
git   
2018-06-03 11:22   
Branch CR29828_1 has been created by abv.

SHA-1: 7cfa08c9a84c00f569691a4be842eebe6c489586


Detailed log of new commits:

Author: kgv
Date: Thu May 31 12:10:44 2018 +0300

    0029828: Coding Rules - specify preferred style for declaring OCCT RTTI elements in class definition
    
    Coding Rules has been extended with a section describing a preferred style for use of standard OCCT macros.
(0076553)
abv   
2018-06-03 11:27   
(edited on: 2018-06-03 11:28)
I have made some changes, please have a look:
- Description of friend declaration and inline modifier are put to separate sections as they have nothing to do with RTTI macros
- New statement on use of override for virtual methods is removed (it is already present in this document)
- Mention on inexistent macro Standard_LOCAL is removed as irrelevant
- The text is revised

With that, I do not agree on approach to put declerations such as RTTI definitions to the beginning of the class definition. For the user of the class, it is more important to see public API of the class, and this should come first. Such things like friend declarations, RTTI macros etc. are implementation details that can be better placed at the end. Let's discuss that.

(0076554)
kgv   
2018-06-03 11:45   
> With that, I do not agree on approach to put declerations such as RTTI
> definitions to the beginning of the class definition.
> For the user of the class, it is more important to see public API of the class,
> and this should come first.
> Such things like friend declarations, RTTI macros etc.
> are implementation details that can be better placed at the end.
The relations of the class (parent class) is defined at the very beginning of
class declaration (e.g. "class AClass : public Standard_Transient");
therefore, it looks natural to me that this relation as well as other
relations (list of friend classes publicly available to user)
could be put near by - hence, at the beginning of the class.

I do not agree that friend class information should be buried inside class properties - friends are very dangerous things in class definition, which should be clearly seen (as they may break/limit sub-classing on application level, due to these protected relations between OCCT classes).