0024816: Tool for upgrading OCCT and dependent code
authorabv <abv@opencascade.com>
Wed, 19 Aug 2015 15:51:52 +0000 (18:51 +0300)
committerabv <abv@opencascade.com>
Wed, 19 Aug 2015 16:03:16 +0000 (19:03 +0300)
A new script adm/upgrade.tcl defines a Tcl procedure occt_upgrade, to be used for upgrading code of OCCT and applications for changes introduced by OCCT 7.0.
Batch script upgrade.bat is provided for convenience.
File upgrade.dat contains data (lists of classes) required for some upgrade steps.
Details on upgrade procedure are put in dox/dev_guides/upgrade/upgrade.md.

OCCT code corrected to improve compatibility with code based on previous versions of OCCT:
- Added conversion operator of handle to bool, for use in conditional expressions.
- Forward declaration of argument class restored in macro DEFINE_STANDARD_HANDLE.
- Includes of used classes added in some headers to avoid problem of missing includes in dependent code
- Type cast operators to base curve and surface added in GC and GCE2d classes to reduce porting issues.

Added test for local reference to handle initialized by temporary handle to derived class.

WOK and CDL User Guides removed.

84 files changed:
.gitattributes
.gitignore
adm/genconf.tcl
adm/genconfdeps.tcl
adm/gendoc.tcl
adm/genproj.tcl
adm/occaux.tcl
adm/start.tcl
adm/upgrade.dat [new file with mode: 0644]
adm/upgrade.tcl [new file with mode: 0644]
dox/FILES_HTML.txt
dox/FILES_PDF.txt
dox/dev_guides/cdl/cdl.md [deleted file]
dox/dev_guides/cdl/images/cdl_image003.png [deleted file]
dox/dev_guides/cdl/images/cdl_image004.png [deleted file]
dox/dev_guides/cdl/images/cdl_image005.png [deleted file]
dox/dev_guides/cdl/images/cdl_image006.png [deleted file]
dox/dev_guides/cdl/images/cdl_image007.png [deleted file]
dox/dev_guides/cdl/images/cdl_image008.png [deleted file]
dox/dev_guides/cdl/images/cdl_image009.png [deleted file]
dox/dev_guides/cdl/images/cdl_image010.png [deleted file]
dox/dev_guides/cdl/images/cdl_image011.png [deleted file]
dox/dev_guides/cdl/images/cdl_image012.png [deleted file]
dox/dev_guides/dev_guides.md
dox/dev_guides/upgrade/upgrade.md
dox/dev_guides/wok/images/wok_image005.jpg [deleted file]
dox/dev_guides/wok/images/wok_image005.png [deleted file]
dox/dev_guides/wok/images/wok_image006.png [deleted file]
dox/dev_guides/wok/images/wok_image007.png [deleted file]
dox/dev_guides/wok/images/wok_image008.png [deleted file]
dox/dev_guides/wok/images/wok_image009.png [deleted file]
dox/dev_guides/wok/images/wok_image010.png [deleted file]
dox/dev_guides/wok/images/wok_image011.png [deleted file]
dox/dev_guides/wok/images/wok_image012.png [deleted file]
dox/dev_guides/wok/images/wok_image013.png [deleted file]
dox/dev_guides/wok/images/wok_image014.png [deleted file]
dox/dev_guides/wok/images/wok_image015.png [deleted file]
dox/dev_guides/wok/images/wok_image016.png [deleted file]
dox/dev_guides/wok/images/wok_image017.png [deleted file]
dox/dev_guides/wok/images/wok_image018.png [deleted file]
dox/dev_guides/wok/images/wok_image019.png [deleted file]
dox/dev_guides/wok/images/wok_image020.png [deleted file]
dox/dev_guides/wok/images/wok_image021.png [deleted file]
dox/dev_guides/wok/images/wok_image022.png [deleted file]
dox/dev_guides/wok/wok.md [deleted file]
gendoc.bat
genproj.bat
src/Adaptor2d/Adaptor2d_HCurve2d.hxx
src/Approx/Approx_Curve2d.hxx
src/Approx/Approx_Curve3d.hxx
src/BRep/BRep_Tool.hxx
src/GC/GC_MakeArcOfCircle.hxx
src/GC/GC_MakeArcOfEllipse.hxx
src/GC/GC_MakeArcOfHyperbola.hxx
src/GC/GC_MakeArcOfParabola.hxx
src/GC/GC_MakeCircle.hxx
src/GC/GC_MakeConicalSurface.hxx
src/GC/GC_MakeCylindricalSurface.hxx
src/GC/GC_MakeEllipse.hxx
src/GC/GC_MakeHyperbola.hxx
src/GC/GC_MakeLine.hxx
src/GC/GC_MakePlane.hxx
src/GC/GC_MakeSegment.hxx
src/GC/GC_MakeTrimmedCone.hxx
src/GC/GC_MakeTrimmedCylinder.hxx
src/GCE2d/GCE2d_MakeArcOfCircle.hxx
src/GCE2d/GCE2d_MakeArcOfEllipse.hxx
src/GCE2d/GCE2d_MakeArcOfHyperbola.hxx
src/GCE2d/GCE2d_MakeArcOfParabola.hxx
src/GCE2d/GCE2d_MakeCircle.hxx
src/GCE2d/GCE2d_MakeEllipse.hxx
src/GCE2d/GCE2d_MakeHyperbola.hxx
src/GCE2d/GCE2d_MakeLine.hxx
src/GCE2d/GCE2d_MakeParabola.hxx
src/GCE2d/GCE2d_MakeSegment.hxx
src/Geom2dHatch/Geom2dHatch_Hatcher.hxx
src/GeomAPI/GeomAPI_Interpolate.hxx
src/IGESData/IGESData_IGESWriter.hxx
src/QANCollection/QANCollection_Handle.cxx
src/ShapeFix/ShapeFix_Shell.hxx
src/Standard/Standard.hxx
src/Standard/Standard_Handle.hxx
tests/perf/fclasses/handle
upgrade.bat [new file with mode: 0644]

index 3592683..db61c81 100644 (file)
@@ -44,6 +44,7 @@ UDLIST      eol=lf
 tests/*     eol=lf
 tests/*/*   eol=lf
 tests/*/*/* eol=lf
+adm/upgrade.dat eol=lf
 *.bat       eol=crlf
 *.cmd       eol=crlf
 *.rc        eol=crlf
index 4964a0f..c2da7e3 100644 (file)
@@ -29,6 +29,7 @@ Release
 /adm/mac
 /adm/make
 *.vcproj*user
+*.vcxproj*user
 *.csproj*user
 *.ncb
 *.suo
index 7293ab6..26f9201 100644 (file)
@@ -1,8 +1,30 @@
 #!/usr/bin/tclsh
 
-package require Tk
+# =======================================================================
+# Created on: 2012-01-26
+# Created by: Kirill GAVRILOV
+# Copyright (c) 2012 OPEN CASCADE SAS
+#
+# This file is part of Open CASCADE Technology software library.
+#
+# This library is free software; you can redistribute it and/or modify it under
+# the terms of the GNU Lesser General Public License version 2.1 as published
+# by the Free Software Foundation, with special exception defined in the file
+# OCCT_LGPL_EXCEPTION.txt. Consult the file LICENSE_LGPL_21.txt included in OCCT
+# distribution for complete text of the license and disclaimer of any warranty.
+#
+# Alternatively, this file may be used under the terms of Open CASCADE
+# commercial license or contractual agreement.
 
-source "./adm/genconfdeps.tcl"
+# =======================================================================
+# GUI procedure for search of third-party tools and generation of environment
+# customization script
+# =======================================================================
+
+# load tools
+source [file join [file dirname [info script]] genconfdeps.tcl]
+
+package require Tk
 
 set aRowIter 0
 frame .myFrame -padx 5 -pady 5
index 2263a29..602426d 100644 (file)
@@ -1,4 +1,23 @@
-#!/usr/bin/tclsh
+# =======================================================================
+# Created on: 2012-01-26
+# Created by: Kirill GAVRILOV
+# Copyright (c) 2012 OPEN CASCADE SAS
+#
+# This file is part of Open CASCADE Technology software library.
+#
+# This library is free software; you can redistribute it and/or modify it under
+# the terms of the GNU Lesser General Public License version 2.1 as published
+# by the Free Software Foundation, with special exception defined in the file
+# OCCT_LGPL_EXCEPTION.txt. Consult the file LICENSE_LGPL_21.txt included in OCCT
+# distribution for complete text of the license and disclaimer of any warranty.
+#
+# Alternatively, this file may be used under the terms of Open CASCADE
+# commercial license or contractual agreement.
+
+# =======================================================================
+# Tools for search of third-party libraries and generation on environment
+# customization script
+# =======================================================================
 
 set ARCH "64"
 
index ec44d44..a9c2e56 100644 (file)
 #
 # Alternatively, this file may be used under the terms of Open CASCADE
 # commercial license or contractual agreement.
-# 
-# Brief:  This script compiles OCCT documents from *.md files to HTML pages
+# =======================================================================
+# This script defines command gendoc compiling OCCT documents 
+# from *.md files to HTML pages
 # =======================================================================
 
+# load auxiliary tools
+source [file join [file dirname [info script]] occaux.tcl]
+
 # ======================================
 #  Common functions
 # ======================================
index 7257976..e767c87 100644 (file)
@@ -1,12 +1,31 @@
 # =======================================================================
-# This script generates project files for different IDEs:
-#      "vc7" "vc8" "vc9" "vc10" "vc11" "vc12" "vc14" "cbp" "amk" "xcd"
+# Created on: 2014-07-24
+# Created by: SKI
+# Copyright (c) 2014 OPEN CASCADE SAS
+#
+# This file is part of Open CASCADE Technology software library.
+#
+# This library is free software; you can redistribute it and/or modify it under
+# the terms of the GNU Lesser General Public License version 2.1 as published
+# by the Free Software Foundation, with special exception defined in the file
+# OCCT_LGPL_EXCEPTION.txt. Consult the file LICENSE_LGPL_21.txt included in OCCT
+# distribution for complete text of the license and disclaimer of any warranty.
+#
+# Alternatively, this file may be used under the terms of Open CASCADE
+# commercial license or contractual agreement.
+
+# =======================================================================
+# This script defines Tcl command genproj generating project files for 
+# different IDEs: 
+# "vc7" "vc8" "vc9" "vc10" "vc11" "vc12" "vc14" "cbp" "amk" "xcd"
 #
 # Example:
 #      genproj -path=D:/occt -target=vc10
 #      genproj -target=xcd -ios -static
 # =======================================================================
 
+source [file join [file dirname [info script]] genconfdeps.tcl]
+
 set path ""
 set fBranch ""
 switch -exact -- "$tcl_platform(platform)" {
@@ -18,8 +37,6 @@ switch -exact -- "$tcl_platform(os)" {
   "Darwin"  {set targetStation "mac"}
 }
 
-source "./adm/genconfdeps.tcl"
-
 proc _get_options { platform type branch } {
   global path
   set res ""
@@ -3793,6 +3810,3 @@ proc osutils:xcdx { theOutDir theExecutable theGuidsMap } {
   puts $aPlistFile $aPlistTmpl
   close $aPlistFile
 }
-
-# launch generation
-genproj {*}$::argv
index ed3aaad..f8a13c6 100644 (file)
 #
 # Alternatively, this file may be used under the terms of Open CASCADE
 # commercial license or contractual agreement.
-# 
-# Brief: This script contains auxilary functions which can be used 
-#         in documentation generation process
+# =======================================================================
+# This script contains auxilary functions which can be used 
+# in documentation generation process
 # =======================================================================
 
 # ==============================================
index b9d4c70..9b16406 100644 (file)
@@ -1,8 +1,30 @@
 #!/usr/bin/tclsh
 
-# Command-line starter for occdoc command, use it as follows:
-# tclsh> source dox/start.tcl [arguments]
+# =======================================================================
+# Created on: 2014-03-21
+# Created by: OMY
+# Copyright (c) 1996-1999 Matra Datavision
+# Copyright (c) 1999-2014 OPEN CASCADE SAS
+#
+# This file is part of Open CASCADE Technology software library.
+#
+# This library is free software; you can redistribute it and/or modify it under
+# the terms of the GNU Lesser General Public License version 2.1 as published
+# by the Free Software Foundation, with special exception defined in the file
+# OCCT_LGPL_EXCEPTION.txt. Consult the file LICENSE_LGPL_21.txt included in OCCT
+# distribution for complete text of the license and disclaimer of any warranty.
+#
+# Alternatively, this file may be used under the terms of Open CASCADE
+# commercial license or contractual agreement.
+if { [llength $argv] < 1 } {
+  puts "Command-line starter for Tcl command defined in same-named file."
+  puts "Use it as follows:"
+  puts "\> tclsh start.tcl command \[arguments\]"
+  return
+}
 
-source [file join [file dirname [info script]] occaux.tcl]
-source [file join [file dirname [info script]] gendoc.tcl]
-gendoc {*}$::argv
+set cmdname [lindex $argv 0]
+source [file join [file dirname [info script]] $cmdname.tcl]
+
+eval $cmdname [lrange $argv 1 end]
diff --git a/adm/upgrade.dat b/adm/upgrade.dat
new file mode 100644 (file)
index 0000000..9687202
--- /dev/null
@@ -0,0 +1,924 @@
+[rename]
+BRepExtrema_OverlappedSubShapes BRepExtrema_MapOfIntegerPackedMapOfInteger
+
+[tcollection]
+AdvApp2Var_SequenceOfNode
+AdvApp2Var_SequenceOfPatch
+AdvApp2Var_SequenceOfStrip
+AdvApp2Var_Strip
+AIS_DataMapOfILC
+AIS_DataMapofIntegerListOfinteractive
+AIS_DataMapOfIOStatus
+AIS_DataMapOfSelStat
+AIS_IndexedDataMapOfOwnerPrs
+AIS_ListOfInteractive
+AIS_MapOfInteractive
+AIS_SequenceOfDimension
+AIS_SequenceOfInteractive
+AppDef_Array1OfMultiPointConstraint
+AppDef_HArray1OfMultiPointConstraint
+AppParCurves_Array1OfConstraintCouple
+AppParCurves_Array1OfMultiBSpCurve
+AppParCurves_Array1OfMultiCurve
+AppParCurves_Array1OfMultiPoint
+AppParCurves_HArray1OfConstraintCouple
+AppParCurves_HArray1OfMultiBSpCurve
+AppParCurves_HArray1OfMultiCurve
+AppParCurves_HArray1OfMultiPoint
+AppParCurves_SequenceOfMultiBSpCurve
+AppParCurves_SequenceOfMultiCurve
+Approx_Array1OfAdHSurface
+Approx_Array1OfGTrsf2d
+Approx_HArray1OfAdHSurface
+Approx_HArray1OfGTrsf2d
+Approx_SequenceOfHArray1OfReal
+Aspect_SequenceOfColor
+BinMDF_TypeADriverMap
+BinMDF_TypeIdMap
+BiTgte_DataMapOfShapeBox
+Blend_SequenceOfPoint
+Bnd_Array1OfBox
+Bnd_Array1OfBox2d
+Bnd_Array1OfSphere
+Bnd_HArray1OfBox
+Bnd_HArray1OfBox2d
+Bnd_HArray1OfSphere
+Bnd_SeqOfBox
+BRep_ListOfCurveRepresentation
+BRep_ListOfPointRepresentation
+BRepAdaptor_Array1OfCurve
+BRepAdaptor_HArray1OfCurve
+BRepAlgo_DataMapOfShapeBoolean
+BRepAlgo_DataMapOfShapeInterference
+BRepAlgo_SequenceOfSequenceOfInteger
+BRepBlend_SequenceOfLine
+BRepBlend_SequenceOfPointOnRst
+BRepCheck_DataMapOfShapeListOfStatus
+BRepCheck_DataMapOfShapeResult
+BRepCheck_ListOfStatus
+BRepClass3d_MapOfInter
+BRepFill_DataMapOfNodeDataMapOfShapeShape
+BRepFill_DataMapOfNodeShape
+BRepFill_DataMapOfOrientedShapeListOfShape
+BRepFill_DataMapOfShapeDataMapOfShapeListOfShape
+BRepFill_DataMapOfShapeHArray2OfShape
+BRepFill_DataMapOfShapeSequenceOfPnt
+BRepFill_DataMapOfShapeSequenceOfReal
+BRepFill_IndexedDataMapOfOrientedShapeListOfShape
+BRepFill_ListOfOffsetWire
+BRepFill_SequenceOfEdgeFaceAndOrder
+BRepFill_SequenceOfFaceAndOrder
+BRepFill_SequenceOfSection
+BRepMAT2d_DataMapOfBasicEltShape
+BRepMAT2d_DataMapOfShapeSequenceOfBasicElt
+BRepOffset_DataMapOfShapeListOfInterval
+BRepOffset_DataMapOfShapeMapOfShape
+BRepOffset_DataMapOfShapeOffset
+BRepOffset_ListOfInterval
+BRepOffsetAPI_SequenceOfSequenceOfReal
+BRepOffsetAPI_SequenceOfSequenceOfShape
+BRepTools_MapOfVertexPnt2d
+BRepTopAdaptor_MapOfShapeTool
+CDM_DocumentHasher
+CDM_ListOfDocument
+CDM_ListOfReferences
+CDM_MapOfDocument
+CDM_MetaDataLookUpTable
+CDM_PresentationDirectory
+ChFiDS_HData
+ChFiDS_IndexedDataMapOfVertexListOfStripe
+ChFiDS_ListOfHElSpine
+ChFiDS_ListOfStripe
+ChFiDS_Regularities
+ChFiDS_SecArray1
+ChFiDS_SecHArray1
+ChFiDS_SequenceOfSpine
+ChFiDS_SequenceOfSurfData
+ChFiDS_StripeArray1
+ChFiKPart_RstMap
+Contap_TheHSequenceOfPoint
+Contap_TheSequenceOfLine
+Contap_TheSequenceOfPoint
+Convert_SequenceOfArray1OfPoles
+DBRep_ListOfEdge
+DBRep_ListOfFace
+DBRep_ListOfHideData
+DDF_TransactionStack
+DNaming_DataMapOfShapeOfName
+Draft_DataMapOfEdgeEdgeInfo
+Draft_DataMapOfFaceFaceInfo
+Draft_DataMapOfVertexVertexInfo
+Draw_MapOfAsciiString
+Draw_SequenceOfDrawable3D
+Expr_Array1OfGeneralExpression
+Expr_Array1OfNamedUnknown
+Expr_Array1OfSingleRelation
+Expr_MapOfNamedUnknown
+Expr_SequenceOfGeneralExpression
+Expr_SequenceOfGeneralRelation
+ExprIntrp_SequenceOfNamedExpression
+ExprIntrp_SequenceOfNamedFunction
+ExprIntrp_StackOfGeneralExpression
+ExprIntrp_StackOfGeneralFunction
+ExprIntrp_StackOfGeneralRelation
+Extrema_Array1OfPOnCurv
+Extrema_Array1OfPOnCurv2d
+Extrema_Array1OfPOnSurf
+Extrema_Array2OfPOnCurv
+Extrema_Array2OfPOnCurv2d
+Extrema_Array2OfPOnSurf
+Extrema_Array2OfPOnSurfParams
+Extrema_HArray1OfPOnCurv
+Extrema_HArray1OfPOnCurv2d
+Extrema_HArray1OfPOnSurf
+Extrema_HArray2OfPOnCurv
+Extrema_HArray2OfPOnCurv2d
+Extrema_HArray2OfPOnSurf
+Extrema_HArray2OfPOnSurfParams
+Extrema_SequenceOfPOnCurv
+Extrema_SequenceOfPOnCurv2d
+Extrema_SequenceOfPOnSurf
+FEmTool_AssemblyTable
+FEmTool_HAssemblyTable
+FEmTool_ListOfVectors
+FEmTool_SeqOfLinConstr
+GccEnt_Array1OfPosition
+Geom2dHatch_Hatchings
+Geom2dHatch_MapOfElements
+Geom_HSequenceOfBSplineSurface
+Geom_SequenceOfBSplineSurface
+GeomFill_Array1OfLocationLaw
+GeomFill_Array1OfSectionLaw
+GeomFill_HArray1OfLocationLaw
+GeomFill_HArray1OfSectionLaw
+GeomFill_HSequenceOfAx2
+GeomFill_SequenceOfAx2
+GeomFill_SequenceOfTrsf
+GeomInt_SequenceOfParameterAndOrientation
+GeomLib_Array1OfMat
+GeomPlate_Array1OfHCurveOnSurface
+GeomPlate_Array1OfSequenceOfReal
+GeomPlate_HArray1OfHCurveOnSurface
+GeomPlate_HArray1OfSequenceOfReal
+GeomPlate_HSequenceOfCurveConstraint
+GeomPlate_HSequenceOfPointConstraint
+GeomPlate_SequenceOfAij
+GeomPlate_SequenceOfCurveConstraint
+GeomPlate_SequenceOfPointConstraint
+Graphic3d_Array1OfVector
+Graphic3d_Array1OfVertex
+Graphic3d_Array2OfVertex
+Graphic3d_HSequenceOfStructure
+Graphic3d_ListOfShortReal
+Graphic3d_SequenceOfStructure
+Hatch_SequenceOfLine
+Hatch_SequenceOfParameter
+HatchGen_Domains
+HatchGen_PointsOnElement
+HatchGen_PointsOnHatching
+HLRAlgo_Array1OfPHDat
+HLRAlgo_Array1OfPINod
+HLRAlgo_Array1OfPISeg
+HLRAlgo_Array1OfTData
+HLRAlgo_HArray1OfPHDat
+HLRAlgo_HArray1OfPINod
+HLRAlgo_HArray1OfPISeg
+HLRAlgo_HArray1OfTData
+HLRAlgo_InterferenceList
+HLRAlgo_ListOfBPoint
+HLRBRep_Array1OfEData
+HLRBRep_Array1OfFData
+HLRBRep_ListOfBPnt2D
+HLRBRep_ListOfBPoint
+HLRBRep_SeqOfShapeBounds
+HLRTopoBRep_DataMapOfShapeFaceData
+HLRTopoBRep_ListOfVData
+HLRTopoBRep_MapOfShapeListOfVData
+IFSelect_HSeqOfSelection
+IFSelect_SequenceOfAppliedModifiers
+IFSelect_SequenceOfGeneralModifier
+IFSelect_SequenceOfInterfaceModel
+IFSelect_TSeqOfDispatch
+IFSelect_TSeqOfSelection
+IGESAppli_Array1OfFiniteElement
+IGESAppli_Array1OfFlow
+IGESAppli_Array1OfNode
+IGESAppli_HArray1OfFiniteElement
+IGESAppli_HArray1OfFlow
+IGESAppli_HArray1OfNode
+IGESBasic_Array1OfLineFontEntity
+IGESBasic_Array2OfHArray1OfReal
+IGESBasic_HArray1OfLineFontEntity
+IGESBasic_HArray2OfHArray1OfReal
+IGESData_Array1OfDirPart
+IGESData_Array1OfIGESEntity
+IGESData_HArray1OfIGESEntity
+IGESDefs_Array1OfTabularData
+IGESDefs_HArray1OfTabularData
+IGESDimen_Array1OfGeneralNote
+IGESDimen_Array1OfLeaderArrow
+IGESDimen_HArray1OfGeneralNote
+IGESDimen_HArray1OfLeaderArrow
+IGESDraw_Array1OfConnectPoint
+IGESDraw_Array1OfViewKindEntity
+IGESDraw_HArray1OfConnectPoint
+IGESDraw_HArray1OfViewKindEntity
+IGESGeom_Array1OfBoundary
+IGESGeom_Array1OfCurveOnSurface
+IGESGeom_Array1OfTransformationMatrix
+IGESGeom_HArray1OfBoundary
+IGESGeom_HArray1OfCurveOnSurface
+IGESGeom_HArray1OfTransformationMatrix
+IGESGraph_Array1OfColor
+IGESGraph_Array1OfTextDisplayTemplate
+IGESGraph_Array1OfTextFontDef
+IGESGraph_HArray1OfColor
+IGESGraph_HArray1OfTextDisplayTemplate
+IGESGraph_HArray1OfTextFontDef
+IGESSolid_Array1OfFace
+IGESSolid_Array1OfLoop
+IGESSolid_Array1OfShell
+IGESSolid_Array1OfVertexList
+IGESSolid_HArray1OfFace
+IGESSolid_HArray1OfLoop
+IGESSolid_HArray1OfShell
+IGESSolid_HArray1OfVertexList
+IntAna_ListOfCurve
+IntCurveSurface_SequenceOfPnt
+IntCurveSurface_SequenceOfSeg
+Interface_Array1OfFileParameter
+Interface_Array1OfHAsciiString
+Interface_DataMapOfTransientInteger
+Interface_HArray1OfHAsciiString
+Interface_HSequenceOfCheck
+Interface_IndexedMapOfAsciiString
+Interface_SequenceOfCheck
+Intf_Array1OfLin
+Intf_SeqOfSectionLine
+Intf_SeqOfSectionPoint
+Intf_SeqOfTangentZone
+IntPatch_SequenceOfLine
+IntPatch_SequenceOfPoint
+IntPolyh_SeqOfStartPoints
+IntRes2d_SequenceOfIntersectionPoint
+IntRes2d_SequenceOfIntersectionSegment
+Intrv_SequenceOfInterval
+IntSurf_ListOfPntOn2S
+IntSurf_SequenceOfCouple
+IntSurf_SequenceOfInteriorPoint
+IntSurf_SequenceOfPathPoint
+IntTools_Array1OfRange
+IntTools_Array1OfRoots
+IntTools_DataMapOfCurveSampleBox
+IntTools_DataMapOfSurfaceSampleBox
+IntTools_IndexedDataMapOfTransientAddress
+IntTools_ListOfBox
+IntTools_ListOfCurveRangeSample
+IntTools_ListOfSurfaceRangeSample
+IntTools_MapOfCurveSample
+IntTools_MapOfSurfaceSample
+IntTools_SequenceOfCommonPrts
+IntTools_SequenceOfCurves
+IntTools_SequenceOfPntOn2Faces
+IntTools_SequenceOfRanges
+IntTools_SequenceOfRoots
+Law_Laws
+LocOpe_DataMapOfShapePnt
+LocOpe_SequenceOfCirc
+LocOpe_SequenceOfLin
+LocOpe_SequenceOfPntFace
+LProp_SequenceOfCIType
+MAT2d_Array2OfConnexion
+MAT2d_DataMapOfBiIntInteger
+MAT2d_DataMapOfBiIntSequenceOfInteger
+MAT2d_DataMapOfIntegerBisec
+MAT2d_DataMapOfIntegerConnexion
+MAT2d_DataMapOfIntegerPnt2d
+MAT2d_DataMapOfIntegerSequenceOfConnexion
+MAT2d_DataMapOfIntegerVec2d
+MAT2d_SequenceOfConnexion
+MAT2d_SequenceOfSequenceOfCurve
+MAT2d_SequenceOfSequenceOfGeometry
+MAT_DataMapOfIntegerArc
+MAT_DataMapOfIntegerBasicElt
+MAT_DataMapOfIntegerBisector
+MAT_DataMapOfIntegerNode
+MAT_SequenceOfArc
+MAT_SequenceOfBasicElt
+math_Array1OfValueAndWeight
+MDF_ARDriverHSequence
+MDF_ARDriverSequence
+MDF_ASDriverHSequence
+MDF_ASDriverSequence
+MDF_TypeARDriverMap
+MDF_TypeASDriverMap
+MeshVS_Array1OfSequenceOfInteger
+MeshVS_DataMapOfColorMapOfInteger
+MeshVS_DataMapOfHArray1OfSequenceOfInteger
+MeshVS_DataMapOfIntegerAsciiString
+MeshVS_DataMapOfIntegerBoolean
+MeshVS_DataMapOfIntegerColor
+MeshVS_DataMapOfIntegerMaterial
+MeshVS_DataMapOfIntegerMeshEntityOwner
+MeshVS_DataMapOfIntegerOwner
+MeshVS_DataMapOfIntegerTwoColors
+MeshVS_DataMapOfIntegerVector
+MeshVS_DataMapOfTwoColorsMapOfInteger
+MeshVS_HArray1OfSequenceOfInteger
+MeshVS_MapOfTwoNodes
+MeshVS_SequenceOfPrsBuilder
+MeshVS_TwoColorsHasher
+MeshVS_TwoNodesHasher
+Message_ListOfMsg
+Message_SequenceOfPrinters
+Message_SequenceOfProgressScale
+MoniTool_DataMapOfShapeTransient
+MoniTool_DataMapOfTimer
+MoniTool_HSequenceOfElement
+MoniTool_IndexedDataMapOfShapeTransient
+MoniTool_SequenceOfElement
+NLPlate_SequenceOfHGPPConstraint
+NLPlate_StackOfPlate
+PCDM_SequenceOfDocument
+PCDM_SequenceOfReference
+Plate_Array1OfPinpointConstraint
+Plate_HArray1OfPinpointConstraint
+Plate_SequenceOfLinearScalarConstraint
+Plate_SequenceOfLinearXYZConstraint
+Plate_SequenceOfPinpointConstraint
+Plugin_MapOfFunctions
+Poly_Array1OfTriangle
+Poly_HArray1OfTriangle
+ProjLib_HSequenceOfHSequenceOfPnt
+ProjLib_SequenceOfHSequenceOfPnt
+PrsMgr_Presentations
+PTColStd_DoubleMapOfTransientPersistent
+PTColStd_MapPersistentHasher
+PTColStd_PersistentTransientMap
+PTColStd_TransientPersistentMap
+QANCollection_DataMapOfRealPnt
+QANCollection_DoubleMapOfRealInteger
+QANCollection_IndexedDataMapOfRealPnt
+QANCollection_ListOfPnt
+Quantity_Array1OfCoefficient
+Quantity_Array1OfColor
+Quantity_Array2OfColor
+Quantity_HArray1OfColor
+Resource_DataMapOfAsciiStringAsciiString
+Resource_DataMapOfAsciiStringExtendedString
+SelectMgr_DataMapOfObjectSelectors
+SelectMgr_IndexedDataMapOfOwnerCriterion
+SelectMgr_IndexedMapOfOwner
+SelectMgr_ListOfFilter
+SelectMgr_SequenceOfFilter
+SelectMgr_SequenceOfOwner
+SelectMgr_SequenceOfSelector
+ShapeAnalysis_DataMapOfShapeListOfReal
+ShapeAnalysis_HSequenceOfFreeBounds
+ShapeAnalysis_SequenceOfFreeBounds
+ShapeExtend_DataMapOfShapeListOfMsg
+ShapeExtend_DataMapOfTransientListOfMsg
+ShapeFix_DataMapOfShapeBox2d
+ShapeFix_SequenceOfWireSegment
+StdSelect_IndexedDataMapOfOwnerPrs
+StepAP203_Array1OfApprovedItem
+StepAP203_Array1OfCertifiedItem
+StepAP203_Array1OfChangeRequestItem
+StepAP203_Array1OfClassifiedItem
+StepAP203_Array1OfContractedItem
+StepAP203_Array1OfDateTimeItem
+StepAP203_Array1OfPersonOrganizationItem
+StepAP203_Array1OfSpecifiedItem
+StepAP203_Array1OfStartRequestItem
+StepAP203_Array1OfWorkItem
+StepAP203_HArray1OfApprovedItem
+StepAP203_HArray1OfCertifiedItem
+StepAP203_HArray1OfChangeRequestItem
+StepAP203_HArray1OfClassifiedItem
+StepAP203_HArray1OfContractedItem
+StepAP203_HArray1OfDateTimeItem
+StepAP203_HArray1OfPersonOrganizationItem
+StepAP203_HArray1OfSpecifiedItem
+StepAP203_HArray1OfStartRequestItem
+StepAP203_HArray1OfWorkItem
+StepAP214_Array1OfApprovalItem
+StepAP214_Array1OfAutoDesignDateAndPersonItem
+StepAP214_Array1OfAutoDesignDateAndTimeItem
+StepAP214_Array1OfAutoDesignDatedItem
+StepAP214_Array1OfAutoDesignGeneralOrgItem
+StepAP214_Array1OfAutoDesignGroupedItem
+StepAP214_Array1OfAutoDesignPresentedItemSelect
+StepAP214_Array1OfAutoDesignReferencingItem
+StepAP214_Array1OfDateAndTimeItem
+StepAP214_Array1OfDateItem
+StepAP214_Array1OfDocumentReferenceItem
+StepAP214_Array1OfExternalIdentificationItem
+StepAP214_Array1OfGroupItem
+StepAP214_Array1OfOrganizationItem
+StepAP214_Array1OfPersonAndOrganizationItem
+StepAP214_Array1OfPresentedItemSelect
+StepAP214_Array1OfSecurityClassificationItem
+StepAP214_HArray1OfApprovalItem
+StepAP214_HArray1OfAutoDesignDateAndPersonItem
+StepAP214_HArray1OfAutoDesignDateAndTimeItem
+StepAP214_HArray1OfAutoDesignDatedItem
+StepAP214_HArray1OfAutoDesignGeneralOrgItem
+StepAP214_HArray1OfAutoDesignGroupedItem
+StepAP214_HArray1OfAutoDesignPresentedItemSelect
+StepAP214_HArray1OfAutoDesignReferencingItem
+StepAP214_HArray1OfDateAndTimeItem
+StepAP214_HArray1OfDateItem
+StepAP214_HArray1OfDocumentReferenceItem
+StepAP214_HArray1OfExternalIdentificationItem
+StepAP214_HArray1OfGroupItem
+StepAP214_HArray1OfOrganizationItem
+StepAP214_HArray1OfPersonAndOrganizationItem
+StepAP214_HArray1OfPresentedItemSelect
+StepAP214_HArray1OfSecurityClassificationItem
+StepBasic_Array1OfApproval
+StepBasic_Array1OfDerivedUnitElement
+StepBasic_Array1OfDocument
+StepBasic_Array1OfNamedUnit
+StepBasic_Array1OfOrganization
+StepBasic_Array1OfPerson
+StepBasic_Array1OfProduct
+StepBasic_Array1OfProductContext
+StepBasic_Array1OfProductDefinition
+StepBasic_Array1OfUncertaintyMeasureWithUnit
+StepBasic_HArray1OfApproval
+StepBasic_HArray1OfDerivedUnitElement
+StepBasic_HArray1OfDocument
+StepBasic_HArray1OfNamedUnit
+StepBasic_HArray1OfOrganization
+StepBasic_HArray1OfPerson
+StepBasic_HArray1OfProduct
+StepBasic_HArray1OfProductContext
+StepBasic_HArray1OfProductDefinition
+StepBasic_HArray1OfUncertaintyMeasureWithUnit
+STEPCAFControl_DataMapOfLabelExternFile
+STEPCAFControl_DataMapOfLabelShape
+STEPCAFControl_DataMapOfPDExternFile
+STEPCAFControl_DataMapOfSDRExternFile
+STEPCAFControl_DataMapOfShapePD
+STEPCAFControl_DataMapOfShapeSDR
+STEPConstruct_DataMapOfAsciiStringTransient
+STEPConstruct_DataMapOfPointTransient
+StepData_Array1OfField
+StepData_HArray1OfField
+StepDimTol_Array1OfDatumReference
+StepDimTol_HArray1OfDatumReference
+StepElement_Array1OfCurveElementEndReleasePacket
+StepElement_Array1OfCurveElementSectionDefinition
+StepElement_Array1OfHSequenceOfCurveElementPurposeMember
+StepElement_Array1OfHSequenceOfSurfaceElementPurposeMember
+StepElement_Array1OfMeasureOrUnspecifiedValue
+StepElement_Array1OfSurfaceSection
+StepElement_Array1OfVolumeElementPurpose
+StepElement_Array1OfVolumeElementPurposeMember
+StepElement_Array2OfCurveElementPurposeMember
+StepElement_Array2OfSurfaceElementPurpose
+StepElement_Array2OfSurfaceElementPurposeMember
+StepElement_HArray1OfCurveElementEndReleasePacket
+StepElement_HArray1OfCurveElementSectionDefinition
+StepElement_HArray1OfHSequenceOfCurveElementPurposeMember
+StepElement_HArray1OfHSequenceOfSurfaceElementPurposeMember
+StepElement_HArray1OfMeasureOrUnspecifiedValue
+StepElement_HArray1OfSurfaceSection
+StepElement_HArray1OfVolumeElementPurpose
+StepElement_HArray1OfVolumeElementPurposeMember
+StepElement_HArray2OfCurveElementPurposeMember
+StepElement_HArray2OfSurfaceElementPurpose
+StepElement_HArray2OfSurfaceElementPurposeMember
+StepElement_HSequenceOfCurveElementPurposeMember
+StepElement_HSequenceOfCurveElementSectionDefinition
+StepElement_HSequenceOfElementMaterial
+StepElement_HSequenceOfSurfaceElementPurposeMember
+StepElement_SequenceOfCurveElementPurposeMember
+StepElement_SequenceOfCurveElementSectionDefinition
+StepElement_SequenceOfElementMaterial
+StepElement_SequenceOfSurfaceElementPurposeMember
+StepFEA_Array1OfCurveElementEndOffset
+StepFEA_Array1OfCurveElementEndRelease
+StepFEA_Array1OfCurveElementInterval
+StepFEA_Array1OfDegreeOfFreedom
+StepFEA_Array1OfElementRepresentation
+StepFEA_Array1OfNodeRepresentation
+StepFEA_HArray1OfCurveElementEndOffset
+StepFEA_HArray1OfCurveElementEndRelease
+StepFEA_HArray1OfCurveElementInterval
+StepFEA_HArray1OfDegreeOfFreedom
+StepFEA_HArray1OfElementRepresentation
+StepFEA_HArray1OfNodeRepresentation
+StepFEA_HSequenceOfCurve3dElementProperty
+StepFEA_HSequenceOfElementGeometricRelationship
+StepFEA_HSequenceOfElementRepresentation
+StepFEA_HSequenceOfNodeRepresentation
+StepFEA_SequenceOfCurve3dElementProperty
+StepFEA_SequenceOfElementGeometricRelationship
+StepFEA_SequenceOfElementRepresentation
+StepFEA_SequenceOfNodeRepresentation
+StepGeom_Array1OfBoundaryCurve
+StepGeom_Array1OfCartesianPoint
+StepGeom_Array1OfCompositeCurveSegment
+StepGeom_Array1OfCurve
+StepGeom_Array1OfPcurveOrSurface
+StepGeom_Array1OfSurfaceBoundary
+StepGeom_Array1OfTrimmingSelect
+StepGeom_Array2OfCartesianPoint
+StepGeom_Array2OfSurfacePatch
+StepGeom_HArray1OfBoundaryCurve
+StepGeom_HArray1OfCartesianPoint
+StepGeom_HArray1OfCompositeCurveSegment
+StepGeom_HArray1OfCurve
+StepGeom_HArray1OfPcurveOrSurface
+StepGeom_HArray1OfSurfaceBoundary
+StepGeom_HArray1OfTrimmingSelect
+StepGeom_HArray2OfCartesianPoint
+StepGeom_HArray2OfSurfacePatch
+StepRepr_Array1OfMaterialPropertyRepresentation
+StepRepr_Array1OfPropertyDefinitionRepresentation
+StepRepr_Array1OfRepresentationItem
+StepRepr_HArray1OfMaterialPropertyRepresentation
+StepRepr_HArray1OfPropertyDefinitionRepresentation
+StepRepr_HArray1OfRepresentationItem
+StepRepr_HSequenceOfMaterialPropertyRepresentation
+StepRepr_HSequenceOfRepresentationItem
+StepRepr_SequenceOfMaterialPropertyRepresentation
+StepRepr_SequenceOfRepresentationItem
+STEPSelections_HSequenceOfAssemblyLink
+STEPSelections_SequenceOfAssemblyComponent
+STEPSelections_SequenceOfAssemblyLink
+StepShape_Array1OfConnectedEdgeSet
+StepShape_Array1OfConnectedFaceSet
+StepShape_Array1OfEdge
+StepShape_Array1OfFace
+StepShape_Array1OfFaceBound
+StepShape_Array1OfGeometricSetSelect
+StepShape_Array1OfOrientedClosedShell
+StepShape_Array1OfOrientedEdge
+StepShape_Array1OfShell
+StepShape_Array1OfValueQualifier
+StepShape_HArray1OfConnectedEdgeSet
+StepShape_HArray1OfConnectedFaceSet
+StepShape_HArray1OfEdge
+StepShape_HArray1OfFace
+StepShape_HArray1OfFaceBound
+StepShape_HArray1OfGeometricSetSelect
+StepShape_HArray1OfOrientedClosedShell
+StepShape_HArray1OfOrientedEdge
+StepShape_HArray1OfShell
+StepShape_HArray1OfValueQualifier
+StepToTopoDS_DataMapOfRI
+StepToTopoDS_DataMapOfRINames
+StepToTopoDS_DataMapOfTRI
+StepToTopoDS_PointEdgeMap
+StepToTopoDS_PointVertexMap
+StepVisual_Array1OfBoxCharacteristicSelect
+StepVisual_Array1OfCurveStyleFontPattern
+StepVisual_Array1OfDirectionCountSelect
+StepVisual_Array1OfFillStyleSelect
+StepVisual_Array1OfInvisibleItem
+StepVisual_Array1OfLayeredItem
+StepVisual_Array1OfPresentationStyleAssignment
+StepVisual_Array1OfPresentationStyleSelect
+StepVisual_Array1OfStyleContextSelect
+StepVisual_Array1OfSurfaceStyleElementSelect
+StepVisual_Array1OfTextOrCharacter
+StepVisual_HArray1OfBoxCharacteristicSelect
+StepVisual_HArray1OfCurveStyleFontPattern
+StepVisual_HArray1OfDirectionCountSelect
+StepVisual_HArray1OfFillStyleSelect
+StepVisual_HArray1OfInvisibleItem
+StepVisual_HArray1OfLayeredItem
+StepVisual_HArray1OfPresentationStyleAssignment
+StepVisual_HArray1OfPresentationStyleSelect
+StepVisual_HArray1OfStyleContextSelect
+StepVisual_HArray1OfSurfaceStyleElementSelect
+StepVisual_HArray1OfTextOrCharacter
+StlMesh_SequenceOfMesh
+StlMesh_SequenceOfMeshDomain
+StlMesh_SequenceOfMeshTriangle
+Storage_ArrayOfCallBack
+Storage_ArrayOfSchema
+Storage_HArrayOfCallBack
+Storage_HArrayOfSchema
+Storage_HPArray
+Storage_HSeqOfRoot
+Storage_MapOfCallBack
+Storage_MapOfPers
+Storage_PArray
+Storage_PType
+Storage_SeqOfRoot
+TColGeom2d_Array1OfBezierCurve
+TColGeom2d_Array1OfBSplineCurve
+TColGeom2d_Array1OfCurve
+TColGeom2d_HArray1OfBezierCurve
+TColGeom2d_HArray1OfBSplineCurve
+TColGeom2d_HArray1OfCurve
+TColGeom2d_HSequenceOfBoundedCurve
+TColGeom2d_HSequenceOfCurve
+TColGeom2d_SequenceOfBoundedCurve
+TColGeom2d_SequenceOfCurve
+TColGeom2d_SequenceOfGeometry
+TColGeom_Array1OfBezierCurve
+TColGeom_Array1OfBSplineCurve
+TColGeom_Array1OfCurve
+TColGeom_Array1OfSurface
+TColGeom_Array2OfBezierSurface
+TColGeom_Array2OfSurface
+TColGeom_HArray1OfBezierCurve
+TColGeom_HArray1OfBSplineCurve
+TColGeom_HArray1OfCurve
+TColGeom_HArray1OfSurface
+TColGeom_HArray2OfSurface
+TColGeom_HSequenceOfBoundedCurve
+TColGeom_HSequenceOfCurve
+TColGeom_SequenceOfBoundedCurve
+TColGeom_SequenceOfCurve
+TColGeom_SequenceOfSurface
+TColgp_Array1OfCirc2d
+TColgp_Array1OfDir
+TColgp_Array1OfDir2d
+TColgp_Array1OfLin2d
+TColgp_Array1OfPnt
+TColgp_Array1OfPnt2d
+TColgp_Array1OfVec
+TColgp_Array1OfVec2d
+TColgp_Array1OfXY
+TColgp_Array1OfXYZ
+TColgp_Array2OfCirc2d
+TColgp_Array2OfDir
+TColgp_Array2OfDir2d
+TColgp_Array2OfLin2d
+TColgp_Array2OfPnt
+TColgp_Array2OfPnt2d
+TColgp_Array2OfVec
+TColgp_Array2OfVec2d
+TColgp_Array2OfXY
+TColgp_Array2OfXYZ
+TColgp_HArray1OfCirc2d
+TColgp_HArray1OfDir
+TColgp_HArray1OfDir2d
+TColgp_HArray1OfLin2d
+TColgp_HArray1OfPnt
+TColgp_HArray1OfPnt2d
+TColgp_HArray1OfVec
+TColgp_HArray1OfVec2d
+TColgp_HArray1OfXY
+TColgp_HArray1OfXYZ
+TColgp_HArray2OfCirc2d
+TColgp_HArray2OfDir
+TColgp_HArray2OfDir2d
+TColgp_HArray2OfLin2d
+TColgp_HArray2OfPnt
+TColgp_HArray2OfPnt2d
+TColgp_HArray2OfVec
+TColgp_HArray2OfVec2d
+TColgp_HArray2OfXY
+TColgp_HArray2OfXYZ
+TColgp_HSequenceOfDir
+TColgp_HSequenceOfDir2d
+TColgp_HSequenceOfPnt
+TColgp_HSequenceOfPnt2d
+TColgp_HSequenceOfVec
+TColgp_HSequenceOfVec2d
+TColgp_HSequenceOfXY
+TColgp_HSequenceOfXYZ
+TColgp_SequenceOfArray1OfPnt2d
+TColgp_SequenceOfAx1
+TColgp_SequenceOfDir
+TColgp_SequenceOfDir2d
+TColgp_SequenceOfPnt
+TColgp_SequenceOfPnt2d
+TColgp_SequenceOfVec
+TColgp_SequenceOfVec2d
+TColgp_SequenceOfXY
+TColgp_SequenceOfXYZ
+TColQuantity_Array1OfLength
+TColQuantity_Array2OfLength
+TColQuantity_HArray1OfLength
+TColQuantity_HArray2OfLength
+TColStd_Array1OfAsciiString
+TColStd_Array1OfBoolean
+TColStd_Array1OfByte
+TColStd_Array1OfCharacter
+TColStd_Array1OfExtendedString
+TColStd_Array1OfInteger
+TColStd_Array1OfListOfInteger
+TColStd_Array1OfReal
+TColStd_Array1OfTransient
+TColStd_Array2OfBoolean
+TColStd_Array2OfCharacter
+TColStd_Array2OfInteger
+TColStd_Array2OfReal
+TColStd_Array2OfTransient
+TColStd_DataMapOfAsciiStringInteger
+TColStd_DataMapOfIntegerInteger
+TColStd_DataMapOfIntegerListOfInteger
+TColStd_DataMapOfIntegerReal
+TColStd_DataMapOfIntegerTransient
+TColStd_DataMapOfStringInteger
+TColStd_DataMapOfTransientTransient
+TColStd_HArray1OfAsciiString
+TColStd_HArray1OfBoolean
+TColStd_HArray1OfByte
+TColStd_HArray1OfCharacter
+TColStd_HArray1OfExtendedString
+TColStd_HArray1OfInteger
+TColStd_HArray1OfListOfInteger
+TColStd_HArray1OfReal
+TColStd_HArray1OfTransient
+TColStd_HArray2OfBoolean
+TColStd_HArray2OfCharacter
+TColStd_HArray2OfInteger
+TColStd_HArray2OfReal
+TColStd_HArray2OfTransient
+TColStd_HSequenceOfAsciiString
+TColStd_HSequenceOfExtendedString
+TColStd_HSequenceOfHAsciiString
+TColStd_HSequenceOfHExtendedString
+TColStd_HSequenceOfInteger
+TColStd_HSequenceOfReal
+TColStd_HSequenceOfTransient
+TColStd_IndexedDataMapOfTransientTransient
+TColStd_IndexedMapOfInteger
+TColStd_IndexedMapOfReal
+TColStd_IndexedMapOfTransient
+TColStd_ListOfAsciiString
+TColStd_ListOfInteger
+TColStd_ListOfReal
+TColStd_ListOfTransient
+TColStd_MapIntegerHasher
+TColStd_MapOfAsciiString
+TColStd_MapOfInteger
+TColStd_MapOfReal
+TColStd_MapOfTransient
+TColStd_MapRealHasher
+TColStd_MapTransientHasher
+TColStd_SequenceOfAddress
+TColStd_SequenceOfAsciiString
+TColStd_SequenceOfBoolean
+TColStd_SequenceOfExtendedString
+TColStd_SequenceOfHAsciiString
+TColStd_SequenceOfHExtendedString
+TColStd_SequenceOfInteger
+TColStd_SequenceOfReal
+TColStd_SequenceOfTransient
+TDataStd_DataMapOfStringByte
+TDataStd_DataMapOfStringHArray1OfInteger
+TDataStd_DataMapOfStringHArray1OfReal
+TDataStd_DataMapOfStringReal
+TDataStd_DataMapOfStringString
+TDataStd_HLabelArray1
+TDataStd_LabelArray1
+TDataStd_ListOfByte
+TDataStd_ListOfExtendedString
+TDataXtd_Array1OfTrsf
+TDataXtd_HArray1OfTrsf
+TDF_AttributeArray1
+TDF_AttributeDataMap
+TDF_AttributeDeltaList
+TDF_AttributeDoubleMap
+TDF_AttributeIndexedMap
+TDF_AttributeList
+TDF_AttributeMap
+TDF_AttributeSequence
+TDF_DeltaList
+TDF_GUIDProgIDMap
+TDF_HAttributeArray1
+TDF_IDList
+TDF_IDMap
+TDF_LabelDataMap
+TDF_LabelDoubleMap
+TDF_LabelIndexedMap
+TDF_LabelIntegerMap
+TDF_LabelList
+TDF_LabelMap
+TDF_LabelSequence
+TDocStd_LabelIDMapDataMap
+TDocStd_SequenceOfApplicationDelta
+TDocStd_SequenceOfDocument
+TestTopOpeDraw_Array1OfDrawableMesure
+TestTopOpeDraw_Array1OfDrawableP3D
+TestTopOpeDraw_HArray1OfDrawableMesure
+TestTopOpeDraw_HArray1OfDrawableP3D
+TestTopOpeDraw_ListOfPnt2d
+TestTopOpeTools_Array1OfMesure
+TestTopOpeTools_HArray1OfMesure
+TFunction_Array1OfDataMapOfGUIDDriver
+TFunction_DataMapOfGUIDDriver
+TFunction_DataMapOfLabelListOfLabel
+TFunction_DoubleMapOfIntegerLabel
+TFunction_HArray1OfDataMapOfGUIDDriver
+TNaming_DataMapOfShapePtrRefShape
+TNaming_DataMapOfShapeShapesSet
+TNaming_ListOfIndexedDataMapOfShapeListOfShape
+TNaming_ListOfMapOfShape
+TNaming_ListOfNamedShape
+TNaming_MapOfNamedShape
+TNaming_NamedShapeHasher
+TopBas_ListOfTestInterference
+TopLoc_IndexedMapOfLocation
+TopLoc_MapLocationHasher
+TopLoc_MapOfLocation
+TopoDS_ListOfShape
+TopOpeBRep_Array1OfLineInter
+TopOpeBRep_Array1OfVPointInter
+TopOpeBRep_DataMapOfTopolTool
+TopOpeBRep_HArray1OfLineInter
+TopOpeBRep_HArray1OfVPointInter
+TopOpeBRep_ListOfBipoint
+TopOpeBRep_SequenceOfPoint2d
+TopOpeBRepBuild_DataMapOfShapeListOfShapeListOfShape
+TopOpeBRepBuild_IndexedDataMapOfShapeVertexInfo
+TopOpeBRepBuild_ListOfListOfLoop
+TopOpeBRepBuild_ListOfLoop
+TopOpeBRepBuild_ListOfPave
+TopOpeBRepBuild_ListOfShapeListOfShape
+TopOpeBRepDS_Array1OfDataMapOfIntegerListOfInterference
+TopOpeBRepDS_DataMapOfCheckStatus
+TopOpeBRepDS_DataMapOfIntegerListOfInterference
+TopOpeBRepDS_DataMapOfInterferenceListOfInterference
+TopOpeBRepDS_DataMapOfInterferenceShape
+TopOpeBRepDS_DataMapOfShapeListOfShapeOn1State
+TopOpeBRepDS_DataMapOfShapeState
+TopOpeBRepDS_DoubleMapOfIntegerShape
+TopOpeBRepDS_HArray1OfDataMapOfIntegerListOfInterference
+TopOpeBRepDS_IndexedDataMapOfShapeWithState
+TopOpeBRepDS_IndexedDataMapOfVertexPoint
+TopOpeBRepDS_ListOfInterference
+TopOpeBRepDS_MapOfCurve
+TopOpeBRepDS_MapOfIntegerShapeData
+TopOpeBRepDS_MapOfPoint
+TopOpeBRepDS_MapOfShapeData
+TopOpeBRepDS_MapOfSurface
+TopOpeBRepDS_ShapeSurface
+TopOpeBRepTool_DataMapOfOrientedShapeC2DF
+TopOpeBRepTool_DataMapOfShapeface
+TopOpeBRepTool_DataMapOfShapeListOfC2DF
+TopOpeBRepTool_IndexedDataMapOfShapeBox
+TopOpeBRepTool_IndexedDataMapOfShapeBox2d
+TopOpeBRepTool_IndexedDataMapOfShapeconnexity
+TopOpeBRepTool_IndexedDataMapOfSolidClassifier
+TopOpeBRepTool_ListOfC2DF
+TopTools_Array1OfListOfShape
+TopTools_Array1OfShape
+TopTools_Array2OfShape
+TopTools_DataMapOfIntegerListOfShape
+TopTools_DataMapOfIntegerShape
+TopTools_DataMapOfOrientedShapeInteger
+TopTools_DataMapOfOrientedShapeShape
+TopTools_DataMapOfShapeInteger
+TopTools_DataMapOfShapeListOfInteger
+TopTools_DataMapOfShapeListOfShape
+TopTools_DataMapOfShapeReal
+TopTools_DataMapOfShapeSequenceOfShape
+TopTools_DataMapOfShapeShape
+TopTools_HArray1OfListOfShape
+TopTools_HArray1OfShape
+TopTools_HArray2OfShape
+TopTools_HSequenceOfShape
+TopTools_IndexedDataMapOfShapeAddress
+TopTools_IndexedDataMapOfShapeListOfShape
+TopTools_IndexedDataMapOfShapeShape
+TopTools_IndexedMapOfOrientedShape
+TopTools_IndexedMapOfShape
+TopTools_ListOfShape
+TopTools_MapOfOrientedShape
+TopTools_MapOfShape
+TopTools_SequenceOfShape
+TopTrans_Array2OfOrientation
+TPrsStd_DataMapOfGUIDDriver
+Transfer_HSequenceOfBinder
+Transfer_HSequenceOfFinder
+Transfer_SequenceOfBinder
+Transfer_SequenceOfFinder
+TransferBRep_HSequenceOfTransferResultInfo
+TransferBRep_SequenceOfTransferResultInfo
+TShort_Array1OfShortReal
+TShort_Array2OfShortReal
+TShort_HArray1OfShortReal
+TShort_HArray2OfShortReal
+TShort_HSequenceOfShortReal
+TShort_SequenceOfShortReal
+Units_QtsSequence
+Units_QuantitiesSequence
+Units_TksSequence
+Units_TokensSequence
+Units_UnitsSequence
+Units_UtsSequence
+ViewerTest_DoubleMapOfInteractiveAndName
+Visual3d_HSequenceOfLight
+Visual3d_HSequenceOfView
+Visual3d_SequenceOfLight
+Visual3d_SequenceOfView
+XCAFDoc_DataMapOfShapeLabel
+XCAFDoc_GraphNodeSequence
+XCAFPrs_DataMapOfShapeStyle
+XCAFPrs_DataMapOfStyleShape
+XCAFPrs_DataMapOfStyleTransient
+XmlLDrivers_SequenceOfNamespaceDef
+XmlMDF_MapOfDriver
+XmlMDF_TypeADriverMap
+XSDRAWSTLVRML_CoordsMap
+XSDRAWSTLVRML_ElemNodesMap
diff --git a/adm/upgrade.tcl b/adm/upgrade.tcl
new file mode 100644 (file)
index 0000000..204fca6
--- /dev/null
@@ -0,0 +1,1319 @@
+# This script provides commands for upgrade of OCCT and software based on it
+# to a newer version of OCCT (7.0)
+
+
+# source code for upgrading
+set ArgName(HelpInfo)       "h"
+
+set ArgName(SourceCode)     "src"
+set ArgName(IncPath)        "inc"
+
+set ArgName(IncExtension)   "incext"
+set ArgName(SrcExtension)   "srcext"
+
+set ArgName(RTTI)           "rtti"
+
+set ArgName(CStyleCastHandle) "handlecast"
+set ArgName(All)            "all"
+
+set ArgName(Handle)         "handle"
+set ArgName(TCollection)    "tcollection"
+
+set ArgName(CompatibleMode) "compat"
+
+set ArgName(Recurse)        "recurse"
+set ArgName(Rename)         "rename"
+
+set ArgName(CheckOnly)      "check"
+set ArgName(WLog)           "wlog"
+set ArgName(Log)            "log"
+
+proc HelpInformation {} {
+  global ArgName
+  global DataSectionName
+
+  loginfo "Tool for upgrade of application code from older versions of OCCT."
+  loginfo ""
+  loginfo "Required parameter:"
+  loginfo "  -$ArgName(SourceCode)=<path>  - path to sources to upgrade"
+  loginfo ""
+  loginfo "File search options:"
+  loginfo "  -$ArgName(IncPath)=<path>  - path to header files of OCCT or other used libraries"
+  loginfo "  -$ArgName(Recurse)     - process all subfolders of '-$ArgName(SourceCode)' and '-$ArgName(IncPath)'"
+  loginfo "  -$ArgName(SrcExtension)=cxx,cpp       - extensions of source files"
+  loginfo "  -$ArgName(IncExtension)=hxx,h,lxx,gxx - extensions of header files"
+  loginfo ""
+  loginfo "Upgrade options:"
+  loginfo "  -$ArgName(All)         - do all upgrades (if neither of below options are given)"
+  loginfo "  -$ArgName(RTTI)        - adapt code for changes in type system (RTTI) in OCCT 7.0"
+  loginfo "  -$ArgName(Handle)      - adapt code for changes in OCCT Handle"
+  loginfo "  -$ArgName(TCollection) - replace forward declaration of TCollection classes by #include"
+  loginfo "  -$ArgName(CStyleCastHandle)  - replace c-style casts of Handle by DownCast()"
+  loginfo "  -$ArgName(Rename)      - apply renaming of classes"
+  loginfo ""
+  loginfo "Advanced options:"
+  loginfo "  -$ArgName(CompatibleMode)      - preserve old RTTI macros for compatability with OCCT 6.x"
+  loginfo "  -$ArgName(CheckOnly)       - do check only, no modifications will be made"
+  loginfo "  -$ArgName(WLog)        - show gui log of upgrade process"
+  loginfo "  -$ArgName(Log)=<file path> - put the log into a file"
+
+  return
+}
+
+proc ParseArgs {theArgValues theArgs {theRemoveFromArgs "false"}} {
+  upvar $theArgValues anArgValues
+
+  global ArgName
+  global DataSectionName
+
+  # help information
+  set anArgValues(HelpInfo) [SeekArg $ArgName(HelpInfo) theArgs "false" $theRemoveFromArgs]
+
+  # sources that will be upgraded
+  set anArgValues(SourceCode) [SeekArg $ArgName(SourceCode) theArgs "" $theRemoveFromArgs]
+
+  set anArgValues(IncExtension) [SeekArg $ArgName(IncExtension) theArgs "h,hpp,hxx,gxx,lxx" $theRemoveFromArgs]
+  set anArgValues(SrcExtension) [SeekArg $ArgName(SrcExtension) theArgs "c,cpp,cxx"         $theRemoveFromArgs]
+
+  # inc folder
+  set anArgValues(IncPath) [SeekArg $ArgName(IncPath) theArgs "$anArgValues(SourceCode)" $theRemoveFromArgs]
+
+  set anArgValues(RTTI)         [SeekArg $ArgName(RTTI)                 theArgs "false" $theRemoveFromArgs]
+  set anArgValues(CStyleCastHandle) [SeekArg $ArgName(CStyleCastHandle) theArgs "false" $theRemoveFromArgs]
+
+  set anArgValues(Handle)       [SeekArg $ArgName(Handle)               theArgs "false" $theRemoveFromArgs]
+  set anArgValues(TCollection)  [SeekArg $ArgName(TCollection)          theArgs "false" $theRemoveFromArgs]
+
+  set anArgValues(Rename) [SeekArg $ArgName(Rename) theArgs "false" $theRemoveFromArgs]
+
+  set aHasAgentArgs [expr {$anArgValues(RTTI)   || $anArgValues(CStyleCastHandle) || \
+                           $anArgValues(Handle) || $anArgValues(TCollection)}     || \
+                           $anArgValues(Rename)]
+
+  set anArgValues(All)       [SeekArg $ArgName(All) theArgs [expr {!$aHasAgentArgs}] $theRemoveFromArgs]
+
+  set anArgValues(Recurse)        [SeekArg $ArgName(Recurse)        theArgs "false" $theRemoveFromArgs]
+  set anArgValues(CompatibleMode) [SeekArg $ArgName(CompatibleMode) theArgs "false" $theRemoveFromArgs]
+  set anArgValues(CheckOnly)      [SeekArg $ArgName(CheckOnly)      theArgs "false" $theRemoveFromArgs]
+  set anArgValues(WLog)           [SeekArg $ArgName(WLog)           theArgs "false" $theRemoveFromArgs]
+
+  set anArgValues(Log)            [SeekArg $ArgName(Log)            theArgs ""      $theRemoveFromArgs]
+
+  return $theArgs
+}
+
+proc SeekArg {theSoughtArgName theArgs {theDefaultArgValue ""} {theRemoveFromArgs false}} {
+  upvar ${theArgs} anArgs
+
+  set aBooleanValue [string is boolean -strict $theDefaultArgValue]
+
+  set anArgValues {}
+
+  set anArgsIndex -1
+  foreach anArg $anArgs {
+    incr anArgsIndex
+
+    if {[regexp -- "-${theSoughtArgName}\=\(.\*\)" $anArg dummy anArgValue]} {
+      set anArgValue [regsub -all {\\} $anArgValue {/}]
+      if {$theRemoveFromArgs} {
+        set anArgs [lreplace $anArgs $anArgsIndex $anArgsIndex]
+        incr anArgsIndex -1
+      }
+      if {"$anArgValue" != ""} {
+        lappend anArgValues $anArgValue  
+      } else {
+        logwarn "'-${theSoughtArgName}' is skipped because it has empty value"
+      }
+    } elseif [string match "-${theSoughtArgName}" $anArg] {
+      if {$theRemoveFromArgs} {
+        set anArgs [lreplace $anArgs $anArgsIndex $anArgsIndex]
+      }
+      # skip non-boolean empty argument; do not break the foreach loop
+      if {$aBooleanValue} {
+        lappend anArgValues "true"
+        break
+      } else {
+        logwarn "'-${theSoughtArgName}' is skipped because it has empty value"
+      }
+    }
+  }
+
+  # return boolean value as string
+  if {$aBooleanValue} {
+    if {[llength $anArgValues] > 0} {
+      return [lindex $anArgValues 0]
+    } else {
+      return $theDefaultArgValue
+    }
+  }
+
+  if {[llength $anArgValues] == 0 && "$theDefaultArgValue" != ""} {
+    lappend anArgValues $theDefaultArgValue
+  }
+
+  return $anArgValues
+}
+
+# section names in the data file
+set DataSectionName(TCollection)  "tcollection"
+set DataSectionName(Rename)       "rename"
+
+proc DataFileName {} {
+  return [file join [file dirname [info script]] upgrade.dat]
+}
+
+proc IsDataFileExist {} {
+  return [file exists [DataFileName]]
+}
+
+proc ReadFromDataFile {theSectionName} {
+  if {![file exists [DataFileName]]} {
+    return
+  }
+
+  set aFileContent [ReadFileToList [DataFileName] aFileRawContent aDataEOL]
+
+  set aSectionValueList {}
+
+  set anIsSection false
+  set aSectionPattern {^ *\[ *([A-Za-z0-9_\.]*) *\]+}
+  foreach aLine $aFileContent {
+    if {[regexp -- $aSectionPattern $aLine dummy aSectionName]} {
+      if {"$aSectionName" == "$theSectionName"} {
+        set anIsSection true
+        continue
+      } elseif {$anIsSection == true} {
+        set anIsSection false
+        break
+      }
+    }
+
+    if {$anIsSection == true} {
+      set aTrimmedLine [string trimright $aLine]
+      if {"$aTrimmedLine" != ""} {
+        lappend aSectionValueList $aTrimmedLine  
+      }
+    }
+  }
+
+  return $aSectionValueList
+}
+
+proc SaveToDataFile {theSectionName theSectionContent} {
+  if {![file exists [DataFileName]]} {
+    return
+  }
+
+  set aFileContent [ReadFileToList [DataFileName] aFileRawContent aDataEOL]
+
+  set aLinesBefore {}
+  set aLinesAfter  {}
+
+  set anIsSection false
+  set anIsSectionBefore true
+  set anIsSectionAfter  false
+
+  set aSectionPattern {^ *\[ *([A-Za-z0-9_\.]*) *\]+}
+  foreach aLine $aFileContent {
+    if {$anIsSectionBefore} {
+      lappend aLinesBefore $aLine  
+    }
+
+    if {[regexp -- $aSectionPattern $aLine dummy aSectionName]} {
+      if {"$aSectionName" == "$theSectionName"} {
+        set anIsSectionBefore false
+        set anIsSection true
+      } elseif {$anIsSection == true} {
+        set anIsSection false
+        set anIsSectionAfter true
+      }
+    }
+
+    if {$anIsSection == true} {
+      continue
+    }
+
+    if {$anIsSectionAfter} {
+      lappend aLinesAfter $aLine  
+    }
+  }
+
+  # write to file
+  SaveListToFile [DataFileName] [list {*}$aLinesBefore {*}$theSectionContent {*}$aLinesAfter] $aDataEOL
+}
+
+# Main tool, accepts path to location of source tree to be upgraded.
+proc upgrade {args} {
+
+  global ArgName
+  global LogFilePath
+  global DataSectionName
+
+  set theArgs $args
+  set anUnparsedArgs [ParseArgs anArgValues $theArgs "true"]
+
+  if {"$anUnparsedArgs" != ""} {
+    logerr "undefined arguments: $anUnparsedArgs"
+    loginfo "use -$ArgName(HelpInfo) to show all the arguments"
+    return
+  }
+
+  if {$anArgValues(HelpInfo) || [llength $anArgValues(SourceCode)] == 0} {
+    HelpInformation
+    return
+  }
+
+  if {"$anArgValues(Log)" != ""} {
+    set LogFilePath $anArgValues(Log)
+
+    # clean file before writing
+    if {[file exists "$LogFilePath"]} {
+      set fd [open "$LogFilePath" r+]
+      chan truncate $fd 0
+      close $fd
+    }
+  }
+
+  if {$anArgValues(WLog)} {
+    _create_logger
+  }
+
+  # collect src directory structure (all subdirs)
+  set anIncPaths {}
+  foreach aSrcDir $anArgValues(SourceCode) {
+    lappend anIncPaths $aSrcDir
+    foreach aSubSrcDir [CollectDirStructure $aSrcDir] {
+      lappend anIncPaths $aSubSrcDir
+    } 
+  }
+
+  foreach anIncDir $anArgValues(IncPath) {
+    lappend anIncPaths $anIncDir 
+    foreach aSubIncDir [CollectDirStructure $anIncDir] {
+      lappend anIncPaths $aSubIncDir 
+    } 
+  }
+
+  set anIncPaths [lsort -unique -dictionary $anIncPaths]
+  # end the collect
+
+  set aRawNewNames [ReadFromDataFile $DataSectionName(Rename)]
+  foreach aRawName $aRawNewNames {
+    set aRawName [split $aRawName " "]
+    if {[llength $aRawName] > 1} {
+      # set aNewNames (old name) [new name]
+      set aNewNames([lindex ${aRawName} 0]) [lindex ${aRawName} 1]
+    }
+  }
+
+  set aDoRename true
+  if {[llength [array names aNewNames]] == 0} {
+    set aDoRename false
+
+    logwarn "renaming skipped. there is no class names to rename"
+    logwarn "see the content of [DataFileName] file, $DataSectionName(Rename) section"
+  }
+
+  set aProcNameWithArgs "[lindex [info level 0] 0]"
+  foreach anArgName [array names anArgValues] {
+    if [string is boolean -strict $anArgValues($anArgName)] {
+      if [string is true "$anArgValues($anArgName)"] {
+        set aProcNameWithArgs [format "$aProcNameWithArgs -%s" "$ArgName($anArgName)"]  
+      }
+    } else {
+      set aProcNameWithArgs [format "$aProcNameWithArgs -%s" "$ArgName($anArgName)=$anArgValues($anArgName)"]
+    }    
+  }
+
+  loginfo "$aProcNameWithArgs" 
+
+  # merge all processed extensions
+  set anExtensions "$anArgValues(SrcExtension),$anArgValues(IncExtension)"
+
+  set aSourceCodePaths $anArgValues(SourceCode)
+  while {[llength $aSourceCodePaths]} {
+    set aSourceCodePaths [lassign $aSourceCodePaths aProcessedPath]
+
+    loginfo "Processing: $aProcessedPath"
+
+    if {$anArgValues(All) || $anArgValues(RTTI)} {
+      ConvertRtti $aProcessedPath \
+                  $anIncPaths \
+                  $anArgValues(CheckOnly) \
+                  $anArgValues(CompatibleMode) \
+                  $anArgValues(IncExtension) \
+                  $anArgValues(SrcExtension)
+    }
+
+    if {$anArgValues(All) || $anArgValues(Handle)} {
+      ConvertHandle $aProcessedPath $anIncPaths $anArgValues(CheckOnly) $anExtensions
+    }
+
+    if {$anArgValues(All) || $anArgValues(TCollection)} {
+      ConvertTColFwd $aProcessedPath $anArgValues(IncExtension)
+    }
+
+    if {$anArgValues(All) || $anArgValues(CStyleCastHandle)} {
+      ConvertCStyleHandleCast $aProcessedPath $anExtensions $anArgValues(CheckOnly)
+    }
+
+    if {$anArgValues(All) || $anArgValues(Rename)} {
+      if {$aDoRename} {
+        Rename $aProcessedPath $anExtensions aNewNames $anArgValues(CheckOnly)
+      }
+    }
+
+    # Recurse processing
+    if {$anArgValues(Recurse)} {
+      lappend aSourceCodePaths {*}[glob -nocomplain -directory $aProcessedPath -type d *]
+    }
+  }
+}
+
+# search and rename the indeces (old names) of @theNewNames with their values (new ones)
+#  processes files that have @theExtensions only in @thePath folder
+proc Rename {thePath theExtensions theNewNames theCheckMode} {
+  upvar $theNewNames aNewNames
+
+  set aNames [array names aNewNames]
+
+  foreach aFile [glob -nocomplain -type f -directory $thePath *.{$theExtensions}] {
+#    loginfo "$aFile processing"
+    set aFileContent [ReadFileToRawText $aFile]
+
+    set aHasChanges false
+    foreach aName $aNames {
+      set anIndexInRow 0
+      set aClassNameTmpl "\\m$aName\\M"
+      while { [regexp -start $anIndexInRow -indices -lineanchor $aClassNameTmpl $aFileContent aFoundClassNameLoc] } {
+        set anIndexInRow [lindex $aFoundClassNameLoc 1]
+
+        if {$theCheckMode} {
+          logwarn "Warning: $aFile contains $aName"
+          break
+        } else {
+          set aHasChanges true
+          ReplaceSubString aFileContent $aFoundClassNameLoc "$aNewNames($aName)" anIndexInRow
+          incr anIndexInRow -1
+        }
+      }
+    }
+
+    if {$aHasChanges} {
+      SaveTextToFile $aFile $aFileContent
+    }
+  }
+}
+
+# @thePackagePath eather file or folder. If it is a folder, 
+# all files with @theHeaderExtensions are processed.
+# "fwd.tcollection" section from upgrade.ini file is used to find out what 
+# classes have been converted and, thus, what forward declarations can be replaced
+proc ConvertTColFwd {thePackagePath theHeaderExtensions} {
+  global DataSectionName
+
+  # Note: the content of theHeaderExtensions should have
+  #       further form (values separated by comma): "ext1,ext2,ext3"
+  # this form will be used below in reg expression to collect all header files
+
+  if {! [file exists $thePackagePath]} {
+    logerr "Error: $thePackagePath does not exist"
+    return 
+  }
+
+  # read the list of already converted TCollection classes
+  if [IsDataFileExist] {
+    set aConvertedTColClasses [ReadFromDataFile $DataSectionName(TCollection)]
+  } else {
+    logerr "[DataFileName] file  of upgrade process does not exist"
+    return
+  }
+
+  # pattern that will be used
+  set aForwardDeclPattern {^ *class *([A-Za-z0-9_/\.]+) *;}
+
+  set aTargetPaths ${thePackagePath}
+  while {[llength $aTargetPaths]} {
+    set aTargetPaths [lassign $aTargetPaths aProcessedPath]
+
+    # if aProcessedPath is a folder, collect all files with $theHeaderExtensions from it
+    set aProcessedHeaders ${aProcessedPath}
+    if {[file isdirectory $aProcessedPath]} {
+      # get all header files
+      set aProcessedHeaders [glob -nocomplain -type f -directory $aProcessedPath *.{$theHeaderExtensions}]
+    }
+
+    foreach aHeader $aProcessedHeaders {
+      set aHeaderLineIndex -1
+      set aHeaderContentUpdated false
+
+      # read the content of the header file
+      set aHeaderContent [ReadFileToList $aHeader aHeaderRawContent aHeaderEOL]
+      
+      # remove _isMulti variable that used in _check_line
+      set _isMulti false
+
+      foreach aHeaderContentLine $aHeaderContent {
+        incr aHeaderLineIndex
+
+        # remove _cmnt variable that used in _check_line
+        set _cmnt ""
+
+        set aHeaderContentLine [_check_line $aHeaderContentLine]
+        if {[regexp {^ *class *([A-Za-z0-9_/\.]+) *;} $aHeaderContentLine dummy aForwardDeclClass]} {
+          if {[lsearch $aConvertedTColClasses $aForwardDeclClass] != -1} {
+            set aHeaderContentUpdated true
+            set aHeaderContentRow "\#include <$aForwardDeclClass.hxx>"
+            set aHeaderContent [lreplace $aHeaderContent $aHeaderLineIndex $aHeaderLineIndex $aHeaderContentRow]
+          }
+        }
+      }
+
+      if {$aHeaderContentUpdated} {
+        loginfo "$aHeader updated"
+        SaveListToFile $aHeader $aHeaderContent $aHeaderEOL
+      }
+    }
+  }
+}
+
+# Parse source files and:
+#
+# - add second argument to macro DEFINE_STANDARD_RTTI specifying first base 
+#   class found in the class declaration;
+# - replace includes of Standard_DefineHandle.hxx by Standard_Type.hxx;
+# - add #includes for all classes used as argument to macro
+#   STANDARD_TYPE(), except of already included ones
+#
+# If theCompatibleMode is false, in addition:
+# - removes macros IMPLEMENT_DOWNCAST() and IMPLEMENT_STANDARD_*();
+proc ConvertRtti {theProcessedPath theIncPaths theCheckMode theCompatibleMode \
+                  theHeaderExtensions theSourceExtensions} {
+
+  # iterate by header and source files
+  foreach aProcessedFile [glob -nocomplain -type f -directory $theProcessedPath *.{$theHeaderExtensions,$theSourceExtensions}] {
+    set aProcessedFileName [file tail $aProcessedFile]
+
+    set aProcessedFileContent [ReadFileToRawText $aProcessedFile]
+
+    # find all declarations of classes with public base in this header file;
+    # the result is stored in array inherits(class)
+    set index 0
+    array unset inherits
+    set pattern_class {^\s*class\s+([A-Za-z_0-9:]+)\s*:\s*public\s+([A-Za-z_0-9:]+)\s*([,]?)}
+    while {[regexp -start $index -indices -lineanchor $pattern_class $aProcessedFileContent location class base comma]} {
+      set index [lindex $location 1]
+
+      set class [eval string range \$aProcessedFileContent $class]
+      set base  [eval string range \$aProcessedFileContent $base]
+
+      if { [info exists inherits($class)] } {
+        set inherits($class,multiple) "found multiple declarations of class $class"
+      } else {
+        if { [lindex $comma 0] <= [lindex $comma 1] } {
+          set inherits($class,multiple) "class $class uses multiple inheritance"
+        }
+        set inherits($class) $base
+      }
+    }
+
+    set change_flag 0
+
+    # find all instances of DEFINE_STANDARD_RTTI with single or two arguments
+    set index 0
+    set pattern_rtti {^(\s*DEFINE_STANDARD_RTTI\s*)\(\s*([A-Za-z_0-9,\s]+)\s*\)}
+    while { [regexp -start $index -indices -lineanchor $pattern_rtti \
+                    $aProcessedFileContent location start clist] } {
+      set index [lindex $location 1]
+
+      set start [eval string range \$aProcessedFileContent $start]
+      set clist [split [eval string range \$aProcessedFileContent $clist] ,]
+
+      if { [llength $clist] == 1 } {
+        set class [string trim [lindex $clist 0]]
+        if { [info exists inherits($class)] } {
+          if { ! $theCheckMode } {
+            if { [info exists inherits($class,multiple)] } {
+              logwarn "Warning in $aProcessedFileName: $inherits($class,multiple);"
+              logwarn "macro DEFINE_STANDARD_RTTI is changed assuming it inherits $inherits($class), please check!"
+            }
+            set change_flag 1
+            ReplaceSubString aProcessedFileContent $location "${start}($class, $inherits($class))" index
+          }
+        } else {
+          logwarn "Error in $aProcessedFile: Macro DEFINE_STANDARD_RTTI used for class $class whose declaration is not found in this file, cannot fix"
+        }
+      } elseif { [llength $clist] == 2 } {
+        set class [string trim [lindex $clist 0]]
+        set base  [string trim [lindex $clist 1]]
+        if { ! [info exists inherits($class)] } {
+          logwarn "Warning in $aProcessedFile: Macro DEFINE_STANDARD_RTTI used for class $class whose declaration is not found in this file"
+        } elseif { $base != $inherits($class) } {
+          logwarn "Warning in $aProcessedFile: Second argument in macro DEFINE_STANDARD_RTTI for class $class is $base while $class seems to inherit from $inherits($class)"
+          if { ! $theCheckMode && ! [info exists inherits($class,multiple)] } {
+            set change_flag 1
+            ReplaceSubString aProcessedFileContent $location "${start}($class, $inherits($class))" index
+          }
+        }
+      }
+    }
+
+    # replace includes of Standard_DefineHandle.hxx by Standard_Type.hxx
+#    set index 0
+#    set pattern_definehandle {\#\s*include\s*<\s*Standard_DefineHandle.hxx\s*>}
+#    while { [regexp -start $index -indices -lineanchor $pattern_definehandle $aProcessedFileContent location] } {
+#      set index [lindex $location 1]
+#      if { ! $theCheckMode } {
+#        set change_flag 1
+#        ReplaceSubString aProcessedFileContent $location "\#include <Standard_Type.hxx>" index
+#        incr index -1
+#      } else {
+#        logwarn "Warning: $aProcessedFile contains obsolete forward declarations of Handle classes"
+#        break
+#      }
+#    }
+
+    # remove macros IMPLEMENT_DOWNCAST() and IMPLEMENT_STANDARD_*();
+    if { ! $theCompatibleMode } {
+      set index 0
+      set first_newline \n\n
+      set pattern_implement {\\?\n\s*IMPLEMENT_(DOWNCAST|STANDARD_[A-Z_]+|HARRAY1|HARRAY2|HUBTREE|HEBTREE|HSEQUENCE)\s*\([A-Za-z0-9_ ,]*\)\s*;?}
+      while { [regexp -start $index -indices -lineanchor $pattern_implement $aProcessedFileContent location] } {
+        set index [lindex $location 1]
+        if { ! $theCheckMode } {
+          set change_flag 1
+          ReplaceSubString aProcessedFileContent $location $first_newline index
+#          set first_newline ""
+          incr index -1
+        } else {
+          logwarn "Warning: $aProcessedFile contains deprecated macros IMPLEMENT_*"
+          break
+        }
+      }
+    }
+
+    # find all uses of macro STANDARD_TYPE and method DownCast and ensure that
+    # argument class is explicitly included
+    set pattern_incbeg {\s*#\s*include\s*[\"<]\s*}
+    set pattern_incend {[.][a-zA-Z]+\s*[\">]}
+    set index 0
+    set addtype {}
+    set pattern_type1 {STANDARD_TYPE\s*\(\s*([A-Za-z0-9_]+)\s*\)}
+    while { [regexp -start $index -indices $pattern_type1 $aProcessedFileContent location name] } {
+      set index [lindex $location 1]
+      set name [eval string range \$aProcessedFileContent $name]
+      if { ! [regexp -lineanchor "^${pattern_incbeg}${name}${pattern_incend}" $aProcessedFileContent] &&
+           [lsearch -exact $addtype $name] < 0 &&
+           [SearchForFile $theIncPaths $name.hxx]} {
+        lappend addtype $name
+      }
+    }
+    set pattern_type2 {Handle\s*\(\s*([A-Za-z0-9_]+)\s*\)\s*::\s*DownCast}
+    while { [regexp -start $index -indices $pattern_type2 $aProcessedFileContent location name] } {
+      set index [lindex $location 1]
+      set name [eval string range \$aProcessedFileContent $name]
+      if { ! [regexp -lineanchor "^${pattern_incbeg}${name}${pattern_incend}" $aProcessedFileContent] &&
+           [lsearch -exact $addtype $name] < 0 &&
+           [SearchForFile $theIncPaths $name.hxx]} {
+        lappend addtype $name
+      }
+    }
+    if { [llength $addtype] > 0 } {
+      if { ! $theCheckMode } {
+        set addinc ""
+        foreach type $addtype {
+          append addinc "\n#include <$type.hxx>"
+        }
+        if { [regexp -indices ".*\n${pattern_incbeg}\[A-Za-z0-9_/\]+${pattern_incend}" $aProcessedFileContent location] } {
+          set change_flag 1
+          ReplaceSubString aProcessedFileContent $location "[eval string range \$aProcessedFileContent $location]$addinc" index
+        } else {
+          logerr "Error: $aProcessedFile: Cannot find #include statement to add more includes..."
+        }
+      } else {
+        logwarn "Warning: $aProcessedFile: The following class names are used as arguments of STANDARD_TYPE"
+        logwarn "         macro, but not included directly: $addtype"
+        break
+      }
+    }
+
+    # apply changes to the header file
+    if { $change_flag } {
+      SaveTextToFile $aProcessedFile $aProcessedFileContent
+    }
+  }
+}
+
+# replace all forward declarations of "class Handle(...)" with fwd of "class ..."
+proc ConvertHandle {theTargetPath theIncPaths theCheckMode theExtensions} {
+
+  # iterate by header files
+  foreach aHeader [glob -nocomplain -type f -directory $theTargetPath *.{$theExtensions}] {
+
+    # skip gxx files, as names Handle_xxx used there are in most cases 
+    # placeholders of the argument types substituted by #define
+    if {[file extension $aHeader] == ".gxx"} {
+      continue
+    }
+
+    # read the content of the header
+    if { [catch {set fd [open $aHeader rb]}] } {
+      logerr "Error: cannot open $aHeader"
+      continue
+    }
+    close $fd
+
+    set aHeaderContent [ReadFileToList $aHeader aHeaderRawContent aHeaderEOL]
+
+    set anUpdateHeader false
+
+    # if file contains "slots:" or "signals:", assume it defines some QObject
+    # class(es). 
+    # In this case, type names "Handle_T" will not be replaced by Handle(T) to
+    # prevent failure of compilation of MOC code if such types are used in 
+    # slots or signals (MOC does not expand macros).
+    # Forward declaration of a Handle will be then replaced by #include of 
+    # corresponding class header (if such header is found), assuming that name
+    # typedefed Handle_T is defined in corresponding header (as typedef).
+    set isQObject [expr [regexp "Q_OBJECT" $aHeaderContent] && [regexp "(slots|signals)\s*:" $aHeaderContent]]
+
+    # replace all IDs with prefix Handle_ by use of Handle() macro
+    if { ! $isQObject } {
+      set anUpdatedHeaderContent {}    
+      set pattern_handle {\mHandle_([A-Za-z0-9_]+)}
+      foreach line $aHeaderContent {
+        # do not touch #include and #if... statements
+        if { [regexp {\s*\#\s*include} $line] || [regexp {\s*\#\s*if} $line] } {
+          lappend anUpdatedHeaderContent $line
+          continue
+        }
+
+        # in other preprocessor statements, skip first expression to avoid
+        # replacements in #define Handle_... and similar cases 
+        set index 0
+        if { [regexp -indices {\s*#\s*[A-Za-z]+\s+[^\s]+} $line location] } {
+          set index [expr 1 + [lindex $location 1]]
+        }
+
+        # replace Handle_T by Handle(T)
+        while { [regexp -start $index -indices $pattern_handle $line location class] } {
+          set index [lindex $location 1]
+
+          set class [eval string range \$line $class]
+#          puts "Found: [eval string range \$line $location]"
+
+          if { ! $theCheckMode } {
+            set anUpdateHeader true
+            ReplaceSubString line $location "Handle($class)" index
+          } else {
+            logwarn "Warning: $aHeader refers to IDs starting with \"Handle_\" which are likely"
+            logwarn "  instances of OCCT Handle classes (e.g. \"$class\"); these are to be "
+            logwarn "  replaced by template opencascade::handle<> or legacy macro Handle()"
+            set index -1 ;# to break outer cycle
+            break
+          }
+        }
+        lappend anUpdatedHeaderContent $line
+
+        if { $index < 0 } { 
+          set anUpdatedHeaderContent $aHeaderContent
+          break
+        }
+      }
+      set aHeaderContent $anUpdatedHeaderContent
+    }
+
+    # replace NS::Handle(A) by Handle(NS::A)
+    set anUpdatedHeaderContent {}    
+    set pattern_nshandle {([A-Za-z0-9_]+)\s*::\s*Handle\s*\(\s*([A-Za-z0-9_]+)\s*\)}
+    foreach line $aHeaderContent {
+      set index 0
+
+      while { [regexp -start $index -indices -lineanchor $pattern_nshandle $line location scope class]} {
+        set index [lindex $location 1]
+
+        set scope [eval string range \$line $scope]
+        set class [eval string range \$line $class]
+
+        if { ! $theCheckMode } {
+           set anUpdateHeader true
+          ReplaceSubString line $location "Handle(${scope}::${class})" index
+        } else {
+          logwarn "Warning in $aHeader: usage of Handle macro inside scope is incorrect: [eval string range \$line $location]"
+          set index -1 ;# to break outer cycle
+          break
+        }
+      }
+      lappend anUpdatedHeaderContent $line
+
+      if { $index < 0 } { 
+        set anUpdatedHeaderContent $aHeaderContent
+        break
+      }
+    }
+    set aHeaderContent $anUpdatedHeaderContent
+
+    # remove all forward declarations of Handle classes
+    set anUpdatedHeaderContent {}    
+    set aFwdHandlePattern     {^\s*class\s+Handle[_\(]([A-Za-z0-9_]+)[\)]?\s*\;\s*$}
+    foreach aHeaderContentLine $aHeaderContent {
+      if {[regexp $aFwdHandlePattern $aHeaderContentLine dummy aForwardDeclHandledClass]} {
+        if {$theCheckMode} {
+          loginfo "Info: $aHeader contains statement involving forward decl of Handle_$aForwardDeclHandledClass"
+        } else {
+          # replace by forward declaration of a class or its include unless 
+          # it is already declared or included
+          if { ! [regexp "^\s*\#\s*include\s*\[\<\"\]\s*$aForwardDeclHandledClass\s*\[\>\"\]" $aHeaderContent] } {
+            if { $isQObject } {
+              lappend anUpdatedHeaderContent "#include <${aForwardDeclHandledClass}.hxx>"
+              if { ! [SearchForFile $theIncPaths ${aForwardDeclHandledClass}.hxx] } {
+                loginfo "Warning: include ${aForwardDeclHandledClass}.hxx added in $aHeader, assuming it exists and defines Handle_$aForwardDeclHandledClass"
+              }
+            } elseif { ! [regexp "^\s*class\s+$aForwardDeclHandledClass\s*;" $aHeaderContent] } {
+              lappend anUpdatedHeaderContent "class $aForwardDeclHandledClass;"
+            }
+          }
+          set anUpdateHeader true
+          continue
+        }
+      }
+      lappend anUpdatedHeaderContent $aHeaderContentLine
+    }
+    set aHeaderContent $anUpdatedHeaderContent
+    
+    # remove all typedefs using Handle() macro to generate typedefed name
+    set anUpdatedHeaderContent {}    
+    set aTypedefHandlePattern {^\s*typedef\s+[_A-Za-z\<\>, \s]+\s+Handle\([A-Za-z0-9_]+\)\s*\;\s*$}
+    foreach aHeaderContentLine $aHeaderContent {
+      if {[regexp $aTypedefHandlePattern $aHeaderContentLine aFoundPattern]} {
+        if {$theCheckMode} {
+          loginfo "Info: $aHeader contains typedef using Handle macro to generate name: $aFoundPattern"
+        } else {
+          set anUpdateHeader true
+          continue
+        }
+      }
+      lappend anUpdatedHeaderContent $aHeaderContentLine
+    }
+    set aHeaderContent $anUpdatedHeaderContent
+    
+    # remove all #include statements for files starting with "Handle_"
+    set anUpdatedHeaderContent {}    
+    set anIncHandlePattern    {^\s*\#\s*include\s+[\<\"]\s*(Handle[\(_][A-Za-z0-9_.]+[\)]?)\s*[\>\"]\s*$}
+    foreach aHeaderContentLine $aHeaderContent {
+      if {[regexp $anIncHandlePattern $aHeaderContentLine aFoundPattern anHxxName] &&
+                ! [SearchForFile $theIncPaths $anHxxName]} {
+        if {$theCheckMode} {
+          loginfo "Info: $aHeader includes missing header: $anHxxName"
+        } else {
+          set anUpdateHeader true
+          continue
+        }
+      }
+      lappend anUpdatedHeaderContent $aHeaderContentLine
+    }
+
+    # save result    
+    if {$anUpdateHeader} {
+      SaveListToFile $aHeader $anUpdatedHeaderContent $aHeaderEOL
+    }
+  }
+}
+
+# Replaces C-style casts of Handle object to Handle to derived type 
+# by call to DownCast() method
+proc ConvertCStyleHandleCast {pkpath theExtensions theCheckMode} {
+
+  # iterate by header files
+  foreach afile [glob -nocomplain -type f -directory $pkpath *.\{$theExtensions\}] {
+    set hxx [ReadFileToRawText $afile]
+
+    set change_flag 0
+
+    # replace ((Handle(A)&)b) by Handle(A)::DownCast(b)
+    set index 0
+    set pattern_refcast1 {\(\(\s*Handle\s*\(\s*([A-Za-z0-9_]+)\s*\)\s*[&]\s*\)\s*([A-Za-z0-9_]+)\)}
+    while { [regexp -start $index -indices -lineanchor $pattern_refcast1 $hxx location class var]} {
+      set index [lindex $location 1]
+
+      set class [eval string range \$hxx $class]
+      set var   [eval string range \$hxx $var]
+
+      if { ! $theCheckMode } {
+         set change_flag 1
+        ReplaceSubString hxx $location "Handle($class)::DownCast ($var)" index
+      } else {
+        logwarn "Warning in $afile: C-style cast: [eval string range \$hxx $location]"
+      }
+    }
+
+    # replace  (Handle(A)&)b, by Handle(A)::DownCast(b),
+    # replace  (Handle(A)&)b; by Handle(A)::DownCast(b);
+    # replace  (Handle(A)&)b) by Handle(A)::DownCast(b))
+    set index 0
+    set pattern_refcast2 {\(\s*Handle\s*\(\s*([A-Za-z0-9_]+)\s*\)\s*[&]\s*\)\s*([A-Za-z0-9_]+)(\s*[,;\)])}
+    while { [regexp -start $index -indices -lineanchor $pattern_refcast2 $hxx location class var end]} {
+      set index [lindex $location 1]
+
+      set class [eval string range \$hxx $class]
+      set var   [eval string range \$hxx $var]
+      set end   [eval string range \$hxx $end]
+
+      if { ! $theCheckMode } {
+        set change_flag 1
+        ReplaceSubString hxx $location "Handle($class)::DownCast ($var)$end" index
+      } else {
+        logwarn "Warning in $afile: C-style cast: [eval string range \$hxx $location]"
+      }
+    }
+
+    # replace (*((Handle(A)*)&b)) by Handle(A)::DownCast(b)
+    set index 0
+    set pattern_ptrcast1 {([^A-Za-z0-9_]\s*)\(\s*[*]\s*\(\(Handle\s*\(\s*([A-Za-z0-9_]+)\s*\)\s*[*]\s*\)\s*[&]\s*([A-Za-z0-9_]+)\s*\)\s*\)}
+    while { [regexp -start $index -indices -lineanchor $pattern_ptrcast1 $hxx location start class var] } {
+      set index [lindex $location 1]
+
+      set start [eval string range \$hxx $start]
+      set class [eval string range \$hxx $class]
+      set var   [eval string range \$hxx $var]
+
+      if { ! $theCheckMode } {
+        set change_flag 1
+        ReplaceSubString hxx $location "${start}Handle($class)::DownCast ($var)" index
+      } else {
+        logwarn "Warning in $afile: C-style cast: [eval string range \$hxx $location]"
+      }
+    }
+
+    # replace  *((Handle(A)*)&b)  by Handle(A)::DownCast(b)
+    set index 0
+    set pattern_ptrcast2 {[*]\s*\(\(Handle\s*\(\s*([A-Za-z0-9_]+)\s*\)\s*[*]\s*\)\s*[&]\s*([A-Za-z0-9_]+)\s*\)}
+    while { [regexp -start $index -indices -lineanchor $pattern_ptrcast2 $hxx location class var] } {
+      set index [lindex $location 1]
+
+      set class [eval string range \$hxx $class]
+      set var   [eval string range \$hxx $var]
+
+      if { ! $theCheckMode } {
+        set change_flag 1
+        ReplaceSubString hxx $location "Handle($class)::DownCast ($var)" index
+      } else {
+        logwarn "Warning in $afile: C-style cast: [eval string range \$hxx $location]"
+      }
+    }
+
+    # replace (*(Handle(A)*)&b) by Handle(A)::DownCast(b)
+    set index 0
+    set pattern_ptrcast3 {([^A-Za-z0-9_]\s*)\(\s*[*]\s*\(Handle\s*\(\s*([A-Za-z0-9_]+)\s*\)\s*[*]\s*\)\s*[&]\s*([A-Za-z0-9_]+)\s*\)}
+    while { [regexp -start $index -indices -lineanchor $pattern_ptrcast3 $hxx location start class var] } {
+      set index [lindex $location 1]
+
+      set start [eval string range \$hxx $start]
+      set class [eval string range \$hxx $class]
+      set var   [eval string range \$hxx $var]
+
+      if { ! $theCheckMode } {
+        set change_flag 1
+        ReplaceSubString hxx $location "${start}Handle($class)::DownCast ($var)" index
+      } else {
+        logwarn "Warning in $afile: C-style cast: [eval string range \$hxx $location]"
+      }
+    }
+
+    # replace  *(Handle(A)*)&b,  by Handle(A)::DownCast(b),
+    # replace  *(Handle(A)*)&b;  by Handle(A)::DownCast(b);
+    # replace  *(Handle(A)*)&b)  by Handle(A)::DownCast(b))
+    set index 0
+    set pattern_ptrcast4 {[*]\s*\(Handle\s*\(\s*([A-Za-z0-9_]+)\s*\)\s*[*]\s*\)\s*[&]\s*([A-Za-z0-9_]+)(\s*[,;\)])}
+    while { [regexp -start $index -indices -lineanchor $pattern_ptrcast4 $hxx location class var end] } {
+      set index [lindex $location 1]
+
+      set class [eval string range \$hxx $class]
+      set var   [eval string range \$hxx $var]
+      set end   [eval string range \$hxx $end]
+
+      if { ! $theCheckMode } {
+        set change_flag 1
+        ReplaceSubString hxx $location "Handle($class)::DownCast ($var)$end" index
+      } else {
+        logwarn "Warning in $afile: C-style cast: [eval string range \$hxx $location]"
+      }
+    }
+
+    # just warn if some casts to & are still there
+    set index 0
+    set pattern_refcast0 {\(\s*Handle\s*\(\s*([A-Za-z0-9_]+)\s*\)\s*[&]\s*\)\s*([A-Za-z0-9_]+)}
+    while { [regexp -start $index -indices -lineanchor $pattern_refcast0 $hxx location class var] } {
+      set index [lindex $location 1]
+
+      logwarn "Warning in $afile: C-style cast: [eval string range \$hxx $location]"
+    }
+
+    # replace const Handle(A)& a = Handle(B)::DownCast (b); by 
+    #               Handle(A)  a ( Handle(B)::DownCast (b) );
+    set index 0
+    set pattern_refvar {\mconst\s+Handle\s*\(\s*([A-Za-z0-9_]+)\s*\)\s*[&]\s*([A-Za-z0-9_]+)\s*=\s*(Handle\s*\(\s*[A-Za-z0-9_]+\s*\)\s*::\s*DownCast\s*\([^;]+);}
+    while { [regexp -start $index -indices -lineanchor $pattern_refvar $hxx location class var hexpr] } {
+      set index [lindex $location 1]
+
+      set class [eval string range \$hxx $class]
+      set var   [eval string range \$hxx $var]
+      set hexpr [eval string range \$hxx $hexpr]
+
+      if { ! $theCheckMode } {
+        set change_flag 1
+        ReplaceSubString hxx $location "Handle($class) $var ($hexpr);" index
+      } else {
+        logwarn "Warning in $afile: C-style cast: [eval string range \$hxx $location]"
+      }
+    }
+
+    # apply changes to the header file
+    if { $change_flag } {
+      SaveTextToFile $afile $hxx
+    }
+  }
+}
+
+# Remove unnecessary forward declaration of a class if found immediately before 
+# its use in DEFINE_STANDARD_HANDLE
+proc RemoveFwdClassForDefineStandardHandle {pkpath theCheckMode} {
+
+  # iterate by header files
+  foreach afile [glob -nocomplain -type f -directory $pkpath *.?xx] {
+
+    # load a file
+    if { [catch {set fd [open $afile rb]}] } {
+      logerr "Error: cannot open $afile"
+      continue
+    }
+    set hxx [read $fd]
+    close $fd  
+
+    set change_flag 0
+
+    # replace
+    set index 0
+    set pattern_fwddef {class\s+([A-Za-z0-9_]+)\s*;\s*DEFINE_STANDARD_HANDLE\s*\(\s*([A-Za-z0-9_]+)\s*,\s*([A-Za-z0-9_]+)\s*\)[ \t]*}
+    while { [regexp -start $index -indices -lineanchor $pattern_fwddef $aProcessedFileContent location fwdclass class1 class2] } {
+      set index [lindex $location 1]
+
+      set fwdclass [eval string range \$aProcessedFileContent $fwdclass]
+      set class1   [eval string range \$aProcessedFileContent $class1]
+      set class2   [eval string range \$aProcessedFileContent $class2]
+
+      if { $fwdclass != $class1 } {
+        continue
+      }
+
+      if { ! $theCheckMode } {
+        set change_flag 1
+        ReplaceSubString aProcessedFileContent $location "DEFINE_STANDARD_HANDLE($class1, $class2)" index
+        incr index -1
+      } else {
+        logwarn "Warning: $aProcessedFile contains unnecessary forward declarations of class $fwdclass"
+        break
+      }
+    }
+
+    # apply changes to the header file
+    if { $change_flag } {
+      SaveTextToFile $afile $hxx
+    }
+  }
+}
+
+# auxiliary: modifies variable text_var replacing part defined by two indices
+# given in location by string str, and updates index_var variable to point to
+# the end of the replaced string. Variable flag_var is set to 1.
+proc ReplaceSubString {theSource theLocation theSubstitute theEndIndex} {
+
+  upvar $theSource aSource
+  upvar $theEndIndex anEndIndex
+
+  set aStartIndex [lindex $theLocation 0]
+  set anEndIndex  [lindex $theLocation 1]
+  set aSource  [string replace "$aSource" $aStartIndex $anEndIndex "$theSubstitute"]
+  set anEndIndex [expr $aStartIndex + [string length $theSubstitute]]
+}
+
+# Save theFileContent some text to theFilePath file 
+proc SaveTextToFile {theFilePath theFileContent} {
+  if { [catch {set aFile [open ${theFilePath} w];} aReason] } {
+    logerr "Error: cannot open file \"${theFilePath}\" for writing: $aReason"
+    return
+  }
+
+  fconfigure $aFile -translation binary
+  puts -nonewline $aFile "$theFileContent"
+  close $aFile
+
+  loginfo "File $theFilePath modified"
+}
+
+# read content from theFilePath to list, theFileContent is a raw content of the file
+proc ReadFileToList {theFilePath theFileContent theFileEOL} {
+  upvar $theFileContent aFileContent
+  upvar $theFileEOL  aFileEOL
+
+  if {"$theFilePath" == "" || ![file exists $theFilePath]} {
+    return
+  }
+
+  if { [catch {set aFile [open ${theFilePath} r]} aReason] } {
+    logerr "Error: cannot open file \"${theFilePath}\" for reading: $aReason"
+    return
+  }
+
+  fconfigure $aFile -translation binary
+  set aFileContent [read $aFile]
+  close $aFile
+
+  set aFileEOL "\r"
+  if [regexp "\r\n" $aFileContent] {
+    set aFileEOL "\r\n"
+  } elseif [regexp "\n" $aFileContent] {
+    set aFileEOL "\n"
+  }
+
+  # convert to unix eol
+  if {"$aFileEOL" != "\n"} {
+    regsub -all {$aFileEOL} $aFileContent "\n" aFileContent
+  }
+
+  set aList {}
+  foreach aLine [split $aFileContent "\n"] {
+    lappend aList [string trimright $aLine]
+  }
+
+  return $aList
+}
+
+# read content from theFilePath to raw text (with unix eol)
+proc ReadFileToRawText {theFilePath} {
+  if {"$theFilePath" == "" || ![file exists $theFilePath]} {
+    return
+  }
+
+  if { [catch {set aFile [open ${theFilePath} r]} aReason] } {
+    logerr "Error: cannot open file \"${theFilePath}\" for reading: $aReason"
+    return
+  }
+
+  fconfigure $aFile -translation binary
+  set aFileContent [read $aFile]
+  close $aFile
+
+  set aFileEOL "\r"
+  if [regexp "\r\n" $aFileContent] {
+    set aFileEOL "\r\n"
+  } elseif [regexp "\n" $aFileContent] {
+    set aFileEOL "\n"
+  }
+
+  # convert to unix eol
+  if {"$aFileEOL" != "\n"} {
+    regsub -all {$aFileEOL} $aFileContent "\n" aFileContent
+  }
+
+  return $aFileContent
+}
+
+# auxiliary: saves content of "theData" list to "theFilePath"
+proc SaveListToFile {theFilePath theData {theEOL "auto"}} {
+  set anUsedEol $theEOL
+
+  if {"$anUsedEol" == ""} {
+    set anUsedEol "auto"
+  }
+
+  # if the file exists and "eol choice" is "auto", detect the file eol
+  if {$anUsedEol == "auto" && [file exists $theFilePath]} {
+    if { [catch {set aFile [open ${theFilePath} r]} aReason] } {
+      logerr "Error: cannot open file \"${theFilePath}\" for reading: $aReason"
+    } else {
+      fconfigure $aFile -translation binary
+      set aFileContent [read $aFile]
+      close $aFile
+
+      set anUsedEol "\r"
+      if [regexp "\r\n" $aFileContent] {
+        set anUsedEol "\r\n"
+      } elseif [regexp "\n" $aFileContent] {
+        set anUsedEol "\n"
+      }
+    }
+  }
+
+  # write
+  if { [catch {set aFile [open ${theFilePath} w];} aReason] } {
+    logerr "Error: cannot open file \"${theFilePath}\" for writing: $aReason"
+    return
+  }
+
+  fconfigure $aFile -translation binary
+  puts -nonewline $aFile [join $theData $anUsedEol]
+  close $aFile
+}
+
+# collect all subdirs of theBaseDir
+proc CollectDirStructure {theBaseDir} {
+  set aDirs [glob -nocomplain -directory $theBaseDir -type d *]
+
+  set aSubDirs {}
+  foreach aDir $aDirs {
+    foreach aSubDir [CollectDirStructure $aDir] {
+      lappend aSubDirs $aSubDir
+    }
+  }
+
+  foreach aSubDir $aSubDirs {
+    lappend aDirs $aSubDir
+  }
+
+  return $aDirs
+}
+
+# check existence of theFileName file in several folders (theIncPaths)
+proc SearchForFile {theIncPaths theFileName} {
+  foreach aPath $theIncPaths {
+    if {[file exists "${aPath}/${theFileName}"]} {
+      return true
+    }
+  }
+
+  return false
+}
+
+# auxiliary: parse the string to comment and not comment parts
+# variable "_cmnt" should be created before using the operation, it will save comment part of line
+# variable "_isMulti" should be created before the loop, equal to "false" if first line in the loop is not multi-comment line
+proc _check_line { line } {
+  upvar _isMulti _isMulti
+  upvar _cmnt _cmnt
+
+  set string_length [string length $line]
+  set c_b $string_length
+  set mc_b $string_length
+  set mc_e $string_length
+  regexp -indices {//} $line c_b
+  regexp -indices {/\*} $line mc_b
+  regexp -indices {\*/} $line mc_e
+  if {!${_isMulti}} {
+    if {[lindex $c_b 0] < [lindex $mc_b 0] && [lindex $c_b 0] < [lindex $mc_e 0]} {
+      set notComment_c [string range $line 0 [expr [lindex $c_b 0]-1]]
+      set Comment_c [string range $line [lindex $c_b 0] end]
+      set _cmnt $_cmnt$Comment_c
+      return $notComment_c
+    } elseif {[lindex $mc_b 0] < [lindex $c_b 0] && [lindex $mc_b 0] < [lindex $mc_e 0]} {
+      set _isMulti true
+      set _cmnt "${_cmnt}/*"
+      set notComment_mc [string range $line 0 [expr [lindex $mc_b 0]-1]]
+      set Comment_mc [string range $line [expr [lindex $mc_b 1]+1] end]
+      return [_check_line "${notComment_mc}[_check_line ${Comment_mc}]"]
+    } elseif {[lindex $mc_e 0] < [lindex $c_b 0] && [lindex $mc_e 0] < [lindex $mc_b 0]} {
+      set notComment_mc [string range $line [expr [lindex $mc_e 1]+1] end]
+      set Comment_mc [string range $line 0 [expr [lindex $mc_e 0]-1]]
+      set _cmnt "${_cmnt}${Comment_mc}*/"
+      set chk [_check_line ${notComment_mc}]
+      set _isMulti true
+      return $chk
+    }
+  } else {
+    if {[lindex $mc_e 0] < [lindex $mc_b 0]} {
+      set _isMulti false
+      set Comment_mc [string range $line 0 [lindex $mc_e 1]]
+      set notComment_mc [string range $line [expr [lindex $mc_e 1]+1] end]
+      set _cmnt $_cmnt$Comment_mc
+      return [_check_line $notComment_mc]
+    } elseif {[lindex $mc_b 0] < [lindex $mc_e 0] } {
+      set notComment_mc [string range $line 0 [expr [lindex $mc_b 0]-1]]
+      set Comment_mc [string range $line [expr [lindex $mc_b 1]+1] end]
+      set _cmnt "${_cmnt}/*"
+      set chk [_check_line "${notComment_mc}[_check_line ${Comment_mc}]"]
+      set _isMulti false
+      return $chk
+    } else {
+      set _cmnt $_cmnt$line
+      return ""
+    }
+  }
+  return $line
+}
+
+# Create Tk-based logger which allows convenient consulting the upgrade process.
+proc _create_logger {} {
+    if { [catch {winfo exists .h}] } {
+        logerr "Error: Tk commands are not available, cannot create UI!"
+        return
+    }
+
+    if { ![winfo exists .h ] } {
+        toplevel .h
+        wm title .h "Conversion log"
+        wm geometry .h +320+200
+        wm resizable .h 0 0
+
+        text .h.t -yscrollcommand {.h.sbar set}
+        scrollbar .h.sbar -orient vertical -command {.h.t yview}
+
+        pack .h.sbar -side right -fill y
+        pack .h.t
+    }
+}
+
+set LogFilePath ""
+
+# Puts the passed string into Tk-based logger highlighting it with the
+# given color for better view. If no logger exists (-wlog option was not
+# activated), the standard output is used.
+proc _logcommon {theLogMessage {theMessageColor ""}} {
+  global LogFilePath
+
+  if {"$LogFilePath" != ""} {
+    if { ! [catch {set aLogFile [open ${LogFilePath} a];} aReason] } {
+      set t [clock milliseconds]
+      set aTimeAndMessage [format "\[%s\] %s" \
+                            [clock format [expr {$t / 1000}] -format %T] \
+                            $theLogMessage \
+                          ]
+
+
+      puts $aLogFile $aTimeAndMessage
+      close $aLogFile
+    } else {
+      logerr "Error: cannot open $LogFilePath log file due to $aReason"
+    }
+  }
+
+  if { ! [catch {winfo exists .h} res] && $res } {
+      .h.t insert end "$theLogMessage\n"
+
+    if {$theLogMessage != ""} {
+      # We use the current number of lines to generate unique tag in the text
+      set aLineNb [lindex [split [.h.t index "end - 1 line"] "."] 0]
+
+      .h.t tag add my_tag_$aLineNb end-2l end-1l
+      .h.t tag configure my_tag_$aLineNb -background $theMessageColor
+    }
+
+    update
+  } else {
+    puts $theLogMessage
+  }
+}
+
+# Puts information message to logger.
+proc loginfo {a} {
+    _logcommon $a
+}
+
+# Puts warning message to logger.
+proc logwarn {a} {
+    _logcommon $a "pink"
+}
+
+# Puts error message to logger.
+proc logerr {a} {
+    _logcommon $a "red"
+}
index 49221cc..7db38e4 100644 (file)
@@ -45,8 +45,7 @@ dev_guides/contribution_workflow/contribution_workflow.md
 dev_guides/git_guide/git_guide.md
 dev_guides/tests/tests.md
 dev_guides/debug/debug.md
-dev_guides/cdl/cdl.md
-dev_guides/wok/wok.md
+dev_guides/upgrade/upgrade.md
 
 dev_guides/building/building.md
 dev_guides/building/3rdparty/3rdparty_windows.md
@@ -60,6 +59,4 @@ dev_guides/building/code_blocks.md
 dev_guides/building/msvc.md
 dev_guides/building/xcode.md
 
-dev_guides/upgrade/upgrade.md
-
 license.md
index fae962c..3d1d797 100644 (file)
@@ -28,7 +28,6 @@ dev_guides/documentation/documentation.md
 dev_guides/contribution/coding_rules.md
 dev_guides/git_guide/git_guide.md
 dev_guides/tests/tests.md
-dev_guides/wok/wok.md
-dev_guides/cdl/cdl.md
+dev_guides/upgrade/upgrade.md
 
 tutorial/tutorial.md
diff --git a/dox/dev_guides/cdl/cdl.md b/dox/dev_guides/cdl/cdl.md
deleted file mode 100644 (file)
index 412c9a8..0000000
+++ /dev/null
@@ -1,1846 +0,0 @@
- Component Definition Language (CDL)  {#occt_dev_guides__cdl}
-==============================
-
-@tableofcontents
-
-@section occt_cdl_0 DEPRECATION WARNING
-
-Please note that CDL is considered as obsolete and is to be removed in one of future releases of OCCT.
-
-@section occt_cdl_1 CDL and Application Architecture
-
-CDL is the component  definition language of the Open CASCADE Technology (**OCCT**) programming  platform. Some components, which CDL allows you to create, are specific to OCCT  application architecture. These and other components, which you can define  using CDL include the following: 
-
-  * Class (including enumeration,  exception)
-  * Package
-  * Schema
-  * Executable
-  * Client.
-  
-A **class** is the  fundamental software component in object-oriented development. Because of a  very large number of resources used in large-scale applications, the **class** itself  is too small to be used as a basic management unit. 
-
-So, while the class is  the basic data component defined in CDL, this language also provides a way to  group classes, **enumerations**, and **exceptions** together – the **package**.  A package groups together a number of classes, which have semantic links. For  example, a geometry package would contain Point, Line, and Circle classes. A  package can also contain enumerations, exceptions, and package methods. In  practice, a class name is prefixed with the name of its package e.g.  *Geom_Circle*. 
-
-Using the services  described in the **packages**, you can construct an **executable**. You  can also group together services provided by **packages**.  
-
-To save data in a file,  you need to define persistent classes. Then, you group these classes in a  schema, which provides the necessary read/write tools. 
-
-
-@image html /dev_guides/cdl/images/cdl_image003.png "Building  an Open CASCADE Technology application" 
-@image latex /dev_guides/cdl/images/cdl_image003.png "Building  an Open CASCADE Technology application" 
-    
-@section occt_cdl_2 Introduction to  CDL
-@subsection occt_cdl_2_1  Purposes of the Language
-
-You can use CDL to **define** **data** in the Open CASCADE Technology environment. CDL allows you to define  various kinds of data types supporting the application architecture and  development methodology, which you envision. CDL is neither an analysis  formalism (e.g. Booch methodology) nor a data manipulation language (e.g. C++). 
-
-You use CDL in the **design** **phase** of a development process to define a set of software components which  best model the concepts stated in the application specification. 
-
-@image html /dev_guides/cdl/images/cdl_image004.png "The Development Process" 
-@image latex /dev_guides/cdl/images/cdl_image004.png "The Development Process" 
-
-
-From a structural point  of view, CDL is an object-oriented language. It is centered on the notion of  the **class** - a data type, which represents an elementary concept. CDL  offers various means of organizing classes, mostly under the fundamental form  of **packages**. A package contains a set of classes, which share some  semantic relationship. This greatly simplifies your task of managing individual  classes when confronted with a very large number of them. 
-
-Once you have defined  the classes and packages using CDL, you can implement their **methods** -  i.e., their functionality - in one of the data manipulation languages supported  by the OCCT environment (currently C++). 
-
-Even though you can describe classes directly in C++  and save them as header files (.hxx), to do so would forfeit all the advantages  of using CDL. These are: 
-
-  * Precise, complete, and  easy-to-read description of the software components.
-  * Creation of a link with the  database; object persistence forms part of the predefined environment of the  language.
-  * Multi-language access to the  services of an application engine – a specific architectural form created using  the CDL tools, which serves as the motor of an application.
-  
-@subsection occt_cdl_2_2   Overview of CDL
-
-CDL is an object-oriented  language. In other words, it structures a system around data types rather than  around the actions carried out on them. In this context, an **object** is an  **instance** of a data type, and its definition determines how you can use  it. Each data type is implemented by one or more classes, which make up the  basic elements of the system. 
-
-@subsubsection occt_cdl_2_2_1    Classes
-
-A class is an  implementation of a **data type**. It defines its **behavior** and its **representation**. 
-
-The behavior of a class  is its programming interface - the services offered by its **methods**. The  representation of a class is its data structure - the **fields**, which  store its data. 
-
-Every object is an **instance** of its class. For example, the object *p* of the data type *Point* is  an instance of the class *Point*. 
-
-The class Point could be  defined as in the example below: 
-
-@code
-class Point from  GeomPack
-    ---Purpose: represents a point in 3D space.
-   is
-    Create returns Point;
-fields
-    x, y, z : Real;
-end Point; 
-@endcode
-
-The definition of this class comprises two sections: 
-
-  * one starting with the  keywords **is**
-  * one starting with the keyword  **fields**.
-
-The first section  contains a list of methods available to the clients of the class. The second  section defines the way in which instances are represented. Once this class has  been compiled you could **instantiate** its data type in a C++ test program  as in the example below: 
-
-
-
-@code
-GeomPack_Point p;
-@endcode
-
-
-@subsubsection occt_cdl_2_2_2     Categories of Types
-
-You declare the  variables of a **data manipulation language** as being of certain data  types. These fall into two categories: 
-
-  * Data types manipulated by  handle (or reference)
-  * Data types manipulated by  value
-  
-    @image html /dev_guides/cdl/images/cdl_image005.png "Manipulation of data types" 
-    @image latex /dev_guides/cdl/images/cdl_image005.png  "Manipulation of data types" 
-
-As seen above, you  implement data types using classes. However, classes not only define their data  representation and methods available for their instances, but they also define  how the instances will be manipulated: 
-  * A data type manipulated by  value contains the instance itself.
-  * A data type manipulated by  handle contains a reference to the instance.
-
-The most obvious  examples of data types manipulated by value are the predefined **primitive  types**: Boolean, Character, Integer, Real... 
-
-A variable of a data  type manipulated by handle, which is not attached to an object, is said to be **null**.  To reference an object, you need to instantiate the class with one of its  constructors. This is done in C++ as in the following syntax: 
-
-~~~~~
-Handle(myClass) m = new myClass;
-~~~~~
-
-
-@subsubsection occt_cdl_2_2_3     Persistence
-
-An object is called **persistent** if it can be permanently stored. In other words, you can use the object  again at a later date, both in the application, which created it, and in  another application. 
-
-In order to make an  object persistent, you need to declare it in CDL as inheriting from the **Persistent**  class, or to have one of its parent classes inheriting from the *Persistent* class. 
-
-Note that the classes  inheriting from the *Persistent* class are handled by reference. 
-
-**Example** 
-~~~~~
-class Watch inherits Persistent
-~~~~~
-
-In this example,  building the application, you add the *Watch* class to the corresponding schema  of data types. 
-If, running the  application, you instantiate an object of the *Watch* class, you have the  possibility of storing it in a file. 
-You cannot store objects  instantiated from classes, which inherit from the *Storable* class.  However, you can store them as fields of an object, which inherits from  *Persistent*. 
-
-Note that the objects  inheriting from Storable are handled by value. 
-
-**Example** 
-~~~~~
-If 
-class WatchSpring  inherits Storable 
-//then this could be  stored as a field of a Watch 
-//object: 
-class Watch inherits  Persistent 
-is...... 
-fields 
-name :  ConstructorName; 
-powersource :  WatchSpring; 
-end; 
-~~~~~
-
-@subsubsection occt_cdl_2_2_4    Packages
-
-In large-scale long-term  development the task of marshalling potentially thousands of classes is likely  to quickly prove unmanageable. CDL introduces the notion of **package** of  classes containing a set of classes, which have some semantic or syntactic  relationship. For example, all classes representing a particular set of  electronic components might make up a package called Diode. 
-
-As the package name  prefixes the class name when implementing such class (in C++ for example),  classes belonging to different packages can have the same name. For example,  two packages, one dealing with finance and the other dealing with aircraft  maneuvers, might both contain a class called *Bank*, without any possibility of  confusion. 
-
-**Example** 
-~~~~~
-Finance_Bank 
-Attitude_Bank 
-~~~~~
-
-
-@subsubsection occt_cdl_2_2_5     Inheritance
-
-The purpose of  inheritance is to reduce development workload. The inheritance mechanisms allow  you to declare a new class as already containing the characteristics of an  existing class. This new class can then be rapidly specialized for a task at  hand. This eliminates the necessity of developing each component “from  scratch”. 
-
-For example, having  already developed a class *BankAccount*, you can quickly specialize new classes -  *SavingsAccount, LongTermDepositAccount, MoneyMarketAccount,  RevolvingCreditAccount*, etc.. 
-
-As a consequence, when  two or more classes inherit from a parent (or ancestor) class, all these  classes surely inherit the behavior of their parent (or ancestor). For example,  if the parent class *BankAccount* contains the method *Print* that tells it to  print itself out, then all its descendent classes offer the same service. 
-
-One way of ensuring the  use of inheritance is to declare classes at the top of a hierarchy as being **deferred**.  In such classes, the inherited methods are not implemented. This forces you to  create a new class used to redefine the methods. In this way, you guarantee a  certain minimum common behavior among descendent classes. 
-
-**Example** 
-~~~~~
-deferred class BankAccount inherits Persistent 
-is 
-....... 
-fields 
-name :  AccountHolderName; 
-balance : CreditBalance; 
-end; 
-~~~~~
-
-@subsubsection occt_cdl_2_2_6     Genericity
-
-You will often wish to  model a certain type of behavior as a class. For example, you will need a list  modeled as a class. 
-
-In order to be able to  list different objects, the class *List* must be able to accept different  data types as parameters. This is where genericity comes in: you first declare  a list declared as the generic class *List*, willing to accept any data  type (or only a particular set of acceptable data types). Then, when you want  to make a list of a certain type of object, you instantiate the class *List* with  the appropriate data type. 
-
-**Example** 
-
-~~~~~
-generic class NewList (Item) 
-inherits OldList 
-is 
-..... 
-end ; 
-~~~~~
-
-Items may be of any  type, an Integer or a Real for example. 
-
-When defining the  package, add the following line: 
-**Example** 
-~~~~~
-class NewListOfInteger instantiates 
-NewList (Integer); 
-~~~~~
-
-@subsubsection occt_cdl_2_2_7     Exceptions
-
-The behavior of any  object is implemented by methods, which you define in its class declaration.  The definition of these methods includes not only their signature (their  programming interface) but also their domain of validity. 
-
-In CDL, this domain is  expressed by **exceptions**. Exceptions are raised under various error  conditions. This mechanism is a safeguard of software quality. 
-
-@subsubsection occt_cdl_2_2_8     Completeness
-
-You use CDL to define  data types. Such definitions are not considered complete unless they contain  the required amount of structured commentary. 
-
-The compiler does not  enforce this required degree of completeness, so it is the responsibility of  the developer to ensure that all CDL codes are properly annotated. 
-
-Completeness is regarded  as an essential component of long-term viability of a software component. 
-
-
-@subsection occt_cdl_2_3   Lexical Conventions
-@subsubsection occt_cdl_2_3_1    Syntax  notation
-
-In this manual, CDL  declarations are described using a simple variant of the Backus-Naur formalism.  Note the following: 
-
-  * Italicized words, which may  also be hyphenated, denote syntactical categories, for example *declaration-of-a-non-generic-class* ;
-  * Keywords appear in bold type: **class** ;
-  * Brackets enclose optional  elements: 
-~~~~~
-  identifier [from package-name] 
-~~~~~
-  * Curly braces enclose repeated  elements. The element may appear zero or many times: 
-~~~~~  
-  integer ::=  digit{digit} 
-~~~~~
-  * Vertical bars separate  alternatives:
-~~~~~
-passing-method ::=  <b>[in] | out | in out </b> 
-~~~~~
-  * Two apostrophes enclose a  character or a string of characters, which must appear:
-~~~~~
-exponent ::=  ’E’[’+’]integer | ’E-’ integer 
-~~~~~
-**NOTE** To introduce the ideas progressively, the  examples presented in this manual may be incomplete, and thus not compilable by  the CDL compiler. 
-
-
-@subsubsection occt_cdl_2_3_2    Lexical  elements
-
-A CDL source is composed  of text from one or more compiled units. The text of each compiled unit is a  string of separate lexical elements: **identifiers**, **keywords**, **constants**,  and **separators**. The separators (blank spaces, end of line, format  characters) are ignored by the CDL compiler, but these are often necessary for  separating identifiers, keywords, and constants. 
-
-
-@subsubsection occt_cdl_2_3_3     Comments
-
-With CDL, you cannot use  the expression of all useful information about a development unit. In  particular, certain information is more easily expressed in natural language.  You can add such information to the CDL description of a data type. 
-
-Rubrics and free  comments are to be differentiated: 
-
-**Free comments** are preceded by the characters “--” (two  hyphens), and they terminate at the end of the line in which they appear. 
-**Example** 
-~~~~~
---This is a comment 
-~~~~~
-
-Unlike rubrics, free  comments can appear before or after any lexical element. The first written  character of the comment itself *must not* be a hyphen. If a hyphen is  necessary make sure it is preceded by a blank. 
-**Example** 
-~~~~~
--- -List item 
-~~~~~
-**Rubrics** are various types of comments attached to CDL components.  A rubric is a comment made up of three hyphens, name of the rubric (without any  intermediary space) and then a colon and a space. It is terminated by the  beginning of the following rubric, or by the end of the commentary. 
-
-**Example** 
-~~~~~
----Purpose:This is an example of a 
---rubric composed of a 
---comment which extends to 
---four lines. 
-~~~~~
-
-The different categories  of rubrics and the form of their content do not depend on the Component  Description Language, but on the tool for which it is intended.  
-
-The use of commentary is  generally governed by the internal programming standards of an enterprise. You  are encouraged to use various well-defined rubrics, such as Purpose, Warning,  Example, References, Keywords, etc. 
-
-These rubrics can be  attached to: 
-
-  * Packages
-  * Classes
-  * Methods
-  * Schemas
-  * Executables
-  * Clients
-
-@subsubsection occt_cdl_2_3_4     Identifiers
-
-An identifier is an  arbitrary chain of characters, either letters or digits, but it must begin with  a letter. 
-
-The underscore “_” is  considered to be a letter as long as it doesn’t appear at the beginning or the  end of an identifier. 
-
-Capital and small  letters are not equivalent (i.e. AB, Ab, aB, ab are four different  identifiers). 
-
-
-@subsubsection occt_cdl_2_3_5     Keywords
-
-The following is a list  of keywords. 
-
-* alias 
-* any                    
-* as                     
-* asynchronous 
-* class                     
-* client                 
-* deferred            
-* end 
-* enumeration           
-* exception           
-* executable        
-* external 
-* fields                     
-* friends               
-* from                 
-* generic 
-* immutable              
-* imported            
-* inherits              
-* instantiates 
-* is                          
-* library                
-* like                   
-* me 
-* mutable                 
-* myclass             
-* out                   
-* package 
-* pointer                   
-* primitive             
-* private              
-* protected 
-* raises                    
-* redefined           
-* returns              
-* schema 
-* static                     
-* to                      
-* uses                 
-* virtual 
-
-In a CDL file, the  following characters are used as punctuation: 
-; : , = ( ) [ ] ‘ “ 
-
-@subsubsection occt_cdl_2_3_6     Constants
-
-There are three  categories of constants: 
-
-  * Numeric
-  * Literal
-  * Named
-
-#### Numeric Constants
-
-There are two types of  numeric constants: integer and real. 
-
-An **integer** constant  consists of a string of digits, which may or may not be preceded by a sign.  Integer constants express whole numbers. 
-
-**Examples** 
-~~~~~
-1995         0            -273         +78 
-~~~~~
-A **real** constant  may or may not be preceded by a sign, and consists of an integral part followed  by a decimal point and a fractional part (either one or both parts may be null,  but both parts must always be present). It may also be followed by the letter E  to indicate that the following figures represent the exponent (also optionally  signed). 
-
-**Examples** 
-~~~~~
-5.0        0.0           -0.8E+3          5.67E-12 
-~~~~~
-#### Literal Constants
-
-Literal constants  include individual characters and strings of characters. 
-
-An **individual  character** constant is a single printable character enclosed by two  apostrophes. (See the definition of the class Character in the Standard  Package). 
-
-**Examples** 
-~~~~~
- ‘B’       ‘y’      ‘&amp;’      ‘*’      ‘’’ ‘‘ 
-~~~~~
-A **string** constant  is composed of printable characters enclosed by quotation marks. 
-
-**Examples** 
-~~~~~
-’’G’’     ’’jjjj’’      ’’This is a character string, isn’t it?’’ 
-~~~~~
-The **quotation mark** can  itself appear within a character string as long as it is preceded by a  backslash. 
-
-**Examples** 
-~~~~~
-’’This film was  originally called \’’Gone with the Tide\’’.’’ 
-~~~~~
-
-#### Named Constants
-
-Named constants are  sub-divided into two categories: Booleans and enumerations. 
-
-**Booleans** can be of two types: True or False. 
-
-An **enumeration** constant  is an identifier, which appears in the description of an enumeration. 
-
-@section occt_cdl_3 Software  Components
-
-@subsection occt_cdl_3_1   Predefined Resources
-@subsubsection occt_cdl_3_1_1     Primitive types
-
-Primitive types are  predefined in the language and they are **manipulated by value**. 
-
-Four of these primitives  are known to the schema of the database because they inherit from the class **Storable**.  In other words, they can be used in the implementation of persistent objects,  either when contained in entities declared within the methods of the object, or  when they form part of the internal representation of the object. 
-
-The primitives inheriting  from **Storable** are the following: 
-
-* **Boolean** Is used to represent logical data. It has only  two values: *True* and *False*. 
-* **Byte** 8-bit number. 
-* **Character** Designates any ASCII character. 
-* **ExtCharacter** Is an extended character. 
-* **Integer** Is an integer number. 
-* **Real** Denotes a real number (i.e. one with a whole and  a fractional part, either of which may be null). 
-* **ShortReal** Real with a smaller choice of values and memory  size. 
-
-There are also  non-storable primitives. They are: 
-
-* **CString** Is used for literal constants. 
-* **ExtString** Is an extended string. 
-* **Address** Represents a byte address of undetermined size. 
-
-The services offered by  each of these types are described in the Standard Package. 
-
-
-@subsubsection occt_cdl_3_1_2     Manipulating types by reference (by handle)
-
-Two types are  manipulated by handle: 
-
-  * Types defined using classes  inheriting from the **Persistent** class are storable in a file.
-  * Types defined using classes  inheriting from the **Transient** class.
-  
-These types are not storable as such in a file. 
-
-@image html /dev_guides/cdl/images/cdl_image006.png "Manipulation of a data type by reference"
-@image latex /dev_guides/cdl/images/cdl_image006.png "Manipulation of a data type by reference"
-
-
-@subsubsection occt_cdl_3_1_3     Manipulating types by value
-
-Types, which are  manipulated by value, behave in a more direct fashion than those manipulated by  handle. As a consequence, they can be expected to perform operations faster,  but they cannot be stored independently in a file. 
-
-You can store types  known to the schema (i.e. either primitives or inheriting from Storable) and  manipulated by value inside a persistent object as part of the representation.  This is the only way for you to store objects “manipulated by value” in a file. 
-
-@image html /dev_guides/cdl/images/cdl_image007.png "Manipulation of a data type by value" 
-@image latex /dev_guides/cdl/images/cdl_image007.png "Manipulation of a data type by value" 
-
-Three types are  manipulated by value: 
-
-  * Primitive types
-  * Enumerated types
-  * Types defined by classes not  inheriting from Persistent or Transient, whether directly or not
-
-@subsubsection occt_cdl_3_1_4   Summary  of properties
-
-
-Here is a summary of how various data types are handled and their  storability:
-| | Manipulated by handle | Manipulated by value |
-| :---- | :---- | :---- |
-| storable | Persistent | Primitive, Storable (storable if nested in a persistent class) |
-| temporary | Transient | Other | 
-
-
-
-
-@subsection occt_cdl_3_2   Classes
-
-@subsubsection occt_cdl_3_2_1    Class  declaration
-
-The class is the main  system for creating data types under CDL. By analyzing any CDL-based software,  you find that classes are the modular units that make up packages. When you  describe a new class, you introduce a new data type. 
-
-Whatever the category of  the described type (manipulated by value, Storable or not, manipulated by  handle, Persistent or not) the structure of the class definition remains the  same. The syntax below illustrates it: 
-
-~~~~~
--- declaration-of-a-simple-class ::= 
-class class-name from package-name 
-[uses data-type {  ’,’ data-type } ] 
-[raises  exception-name { ’,’ exception-name} ] 
-is class-definition 
-end [ class-name ]  ’;’ 
-data-type ::=  enumeration-name | class-name | 
-exception-name | primitive-type 
-package-name ::=  identifier 
-class-name ::=  identifier 
-class-definition ::= 
-[{member-method}] 
-[declaration-of-fields] 
-[declaration-of-friends] 
-~~~~~
-Class name becomes a new  data type, which you can use inside its own definition. Other types appearing  in the definition must either be primitive types, previously declared classes,  exceptions, or enumerations. 
-
-Apart from the types  defined in the Standard Package, which are **implicitly visible** everywhere,  you need to declare the data types after the keyword **uses**. This concerns  both the class behavior and its internal representation. 
-
-**Exceptions** are declared after the word **raises**. 
-
-**Example** 
-~~~~~
-class Line from  GeomPack 
-usesPoint,  Direction, Transformation 
-raisesNullDirection,  IdenticalPoints 
-is-- class  definition follows here 
--- using Point,  Direction and 
--- Transformation  objects,and the 
--- NullDirection and  Identical- 
--- -Points  exceptions. 
-end Line; 
-~~~~~
-
-The elements, which make  up the definition of a class, are divided into four parts: 
-  * the behavior
-  * the invariants
-  * the internal representation
-  * the friend methods and friend  classes.
-
-    @image html /dev_guides/cdl/images/cdl_image009.png "Contents of a class"
-    @image latex /dev_guides/cdl/images/cdl_image009.png "Contents of a class"
-
-@subsubsection occt_cdl_3_2_2     Categories of classes
-
-Classes fall into three categories: 
-  * Ordinary classes
-  * Deferred classes
-  * Generic classes
-
-#### Deferred classes
-
-The principal  characteristic of a **deferred class** is that you cannot instantiate it.  Its purpose is to provide a given behavior shared by a hierarchy of  classes and dependent on the implementation of the descendents. This allows guaranteeing a certain base of inherited behavior common to all classes based on a particular deferred class. Deferred classes are declared as in the  following syntax: 
-
-~~~~~
--- declaration-of-a-deferred-class ::= deferred class  class-name 
-[inherits class-name  {’,’ class-name}] 
-[uses data-type {’,’  data-type}] 
-[raises exception-name  {’,’ exception-name}] 
-       is class-definition 
-       end [class-name]’;’ 
-~~~~~
-Please, note that a deferred class does not have to contain a  constructor
-
-<h4>Generic classes</h4>
-
-The principal  characteristic of a **generic class** is that it offers a set of  functional behavior to manipulate other data types. To instantiate  a generic class you need to pass a data type in argument. Generic classes are  declared as in the following syntax: 
-
-~~~~~
--- declaration-of-a-generic-class ::= [deferred] generic  class class-name ’(’generic-type {’,’generic-type}’)’ 
-[inheritsclass-name {’,’ class-name}] 
-[usesdata-type {’,’  data-type}] 
-[raisesexception-name  {’,’ exception-name}] 
-[{[visibility]  declaration-of-a-class}] 
-       is class-definition 
-       end [class-name]’;’ 
-generic-type ::=  identifier as type-constraint 
-identifier ::=  letter{[underscore]alphanumeric} 
-type-constraint ::= any | class-name [’(’data-type {’,’ data-type}’)’] 
-~~~~~
-
-
-@subsection occt_cdl_3_3   Packages
-
-@subsubsection occt_cdl_3_3_1    Package  declaration
-
-**Packages** are  used to group   classes, which have some logical coherence. For example, the  Standard Package groups together all the predefined resources of the language.  In its simplest form, a package contains the declaration of all data types,  which it introduces. You may also use a package to offer public methods and  hide its internal classes by declaring them private. 
-
-**Example** 
-
-~~~~~
--- package-declaration ::= package package-name 
-       [uses package-name {’,’ package-name}] 
-       is package-definition 
-       end [package-name]’;’ 
--- package-name ::= identifier 
--- package-definition ::= 
-       [{type-declaration}] 
-       [{package-method}] 
--- type-declaration ::= 
-       [private] declaration-of-an-enumeration |       [private] declaration-of-a-class |      declaration-of-an-exception 
--- package-method ::= identifier [simple-formal-part][returned-type -declaration] 
-[error-declaration] 
-[is private]’;’ 
-~~~~~
-
-The data types described  in a package *may* include one or more of the following data types: 
-  * Enumerations
-  * Object classes
-  * Exceptions
-  * Pointers to other object  classes.
-
-Inside a package, two  data types *cannot* have the same name. 
-
-You declare data types  before using them in the definition of other data types. 
-
-When two classes are **mutually  recursive**, one of the two must be first declared in an incomplete  fashion. 
-
-Grouped behind the  keyword **uses** are the names of all the packages containing definitions of  classes of which the newly introduced data types are clients. 
-
-The methods you declare  in a package do not belong to any particular class. **Package methods** must carry a name different from the data types contained in the package. Like  any other method, they can be overloaded. With the exception of the keyword **me** and the visibility (a package method can *only* be either public or  private) package methods are described in the same way as **instance methods**. 
-
-@image html /dev_guides/cdl/images/cdl_image010.png "Contents of a package" 
-@image latex /dev_guides/cdl/images/cdl_image010.png "Contents of a package" 
-
-
-The example of the package below includes some of the basic data structures: 
-
-~~~~~
-package Collection 
-       uses 
-       Standard 
-       is 
-exception NoSuchObject inherits Failure; 
-exception NoMoreObject inherits Failure; 
-generic class SingleList; 
-generic class Set; 
-end Collection; 
-~~~~~
-
-Note that the class *Set* is declared after the declarations of the *NoSuchObject* and *NoMoreObject*  exceptions and the *SingleList* class of which Set is a client. In the same way, the classes *Failure*, *Persistent*, and the exception *NoSuchObject* are defined before they are used. They are  defined in the *Standard* package, which appears after the keyword **uses**. 
-
-@subsubsection occt_cdl_3_3_2    Name space
-
-The **name space** or  **scope** of a class extends from the beginning of its declaration up to the  end of the package in which it appears. 
-
-Sometimes, two classes,  which come from separate packages, are both visible to a third package and  carry the same name. For example, there might be two different classes both  called “Window” in a screen generator package and in an architectural package.  As a client of a data type, you can find yourself in the position of having to  remove the ambiguity over the origin of this type; you do this by means of the  keyword **from**.
-
-~~~~~
--- class-name ::= identifier [from package-name] 
--- exception-name ::= identifier [from package-name] 
--- enumeration-name ::= identifier [from package-name] 
-~~~~~
-
-You can use the keyword **from** everywhere the name of a class, exception, or enumeration appears. As a  consequence, as a client of the class “Window” you could write wherever  necessary: 
-
-~~~~~
-Window from ScreenGenerator 
--- or 
-Window from ArchitecturalFeatures 
-~~~~~
-
-**Note** that within the description of a package the keyword **from** must be used when referencing any data type  that is not defined in this package.
-
-Here is a further  example: 
-
-~~~~~
-class Line from Geom 
-uses 
-       Point from Geom2d, 
-       Point from Geom3d 
-is 
-       -- class definition  using Point from AppropriatePackage wherever Point  appears 
-end; 
-~~~~~
-
-@subsubsection occt_cdl_3_3_3     Declaration of classes
-
-You cannot describe a  package in one single file. You need to describe it in different units and send  them separately to the CDL compiler. Each compilation unit can contain the  declaration of a class or of a package. When you describe a class in a unit  different than that, which describes its package, you need to specify which  package the class belongs to. You do this using the keyword **from**. 
-
-If the **from** clause  appears in the **uses** clause of the package, it does not need to be  repeated elsewhere. 
-
-The following example  takes the package “Collection” which was presented above, but this time it is  divided into three compilation units. 
-
-~~~~~
--- First compilation unit, the package “Collection” : 
-package Collection 
-       uses 
-       Standard 
-       is 
-exception  NoMoreObject inherits Failure from Standard; 
-exception NoSuchObject inherits Failure from Standard; 
-generic class SingleList; 
-generic class Set, Node, Iterator; 
-end Collection; 
--- Second compilation unit, the class “SingleList” : 
-generic class SingleList from Collection (Item as 
-Storable) 
-       inherits 
-               Persistent from Standard 
-               raises 
-               NoSuchObject from  Collection 
-               is 
-               -- definition of the  SingleList class 
-       end SingleList; 
--- Third compilation unit, the class “Set” : 
-generic class Set from Collection (Item as Storable) 
-       inherits 
-               Persistent from Standard; 
-       raises 
-               NoSuchObject from Collection, 
-               NoMoreObject from  Collection 
-               private class Node  instantiates SingleList 
-               from Collection  (Item); 
- end Set; 
-~~~~~
-
-NOTE 
-It is not explicitly stated that the *Node* class  belongs to the *Collection* package. In fact any nested class necessarily  belongs to the package of the class, which encompasses it. 
-
-Note that a package can  hide certain classes (just as it can hide methods) by declaring them **private**.  To make a class private, you prefix its description with the keyword **private**.  In the example of the *Collection* package, the *SingleList* class serves only  to implement the *Set* class. It is recommended to make it private. You write  this as in the following syntax: 
-
-
-**Example** 
-~~~~~
-package Collection 
-       uses 
-       Standard 
-       is 
-generic class Set,  Node, Iterator; 
-private generic class SingleList; 
-exception NoMoreObject inherits Failure from Standard; 
-end Collection; 
-~~~~~
-
-
-
-@subsection occt_cdl_3_4   Other Data Types
-
-The other data types are: 
-  * Enumerations
-  * Imports
-  * Aliases
-  * Exceptions
-  * Pointers
-
-@subsubsection occt_cdl_3_4_1     Enumerations
-
-The **enumerated types** are  the second type, which is manipulated by value. Unlike the primitive types they  are extensible because they are defined by the user under the form of  enumerations. An enumeration is an ordered sequence of named whole constant  values called enumeration constants. 
-
-**Example** 
-~~~~~
-declaration-of-an-enumeration ::= 
-enumeration enumeration-name 
-is identifier {’,’ identifier} 
-[end [enumeration-name]]’;’ 
-enumeration-name ::= identifier 
-~~~~~
-The declaration of an  enumeration creates an enumerated type. An object of this type can successively  take the value of any one of the constants cited in the list. 
-
-**Example** 
-~~~~~
-enumeration MagnitudeSign is Negative, Null, Positive; 
-~~~~~
-
-Inside a package, two  enumeration constants cannot have the same name, even if they belong to  different enumerated types.
-**Example** 
-~~~~~
-enumeration Cars is 
-       Honda, 
-       Ford, 
-       Volkswagen, 
-       Renault 
-end; 
-enumeration AmericanPresidents is 
-       Nixon, 
-       Reagan, 
-       Ford, -- Error: ‘Ford’ already defined 
-       Carter 
-end; 
-~~~~~
-
-@subsubsection occt_cdl_3_4_2    Imports
-
-An **imported type** is  one of which which has not been defined in CDL. It is up to the supplier of  this data type to ensure compatibility with the CDL language by providing  services which allow CDL to recognize the imported data type. 
-
-The CDL syntax for  declaring an imported type is: 
-~~~~~
-declaration-of-an-imported-type::=[private] imported  typename ; 
-~~~~~
-
-Let us try to define an imported type:
-
-* In the *MyPack.cdl* file, you declare the imported type:
-~~~~~ 
-package MyPack 
-       .... 
-       imported MyImport; 
-       .... 
-       end Mypack; 
-~~~~~  
-* In the *MyPack_MyImport.hxx* file, you write the following C++ code: 
-~~~~~
-#ifndef _MyPack_MyImport_HeaderFile 
-#define _MyPack_MyImport_HeaderFile 
-#include Standard_Type.hxx 
-typedef unsigned long MyPack_MyImport; 
-extern const Handle(Standard_Type)&amp; TYPE 
-(MyPack_MyImport); 
-~~~~~
-* In the *MyPack_MyImport.cxx* file, you write the following C++ code: 
-~~~~~
-#ifndef _MyPack_MyImport_HeaderFile 
-#include MyPack_MyImport.hxx 
-#endif 
-const Handle(Standard_Type)&amp; TYPE (MyPack_MyImport) 
-{ 
-       static Handle(Standard_Type) _aType = 
-               new Standard_Type  (“MyPack_MyImport”,sizeof 
-               (MyPack_MyImport)) 
-                return _aType; 
-       } 
-~~~~~
-
-Then, add the names of  these two files <i>(MyPack_MyImport.hxx, MyPack_MyImport.cxx)</i> to a file called  FILES in the src subdirectory of the package. If the file does not exist you  must create it. 
-
-
-@subsubsection occt_cdl_3_4_3    Aliases
-
-An **alias** is an  extra name for a type, which is already known. It is declared as in the  following syntax: 
-
-~~~~~
-declaration-of-an-alias::= [private] alias type1 is type2  [from apackage] ; 
-~~~~~
-
-**Example** 
-~~~~~
-alias Mass is Real; 
----Purpose: 
--- Defined as a quantity of matter. 
--- Gives rise to the  inertial and 
--- gravitational  properties of a body. 
--- It is measured in  kilograms. 
-~~~~~
-
-Having defined *Mass* as  a type of *Real*, you can use either *Mass* or *Real* to type an  argument when defining a method. 
-
-
-@subsubsection occt_cdl_3_4_4     Exceptions
-
-In the model recommended  by CDL, the principal characteristic of errors is that they are treated in a  different place from the place where they appear. In other words, the methods  recovering and those raising a given exception are written independently from  each other. 
-
-Subsequently this poses  the problem of communication between the two programs. The principle adopted  consists in viewing the exception as both a class and an object. The exception  class (by means of one of its instances) is used to take control of an  exception, which has been raised. 
-
-Consequently, error conditions  are defined by means of **classes of exceptions**. Exception classes are  arranged hierarchically so as to be able to recover them in groups. They are  all descendents of a single root class called *Failure*, and it is at the level  of this class that the behavior linked to the raising of exceptions is  implemented. 
-~~~~~
-declaration-of-an-exception ::=exception exception-name inherits exception-name 
-~~~~~
-
-All exceptions share identical behavior, that of the  class *Failure*. Here are some examples of exception classes: 
-~~~~~
-exception NumericError inherits Failure; 
-exception Overflow inherits NumericError; 
-exception Underflow inherits NumericError; 
-~~~~~
-
-The use of exceptions as  a means to interrupt the normal execution of one program and then take control  of another one depends on the programming language used to implement the  methods. See the following chapter <a href="#occt_cdl_4">“Defining the Software Components”</a>  on page 32. 
-
-
-@subsection occt_cdl_3_5   Schemas
-
-The purpose of a **schema** is to list persistent data types, which will be stored in files by the  application. A schema groups together persistent packages. A persistent package  is one, which contains at least one persistent class. 
-
-~~~~~
-declaration-of-a-schema ::= 
-schema SchemaName 
-is 
-{package PackageName;} 
-{class ClassName;} 
-end;
-~~~~~
-For example 
-~~~~~
-schema Bicycle 
----Purpose: Defines the Bicycle schema. 
-is 
-package  FrameComponents; 
-package WheelComponents; 
-end; 
-~~~~~
-
-
-**Note** that it is  unnecessary to specify all the dependencies of the packages. It is sufficient  to specify the highest level ones. The others on which they depend are  automatically supplied. 
-
-@subsection occt_cdl_3_6   Executables
-
-The purpose of an **executable** is to make an executable program without a front-end. It can be used to  test more than one package at a time. An executable is written in a .cdl file  as a set of packages. 
-**Example** 
-~~~~~
-definition-of-an-executable ::= 
-       executable ExecutableName 
-       is 
-{ 
-executable ExecutablePart 
-       [uses  [Identifier as external] 
-       [{’,’  Identifier as external}] 
-       [UnitName as  library] 
-       [{’,’  UnitName as library}] 
-       is 
-       {FileName  [as C++|c|fortran|object];} 
-       end; 
-       } 
-end; 
-~~~~~
-
-**Example** 
-~~~~~
-executable MyExecUnit 
-       ---Purpose: 
-       -- Describes the  executable MyExecUnit 
-       is 
-       executable myexec 
-       -- the binary file 
-       uses 
-       Tcl_Lib as external 
-       is 
-       myexec; 
-       -- the C++ file 
-       end; 
-       -- several binaries can be specified in one .cdl file. 
-       executable myex2 
-       is 
-       myex2; 
-end; 
-end; 
-~~~~~
-
-@section occt_cdl_4 Defining the Software Components
-
-@subsection occt_cdl_4_1   Behavior
-
-The behavior of an  object class is defined by a list of **methods**, which are either **functions** or **procedures**. Functions return an object, whereas procedures only  communicate by passing arguments. In both cases, when the transmitted object is  an instance manipulated by a handle, its identifier is passed. There are three  categories of methods: 
-
-* **Object constructor** Creates an instance of the described class. A  class will have one or more object constructors with various arguments or none. 
-* **Instance method** Operates on the instance which owns it. 
-* **Class method** Does not work on individual instances, only on the class itself. 
-
-@subsubsection occt_cdl_4_11    Object  Constructors
-
-A constructor is a  function, which allows the **creation of instances** of the class it  describes. 
-
-~~~~~
-constructor-declaration ::= 
-Create [ simple-formal-part ] declaration-ofconstructed-type 
-[ exception-declarations ] 
-simple-formal-part ::= 
-’(’  initialization-parameter {’;’ initialization parameter}’)’ 
-initialization-parameter ::= 
-identifier {’,’ identifier} ’:’ parameter-access  datatype 
-[ ’=’ initial-value ] 
-parameter-access ::= 
-mutable | [ immutable ] 
-initial_value ::= 
-numeric-constant | literal-constant | named-constant 
-declaration-of-constructed-type ::= 
-returns [ mutable ] class-name 
-~~~~~
-
-The name of the  constructors is fixed: “Create”. The object returned by a constructor is  always of the type of the described class. If that type is manipulated by a  handle, you *must* declare it as **mutable**, in which case the content  of the instance it references is accessible for further modification. 
-
-For example, the  constructor of the class “Point” 
-~~~~~
-Create (X, Y, Z : Real) 
-returns mutable  Point; 
-~~~~~
-
-With the exception of  the types predefined by the language, all types of initialization parameters *must* appear in the **uses** clause of the class of which the constructor is a  member. 
-
-When an initialization  parameter is of a type which is manipulated by a handle, an access right *must* be associated with it so as to express if the internal representation of  the referenced object is modifiable (**mutable**) or not (**immutable**).  The default option is **immutable**. Let, for example, take the constructor of the  persistent class “Line”. 
-
-~~~~~
-Create (P : mutable Point; D : mutable Direction) 
-returns mutable  Line; 
-~~~~~
-
-In the above example “P”  and “D” must be mutable because the constructor stores them in the internal  representation of the created line, which is mutable itself. An alternative  would be to accept immutable initialization parameters and then copy them into  the constructor in a mutable form. 
-
-The parameters of a  native type can have a default value: this is expressed by assigning a constant  of the same type to the parameter concerned. Parameters, which have a default  value, may not be present when the call to the constructor is made, in which  case they take the value specified in the declaration. For this reason, they  must all be grouped at the end of the list. Let, for example, take the constructor of the  persistent class “Vector”. 
-
-~~~~~
-Create (D : mutable Direction; M : Real = 1.0) 
-returns mutable  Vector; 
-~~~~~
-
-A class can have many  constructors (in this case, you say they are **overloaded**) provided that  they differ in their syntax and that the presence of parameters having default  values does not create ambiguities. 
-
-The restrictions on  their use are expressed by a list of **exceptions** against which each  constructor is protected. 
-
-Each class must have at  least one constructor to be able to create objects of its type. 
-
-@subsubsection occt_cdl_4_1_2     Instance Methods
-
-An instance method is a  function or procedure, which applies to any instance of the class, which  describes it. 
-
-**Example** 
-~~~~~
-declaration-of-an-instance-method ::= identifier formal-part-of-instance-method 
-[  declaration-of-returned-type ] 
-[  exception-declaration ] 
-formal-part-of-instance-method  ::=  ’(’ me [’:’  passing-mode parameter-access ] {’;’ parameter}’)’ 
-parameter ::= identifier {’,’  identifier} ’:’ passing-mode 
-parameter-access 
-data-type [ ’=’ initial-value ] 
-passing-mode ::= [ in ] | out | in  out 
-parameter-access ::= mutable |  [immutable] 
-declaration-of-returned-type  ::= returns  return-access data-type 
-return-access ::= mutable |[ immutable  ]| any 
-~~~~~
-
-The name **me** denotes  the object to which the method is applied: you call this the “principal object”  of the method. The passing mode expresses whether the direct content of the  principal object or a parameter is either: 
-
-  * read
-  * created and returned
-  * read then updated and  returned by the method.
-
-Remember that the direct  content of an argument of a type which is manipulated by value contains the  internal representation of the object itself. Thus, when the argument is of  this type, **out** and **in out** mean that the content of the object will  undergo a modification. When the method is a function (as is the case for  constructors), all the arguments must be **in** (read). This is the default  mode. 
-
-In case of an argument  of a type manipulated by a handle, the direct content being an object identifier,  the passing mode addresses itself to the handle, and no longer to the internal  representation of the object, the modification of which is controlled by the  access right. An argument of this type declared **mutable** may see its  internal representation modified. If declared **immutable**, it is  protected. When a parameter is both **in out** and **mutable**, the  identifiers passed and returned denote two distinct modifiable objects. 
-
-When the returned object  is manipulated by a handle it can be declared modifiable or not, or  indeterminate (**any**). To return an object with an indeterminate access  right means that the method transmits the identifier without changing its state  and that the method has no right to alter the access right. This functionality  is particularly useful in the case of collections; temporarily storing an  object in a structure and unable to modify its state. 
-
-With the exception of  the types predefined by the language, all types of parameters and returned  objects, whether manipulated by a handle or by value, *must* appear in the  **uses** clause of the class of which the method is a member. 
-As is the case for  constructors, some parameters can have a default value, provided that they are  of primitive or enumerated type. They are passed in the **in** mode, and  they are found at the end of the list of arguments. 
-
-Overloading of instance  methods and use of exceptions and post-conditions is allowed and respects the  same rules than constructors. 
-
-Note the overloading of  “Coord” in the following example of instance methods associated with the  persistent class “Point”: 
-
-~~~~~
-Coord (me; X, Y, Z : out Real); 
----Purpose: returns the coordinates of me 
-
-Coord (me; i : Integer) returns Real; 
----Purpose: returns the abscissa (i=1), the 
--- ordinate (i=2) or the value (i=3) of  me 
-
-SetCoord (me : mutable; X, Y, Z : Real); 
----Purpose: modifies the coordinates of me 
-
-Distance (me; P : Point) returns Real 
----Purpose: returns the distance to a point 
-~~~~~
-
-In all these cases, **me** is implicitly an object of type *Point*. Only “SetCoord” is able to modify  the internal representation of a point. 
-
-@subsubsection occt_cdl_4_1_3    Class  Methods
-
-A class method is a  function or procedure relative to the class it describes, but does not apply to  a particular instance of the class. 
-
-~~~~~
-declaration-of-a-class-method ::= identifier formal-part-of-class-method 
-[ declaration-of-returned-type ] 
-[ exception-declaration ] 
-formal-part-of-class-method ::= ’(’ myclass {’;’ parameter}’)’ 
-~~~~~
-
-The first parameter **myclass** indicates that the method does not apply to a previously created instance,  but to the class itself. The rest of the syntax is identical to that of the  instance methods. In particular, access rights (**mutable**, **immutable**,  **any**) and the argument passing mode (**in**, **out**, **in out**)  must remain unchanged. With the exception of the types predefined by the  language, all types of parameters must appear in the **uses** clause of the  class of which the method is a member. Overloading of class methods and the use  of exceptions and post-conditions is allowed, and it follows the same rules as  for constructors and instance methods. 
-
-Examples of class  methods associated with the class “Real”: 
-
-~~~~~
-First (myclass) returns Real; 
----Purpose: returns lower limit of reals 
-
-Last (myclass) returns Real; 
----Purpose: returns upper limit of reals 
-~~~~~
-
-@subsubsection occt_cdl_4_1_4    Package  Methods
-
-Package methods are  methods which are members of a package. They are frequently used for library or  application initialization, or for offering an application programming  interface to the sources to the package. They are sometimes methods used for  development purposes but which are not made available to final end-users of the  package. 
-
-~~~~~
-package-method ::= identifier  [simple-formal-part][returned-type-declaration] 
-[exception-declaration] 
-[is private]’;’ 
-~~~~~
-
-@subsubsection occt_cdl_4_1_5     Sensitivity to Overloading
-
-When there is more than  one method of a class, several methods share the same name but have different  syntax, you say the method is overloaded. 
-
-In order that the  methods can be considered distinct, they must differ either in the number of  parameters, or one of their parameters must be of a different type. In  particular, you *cannot* overload a method if you merely modify it as  follows: 
-
-  * The type of the returned  object when the method behaves as a function
-  * The name or the mode of  passing a parameter (**in**, **out**, or **in out**) 
-  * The mutability of passed  objects (**mutable**, **immutable**, **any**) 
-  * Default value of a parameter.
-  
-@subsection occt_cdl_4_2   Internal Representation
-
-Each object contains its  own state in a private space in the memory. This state consists of a set of **fields**, which include or reference other objects. 
-
-**Example** 
-~~~~~
-declaration-of-the-internal-representation-of-a-class ::= fields field {field} 
-field ::= identifier {’,’ identifier} ’:’ data-type [’[’integer {’,’integer}’]’]’;’ 
-~~~~~
-
-A copy of all the  defined fields exists locally in each instance of the class. This group of  fields will be initialized by the class constructors when the object is  instantiated. 
-
-Fields *must not* have  the same name as any method of the class in which they appear. When the field  type is followed by a list of integer constants between square brackets, the  data will take the form of a multi-dimensional array containing objects of this  type. 
-
-The following example  shows two equivalent ways of describing three fields of the “Real” type: 
-
-**Example** 
-~~~~~
-fields 
-x, y, z: Real; 
-coord: Real[3]; 
-~~~~~
-
-
-Depending on their type,  Object fields have one of the two forms. When the field is of the “manipulated  by handle” type, it corresponds to an identifier. In this case, the contents of  the object can be shared by other objects or by a handle in a program. When the  field is of a “manipulated by value” type, it contains the value of the object.  In this case you say the object is **embedded**. 
-
-@subsection occt_cdl_4_3   Exceptions
-  
-Exceptions describe  exceptional situations, which can arise during the execution of a method. With  the raising of an exception, the normal course of program execution is  interrupted. The actions carried out in response to this situation are called   treatment of exception. 
-~~~~~
-exception-treatment ::= raises exception-name  {’,’ exception-name} 
-~~~~~
-Each exception name  corresponds to a class of exceptions previously defined as being susceptible to  being raised by the method under which it appears. Exception classes must all  appear in the **raises** clause of the class of which the method is a member.  The class of exceptions is analogous to the class of objects described in this  manual. 
-
-Take for example the  method which returns the x, y, or z coordinate of a point. 
-
-~~~~~
-Coord (me; i : Integer) returns Real 
----Purpose: 
--- Returns the abscissa (i=1) 
--- the ordinate (i=2) 
--- or the value (i=3) 
--- of me. 
-raises OutOfRange; 
--- if i is not equal to 1, 2, or 3. 
-~~~~~
-
-
-Instance methods are  likely to raise certain exceptions called **systematic exceptions** which do  not have to appear. They are: 
-
-* *NullObject* - raised when the principal object does not exist. 
-* *ImmutableObject* - raised when a method tries to modify an immutable  principal object. 
-* *TypeMismatch* - raised if an argument typed by association is of  an unsuitable type. 
-
-These exceptions are described  in the Standard Package (System Toolkits). 
-
-
-@subsection occt_cdl_4_4   Inheritance
-
-@subsubsection occt_cdl_4_4_1     Overview
-
-The notion of  inheritance comes from a development strategy according to which you begin by  modeling data in the most general fashion. Then you specialize it more and more  so as to correspond to more and more precise cases. 
-
-For example, to develop  a basic geometry, you can first of all consider the group of geometric objects,  and then differentiate the points, vectors, and curves. You can specialize the  latter into conic sections, and then decompose them into circles, ellipses, and  hyperbolas. Then, the class of conics is considered as a sub-class of curves,  and a super-class of circles. 
-
-A sub-class has at least  the behavior of its super-classes. Thus, a circle could be viewed as a conic, a  curve, or even as a geometric object. In each case, the applicable methods  belong to the level where you view the class. In this case, you say that the  sub-class inherits the behavior from its super-classes. 
-
-
-**Example** 
-~~~~~
-declaration-of-a-sub-class ::= class class-name 
-inherits class-name 
-[uses data-type {’,’ data-type}] 
-[raises exception-name {’,’ exception-name}] 
-is class-definition 
-end [class-name]’;’ 
-~~~~~
-
-A class cannot inherit  one of its descendent classes; nor can it inherit a native type. All the  classes of a system can be described in a non-cyclic diagram called the **inheritance  graph**. 
-
-The definition of a  sub-class is identical to that of a simple class. Note that a super-class must  not appear in the **uses** clause of the sub-class, even if it appears  in the definition of the sub-class. The behavior of a sub-class includes as a  minimum all  instance methods and protected methods of its super-classes. 
-
-**Note** that constructors and class methods are never  inherited. 
-
-@subsubsection occt_cdl_4_4_2     Redefining methods
-
-Certain inherited  methods can be redefined. 
-
-**Example** 
-
-~~~~~
-declaration-of-a-redefined-method ::= identifier formal-part-of-instance-method [returnedtype- declaration] 
-[declaration-of-exceptions] 
-is redefined [visibility]’;’ 
-~~~~~
-
-A redefined method must conform  to the syntax described in the super-class where it appears. The exceptions  contained in the super-class can be renewed, and others may be added as long as  they inherit from an ancestor class. 
-
-The redefined attribute  can be applied neither to a constructor, nor to a class method, since neither  of them can be inherited. If the redefined method is private or protected, the  visibility must be exactly repeated in the redefinition. For further details on  visibility, refer to <a href="#occt_cdl_4_6"> Visibility </a> section. 
-
-
-**Example** 
-~~~~~
-SquareDistance (me; P : Point) returns Real 
-is redefined private; 
-~~~~~
-
-With regards to the  internal representation, all fields defined in the super-classes are, by  default, inherited, but they can also be redefined. 
-
-@subsubsection occt_cdl_4_4_3 Non-redefinable methods
-
-Instance methods, which  are declared virtual are redefinable in descendent classes, and you can force  this redefinition by making a method **deferred**. For more details, see the  next section.
-**Example** 
-
-~~~~~
-declaration-of-a-non-redefinable-method ::= identifier formal-part-of-instance-method [returnedtype- declaration] 
-[declaration-of-exceptions] 
- is virtual [visibility]’;’ 
-~~~~~
-
-All methods are static  by default. To enable redefinition in all the child classes, add **is virtual** when declaring the method. 
-
-You must also be able to  forbid redefinition. A redefinable method can become non-redefinable if you  declare: **is redefined static**. 
-
-
-@subsubsection occt_cdl_4_4_4 Deferred Classes and Methods
-
-The presence of certain  classes in the inheritance graph can be justified purely by their ability to  force certain behavior on other classes, in other words, to make other classes  provide various services. 
-
-The CDL language allows  you to describe a class, which introduces methods without implementing them, so  as to force its descendent classes to define them. These are called **deferred  classes**; the non-implemented methods are also termed **deferred methods**. 
-
-
-**Example** 
-~~~~~
-declaration-of-a-deferred-class ::= deferred class class-name 
-[inherits class-name [uses data-type {’,’ data-type}] 
-[raises exception-name {’,’ exception-name}] 
-is class-definition 
-end [class-name]’;’ 
-declaration-of-a-deferred-method ::= identifier formal-part-of-instance-method [returnedtype- declaration] 
-[declaration-of-exceptions] 
-is deferred [visibility]’;’ 
-~~~~~
-
-Only instance methods  can be deferred. 
-
-It is sufficient for a class to contain one deferred  method for it to be a deferred class. It can contain any number of deferred  methods (or none). 
-
-A deferred class may  still have an internal representation but one or more **non-protected** constructors  would be necessary to initialize them. The constructors must be visible in the  sub-classes. 
-
-The constructors of a  deferred class are called **Initialize** (not **Create**). They are **protected** by default, and do not return any object. You cannot create an object of a  deferred class type. 
-For example, consider  the class *Point*, and its declaration as deferred. 
-
-**Example** 
-~~~~~
-deferred class Point inherits Geometry is 
-Initialize; 
----Purpose: Initializes the point. 
-Coord (me; X, Y, Z : out Real) 
----Purpose: Returns the coordinates 
-is deferred; 
-SetCoord (me : mutable; X, Y, Z : Real) 
----Purpose: Modifies the coordinates 
-is deferred; 
-Distance (me; P : Point) returns Real; 
----Purpose: Returns the distance from the point P 
-end Point; 
-~~~~~
-
-Notice that the function  *Distance* is not deferred. Although this class contains no representation,  this method is programmable by calling *Coord*. 
-
-In a sub-class of a  deferred class, all deferred methods, which have been inherited, must be  implemented, then redeclared (the attribute **redefined** is useless for  this purpose), unless the sub-class is itself deferred. 
-
-A non-deferred method  can be redefined as a deferred one, in which case it will be declared as  follows: **is redefined deferred**. 
-
-The notion of deferred  class is very useful. The advantage of introducing it, as was previously shown  in the deferred class *Point*, is that the corresponding resources will be  available even before being implemented. Later, you can add different  representations to Point (for example, spherical or Cartesian coordinates)  without having to modify client programs. 
-
-Thanks to the  possibility of redefining methods, this approach does not have any negative  impact on performance: a method implemented at the level of a deferred class  can be reprogrammed in one of its sub-classes while taking into account the  data representation. 
-
-@subsubsection occt_cdl_4_4_5     Declaration by Association
-
-At the heart of a class  hierarchy, object identifiers are compatible in the ascendant sense. Since the  *Conic* class is descended from the *Curve* class, an identifier of type *Curve* can  reference an object of type *Conic* (remember that the behavior of *Curve* is  applicable to *Conic*). In other words, you can assign a reference to a *Conic* to an identifier of type *Curve*, but not vice versa. 
-
-For example, once the  classes have been compiled you could write a C++ test program in which you  instantiate a Conic but reference it with a handle to a Curve: 
-~~~~~
-Handle(Curve) c = new Conic 
-~~~~~
-This same rule applies  to parameters of methods; that is to say, you can call a method with  identifiers corresponding to a sub-type of that specified in its declaration.  To illustrate this, let us go back to the “Distance” method of the “Point” class: 
-
-~~~~~
-Distance (me; P : point) returns Real; 
-~~~~~
-Conforming to the rule  of type compatibility, you could make a call to the method “Distance” with  reference to an object from a class descended from “Point”. Consequently, if  “SphericPoint” is a sub-class of “Point” and therefore inherits this method, it  will be possible to calculate the distance between two “SphericPoint”, or  between a “SphericPoint” and a “Point”, without having to redefine the method. 
-
-On the other hand,  sometimes you may want to force two parameters to be exactly of the same type,  and thus not apply the rule of type compatibility. To do this, you need to  associate the type of the concerned parameters in the method declaration. 
-
-~~~~~
-association-typing ::= like associated-parameter 
-associated-parameter ::= me | identifier 
-~~~~~
-
-Note that identifier is the name of a parameter, which appears first in the formal part of the declaration of the method.
-
-
-You can use this  technique, which consists in declaring by association, to declare a method that  will exchange the content of two objects, or a method, which copies another  object: 
-
-~~~~~
-Swap (me : mutable; With : mutable like me); 
-DeepCopy (me) returns mutable like me; 
-~~~~~
-
-Make sure not to  write the Swap method as in the syntax below: 
-
-
-~~~~~
-Swap (me : mutable; With : mutable Point); 
-~~~~~
-
-In this case **me** may  be a CartesianPoint or a SphericalPoint, while *With* can only be a Point. 
-
-@subsubsection occt_cdl_4_4_6     Redefinition of Fields
-
-The creation of a  hierarchy of classes should be viewed as a means to specialize their behavior,  (e.g. a circle is more specialized than a conic section). The more you  specialize the object classes, the more it is justified to call into question  the inherited fields in order to obtain greater optimization. So, in the  description of the internal representation of a sub-class, it is possible not  to inherit all of the fields of the super-classes. You then say the fields have  been redefined. 
-
-~~~~~
-redefinition-of-the-representation-of-a-class ::= redefined redefinition-of-a-field {’,’ redefinition-of-a- 
-field}’,’ 
-redefinition-of-a-field ::= [field-name] from [class] class-name 
-~~~~~
-
-Redefinition of fields  can only be done in classes manipulated by a handle. 
-
-This declaration appears  at the beginning of the definition of the internal representation of the  sub-class, which breaks the field inheritance. The non-inherited fields are all  those which come from the class specified behind the rubric **from**. 
-
-
-@subsection occt_cdl_4_5   Genericity
-
-@subsubsection occt_cdl_4_5_1     Overview
-
-Inheritance is a  powerful mechanism for extending a system, but it does not always allow you to  avoid code duplication, particularly in the case where two classes differ only  in the type of objects they manipulate (you certainly encounter this phenomenon  in all basic structures). In such cases, it is convenient to send arbitrary  parameters representing types to a class. Such a class is called a **generic  class**. Its parameters are the generic types of the class. 
-
-Generic classes are  implemented in two steps. You first declare the generic class to establish the  model, and then instantiate this class by giving information about the generic  types. 
-
-@subsubsection occt_cdl_4_5_2     Declaration of a Generic Class
-
-The syntax is as  follows: 
-
-~~~~~
-declaration-of-a-generic-class ::= [deferred] generic class class-name  ’(’generic-type {’,’generic-type}’)’ 
-[inherits class-name 
-[uses data-type {’,’ data-type}] 
-[raises exception-name {’,’ exception-name}] 
-       is class-definition 
-       end [class-name]’;’ 
-generic-type ::= identifier as type-constraint 
-type-constraint ::= any | class-name [’(’data-type {’,’data-type}’)’] 
-~~~~~
-
-The names of generic  types become new types, which are usable in the definition of a class, both in  its behavior (methods) and its representation (fields). The generic type is  only visible inside the generic class introducing it. As a result, it is  possible to have another generic class using the same generic type within the  same package. 
-
-When you specify the  type constraint under the form of a class name, you impose a minimum set of  behavior on the manipulated object.  
-
-This shows that the  generic type has as a minimum the services defined in the class. This can be  any kind of a previously defined class, including another generic class, in  which case you state exactly with what types they are instantiated. 
-
-When the generic type is  constrained by the attribute **any**, the generic class is intended to be  used for any type at all, and thus corresponds to classes whether manipulated  by a handle or by value. 
-
-No class can inherit  from a generic class. 
-
-A generic class can be a  deferred class. A generic class can also accept a deferred class as its  argument. In both these cases any class instantiated from it will also be  deferred. The resulting class can then be inherited by another class. 
-
-Below is a partial  example of a generic class: a persistent singly linked list.
-~~~~~
-generic class SingleList (Item as Storable) 
-       inherits Persistent 
-       raises NoSuchObject 
-       is 
-       Create returns mutable SingleList; 
-    ---Purpose: Creates an empty list 
-       IsEmpty (me) returns  Boolean; 
-               ---Purpose: Returns true if the list me is  empty 
-       SwapTail (me :  mutable; S : in out mutable 
-       SingleList) 
-               ---Purpose: Exchanges the tail of list me  with S 
-       -- Exception  NoSuchObject raised when me is empty 
-       raises NoSuchObject; 
-          Value (me) returns Item 
-          ---Purpose: Returns first element of the list  me 
-       -- Exception NoSuchObject  raised when me is empty 
-       raises NoSuchObject; 
-          Tail (me) returns mutable SingleList 
-       ---Purpose: Returns  the tail of the list me 
-       -- Exception  NoSuchObject raised when me is empty 
-       raises NoSuchObject; 
-          fields 
-               Data : Item; 
-          Next : SingleList; 
-          end SingleList; 
-~~~~~     
-
-Even though no object of  the type “SingleList” IS created, the class contains a constructor. This class  constitutes a model, which will be recopied at instantiation time to create a  new class which will generate objects. The constructor will then be required. 
-
-**Example** 
-~~~~~
-generic class Sequence(Item as any, Node as 
-SingleList(Item)) 
-inherits Object 
-. . . 
-end Sequence 
-~~~~~
-
-In the above example,  there are two generic types: *Item* and *Node*. The first imposes no restriction.  The second must at least have available the services of the class *SingleList* instantiated with the type with which *Sequence* will itself be instantiated. 
-
-In the incomplete  declaration of a generic class, the keyword **generic** must appear. 
-
-**Example** 
-~~~~~
-generic class SingleList; 
-generic class Sequence; 
-~~~~~
-
-@subsubsection occt_cdl_4_5_3     Instantiation of a Generic Class
-
-The syntax is as  follows: 
-
-~~~~~
-instantiation-of-a-generic-class ::= [deferred] class  class-name 
-     instantiates class-name ’(’data-type {’,’ data-type}’);’ 
-~~~~~
-
-Instantiation is said to  be **static**. In other words, it must take place before any use can be made  of the type of the instantiated class. Each data type is associated term by  term with those declared at the definition of the generic class. These latter  ones, when they are not of the type **any**, restrict instantiation to those  classes, which have a behavior at least equal to that of the class specified in  the type constraint, including constructors. Note that this is not guaranteed  by inheritance itself. 
-
-For example, let’s  instantiate the class *Sequence* for the type *Point*: 
-
-~~~~~
-class SingleListOfPoint instantiates SingleList(Point); 
-class Sequence instantiates 
-       Sequence(Point,SingleListOfPoint); 
-~~~~~
-
-The instantiation of a  generic deferred class is a deferred class (the **deferred** attribute must  be present during instantiation). An instantiated class cannot be declared in  an incomplete fashion. 
-
-@subsubsection occt_cdl_4_5_4    Nested  Generic Classes
-
-It often happens that  many classes are linked by a common generic type. This is the case when a base  structure provides an iterator, for example, in the class *Graph*. A graph is  made up of arcs, which join together the nodes, which reference objects of any  type. This type is generic both for the graph and for the node. In this  context, it is necessary to make sure that the group of linked generic classes  is indeed instantiated for the same type of object. So as to group the  instantiation, CDL allows the declaration of certain classes to be nested. 
-
-**Example** 
-
-~~~~~
-declaration-of-a-generic-class ::=  [deferred] generic class class-name  ’(’generic-type{’,’generic-type}’)’ 
-   [inherits class-name {’,’ class-name}] 
-   [uses data-type {’,’ data-type}] 
-   [raises exception-name {’,’ exception-name}] 
-   [{[visibility] class-declaration}] 
-   is class-definition 
-end [class-name]’;’ 
-   class-declaration ::= incomplete-declaration-of-a-class | declaration-of-a-non-generic-class | instantiation-of-a-generic-class 
-~~~~~
-
-**Nested classes**, even though they are described as non-generic  classes, are generic by construction, being inside the class of which they are  a part. As a consequence, the generic types introduced by the **encompassing  class** can be used in the definition of the nested class. This is true even  if the generic type is only used in a nested class. The generic types still must appear as an argument of the encompassing class. All other types used by a  nested class must appear in its **uses** or **raises** clauses,  just as if it were an independent class. 
-
-Nested classes are, by  default, **public**. In other words, they can be used by the clients of the  encompassing class. On the other hand, when one of the nested classes is  declared **private** or **protected**, this class must not appear  in any of the public methods of the other classes. It cannot be used in a  protected field because then it could be used in a sub-class, which implies it  would not be private. 
-
-The following example  shows how to write the Set class with its iterator. 
-
-~~~~~
-generic class Set (Item as Storable) 
-       inherits Persistent 
-       private class Node  instantiates SingleList (Item); 
-       class Iterator 
-                  uses Set, Node 
-                  raises  NoSuchObject, NoMoreObject 
-                  is 
-                  Create (S : Set)  returns mutable Iterator; 
-               ---Purpose: Creates  an iterator on the group S 
-                  More (me) returns  Boolean; 
-               ---Purpose: Returns  true if there are still elements 
-                  -- to explore 
-                  Next (me) raises  NoMoreObject; 
-               ---Purpose: Passes  to the following element 
-                  Value (me)  returns any Item raises NoSuchObject; 
-               ---Purpose: Returns  the current element 
-                  fields 
-                  Current : Node; 
-               end Iterator; 
-               is 
-                  Create returns  mutable Set; 
-               ---Purpose: Creates  an empty group 
-                  IsEmpty (me)  returns Boolean; 
-               ---Purpose: Returns  true if the group is empty 
-                  Add (me :  mutable; T : Item); 
-               ---Purpose: Adds an  item to the group me 
-                  Remove (me :  mutable; T : item) raises 
-               NoSuchObject; 
-               ---Purpose: Removes  an item from the group me 
-                  etc. 
-                  fields 
-                  Head : Node; 
-       end Set; 
-~~~~~
-
-Note that in their  fields, both “Set” and “Iterator” are clients of another class, “Node”. This  last can be effectively declared **private** for it only appears in fields  which are themselves private. 
-
-The instantiation of a  generic class containing nested classes remains unchanged. The same declaration  is used to instantiate the encompassing class and the nested classes. These  latter will have their name suffixed by the name supplied at instantiation,  separated by “Of”. For example, you instantiate the class “Set” described above  for the type “Point” as follows: 
-
-~~~~~
-class SetOfPoint instantiates Set(Point); 
-~~~~~
-In doing so, you  implicitly describe the classes “NodeOfSetOfPoint” and “IteratorOfSetOfPoint”,  which are respectively the result of the concatenation of “Node” and “Iterator”  with “Of” then “SetOfPoint”. 
-
-Note that in the  incomplete declaration of an encompassing class, all the names of the nested  classes *must* appear behind that of the encompassing class. 
-
-~~~~~
-incomplete-declaration-of-a-generic-class ::= [deferred] generic class-name {’,’  class-name}; 
-~~~~~
-
-For example, an incomplete declaration of the above  class “Set” would be as in the example below: 
-
-~~~~~
-generic class Set, Node, Iterator; 
-~~~~~
-
-Only the encompassing  class can be deferred. In the above example only the class “Set” can be  deferred. 
-
-
-
-@subsection occt_cdl_4_6   Visibility
-
-@subsubsection occt_cdl_4_6_1     Overview
-
-A field, method, class,  or package method is only available for use if it is **visible**. 
-Each of these components  has a default visibility, which can be explicitly modified during class or  package declaration. The three possible states of visibility are: 
-  * Public
-  * Private
-  * Protected
-
-@subsubsection occt_cdl_4_6_2     Visibility of Fields
-
-A field is **private**.  It can never be public - this would destroy the whole concept of data  encapsulation. The attribute **private** is redundant when it is applied to  a field. This means that a field is only visible to methods within its own  class. 
-A field can be declared **protected**, which means that it becomes visible in subclasses of its own class. Its  contents can be modified by methods in subclasses. 
-
-~~~~~
-field ::= identifier {’,’ identifier} ’:’ data-type 
-[’[’integer{’,’integer}’]’] 
-[is protected]’;’ 
-~~~~~
-
-**Example** 
-
-~~~~~
-fields 
-   Phi, Delta, Gamma : AngularMomenta [3] 
-   is protected ; 
-~~~~~
-
-@subsubsection occt_cdl_4_6_3     Visibility of Methods
-
-Methods act on fields.  Only methods belonging to a class can act on the fields of the class; this  stems from the principle of object encapsulation. Methods can be characterized  in three ways: by default, methods are **public**. Methods can be declared **private** or **protected** to restrict their usage. 
-
-* **Public** methods are the default and generally the most common. They describe the behavior of a class or a package, and they are  callable by any part of a program. 
-* **Private** methods  exist only for the internal structuring of their  class or their package. Private class methods can only be called by methods  belonging to the same class. Private package methods can only be called by all  methods belonging to the same package and its classes. 
-* **Protected**  methods are private methods, which are also callable from  the interior of descendent classes.  
-
-If you want to restrict  the usage of a method, you associate with it a visibility as follows : 
-~~~~~
--- declaration-of-the-visibility ::= is visibility 
-visibility ::= private | protected 
-~~~~~
-
-The declaration of the  visibility of a method appears at the end of its definition, before the final  semi-colon. The attribute **private** indicates that the method will only be  visible to the behavior of the class of which the method is a member; **protected** will propagate the visibility among the sub-classes of this class. 
-
-For example, add to the  class “Line” an internal method allowing the calculation of the perpendicular  distance to the power of two, from the line to a point. 
-
-~~~~~
-SquareDistance (me; P : Point) returns Real 
-is private;
-~~~~~
-
-@subsubsection occt_cdl_4_6_4     Visibility of Classes, Exceptions and Enumerations
-
-The visibility of a  class is the facility to be able to use this class in the definition of another  class. The visibility of a class extends from the beginning of its declaration  up to the end of the package in which it appears. You have seen that the  keyword **uses** allows extension of this visibility to other packages. 
-
-As was explained in the  section on “<a href="#occt_cdl_3_3_2">Name Space</a>”, any ambiguity, which arises from having two classes  with the same name coming from different packages, is dealt with by the use of  the keyword **from**. 
-
-A class declared **private** is only available within its own package. 
-
-@subsubsection occt_cdl_4_6_5    Friend  Classes and Methods
-
-In certain cases,  methods need to have direct access to the private or protected parts of classes  of which they are clients. Such a method is called a **friend** of the  class, which is accessed. For example, you declare a method to be a friend when  a service can only be obtained via the use of another non-descendent class, or  perhaps when this will help to improve performance. 
-
-Classes can also be  declared friends of other classes. In this case all the methods of the friend  class will have access to the fields and methods of the host class. The right  is **not reciprocal**. 
-
-Friend classes or  methods are declared inside the class, which reveals its private and protected  data or methods to them. This helps in managing the continuing evolution of a  class, helping to recognize and to avoid the creation of side effects. 
-
-**Example** 
-~~~~~
-declaration-of-friends ::= friends friend {’,’friend} 
-   friend ::=    identifier from [class] class-name  [formal-part] | 
--- Defining the Software Components 67 
-identifier from [package] package-name  [formal-part] | class] class-name 
-   formal-part ::= simple-formal-part | formal-part-of-instance-method | formal-part-of-class-method 
-~~~~~
-
-The formal part must be present if the method contains one; thus this can be overloaded without  necessarily propagating the friend relationship among its homonyms. The keyword  **class** allows you to avoid certain ambiguities. For example, it removes  any confusion between “method M from class C” and “method M from package P”. 
-
-As an example, take a  method, which calculates the perpendicular distance between a line and a point.  Suppose this method needs to access the fields of the point. In the class  “Point” you would write: 
-
-~~~~~
-friends Distance from Line (me; P : Point) 
-~~~~~
-
-A method can be a friend  to many classes. The class to which the method belongs does not need to  appear in the **uses** clause of other classes of which it is a friend. 
-
-When the methods of a class are all friends  of another class, you can establish the friendship at the level of the class. 
-
-
-| | Public | Private | Protected |
-| :---- | :---- | :---- | :----- |
-| Field | Does not exist | **Default** - Visible to methods in its own class and in friend classes | Visible to methods in its own class, sub-classes and friend classes |
-| Method | **Default** - Callable anywhere | Callable by methods in its own class and in friend classes | Callable by methods in its own class, sub-classes and friend classes | 
-| Class | **Default**  - Visible everywhere with the use of **from** rubric | Visible to classes in its own package | Does not exist | 
-| Package method | **Default** - Callable everywhere with the use of **from** rubric | Visible to classes in its own package | Does not exist | 
-| Nested Class | **Default** -  Visible to the clients of the encompassing class | Visible to the encompassing class and other classes nested in the encompassing class | Does not exist | 
-
-
-@section occt_cdl_5 Appendix A. Syntax  Summary
-
-
-This summary of the CDL  syntax will aid in the comprehension of the language, but does *not* constitute  an exact definition thereof. In particular, the grammar described here accepts  a super-set of CDL constructors semantically validated. 
-
-(1) capital ::= ’A’ | ’B’ | ’C’ | ’D’ | ’E’ | ’F’ | ’G’ | ’H’ | ’I’ | ’J’ | ’K’ | ’L’ | ’M’ | ’N’ | 
-’O’ | ’P’ | ’Q’ | ’R’ | ’S’ | ’T’ | ’U’ | ’V’ | ’W’ | ’X’ | ’Y’ | ’Z’ 
-
-(2) non-capital ::= ’a’ | ’b’ | ’c’ | ’d’ | ’e’ | ’f’ | ’g’ | ’h’ | ’i’ | ’j’ | ’k’ | ’l’ | ’m’ | ’n’ | 
-’o’ | ’p’ | ’q’ | ’r’ | ’s’ | ’t’ | ’u’ | ’v’ | ’w’ | ’x’ | ’y’ | ’z’ 
-
-(3) digit ::= ’0’ | ’1’ | ’2’ | ’3’ | ’4’ | ’5’ | ’6’ | ’7’ | ’8’ | ’9’ 
-
-(4) underscore ::= ’_’ 
-
-(5) special character  ::= ’ ’ | ’!’ | ’”’ | ’#’ | ’$’ | ’%’ | ’&amp;’ | ’’’ | ’(’ | ’)’ | ’*’ | ’+’ | ’,’ | ’-’ | ’.’ | ’/’ | ’:’ | ’;’ | ’’ | ’=’ | ’’ | ’?’ | ’@’ | ’[’ | ’\’ | ’]’ | ’^’ | ’‘’ | ’{’ | ’|’ | ’}’ | ’~’ 
-
-(6) printable  character::= capitals | non-capitals | digits | underscore | special characters 
-
-(7) letter ::= capital |  non-capital 
-
-(8) alphanumeric ::= letter | digit 
-
-(9) identifier ::= letter{[underscore]alphanumeric} 
-
-(10) integer ::= digit{digit} 
-
-(11) exponent ::= ’E’[’+’]integer |  ’E-’integer 
-
-(12) numeric-constant  ::= [’+’]integer ’.’ integer[exponent] | ’-’integer ’.’ integer[exponent] 
-
-
-(13) literal-constant  ::= ’’’printable character’’’ | ’~’{printable 
-character}’~’ 
-
-(14) package-name ::= identifier 
-
-(15) enumeration-name  ::= identifier [**from** package-name] 
-
-(16) class-name ::= identifier [**from** package-name] 
-
-(17) exception-name ::= identifier [**from** package-name] 
-
-(18) constructor-name  ::= ’Create’ |  ’Initialize’ 
-
-(19) primitive-type ::= ’Boolean’ |  ’Character’ | ’Integer’ | ’Real’ 
-
-(20) data-type ::= enumeration-name | class-name | exception-name | primitive-type 
-
-(21) passed-type ::= data-type | **like me** | **like** identifier 
-
-(22) passing-mode ::= [**in**] | **out** | **in out** 
-
-(23) parameter-access ::= **mutable** | [**immutable**] 
-
-(23A) return-access ::= **mutable** | [**immutable**]| **any** 
-
-(24) value ::= numeric-constant | literal-constant | identifier 
-
-(25) parameter ::= identifier {’,’ identifier} ’:’ passing-mode access-right passed-type [’=’ value] 
-
-(26) simple-formal-part  ::= ’(’parameter {’;’  parameter}’)’ 
-
-(27)  formal-part-of-instance-method ::= ’(’ **me** [’:’ passing-mode access-right] {’;’ parameter}’)’ 
-
-(28)  formal-part-of-class-method ::= ’(’ **myclass** {’;’ parameter}’)’ 
-
-(29) visibility ::= **private** | **protected** 
-
-(30) redefinition ::= **static** | **deferred** 
-
-(31) definition-level ::= redefinition | **redefined** [redefinition] 
-
-(32)  declaration-of-constructed-type ::= **returns** [**mutable**] class-name 
-
-(33)  declaration-of-returned-type ::= **returns** return-access  passed-type 
-
-(34)  declaration-of-errors ::= **raises** exception-name {’,’  exception-name} 
-
-(35)  declaration-of-visibility ::= **is** visibility 
-
-(36)  declaration-of-attributes-of-instance-method ::= **is** visibility | **is** definition-of-level [visibility] 
-
-(37) constructor ::= constructor-name [simple-formal-part] 
-[declaration-of-constructed-type] 
-[declaration-of-errors] 
-[declaration-of-visibility]’;’ 
-
-(38) instance-method ::= identifier formal-part-of-instance-method 
-[declaration of returned type] 
-[declaration-of-errors] 
-[declaration-of-attributes-of-instancemethod]’;’ 
-
-(39) class-method ::= identifier formal-part-of-the-class-method 
-[declaration of returned type] 
-[declaration-of-errors] 
-[declaration-of-visibility]’;’ 
-
-(40) package-method ::= identifier [simple-formal-part] 
-[declaration-of-returned-type] 
-[declaration-of-errors] 
-[**is private**]’;’ 
-
-(41) member-method ::= constructor |  instance-method | class-method 
-
-(42) formal-part ::= simple-formal-part | formal-part-of-instance-method| formal-part-of-class-method 
-
-(43) friend ::= identifier **from** [**class**] class-name  [formal-part] 
-| identifier **from** [**package**] package-name [formal-part] | 
-[**class**] class-name 
-
-(44) field ::= identifier {’,’ identifier} ’:’ data-type 
-[’[’integer {’,’ integer}’]’] 
-[**is protected**]’;’ 
-
-45)  redefinition-of-field ::= [field-name] **from** [**class**] class-name 
-
-(46)  declaration-of-fields ::= **fields** [**redefined** redefinition-of-field  {’,’ redefinition-of-field}’;’] 
-field {field} 
-
-(47)  declaration-of-an-alias::= [**private**] **alias** class-name1 **is** class-name2  [**from** package-name] 
-
-(48)  declaration-of-friends ::= **friends** friend {’,’ friend} 
-
-(49) class-definition  ::= [{member-method}] 
-[declaration-of-fields] 
-[declaration-of-friends] 
-
-(50)  declaration-of-an-exception ::= **exception** exception-name **inherits** exception-name 
-
-(51) declaration-of-an-enumeration  ::= **enumeration** enumeration-name 
-**is** identifier {’,’  identifier} 
-[**end** [enumeration-name]]’;’ 
-
-(52)  incomplete-declaration-of-a-non-generic-class ::= 
-[**deferred**] **class** class-name’;’ 
-
-(53)  incomplete-declaration-of-a-generic-class ::= 
-[**deferred**] **generic class** class-name {’,’ class-name}’;’ 
-
-(54)  declaration-of-a-non-generic-class ::= 
-[**deferred**] **class** class-name 
-[**inherits** class-name 
-[**uses** data-type {’,’ data-type}] 
-[**raises** exception-name {’,’ exception-name}] 
-**is** definition-of-a-class 
-**end** [class-name]’;’ 
-
-(55) type-constraint ::= **any** | class-name  [’(’data-type {’,’ data-type}’)’] 
-
-(56) generic-type ::= identifier **as** type-constraint 
-
-(57) declaration-of-a-generic-class ::=
-[**deferred**] **generic class** class-name ’(’generic-type
-{’,’ generic-type}’)’
-[**inherits** class-name
-[**uses** data-type {’,’ data-type}]
-[**raises** exception-name {’,’ exception-name}]
-[{[visibility] declaration-of-a-class}]
-**is** class-definition
-**end** [class-name]’;’
-
-(58) instantiation-of-a-generic-class::=
-[**deferred**] **class** class-name
-**instantiates** class-name ’(’data-type
-{’,’ data-type}’);’
-
-(59) declaration-of-a-class::=
-incomplete-declaration-of-a-non-generic-class
-|
-incomplete-declaration-of-a-generic-class |
-declaration-of-a-non-generic-class |
-declaration-of-a-generic-class |
-instantiation-of-a-generic-class
-
-(60) type-declaration ::=
-[private] declaration-of-an-enumeration | [**private**] class-declaration | declaration-of-an-exception
-
-(61) package-definition ::=
-[{type-declaration}]
-[{package-method}]
-
-(62) package-declaration ::= **package** package-name
-[**uses** package-name {’,’ package-name}]
-  **is** package-definition
-**end** [package-name]’;’
-
-(63) executable-declaration ::=
-             **executable** executable-name
-                            **is**
-            {
-             **executable** executable-part
-[**uses** [identifier **as external**]
-     [{’,’ identifier **as external**}]
-     [unit-name **as library**]
-     [{’,’ unit-name **as library**}]
-                           **is**
-                     {file-name [as C++|c|fortran|object];}
-                               **end** ’;’
-                }
-                **end** ’;’
-
-(64) schema-declaration ::=
- **schema** schema-name
-  **is**
-[{**package** package-name ’;’ }]
-[{**class** class-name ’;’ }]
-**end** ’;’
-
-
-
-
-
-@section occt_cdl_6 Appendix B Comparison of CDL and C++ 
-
-## Syntax for Data Types manipulated by Handle and by Value in CDL
-
-|  | Handle | Value |
-| :---- | :---- | :---- | 
-| Permanent | Persistent | Storable |
-| Temporary | Transient | Any |
-| Reading | Immutable | In |
-| Writing | Mutable | Out |
-| Read/Write | Mutable | In out | 
-| Return | Not specified : any | Without copy: --C++ return const& |
-
-## Syntax for Data Types manipulated by Handle and by Value in C++
-
-| | Handle | Value |
-| :---- | :---- | :--- |
-| C++ Declaration | Handle(PGeom_Point) p1; | gp_Pnt p2; |
-| C++ Constructor | p1 = newPGeom_Point(p2); | p2(0.,0.,0.); |
-| C++ Method | x=p1 -> XCoord(); | x=p2.XCoord(); |
-
-
-   
\ No newline at end of file
diff --git a/dox/dev_guides/cdl/images/cdl_image003.png b/dox/dev_guides/cdl/images/cdl_image003.png
deleted file mode 100644 (file)
index 97f4480..0000000
Binary files a/dox/dev_guides/cdl/images/cdl_image003.png and /dev/null differ
diff --git a/dox/dev_guides/cdl/images/cdl_image004.png b/dox/dev_guides/cdl/images/cdl_image004.png
deleted file mode 100644 (file)
index 9a07132..0000000
Binary files a/dox/dev_guides/cdl/images/cdl_image004.png and /dev/null differ
diff --git a/dox/dev_guides/cdl/images/cdl_image005.png b/dox/dev_guides/cdl/images/cdl_image005.png
deleted file mode 100644 (file)
index 9c91d68..0000000
Binary files a/dox/dev_guides/cdl/images/cdl_image005.png and /dev/null differ
diff --git a/dox/dev_guides/cdl/images/cdl_image006.png b/dox/dev_guides/cdl/images/cdl_image006.png
deleted file mode 100644 (file)
index 3e1ba07..0000000
Binary files a/dox/dev_guides/cdl/images/cdl_image006.png and /dev/null differ
diff --git a/dox/dev_guides/cdl/images/cdl_image007.png b/dox/dev_guides/cdl/images/cdl_image007.png
deleted file mode 100644 (file)
index 869e4a2..0000000
Binary files a/dox/dev_guides/cdl/images/cdl_image007.png and /dev/null differ
diff --git a/dox/dev_guides/cdl/images/cdl_image008.png b/dox/dev_guides/cdl/images/cdl_image008.png
deleted file mode 100644 (file)
index 923e014..0000000
Binary files a/dox/dev_guides/cdl/images/cdl_image008.png and /dev/null differ
diff --git a/dox/dev_guides/cdl/images/cdl_image009.png b/dox/dev_guides/cdl/images/cdl_image009.png
deleted file mode 100644 (file)
index 5860e77..0000000
Binary files a/dox/dev_guides/cdl/images/cdl_image009.png and /dev/null differ
diff --git a/dox/dev_guides/cdl/images/cdl_image010.png b/dox/dev_guides/cdl/images/cdl_image010.png
deleted file mode 100644 (file)
index 701df35..0000000
Binary files a/dox/dev_guides/cdl/images/cdl_image010.png and /dev/null differ
diff --git a/dox/dev_guides/cdl/images/cdl_image011.png b/dox/dev_guides/cdl/images/cdl_image011.png
deleted file mode 100644 (file)
index 0c1546b..0000000
Binary files a/dox/dev_guides/cdl/images/cdl_image011.png and /dev/null differ
diff --git a/dox/dev_guides/cdl/images/cdl_image012.png b/dox/dev_guides/cdl/images/cdl_image012.png
deleted file mode 100644 (file)
index 2785fd9..0000000
Binary files a/dox/dev_guides/cdl/images/cdl_image012.png and /dev/null differ
index 44f43bf..f99855e 100644 (file)
@@ -11,12 +11,6 @@ The following documents provide information on OCCT building, development and te
 * @subpage occt_dev_guides__tests "Automatic Testing system"
 * @subpage occt_dev_guides__debug "Debugging tools and hints"
 
-These two documents provide details on obsolete technologies used by OCCT, 
-to be removed in future releases:
-
-* @subpage occt_dev_guides__wok "Workshop Organization Kit (WOK)"
-* @subpage occt_dev_guides__cdl "Component Definition Language (CDL)"
-
 The following guide provides information relevant to upgrading applications developed with previous versions of OCCT, to recent one:
 
 * @subpage occt_dev_guides__upgrade "Upgrade from previous OCCT versions"
index ce86f54..a8e10b2 100644 (file)
@@ -3,18 +3,35 @@ Upgrade from older OCCT versions  {#occt_dev_guides__upgrade}
 
 @tableofcontents
 
-@section occt_upgrade_intro Introduction
+@section upgrade_intro Introduction
 
-This document provides technical details on upgrading user applications using previous versions of OCCT, to the current one.
+This document provides technical details on changes made in particular versions of OCCT, and is aimed to help upgrading user applications based on previous versions of OCCT to newer ones.
 
-@subsection occt_upgrade_700 Upgrade to OCCT 7.0.0
+@subsection upgrade_intro_precautions Precautions
 
-@subsubsection occt_upgrade_700_persist Removal of legacy persistence
+Back-up your code before upgrade.
+We strongly recommend using version control system during upgrade process, saving one or several commits for each step of upgrade, until overall result is verified.
+This will facilitate identification and correction of possible problems that can occur on intermediate steps of upgrade.
+Carefully document each step to be able to repeat it if necessary.
+
+@subsection upgrade_intro_disclaim Disclaimer
+
+This document describes known issues that have been encountered in porting of OCCT and some applications, and approaches that helped to resolve these issues in known cases.
+It does not pretend to cover all possible migration issues that can appear in your application.
+Please take this document with discretion; apply your expertise and knowledge of your application to ensure correct result. 
+
+The automatic upgrade tool is provided as-is, without warranty of any kind, and we explicitly disclaim any liability for possible errors that may appear due to use of this tool. 
+It is your responsibility to ensure that the changes you made in your code are correct. 
+When upgrading your code by automatic script, make sure to carefully review the changes made by it, on each step, before committing them.
+
+@section upgrade_700 Upgrade to OCCT 7.0.0
+
+@subsection upgrade_700_persist Removal of legacy persistence
 
 Legacy persistence for shapes and OCAF data based on Storage_Schema (toolkits TKShapeShcema, TLStdLSchema, TKStdSchema, TKXCAFSchema) has been removed in OCCT 7.0.0.
 Applications that used these persistence tools for their data need to be updated to use other persistence mechanisms.
 
-The existing data files in standard formats can be converted using OCCT 6.9.0 or previous, as follows.
+The existing data files in standard formats can be converted using OCCT 6.9.0 or previous version, as follows.
 
 #### CSFDB files
 
@@ -55,3 +72,316 @@ For that, start *DRAWEXE* and perform the following commands:
 On Windows, be careful to replace back slashes in the file path by either direct slash or pairs of back slashes.
 Use "XmlOcaf" or "XmlXCAF" instead of "BinOcaf" and "BinXCAF", respectively, to save in XML format instead of binary one.
 
+@subsection upgrade_occt700_cdl Removal of CDL and WOK
+
+OCCT code has been completely refactored in version 7.0 to get rid of obsolete technologies used since its inception: CDL (Cas.Cade Definition Language) and WOK (Workshop Organization Kit).
+C++ code previously generated by WOK from CDL declarations is now included directly in OCCT sources.
+
+This modification did not change names, API, and behavior of existing OCCT classes, thus in general the code based on OCCT 6.x should compile and work fine with OCCT 7.0.
+However, due to redesign of basic mechanisms (CDL generic classes, Handles and RTTI) using C++ templates, some changes may be necessary in the code when porting to OCCT 7.0, as described below.
+
+WOK is not necessary anymore for building OCCT from sources, though it still can be used in traditional way -- auxiliary files required for that are preserved.
+The recommended method for building OCCT 7.x is CMake, see @ref occt_dev_guides__building_cmake.
+Alternative solution is to use legacy generator of project files (extracted from WOK), see @ref occt_dev_guides__building_wok.
+
+@subsubsection upgrade_occt700_cdl_auto Automatic upgrade
+
+Most of typical changes required for upgrading code to use OCCT 7.0 can be done automatically using the *upgrade* tool included in OCCT 7.0.
+This tool is a Tcl script, thus Tcl should be available on your workstation to run it.
+
+Example:
+~~~~~
+ $ tclsh
+ % source <path_to_occt>/adm/upgrade.tcl
+ % upgrade -recurse -all -src=<path_to_your_sources>
+~~~~~
+
+On Windows, helper batch script upgrade.bat can be used, provided that Tcl is either available in PATH, or configured via custom.bat script (for instance, if you use OCCT installed from Windows installer package). Start it from command prompt:
+
+~~~~~
+cmd> <path_to_occt>\upgrade.bat -recurse -all -inc=<path_to_occt>\inc -src=<path_to_your_sources> [options]
+~~~~~
+
+Run upgrade tool without arguments to see the list of available options.
+
+Upgrade tool performs the following changes in the code.
+
+1. Adds second argument to macro DEFINE_STANDARD_RTTI indicating base class for its argument class (if inheritance is recognized by the script):
+~~~~~
+DEFINE_STANDARD_RTTI(Class) -> DEFINE_STANDARD_RTTI(Class, Base)
+~~~~~
+
+2. Replaces forward declarations of collection classes previously generated from CDL generics (defined in TCollection package) by \#include of corresponding header:
+~~~~~
+class TColStd_Array1OfReal; -> #include <TColStd_Array1OfReal.hxx>
+~~~~~
+
+3. Replaces underscored names of Handle classes by usage of a macro:
+~~~~~
+Handle_Class -> Handle(Class)
+~~~~~
+  This change is not applied if source or header file is recognized as containing definition of Qt class with signals or slots, to avoid possible compilation errors of MOC files caused by inability of MOC to recognize macros (see http://doc.qt.io/qt-4.8/signalsandslots.html).
+  The file is considered as defining Qt object if it contains strings "Q_OBJECT" and either "slots:" or "signals". 
+
+4. Removes forward declarations of classes with names Handle(C) or Handle_C, replacing these either by forward declaration of its argument class, or (for files defining Qt objects) \#include statement for header with name of the argument class and extension .hxx:
+~~~~~
+class Handle(TColStd_HArray1OfReal); -> #include <TColStd_HArray1OfReal.hxx>
+~~~~~
+
+5. Removes \#includes of files Handle_...hxx disappeared in OCCT 7.0:
+~~~~~
+#include <Handle_Geom_Curve.hxx> ->
+~~~~~
+
+6. Removes typedef statements that use Handle macro to generate name:
+~~~~~
+typedef NCollection_Handle<Message_Msg> Handle(Message_Msg); ->
+~~~~~
+
+7. Converts C-style casts applied to Handles to calls to DownCast() method:
+~~~~~
+    ((Handle(A)&)b)     -> Handle(A)::DownCast(b)
+    (Handle(A)&)b       -> Handle(A)::DownCast(b)
+    (*((Handle(A)*)&b)) -> Handle(A)::DownCast(b)
+    *((Handle(A)*)&b)   -> Handle(A)::DownCast(b)
+    (*(Handle(A)*)&b)   -> Handle(A)::DownCast(b)
+~~~~~
+
+8. Moves Handle() macro out of namespace scope:
+~~~~~
+Namespace::Handle(Class) -> Handle(Namespace::Class)
+~~~~~
+
+9. Converts local variables of reference type initialized by temporary object returned by call to DownCast(), to non-references (to avoid using reference to destroyed memory):
+~~~~~
+    const Handle(A)& a = Handle(B)::DownCast (b); -> Handle(A) a (Handle(B)::DownCast (b));
+~~~~~
+
+10. Adds \#include for all classes used as argument to macro STANDARD_TYPE(), except of already included ones;
+
+11. Removes uses of obsolete macros IMPLEMENT_DOWNCAST() and IMPLEMENT_STANDARD_*().
+
+  > If you plan to keep compatibility of your code with older versions of OCCT, add option "-compat" to avoid the latter change. See also @ref upgrade_occt700_cdl_compat.
+
+As long as the upgrade routine runs, some information messages are sent to the standard output. 
+In some cases the warnings or errors like the following may appear:
+
+~~~~~
+  Error in {HEADER_FILE}: Macro DEFINE_STANDARD_RTTI used for class {CLASS_NAME} whose declaration is not found in this file, cannot fix
+~~~~~
+
+Be sure to check carefully all reported errors and warnings, as corresponding places likely will require manual corrections.
+In some cases these messages may help you to detect errors in your code, for instance, cases where DEFINE_STANDARD_RTTI macro passes invalid class name as an argument.
+
+@subsubsection upgrade_occt700_cdl_compiler Possible compiler errors
+
+Some situations requiring upgrade cannot be detected and / or handled by automatic procedure.
+If you get compiler errors or warnings when trying to build upgraded code, you will need to fix them manually. 
+The following paragraphs list known situations of this kind.
+
+#### Missing header files
+
+Use of handle objects (construction, comparison using operators == or !=, use of function STANDRAD_TYPE() and method DownCast()) now requires the type of the object pointed by Handle to be completely known at compile time. Thus it may be necessary to include header of the corresponding class to make the code compilable.
+
+For example, the following lines will fail to compile if Geom_Line.hxx is not included:
+
+~~~~~
+Handle(Geom_Line) aLine = 0;
+if (aLine != aCurve) {...} 
+if (aCurve->IsKind(STANDARD_TYPE(Geom_Line)) {...}
+aLine = Handle(Geom_Line)::DownCast (aCurve);
+~~~~~
+
+Note that it is not necessary to include header of the class to declare Handle to it.
+However, if you define a class *B* that uses Handle(*A*) in its fields, or contains a method returning Handle(*A*), it is advisable to have header defining *A* included in the header of *B*.
+This will eliminate the need to include the header *A* in each source file where class *B* is used.
+
+#### Ambiguity of calls to overloaded functions
+
+This issue appears in compilers that do not support default arguments in template functions (known cases are Visual C++ 10 and 11): compiler reports ambiguity error if handle is used in argument of call to function that has two or move overloaded versions, accepting handles to different types. 
+The problem is that operator const handle<T2>& is defined for any type T2, thus compiler cannot make a right choice.
+
+Example:
+~~~~~
+void func (const Handle(Geom_Curve)&);
+void func (const Handle(Geom_Surface)&);
+
+Handle(Geom_TrimmedCurve) aCurve = new Geom_TrimmedCurve (...);
+func (aCurve); // ambiguity error in VC++ 10
+~~~~~
+
+To resolve this ambiguity, change your code so that argument type corresponds exactly to the function signature. 
+In some cases this can be done by using relevant type for the corresponding variable, like in the example above:
+
+~~~~~
+Handle(Geom_Curve) aCurve = new Geom_TrimmedCurve (...);  
+~~~~~
+
+Other variants are assigning the argument to local variable of correct type, using direct cast or constructor:
+
+~~~~~
+const Handle(Geom_Curve)& aGCurve (aTrimmedCurve);
+func (aGCurve); // OK - argument has exact type
+func (static_cast(aCurve)); // OK - direct cast 
+func (Handle(Geom_Curve)(aCurve)); // OK - temporary handle is constructed
+~~~~~
+
+Another possibility is defining additional templated variant of the overloaded function causing ambiguity, and use SFINAE to resolve the ambiguity.
+For example of this technique, see definition of the template variant of the method IGESData_IGESWriter::Send().
+
+#### Lack of implicit cast to base type
+
+Due to the fact that now cast of handle to reference to handle to the base type is user-defined operation, conversions that require this cast combined with other user-defined cast will not be resolved automatically by compiler.
+
+For example:
+
+~~~~~
+Handle(Geom_Geometry) aC = GC_MakeLine (p, v); // compiler error
+~~~~~
+
+The problem here is that class GCE2d_MakeSegment has user-defined conversion to const Handle(Geom_TrimmedCurve)&, which is not the same as type of the local variable aC.
+
+To resolve this, use method Value():
+
+~~~~~
+Handle(Geom_Geometry) aC = GC_MakeLine (p, v).Value(); // ok
+~~~~~
+
+or use variable of appropriate type:
+
+~~~~~
+Handle(Geom_TrimmedCurve) aC = GC_MakeLine (p, v); // ok
+~~~~~
+
+#### Incorrect use of STANDARD_TYPE and Handle macros
+
+You might need to clean your code from incorrect use of macros *STANDARD_TYPE*() and *Handle*().
+
+1. Explicit definitions of static functions with names generated by macro STANDARD_TYPE(), which are artifacts of old implementation of RTTI, should be removed.
+   
+   Example:
+~~~~~
+const Handle(Standard_Type)& STANDARD_TYPE(math_GlobOptMin)
+{
+  static Handle(Standard_Type) _atype = new Standard_Type ("math_GlobOptMin", sizeof (math_GlobOptMin));
+  return _atype;
+}
+~~~~~
+
+2. Incorrect location of closing parenthesis of Handle() macro that was not detectable in OCCT 6.x will cause compiler error and must be corrected.
+
+   Example (note misplaced closing parenthesis):
+~~~~~
+aBSpline = Handle( Geom2d_BSplineCurve::DownCast(BS->Copy()) );
+~~~~~
+
+#### Use of class Standard_AncestorIterator
+
+Class Standard_AncestorIterator has been removed; use method Parent() of Standard_Type class to parse inheritance chain.
+
+#### Absence of cast to Standard_Transient*
+
+Handles in OCCT 7.0 do not have operator of conversion to Standard_Transient*, which was present in earlier versions.
+This is done to prevent possible unintended errors like this:
+
+~~~~~
+Handle(Geom_Line) aLine = ...;
+Handle(Geom_Surface) aSurf = ...;
+...
+if (aLine == aSurf) {...} // will cause compiler error in OCCT 7.0, but not OCCT 6.x
+~~~~~
+
+Places where this implicit cast has been used should be corrected manually.
+The typical situation is when Handle is passed to stream:
+
+~~~~~
+Handle(Geom_Line) aLine = ...;
+os << aLine; // in OCCT 6.9.0, resolves to operator << (void*) 
+~~~~~
+
+Call method get() explicitly to output address of the Handle.
+
+@subsubsection upgrade_occt700_cdl_runtime Possible runtime problems
+
+Known situations when problems are possible at run time after upgrade to OCCT 7.0 are listed here.
+
+#### References to temporary objects
+
+In previous versions, compiler was able to detect situation when local variable of reference type to Handle is initialized by temporary object, and ensured that lifetime of that object is longer than that of the variable. 
+Since OCCT 7.0, it will not work if types of the temporary object and variable are different (due to involvement of user-defined type cast), thus such temporary object will be destroyed immediately.
+
+Example:
+
+~~~~~
+// note that DownCast() returns new temporary object!
+const Handle(Geom_BoundedCurve)& aBC =
+Handle(Geom_TrimmedCurve)::DownCast(aCurve);
+aBC->Transform (T); // access violation in OCCT 7.0
+~~~~~
+
+@subsubsection upgrade_occt700_cdl_compat Preserving compatibility with OCCT 6.x
+
+If you like to preserve compatibility of your application code with OCCT versions 6.x even after upgrade to 7.0, consider the following suggestions:
+
+1. When running automatic upgrade tool, add option *-compat*.
+
+2. In order to overcome incompatibility of macro DEFINE_STANDARD_RTTI which has additional argument in OCCT 7.0, you can replace (after upgrade) its use in your code by your own version-dependent macro, which resolves to either 6.x or 7.x version.
+
+   Example:
+~~~~~   
+#if OCC_VERSION_HEX < 0x070000
+  #define DEFINE_STANDARD_RTTI_COMPAT(C1,C2) DEFINE_STANDARD_RTTI(C1) 
+#else
+  #define DEFINE_STANDARD_RTTI_COMPAT(C1,C2) DEFINE_STANDARD_RTTI(C1,C2) 
+#endif
+~~~~~
+
+@subsubsection upgrade_occt700_cdl_wok Applications based on CDL and WOK
+
+If you have application essentially based on CDL, and need to upgrade it to OCCT 7.0, you will very likely need to convert your application code to non-CDL form.
+This is non-trivial effort; the required actions would depend strongly on the structure of the code and used features of CDL.
+
+The upgrade script and sources of specialized version of WOK used for upgrading OCCT code can be found in WOK Git repository in branch [CR0_700_2](http://git.dev.opencascade.org/gitweb/?p=occt-wok.git;a=log;h=refs/heads/CR0_700_2).
+
+[Contact us](http://www.opencascade.com/contact/) if you need more help.
+
+@subsection upgrade_occt700_bspline Separation of BSpline cache
+
+Implementation of NURBS curves and surfaces has been revised: cache of polynomial coefficients, used to accelerate calculate values of B-spline, is separated from data objects (Geom2d_BSplineCurve, Geom_BSplineCurve, Geom_BSplineSurface), into dedicated classes (BSplCLib_Cache and BSplSLib_Cache). 
+
+The benefits of this change are:
+
+* Reduced memory footprint of OCCT shapes (up to 20% on some cases)
+* Possibility to evaluate the same B-Spline concurrently in parallel threads without data races and mutex locks 
+
+The drawback is that direct evaluation of B-Splines using methods of curves and surfaces becomes slower, due to absence of cache. The way to avoid slow down is to use adaptor classes (Geom2dAdaptor_Curve, GeomAdaptor_Curve and GeomAdaptor_Surface): they now use cache when the curve or surface is a B-spline.
+
+OCCT algorithms are changed to use adaptors for B-spline calculations instead of direct methods of curves and surfaces.
+The same changes (use of adaptors instead of direct call to curve and surface methods) should be implemented in relevant places in applications based on OCCT in order to get maximum performance.
+
+@subsection upgrade_occt700_sorttools Removal of SortTools package
+
+Package SortTools has been removed. 
+The code that used the tools provided by that package should be corrected manually.
+The recommended approach is to use sorting algorithms provided by STL.
+
+For instance:
+~~~~~
+#include <SortTools_StraightInsertionSortOfReal.hxx>
+#include <SortTools_ShellSortOfReal.hxx>
+#include <TCollection_CompareOfReal.hxx>
+...
+TCollection_Array1OfReal aValues = ...;
+...
+TCollection_CompareOfReal aCompReal;
+SortTools_StraightInsertionSortOfReal::Sort(aValues, aCompReal);
+~~~~~
+can be replaced by:
+~~~~~
+#include <algorithm>
+...
+TCollection_Array1OfReal aValues = ...;
+...
+std::stable_sort (aValues->begin(), aValues->end());
+~~~~~
+
diff --git a/dox/dev_guides/wok/images/wok_image005.jpg b/dox/dev_guides/wok/images/wok_image005.jpg
deleted file mode 100644 (file)
index d5f92d4..0000000
Binary files a/dox/dev_guides/wok/images/wok_image005.jpg and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image005.png b/dox/dev_guides/wok/images/wok_image005.png
deleted file mode 100644 (file)
index f0937f8..0000000
Binary files a/dox/dev_guides/wok/images/wok_image005.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image006.png b/dox/dev_guides/wok/images/wok_image006.png
deleted file mode 100644 (file)
index 29a2843..0000000
Binary files a/dox/dev_guides/wok/images/wok_image006.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image007.png b/dox/dev_guides/wok/images/wok_image007.png
deleted file mode 100644 (file)
index 3cd21fc..0000000
Binary files a/dox/dev_guides/wok/images/wok_image007.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image008.png b/dox/dev_guides/wok/images/wok_image008.png
deleted file mode 100644 (file)
index 7df90f6..0000000
Binary files a/dox/dev_guides/wok/images/wok_image008.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image009.png b/dox/dev_guides/wok/images/wok_image009.png
deleted file mode 100644 (file)
index 5ede9e4..0000000
Binary files a/dox/dev_guides/wok/images/wok_image009.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image010.png b/dox/dev_guides/wok/images/wok_image010.png
deleted file mode 100644 (file)
index a4fcaa0..0000000
Binary files a/dox/dev_guides/wok/images/wok_image010.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image011.png b/dox/dev_guides/wok/images/wok_image011.png
deleted file mode 100644 (file)
index 172cafd..0000000
Binary files a/dox/dev_guides/wok/images/wok_image011.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image012.png b/dox/dev_guides/wok/images/wok_image012.png
deleted file mode 100644 (file)
index 241f534..0000000
Binary files a/dox/dev_guides/wok/images/wok_image012.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image013.png b/dox/dev_guides/wok/images/wok_image013.png
deleted file mode 100644 (file)
index af43ae4..0000000
Binary files a/dox/dev_guides/wok/images/wok_image013.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image014.png b/dox/dev_guides/wok/images/wok_image014.png
deleted file mode 100644 (file)
index 30bb297..0000000
Binary files a/dox/dev_guides/wok/images/wok_image014.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image015.png b/dox/dev_guides/wok/images/wok_image015.png
deleted file mode 100644 (file)
index f5e58c1..0000000
Binary files a/dox/dev_guides/wok/images/wok_image015.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image016.png b/dox/dev_guides/wok/images/wok_image016.png
deleted file mode 100644 (file)
index bc68e29..0000000
Binary files a/dox/dev_guides/wok/images/wok_image016.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image017.png b/dox/dev_guides/wok/images/wok_image017.png
deleted file mode 100644 (file)
index 47e1ed5..0000000
Binary files a/dox/dev_guides/wok/images/wok_image017.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image018.png b/dox/dev_guides/wok/images/wok_image018.png
deleted file mode 100644 (file)
index 57a221d..0000000
Binary files a/dox/dev_guides/wok/images/wok_image018.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image019.png b/dox/dev_guides/wok/images/wok_image019.png
deleted file mode 100644 (file)
index fa39eff..0000000
Binary files a/dox/dev_guides/wok/images/wok_image019.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image020.png b/dox/dev_guides/wok/images/wok_image020.png
deleted file mode 100644 (file)
index 3540fdc..0000000
Binary files a/dox/dev_guides/wok/images/wok_image020.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image021.png b/dox/dev_guides/wok/images/wok_image021.png
deleted file mode 100644 (file)
index 795e2e2..0000000
Binary files a/dox/dev_guides/wok/images/wok_image021.png and /dev/null differ
diff --git a/dox/dev_guides/wok/images/wok_image022.png b/dox/dev_guides/wok/images/wok_image022.png
deleted file mode 100644 (file)
index 0dad63c..0000000
Binary files a/dox/dev_guides/wok/images/wok_image022.png and /dev/null differ
diff --git a/dox/dev_guides/wok/wok.md b/dox/dev_guides/wok/wok.md
deleted file mode 100644 (file)
index d680815..0000000
+++ /dev/null
@@ -1,3277 +0,0 @@
-Workshop Organisation Kit  {#occt_dev_guides__wok}
-=========================
-
-@tableofcontents
-
-@section occt_wok_0 DEPRECATION WARNING
-
-Please note that this document describes use of WOK as comprehensive build system. This use is outdated, and WOK is to be removed in one of the future OCCT  releases.
-
-Currently only a small subset of WOK capabilities described in this document
-is actually necessary for building OCCT. See @ref occt_dev_guides__building_wok
-for a more practical guide.
-
-@section occt_wok_1_ Introduction Glossary
-
-@subsection occt_wok_1_1 About the Development Environment
-
-Open CASCADE Technology (**OCCT**) development environment is able to accommodate large numbers of developers working on a variety of products. Within this environment developers can produce multiple versions of products for various hardware and software platforms, including versions corresponding to particular marketing requirements. At the same time, OCCT development environment enables the maximum possible reuse of software components. In other words, OCCT development environment is designed to facilitate industrial scale development.  
-@subsection occt_wok_1_2 Brief Overview of Open CASCADE Technology Development Environment
-The following diagram shows OPEN CASCADE tools and resources, the development method, and the architecture of applications that you can develop with Open CASCADE Technology.   
-
-@image html /dev_guides/wok/images/wok_image005.png "Schematic View of OCCT Development Platform"
-@image latex /dev_guides/wok/images/wok_image005.png "Schematic View of OCCT Development Platform"
-
-The application developer goes about creating his application by editing his source code and producing the final application using a set of intelligent construction tools. These tools are available within a structured development environment called the **software factory**.  
-
-The developer defines new software components in CDL, Component Description Language, and uses a CDL compiler to derive their C++ implementations. These components are then compiled into packages.  
-@subsection occt_wok_1_3 WOK Components
-@subsubsection occt_wok_1_3_1 Entities
-The WOK environment is made up of entities, for example software factories and development units. A full list of WOK entities is provided in the <a href="#occt_wok_1_4">Glossary</a> section. 
-@subsubsection occt_wok_1_3_2 Files
-WOK manages two different types of files: user source files and WOK administration files. To support this, each entity has a home directory, which contains its administration directory. This is called *adm* and stores the administration files that WOK needs. In addition development units have a source directory called *src*, which contains both .cdl and .cxx source files, and a header file directory called *inc*, which contains .hxx files.  
-
-@subsection occt_wok_1_4 Glossary
-@subsubsection occt_wok_1_4_1 Development Units
-A **development unit** is the smallest unit that can be subject to basic development operations such as modifying, compiling, linking and building.  
-The following list contains all types of development units. The letter in parentheses indicates the letter key by commands such as *ucreate* and *umake*. In the rest of the manual, this letter key is referred to as the *short key*. 
-* package (p) A set of related classes and methods along with their CDL definitions. 
-* schema (s) A set of persistent data types. 
-* executable (x) An executable is used for unit and integration test purposes. It is based on one or more packages. 
-* nocdlpack (n) A package without a CDL definition. Used for low-level programming or for incorporating foreign resources. 
-* interface (i) A specific set of services available for wrapping (an interface contains packages, classes, and methods). 
-* jni (j) A development unit used to wrap C++ classes to Java. It is based on one or more interfaces. 
-* toolkit (t) A set of packages. Useful in grouping packages together when there is a large number of packages based around a particular subject. 
-* delivery (d) A development unit for publishing development units. 
-* resource (r) A development unit containing miscellaneous files. 
-
-@subsubsection occt_wok_1_4_2 Workbenches
-A workbench is a specialized directory structure where the user creates, modifies, and uses development units. A workbench is likely to be the personal property of one user or at most a small team of developers. 
-@image html /dev_guides/wok/images/wok_image006.png "Schema of a Workbench Containing three Development Units"
-@image latex /dev_guides/wok/images/wok_image006.png "Schema of a Workbench Containing three Development Units"
-
-@subsubsection occt_wok_1_4_3 Workshops
-A workshop is a tree of workbenches. It provides the development team with an independent workspace inside which the complete cycle of software production can be carried out. 
-The root workbench is in a valid state and contains the working versions of the development units. 
-Development units in a root workbench are visible in its child workbenches. 
-
-For example, the schema below shows a workshop containing three workbenches. Workbenches B and C are the children of workbench A. Development units in A are visible in both B and C
-@image html /dev_guides/wok/images/wok_image007.png "Workbenches"
-@image latex /dev_guides/wok/images/wok_image007.png "Workbenches"
-
-Workshops are fully independent of each other. They are organized in such a way that development units can be grouped into a delivery and placed in a warehouse. Communication between workshops is carried out by means of these deliveries. A warehouse belongs to a factory and is visible from all workshops in that factory. In this way, development units can be shared between a group of development teams. 
-
-@image html /dev_guides/wok/images/wok_image008.png "Two Workshops Delivering and Borrowing Parcels"
-@image latex /dev_guides/wok/images/wok_image008.png "Two Workshops Delivering and Borrowing Parcels"
-
-@subsubsection occt_wok_1_4_4 Factories
-A factory is a set of workshops and their corresponding warehouse. There is a single warehouse in any factory. The continuous upgrading and improvement of a product is carried out in a specific factory. 
-To create a new version of an application within the factory, you establish a new workshop dedicated to creation and support of the new version. 
-
-@image html /dev_guides/wok/images/wok_image009.png "Factory Contains Workshops and Warehouse"
-@image latex /dev_guides/wok/images/wok_image009.png "Factory Contains Workshops and Warehouse"
-
-@section occt_wok_2_ Elements of the Platform
-@subsection occt_wok_2_1 Development Units
-A **development unit** is the basic element of WOK development. It includes the following three entities: 
-  *  A directory structure (a minor component) 
-  *  Source files, also called primary files 
-  *  The result of the build process (compilation, etc.), also called derived files. 
-
-@subsubsection occt_wok_2_1_1 Directory Structure of a Development Unit
-The directory structure of a development unit consists of a tree of directories, which are created when the development unit is initialized. Refer to the <a href="#occt_wok_2_2">Workbenches</a> section for further details on the workbench structure. 
-@subsubsection occt_wok_2_1_2 Files in a Development Unit
-
-#### Source Files
-Source files are written by the developer in the source section (the *src* directory) of the development unit. 
-Each development unit maintains the description of its own source files, and this description is stored in one or more files within the *src* directory. The details of how the description is stored vary according to development unit type as shown below: 
-* package (p) The names of all source files are worked out from the CDL description, following the conventions described in the *C++ Programming Guide*. This list of files can be supplemented by additional files listed in the file called FILES. This file must be stored in the unit’s src directory. Whenever header files are included in the *src* directory of a development unit, they must be specified in FILES so that the C++ preprocessor will take them into account. This reduces compilation time by 10 to 40 percent. 
-* schema (s) No description of the source files is needed. There is a single source file: *schema.cdl*. 
-* executable (x) The names of all source files are worked out from the CDL description. The format of this file is described in the <a href="#occt_wok_3_5">Building an Executable</a> section. 
-* nocdlpack (n) The list of source files is contained in the FILES file stored in the unit’s src directory. 
-interface (i). No description of the source files is needed. There is a single source file: *interface.cdl*. 
-* jni (j). No description of the source files is needed. There is a single source file: *jni.cdl*. 
-* toolkit (t) The description is given by the file called PACKAGES which is stored in the unit’s src directory. FILES must also exist in this directory, and must include PACKAGES in its list of files. 
-* delivery (d) The description is given by two files stored in the unit’s src directory: FILES and a file called COMPONENTS. FILES must include COMPONENTS in its list of files. 
-* resource (r) A resource unit is used in a delivery. FILES contains a list of the unit’s files, one per line in the following format: *atype\:\:\:afilename*  Here, *filename* is the name of a file, which the compiler will look for in the src directory of the unit, and *atype* is a WOK type. To display a list of all available WOK types, use the command: *wokinfo -T*. 
-
-#### Derived files
-
-Derived files created by compilation are automatically placed in the derived section of the development unit. These may be executable files or archives of compilation results. 
-
-@subsubsection occt_wok_2_1_3 Package
-
-A package is a development unit that defines a set of classes, which share a number of common features such as similar data structure or a set of complementary algorithmic services. Packages help to manage creation and the use of large hierarchies of software components.  
-To create a package, you write a .cdl file describing it in the src directory of the package development unit. The description includes classes and global methods, which comprise it. Each class is also described in a separate .cdl file. The package .cdl file also lists the packages used in the specification of its classes and methods. 
-C++ implementation files are also stored in the src subdirectory of the package development unit. These implementation files are: 
-  *  .cxx for an ordinary class 
-  *  .lxx for any inline methods 
-  *  .pxx for any private declarations 
-  *  .gxx for a generic class 
-  
-To create the Development Unit structure for a package use the following syntax:
-~~~~~
-ucreate –p MyPackage 
-~~~~~
-
-The package description has the following CDL syntax: 
-~~~~~
-package PackageName 
-[uses AnotherPackage {‘,’ YetAnotherPackage}] 
-is 
-[{type-declaration}] 
-[{package-method}] 
-end [PackageName]’:’ 
-~~~~~
-
-For example:
-~~~~~
-package CycleModel 
-uses 
-Pcollection 
-Tcollection 
-BREpPrimAPI 
-TopExp 
-Geom 
-Pgeom 
-is 
-deferred class Element; 
-class Wheel; 
-class Frame; 
-class LocalReference; 
-Adjust(awheel: wheel from CycleModel; 
-  aframe: Frame from CycleModel); 
-end CycleModel; 
-~~~~~
-For full details on the CDL syntax, refer to the *CDL User’s Guide*. 
-
-@subsubsection occt_wok_2_1_4 Schema
-
-A schema is a development unit that defines the set of all data types, which your application is likely to need in order to read and write files. Such data types are **persistent**. 
-
-To create a schema, write a .cdl file that lists all the packages, which contain all persistent data types used by the application. Note that only persistent classes are taken into account during compilation; transient classes are ignored. 
-
-Note that you don’t have to put dependencies in all packages and classes. You only have to write the highest level dependencies. In other words, the *uses* keyword in the schema file allows you to list packages. Any package similarly listed in the package files for these packages are also incorporated into the schema. 
-
-To create the Development Unit structure for a schema use the syntax below: 
-~~~~~
-ucreate –s MySchema 
-~~~~~
-
-The schema description has the following CDL syntax : 
-
-~~~~~
-schema SchemaName 
-is 
-ListOfPackagesContainingPersistentClasses; 
-ListOfPersistentClasses; 
-end; 
-~~~~~
-
-For example:
-~~~~~ 
-schema MyCycleSchema 
-is 
-class Wheel from package CycleModel; 
-class Frame from package CycleModel; 
-.. 
-class Spanner from package CycleTools; 
-end; 
-~~~~~
-For full details on the CDL syntax, refer to the *CDL User’s Guide*. 
-
-@subsubsection occt_wok_2_1_5 Executable
-The purpose of an executable is to make executable programs. The executable can use services from one or more packages and is described in a .cdl file as a set of packages. 
-
-To create an executable, you write one or more MyExe.cxx files in the src subdirectory of the unit. This file will contain the main function. Then it is possible to compile the executable. 
-
-To create the Development Unit structure for an executable, use the syntax below: 
-~~~~~
-ucreate –x MyExec 
-~~~~~
-
-The executable description has the following CDL syntax: 
-~~~~~
-executable ExecName 
-is 
-executable BinaryFile 
-uses 
-LibFile as external 
-is 
-C++File; 
-end; 
-end; 
-~~~~~
-
-For example:
-~~~~~
-executable MyExecUnit’ 
-is 
-executable myexec 
-uses 
-Tcl_Lib as external 
-is 
-myexec; 
-end; 
-executable myex2 
-is 
-myex2; 
-end; 
-end; 
-~~~~~
-For full details on the CDL syntax, refer to the *CDL Reference Manual*. 
-
-@subsubsection occt_wok_2_1_6 Toolkit
-A toolkit is a development unit that groups a set of packages to create a shareable library. An example of a toolkit is the ModelingData module. Toolkits serve for the following purposes: 
-  *  Linking of large numbers of packages 
-  *  Faster loading of executable files that use toolkits such as test files. 
-  
-A toolkit has no CDL definition. Creating a toolkit involves writing a PACKAGES file in the src subdirectory of its development unit. This file lists all the packages needed in the toolkit. You then create a definition of this file to the FILES. 
-
-You then compile the toolkit to create a shareable library. 
-
-@subsubsection occt_wok_2_1_7 Nocdlpack
-A nocdlpack is a development unit that has no CDL definition. It is compiled directly from source files written in C, C++, Fortran, or in sources to be treated by the lex or yacc tools. A nocdlpack is useful when you write a low-level interface with another product, for example, a network application. 
-
-To define a nocdlpack, you create a file called FILES in the src subdirectory of the nocdlpack development unit. In this file, you list the Fortran, C, C++, lex, and yacc files that compose the pack. You list the files one per line. 
-
-On compilation, the result is a shareable library. 
-
-@subsubsection occt_wok_2_1_8 Interface
-An interface is a development unit that defines a set of services available for wrapping into Java. 
-An interface is defined in a .cdl file as a list of packages, package methods, classes, and methods. It makes these available to a jni unit. 
-
-To create the Development Unit structure for an interface, use the syntax below: 
-~~~~~
-ucreate -i MyInterface 
-~~~~~
-
-The interface description has the following CDL syntax: 
-
-~~~~~
-interface InterfaceName 
-is 
-ListOfPackages 
-ListOfClasses 
-ListOfMethods 
-end; 
-~~~~~
-
-For example:
-~~~~~
-interface MyInterface 
-is 
-        package TopoDS; 
-        class Shape from ShapeFix; 
-end ; 
-~~~~~
-
-@subsubsection occt_wok_2_1_9 Jni
-A jni is a development unit that wraps declared services into Java using JNI (Java Native Interface). 
-
-A jni creates Java classes that are used as C++ counterparts when developing in Java. 
-
-To create the Development Unit structure for an Jni, use the syntax below: 
-ucreate -j MyJni 
-
-The interface description has the following CDL syntax: 
-~~~~~
-client JniName 
-is 
-{interface InterfaceName;} 
-end; 
-~~~~~
-
-For example :
-~~~~~
-client MyJni 
-is 
-        interface MyInterface; 
-        interface MyAnotherInterface; 
-end ; 
-~~~~~
-
-@subsubsection occt_wok_2_1_10 Delivering Parcels
-The delivery process allows creating parcels. These parcels group together the development work done within a given workshop. You can ship these parcels to other workshops called client workshops. 
-
-A delivery is autonomous. Once the delivery development unit is compiled, a parcel is stored in the factory warehouse and has no more connection with the workshop where it was created. A parcel has its own directory structure. 
-
-All Open CASCADE Technology resources are seen as parcels. 
-
-@image html /dev_guides/wok/images/wok_image010.png "Parcels"
-@image latex /dev_guides/wok/images/wok_image010.png "Parcels"
-   
-You create a delivery unit under a specified workbench. 
-
-You are **strongly advised** to create delivery units under the *root* workbench of the workshop. Child workbenches could be deleted in the future, whereas the root workbench is likely to remain untouched. In other words, you safeguard the delivery by creating it in the root workbench. 
-
-**Note** If you do not specify a workbench when you make a delivery, it is created under the current workbench.
-@subsection occt_wok_2_2  Workbenches
-A workbench is generally the place where one particular developer or a team of developers works on a particular development. A workbench is composed of a public part and a private part. 
-
-@subsubsection occt_wok_2_2_1  Roots
-The following roots are used in the structure of a workbench: 
-* **Home** Workbench root containing various administration files of the workbench. 
-* **Src** Root of the workbench sources, which facilitates the integration into WOK of version management software such as CVS. 
-* **DBMS** Root of the derived files dependent on the extraction profile (.hxx, _0.cxx files, etc.). 
-* **DBMS_Station** Roots of the derived files dependent on the extraction profile and on the platform (.o, .so files, etc.). 
-
-Roots are defined for each profile and platform supported by the workbench. For example, a workbench supporting the DFLT profile on Sun and SGI platforms has the following roots: 
-* **Home** Workbench root, 
-* **Src** Root of the source files, 
-* **DFLT** Root of the derived files, 
-* **DFLT_sun** Root of the files built on Sun platforms, 
-* **DFLT_sil** Root of the files built on SGI platforms, 
-
-For a workbench additionally supporting *ObjectStore*, the following additional roots are also found: *OBJS, OBJS_sun, OBJS_sil*.
-These roots are defined in the workbench definition file *MyWorkbench.edl* as the parameter <i>\%MyWorkbench_RootName</i>. 
-
-**Note** that default values help to define various roots.
-@subsubsection occt_wok_2_2_2  Directories
-Under each root, a hierarchy of directories allows to store various files. 
-* Under the Home root are found: 
-  *  *work*, the private workbench directory reserved for the developer 
-  *  *Adm*, the directory reserved for administration files. 
-* Src contains: 
-  *  *src/MyUD*, the directory containing the source files of the development unit MyUD. 
-* DBMS contains: 
-  *  *inc*, containing the public header files of the workbench UDs 
-  *  *drv/MyUD*, containing the private extracted files of MyUD 
-  *  *drv/MyUD/.adm*, containing the administration files dependent on the extraction profile 
-  *  *drv/MyUD/.tmp*, containing the temporary files dependent on the extraction profile. 
-* DBMS_Station contains: 
-  * *\<station\>/lib* with all the libraries produced in the workbench
-  * *\<station\>/bin* with all the binaries produced in the workbench
-  * *\<station\>/MyUD* with all the station dependent files which are private to the development unit such as objects
-  * *\<station\>/MyUD/.adm* with all the station dependent administration files
-  * *\<station\>/MyUD/.tmp* with all the temporary files constructed in the development unit.
-
-  
-@image html /dev_guides/wok/images/wok_image011.png "Structure of the workbench Mywb"
-@image latex /dev_guides/wok/images/wok_image011.png "Structure of the workbench Mywb"
-
-@subsection occt_wok_2_2_3  Workshops
-A **workshop** is an independent workspace inside which the complete cycle of software production is carried out. Workbenches inside a workshop are organized so that development units can be shared either by being published in a father workbench or by being placed in reference in the root workbench.
-@image html /dev_guides/wok/images/wok_image012.png "Visibility between Workbenches in a Workshop"
-@image latex /dev_guides/wok/images/wok_image012.png "Visibility between Workbenches in a Workshop"
-
-In this image:
- * **A** is the development unit A from Grandchild 11  placed in reference in root. It is visible throughout the workshop. 
- * **B** is the development unit B from Grandchild 12 published in ancestor Child 1. It is visible to Child 1, Grandchild 11 and  Grandchild 12.
-
-
-In a large-scale development that involves one or more teams of developers, you should decide how you are going to structure a workshop right at the beginning. If need be, you can review your decision later. 
-
-An existing workshop can be duplicated and the original workshop can be used as the basis for maintaining the present version of a product. The new workshop can then be used to develop and maintain a new version of the product. 
-
-When creating a new workshop, you specify - in the form of parcels – which resources are to be available within the workshop. 
-
-@subsection occt_wok_2_2_4  Factories
-A factory contains a number of workshops and a warehouse. When Open CASCADE Technology is installed, the system administrator creates a single factory. This contains a single workshop as well as the warehouse containing OCCT resources in the form of parcels. 
-
-There is no theoretical limit to the number of workshops that can be added to a factory. However, a single factory should be enough. 
-
-@section occt_wok_3 Development Process
-@subsection occt_wok_3_1  WOK Environment
-The WOK interface is based on tcl, a command language provided by the Regents of the University of California and Sun Microsystems, Inc. The WOK development environment is in fact a tcl session.
-
-
-Before you run a tcl session you must make sure that your account is configured for using tcl, see the <a href="#occt_wok_8_3">Configuring Your Account for Tcl and WOK</a> section. 
-
-To start a tcl session use the command: 
-~~~~~
-% tclsh 
-~~~~~
-Within this session, all WOK commands are available as well as standard tcl commands. You can also use tcl language extensions, if these are installed. 
-To exit from a tcl session use the command: 
-~~~~~ 
-> exit
-~~~~~ 
-Online help is provided with tcl. To access this, use the following command: 
-~~~~~
-% tclhelp  
-~~~~~
-Online help is also available for all WOK commands. To display help on a particular WOK command, give the command name followed by the -h flag, as in the following example: 
-~~~~~
-> wokcd -h
-~~~~~
-
-@subsection occt_wok_3_2  Steps
-Implementation of an application is based on the following steps: 
-1. Enter the software factory using the command wokcd MyFactory 
-2. Enter a workshop using the command wokcd MyWorkshop 
-3. Open a workbench using the command wokcd MyWorkbench 
-4. Search for the data types required among the existing OCCT libraries 
-5. Define one or more packages which will contain the classes 
-6. Define new data types as classes 
-7. Implement the methods of those classes in C++ 
-8. Implement any package methods in C++ 
-9. Unite the test packages 
-10. Define any nocdlpacks (if any) 
-11. Test the components 
-
-**Note:** Steps 1-3 can be performed with a single WOK command: 
-~~~~~
-> wokcd MyFactory:MyWorkshop:MyWorkbench
-~~~~~
-@subsection occt_wok_3_3  Getting Started
-@subsubsection occt_wok_3_3_1  Entity Names
-Before you start, the following restrictions on WOK entity names must be noted: 
-  *  Entity names may only contain alphanumeric characters and dashes. 
-  *  Entity names must be unique within a hierarchy. For example, you must not have two workbenches called MyBench in the same Workshop. Likewise, you may not have a workshop called CSF in a factory of the same name. 
-  *  Do not use upper and lower case characters to distinguish between two entity names, for example ENT1 and eNt1. This restriction is for reasons of portability. 
-  *  Parcel names must be unique. 
-  
-@subsubsection occt_wok_3_3_2  Entering the Factory
-When you start work you go to the factory using the following command: 
-~~~~~
-> wokcd <MyFactory>
-~~~~~ 
-@subsubsection occt_wok_3_3_3  Creating a New Workshop
-If you don’t want to work in a workshop already present in the factory, you can create a new one. To do this, use the following command: 
-~~~~~
-> screate –d <MyWorkshop> 
-~~~~~
-This creates the new workshop **MyWorkshop** in the current factory. To create the same workshop in a different factory use the syntax below: 
-~~~~~
-> screate –d <MyFactory:MyWorkshop>
-~~~~~
-
-When you create a new workshop, it is empty. 
-
-@subsubsection occt_wok_3_3_4  Selecting Parcels
-When you create a workshop, you select existing OCCT resources, for example, parcels, to use in it. To do this, you create the workshop and add the parcels using the following syntax: 
-~~~~~
-> screate –d <MyWorkshop> -DparcelConfig=Parcel1,Parcel2…
-~~~~~
-To display available OCCT resources, in other words, to see what parcels are available, you use the following command: 
-~~~~~
-Winfo –p <WarehouseName>
-~~~~~
-**Note:** parcel configuration rarely needs to change. If it does, only the workshop administrator should make them. 
-@subsubsection occt_wok_3_3_5  Opening a Workshop
-To open a workshop, you use the following command: 
-~~~~~
-> wokcd <MyWorkshop>
-~~~~~
-@subsubsection occt_wok_3_3_6  Creating a New Workbench
-When you create a new workshop, it is empty. In other words, it does not contain any workbenches. 
-To create the root workbench of a new workshop, you use the following command: 
-~~~~~
-> wcreate -d <MyWorkbench>
-~~~~~
-This creates a tree of workbench subdirectories. 
-If workbenches already exist in your workshop, but you do not want to work in any of these, create a new workbench as a child of an existing one. You do this using the following syntax: 
-~~~~~
-> wcreate –d <MyWorkbench> -f <ParentWorkbench>
-~~~~~
-@subsubsection occt_wok_3_3_7  Opening a Workbench
-To open a workbench, you use the command below: 
-~~~~~
-> wokcd <MyWorkbench>
-~~~~~
-This automatically takes you to the root directory of the workbench 
-
-@subsubsection occt_wok_3_3_8  Using Existing Resources
-Before creating new data types, you should look for existing components that you can reuse. In particular, you should look through the existing resources of your Open CASCADE Technology platform to see if any of the required components already exist, or if any existing generic components can be suitably implemented. This search can be conducted using the online documentation. You should note the packages and classes, which you can reuse. 
-
-@subsection occt_wok_3_4  Creating Software Components
-
-@subsubsection occt_wok_3_4_1  Creating a Package
-
-To develop new software components, you usually need to create one or more packages. You do this, by using the following command: 
-~~~~~
-> ucreate –p <MyPackage> 
-~~~~~
-Because the key -p defines the default value for the *ucreate* command, you do not need to specify it. The following syntax, for example, will also create a package: 
-~~~~~
- > ucreate <MyPackage> 
-~~~~~
-#### Enter a Package or other Development Unit Structure
-
-Enter the package or any other development unit structure using the *wokcd* command as in the syntax below: 
-~~~~~
-> wokcd MyPackage 
-~~~~~
-The current directory is now: 
-~~~~~
-MyWorkbenchRoot/src/MyPackage 
-~~~~~
-
-#### Writing the Package and Class Specifications in CDL 
-
-Write the descriptions of the software components in CDL using an editor of your choice. Write each class in its own .cdl file and write one .cdl file (MyPackage.cdl) to specify the package that contains those classes. 
-
-#### CDL Compilation of the Package
-
-Compile and check the package and its classes using: 
-~~~~~
- > umake –e xcpp 
-~~~~~
-This command also extracts the C++ header files (.hxx) and stores them in the derived files directory. 
-
-#### Implementing Methods in C++ 
-
-A package will contain methods, which may be: 
-  *  Instance methods 
-  *  Class methods 
-  *  Package methods. 
-Extract **prototypes** for the C++ methods using the following command: 
-~~~~~ 
- > umake -o xcpp.fill -o xcpp.template 
-~~~~~
-
-You should not confuse this syntax with the template feature of C++ used to implement the genericity. 
-The *umake -o xcpp.template* command creates a skeleton C++ file for: 
-  *  Each class 
-  *  All the package methods. 
-The packages methods will be created in a file called *package.cxx.template*. This command is not included in the umbrella command *MyPackage*. 
-You will need to use an editor to implement these methods in C++. 
-
-
-#### Compiling the Package
-
-To compile the package, use the command: 
-~~~~~
-  > umake -o obj <MyPackage>
-~~~~~  
-If you do not specify a package, the current development unit is compiled. 
-
-#### Sample Construction of a Package
-
-In the following example a workbench named **MyWb** is created as a child of an existing workbench **Topo**. MyWb is used for working on the package **MyPack**. Commands preceded by an asterisk below are used only once per session: 
-1. Create the MyWb workbench as a child of Topo. 
-~~~~~
-  > wcreate MyWb -f Topo -d
-~~~~~
-2. Create MyPack in MyWb. 
-~~~~~
-  > ucreate MyPack     
-~~~~~
-3. Move to the source directory of MyPack. 
-~~~~~
-  > wokcd MyPack 
-~~~~~
-4. Edit the source files (MyPack.cdl etc.). You do this outside tcl, using the editor of your choice. 
-5. Start the extraction of MyPack. 
-~~~~~
-   >  umake -e xcpp 
-~~~~~
-6. Generate the .cxx templates for MyPack: MyPack.cxx.template 
-~~~~~
-   > umake -o xcpp.fill -o xcpp.template -t 
-~~~~~
-7. Edit the source files (MyPack.cxx etc). You do this outside tcl, using the editor of your choice. 
-
-**Note** that *umake* command used without arguments will carry out all the above *umake* steps. You can also use it with specific arguments as above to go through the development process step by step. 
-
-#### Package Files
-
-* Primary Files for a Package 
-  + \<Package\>.cdl       Primary package file.
-  + \<Package\>_\<Class\>.cdl   Primary class file.
-* C++ Files for a Package
-  + \<Package\>.cxx       Primary package source file.
-  + \<Package\>_[1..9[0..9]*].cxx   Secondary package source files.
-  + \<Package\>.lxx       Inline package methods source file.
-  + \<Package\>.pxx       Private instructions source file.
-* C++ Files for a Class
-  + \<Package\>_\<Class\>.cxx   Primary class source file.
-  + \<Package\>_\<Class\>_[1..9[0..9]*].cxx
-* Secondary class source files.
-  + \<Package\>_\<Class\>.gxx   Generic class methods source file. This is an alternative to the .cxx file(s), you do not have both.
-  + \<Package\>_\<Class\>.lxx   Inline methods source file.
-  + \<Package\>_\<Class\>.pxx   Private instructions source file.
-* Derived C++ Files for a Package
-  + \<Package\>.hxx       User header file.
-  + \<Package\>.ixx       User header file included in \<Package\>.cxx.
-  + \<Package\>.jxx       User header file included in \<Package\>_[1-9].cxx.
-* Derived C++ files for a class
-  + \<Package\>_\<Class\>.hxx   User header file.
-  + \<Package\>_\<Class\>.ixx   User header file included in \<Package\>_\<Class\>.cxx.
-  + \<Package\>_\<Class\>.jxx   User header file in \<Package\>_\<Class\>_[1..9[0..9]*].cxx.
-  + Handle_\<Package\>_\<Class\>.hxx Persistent or Transient class header file.
-  + \<Package\>_\<Class\>_0.cxx   For instantiated classes.
-
-Umake Steps for a Package 
--------------------------
-The umake steps for development units of package type are explained below. 
-* *src*       Processes the file *MyPackage.cdl* to generate a list of all the CDL files in the development unit. Processes FILES to list source files. 
-* *xcpp.fill*   Compiles the internal data structure to prepare for subsequent extractions. 
-* *xcpp.src*     Lists the source files (.cxx, .gxx, .lxx) deduced from the CDL files. 
-* *xcpp.header*   Extracts header files for the classes in the development unit. 
-* *xcpp.template* Extracts a template for implementation of methods. (Hidden step.)
-* *obj.inc*      Based on the list of source files generated by the src and xcpp.src steps, this step publishes the include files for the development unit so that other units can use them. 
-* *obj.cgen*     Processes the source files to generate code. 
-* *obj.comp*    Compiles each file that can be compiled. 
-* *obj.idep*      Generates dependency information for the unit. This comprises: 
-  + Includes performed by unit compilation (Unit.MakeState) 
-  + Implementation dependencies in terms of the unit suppliers (Unit.ImplDep) 
-* *obj.lib*     Generates the shared library for the development unit. 
-
-@subsubsection occt_wok_3_4_2  Creating a Nocdlpack
-
-If your executable requires the use of a nocdlpack, create a development unit of nocdlpack type and move to its structure using the commands below: 
-~~~~~
-  > ucreate -n <MyNoCDLPack>
-  > wokcd <MyNoCDLPack> 
-~~~~~
-Use an editor to write *FILES*, which is a nomenclature file for a nocdlpack. This file must list all the C, C++, Fortran, lex, and yacc sourcs files (one per line). 
-Build the nocdlpack using the following command: 
-~~~~~
-  > umake [<MyNoCDLPack>]
-~~~~~
-**Note** that a nocdlpack unit is not intended to perform tests. Use an executable unit instead.
-
-
-#### Sample Construction of a Nocdlpack
-
-In the following example a nocdlpack *MyNocdlpack*, is created. Commands preceded by an asterisk below are used only once per session: 
-1. \*Create MyNocdlpack in MyWb. 
-~~~~~
-> ucreate -n <MyNoCDLPack>
-~~~~~
-2. Move to the source directory of MyNocdlpack. 
-~~~~~
-> wokcd <MyNoCDLPack>
-~~~~~
-3. Write the FILES list. You do this outside tcl, using the editor of your choice. 
-4. Write the source code. 
-5. Build MyNocdlpack. 
-~~~~~
-> umake [<MyNoCDLPack>]
-~~~~~ 
-
-#### Umake Steps for a Nocdlpack 
-
-The *umake* steps for development units of *nocdlpack* type are explained below. 
-* *src*      Processes FILES to list source files. 
-* *obj.cgen*   Processes the source files to generate code. 
-* *obj.inc*   Based on the list of source files, this step publishes the header files for the unit so that other units can use them. 
-* *obj.comp*   Compiles each file that can be compiled. 
-* *obj.idep*   Generates dependency information for the unit. This comprises: 
-  + Includes performed by unit compilation. (Unit.MakeState) 
-  + Implementation dependencies in terms of the unit suppliers. (Unit.ImplDep) 
-* *obj.lib*   Generates the shared library for the unit. 
-
-@subsubsection occt_wok_3_4_3  Creating a Schema
-
-If the application, which you intend to build, stores data in a file, you need to define a schema for the persistent data types that are known. 
-
-You create a schema and go to its root directory using the commands: 
-~~~~~
-> ucreate -n <MySchema>
-> wokcd <MySchema>
-~~~~~ 
-Using the editor of your choice, write a .cdl file to define the schema. This schema file lists all the packages that contain persistent data types used in the implementation of your application. It has the following format: 
-~~~~~
-  schema MySchema
-  is
-class <MyClass> from <Package>;
-  end;
-~~~~~
-  
-#### Building a Schema 
-
-Compile and check the coherence of the CDL specification for the schema: 
-~~~~~
-> umake -e xcpp.fill
-~~~~~
-Extract the C++ description: 
-~~~~~
-> umake -o xcpp
-~~~~~
-Compile the C++ description of the schema: 
-~~~~~
-> umake -o obj
-~~~~~
-Alternatively, the above three steps can all be carried out by one command: 
-~~~~~
-> umake
-~~~~~
-#### Sample Construction of a Schema 
-
-In the following example the schema *MySchema* is created. It contains all the schemas of the persistent classes of your own packages and the packages they depend on. Commands preceded by an asterisk below are used only once per session: 
-1. Create MySchema in MyWb. 
-~~~~~
- > ucreate -s MySchema
-~~~~~
-2. Move to the source directory of MySchema. 
-~~~~~
-> wokcd MySchema
-~~~~~
-3. Edit the source file MySchema.cdl. You do this outside tcl, using the editor of your choice. 
-4. Derive implementation files. 
-~~~~~
-  > umake -e xcpp.sch
-~~~~~
-5. Derive application schema files. 
-~~~~~
-  > umake -o xcpp.ossg
-~~~~~
-6. Compile the schema. 
-~~~~~
-  > umake -o obj
-~~~~~
-
-#### Schema Files
-
-* Primary Files for a Schema
-  + *\<Schema\>.cdl* Primary schema file.
-* Derived C++ Files for a Schema
-  + *\<Schema\>.hxx* User header files.
-  + *\<Schema\>.cxx* Schema implementation files.
-  + *\<Sch_MyPack_MyClass\>.cxx* Schema implementation files.
-
-#### Umake Steps for a Schema 
-
-The umake steps for development units of schema type are explained below. 
-* *src*        Processes MySchema.cdl to generate a list of CDL files for the development unit. Processes the FILES file to list source files. 
-* *xcpp.fill*  Compiles the internal data structure to prepare for subsequent extractions. 
-* *xcpp.sch*   Extracts the schema implementation code. 
-* *obj.comp*   Compiles the extracted files that can be compiled. 
-* *obj.lib*    Generates the shared library for the unit. 
-* *obj.idep*   Generates dependency information for the schema. 
-
-@subsection occt_wok_3_5  Building an Executable
-
-@subsubsection occt_wok_3_5_1  Creating an Executable
-
-To make an executable from one or more of the packages, which you have created, write a .cdl file to specify the packages to use. 
-
-#### Writing an Executable
-
-Refer to the **CDL User’s Guide** for full details. A simple example is given below. 
-
-~~~~~
-  executable <MyExec> // the executable unit
-is
-  executable myexec // the binary file
-uses
-Tcl_Lib as external
-is
-  myexec; // the C++ file
-end;    // several binaries can be specified in one .cdl file.
-executable myex2
-is
-  myex2;
-end;
-  end;
-~~~~~  
-  
-Write the C++ file(s). For the example above you write two files: *myexec.cxx* and *myex2.cxx*.
-#### Building the Executable 
-
-To build the executable, use the command *umake*
-
-#### Construction of an Executable 
-
-In the following example an executable, *MyExec*, is created in the workbench *MyWb*. Commands preceded by an asterisk below are used only once per session: 
-1. \*Create MyExec in MyWb. 
-~~~~~
-  > ucreate -x MyExec
-~~~~~
-2. Move to the source directory of *MyExec*. 
-~~~~~
-  > wokcd MyExec
-~~~~~  
-3. Edit the cdl source file *MyExec.cdl*. You do this outside tcl, using the editor of your choice. 
-4. Edit the C++ files *AnExe.cxx*, etc. You do this outside tcl, using the editor of your choice. 
-5. Build MyExec. 
-~~~~~
-  > umake
-~~~~~  
-6. Run the executable file. 
-~~~~~
-  > wokcd -PLib
-    > MyExec
-~~~~~
-
-#### Executable Files 
-
-| \<Exec\>.cdl        |  Primary executable file |
-| \<AnExe\>.cxx       |  Source C++ file         |
-| \<AnExe\>_[1-9].cxx |  Other source C++ files  |
-
-#### Umake Steps for an Executable
-
-The umake steps for development units of executable type are explained below. 
-* *src* Processes MyExe.cdl to generate a list of CDL files for the development unit. Processes FILES to list source files. 
-* *src.list* Based on MyExe.cdl, works out the list of parts and the source files involved for each part. 
-* *exec.comp* Compiles the files that can be compiled for each part of the executable. 
-* *exec.idep* Generates dependency information for each part of the executable. 
-* *exec.libs* Computes full implementation dependency to prepare for linking for each part of the executable. 
-* *exec.tks* Performs toolkit substitution according to TOOLKITS for each part of the executable. 
-* *exec.link* Links each part of the executable. 
-
-@subsection occt_wok_3_6  Test Environments
-
-@subsubsection occt_wok_3_6_1  Testing an Executable
-
-To test an executable, you create an executable development unit and move to its structure.
-
-When you write the .cdl file for your test executable, specify the packages to test, for example: 
-~~~~~
-executable MyTest // the executable unit 
-  is 
-executable mytest1 // the binary file 
-is 
-  mytest1; //the C++ file 
-end; // several binaries can be specified in one .cdl file. 
-executable mytest2 
-is 
-  mytest2; 
-end; 
-  end; 
-~~~~~
-Write the C++ test file(s), in the example, *mytest1.cxx* and *mytest2.cxx*. 
-#### Building the Executable 
-
-To build the executable use the command: 
-~~~~~
-> umake
-~~~~~
-
-#### Setting up a Test Environment
-
-To set up a test environment, move to the <i>/drv</i> subdirectory that corresponds to the current profile (e.g. <i>/MyExec/drv/DFLT/sun</i>) and run the executable test file.  
-~~~~~
-> wokcd -PLib
-> wokenv -s
-> myApp
-~~~~~
-The command *wokenv* is used with -s option to configure the test environment.  
-The command *wokenv –s* uses the current workbench to decide what actions are needed to configure the tcl shell for use as your test environment.  
-WOK sets the following environment variables: 
-
-* <i>$STATION</i>  - The current station. 
-* <i>$TARGET_DBMS</i> - The current database platform. 
-* <i>$PATH</i> - The current path, plus the bin directories of the parcels. 
-* <i>$LD_LIBRARY_PATH</i> The current path, plus the lib directories of the parcels. 
-WOK then sets a variable for each parcel listed in the parcel configuration of the current workshop. This variable is the original name of the delivery unit in the uppercase, with the suffix *HOME*.  
-* <i>$ORIGDELIVUNITHOME</i> is set as the root directory of the parcel. 
-WOK then sources the following files: 
-  *  MyFactory.tcl, found in the admin directory of the factory. 
-  *  MyWorkshop.tcl found in the admin directory of the workshop. 
-Then for each Workbench, WOK sources according to the hierarchy of the workbenches: 
-  *  Workbench.tcl, found in the /Adm directory of the workbench.  
-  
-After the environment is set up, you are at a C shell prompt and can run the executable. 
-
-**Note** Environment variables are only set when the command is used with the option <i>-s</i>. Thus, if you change a workbench or a factory within WOK and then return to the test environment you must use *wokenv -s* to ensure that the set environment variables configuration is correct for the current WOK state.  
-The configuration actions that WOK performs can be written to a file and saved as a script. You can then edit this script to suit it to your own needs, and generate a personalized test environment. 
-
-To create the script file use the following command: 
-~~~~~
- > wokenv -f <ScriptFile> -t csh
-~~~~~ 
-This command generates a file, ScriptFile, which configures a C shell to mirror the current WOK environment. An example script file is given below. 
-~~~~~
-setenv STATION *sil* 
-setenv TARGET_DBMS *DFLT* 
-setenv KERNELHOME */adv_22/WOK/BAG/KERNEL-K1-2-WOK* 
-setenv LD_LIBRARY_PATH */adv_22/WOK/BAG/wok-K1-2/lib/sil:/adv_22/WOK/BAG/KERNEL-K1-2-WOK/sil/lib/* 
-setenv PATH */usr/tcltk/bin:/usr/bin:/bin:/usr/bin/X11:/lib:.:/SGI_SYSTEM/util_MDTV/factory_proc:/adv_22/WOK/BAG/KERNEL-K1-2-WOK/sil/bin/* 
-source /adv_22/WOK/BAG/KERNEL-K1-2-WOK/adm/Kernel.csh 
-~~~~~
-
-@subsection occt_wok_3_7  Building a Toolkit
-@subsubsection occt_wok_3_7_1  Creating a Toolkit
-
-You create and enter a toolkit development unit using the following commands: 
-~~~~~
-  > ucreate -t <TKMyToolkit>
-  > wokcd <TKMyToolkit>
-~~~~~
-
-#### Write the Nomenclature File for the Toolkit 
-
-Using an editor, write a nomenclature file called PACKAGES which lists all the packages, one per line, that make up the toolkit. Add PACKAGES to FILES. 
-Build the shareable library for this toolkit as follows: 
-~~~~~
-\> umake [<TKMyToolkit>]
-~~~~~
-**Note:** when one of the packages in the toolkit is modified, recompile the toolkit. A package should belong to one toolkit only.
-
-#### Sample Construction of a Toolkit 
-
-In the following example, the toolkit **TKMyToolkit** is created. Commands preceded by an asterisk are used only once per session: 
-1. \*Create MyToolkit in MyWb. 
-~~~~~
-\> ucreate -t TKMyToolkit
-~~~~~
-2. Move to the source directory of MyToolkit. 
-~~~~~
-\> wokcd TKMyToolkit
-~~~~~
-3. Edit the nomenclature files, PACKAGES and FILES. You do this outside tcl, using the editor of your choice. 
-4. \*Create the library for MyToolkit 
-~~~~~
-\> umake TKMyToolkit
-~~~~~
-
-#### Umake Steps for a Toolkit 
-
-The umake steps for development units of toolkit type are explained below. 
-* *src*  Processes FILES to list source files. 
-* *lib.list* Works out the objects and archive library to add to the toolkit shared library. 
-* *lib.limit* Manages the build process strategy within the limitations of a particular platform. 
-* *lib.arch* Builds archives according to the building strategy. 
-* *lib.uncomp* Decompresses third party archives. 
-* *lib.arx* Extracts object files from archives. 
-* *lib.build* Generates the shared library for the toolkit.  
-
-Building strategy depends on the platform. The following step sequences apply: 
-  *  On Sun (Solaris): 
-~~~~~
-src 
-lib.list 
-lib.arx 
-lib.build 
-~~~~~  
-  *  On sil (IRIX): 
-~~~~~
-src 
-lib.list 
-lib.uncomp 
-lib.build 
-~~~~~
-
-#### The TOOLKITS File
-When executables are compiled, a TOOLKITS file is used to determine which toolkits are included. This file is located in the src directory of the entity being compiled. The process is as follows: 
-* If no TOOLKITS file has been found, all toolkits are candidates for substitution. To find out which toolkits are candidates, use the command  *w_info -k*. 
-* If an empty TOOLKITS file has been found, there is no toolkit candidate for substitution. 
-* If a non-empty TOOLKITS file has been found, only the toolkits listed in this file are candidates for substitution. 
-
-#### Toolkit Substitution
-
-Toolkit substitution is performed as follows: 
-1. MyEngine uses A, B and C; 
-2. The toolkit TK provides  A and D; D uses E; 
-3. Compilation of *MyEngine* includes TK, B C and E.
-Here, for simplicity, assume that additional toolkits are not substituted for B, C and E. 
-
-@subsection occt_wok_3_8  Building a Delivery Unit
-@subsubsection occt_wok_3_8_1  Creating a Delivery Unit
-~~~~~
-\> ucreate -d <MyDeliveryUnit>
-~~~~~
-
-#### Writing the COMPONENTS File
-
-Create a file named COMPONENTS in the src subdirectory of the delivery development unit. List in this file the prerequisites of the delivery and the components that are part of the delivery. Use the syntax shown below. 
-Note that keywords and default options are shown in bold. 
-
-| **Name** | ParcelName |
-| Put path | |
-| Put include ||
-|Put lib ||
-| **Requires** | DeliveryName\* |
-| **Package** | MyPack **[CDL][LIBRARY][INCLUDES][SOURCES]** |
-| **Nocdlpack** | MyNcdl **[LIBRARY][INCLUDES][SOURCES]** |
-| **Executable** | MyExec **[CDL][DYNAMIC][SOURCES]** |
-| **Interface** | MyIntf **[CDL][STUB_SERVER][SOURCES]** |
-| **Client** | MyClient **[CDL]**[STUB_CLIENT][SOURCES] |
-| **Engine** | MyEng **[CDL][DYNAMIC][SOURCES]** | 
-| **Schema** | MyShma **[CDL][LIBRARY][SOURCES][DOC]** |
-| **Toolkit** |MyTk **[LIBRARY][SOURCES]** |
-| **Get** | DevelopmentUnitName::Type\:\:\:File |
-
-\* Without mention of the version 
-
-If no keywords are specified then all default arguments shown in bold are taken into account. To select arguments, list the ones required explicitly. The arguments are explained below: 
-* **Name** The full name of the current delivery, including a version number. This is the name of the parcel. 
-* **Put path** Requires that the delivery be inserted in the user path (bin directory). 
-* **\[CDL\]** Copy the cdl files to the delivery. 
-* **\[LIBRARY\]** Generate the static library. Copy the shareable library to the delivery. Copy the list of objects of the library. 
-* **\[INCLUDES\]** Generate includes.origin. Copy the includes to the delivery. Copy the ddl to the delivery. 
-* **\[DYNAMIC\]** Select to copy the static or dynamic executable file. 
-* **\[SOURCES\]** Copy the source files. 
-
-#### Build the Delivery
-
-To build the delivery unit, use the command: 
-~~~~~
-\> umake <MyDeliveryUnit>
-~~~~~
-The result of building a delivery unit is a **parcel**, which can be installed in a warehouse and used by other workbenches. 
-
-#### Sample Delivery of a Parcel
-
-In the following example a delivery is created, compiled and made into a parcel. Commands preceded by an asterisk below are used only once per session: 
-1. Move to the root workbench under which the parcel is to be made.
-~~~~~
-> wokcd MyRootWb
-~~~~~
-2. \*Create MyDelivery in MyRootwb.
-~~~~~
-> ucreate -d MyDelivery
-~~~~~
-3. Move to the source directory of MyDelivery.
-~~~~~
-> wokcd MyDelivery
-~~~~~
-4. Use an editor to list all the prerequisites and components of the delivery in the COMPONENTS files using the appropriate syntax.
-5. Build MyDelivery.
-~~~~~
-> umake MyDelivery 
-~~~~~
-The output of the umake process is a parcel
-#### Umake Steps for a Delivery Unit
-
-The umake steps for development units of type delivery are explained below. 
-* *src*         Processes FILES to list source files. 
-* *base*           Creates directories, defines the list of units, copies the parcels and the release notes. 
-* *get.list*           Lists files to get (using Get, Resource). 
-* *get.copy*       Copy the files listed by get.list. 
-* *cdl.list*         Lists CDL files to copy. 
-* *cdl.copy*        Copies the files listed by cdl.list. 
-* *source.list*     Lists units from which sources are to be copied. 
-* *source.build*       Creates a file for sources (in the format: unit.type.Z). 
-* *inc.list*           Lists includes to copy. 
-* *inc.copy*         Copies files listed by inc.list. 
-* *lib.shared*       Works out the inputs for building or copying shareable libraries. 
-* *lib.shared.build*  Copies or builds (depending on the platform) the shareable libraries. 
-* *lib.server.list*     Lists interface files to copy. 
-* *exec.list*       Lists inputs for executable delivery. 
-* *exec.build*       Creates executable in the parcel. 
-* *files*          Works out the list of files delivered in the parcel. 
-
-@subsubsection occt_wok_3_8_2  Installing a Parcel
-You open the root workbench of the workshop where you want to install the parcel using the following command: 
-~~~~~
-\> wokcd <MyWorkshop> 
-~~~~~
-To install the parcel, use the following syntax: 
-~~~~~
-\> pinstall <MyParcel>
-~~~~~
-
-@subsection occt_wok_3_9  Working with Resource
-
-### Building a Resource 
-
-There is a single umake step for development units of resource type. 
-* *src*                 Processes FILES to list source files. 
-
-@subsection occt_wok_3_10  Java wrapping
-@subsubsection occt_wok_3_10_1  Creating an interface
-
-To create an interface development unit and move to its structure, use commands: 
-~~~~~
-\> ucreate -i <MyInterface>
-\> wokcd <MyInterface>
-~~~~~
-
-### Writing an Interface 
-
-Having created the interface, you select the classes and packages that you wish to make available for Java wrapping in the jni units. Use an editor of your choice to write a .cdl interface file that specifies these exported services. This file has the format: 
-
-~~~~~
-interface MyInterface 
-uses 
-  ListOfPackages; 
-is 
-  ListOfPackages; 
-  ListOfClasses; 
-  ListOfMethods; 
-end; 
-~~~~~
-
-### Building an Interface
-
-To make the services of the interface available for further wrapping, build the interface, using the command: 
-~~~~~
-> umake [<MyInterface>] -o src
-~~~~~
-
-### Sample Construction of an Interface
-
-In the following example a workbench, *MyWb*, is used for working on the interface *MyInterface*. Commands preceded by  \* (asterisk) are used only once during a session. 
-
-1. \*Create MyInterface in MyWb. 
-~~~~~
->ucreate -i MyInterface 
-~~~~~
-2. Move to the source directory of MyInterface. 
-~~~~~
->wokcd MyInterface 
-~~~~~
-3. Edit the source file MyInterface.cdl. You do this outside tcl, using an editor of your choice. 
-4. Build the interface. 
-~~~~~
-> umake -o src 
-~~~~~
-
-### Interface Files
-
-_<Interface>.cdl_ is the primary interface file. 
-
-### Umake Steps for an Interface
-
-The umake steps for development units of type interface are explained below. 
-
-* *src* - processes *MyInt.cdl* to list the CDL files for the development unit. Processes the FILES file to list source files. 
-
-**Note** Make sure you only use the *src* step of umake. Using umake without arguments will lead to an attempt of launching other steps relevant to the interface unit. However these steps will fail and anyway are not required for use in Java wrapping. 
-
-@subsubsection occt_wok_3_10_2  Creating a jni
-To create a development unit of type jni and move to its structure, use commands: 
-~~~~~
-> ucreate -j <MyJni>
-> wokcd <MyJni>
-~~~~~
-
-### Writing a Jni 
-
-Use an editor to write a .cdl file that specifies the interface or interfaces required by the jni. This file has the following format: 
-~~~~~
-client MyJni 
-is 
-{interface MyInterface;} 
-{interface YourInterface;} 
-end; 
-~~~~~
-
-### Building a Jni
-
-To wrap services exported by the interfaces to Java, build the jni, using the command: 
-~~~~~
- > umake [MyJni] 
-~~~~~
-
-### Sample Construction of a Jni
-
-In the following example a workbench, *MyWb*, is used for working on the jni, *MyJni*. Commands preceded by  \* (asterisk) are used only once during a session. 
-
-1. \*Create MyJni in MyWb. 
-~~~~~
-> ucreate -j MyJni  
-~~~~~
-2. Move to the source directory of *MyJni*. 
-~~~~~
-> wokcd MyJni  
-~~~~~
-3. Edit the source file *MyJni.cdl*. You do this outside tcl, using an editor of your choice. 
-4. Derive Java files (.java and .class files) and C++ files (.h and .cxx) used for wrapping. 
-~~~~~
- > umake -e xcpp 
-~~~~~
-5. Compile the sources. 
-~~~~~ 
-> umake -o obj 
-~~~~~
-6. Link the object files. 
-~~~~~
-> umake -o exec
-~~~~~
-
-Primary jni file is *Jni.cdl*
-
-Derived Java files for a Jni are:
-* \<Package\>_\<Class\>.java - Java source file of the class to be wrapped. 
-* \<Package\>_\<Class\>.class - Compiled java source file. 
-
-Derived C++ files for a Jni are:
-* \<Jni\>_\<Package\>_\<Class\>_java.h  - Include file for the C++ implementation of JNI. 
-* \<Jni\>_\<Package\>_\<Class\>_java.cxx  - C++ implementation of JNI.
-
-### Umake Steps for a Jni
-
-The umake steps for development units of type jni are explained below. 
-* *src*          Processes MyJni.cdl to list the CDL files for the development unit. Processes the FILES file to list source files. 
-* *xcpp.fill*     Compiles the internal data structure to prepare for subsequent extractions. 
-* *xcpp.client*   Extracts the services declared in included interface unit(s) into Java and creates .java and \*_java.cxx files. 
-* *xcpp.javac*   Compiles .java files into .class files. 
-* *xcpp.javah*   Creates .h header files. 
-* *obj.comp* Compiles generated C++ files. 
-* *obj.idep*     Generates dependency information for the unit. 
-* *exec.libs*   Computes full implementation dependency to prepare for linking. 
-* *exec.tks*     Performs toolkit substitution. 
-* *exec.link*     Generates the shared library for the development unit. 
-
-@subsection occt_wok_3_11  More Advanced Use
-@subsubsection occt_wok_3_11_1  Default User Profile
-There is a default user profile. If you wish to change this profile the command *wokprofile* is available. 
-
-An example profile is given below. 
-~~~~~
-  Info : Profile in : WOK:k1dev:ref 
-  Info : Extractor : DFLT 
-  Info : Compile Mode : Optimized 
-  Info : Station Type : sil 
-~~~~~
-@subsubsection occt_wok_3_11_2  Changing Parcel Configuration
-Parcel configuration rarely needs changes. However, if you do need to modify the list of resources, you can do so by editing the admin parameter file of the factory. This file is found in the admin directory of the factory and is named after the workshop. It has the suffix .edl. Its full name has the following format: 
-~~~~~
-<MyWorkshop>.edl.
-~~~~~
-
-Move to the admin directory of the factory: 
-~~~~~
-\> wokcd <MyFactory> -PAdm
-~~~~~
-
-Then use the editor of your choice to edit the admin parameter file, MyWorkshop.edl. 
-In this file, the parcel configuration is defined by an entry of the form: 
-~~~~~
-\@set %<MyWorkshop>_ParcelConfig = “Parcel1 Parcel2...Parceln”;
-~~~~~
-The resources are listed within quotation marks. They are separated by spaces. 
-Edit this list as required. Save the file and close it. 
-To validate and take into account your changes use the command: 
-~~~~~
-\> wokclose -a 
-~~~~~
-This command closes and reopens all the entities. Without the -a option, *wokclose* only applies to the current entity. 
-
-@section occt_wok_4_ Available Services
-@subsection occt_wok_4_1  Synopsis
-WOK provides sets of services, which can be grouped according to the entity they apply to: 
-  *  General Services 
-  *  Factories 
-  *  Warehouses 
-  *  Parcels 
-  *  Workshops 
-  *  Workbenches 
-  *  Development Units 
-  *  Source Management Services 
-  *  Session Services 
-@subsubsection occt_wok_4_1_1  Common Command Syntax
-
-#### Command Names 
-
-All WOK commands follow a common naming convention. This is based on a set of common command names and a group of prefixes, which denote entity type. The command name takes a prefix representing the entity to which it applies. 
-The following prefixes exist: 
-  *  f: for factories 
-  *  s: for workshops 
-  *  w: for workbenches 
-  *  u: for development units 
-  *  W: for warehouses 
-  *  p: for parcels 
-  *  wok: for commands that apply to any type of entity 
-These prefixes are followed by a command that determines the action to be executed. Examples of such commands are: 
-  *  create: create an entity 
-  *  rm: delete an entity 
-  *  info: request information 
-Consequently, the command ucreate creates a development unit. The command wrm removes a workbench. 
-
-#### Command Options
-
-All command options are expressed using a dash (-) followed by one or more key letters and, if applicable, an argument. For example: 
-~~~~~
-> umake -f -o <argument> MyUnit
-~~~~~
-The compact version of this syntax is also valid: 
-~~~~~
- umake -fo argument MyUnit 
-~~~~~
-This syntax conforms to the POSIX recommendations for UNIX commands. 
-For all commands, there is a –h option, which displays help on usage. 
-
-#### Presentation of Commands
-
-The general syntax of the commands is presented in this document as follows: 
-~~~~~
-CommandName [option(s) [<argument(s)>] [<Entity>]]
-~~~~~
-Consequently, there are four general cases for a command: 
-~~~~~
-CommandName <Entity>
-CommandName <option(s)> [<argument(s)>] <Entity>
-CommandName <option(s)> [<argument(s)>]
-CommandName
-~~~~~
-**Note** a few commands described in this chapter do not completely respect this syntax; for example, *create* and *rm*. 
-
-As a rule, where an _\<EntityPath\>_ is given as an argument it specifies which entity the command applies to. Where no _\<EntityPath\>_ is specified, the command applies to the nearest appropriate entity. The *create* and *rm* commands are notable exceptions: you **must** specify an entity path with these commands. 
-
-@subsection occt_wok_4_2  General Services
-General services are commands that apply to any entity manipulated by WOK. They are used for: 
-  *  Navigation 
-  *  Managing parameters 
-  *  Managing profiles. 
-
-@subsubsection occt_wok_4_2_1  wokcd
-~~~~~
-wokcd
-wokcd <EntityPath>
-wokcd -P <ParamSuffix> [<EntityPath>]
-~~~~~
-
-Navigates between different WOK entities and changes the current working directory. Without any arguments wokcd lists the current position (the WOK equivalent of ‘pwd’). With an argument, wokcd moves to the specified location. 
-Options: 
-* _\<EntityPath\>_   Moves to the home directory of the entity specified by \<EntityPath\>, i.e. moves to the location given by the parameter: %wokcd \<EntityPath\>_Home.
-* _-P \<ParamSuffix\> [\<EntityPath\>]_ Moves to the \<ParamSuffix\> directory of the entity specified by \<EntityPath\>. i.e. moves to the location given by the parameter: %\<EntityPath\>_\<ParamSuffix\>. If no entity path is specified, this command moves to the \<ParamSuffix\> directory of the current entity.
-
-Possible values for \<ParamSuffix\> are: Home, Adm and Src.
-Use the following commands to change directories within a development unit: 
-* **wsrc** To access the source files. 
-* **winc** To access the include files. 
-* **wobj** To access objects. 
-* **wlib** To access shareable libraries. 
-* **wbin** To access executables. 
-* **wadm** To access the workbench administration files. 
-
-#### Examples 
-
-*wokcd* - Lists the current position. 
-
-*wokcd MODEL:GTI:gti:gp* - Moves to the home directory of the gp package of the gti workbench in the GTI workshop in the MODEL factory. 
-
-*wokcd -P Adm* - Moves to the administration directory of the current entity. 
-
-
-@subsubsection occt_wok_4_2_2  wokclose
-~~~~~
-wokclose [-a] 
-~~~~~
-Closes and reopens entities, i.e. reloads them into memory thus taking any changes into account. 
-Option <i>-a</i> closes and reloads all entities. 
-
-#### Examples
-
-~~~~~
-wokclose 
-~~~~~
-Closes and reopens the current entity. 
-~~~~~
-wokclose -a 
-~~~~~
-Closes and reopens all the entities. 
-@subsubsection occt_wok_4_2_3  wokenv
-~~~~~
-wokenv -f <ScriptFile> -t csh
-~~~~~
-Creates the file \<ScriptFile\>. This file is a script, which configures a C shell to mirror the current WOK environment. See the <a href="#occt_wok_3_6">Test Environments</a> section for more details. 
-Options: 
-* -f \<ScriptFile\> - Specifies the name of the file to produce. 
-* -t csh - Produces a file for configuring a C shell. 
-* -s - Sets up environment variables for application launching. 
-Example
-------- 
-~~~~~
-> wokenv -f MyTestEnvScript -t csh
-~~~~~
-Generates the shell script *MyTestEnvScript* to configure a C shell so that it mirrors the current WOK environment. 
-@subsubsection occt_wok_4_2_4  wokinfo
-~~~~~
-wokinfo -<option> [<EntityPath>]
-wokinfo -<option> <argument> [<EntityPath>]
-~~~~~
-Displays information about _\<EntityPath\>_. The information displayed is common to all the entities. If no _\<EntityPath\>_ is specified, information about the current entity is returned. 
-This command can be used to find the path of a file. 
-Options: 
-* -t - Returns the type of entity (factory, warehouse, parcel, workbench, development unit). 
-* -T - Lists the types of files known in the entity. 
-* -f - Gets factory from path. 
-* -N - Gets the nesting path, i.e. where the current entity is nested. 
-* -n - Gets entity name. 
-* -P - Gets parcel from path. 
-* -s - Gets workshop from path. 
-* -u - Gets development unit from path. 
-* -W - Gets warehouse from path. 
-* -w - Gets workbench from path. 
-* -x - Tests if entity exists. 
-* -d \<type\> - Gets type definition. 
-* -a \<type\> - Gets type arguments. 
-* -p \<type\>:\<filename\> - Gets the path for a file, which is of the type type that depends on %File. In other words, the path for a file of this type depends on the file name, \<filename\>. 
-* -p \<type\> - Gets the path for a file, which is of the type \<type\> that is not %File dependent, for example EXTERNLIB. 
-
-#### Examples
-
-~~~~~
-wokinfo -p source:gp.cdl MODEL:GTI:gti:gp 
-~~~~~
-Returns the path of the source file gp.cdl in the MODEL:GTI:gti:gp. 
-~~~~~
-wokinfo -t MODEL:GTI:gti:gp 
-~~~~~
-Returns the development unit. 
-
-@subsubsection occt_wok_4_2_5  woklocate
-~~~~~
-woklocate -<option> <argument> [<WorkbenchPath>]
-woklocate -P [<WorkbenchPath>]
-~~~~~ 
-Using WorkbenchPath as the starting point, this command locates files associated with the development unit and specified by the argument argument. 
-Options are: 
-* -f \<Unit:Type:File\> - Locates a file and gives its ID. 
-* -p \<Unit:Type:File\> - Locates a file and gives its path. 
-* -u \<Unit\> - Locates a development unit. 
-* -P - Displays all available WOK public types. 
-
-#### Example
-
-~~~~~
-woklocate <MyFile> 
-~~~~~
-Displays the location of the file, MyFile. 
-
-@subsubsection occt_wok_4_2_6  wokparam
-~~~~~
-wokparam -<option> [<EntityPath>]
-wokparam -<option> <argument> [<EntityPath>]
-~~~~~
-Queries system parameters such as variables and templates. For more information about parameters refer to the appendix *Parameters and EDL Files* at the end of this User’s Guide. If an \<EntityPath\> is specified this indicates the entity to which the command applies. 
-Options: 
-* -L - Lists the directories used to search for the parameter files. 
-* -C - Displays the subclasses list. 
-* -a \<TemplateName\> - Gets arguments for the template TemplateName. 
-* -e \<ParamName\> - Evaluates the parameter ParamName. 
-* -F \<ClassName\> - Displays the files comprising the definition of the class *ClassName*. 
-* -l \<Class\> - Lists parameters concerning class (prefix) class. 
-* -S \<FileName\> - Finds the first file FileName in the list of directories cited afterwards. 
-* -t \<Name\> - Tests if the variable Name is set. 
-* -v \<ParamName\> - Displays the value of the parameter *ParamName*. 
-* -s \<Name\>=\<Value> Reserved for advanced use. Sets the variable *Name* to value *Value*. 
-* -u \<Name\> Reserved for advanced use. Unsets the variable Name. 
-
-#### Examples 
-
-~~~~~
-wokparam -L MODEL:GTI:gti 
-~~~~~
-Returns a list of directories used for parameters by the gti workbench. 
-~~~~~
-wokparam -S CSF.edl 
-~~~~~
-Locates the nearest CSF.edl file used by the current entity. 
-~~~~~
-wokparam MODEL:GTI:gti:gp -e %WOKUMake_Steps 
-~~~~~
-Displays the value of the _\%WOKUMake_Steps_ parameter in the *gp* package. The _\%WOKUMake_Steps_ parameter contains a description of the steps used by umake. 
-@subsubsection occt_wok_4_2_7  wokprofile
-~~~~~
-wokprofile
-wokprofile -<option> [<argument>]
-~~~~~
-Modifies session parameters. This command changes the mode of the current compilation and the profile of the current database. It also displays the current value of the session parameters. If no argument is specified, it displays the values of different parameters in the current session as well as the current position *wokprofile -v*. 
-Options: 
-* -b - Returns the current database profile (OBJS, DFLT). 
-* -d -  Switches to compilation with debug. 
-* -m - Returns the current compilation mode. 
-* -o - Switches to optimized compilation. 
-* -s - Returns the current station type 
-* -v - Switches to wokprofile verbose mode. In this mode all the parameters of the session are displayed. Running this command displays the current/changed profile. 
-
-#### Examples 
-
-~~~~~
-wokprofile 
-~~~~~
-Displays all the session parameters. 
-~~~~~
-wokprofile -b 
-~~~~~
-Displays the current database profile. 
-~~~~~
-wokprofile -v -o 
-~~~~~
-Switches to optimized compilation and displays the parameters of the current session after the change has been made. 
-~~~~~
-wokprofile -o -v 
-~~~~~
-Switches to optimized compilation and displays the parameters of the current session after the change has been made. Note that the order in which these options are specified does not affect the result. 
-
-@subsection occt_wok_4_3  Services Associated with Factories
-There is a dedicated list of commands for the management of factories. The commands to create and destroy factories are reserved for the exclusive use of the site administrator. 
-* *fcreate* Creates a factory. 
-* *finfo* Displays information about the factory. 
-* *frm* Deletes a factory if it is empty. 
-
-@subsubsection occt_wok_4_3_1  fcreate
-*Reserved for administrator’s use* 
-~~~~~
-fcreate -<option> [-D <Suffix>=<Value>]* <EntityPath>
-~~~~~
-Creates a factory. The name of the factory to create is specified by EntityPath. You can also specify the entity that will contain the entity to be created. 
-
-Once the creation is completed, a file containing the parameters of the creation of the factory is created in the administration directory of the container to which the factory belongs. 
-
-Parameters: 
-The following parameters are mandatory when a factory is created: 
-* **Adm** - Path name for administration directory 
-* **Home** - Path name for home directory 
-* **Stations** - List of supported stations 
-* **DBMSystems** - List of supported dbms 
-* **Warehouse** - Name of factory warehouse. 
-
-Options: 
-* -P - Propose defaults. Returns a list of default values for the parameters necessary for the creation of the factory. No entity is created if this option is used. 
-* -d Use default. Uses default values to create the factory. 
-* -D\<Suffix\>=\<Value\> - Defines parameter(s). Specifies the value to use for the given parameter(s) explicitly. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here. 
-
-#### Examples 
-
-~~~~~
-fcreate -P NewFactoryName 
-~~~~~
-Returns a list of default values for the parameters that are mandatory when creating a factory. 
-~~~~~
-fcreate MyFactory -d -DHome=/fred/myfactory 
-~~~~~
-Creates the factory MyFactory using default values for all mandatory parameters, except for Home, which is set to: /fred/myfactory 
-
-@subsubsection occt_wok_4_3_2  finfo
-~~~~~
-finfo -<option> [<EntityPath>]
-~~~~~
-Displays details about the factory. If an EntityPath is specified this determines the factory to apply to. If no entity path is given, the command applies to the nearest factory. 
-Options: 
-* -s - Displays a list of workshops in the factory. 
-* -W - Displays the name of the warehouse in the factory. 
-* -S - Displays the name of the source repository. 
-
-#### Examples
-
-~~~~~
-finfo -s 
-~~~~~
-Displays a list of workshops in the nearest factory. 
-~~~~~
-finfo MyFactory -W 
-~~~~~
-Displays the name of the warehouse in MyFactory. 
-
-@subsubsection occt_wok_4_3_3  frm
-*Reserved for administrator’s use* 
-~~~~~
-frm <EntityPath>
-~~~~~
-Deletes the factory specified by EntityPath if it is empty. 
-
-Note, that you must not be in the factory you intend to destroy. 
-
-#### Example
-
-~~~~~
-frm MyFactory 
-~~~~~
-Deletes the factory MyFactory provided that it is empty. 
-
-@subsection occt_wok_4_4  Services Associated with Warehouses
-A warehouse contains the parcels that are available in a factory. There is a dedicated list of commands for management of warehouses. 
-The commands you use to create and destroy the warehouses are reserved for the exclusive use of the site administrator. 
-* *Wcreate*   - creates a warehouse. 
-* *Winfo* - displays information about the warehouse 
-* *Wrm* - deletes a warehouse if it is empty. 
-* *Wdeclare* - declares a parcel in the warehouse. 
-
-@subsubsection occt_wok_4_4_1  Wcreate
-*Reserved for administrator’s use.* 
-~~~~~
-Wcreate [-<option>] -D <Suffix>=<Value>* <WarehouseName>
-Wcreate -<option> [-D  <Suffix>=<Value>]* <WarehouseName>
-~~~~~
-Creates a warehouse. The name of the warehouse to create is given by *\<WarehouseName\>*. You can also specify the factory that will contain the warehouse. 
-Once the creation is completed, a file containing the parameters of warehouse creation is in its turn created in the administration directory of the factory to which the warehouse belongs. 
-
-Parameters: 
-The following parameters are mandatory when a warehouse is created: 
-* **Adm** - Path name for administration directory. 
-* **Home** - Path name for home directory. 
-* **Stations** - List of supported stations. 
-* **DBMSystems** - List of supported dbms. 
-
-Options: 
-* -P - (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of a warehouse. No entity is created if this option is used. 
-* -d - (Use defaults.) Uses default values to create the warehouse. 
-* -D \<Suffix\>=\<Value\> (Define parameter.) Explicitly specifies the value to use for this parameter. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here. 
-
-#### Examples
-
-~~~~~
-Wcreate -P MyWarehouse 
-~~~~~
-Returns a list of default values for the parameters that are mandatory when creating a warehouse. 
-~~~~~
-Wcreate MyWarehouse -d 
-~~~~~
-Creates the warehouse *MyWarehouse* using default values for all mandatory parameters. 
-@subsubsection occt_wok_4_4_2  Winfo
-~~~~~
-Winfo -p [<EntityPath>]
-~~~~~
-Displays details about the warehouse and its contents. If an EntityPath is specified, this determines the warehouse to apply to. 
-Option -p displays the parcels in the warehouse. 
-
-#### Example
-
-~~~~~
-Winfo -p 
-~~~~~
-Displays a list of parcels in the current warehouse. 
-@subsubsection occt_wok_4_4_3  Wrm
-*Reserved for Administrator’s Use.* 
-~~~~~
-Wrm <EntityPath> 
-~~~~~
-Deletes the warehouse specified by EntityPath if it is empty. You should not be in the warehouse you intend to destroy. 
-#### Example
-
-~~~~~
-Wrm MyWarehouse 
-~~~~~
-Deletes the warehouse *MyWarehouse* provided that it is empty. 
-@subsubsection occt_wok_4_4_4  Wdeclare
-*Reserved for administrator’s use* 
-~~~~~
-Wdeclare -p<Parcel> [-d] [-D<ParamName>=<Value>]* <House>
-~~~~~
-Declares the *Parcel*. This command adds the parcel to the list of parcels available in the warehouse House. 
-Note that a factory has a default list of deliveries (which are represented by parcels) available to it. This list only needs to be modified when moving to a new version of the delivery. This is done using the *Wdeclare* command, and then by editing the .edl file of the appropriate workshop. 
-
-The following parameters are mandatory when declaring parcels: 
-* **Adm** - Path name for administration directory of a parcel. 
-* **Home**  - Path name for home directory of a parcel. 
-* **Stations** - List of available stations. 
-* **DBMSystems**  - List of available dbms. 
-* **Delivery** - Delivery name. 
-
-Options: 
-* -p \<Parcel\> Defines the name of the parcel to declare. This name must be given with the option. 
-* -d Creates a parcel using defaults. 
-* -P Proposes defaults. 
-
-#### Example
-
-~~~~~
-Wdeclare -pMyParcel -d MyWarehouse 
-~~~~~
-Adds the parcel MyParcel to the warehouse MyWarehouse. 
-
-@subsection occt_wok_4_5  Services Associated with Parcels
-A parcel is a receptacle for development units. You use it to group together the units, which comprise a delivery unit. There is a dedicated list of commands for management of parcels. Only the site administrator should perform installation of parcels in a warehouse. 
-* *pinfo* - displays information about the contents of the parcel 
-* *pinstall* - installs the parcel in a Warehouse. 
-
-@subsubsection occt_wok_4_5_1  pinfo
-
-pinfo -\<option\> [\<ParcelPath\>] - displays details about the contents of the parcel. If *ParcelPath* is specified this determines the parcel to apply to. If no parcel path is specified the command applies to the nearest parcel. 
-
-Options: 
-* -d - Displays the delivery contained in the parcel. 
-* -l - Displays the development units in the parcel. 
-* -a - Lists the development units in the parcel together with their types. 
-
-#### Examples 
-
-~~~~~
-pinfo -l MyParcel 
-~~~~~
-Displays a list of units in the parcel MyParcel. 
-
-@subsubsection occt_wok_4_5_2  pinstall
-*Reserved for administrator’s use* 
-~~~~~
-pinstall <ParcelName> 
-~~~~~
-Installs the parcel \<ParcelName\> in the current warehouse. The process of installing a parcel sets up various paths and variables to ensure that the application can locate necessary resources and so on. 
-The administrator must perform *pinstall* for each platform used. 
-
-#### Example
-
-~~~~~ 
-pinstall MyParcel 
-~~~~~
-Installs the parcel *MyParcel* in the current warehouse. 
-
-@subsection occt_wok_4_6  Services Associated with Workshops
-A workshop is a tree of workbenches using the same parcel configuration. There is a dedicated list of commands for management of workshops. The commands to create and destroy workshops are reserved for the exclusive use of the site administrator. 
-* *screate* - creates a workshop. 
-* *sinfo* - displays information about the workshop 
-* *srm* - deletes a workshop if it is empty. 
-
-@subsubsection occt_wok_4_6_1  screate
-*Reserved for administrator’s use* 
-~~~~~
-screate [-<option>] {-D<Suffix>=<Value>}* <WorkshopName>
-screate -<option> <WorkshopName>
-~~~~~
-Creates a workshop, \<WorkshopName\>. You can also specify the factory that contains this workshop. 
-Once the creation is completed, a file containing the parameters for the creation of the workshop is generated in the administration directory of the factory to which it belongs. 
-
-The following parameters are mandatory when creating a workshop: 
-* **Adm** - Path name for administration directory. 
-* **Home** - Path name for home directory. 
-* **Stations** - List of supported stations. 
-* **DBMSystems** - List of supported dbms. 
-* **ParcelConfig** - List of parcels used. 
-* **Workbenchlist** - Path name for the list of workbenches. 
-
-Options: 
-* -P (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of a workshop. No entity is created if this option is used. 
-* -d (Use defaults.) Uses default values to create the workshop. 
-* -D \<Suffix\>=\<Value> (Define parameter.) Specifies the value to use for this parameter explicitly. This option can be used in conjunction with the –d option to accept default values for all the mandatory parameters except the parameter(s) explicitly specified here. 
-
-
-#### Examples
-
-~~~~~
-screate -P <WorkshopName>
-~~~~~
-Returns a list of default values for the parameters that are mandatory for creating a workshop. 
-~~~~~
-screate MyFactory:MyWorkshop -d 
-~~~~~
-Creates the workshop *MyWorkshop* in the factory *MyFactory*, using default values for all mandatory parameters. 
-~~~~~
-screate -DParcelConfig=Parcel1,Parcel2 MyFactory:MyWorkshop -d 
-~~~~~
-Creates the workshop *MyWorkshop* in the factory *MyFactory*, using default values for all mandatory parameters except for *ParcelConfig*, which is set to *Parcel1 Parcel2*. 
-
-@subsubsection occt_wok_4_6_2  sinfo
-~~~~~
-sinfo -<option> [WorkshopName] 
-~~~~~
-Displays details about the workshop. If *WorkshopName* is specified this determines the workshop this command is applied to. If no workshop is specified the command applies to the nearest workshop. 
-Options: 
-* -w - Displays a list of workbenches in the workshop. 
-* -p - Displays the parcel configuration of the workshop. 
-
-#### Example 
-
-~~~~~
-sinfo -w 
-~~~~~
-Displays a list of workbenches in the nearest workshop. 
-
-@subsubsection occt_wok_4_6_3  srm
-*Reserved for administrator’s use* 
-~~~~~
-srm WorkshopName 
-~~~~~
-Deletes the workshop \<WorkshopName\> if it is empty. You must not be in the workshop you intend to destroy.
-
-#### Example
-
-~~~~~
-srm MyWorkshop 
-~~~~~
-Deletes the *MyWorkshop* provided that it is empty. 
-
-@subsection occt_wok_4_7  Services Associated with Workbenches
-A workbench is the place where a developer (or a team of developers) works on a particular product. There is a dedicated list of commands for management of workbenches. 
-
-* *wcreate* - creates a workbench. 
-* *w_info* - displays information about a workbench. 
-* *wrm* - deletes a workbench if it is empty. 
-* *wmove* - moves a workbench to a new location. 
-
-@subsubsection occt_wok_4_7_1 wcreate
-~~~~~
-wcreate -f <ParentWB> [-D <Suffix>=<Value>]* <WBName>
-wcreate -f <ParentWB> -P|d [-D <Suffix>=<Value>]* <WBName>
-wcreate -f <ParentWB> -P|d <WBName>
-~~~~~
-Creates the workbench \<WBName\> as a child of the workbench \<ParentWB\>. The result of this creation is a directory structure. 
-Compared to the creation of other entities, creating a workbench requires an additional piece of information: you must specify the parent of the workbench to create. 
-Once the creation is completed, a file containing the parameters of the creation of this workbench is created in the administration directory of the workshop that contains it. 
-Parameters: 
-The following parameters are mandatory when creating a workbench: 
-* **Adm**     Path name for administration directory. 
-* **Home**     Path name for home directory. 
-* **Stations**   List of supported stations. 
-* **DBMSystems**   List of supported dbms. 
-
-Options: 
-* -f - Specifies the parent workbench. 
-* -P - (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of the workbench. No entity is created if this option is used. 
-* -d - (Use defaults.) Uses default values to create the workbench. 
-* -D \<Suffix\>=\<Value\> - (Define parameter.) Specifies the value to use for this parameter explicitly. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here. 
-
-#### Example
-
-~~~~~
-wcreate -P WorkBenchName 
-~~~~~
-Returns a list of default values for the mandatory parameters to create a workbench. 
-~~~~~
-wcreate MyWorkbench -d 
-~~~~~
-Creates the workbench MyWorkbench using default values for all mandatory parameters. 
-**Note** The –f option of this command is not obligatory. The system administrator can create the root workbench of a workshop without specifying a parent workbench.
-@subsubsection occt_wok_4_7_2  w_info
-~~~~~
-w_info -option[Workbench] 
-w_info -option argument[Workbench] 
-~~~~~
-The *w_info* command is the exception to the common command syntax. The form w_info is used instead of winfo because the latter already exists as a tcl/tk command and cannot be reused as a name by WOK. If \<Workbench\> is specified, this determines the workbench to apply to. If no \<Workbench\> is specified, the nearest workbench is used. 
-
-Using the tcl winfo command by mistake generates an error message, but does not cause any damage. 
-
-Options: 
-* -l - Lists the development units in the workbench. 
-* -a - Lists the development units in the workbench along with their respective types. 
-* -f - Displays the parent workbench. 
-* -A - Lists all the ancestors of the workbench. 
-* -k - Lists visible toolkits. 
-* -S \<arg\> - Lists suppliers of the unit \<arg\> within the visibility of the workbench. 
-* -S <execname:partname> - Lists the suppliers of the component executable partname within an executable development unit execname. 
-* -I <arg1, arg2 ... argN> - Lists the development units, sorted by order of implementation dependency. 
-
-#### Example
-
-~~~~~
-w_info -S MyDevUnit 
-~~~~~
-
-Returns a list of suppliers of the development unit MyDevUnit within the visibility of the current workbench. 
-
-@subsubsection occt_wok_4_7_3  wrm
-~~~~~
-wrm Workbench 
-~~~~~
-Deletes the workbench, provided that it is empty and has no children. You must not be in a workbench you intend to destroy. 
-
-#### Example
-~~~~~
-wrm MyWorkbench 
-~~~~~
-Deletes *MyWorkbench*, provided that it is empty and has no children. 
-
-@subsubsection occt_wok_4_7_4  wmove
-*Reserved for advanced use* 
-wmove -f \<NewParentWorkbench\> \<Workbench\>
-Moves the \<Workbench\> (and its children), to a different parent *NewParentWorkbench* within the same workshop. 
-Option  -f \<argument\> specifies the new parent workbench. 
-
-#### Example
-
-~~~~~
-wmove -f MyOtherWorkbench MyWorkbench 
-~~~~~
-Moves the *MyWorkbench* under *MyOtherWorkbench*. 
-
-@subsubsection occt_wok_4_7_5  wprocess
-~~~~~
-wprocess <WorkbenchName> <options>
-~~~~~
-Allows automatic reconstruction of a workbench. 
-
-Options: 
-* -DGroups =Obj,Lib,Exec     - Selects groups Obj, Lib and Exec. 
-* -DUnits = MyUd1,MyUd2,...   - Selects the development units MyUd1, MyUd2 etc. 
-* -DXGroups =Src,Deliv       - Excludes groups Obj and Deliv. 
-* -DXUnits=MyUd1,MyUd2,...     - Excludes units MyUd1, MyUd2 etc. 
-* -B \<Profile\>           - Selects the extraction profile. 
-* -f               - Forces all selected steps. 
-* -d | -o              - Switches between debug and optimized modes. 
-* -P               - Prints out the selected steps. 
-* -S               - Silent mode (no print of the banner). 
-* -L               - Logs output to MyUD_<step code>. Log in step administration directory. Valid group names are: Src, Xcpp, Obj, Dep, Lib, Exec, Deliv. 
-
-#### Example
-
-~~~~~
-wprocess -DGroups=Src,Xcpp,Obj,Lib,Exec 
-~~~~~
-Compiles the whole workbench 
-
-@subsection occt_wok_4_8  Services Associated with Development Units
-The development unit is the basic building block of development work in the WOK environment. It is the base component of Open CASCADE Technology architecture. For a list of available types of development units refer to the <a href="#occt_wok_2_1">Development Units</a> section. There is a dedicated list of commands for management of development units. 
-
-* *ucreate* **Creates** a development unit. 
-* *uinfo* **Displays** information about the development unit. 
-* *urm* **Deletes** a development unit. 
-* *umake* **Builds** a development unit. 
-
-@subsubsection occt_wok_4_8_1  ucreate
-~~~~~
-ucreate [-<TypeCode>] <UnitName>
-ucreate -P 
-~~~~~
-Creates a development unit named \<UnitName\> of type \<TypeCode\>. 
-
-Once the creation is completed, a file containing the parameters of the creation of the development unit is generated in the administration directory of the workbench to which the development unit belongs. 
-
-TypeCodes: 
-* -p - Creates a development unit of type package. This is the default option. Where no option is specified, a development unit of type package is created. 
-* -n - Creates a development unit of type nocdlpack. 
-* -s - Creates a development unit of type schema. 
-* -t - Creates a development unit of type toolkit. 
-* -d - Creates a development unit of type delivery. 
-* -x - Creates a development unit of type executable. 
-* -f - Creates a development unit of type frontal. 
-* -r - Creates a development unit of type resource. 
-* -P - Displays ucreate creation possibilities in format: \<TypeCode\> \<TypeName\>.
-
-#### Examples
-
-~~~~~
-ucreate -p MyWorkbench:MyPackage 
-~~~~~
-Creates the development unit *MyPackage* in *MyWorkbench*. The unit is of package type. 
-
-@subsubsection occt_wok_4_8_2  uinfo
-
-~~~~~
-uinfo -t|c [<UnitPath>]
-uinfo -f|F|p [-<FilterOption> [<Type>]]* [<UnitPath>]
-~~~~~
-
-Displays details about the development unit. Where no \<UnitPath\> is specified, details of the current unit are displayed. Filter options are available for use in conjunction with the options -f, -F, -p to filter the file list. Combinations of filter options can be used.
-Note that the uinfo command is based on the results of construction using umake. As a consequence, the list of files displayed by uinfo is only valid if the construction has completed normally. Similarly, the list of files derived from the CDL is only valid if the CDLs of the unit have been translated successfully. 
-
-Options: 
-* -t - Displays the type of the development unit as a string. 
-* -c - Displays the typecode of the development unit, i.e. a single character, as used by *ucreate* to indicate package (p), schema (s) and so on. 
-* -f - Displays a list of file names associated with the unit. 
-* -F - Displays a list of file names associated with the unit, together with their respective types. Types of files include for example: *source*, *library*, *executable*, and *pubinclude*. To display a full list of file types, use the command *ucreate*. 
-* -p - Displays the full paths of the files associated with the unit. 
-Filter Options: 
-* -T - \<Type\> Displays files of type \<Type\> only. 
-* -i - Displays only *independent* files, i.e. files that are not specific to a DBMS, for example sources. 
-* -s - Displays only station dependent files. 
-* -b - Displays only DBMS dependent files. 
-* -B - Displays only files that are dependent on *both *DBMS and Station. 
-* -l - Displays only files that are local to the workbench. 
-* -m - Displays only missing files, i.e. files that are listed, but not found. 
-* -e - Displays only existing files, i.e. files that are listed and found. 
-
-#### Examples
-
-~~~~~
-uinfo -Fp 
-~~~~~
-Displays the types, paths and names of all files associated with the unit. 
-~~~~~
-uinfo -f -Tpubinclude MyWorkbench:MyUnit 
-~~~~~
-Lists the names of the header files associated with the unit MyUnit which is in MyWorkbench. 
-
-@subsubsection occt_wok_4_8_3  urm
-~~~~~
-urm <UnitPath> 
-~~~~~
-Deletes the development unit \<UnitPath\> with its directory structure and its files, even if the unit is referenced by another one. 
-
-#### Example
-~~~~~ 
-urm MyWorkBench:MyPack 
-~~~~~
-Deletes the development unit *MyPack* found in *MyWorkBench*. 
-
-@subsubsection occt_wok_4_8_4  umake
-~~~~~
-umake -S [<UnitPath>]
-umake [-f][<UnitPath>]
-umake [-f]-o<step> [-t<target>]* [-o<step> [-t<target>]*]*[<UnitPath>]
-umake [-f][-s <step>] [-e <step>][<UnitPath>]
-umake
-~~~~~
-Builds a development unit. The build process includes compilations, links, and various other actions, which make the development unit usable. The build process is specific for each type of development unit, refer to chapter 3 for details. 
-The following properties apply: 
-1. There are steps identified by a keyword. 
-2. The steps involved and their content depends on the type of development unit being treated. 
-3. You can ask for single step execution using the -o option. 
-4. Unless explicitly requested using the –f option, the operations are carried out in those steps where necessary. 
-5. Only the processed development unit is modified. 
-
-Used without any arguments the *umake* command carries out all of the steps appropriate for the development unit to be constructed. Using keywords and arguments you can perform the build process step by step. 
-
-Options: 
-* -S            - Displays the list of steps. 
-* -s \<step\>   - Starts the build process at the step specified. 
-* -e \<step\>   - Ends the build process at the step specified. 
-* -o \<step\>   - Only executes the step specified. 
-* -t \<target\> - Specifies the target to build. 
-* -f            - Forces the build process, skipping the verification of dependencies. 
-
-#### Example
-
-~~~~~
-umake gp 
-~~~~~
-Builds the gp package. 
-
-@subsubsection occt_wok_4_8_5 Specifying Targets (-t) for umake
-
-The umake command is also used to specify build targets and extract C++ method prototypes. src, xcpp and obj units can be targeted. The syntax is explained below. 
-For delivery units (for all options apart from *.list) the syntax is as follows: 
-~~~~~
--\*.\* -t MyDU 
-umake MyDeliv -olib.shared.build -tMyUD. 
-~~~~~
-
-#### src
-
-This target computes a source file list as in the example below: 
-~~~~~
-umake -o src MyUnit 
-~~~~~
-
-#### xcpp
-
-Extracts C++ header files. For -xcpp.\* (with the exception of \*.fill), the syntax is as follows: 
-~~~~~
-umake -o -xcpp.* -t MyPack_MyClass 
-~~~~~
-You extract the method prototypes using the following command: 
-~~~~~
-umake -o xcpp.template [-t<class>|-t<package>]
-~~~~~
-This syntax of  *umake* command is only used with packages. It extracts the C++ prototypes of the methods of the classes contained in the package. 
-The generated files are placed in the src directory of the current package. These files always have a .template suffix. With each extraction of a class, these files will contain all the methods of the class. 
-Prototypes are extracted for: 
-  *  Ordinary classes (non-instantiated) 
-  *  Generic classes (including nested generic classes) 
-  *  Package methods 
-Classes, which are instantiations of generic classes, are not extracted. Nor are other CDL types (exceptions, alias, etc.) which have no user implementation. 
-For each class, we extract the prototypes of: 
-  *  Instance methods 
-  *  Class methods 
-  *  Constructors 
-The extracted files are the following: 
-  *  for an ordinary class C 
-    +  C.cxx.template for the non-inline class methods. 
-    +  C.lxx.template for the inline class methods. 
-  *  for a generic class G 
-    *  G.gxx.template for the non-inline class methods. 
-    *  G.lxx.template for the inline class methods. 
-  *  for a package method P 
-    *  P.cxx.template for the non-inline package methods. 
-    *  P.lxx.template for the inline package methods. 
-    
-    
-#### obj
-
-Specifying the target, *obj* compiles the object files for one or more files. The syntax for -obj.* is as follows: 
-~~~~~
-umake -o -obj.* -t MyPack_MyClass.cxx 
-~~~~~
-In a package, the following command executes all construction steps up to and including obj, doing for each of them only what is strictly necessary: 
-~~~~~
-umake -s obj 
-~~~~~
-The following command will recompile all the primary sources of a package which are out of date: 
-~~~~~
-umake -o obj 
-~~~~~
-
-@subsubsection occt_wok_4_8_6  Customizing umake
-You can use three levels of umake customization for a development unit. 
-  *  Compiler and link options, EXTERNLIB 
-  *  Step definition 
-  *  Tcl umake step implementation 
-These different levels of complexity correspond to the needs of regular users and more advanced users. 
-
-#### Modification of Compiler and Link Options and EXTERNLIB
-
-Customization at this level involves setting parameters of existing umake steps using an .edl file. This file is taken into account each time umake is performed. It contains a series of assignments or appended variables used when creating the development unit. These commands can be preceded by instructions dedicated to the preprocessor in order to adjust its behavior within the actual context. 
-
-EXTERNLIB uses resources contained in Open CASCADE Technology prerequisites. To avoid referencing the path of these resources more than one time, the user may use the component EXTERNLIB to include these resources automatically via the link. The file contains the name of parameters, which are set independently. 
-
-The umake command does not generate actual dependencies. To avoid any cumbersome dependencies, for example, if you do not want the shareable library file for a package but the package enumeration only, use the INTERNLIB component listed in FILES, to get only the given dependencies. 
-
-In practice, the generated file, \<myUD\>.ImplDep, in the /drv/adm directory, is copied into INTERNLIB. INTERNLIB contains lines of enumerations, as below: 
-~~~~~
-Dependence 1 
-Dependence 2 
-... 
-~~~~~
-The example below illustrates how you can modify your WOK compiler options. Refer to *Using EDL to Define WOK Parameters* for an example of how to set link options as well as for more details about available parameters and .edl files. 
-~~~~~ 
--- File Name: Kernel_CMPLRS.edl 
--- Copyright: Matra Datavision 1996 
-#--------------------------------- 
-#// First, ensure that we only execute this file once 
-\@ifnotdefined ( %Kernel_CMPLRS_EDL ) then 
-  \@set %Kernel_CMPLRS_EDL = **; 
-#// Then set C++ compilation options, based on workstation type: 
-  \@if( %Station == *sil* ) then 
-\@set %ModeOpt =  * *; 
-  \@endif; 
-  \@if( %Station == *ao1* ) then 
-\@set %ModeOpt = *-g *; 
-  \@endif; 
-  \@if( %Station == *hp* ) then 
-\@string %CMPLRS_C_Options +=  * -Aa -D_HPUX_SOURCE +e*; 
-  \@endif; 
-\@endif; 
-~~~~~
-
-#### Step Definition
-
-The WOK umake command uses a dependency tree. This dependency tree is a graph that shows the umake steps, their inputs and their dependencies. You use it to perform the build, for example to ensure that only files, which have changed, and the files, which depend on these modified files, are recompiled. 
-
-This dependency tree is defined in an .edl file. The steps are listed in an order. Each is assigned a name and has its inputs specified. The output of one or more steps is the input to another step. 
-
-The following steps are standard for WOK umakes: src, src.list, exec.comp and exec.link. Any new step that you insert into the tree must be associated with a tcl program, which will be responsible for performing the step. You supply these tcl programs. For more details of tcl programming refer to the examples below and also to the <a href="#occt_wok_8">Tcl Overview</a> section. 
-
-The following example defines a umake dependency tree and introduces two new steps: exec.kerobj and exec.core. Each of these steps is then associated with a tcl program. 
-~~~~~
--- File Name: DCube_WOKSteps.edl 
-
-\@ifnotdefined (%DCube_WOKSteps_EDL) then 
-  \@set %DCube_WOKSteps_EDL = **; 
-  \@string %WOKSteps_ObjGroup += *obj.libs obj.arx obj.objs *; 
----\@set %WOKUmake_Steps =**src obj.inc(src) objc.cgen(src) obj.comp(src, obj.cgen) obj.libs(src) obj.arx(obj.libs) obj.objs(obj.arx) obj.lib(obj.comp, obj.objs) obj.idep(obj.comp,src)*; 
-  \@set %WOKSteps_obj_libs = *DCube_Libs(src)*; 
-  \@set %WOKSteps_obj_arx = *WOKStep_LibExtract(obj.libs)*; 
-  \@set %WOKSteps_obj_objs = *DCube_Objs(obj.arx)*; 
-\@set %WOKSteps_obj_lib = *WOKStep_DynamicLibrary(obj.comp, obj.objs)*; 
-  \@set %WOKSteps_toolkit_ListWith = *obj.comp obj.objs*; 
-\@endif; 
-~~~~~
-
-#### Tcl Step Implementation
-
-Customization at the tcl step level requires an understanding of the build process and the WOK dependency tree. Modification at this level is generally used to add elements to the build which are not described in the CDL. For example one possible use is to include external libraries or files into the final shareable library. Refer to <a href="#occt_wok_8_3_4">Writing Tcl Steps for a WOK Build</a> for more details.
-@subsection occt_wok_4_9  Source Management Services
-You use the source management services to integrate source files between a root workbench and one of its children. The services are related to a particular workshop. 
-
-* *wprepare* - displays a report of the files state in the current workbench (as compared with the files in the root workbench). 
-* *wstore* - queues a report for further integration and stores the related files. 
-* *wintegre* - performs check-in operations for requested files and updates the root workbench. 
-* *wnews* - allows management and use of data stored in the integration journal. 
-* *wget* - imports source files to the current workbench. 
-
-@subsubsection occt_wok_4_9_1  wprepare
-~~~~~
-wprepare –wb <father workbench> [-ud <ud1,ud2,...,udN>] -o [<filename>]
-wprepare –wb <father workbench> [-ref][-ud <ud1,ud2,...,udN>] -o [<filename>]
-~~~~~
-Prepares a report for integration to a reference (root) Workbench. This command prints a comparison of the state of source files contained in the specified units, <ud1,ud2,...,udN,> of the current workbench. 
-
-This workbench must be a direct descendant of the root workbench. If no unit names are specified, all the units in the workbench are processed. By default, the results of the comparison are printed to the standard output. The differences are computed in relation to the root workbench. 
-
-For each file, the status is indicated as follows: 
-* \# The file has been modified. 
-* \= The file was found in the current workbench but was not modified. 
-* \- The file has been removed. In other words, the entry was deleted from FILES). 
-* \+ The file has been added. In other words, the entry has been added in FILES). 
-
-Options: 
-* -ref - Creates a report that is used to initialize a base of source files. This report is used with the *wintegre -ref* command. 
-* -ud \<ud1\>, \<ud2\>, ..., \<udN\> - Specifies the list of development units to prepare for integration. Separate the unit names with a comma. If no unit names are specified, all the units in the workbench are processed. 
-* -o \<fileName\> - Writes the integration report to the specified file. By default, the report is displayed (i.e. written to standard output). 
-* -wb \<The name of target workbench\> - Specifies the name of target workbench. It should be one of father workbenches with attached integration queue. 
-
-@subsubsection occt_wok_4_9_2  wstore
-~~~~~
-wstore –ls –wb <MasterWb>
-wstore -cat <ID>
-wstore [-trig] -rm <ID> [-f] –wb <MasterWb>
-wstore –create –wb <MasterWb>
-wstore [<FileName>]
-~~~~~
-This command manages the queue of pending reports. When a report is queued it is given a unique number also called a report-ID. 
-
-Options: 
-* \<FileName\> - Adds a report from the file FileName to the report queue. 
-* -trig - Calls a tcl procedure after the report has been processed. This tcl procedure must be located in the admin directory of the workshop and the file must be named wstore_trigger.tcl. An example of a trigger can be found in the file <i>$env(WOK_LIBRARY)/wstore_trigger.example</i>. 
-* -ls - Lists pending reports, together with their owners and their IDs. This is a default option. If two files are found with the same name in the same development unit in two different reports the full path of each of these files is displayed. 
-* -cat \<Report_ID\> - Displays the contents of the report <i>\<Report_ID\></i>. 
-* -rm - Removes a report from the report queue. 
-* -f - Forces deletion. This option must be used with the -rm option when you delete a report that you do not own. 
-* -param - Lists queue parameters associated with the workbench. 
-* -create –wb \<MasterWb\> -queue \<any/dir\> -type SCCS - Creates an integration queue associated with MasterWb workbench, queue should be located at any/dir and specify SCCS type of database. 
-
-Possible options for –create are: 
-* -queue - Specify the name of directory under which queue is created 
-* -type - Specify the type of database (can be SCCS or RSC, SCCS by default) 
-* -base - Specify the location where to put the repository (only for SCCS database). Default behavior: creates repository in the adm directory of the master workbench. 
-* -counter - Specify the name of directory where the integration counter is located. Default behavior: creates subdirectory adm in directory created using –base option 
-* -journal - Specify the location of integration journal. Default behavior: : creates subdirectory adm in directory created using –base option 
-* -welcome - If increment contains new development units, by default store will refuse such increment. If you want to be able to add new units to MasterWb through integration mechanism use – welcome option. 
-
-#### Example 
-
-~~~~~
-wstore ReportName –wb MasterWb 
-~~~~~
-Queues the report ReportName and saves a copy of the files mentioned in the report. This copy will be used when the report is actually processed by the command *wintegre*.
-~~~~~
-wstore –wb MasterWb -f -rm Report_ID 
-~~~~~
-Removes the report Report_ID from the queue, even if you do not own it. 
-
-@subsubsection occt_wok_4_9_3  wintegre
-~~~~~
-wintegre [<reportID>] –wb <MasterWb> 
-~~~~~
-Processes a report and removes it from the queue in the current workshop. 
-
-Parameters: 
-* \<reportID\> - Number indicating the rank of the report in the integration queue. Use the command *wstore –l* to get this number. 
-
-Options: 
-* -ref \<BaseNumber\> - Initializes the version of the elements in the repository. 
-* -all - Processes all the reports in the integration queue. 
-* -wb - Specify the integration queue of which workbench should be used 
-* -norefcopy - Updates the repository but not the target workbench. 
-* -nobase - Updates the target workbench but not the repository. This option is rather useful when copying a set of UDs from a workbench into another. 
-* -param - Shows the parameters’ current value. 
-
-**Note** that the -nobase and -norefcopy options are mutually exclusive.
-
-#### Examples
-
-~~~~~
-wintegre -ref 2 1 –wb ref 
-~~~~~
-Uses the report whose ID is 1 to initialize the ref workbench with BaseNumber equal to 2. 
-~~~~~
-wintegre 1 –wb ref 
-~~~~~
-Integrates the report whose ID is 1 to ref workbench. 
-~~~~~
-wintegre -f 8 –wb ref 
-~~~~~
-Forces the integration of report 8. Use the –f option if you want report 8 to be processed first. 
-
-
-~~~~~
-wprepare -MyWb -o/tmp/MyReport 
-wstore /tmp/MyReport (GetID say 3) –wb ref 
-wintegre –wb ref -nobase 3 
-~~~~~
-Edit the comment and modify <i>/tmp/MyReport</i> if required with current workbench accessed from ref workbench. 
-You may use the -nobase option adding the following line in the VC.edl file (Adm of the concerned file): 
-~~~~~
-\@set %VC_TYPE = *NOBASE*; 
-~~~~~
-@subsubsection occt_wok_4_9_4  wnews
-
-The command has the following syntax: 
-~~~~~
-wnews [-x] [-from p1 -to p2] [-headers|-units|-comments|- all] [-command TclCmd] 
-wnews -set markname [ -at p ] 
-wnews -ls [-bydate] 
-wnews -rm markname 
-wnews -admin 
-wnews -purge 
-~~~~~
-
-The *wnews* command allows managing and using the data stored in the integration journal. 
-The integration journal is updated via the command *wintegre* each time an integration is performed; it contains all the UDs and files concerned with the integration, as well as the comments provided by the developers (reports). 
-
-Every integration is numbered and the associated files are archived with a specific version number. 
-Marks can be set on specific zones of the integrations via the wnews command. A mark is a character string which does not contain any dash character (-) and is associated with an integration number. Several marks may point to the same number, but one mark may only point to one number. 
-
-**Note** that *BEGIN* and *END* are reserved mark names. You cannot use them. 
-
-Options: 
-* -from p1 -to p2 - Extracts a portion of the journal file between index p1 and p2, with p1 and p2 integration numbers or marks. If p1 is not specified, reports are extracted from the beginning of the journal file. If p2 is not specified, reports are extracted up to the end of the journal file. 
-* -at p - Places a mark at index p, with p being an integration number. If p is not specified, the mark is placed at the end of the journal. 
-* -ls [-bydate] - Lists the marks. If -bydate is specified, the marks are listed in the order they were created. Otherwise, they are listed according to their place in the journal file. 
-* -rm \<markname\> - Removes the mark *markname*. 
-* -admin - Displays the journal location, date and other information. 
-* -purge - Saves the journal file and creates a new empty one. 
-
-Additional options: 
-* -o file \<name\> - Redirects output in file. This option is ignored if -command is specified. 
-* -ws \<shop\> - Uses journal of shop instead of the current one. shop must belong to the current factory. 
-* -command \<MyCommand\> - Runs the command *Tcl MyComm* on the specified part of the journal. The syntax is the following: *proc MyComm { comments table args } { ...}*, where *comments* is a string containing all the comments on the integration between n1 and n2, and *table* is a table indexed with the names of the concerned *uds* (each element of the table is a list of UD files with definition of their status and version). Additional arguments may be passed using *userdata* with the argument *args* containing *mydata1, mydata2*. 
-
-Wok provides a similar procedure *wnews:cpwb*, which allows to copy UDs from one workbench into another. 
-
-**Note** that you may access the associated code of this command by typing *tclsh>cat $env(WOK_LIBRARY)/news_cpwb.tcl*
-For example, we can add the following to the file *Me.tcl*: 
-~~~~~
-proc MyComm {comments table args} { 
-puts *comments = $comments* 
-parray table 
-puts *args = $args* 
-return 
-} 
-~~~~~
-Then type the following commands: 
-~~~~~
-\> source Me.tcl 
-\> wnews -x -from n1 -to n2 -command MyComm -userdata wb1 wb2 
-~~~~~
-
-Examples
---------
-~~~~~
-wnews -set BETA_V1.1 -at 345 
-~~~~~
-Sets a mark on integration number 345 
-~~~~~
-wnews -set RELEASED_V1.1_CLOSED 
-~~~~~
-Sets a mark after the last integration performed 
-~~~~~
-wnews -ls 
-~~~~~
-Lists all the marks set in the journal 
-~~~~~
-wnews -x -from INT_DEB -to INT_END -units 
-~~~~~
-Gets all the UDs modified between integrations INT_DEB and INT_END. Integration numbers and marks may be mixed as in the following: 
-~~~~~
-wnews -x -from INT_DEB -to 856 -comments 
-wnews -x -from INT_DEB -to INT_END -comments 
-~~~~~
-Gets all the comments from the integrations between *INT_DEB* and *INT_END* 
-~~~~~
-source Mycommand.tcl 
-wnews -x -from INT_DEB -to INT_END -command Mycommand 
-~~~~~
-In a more elaborate way, a Tcl process may be called to get all information on the reports between *INT_DEB* and *INT_END*.
-~~~~~ 
-wnews -x -from n1 -to n2 -command wnews:cpwb –userdata w1,w2,[ulist, notes] 
-~~~~~
-All modified files between n1 and n2 are copied from workbench w1 into workbench w2. New UDs are created in w2 if required If *ulist* is specified, only the UDs contained in this list are Processed. If notes is specified, all comments between n1 and n2 are written into this file. 
-
-@subsubsection occt_wok_4_9_5  wget
-~~~~~
-wget [-l] –wh <MasterWb>
-wget [-f] –wb <MasterWb> [-ud <UnitName>] <SourceFile> [-v <Version>]
-wget [-f] –wb <MasterWb> [-ud <UnitName>] <SourceFile1>...<SourceFileN>
-~~~~~
-The *wget* command allows importing source files into the workbench. The files are fetched from the SCCS database of the factory. This operation is known as a check-out operation. You can specify one or more files or a unit name. By default, the latest version of the files is fetched.
-Options: 
-* \<SourceFile\> - Fetches a copy of the specified file. 
-* -ud \<UnitName\> Fetches all the source files of the development unit you specified. 
-* -f Forces existing files to be overwritten. 
-* -v \<Version\> Fetches \<Version\> of the file you specified. 
-* -l Lists the files of the development unit that can be copied (i.e. that you can **get**). This is a default option. 
-
-#### Example
-
-~~~~~
-wget –wb MasteWb –ud MyUd File1.cxx File2.hxx 
-~~~~~
-Fetches the latest version of *File1.cxx* and *File2.hxx*.
-@subsubsection occt_wok_4_9_6  Installation Procedure
-
-In the new WOK model: 
-  *  each workbench can have its own database 
-  *  the version control environment variables are relative to the workbench. 
-@image html /dev_guides/wok/images/wok_image014.png "Workshop Installation Model"
-@image latex /dev_guides/wok/images/wok_image014.png "Workshop Installation Model"
-
-The following procedure explains how to set up the source management environment for a workshop. 
-1. Open the factory and the workshop. 
-~~~~~
-\> wokcd <factory:workshop> -P Adm
-~~~~~
-2. Define the environment variables for version control by editing the file *VC.edl*. Your entries should respect the following syntax: 
-~~~~~
-\@set %VC_TYPE=”SCCS”
-\@set %VC_ROOT=”/dirA/dirB/.../<MyDir>”
-~~~~~
-3. Reopen the workbench that you want to connect to the database. 
-~~~~~
-\> wokcd <factory:workshop:workbench>
-~~~~~ 
-4. Create SCCS database associated with workbench. 
-~~~~~
-\> wstore –create –wb <factory:workshop:workbench> -queue <PathToQueue>
-~~~~~
-5. Create a report associated with the root workbench. 
-~~~~~
-\> wprepare –wb <workbench> -o ref.report
-~~~~~
-6. Queue this report. 
-~~~~~
-\> wstore –wb <workbench> ref.report
-~~~~~
-7. Perform the actual creation of the SCCS database. 
-~~~~~
-> wintegre –wb <workbench> < BaseNumber >
-~~~~~
-   Here \<BaseNumber\> is the first digit of the SCCS version numbers. 
-
-@subsubsection occt_wok_4_9_7  Integration Procedure
-
-To integrate, proceed as follows: 
-1. Create the report for the current workbench.
-~~~~~ 
- \> wprepare –wb MasterWb -o MyReport 
-~~~~~
-2. If necessary, edit this report to remove lines and append comments. Comments should begin with -- (double hyphen). 
-3. Queue the report and store the files. 
-~~~~~
-\> wstore –wb MasterWb MyReport
-~~~~~
-   By this step, all the files you have modified have been stored and the report has been queued. You can continue with modifying these files.
-
-4. Examine the state of the integration queue to get the ID of your report. 
-~~~~~
-\> wstore –wb MasterWb -ls
-~~~~~
-5. Perform the integration and be sure you can write in the root workbench. This operation is usually reserved for the workshop administrator. 
-~~~~~
-\> wintegre –wb MasterWb [ID]
-~~~~~
-
-@subsection occt_wok_4_10 Session Services
-
-A single session service is also available to allow you to query WOK. 
-*Sinfo* command returns details of the WOK session. 
-~~~~~
-Sinfo -option 
-~~~~~
-
-Options: 
-* -F Gets factory list 
-* -f Gets current factory 
-* -s Gets current workshop 
-* -w Gets current workbench 
-* -u Gets current development unit 
-* -t \<entity_path\> Gets the entity type 
-* -E Reserved for internal use. Gets known Entity List 
-* -N Reserved for internal use. Gets known Entity Names 
-
-#### Example
-
-~~~~~ 
-Sinfo -F 
-~~~~~
-Returns a list of WOK factories. 
-
-@subsubsection occt_wok_4_10_2  Convenience Aliases
-
-To ease the upgrade to the new version of WOK a number of aliases, compatible with the old version, have been set up. These convenience aliases include: 
-* **fcd** - Moves to the specified factory. 
-* **scd** - Moves to the specified workshop. 
-* **wcd** - Moves to the *src* directory of the specified development unit. 
-* **wdrv** - Moves to the *drv/DBMS/Station* directory of the current development unit. 
-* **wls** - Lists the development units in the current workbench. 
-* **wsrc** - Moves to the *src* directory of the current development unit. 
-
-@section occt_wok_5 Using the Graphic Interface
-The following is an overall description of the IWOK main menu bar. Please, refer to the on-line help to get more detailed information on the various applications accessed via the graphic interface. 
-@subsection occt_wok_5_1  Main menu bar
-@image html /dev_guides/wok/images/wok_image015.png
-@image latex /dev_guides/wok/images/wok_image015.png
-@subsubsection occt_wok_5_1_1  Menus
-The main menu bar contains three menus: 
-  *  **File** to exit the iwok session, 
-  *  **Windows** to display all windows created in the session, 
-  *  **Help** to display the associated on-line help. 
-
-@subsubsection occt_wok_5_1_2  Application icons
-
-The four icons on the left are used to access applications: 
-*  **wprepare**, allows preparing the integration queue being associated with a given workshop, 
-@image html /dev_guides/wok/images/wok_image016.png
-@image latex /dev_guides/wok/images/wok_image016.png
-*  **umake**, gives access to all available umake options plus compilation options, 
-@image html /dev_guides/wok/images/wok_image017.png
-@image latex /dev_guides/wok/images/wok_image017.png
-*  **CDL browser**, provides information on the class structure or translated classes, 
-@image html /dev_guides/wok/images/wok_image018.png
-@image latex /dev_guides/wok/images/wok_image018.png
-
-*  **parameters**, allows displaying and editing all EDL files. 
-@image html /dev_guides/wok/images/wok_image019.png
-@image latex /dev_guides/wok/images/wok_image019.png
-
-
-**Note:** for further information on CDL, refer to the CDL Reference Manual. 
-
-@subsubsection occt_wok_5_1_3  Display management
-Click on the logo to either display or not the session in a window just below the main menu bar. 
-
-You may choose to display icons in the window, either in **columns**, with the **last modified first**, by **date and size**, or in **rows**. 
-
-Use the **go up** icon to navigate through the session and **wokcd** to update the window where the session was started. 
-@image html /dev_guides/wok/images/wok_image020.png
-@image latex /dev_guides/wok/images/wok_image020.png
-
-The field **Location** gives the exact address of the item in the session. Use the arrow on the right to select already visited addresses. 
-
-@subsection occt_wok_5_2  Popup menus
-
-Two types of popup menus may be accessed according to the context. Just click MB3 to display the popup menu. 
-
-Click on an item in the left window to get the popup menu providing access to applications. 
-
-@image html /dev_guides/wok/images/wok_image021.png
-@image latex /dev_guides/wok/images/wok_image021.png
-
-In the right window you get the selection popup menu for the item types: 
-
-@image html /dev_guides/wok/images/wok_image022.png
-@image latex /dev_guides/wok/images/wok_image022.png
-
-@section occt_wok_6 Appendix A. Using the Emacs Editor
-
-WOK is operated using the editor Emacs. Emacs is not provided in the Open CASCADE Technology distribution but is available from http://www.gnu.org/software/emacs/#Releases
-
-A CDL mode has been created for Emacs. The .el file for this mode is not provided in the distribution, but is available on request from OPEN CASCADE. 
-
-List of Keys and their Bindings in cdl Mode
--------------------------------------------
-
-|C-c |Command prefix |
-|TAB | cdl-tab |
-|DEL | backward-delete-character-untabify |
-|ESC | Command prefix |
-|C-c C-x | cdl-new-exception |
-|C-c C-e | cdl-new-enumeration |
-|C-c C-b | cdl-new-buffer |
-|C-c C-p | cdl-new-package |
-|C-c C-r | cdl-new-rubric |
-|C-c C-c | cdl-new-class |
-|C-c f | cdl-fill-mode |
-|C-c s | cdl-structure |
-|C-c t | cdl-tabsize |
-|C-c e | cdl-comment-end |
-|ESC k | cdl-find-class |
-|ESC q | cdl-comment-fill |
-|ESC TAB | cdl-untab |
-|ESC-RET | cdl-raw-newline |
-
-@section occt_wok_7 Appendix B. Parameters and EDL Files
-
-@subsection occt_wok_7_1 EDL language
-
-@subsubsection occt_wok_7_1_1 Key Concepts
-
-EDL is a script-like programming language.
-
-**Comment** - text, preceded by two hyphens. 
-~~~~~
--- Comment text.... 
-~~~~~
-* **Identifier** - any combination of characters in the ranges A-Z, az, 0-9 and _ (underscore). 
-* **Variable** - an identifier preceded by % (percent sign). 
-* **Actions** The following actions are available: 
-~~~~~
-\@string 
-\@set 
-\@apply 
-~~~~~
-* **Execution**  <i>\@uses</i> is an execution operator.
-* **Input/Output** The following input/output operators are provided: 
-~~~~~
-\@file 
-\@write 
-\@close 
-\@cout
-~~~~~ 
-* **Conditional Operators** The following conditional operators are provided: 
-~~~~~
-\@iffile 
-\@ifdefined 
-\@ifnotdefined 
-\@ifnotfile 
-\@if 
-then 
-\@else 
-\@endif
-~~~~~
-* **Operators** The following operators are available: 
-<code>
-== 
-!= 
-|| 
-&& 
-file 
-notfile 
-defined 
-notdefined 
-</code>
-
-**Templates** The following template commands/keywords are available: 
-~~~~~
-\@template 
-is 
-\@end 
-\@addtotemplate 
-\@cleartemplate 
-~~~~~
-**Miscellaneous** The following miscellaneous commands exist: 
-~~~~~
-\@verboseon 
-\@verboseoff 
-~~~~~
-
-@subsubsection occt_wok_7_1_2  Syntax
-
-The following conventions are used in the explanations below: 
-
-| *\<Variable\>*  | refers to a variable, for example: *%myvariable*                               |
-| *\<Id\>*        | refers to an identifier, for example: *myidentifier*                           |
-| *“String”*      | refers to a string of characters, for example: *“my string of characters”*     |
-| *\<Condition\>* | refers to a condition, for example: *(%mytest == “ok”) || (%mytest == “good”)* |
-| *\<Template\>*  | refers to the name of a template, for example: mytemplate.                     |
-|{}               | indicates possible repetition of what is within the curly brackets.            |
-
-@subsubsection occt_wok_7_1_3  EDL Actions
-
-\@string 
---------
-~~~~~
-\@string <Variable> = {<Variable> or “String”} ;
-\@string <Variable> += {<Variable> or “String”} ;
-~~~~~
-Concatenates the contents of the variables and strings on the right of the equals sign and assigns the result to the variable situated on the left. Using the operator ‘+=’ instead of ‘=’ adds the concatenation to the current contents of the variable on the left. 
-
-\@set
----- 
-~~~~~
-\@set <Variable> = “ String” ;
-~~~~~
-Sets \<Variable\> to the value “String”
-
-\@apply
------- 
-~~~~~
-\@apply <Variable> = <Template> ;
-~~~~~
-Evaluates the template, \<Template\>, and sets \<Variable\> equal to this.
-
-\@uses
------
-~~~~~
-\@uses <Variable>;
-\@uses “ String”;
-~~~~~
-Runs an EDL file. The name of this file is either contained in the variable \<Variable\> or is given as a string, \<String\>.
-
-\@file
------
-~~~~~
-\@file <Id> <Variable> ;
-\@file <Id> “String” ;
-~~~~~
-Opens a file and associates it with the identifier \<Id\>. This \<Id\> identifies the file until it is closed. The name of the file is given as a string \<String\>, or using a variable \<Variable\>.
-
-\@write
-------
-~~~~~
-\@write <Id> <Variable> ;
-~~~~~
-Writes the contents of the variable out to a file indicated by the file \<Id\>. This \<Id\> is the identifier allocated to the file when is opened using \@file.
-
-\@close
-------
-~~~~~
-\@close <Id> ;
-~~~~~
-Closes the file identified by \<Id\>. This \<Id\> is the identifier allocated to the file when is opened using \@file.
-
-\@cout
------
-~~~~~
-\@cout {<Variable> or “String”} ;
-~~~~~
-Concatenates the contents of the variables and strings and displays the result on standard out.
-
-\@iffile
--------
-~~~~~
-\@iffile ( <Variable> or “String”) then
-\@endif ;
-\@iffile ( <Variable> or “String”) then
-\@else
-\@endif ;
-~~~~~
-Checks for the existence of a file, the name of which is given in the string  ‘String”, or else contained in the variable \<Variable\>.
-If the file exists, the instructions contained in the ‘then’ loop are executed up to the *\@endif*, (or an \@else if one is found before the \@endif ).
-If the files do not exist, the ‘else’ loop is executed (if one exists).
-
-\@ifnotfile
-----------
-~~~~~
-\@ifnotfile ( <Variable> or “String”) then
-\@endif ;
-\@ifnotfile ( <Variable> or “String”) then
-\@else
-\@endif ;
-~~~~~
-Checks for the existence of a file, the name of which is given in the string ‘String”, or else contained in the variable \<Variable\>.
-If the file does not exist, the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
-If the file does exist, the ‘else’ loop is executed (if one exists).
-
-\@ifdefined 
-----------
-~~~~~
-\@ifnotdefined ( <Variable> or <Template>) then
-\@endif ;
-\@ifnotdefined ( <Variable> or <Template>) then
-\@else
-\@endif ;
-~~~~~
-Checks for the existence of a variable or template, the name of which is given by \<Template\>, or else contained in the variable \<Variable\>.
-If a variable or a template by this name exists the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
-If neither a variable nor a template exists, the ‘else’ loop is executed (if one exists).
-
-
-\@ifnotdefined
--------------
-~~~~~
-\@ifnotdefined ( <Variable> or <Template>) then
-\@endif ;
-\@ifnotdefined ( <Variable> or <Template>) then
-\@else
-\@endif ;
-~~~~~
-Checks for the existence of a variable or template, the name of which is given by \<Template\>, or else contained in the variable \<Variable\>.
-If neither a variable nor a template by this name exists the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
-If a variable or a template does exist, the ‘else’ loop is executed (if one exists).
-
-\@if 
------
-~~~~~
-\@if (<Condition>) then
-\@endif ;
-\@if (<Condition>) then
-\@else
-\@endif ;
-~~~~~
-Tests a condition.
-If the condition is true the instructions in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
-If the condition is false, the ‘else’ loop is executed (if one exists).
-
-\@template
----------
-~~~~~
-\@template <Template> (<Variable>, ... , <Variable>) is
-  $ text...
-  .
-  .
-  $ text...
-\@end;
-~~~~~
-Creates a template, which is a definition that contains variables. The variables on which a template relies are given in parentheses, following the name of the template. These variables are used to evaluate the template, and are referred to as ‘variables of evaluation’. When a template is evaluated (see \@apply) the variables in its definition are replaced by the current values of the ‘variables of evaluation’.
-A template is re-evaluated each time it is used.
-
-\@addtotemplate
---------------
-~~~~~
-\@addtotemplate <Template> is
-  $ text
-  .
-  .
-  $ text
-\@end;
-~~~~~
-
-Adds the specified lines to an existing template.
-
-\@cleartemplate
---------------
-~~~~~
-\@cleartemplate <Template> ;
-~~~~~
-Removes all the lines of a template. 
-
-\@verboseon
-----------
-~~~~~
-\@verboseon ; 
-~~~~~
-Turns on the verbose mode, such that lines of text are displayed on standard out when you run EDL files. 
-
-\@verboseoff
------------
-~~~~~
-\@verboseoff ; 
-~~~~~
-Turns off the verbose mode, such that lines of text are not displayed on standard out when you run EDL files. 
-
-@subsubsection occt_wok_7_1_4  EDL Conditions
-Conditions are used with *\@if* commands. Complex and simple conditions are available. The syntax is similar to C++. 
-
-#### Simple Conditions
-Simple conditions test for equality, the existence of a particular file and so on. The general format is: 
-~~~~~
-\@if(<Condition>) then 
-... 
-~~~~~
-The syntax of simple conditions is given below. 
-~~~~~
-<Variable> == “String” -- (equals)
-<Variable> != “String” -- (does not equal)
-defined(<Variable>) -- (see \@ifdefined)
-defined(<Template>) -- (see \@ifdefined)
-notdefined(<Variable>) -- (see \@ifnotdefined)
-notdefined(<Template>) -- (see \@ifnotdefined)
-file(<Variable>) -- (see \@iffile)
-file(“String”) -- (see \@iffile)
-notfile(<Variable>) -- (see \@ifnotfile)
-notfile(“String”) -- (see \@ifnotfile)
-~~~~~
-
-#### Complex conditions
-
-Complex conditions take into account the results of other conditions. Complex conditions use the operators || (logical OR) or the operator  (logical AND). There are no restrictions on the formulation of these conditions: 
-* (Simple condition) operator (Simple condition) 
-* (Complex condition) operator (Simple condition) 
-* (Simple condition) operator (Complex condition) 
-* (Complex condition) operator (Complex condition) 
-
-For example,
-~~~~~
-\@if ((%a == “0” && %b == “1” && %c == “1”) || %d == “1” && ((%a == “1”) && %b == “1”)) then
-  \@cout “CONDITION TRUE”;
-\@else
-  \@cout “CONDITION FALSE”;
-\@endif;
-~~~~~
-
-@subsection occt_wok_7_2  WOK Parameters
-WOK parameters are defined using EDL. There are two types of EDL parameters: Variables and Templates. 
-
-Variables have a ‘fixed’ value. By contrast a template relies on the values of other variables, and must re-evaluate itself each time it is used. 
-
-@subsubsection occt_wok_7_2_1  Classes of WOK Parameters
-WOK parameters are grouped according to their class. The following classes exist: 
-| CODEGEN  | Code generator options, for example options for lex and yacc. |
-| CMPLRS   | Compiler options. |
-| LDAR     | Archive creation options. |
-| ARX      | Archive extraction options. |
-| LDEXE    | Executable linker options. |
-| LDSHR    |  Shared linker options. |
-
-@subsubsection occt_wok_7_2_2  Defining WOK Parameters
-The WOK distribution includes a base configuration for each class of parameters. This base configuration is provided in the form of EDL files, one file per a class of parameters. Each file is named according to the parameter class: 
-~~~~~
-<ParamClassName>.edl
-~~~~~
-This configuration file sets the values of all the parameters in the class. 
-
-For example, consider a parameter class FOO. There are two variable parameters in this class: FOO_Shared and FOO_Name. These two parameters are assigned a value in the FOO.edl file. The file is given as an example below: 
-~~~~~
--- standard protection against multiple execution 
-\@ifnotdefined ( %FOO_EDL) then 
-\@set %FOO_EDL = **; 
-
--- set %FOO_Shared according to the platform 
-\@if ( %LocalArch != *hp* ) then 
-\@set %FOO_Shared = *libCPPExt.so*; 
-\@endif; 
-\@if ( %LocalArch == *hp* ) then 
-\@set %FOO_Shared = *libCPPExt.sl*; 
-\@endif; 
-
--- set the FOO_Name parameter to FOO 
-\@set %FOO_Name = *FOO*; 
-\@endif; 
-~~~~~
-
-Note that all the parameters in a class take the name of the class as a prefix to their own name. Parameters of type variable are also prefixed by % (percent symbol): 
-~~~~~
-%ClassName_VariableParamName 
-ClassName_TemplateParamName 
-~~~~~
-A simplified template definition is given as an example below. This definition is based on the FOO parameters set in the previous example above. 
-
-Let us define the variable parameter(s) to be used in the template and then the template itself:
-~~~~~
-\@set %FOO_Shared = *libCPPExt.so*; 
-\@set %FOO_Name = *FOO*; 
-
-\@template FOO_Load ( %FOO_Shared, %FOO_Name) is 
-$ %FOO_Load_%FOO_Shared %FOO_Name 
-\@end; 
-~~~~~
-
-@subsubsection occt_wok_7_2_3  Redefining Parameters
-Occasionally you may want to redefine WOK parameters. For example, you can change the compiler options to force ANSI mode compilation, or redefine how external libraries are referenced. 
-Before redefining anything, decide on the scope of the redefinition. Is the redefinition to apply to the whole factory, a single workshop, a workbench, or just a development unit? In some cases you may want to redefine parameters within a delivery unit, so that a parcel is delivered with particular options. 
-
-The order in which redefinitions are applied (order of precedence) may mean your options are overwritten by subsequent redefinitions.
-
-#### Redefinition Files
-
-Each entity can have an associated redefinition file for each class of parameters. A redefinition file is an EDL file. It always takes the name of the entity to which it belongs, followed by the name of the class of parameters that it applies to: 
-~~~~~
-<EntityName>_<ParamClassName>.edl
-~~~~~
-For example, the file MyFactory_CMPLRS.edl redefines one of more of the parameters in the CMPLRS class. The scope of this redefinition is MyFactory. To be taken into account by WOK, this redefinition file must be created in the administration directory of the entity to which it belongs. To find out the pathname of this directory, use the command: 
-~~~~~
-wokinfo -p admfile:<EntityName>_<ParamClassName>.edl <EntityPath>
-~~~~~
-To test whether the file exists actually, use the command: 
-~~~~~
-wokinfo -p adminfile:WOK_LDAR.edl WOK=> /adv22/wok/adm
-~~~~~
-There is one exception to this rule for file placement. For a development unit, the redefinition file is treated as a *source *file, and consequently it must be located in the src directory of the unit. To find out the path of this directory, use the command: 
-~~~~~
-wokinfo -p source:<UnitName>_<ParamClassName>.edl <UnitPath>
-~~~~~
-
-One of the most common reasons to redefine WOK parameters is to modify compiler options. To do this, for example to add a compile option to the package *MyPack*: 
-* In the source directory of MyPk, create file *MyPk_CMPLRS.edl* 
-* In this file add the definition: 
-~~~~~
-\@string %CMPLRS_CXX_Options +=  * -DMyDefine=string *; 
-~~~~~
-
-Order of Precedence for Parameter Redefinitions 
------------------------------------------------
-WOK takes parameter (re)definitions into account in the following order. 
-* WOK 
-* Factory 
-* Workshop 
-* Parcels (within the Workshop configuration, in the order in which they are declared in the parcel configuration). 
-* Workbench (in order of inheritance) 
-* Development unit 
-WOK provides commands to find out what parameter definitions (and redefinitions) are used, and in what order. You can see what compiler parameters are used by WOK in *CMPLRS.edl* file. To find this file, use the command: 
-~~~~~
- wokparam -S CMPLRS.edl 
-~~~~~
-Then run the command. 
-~~~~~
-wokparam -F CMPLRS EntityPath 
-~~~~~
-This command displays a list of all the definition files, for parameters of type compiler, that are taken into account for EntityPath. These file are listed in the order in which they are taken into account. The last definition is the one that is used. 
-
-@subsection occt_wok_7_3  Using EDL to Define WOK Parameters
-@subsubsection occt_wok_7_3_1  Modification of Link Options - Example
-
-#### How to add a define to the compilation
-
-To add a define for all C++ files compiled in the package *MyPackage*, *MyPackage_CMPLRS.edl* is declared in the development unit *MyPackage* This file contains: 
-~~~~~
-\@string %CMPLRS_CXX_Options = 
-%CMPLRS_CXX_Options  * -DMYDEFINE*; 
-~~~~~
-
-#### How to use a code generator
-
-In this example, a C code generator is used, which takes the input <i>\<file\>.mygen</i> and generates a <i>\<file\>.c</i>. The step *obj.cgen* automatically recognizes all files with the extension mygen and uses the generator on these files. The resulting .c files are compiled by the step *obj.comp*. 
-The file *MyUnit_CODEGEN.edl* is written in a nocdlpack development unit *MyUnit*. This file contains the following code: 
-
-~~~~~
--- list of tools recognized by the step obj.cgen 
--- the tool MYGEN is added 
-\@ string %CODEGEN_Tools = %CODEGEN_Tools  * CODEGEN_MYGEN*; 
-
--- the tool MYGEN is called via the template CODEGEN_MYGEN_CmdLine 
-
-\@set %CODEGEN_MYGEN_Template = *CODEGEN_MYGEN_CmdLine*; 
-
--- the extension of files processed by MYGEN is mygen 
-
-\@set %CODEGEN_MYGEN_Extensions = *foo.mygen*; 
-
--- the tool MYGEN is the executable /usr/local/bin/mygen 
-
-\@set %CODEGEN_MYGEN_Tool =  * /usr/local/bin/mygen*; 
-
--- the tool MYGEN produces a .c file 
-
-\@template CODEGEN_MYGEN_Production ( %BaseName ) is 
-$%BaseName.c 
-\@end; 
-
--- the command executed to construct the .c file is: 
-
-\@template CODEGEN_MYGEN_CmdLine ( %CODEGEN_MYGEN_Tool, 
-%Source, %BaseName, %OutputDir ) is 
-$cd %OutputDir 
-$%CODEGEN_MYGEN_Tool -f %Source -o %BaseName.c 
-\@end; 
-~~~~~
-
-@section occt_wok_8 Appendix C. Tcl
-@subsection occt_wok_8_1  Tcl Overview
-Tcl stands for ‘‘tool command language* and is pronounced ‘‘tickle*. It is actually two things: a language and a library. 
-
-As a simple textual language, tcl is intended primarily for issuing commands to interactive programs such as text editors, debuggers, illustrators, and shells. It has a simple syntax and is also programmable, so tcl users can write command procedures to provide more powerful commands than those in the built-in set. 
-
-As a library package, tcl can be embedded in application programs. The tcl library consists of a parser for the cl language, routines to implement the tcl builtin commands, and procedures that allow each application to extend tcl with additional commands specific to that application. The application program generates tcl commands and passes them to the tcl parser for execution. Commands may be generated by reading characters from an input source, or by associating command strings with elements of the application's user interface, such as menu entries, buttons, or keystrokes.
-
-Download Tcltk 8.5 or 8.6 from http://www.tcl.tk/software/tcltk/8.6.html
-
-A help application, tclhelp, is also provided with tcl and can be activated by command *tclhelp*.  
-
-@subsection occt_wok_8_2  Tcl and WOK
-The tcl interpreter offers WOK the following advantages: 
-* an environment in which both WOK and UNIX commands are available, 
-* dynamic loading of WOK as it is needed, 
-* a high performance portable environment, in which the user can write customized procedures. 
-
-The following tcl commands are most commonly used with WOK: *expr, foreach, glob, if, package, proc, puts, set, source* and *unlink*. 
-
-Refer to the tcl documentation, or the tcl help application, for details of these and other tcl commands. 
-
-@subsection occt_wok_8_3  Configuring Your Account for Tcl and WOK
-To have access to WOK you must modify the configuration files of your account as described below. 
-@subsubsection occt_wok_8_3_1  The cshrc File
-To allow the C shell session to configure tcl add the following line to your .chsrc file: 
-~~~~~
-source/<sun|ao1|sgi|hp>_SYSTEM/util_LOG/cshrc_TCL
-~~~~~
-To configure your account to allow access to WOK add the following line to your .cshrc file: 
-~~~~~
-if(!$?WOKHOME) then
-setenv WOKHOME /YOURCONTAINER/wok-<version of wok>
-source /<sun|ao1|sgi|hp>_SYSTEM/util_LOG/cshrc_Wok
-~~~~~
-@subsubsection occt_wok_8_3_2  The tclshrc File
-To enable configuration of the tcl interpreter, add the following line to your .tclshrc if it exists (if not create one): 
-~~~~~
-source $env(WOKHOME)/site/tclshrc_Wok 
-~~~~~
-
-@subsubsection occt_wok_8_3_3  The WOK_SESSIONID Variable
-The *WOK_SESSIONID* environment variable ensures that you start a new WOK session in the same state and with the same parameter values as your previous WOK session. This continuity is provided by using the same WOK_SESSIONID. Note that your *WOK_SESSIONID* does not change, unless you change it manually. 
-
-Make sure that *WOK_SESSIONID* points to (a subdirectory of) your home directory. 
-
-@subsubsection occt_wok_8_3_4  Writing Tcl Steps for a WOK Build
-There are three advanced WOK commands available for writing umake steps in tcl: 
-  *  *msgprint* 
-  *  *stepoutputadd* 
-  *  *stepaddexecdepitem* 
-*msgprint [-i|-w|-e|-v|-V Class]* prints a message. The output is directed to a WOK internal process that is in charge of printing messages. 
-
-The following options are available:  
-| -i          | Prints an information message.                                |
-| -w          | Prints a warning message.                                     |
-| -e          | Prints an error message.                                      |
-| -v          | Prints a verbose message.                                     |
-| -V\<Class\> | Prints a verbose message for class \<Class\>.                 |
-| -c          | Prints context of message, i.e. the procedure that called it. |
-
-For example, 
-~~~~~
-msgprint -e -c *CCLKernel_GetObjects\::Execute* *Cannot locate object file :  * $file; 
-~~~~~
-Writes an error message, in format: 
-~~~~~
-ERROR: CCLKernel_GetObjects\::Execute - Cannot locate object file : MyFile 
-~~~~~
-*stepoutputadd \<options\> \<OutputFileID\> [\<filepath\>]* adds an output file to the outputs of the step. This file is treated by subsequent steps in the same way as all the other output files of the step. The following options are available:  
-
-| -p\<path\> |  Specifies the path where the file is located. |
-| -L | Output can be located (default). |
-| -N | Not a WOK file. Cannot be located. |
-| -F | Physical file (i.e. resides on a disk somewhere). |
-| -M | File is a member of the unit being built (default). |
-| -X | File is not a member of the unit being built. Not a WOK file. Cannot be located. |
-| -P | File is produced by this umake step (i.e. WOK can delete it because it will be regenerated). |
-| -R | File is not produced by this umake step (i.e. WOK must not delete it because it can not be regenerated). 
-| -S\<StepID\> | Reserved for advanced use. Specifies stepID. |
-| -V | Reserved for advanced use. Virtual ‘file’ (i.e. an MSEntity). This option is used for passing keywords between steps for example. | 
-
-For example, 
-~~~~~ 
-stepoutputadd -X -R -N -F /usr/myfiles/res.o -p /usr/myfiles/res.o 
-~~~~~
-Adds the file */usr/myfiles/res.o* to the outputs of this step. Specifies that this file is not a WOK file, cannot be located automatically by WOK, and is not generated by this step. Here the full file path is used as the unique file identifier. This appears to be duplicated when it is also given as the physical location of the file. 
-
-*stepaddexecdepitem \<options\> \<InputFileID\> \<OutputFileID\>* adds a dependency between one file and another. Typically when introducing external object libraries the files are set to be dependent on the CDL file. We do this because the CDL file changes rarely, so the external files are not needlessly reprocessed, but they are always included in the final executable. The following options are available:  
-
-| -d  | Adds a direct dependency (default). |
-| -i  | Adds an indirect dependency. |
-
-For example, 
-~~~~~
-stepaddexecdepitem -d MyInFile MyOutFile 
-~~~~~
-States that the file *MyOutFile* depends directly on the file *MyInFile*. 
-
-@subsubsection occt_wok_8_3_5  Components of a Tcl UMake Step
-
-Each tcl umake step has the following components: 
-* *HandleInputFile* - a filter: for each input file this component decides whether or not to accept the file. 
-* *OutputDirTypeName* returns one of three strings, according to the dependency of the file: 
-  * *tmpfile* = the file is independent (i.e. dependent only on its source);
-  * *dbtmpdir* = the file is dependent on the database profile;
-  * *sttmpdir* = the file is dependent on the station profile. 
-* *AdmFileType* returns one of three strings, according to the dependency of the file: 
-  * *admfile* = the file is independent (i.e. dependent only on its source); 
-  * *Dbadmfile* = the file is dependent on the database profile; 
-  * *stadmfile* = the file is dependent on the station profile. 
-
-*Execute* processes each input file that is out of date (i.e. has changed since it was last processed, or depends on a file that has changed since it was last processed). Typically this procedure takes the form of a *foreach* loop. Argument: a development unit to process and a list of one or more arguments. 
-
-@subsubsection occt_wok_8_3_6  Sample Tcl Steps
-
-#### Sample 1
-
-~~~~~
-# CCLKernel_GetObjects.tcl 
-proc CCLKernel_GetObjects::AdmFileType {} { 
-  return stadmfile; 
-} 
-proc CCLKernel_GetObjects::OutputDirTypeName {} { 
-  return sttmpdir; 
-} 
-proc CCLKernel_GetObjects::HandleInputFile { ID } { 
-  scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* unit type name 
-  return 1; 
-  switch [file extension $name] { 
-.cdl { 
-    return 1; 
-    } 
-  default { 
-    return 0; 
-    } 
-  } 
-} 
-proc CCLKernel_GetObjects\::Execute { unit args } { 
-  msgprint -i -c *CCLKernel_GetObjects\::Execute* 
-  *Processing unit : $unit*; 
-  msgprint -i -c *CCLKernel_GetObjects\::Execute* 
-  set failed 0; 
-  set inid [lindex $args 0] 
-  foreach file { Frontal_Ccal_Init_Request.o Frontal_Ccal_Send_Request.o \ 
-Frontal_Ccal_sd.o Frontal_Get_Response.o Frontal_Ccal_Connect.o } { 
-set resid *Frontal:object:$file* 
-set path [woklocate -p $resid] 
-if { $path == ** } { 
-  msgprint -e -c *CCLKernel_GetObjects\::Execute* 
-*Cannot locate object file :  * $file; 
-  set failed 1; 
-} else { 
-  msgprint -i -c *CCLKernel_GetObjects\::Execute* *Add 
-object $file at  * $path 
-  stepoutputadd -X -R -L -F $resid 
-  stepaddexecdepitem -d $inid $resid 
-  } 
-} 
-if { [wokparam -e %Station] == *sun* } { 
-  set file *risc_return.o* 
-  set resid *CCLKernel:source:$file* 
-  set path [woklocate -p $resid] 
-## set path */adv_23/wb/kl/Kernel7/prod/EngineStarter/ 
-src/risc_return.o* 
-  msgprint -i -c *CCLKernel_GetObjects\::Execute* *Add 
-object $file at  * $path 
-  stepoutputadd -X -R -N -F $path -p $path 
-  stepaddexecdepitem -d $inid $path 
-} 
-set home [wokparam -e %Ilog_Home] 
-if { $home == ** } { 
-  msprint -c *CCLKernel_GetObjects\::Execute* -e *Cannot 
-evaluate parameter : %Ilog_Home 
-  return 1; 
-} 
-foreach file { llstdio.o llfloat.o llfloat31.o cfix.o 
-lelisp.o getgloba.o cload.o } { 
-  set path *$home/o/$file* 
-  msgprint -i -c *CCLKernel_GetObjects\::Execute* *Add 
-object $file at  * $path 
-  stepoutputadd -X -R -N -F $path -p $path 
-  stepaddexecdepitem -d $inid $path 
-} 
-set file *lelisp31bin.o* 
-set path *$home/lelisp31bin.o* 
-msgprint -i -c *CCLKernel_GetObjects\::Execute* *Add 
-object $file at  * $path 
-stepoutputadd -X -R -N -F $path -p $path 
-stepaddexecdepitem -d $inid $path 
-if { $failed } {return 1;} 
-return 0; 
-} 
-~~~~~
-Sample 2
---------
-# File Name: CCLKernel_core.tcl 
-proc CCLKernel_core::AdmFileType {} { 
-  return stadmfile; 
-} 
-proc CCLKernel_core::OutputDirTypeName {} { 
-  return sttmpdir; 
-} 
-proc CCLKernel_core::HandleInputFile { ID } { 
-  scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* unit type name 
-  switch $type { 
-executable { 
-  return 1; 
-} 
-  } 
-  switch $name { 
-CCL_lelisp.ll { 
-  return 1; 
-  } 
-} 
-  return 0; 
-  } 
-proc CCLKernel_core\::Execute { unit args } { 
-  global WOK_GLOBALS env 
-msgprint -i -c *CCLKernel_core\::Execute* *Processing unit : $unit*; 
-  msgprint -i -c *CCLKernel_core\::Execute* 
-  set workbench [wokinfo -N $unit] 
-  set unitname [wokinfo -n $unit] 
-  set failed 0; 
-  set lispbin ** 
-  set lispfile ** 
-  set lispbinid ** 
-  set lispfileid ** 
-  foreach ID $args { 
-scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* Unit type name 
-switch $type { 
-  executable { 
-    set lispbinid $ID 
-    set lispbin [stepinputinfo -p $ID] 
-  } 
-} 
-switch $name { 
-CCL_lelisp.ll { 
-set lispfileid $ID 
-set lispfile [stepinputinfo -p $ID] 
-} 
-} 
-} 
-if { $lispfile == **} { 
-set lispfileid *CCLKernel:source:CCL_lelisp.ll*; 
-set lispfile [woklocate -p $lispfileid $workbench] 
-} 
-if { $lispbin == **} { 
-msgprint -e -c *CCLKernel_core\::Execute* *Cannot find lelispbin in input* 
-return 1; 
-} 
-msgprint -i -c *CCLKernel_core\::Execute* *Using lelisp.bin at  * $lispbin 
-msgprint -i -c *CCLKernel_core\::Execute* 
-set config *[wokparam -e %Ilog_Home]/config* 
-set tmpdir [wokinfo -p sttmpdir:. $unit] 
-set output [wokinfo -p executable:. $unit] 
-set lelisppointbin [wokinfo -p executable:lelisp.bin $unit] 
-unlink -nocomplain $lelisppointbin 
-link -sym $lispbin $lelisppointbin 
-msgprint -i -c *CCLKernel_core\::Execute* *Setting Environment* 
-set WOK_GLOBALS(setenv_proc,tcl) 1 
-wokenv -s 
-set WOK_GLOBALS(setenv_proc,tcl) 0 
-set olddir [pwd] 
-cd [wokinfo -p source:. $unit] 
-set FrontSIZE *-stack 12 -code 1500 -heap 2048 -number 0 -vector 32 -string 50 -symbol 30 -float 0 -cons  * 
-msgprint -i -c *CCLKernel_core\::Execute* *Exec : $config $tmpdir $lispbin $lispfile $output $FrontSIZE 8* 
-puts *exec /bin/env \\ 
-COREDIR=$output \\ 
-WBPACKAGE=[wokinfo -n $unit] ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\ 
-CSF_EngineStarterList=/usr/local/etc/ 
-EngineStarter.Hosts \\ 
-ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\ 
-\*FrontSIZE=$FrontSIZE\* \\ 
-$config $tmpdir $lispbin $lispfile $output $FrontSIZE 8* 
-msgprint -i -c *CCLKernel_core\::Execute* [eval *exec /bin/env \\ 
-  COREDIR=$output \\ 
-  WBPACKAGE=[wokinfo -n $unit] \\ 
-  ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\ 
-  CSF_EngineStarterList=/usr/local/etc/ EngineStarter.Hosts \\ 
-  \*FrontSIZE=$FrontSIZE\* \\ 
-$config $tmpdir $lispbin $lispfile $output $FrontSIZE 8*] 
-  stepoutputadd -P $unitname:corelisp:$unitname.core 
-  stepaddexecdepitem -d $lispbinid 
-$unitname:corelisp:$unitname.core 
-  stepaddexecdepitem -d $lispfileid 
-$unitname:corelisp:$unitname.core 
-  cd $olddir 
-  return 0; 
-}
-~~~~~
\ No newline at end of file
index c54601a..0fc61a4 100644 (file)
@@ -15,7 +15,7 @@ set "TCL_EXEC=tclsh.exe"
 for %%X in (%TCL_EXEC%) do (set TCL_FOUND=%%~$PATH:X)
 
 if defined TCL_FOUND (
-  %TCL_EXEC% %~dp0adm/start.tcl  %*
+  %TCL_EXEC% %~dp0adm/start.tcl gendoc %*
 ) else (
   echo "Error. %TCL_EXEC% is not found. Please update PATH variable"
 )
index ab7d259..0610af6 100644 (file)
@@ -5,15 +5,26 @@ rem Running it requires that Tcl should be in the PATH
 
 SET "OLD_PATH=%PATH%"
 
+if exist "%~dp0env.bat" (
+  call "%~dp0env.bat"
+)
+
+set "TCL_EXEC=tclsh.exe"
+
+for %%X in (%TCL_EXEC%) do (set TCL_FOUND=%%~$PATH:X)
+
+if not defined TCL_FOUND (
+  echo "Error. %TCL_EXEC% is not found. Please update PATH variable"
+  goto :eof
+)
+
 if not exist "%~dp0custom.bat" (
-  tclsh.exe ./adm/genconf.tcl
+  %TCL_EXEC% %~dp0adm/genconf.tcl
 )
 
 if not exist "%~dp0custom.bat" (
-  echo custom.bat is not created. Run the script again and generate custom.bat
+  echo custom.bat is not created. Run the script again or create custom.bat manually
   goto :eof
-) else (
-  call "%~dp0custom.bat"
 )
 
 if exist "%~dp0env.bat" (
@@ -21,5 +32,5 @@ if exist "%~dp0env.bat" (
 )
 
 cd %~dp0
-tclsh.exe ./adm/genproj.tcl -path=. -target=%VCVER% 
+%TCL_EXEC% %~dp0adm/start.tcl genproj -path=. -target=%VCVER%
 SET "PATH=%OLD_PATH%"
index 1305364..4923873 100644 (file)
 #include <gp_Elips2d.hxx>
 #include <gp_Hypr2d.hxx>
 #include <gp_Parab2d.hxx>
-class Standard_OutOfRange;
-class Standard_NoSuchObject;
-class Standard_DomainError;
-class Standard_NotImplemented;
+#include <Geom2d_BezierCurve.hxx>
+#include <Geom2d_BSplineCurve.hxx>
+
 class Adaptor2d_Curve2d;
 class gp_Pnt2d;
 class gp_Vec2d;
-class Geom2d_BezierCurve;
-class Geom2d_BSplineCurve;
 
 
 class Adaptor2d_HCurve2d;
@@ -122,27 +119,9 @@ public:
     virtual Handle(Geom2d_BSplineCurve) BSpline() const;
 
 
-
-
   DEFINE_STANDARD_RTTI(Adaptor2d_HCurve2d,MMgt_TShared)
-
-protected:
-
-
-
-
-private:
-
-
-
-
 };
 
-
 #include <Adaptor2d_HCurve2d.lxx>
 
-
-
-
-
 #endif // _Adaptor2d_HCurve2d_HeaderFile
index a215fcd..2109447 100644 (file)
 #include <Standard_DefineAlloc.hxx>
 #include <Standard_Handle.hxx>
 
-#include <Standard_Boolean.hxx>
-#include <Standard_Real.hxx>
 #include <GeomAbs_Shape.hxx>
-#include <Standard_Integer.hxx>
-class Geom2d_BSplineCurve;
-class Adaptor2d_HCurve2d;
+#include <Geom2d_BSplineCurve.hxx>
 
+class Adaptor2d_HCurve2d;
 
 //! Makes  an  approximation  for  HCurve2d  from  Adaptor3d
 class Approx_Curve2d 
@@ -49,32 +46,14 @@ public:
   
   Standard_EXPORT Standard_Real MaxError2dV() const;
 
-
-
-
-protected:
-
-
-
-
-
 private:
 
-
-
   Handle(Geom2d_BSplineCurve) myCurve;
   Standard_Boolean myIsDone;
   Standard_Boolean myHasResult;
   Standard_Real myMaxError2dU;
   Standard_Real myMaxError2dV;
 
-
 };
 
-
-
-
-
-
-
 #endif // _Approx_Curve2d_HeaderFile
index 170b233..359bf42 100644 (file)
 #include <Standard_DefineAlloc.hxx>
 #include <Standard_Handle.hxx>
 
-#include <Standard_Boolean.hxx>
-#include <Standard_Real.hxx>
 #include <GeomAbs_Shape.hxx>
-#include <Standard_Integer.hxx>
-#include <Standard_OStream.hxx>
-class Geom_BSplineCurve;
-class Standard_OutOfRange;
-class Standard_ConstructionError;
-class Adaptor3d_HCurve;
-
+#include <Geom_BSplineCurve.hxx>
 
+class Adaptor3d_HCurve;
 
 class Approx_Curve3d 
 {
@@ -62,31 +55,13 @@ public:
   //! Print on the stream  o  information about the object
   Standard_EXPORT void Dump (Standard_OStream& o) const;
 
-
-
-
-protected:
-
-
-
-
-
 private:
 
-
-
   Standard_Boolean myIsDone;
   Standard_Boolean myHasResult;
   Handle(Geom_BSplineCurve) myBSplCurve;
   Standard_Real myMaxError;
 
-
 };
 
-
-
-
-
-
-
 #endif // _Approx_Curve3d_HeaderFile
index 03242eb..103e60b 100644 (file)
 #include <Standard_DefineAlloc.hxx>
 #include <Standard_Handle.hxx>
 
-#include <Standard_Boolean.hxx>
-#include <Standard_Real.hxx>
-#include <Standard_Integer.hxx>
 #include <GeomAbs_Shape.hxx>
-class Standard_NullObject;
-class Standard_NoSuchObject;
+#include <Geom_Surface.hxx>
+#include <Geom_Curve.hxx>
+#include <Geom2d_Curve.hxx>
+#include <gp_Pnt2d.hxx>
+#include <gp_Pnt.hxx>
+#include <Poly_Triangulation.hxx>
+#include <Poly_Polygon3D.hxx>
+#include <Poly_Polygon2D.hxx>
+#include <Poly_PolygonOnTriangulation.hxx>
+
 class TopoDS_Shape;
-class Geom_Surface;
 class TopoDS_Face;
 class TopLoc_Location;
-class Poly_Triangulation;
 class TopoDS_Edge;
-class Geom_Curve;
-class Poly_Polygon3D;
-class Geom2d_Curve;
-class Poly_Polygon2D;
-class Poly_PolygonOnTriangulation;
-class gp_Pnt2d;
-class gp_Pnt;
 class TopoDS_Vertex;
 
 
@@ -241,27 +237,6 @@ public:
   //! Returns the parameters of the vertex on the face.
   Standard_EXPORT static gp_Pnt2d Parameters (const TopoDS_Vertex& V, const TopoDS_Face& F);
 
-
-
-
-protected:
-
-
-
-
-
-private:
-
-
-
-
-
 };
 
-
-
-
-
-
-
 #endif // _BRep_Tool_HeaderFile
index 3c5e04c..7d4d45a 100644 (file)
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-#include <Standard_Boolean.hxx>
-class Geom_TrimmedCurve;
-class StdFail_NotDone;
+#include <Geom_TrimmedCurve.hxx>
+
 class gp_Circ;
 class gp_Pnt;
 class gp_Vec;
@@ -88,30 +86,12 @@ public:
   //! Returns the constructed arc of circle.
   //! Exceptions StdFail_NotDone if no arc of circle is constructed.
   Standard_EXPORT const Handle(Geom_TrimmedCurve)& Value() const;
-operator const Handle(Geom_TrimmedCurve)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_TrimmedCurve)& () const { return Value(); }
+  operator const Handle(Geom_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_TrimmedCurve) TheArc;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeArcOfCircle_HeaderFile
index ec56db4..6f1f302 100644 (file)
@@ -22,9 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-#include <Standard_Boolean.hxx>
-class Geom_TrimmedCurve;
+#include <Geom_TrimmedCurve.hxx>
+
 class StdFail_NotDone;
 class gp_Elips;
 class gp_Pnt;
@@ -65,30 +64,12 @@ public:
   
   //! Returns the constructed arc of ellipse.
   Standard_EXPORT const Handle(Geom_TrimmedCurve)& Value() const;
-operator const Handle(Geom_TrimmedCurve)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_TrimmedCurve)& () const { return Value(); }
+  operator const Handle(Geom_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_TrimmedCurve) TheArc;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeArcOfEllipse_HeaderFile
index e14795d..12263ad 100644 (file)
@@ -22,9 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-#include <Standard_Boolean.hxx>
-class Geom_TrimmedCurve;
+#include <Geom_TrimmedCurve.hxx>
+
 class StdFail_NotDone;
 class gp_Hypr;
 class gp_Pnt;
@@ -63,30 +62,13 @@ public:
   
   //! Returns the constructed arc of hyperbola.
   Standard_EXPORT const Handle(Geom_TrimmedCurve)& Value() const;
-operator const Handle(Geom_TrimmedCurve)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_TrimmedCurve)& () const { return Value(); }
+  operator const Handle(Geom_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_TrimmedCurve) TheArc;
-
-
 };
 
 
-
-
-
-
-
 #endif // _GC_MakeArcOfHyperbola_HeaderFile
index ba88b3e..34973ca 100644 (file)
@@ -22,9 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-#include <Standard_Boolean.hxx>
-class Geom_TrimmedCurve;
+#include <Geom_TrimmedCurve.hxx>
+
 class StdFail_NotDone;
 class gp_Parab;
 class gp_Pnt;
@@ -60,30 +59,12 @@ public:
   
   //! Returns the constructed arc of parabola.
   Standard_EXPORT const Handle(Geom_TrimmedCurve)& Value() const;
-operator const Handle(Geom_TrimmedCurve)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_TrimmedCurve)& () const { return Value(); }
+  operator const Handle(Geom_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_TrimmedCurve) TheArc;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeArcOfParabola_HeaderFile
index cd8d26e..77915cc 100644 (file)
@@ -22,8 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-class Geom_Circle;
+#include <Geom_Circle.hxx>
+
 class StdFail_NotDone;
 class gp_Circ;
 class gp_Ax2;
@@ -99,30 +99,12 @@ public:
   //! Exceptions
   //! StdFail_NotDone if no circle is constructed.
   Standard_EXPORT const Handle(Geom_Circle)& Value() const;
-operator const Handle(Geom_Circle)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_Circle)& () const { return Value(); }
+  operator const Handle(Geom_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_Circle) TheCircle;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeCircle_HeaderFile
index e81c786..82477d8 100644 (file)
@@ -22,8 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-class Geom_ConicalSurface;
+#include <Geom_ConicalSurface.hxx>
+
 class StdFail_NotDone;
 class gp_Ax2;
 class gp_Cone;
@@ -123,30 +123,12 @@ public:
   //! Exceptions
   //! StdFail_NotDone if no cone is constructed.
   Standard_EXPORT const Handle(Geom_ConicalSurface)& Value() const;
-operator const Handle(Geom_ConicalSurface)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_ConicalSurface)& () const { return Value(); }
+  operator const Handle(Geom_Surface)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_ConicalSurface) TheCone;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeConicalSurface_HeaderFile
index 65e5226..ba0f3d8 100644 (file)
@@ -22,8 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-class Geom_CylindricalSurface;
+#include <Geom_CylindricalSurface.hxx>
+
 class StdFail_NotDone;
 class gp_Ax2;
 class gp_Cylinder;
@@ -111,30 +111,12 @@ public:
   //! Returns the constructed cylinder.
   //! Exceptions StdFail_NotDone if no cylinder is constructed.
   Standard_EXPORT const Handle(Geom_CylindricalSurface)& Value() const;
-operator const Handle(Geom_CylindricalSurface)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_CylindricalSurface)& () const { return Value(); }
+  operator const Handle(Geom_Surface)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_CylindricalSurface) TheCylinder;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeCylindricalSurface_HeaderFile
index 7517bda..4e201dc 100644 (file)
@@ -22,8 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-class Geom_Ellipse;
+#include <Geom_Ellipse.hxx>
+
 class StdFail_NotDone;
 class gp_Elips;
 class gp_Ax2;
@@ -77,30 +77,12 @@ public:
   //! Returns the constructed ellipse.
   //! Exceptions StdFail_NotDone if no ellipse is constructed.
   Standard_EXPORT const Handle(Geom_Ellipse)& Value() const;
-operator const Handle(Geom_Ellipse)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_Ellipse)& () const { return Value(); }
+  operator const Handle(Geom_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_Ellipse) TheEllipse;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeEllipse_HeaderFile
index 7a43122..6bdf8bf 100644 (file)
@@ -22,8 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-class Geom_Hyperbola;
+#include <Geom_Hyperbola.hxx>
+
 class StdFail_NotDone;
 class gp_Hypr;
 class gp_Ax2;
@@ -87,30 +87,12 @@ public:
   //! Returns the constructed hyperbola.
   //! Exceptions StdFail_NotDone if no hyperbola is constructed.
   Standard_EXPORT const Handle(Geom_Hyperbola)& Value() const;
-operator const Handle(Geom_Hyperbola)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_Hyperbola)& () const { return Value(); }
+  operator const Handle(Geom_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_Hyperbola) TheHyperbola;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeHyperbola_HeaderFile
index 7cb98c0..6cdf3a1 100644 (file)
@@ -22,7 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-class Geom_Line;
+#include <Geom_Line.hxx>
+
 class StdFail_NotDone;
 class gp_Ax1;
 class gp_Lin;
@@ -75,30 +76,12 @@ public:
   //! Returns the constructed line.
   //! Exceptions StdFail_NotDone if no line is constructed.
   Standard_EXPORT const Handle(Geom_Line)& Value() const;
-operator const Handle(Geom_Line)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_Line)& () const { return Value(); }
+  operator const Handle(Geom_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_Line) TheLine;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeLine_HeaderFile
index bfee277..dfe2339 100644 (file)
@@ -22,8 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-class Geom_Plane;
+#include <Geom_Plane.hxx>
+
 class StdFail_NotDone;
 class gp_Ax2;
 class gp_Pln;
@@ -100,30 +100,12 @@ public:
   //! Returns the constructed plane.
   //! Exceptions StdFail_NotDone if no plane is constructed.
   Standard_EXPORT const Handle(Geom_Plane)& Value() const;
-operator const Handle(Geom_Plane)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_Plane)& () const { return Value(); }
+  operator const Handle(Geom_Surface)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_Plane) ThePlane;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakePlane_HeaderFile
index d6596b9..1f92723 100644 (file)
@@ -22,8 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-class Geom_TrimmedCurve;
+#include <Geom_TrimmedCurve.hxx>
+
 class StdFail_NotDone;
 class gp_Pnt;
 class gp_Lin;
@@ -66,30 +66,12 @@ public:
   
   //! Returns the constructed line segment.
   Standard_EXPORT const Handle(Geom_TrimmedCurve)& Value() const;
-operator const Handle(Geom_TrimmedCurve)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_TrimmedCurve)& () const { return Value(); }
+  operator const Handle(Geom_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_TrimmedCurve) TheSegment;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeSegment_HeaderFile
index 6193d93..6548308 100644 (file)
@@ -22,8 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-class Geom_RectangularTrimmedSurface;
+#include <Geom_RectangularTrimmedSurface.hxx>
+
 class StdFail_NotDone;
 class gp_Pnt;
 
@@ -75,30 +75,12 @@ public:
   //! Returns the constructed trimmed cone.
   //! StdFail_NotDone if no trimmed cone is constructed.
   Standard_EXPORT const Handle(Geom_RectangularTrimmedSurface)& Value() const;
-operator const Handle(Geom_RectangularTrimmedSurface)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_RectangularTrimmedSurface)& () const { return Value(); }
+  operator const Handle(Geom_Surface)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_RectangularTrimmedSurface) TheCone;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeTrimmedCone_HeaderFile
index 6027119..437aa80 100644 (file)
@@ -22,8 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GC_Root.hxx>
-#include <Standard_Real.hxx>
-class Geom_RectangularTrimmedSurface;
+#include <Geom_RectangularTrimmedSurface.hxx>
+
 class StdFail_NotDone;
 class gp_Pnt;
 class gp_Circ;
@@ -93,30 +93,12 @@ public:
   //! Exceptions
   //! StdFail_NotDone if no trimmed cylinder is constructed.
   Standard_EXPORT const Handle(Geom_RectangularTrimmedSurface)& Value() const;
-operator const Handle(Geom_RectangularTrimmedSurface)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom_RectangularTrimmedSurface)& () const { return Value(); }
+  operator const Handle(Geom_Surface)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom_RectangularTrimmedSurface) TheCyl;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GC_MakeTrimmedCylinder_HeaderFile
index fa8c452..34ca3ef 100644 (file)
@@ -22,9 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GCE2d_Root.hxx>
-#include <Standard_Real.hxx>
-#include <Standard_Boolean.hxx>
-class Geom2d_TrimmedCurve;
+#include <Geom2d_TrimmedCurve.hxx>
+
 class StdFail_NotDone;
 class gp_Circ2d;
 class gp_Pnt2d;
@@ -73,30 +72,12 @@ public:
   //! Returns the constructed arc of circle.
   //! Exceptions StdFail_NotDone if no arc of circle is constructed.
   Standard_EXPORT const Handle(Geom2d_TrimmedCurve)& Value() const;
-operator const Handle(Geom2d_TrimmedCurve)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom2d_TrimmedCurve)& () const { return Value(); }
+  operator const Handle(Geom2d_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom2d_TrimmedCurve) TheArc;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GCE2d_MakeArcOfCircle_HeaderFile
index f517dc2..a2c8fd2 100644 (file)
@@ -22,9 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GCE2d_Root.hxx>
-#include <Standard_Real.hxx>
-#include <Standard_Boolean.hxx>
-class Geom2d_TrimmedCurve;
+#include <Geom2d_TrimmedCurve.hxx>
+
 class StdFail_NotDone;
 class gp_Elips2d;
 class gp_Pnt2d;
@@ -65,30 +64,12 @@ public:
   
   //! Returns the constructed arc of ellipse.
   Standard_EXPORT const Handle(Geom2d_TrimmedCurve)& Value() const;
-operator const Handle(Geom2d_TrimmedCurve)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom2d_TrimmedCurve)& () const { return Value(); }
+  operator const Handle(Geom2d_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom2d_TrimmedCurve) TheArc;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GCE2d_MakeArcOfEllipse_HeaderFile
index e6475c0..2393933 100644 (file)
@@ -22,9 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GCE2d_Root.hxx>
-#include <Standard_Real.hxx>
-#include <Standard_Boolean.hxx>
-class Geom2d_TrimmedCurve;
+#include <Geom2d_TrimmedCurve.hxx>
+
 class StdFail_NotDone;
 class gp_Hypr2d;
 class gp_Pnt2d;
@@ -64,30 +63,12 @@ public:
   
   //! Returns the constructed arc of hyperbola.
   Standard_EXPORT const Handle(Geom2d_TrimmedCurve)& Value() const;
-operator const Handle(Geom2d_TrimmedCurve)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom2d_TrimmedCurve)& () const { return Value(); }
+  operator const Handle(Geom2d_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom2d_TrimmedCurve) TheArc;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GCE2d_MakeArcOfHyperbola_HeaderFile
index 37ab96b..854f103 100644 (file)
@@ -22,9 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GCE2d_Root.hxx>
-#include <Standard_Real.hxx>
-#include <Standard_Boolean.hxx>
-class Geom2d_TrimmedCurve;
+#include <Geom2d_TrimmedCurve.hxx>
+
 class StdFail_NotDone;
 class gp_Parab2d;
 class gp_Pnt2d;
@@ -64,30 +63,12 @@ public:
   
   //! Returns the constructed arc of parabola.
   Standard_EXPORT const Handle(Geom2d_TrimmedCurve)& Value() const;
-operator const Handle(Geom2d_TrimmedCurve)& () const { return Value(); }
-
-
-
-
-protected:
-
-
-
 
+  operator const Handle(Geom2d_TrimmedCurve)& () const { return Value(); }
+  operator const Handle(Geom2d_Curve)& () const { return Value(); }
 
 private:
-
-
-
   Handle(Geom2d_TrimmedCurve) TheArc;
-
-
 };
 
-
-
-
-
-
-
 #endif // _GCE2d_MakeArcOfParabola_HeaderFile
index d3428d6..d51dcaa 100644 (file)
@@ -22,9 +22,8 @@
 #include <Standard_Handle.hxx>
 
 #include <GCE2d_Root.hxx>
-#include <Standard_Real.hxx>
-#include <Standard_Boolean.hxx>
-class Geom2d_Circle;
+#include <Geom2d_Circle.hxx>
+
 class StdFail_NotDone;
 class gp_Circ2d;
 class gp_Ax2d;
@@ -102,30 +101,12 @@ public:
   //! Returns the constructed circle.
   //! Exceptions StdFail_NotDone if no circle is constructed.
   Standard_EXPORT const Handle(Geom2d_Circle)& Value() const;
-operator const Handle(Geom2d_C