Home > User Guide > Memory Management

Versioning within ACIS

Any change introduced within ACIS that fits one of the following criteria is versioned:

The following types of changes are not versioned (this list is not exhaustive) because ACIS does not guarantee their stability:

Versioning is intended to allow you to regenerate a part as if you were still running the version of the modeler used to create that part. However, versioning cannot not be used to make new modifications to a body, but only to reproduce the same result obtained before. Bugs fixes and changes in ACIS are only made to the latest algorithm. This means that by using the versioned API, you will not benefit from the latest enhancements.

Important Versioning Details

The ACIS product binaries contain information to identify its version. This version information consists of three numbers: a major, a minor, and a point number. A major release causes an increase in the major version, a minor release causes an increase in the minor version, and an ACIS service pack causes an increase in the point version. All ACIS releases are versioned and can be identified by these numbers. The ACIS 8.0 release, for example, has a major number of 8, a minor number of 0, and a point number of 0. For simplicity, these numbers are depicted with dot separation (for example, 8.0.0). The first service pack to the ACIS 8.0 release would consequently be identified as 8.0.1.

The purpose of the three-part ACIS versioning system is not only to identify the significance of the changes and enhancements of the product but also to provide expectations of the impact these changes can pose to you, the customer. Major releases signify significant changes to the product that could require changes in customer code in order to integrate the release. When these changes are significant, an update tool is delivered with the ACIS product to simplify source code modifications. Minor releases, not frequently shipped by Spatial, signify minor changes to the product that do not require changes in customer code, but could require a complete rebuild and re-link of the customer application in order to integrate the release. Point releases (Service Packs) signify minimal changes to the product that do not require any code changes, rebuilds, or re-links, in order to integrate the release.

While it is almost always the case that major and minor releases cause changes to the shape/topology of a model, Spatial service packs try as much as possible not to modify the topology or the shape of a model. However, it is possible that a specific bug fix introduces a topology/shape change in a service pack.

If your application depends on a specific version of ACIS (for shape/topology reasons), you can use ACIS versioning to target that version. However, note that once Spatial adds versioning because of a shape/topology change, no fixes are made to older versioned algorithms. Therefore, be aware that using ACIS versioning to target a specific version of ACIS prevents you from receiving the benefit of bug fixes in future service packs.

The current version of the ACIS product can be queried at runtime by calling the get_major_version(), get_minor_version(), and get_point_version() functions, which return the major, minor, and point version numbers respectively.

There is currently one API whose behavior is intentionally not versioned: api_check_entity. Therefore, customers should not use api_check_entitys results to determine the algorithmic flow of their application. Also, api_check_entitys performance is not guaranteed. Instead, api_check_entity is being continually refined to meet this simple goal: to provide the caller the most comprehensive verification of their model.

Specifying an ACIS Version for a Single API Call

Every ACIS API has an additional, optional parameter: AcisOptions *. This parameter allows the caller to control both how the API is journaled and how the API is versioned. Versioning an ACIS API may be done as follows:

// Run this api as ACIS 7.0
AcisOptions ao(AcisVersion(7,0,0));
api_do_something(<param1>, <param2>, ..., <paramN>, &ao);

The above logic will construct an AcisOptions object on the stack. It also creates a temporary AcisVersion object and passes it to the AcisOptions constructor. This is the easiest method of constructing an AcisOptions object that is set to a particular ACIS version. Here is an alternate method that is functionally equivalent:

// Run this api as ACIS 7.0
AcisOptions ao; ao.set_version(AcisVersion(7,0,0));
api_do_something(<param1>, <param2>, ..., <paramN>, &ao);

Alternate Methods of Versioning

Alternate methods of versioning in ACIS are discussed in the following sections:

ALGORITHMIC_VERSION_BLOCK

It is also possible to control the ACIS version for large blocks of code without having to pass an AcisOptions parameter to each API call. This is defined in base/baseutil/version/vers.hxx Consider the following example customer code:

void cust_func(void)
{
   outcome oc;
   oc = api_do_something(...);
   if (oc.ok())
   oc = api_do_something_else(...);
   cust_func2(. . .);
}

To run the above logic as ACIS 6.3, change the code as follows:

void cust_func(void)
{
   outcome oc;
{
//Run everything in the following block as ACIS 6.3.
// When this code  block is exited the version will revert
//to its original setting.
   ALGORITHMIC_VERSION_BLOCK(AcisVersion(6,3,0));
   oc =  api_do_something(...);
   if (oc.ok())
      oc = api_do_something_else(...);
   // Even ACIS calls  within cust_func2 will be run as ACIS 6.3.
   cust_func2(
             .
             .
             .
             );
}
}

ALGORITHMIC_VERSION_BLOCKs can also be nested. When a nested version block is exited, the ACIS version will be reverted to the version given by the next outermost version block. When all version blocks are exited, the default version is the current ACIS version.

API_VERS_BEGIN

API_VERS_BEGIN is a way to combine an API_BEGIN and ALGORITHMIC_VERSION_BLOCK in a single statement. An API_VERS_END should terminate the block. this is defined in: kern/kernel/kernapi/api/api.hxx The following logic:

API_BEGIN ALGORITHMIC_VERSION_BLOCK(AcisVersion(6,3,0));
// insert code here API_END

is equivalent to this logic:

AcisOptions ao(AcisVersion(6,3,0)); API_VERS_BEGIN(&ao);
// insert code here API_VERS_END

[Top]

© 1989-2007 Spatial Corp., a Dassault Systèmes company. All rights reserved.