MantisBT
Mantis Bug Tracker Workflow
My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0023762Open CASCADE[OCCT] OCCT:Foundation Classespublic2013-02-14 10:592020-12-14 12:51
Reportersan 
Assigned Toabv 
PrioritynormalSeveritytweak 
StatusnewResolutionopen 
PlatformAOSLOS VersionL
Product Version[OCCT] 6.5.4 
Target Version[OCCT] 7.6.0*Fixed in Version 
Summary0023762: Way of getting normals from Poly_Triangulation is inconvenient
DescriptionThe current implementation of Poly_Triangulation::Normals() looks heavy and inconvenient:
const TShort_Array1OfShortReal& Poly_Triangulation::Normals() const
{

  if(myNormals.IsNull() || myNormals->Length() != 3*myNbNodes) {
    Standard_NullObject::Raise("Poly_Triangulation::Normals : "
                               "wrong length or null array");
  }

  return myNormals->Array1();
}


1. Why return a const reference to the internal array instead of returning myNormals directly?
2. Throwing an exception in case if normals data is not available requires special tricks or code duplication in order to write the conditional code that works both when normals are present and when they are not.
3. What is the purpose of Poly_Triangulation::ChangeNormals()? Why provide access to internal array of myNormals instead of simply returning myNormals itself and letting the applications decide what to do with it?

It is proposed to return myNormals in Poly_Trinagulation::Normals() and remove consistency checks leaving them to the applications that can e.g. use Poly_Triangulation::HasNormals() for this purpose. Poly_Trinagulation::ChangeNormals() is most likely to be removed, too. Normals() and SetNormals() methods seem sufficient.

TagsNo tags attached.
Test case number
Attached Files

- Relationships
related to 0025936assignedkgv Open CASCADE Modeling Data - reusable data structure for 2D tesselation (3- and 4-nodal mesh) 

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2013-02-14 10:59 san New Issue
2013-02-14 10:59 san Assigned To => abv
2013-02-14 10:59 san Relationship added related to 0023743
2014-09-12 14:43 abv Target Version => 7.1.0
2016-11-01 06:41 abv Target Version 7.1.0 => 7.2.0
2016-11-01 10:14 kgv Relationship added related to 0025936
2017-07-10 10:24 kgv Relationship added related to 0026007
2017-07-27 11:17 abv Target Version 7.2.0 => 7.4.0
2019-07-10 22:29 abv Target Version 7.4.0 => 7.5.0
2020-09-11 16:13 utverdov Target Version 7.5.0 => 7.6.0*
2020-12-14 12:51 kgv Description Updated View Revisions

Copyright © 2000 - 2021 MantisBT Team
Powered by Mantis Bugtracker