0023762: Way of getting normals from Poly_Triangulation is inconvenient

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0023762

Open CASCADE

[OCCT] OCCT:Foundation Classes

public

2013-02-14 10:59

2020-09-11 16:13

Reporter

san

Assigned To

abv

Priority

normal

Severity

tweak

Status

new

Resolution

open

Platform

OS Version

Product Version

[OCCT] 6.5.4

Target Version

[OCCT] 7.6.0*

Fixed in Version

Summary

0023762: Way of getting normals from Poly_Triangulation is inconvenient

Description

The 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.

Tags

No tags attached.

Test case number

Attached Files

Relationships

related to

0025936

assigned

Open CASCADE

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*