MantisBT
Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0029828Open CASCADE[OCCT] OCCT:Codingpublic2018-05-31 10:542018-06-03 11:45
Reporterkgv 
Assigned Tokgv 
PrioritynormalSeverityintegration request 
StatusfeedbackResolutionopen 
PlatformOSOS Version
Product Version 
Target Version[OCCT] 7.4.0*Fixed in Version 
Summary0029828: Coding Rules - specify preferred style for declaring OCCT RTTI elements in class definition
DescriptionCurrently, 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.
TagsNo tags attached.
Test case number
Attached Files

- Relationships
related to 0029814verifiedbugmaster Modeling Data - add method TopoDS_Shape::NbChildren() for simple check of sub-shapes number 

-  Notes
(0076474)
git (administrator)
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 (developer)
2018-05-31 12:11

Patch is ready for review.
(0076552)
git (administrator)
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 (manager)
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 (developer)
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).

- Issue History
Date Modified Username Field Change
2018-05-31 10:54 kgv New Issue
2018-05-31 10:54 kgv Assigned To => kgv
2018-05-31 11:50 kgv Description Updated View Revisions
2018-05-31 12:10 git Note Added: 0076474
2018-05-31 12:11 kgv Note Added: 0076475
2018-05-31 12:11 kgv Assigned To kgv => abv
2018-05-31 12:11 kgv Status new => resolved
2018-05-31 12:11 kgv Relationship added related to 0029814
2018-06-03 11:22 git Note Added: 0076552
2018-06-03 11:27 abv Note Added: 0076553
2018-06-03 11:27 abv Assigned To abv => kgv
2018-06-03 11:27 abv Status resolved => feedback
2018-06-03 11:28 abv Note Edited: 0076553 View Revisions
2018-06-03 11:45 kgv Note Added: 0076554


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker