mirror of
https://git.dev.opencascade.org/repos/occt.git
synced 2025-04-01 17:36:21 +03:00
Documentation - Update coding rules and formatting guidelines #379
This commit is contained in:
parent
20c7202089
commit
7f7e7df782
@ -12,54 +12,70 @@ The easiest way to install third-party libraries is to download archive with pre
|
||||
from [Development Portal](https://dev.opencascade.org/resources/download/3rd-party-components).
|
||||
You can also build third-party libraries from their sources, see @ref build_upgrade_building_3rdparty for instructions.
|
||||
|
||||
On Linux and macOS we recommend to use libraries maintained by distributive developers, when possible.
|
||||
On Linux and macOS we recommend using libraries maintained by distributive developers when possible.
|
||||
|
||||
@section build_occt_win_cmake Building with CMake tool
|
||||
@section build_requirements System Requirements
|
||||
|
||||
This chapter describes the [CMake](https://cmake.org/download/)-based build process, which is now suggested as a standard way to produce the binaries of Open CASCADE Technology from sources.
|
||||
OCCT requires CMake version 3.1 or later.
|
||||
* **CMake** version 3.10 or later (3.16+ recommended for precompiled headers support)
|
||||
* C++11 compliant compiler (required)
|
||||
* Supported platforms and compilers:
|
||||
* Windows:
|
||||
- Visual Studio 2015 or later
|
||||
- MinGW-w64 7.3 or later
|
||||
* Linux:
|
||||
- GCC 5.0 or later
|
||||
- Clang 3.8 or later
|
||||
* macOS:
|
||||
- Apple Clang 9.0 or later
|
||||
- Xcode 9.0 or later
|
||||
|
||||
CMake is a tool that generates the actual project files for the selected target build system (e.g. Unix makefiles) or IDE (e.g. Visual Studio 2010).
|
||||
Here we describe the build procedure on the example of Windows platform with Visual Studio 2010.
|
||||
@section build_occt_cmake Building with CMake
|
||||
|
||||
This chapter describes the [CMake](https://cmake.org/download/)-based build process, which is the standard way to produce OCCT binaries from sources.
|
||||
|
||||
CMake is a tool that generates project files for the selected target build system (e.g. Unix makefiles) or IDE (e.g. Visual Studio).
|
||||
Here we describe the build procedure using Windows platform with Visual Studio as an example.
|
||||
However, CMake is cross-platform and can be used to build OCCT on Linux and macOS in essentially the same way.
|
||||
|
||||
CMake deals with three directories: source, build or binary and installation.
|
||||
|
||||
* The source directory is where the sources of OCCT are located in your file system;
|
||||
* The build or binary directory is where all files created during CMake configuration and generation process will be located. The mentioned process will be described below.
|
||||
* The installation directory is where binaries will be installed after building the *INSTALL* project that is created by CMake generation process, along with header files and resources required for OCCT use in applications.
|
||||
* The build or binary directory is where all files created during CMake configuration and generation process will be located;
|
||||
* The installation directory is where binaries will be installed after building the *INSTALL* project, along with header files and resources required for OCCT use in applications.
|
||||
|
||||
The good practice is not to use the source directory as a build one.
|
||||
Different configurations should be built in different build directories to avoid conflicts.
|
||||
It is however possible to choose one installation directory for several configurations of OCCT (differentiated by platform, bitness, compiler and build type), for example:
|
||||
Different configurations should be built in different build directories to avoid conflicts.
|
||||
For example:
|
||||
|
||||
d:/occt/ - the source directory
|
||||
d:/tmp/occt-build-vc10-x64 - the build directory with the generated
|
||||
d:/tmp/occt-build-vc14-x64 - the build directory with the generated
|
||||
solution and other intermediate files created during a CMake tool working
|
||||
d:/occt-install - the installation directory that is
|
||||
able to contain several OCCT configurations
|
||||
d:/occt-install - the installation directory that can
|
||||
contain several OCCT configurations
|
||||
|
||||
@subsection build_cmake_conf Configuration process
|
||||
|
||||
For unexperienced users we recommend to start with *cmake-gui* -- a cross-platform GUI tool provided by CMake on Windows, Mac and Linux.
|
||||
For inexperienced users we recommend starting with *cmake-gui* -- a cross-platform GUI tool provided by CMake on Windows, Mac and Linux.
|
||||
A command-line alternative, *ccmake* can also be used.
|
||||
|
||||
If the command-line tool is used, run the tool from the build directory with a single argument indicating the source (relative or absolute path) directory, and press *c* to configure:
|
||||
If the command-line tool is used, run it from the build directory with a single argument indicating the source directory:
|
||||
|
||||
cd d:/tmp/occt-build-vc10-x64
|
||||
cd d:/tmp/occt-build-vc14-x64
|
||||
ccmake d:/occt
|
||||
|
||||
Then press *c* to configure.
|
||||
|
||||
@figure{/build/build_occt/images/cmake_image000.png}
|
||||
|
||||
If the GUI tool is used, run this tool without additional arguments and after that specify the source directory by clicking **Browse Source** and the build (binary) one by clicking **Browse Build**:
|
||||
If the GUI tool is used, run this tool without additional arguments and specify the source directory by clicking **Browse Source** and the build directory by clicking **Browse Build**:
|
||||
|
||||
@figure{/build/build_occt/images/cmake_image001.png}
|
||||
|
||||
@note Each configuration of the project should be built in its own directory.
|
||||
When building multiple configurations it is suggested to indicate in the name of build directories the system, bitness and compiler (e.g., <i>d:/occt/build/win32-vc10</i>).
|
||||
When building multiple configurations it is suggested to indicate in the name of build directories the system, bitness and compiler (e.g., <i>d:/occt/build/win32-vc14</i>).
|
||||
|
||||
Once the source and build directories are selected, "Configure" button should be pressed in order to start manual configuration process.
|
||||
It begins with selection of a target configurator. It is "Visual Studio 10 2010 Win64" in our example.
|
||||
It begins with selection of a target configurator. It is "Visual Studio 14 2015 Win64" in our example.
|
||||
|
||||
@figure{/build/build_occt/images/cmake_image002.png}
|
||||
|
||||
@ -86,24 +102,29 @@ The following table gives the full list of environment variables used at the con
|
||||
| Variable | Type | Purpose |
|
||||
|----------|------|---------|
|
||||
| CMAKE_BUILD_TYPE | String | Specifies the build type on single-configuration generators (such as make). Possible values are Debug, Release and RelWithDebInfo |
|
||||
| USE_FREETYPE | Boolean | Indicates whether FreeType product should be used in OCCT for text rendering |
|
||||
| USE_FREEIMAGE | Boolean | Indicates whether FreeImage product should be used in OCCT visualization module for support of popular graphics image formats (PNG, BMP, etc.) |
|
||||
| USE_OPENVR | Boolean | Indicates whether OpenVR product should be used in OCCT visualization module for support of Virtual Reality |
|
||||
| USE_OPENGL | Boolean | Indicates whether TKOpenGl graphic driver using OpenGL library (desktop) should be built within OCCT visualization module |
|
||||
| USE_GLES2 | Boolean | Indicates whether TKOpenGles graphic driver using OpenGL ES library (embedded OpenGL) should be built within OCCT visualization module |
|
||||
| USE_RAPIDJSON | Boolean | Indicates whether RapidJSON product should be used in OCCT Data Exchange module for support of glTF mesh file format |
|
||||
| USE_DRACO | Boolean | Indicates whether Draco product should be used in OCCT Data Exchange module for support of Draco compression in glTF mesh file format |
|
||||
| USE_TK | Boolean | Indicates whether Tcl/Tk product should be used in OCCT Draw Harness module for user interface (in addition to Tcl, which is mandatory for Draw Harness) |
|
||||
| USE_TBB | Boolean | Indicates whether TBB (Threading Building Blocks) 3rd party is used or not. Note that OCCT remains parallel even without TBB product |
|
||||
| USE_VTK | Boolean | Indicates whether VTK 3rd party is used or not. OCCT comes with a bridge between CAD data representation and VTK by means of its dedicated VIS component (VTK Integration Services). You may skip this 3rd party unless you are planning to use VTK visualization for OCCT geometry. See the official documentation @ref occt_user_guides__vis for the details on VIS |
|
||||
| USE_FREETYPE | Boolean | Indicates whether FreeType product should be used in OCCT for text rendering |
|
||||
| USE_FREEIMAGE | Boolean | Indicates whether FreeImage product should be used in OCCT visualization module for support of popular graphics image formats |
|
||||
| USE_FFMPEG | Boolean | Indicates whether FFmpeg framework should be used for video encoding/decoding support |
|
||||
| USE_OPENVR | Boolean | Indicates whether OpenVR product should be used in OCCT visualization module for VR support |
|
||||
| USE_OPENGL | Boolean | Indicates whether TKOpenGl graphic driver using OpenGL library (desktop) should be built |
|
||||
| USE_GLES2 | Boolean | Indicates whether TKOpenGles graphic driver using OpenGL ES library should be built |
|
||||
| USE_RAPIDJSON | Boolean | Indicates whether RapidJSON product should be used for JSON format support |
|
||||
| USE_DRACO | Boolean | Indicates whether Draco mesh compression library should be used |
|
||||
| USE_TK | Boolean | Indicates whether Tcl/Tk product should be used in Draw Harness for user interface |
|
||||
| USE_TBB | Boolean | Indicates whether TBB (Threading Building Blocks) should be used for parallel computations |
|
||||
| USE_VTK | Boolean | Indicates whether VTK bridge should be built |
|
||||
| BUILD_USE_PCH | Boolean | Enable/disable use of precompiled headers. Requires CMake 3.16 or later |
|
||||
| BUILD_USE_VCPKG | Boolean | Use vcpkg for managing third-party dependencies |
|
||||
| BUILD_INCLUDE_SYMLINK | Boolean | Use symbolic links instead of copies for header files in build directory |
|
||||
| BUILD_MODULE_<MODULE>| Boolean | Indicates whether the corresponding OCCT module should be built |
|
||||
| BUILD_LIBRARY_TYPE | String | Specifies library type ("Shared" or "Static") |
|
||||
| BUILD_CPP_STANDARD | String | Select C++ standard (C++11, C++14, C++17, C++20, C++23) |
|
||||
| 3RDPARTY_DIR | Path | Defines the root directory where all required 3rd party products will be searched. Once you define this path it is very convenient to click "Configure" button in order to let CMake automatically detect all necessary products|
|
||||
| 3RDPARTY_FREETYPE_* | Path | Path to FreeType binaries |
|
||||
| 3RDPARTY_TCL_* 3RDPARTY_TK_* | Path | Path to Tcl/Tk binaries |
|
||||
| 3RDPARTY_FREEIMAGE* | Path | Path to FreeImage binaries |
|
||||
| 3RDPARTY_TBB* | Path | Path to TBB binaries |
|
||||
| 3RDPARTY_VTK_* | Path | Path to VTK binaries |
|
||||
| BUILD_MODULE_<MODULE>| Boolean | Indicates whether the corresponding OCCT module should be built or not. It should be noted that some toolkits of a module can be built even if this module is not checked (this happens if some other modules depend on these toolkits). The main modules and their descriptions can be found in @ref user_guides |
|
||||
| BUILD_LIBRARY_TYPE | String | Specifies the type of library to be created. "Shared" libraries are linked dynamically and loaded at runtime. "Static" libraries are archives of object files used when linking other targets. Note that Draw Harness plugin system is incompatible with "Static" builds, and therefore it is disabled for these builds.|
|
||||
| BUILD_ADDITIONAL_TOOLKITS | String | Semicolon-separated individual toolkits to include into build process. If you want to build some particular libraries (toolkits) only, then you may uncheck all modules in the corresponding *BUILD_MODUE_\<MODULE\>* options and provide the list of necessary libraries here. Of course, all dependencies will be resolved automatically |
|
||||
| BUILD_YACCLEX | Boolean | Enables Flex/Bison lexical analyzers. OCCT source files relating to STEP reader and ExprIntrp functionality are generated automatically with Flex/Bison. Checking this option leads to automatic search of Flex/Bison binaries and regeneration of the mentioned files |
|
||||
| BUILD_SAMPLES_MFC | Boolean | Indicates whether MFC samples should be built together with OCCT. This option is only relevant to Windows platforms |
|
||||
@ -113,7 +134,6 @@ The following table gives the full list of environment variables used at the con
|
||||
| BUILD_PATCH | Path | Points to the directory recognized as a "patch" for OCCT. If specified, the files from this directory take precedence over the corresponding native OCCT sources. This way you are able to introduce patches to Open CASCADE Technology not affecting the original source distribution |
|
||||
| BUILD_WITH_DEBUG | Boolean | Enables extended messages of many OCCT algorithms, usually printed to cout. These include messages on internal errors and special cases encountered, timing, etc. |
|
||||
| BUILD_ENABLE_FPE_SIGNAL_HANDLER | Boolean | Enable/Disable the floating point exceptions (FPE) during DRAW execution only. Corresponding environment variable (CSF_FPE) can be changed manually in custom.bat/sh scripts without regeneration by CMake. |
|
||||
| BUILD_CPP_STANDARD | String | Employ corresponding c++ standard (C++11, C++14, ..C++23) for building OCCT |
|
||||
| CMAKE_CONFIGURATION_TYPES | String | Semicolon-separated CMake configurations |
|
||||
| INSTALL_DIR | Path | Points to the installation directory. *INSTALL_DIR* is a synonym of *CMAKE_INSTALL_PREFIX*. The user can specify both *INSTALL_DIR* or *CMAKE_INSTALL_PREFIX* |
|
||||
| INSTALL_DIR_BIN | Path | Relative path to the binaries installation directory (absolute path is ${INSTALL_DIR}/${INSTALL_DIR_BIN}) |
|
||||
@ -211,7 +231,7 @@ The directory structure is as follows:
|
||||
samples - samples
|
||||
src - all required source files for OCCT
|
||||
tests - OCCT test suite
|
||||
win32\vc10\bind - binary files (installed 3rdparties and occt)
|
||||
win32\vc14\bind - binary files (installed 3rdparties and occt)
|
||||
\libd - libraries (installed 3rdparties and occt)
|
||||
|
||||
@note The above example is given for debug configuration.
|
||||
@ -219,7 +239,7 @@ However, it is generally safe to use the same installation directory for the rel
|
||||
In the latter case the contents of install directory will be enriched with subdirectories and files related to the release configuration.
|
||||
In particular, the binaries directory win64 will be expanded as follows:
|
||||
|
||||
\win32\vc10\bind
|
||||
\win32\vc14\bind
|
||||
\libd
|
||||
\bin
|
||||
\lib
|
||||
@ -235,10 +255,11 @@ This section describes the steps to build OCCT libraries for Android from a comp
|
||||
The steps on Windows 7 and Ubuntu 15.10 are similar. There is the only one difference: makefiles are built with mingw32-make on Windows and native GNU make on Ubuntu.
|
||||
|
||||
Required tools (download and install if it is required):
|
||||
- CMake 3.0+
|
||||
- [Cross-compilation toolchain for CMake](https://github.com/taka-no-me/android-cmake)
|
||||
- [Android NDK r12+](https://developer.android.com/ndk/downloads)
|
||||
- GNU Make: MinGW v4.82+ for [Windows](https://www.mingw-w64.org/), GNU Make 4.0 for Ubuntu.
|
||||
- CMake 3.10+ (3.16+ recommended)
|
||||
- Android NDK r19+
|
||||
- Android SDK API level 21+
|
||||
- For Windows: MinGW-w64 7.3+ or Visual Studio 2015+
|
||||
- For Linux/macOS: GNU Make 4.0+
|
||||
|
||||
Run GUI tool provided by CMake and:
|
||||
- Specify the root folder of OCCT (`$CASROOT`, which contains *CMakelists.txt* file) by clicking **Browse Source**.
|
||||
@ -263,9 +284,9 @@ specify `CMAKE_MAKE_PROGRAM` to mingw32-make executable.
|
||||
@figure{/build/build_occt/images/android_image005.png}
|
||||
|
||||
How to configure OCCT, see @ref build_cmake_conf "Configure" section taking into account the specific configuration variables for Android:
|
||||
- `ANDROID_ABI` = `armeabi-v7a`
|
||||
- `ANDROID_NATIVE_API_LEVEL` = `15`
|
||||
- `ANDROID_NDK_LAYOUT` is equal to `CMAKE_BUILD_TYPE` variable
|
||||
- `ANDROID_ABI` = `armeabi-v7a`, `arm64-v8a`, `x86`, or `x86_64`
|
||||
- `ANDROID_PLATFORM` = `android-21` (minimum supported API level)
|
||||
- `ANDROID_STL` = `c++_shared` (recommended)
|
||||
- `BUILD_MODULE_Draw` = `OFF`
|
||||
|
||||
@figure{/build/build_occt/images/android_image006.png}
|
||||
|
@ -233,13 +233,18 @@ void Average (const Standard_Real** theArray,
|
||||
|
||||
To improve the open source readability and, consequently, maintainability, the following set of rules is applied.
|
||||
|
||||
### Clang-format [MANDATORY]
|
||||
|
||||
The source code should be formatted using the clang-format tool with the configuration file provided in the OCCT repository.
|
||||
The version of clang-format should be 18.1.8 or higher.
|
||||
|
||||
### International language [MANDATORY]
|
||||
|
||||
All comments in all sources must be in English.
|
||||
|
||||
### Line length
|
||||
|
||||
Try to stay within the limit of 120 characters per line in all sources.
|
||||
Try to stay within the limit of 100 characters per line in all sources.
|
||||
|
||||
### C++ style comments
|
||||
|
||||
@ -254,49 +259,6 @@ Delete unused code instead of commenting it or using \#define.
|
||||
Indentation in all sources should be set to two space characters.
|
||||
Use of tabulation characters for indentation is disallowed.
|
||||
|
||||
### Separating spaces
|
||||
|
||||
Punctuation rules follow the rules of the English language.
|
||||
* C/C++ reserved words, commas, colons and semicolons should be followed by a space character if they are not at the end of a line.
|
||||
* There should be no space characters after '(' and before ')'. Closing and opening brackets should be separated by a space character.
|
||||
* For better readability it is also recommended to surround conventional operators by a space character.
|
||||
Examples:
|
||||
|
||||
~~~~{.cpp}
|
||||
while (true) // NOT: while( true ) ...
|
||||
{
|
||||
DoSomething (theA, theB, theC, theD); // NOT: DoSomething(theA,theB,theC,theD);
|
||||
}
|
||||
for (anIter = 0; anIter < 10; ++anIter) // NOT: for (anIter=0;anIter<10;++anIter){
|
||||
{
|
||||
theA = (theB + theC) * theD; // NOT: theA=(theB+theC)*theD
|
||||
}
|
||||
~~~~
|
||||
|
||||
### Declaration of pointers and references
|
||||
|
||||
In declarations of simple pointers and references put asterisk (*) or ampersand (&) right after the type without extra space.
|
||||
|
||||
Since declaration of several variables with mixed pointer types contrudicts this rule, it should be avoided. Instead, declare each variable independently with fully qualified type.
|
||||
|
||||
Examples:
|
||||
|
||||
~~~~{.cpp}
|
||||
Standard_Integer *theVariable; // not recommended
|
||||
Standard_Integer * theVariable; // not recommended
|
||||
Standard_Integer* theVariable; // this is OK
|
||||
|
||||
Standard_Integer *&theVariable; // not recommended
|
||||
Standard_Integer *& theVariable; // not recommended
|
||||
Standard_Integer*& theVariable; // this is OK
|
||||
|
||||
Standard_Integer **theVariable; // not recommended
|
||||
Standard_Integer ** theVariable; // not recommended
|
||||
Standard_Integer** theVariable; // this is OK
|
||||
|
||||
Standard_Integer *theA, theB, **theC; // not recommended (declare each variable independently)
|
||||
~~~~
|
||||
|
||||
### Separate logical blocks
|
||||
|
||||
Separate logical blocks of code with one blank line and comments.
|
||||
@ -330,19 +292,16 @@ Each descriptive block should contain at least a function name and purpose descr
|
||||
See the following example:
|
||||
|
||||
~~~~{.cpp}
|
||||
// =======================================================================
|
||||
// function : TellMeSmthGood
|
||||
// purpose : Gives me good news
|
||||
// =======================================================================
|
||||
|
||||
// ================================================================================================
|
||||
|
||||
void TellMeSmthGood()
|
||||
{
|
||||
...
|
||||
}
|
||||
|
||||
// =======================================================================
|
||||
// function : TellMeSmthBad
|
||||
// purpose : Gives me bad news
|
||||
// =======================================================================
|
||||
// ================================================================================================
|
||||
|
||||
void TellMeSmthBad()
|
||||
{
|
||||
...
|
||||
@ -400,23 +359,6 @@ if (THE_LIMIT == theValue) // bad style (global constant vs. variable)
|
||||
if (theValue == THE_LIMIT) // OK
|
||||
~~~~
|
||||
|
||||
### Alignment
|
||||
|
||||
Use alignment wherever it enhances the readability. See the following example:
|
||||
|
||||
~~~~{.cpp}
|
||||
MyPackage_MyClass anObject;
|
||||
Standard_Real aMinimum = 0.0;
|
||||
Standard_Integer aVal = theVal;
|
||||
switch (aVal)
|
||||
{
|
||||
case 0: computeSomething(); break;
|
||||
case 12: computeSomethingElse (aMinimum); break;
|
||||
case 3:
|
||||
default: computeSomethingElseYet(); break;
|
||||
}
|
||||
~~~~
|
||||
|
||||
### Indentation of comments
|
||||
|
||||
Comments should be indented in the same way as the code to which they refer or they can be in the same line if they are short.
|
||||
|
@ -7,7 +7,7 @@ Upgrade from older OCCT versions {#occt__upgrade}
|
||||
|
||||
This document provides technical details on changes made in particular versions of OCCT. It can help to upgrade user applications based on previous versions of OCCT to newer ones.
|
||||
|
||||
@ref upgrade_occt780 "SEEK TO THE LAST CHAPTER (UPGRADE TO 7.8.0)"
|
||||
@ref upgrade_occt790 "SEEK TO THE LAST CHAPTER (UPGRADE TO 7.9.0)"
|
||||
|
||||
@subsection upgrade_intro_precautions Precautions
|
||||
|
||||
@ -2409,3 +2409,77 @@ The most recommended manager is `JeMalloc`. To use it with a plugin system, like
|
||||
`BUILD_OPT_PROFILE` is a new variable to define optimization level. Available profiles:
|
||||
* `Default` - specializes only in quality-dependent parameters for the compiler.
|
||||
* `Production` - specializes in performance and quality-dependent parameters for the compiler and linker.
|
||||
|
||||
@section upgrade_occt790 Upgrade to OCCT 7.9.0
|
||||
|
||||
@subsection upgrade_790_code_formatting Code Formatting update
|
||||
|
||||
The entire code base has been formatted with `clang-format` 18.1.8 (Windows) using settings available in the root of the repository.
|
||||
Most custom patches on top of previous releases will likely have merge conflicts.
|
||||
When encountering merge conflicts, it is recommended to use `clang-format` to format the code.
|
||||
To maintain patches, it is recommended to merge them into the main repository as part of a contribution. See [Get Involved](https://dev.opencascade.org/get_involved) and [Contribution Guide](https://github.com/Open-Cascade-SAS/OCCT/discussions/36).
|
||||
|
||||
@subsection upgrade_790_migration Migration to GitHub
|
||||
|
||||
The OCCT repository has been migrated to GitHub. The new repository is available at [GitHub](https://github.com/Open-Cascade-SAS/OCCT).
|
||||
The old repository will be available for some time, but it is recommended to use the new repository for all new changes.
|
||||
Contribution to the new repository is available through the GitHub interface - see [Get Involved](https://dev.opencascade.org/get_involved) and [Contribution Guide](https://github.com/Open-Cascade-SAS/OCCT/discussions/36).
|
||||
|
||||
@subsection upgrade_790_configuration GenProj no longer supported
|
||||
|
||||
The `GenProj` tool is no longer supported. It is recommended to use CMake for building OCCT.
|
||||
In case of problems, please refer to the [CMake Guide](https://dev.opencascade.org/doc/overview/html/build_upgrade__building_occt.html).
|
||||
|
||||
@subsection upgrade_790_modeling_scale_exception Disabling exception for transformation with scale
|
||||
|
||||
The exception for transformation with scale has been disabled by default.
|
||||
These exceptions were enabled in OCCT 7.6.0 for all cases of applying a transformation on a `TopoDS_Shape` with scale or negative determinant.
|
||||
Now the exceptions are disabled by default but can be enabled by changing the parameter in the method which applies the transformation on `TopoDS_Shape`.
|
||||
|
||||
@subsection upgrade_790_de_wrapper Migration of DE_Wrapper classes
|
||||
|
||||
The DE Wrapper classes have been reorganized to follow a single style throughout the OCCT open source and commercial code.
|
||||
All DE formats starting from 7.8.0 were grouped into their own TKs with the `TKDE` prefix.
|
||||
Now all DE Wrapper interfaces have moved to their own package with the `DE` prefix.
|
||||
DE Wrapper classes follow the pattern: `DE<Format>_Parameters`, `DE<Format>_Provider`, and `DE<Format>_ConfigurationNode`.
|
||||
Example: `DESTEP_Parameters`, `DESTEP_Provider`, `DESTEP_ConfigurationNode`.
|
||||
|
||||
@subsection upgrade_790_de_shape_healing Migration of shape healing parameters
|
||||
|
||||
The shape healing parameters have migrated from the resource file to the DE interface.
|
||||
The previous implementation was based on the resource file or `Interface_Static`.
|
||||
Now the parameters are stored in the `DE_ShapeFixParameters` structure with the option to use a string-string map to store extra parameters.
|
||||
To use the previous interface, use code similar to:
|
||||
|
||||
~~~~{.cpp}
|
||||
STEPControl_Reader aReader;
|
||||
XSAlgo_ShapeProcessor::ProcessingData aProcessingData =
|
||||
XSAlgo_ShapeProcessor::ReadProcessingData("read.step.resource.name", "read.step.sequence");
|
||||
aReader.SetShapeFixParameters(std::move(aProcessingData.first));
|
||||
aReader.SetShapeProcessFlags(aProcessingData.second);
|
||||
~~~~
|
||||
|
||||
It is recommended to use the new interface to store parameters in the `DE_ShapeFixParameters` structure directly.
|
||||
|
||||
@subsection upgrade_790_de_interface_static Migration of DE parameters from Interface_Static
|
||||
|
||||
During transfer operations, all parameters that were stored in `Interface_Static` have moved to their own DE structure.
|
||||
The parameters are read only once during initialization and stored in the model.
|
||||
Parameters are now available as part of the DE Wrapper interface, for example: `DESTEP_Parameters`, `DEIGES_Parameters`.
|
||||
Code samples showing how to set the parameters can be found in `DESTEP_Provider` and `DEIGES_Provider`.
|
||||
|
||||
@subsection upgrade_790_general_handle_types Deprecated Handle types
|
||||
|
||||
The `Handle_*` type names have been deprecated in favor of directly using the macro.
|
||||
The `Handle_*` type names are still available, but it is recommended to use the macro directly.
|
||||
Example:
|
||||
|
||||
~~~~{.cpp}
|
||||
Handle(TDataStd_Application) anApp = new TDataStd_Application(); // recommended
|
||||
Handle_TDataStd_Application anApp = new TDataStd_Application(); // deprecated
|
||||
~~~~
|
||||
|
||||
@subsection upgrade_790_general_map NCollection_Map algorithm method migration
|
||||
|
||||
The `NCollection_Map` class has been reorganized to migrate extra methods to the `NCollection_MapAlgo` class.
|
||||
Boolean operations on maps are now available in the `NCollection_MapAlgo` class.
|
||||
|
Loading…
x
Reference in New Issue
Block a user