ACE's popularity is growing by the day it seems, and with the increased popularity, it's becoming more common for multiple applications on a system to require ACE. This can cause problems because

• Different ACE releases can have API differences
• Rebuilding ACE with a different compiler version can change the name mangling
• Some applications may require different features or settings than others

Beginning with ACE 5.5, there is a new feature designed to help alleviate these difficulties. The ACE Namespace Versioning provides a means for ACE-based application developers to avoid symbol conflicts by using versioned namespaces. This is an optional feature and its default setting is off (disabled) equivalent to all prior versions of ACE. When enabled, ACE's versioned namespace support causes all ACE symbols (classes, free functions, etc.) to be placed within a C++ namespace of the form namespace ACE_<ACE-version>. For example, at ACE 5.5, the default namespace name is ACE_5_5_0. The ACE_Reactor would end up being placed in the versioned namespace like this:

       namespace ACE_5_5_0
       {
         class ACE_Reactor
         {
           ...
         };
       }
       using namespace ACE_5_5_0;

Users may change the namespace name used in this mechanism by defining the ACE_VERSIONED_NAMESPACE_NAME macro in the ace/config.h file before building ACE.

Every effort has been made to make the versioned namespace support in ACE as transparent as possible, including transparent versioned symbol support in the ACE Service Configurator framework when the standard service-related macros (e.g., ACE_FACTORY_DECLARE) are used appropriately. No changes to service configurator directives are necessary. For example, the Service Configurator will transparently mangle the factory function name in a service configurator directive on the fly, meaning it will only load a "versioned" factory function name. This allows multiple service object factory functions, for example, to coexist in the same process space. For more information on the ACE Service Configurator framework, see chapter 5 in C++NPv2 and chapter 19 in APG.

There is, however, at least one caveat with respect to source code compatibility: any forward declarations of ACE symbols must also be placed within the versioned namespace. For example, if you have a forward declaration for ACE_Reactor in your application code, you will need to place it within the configured ACE versioned namespace as follows:

        ACE_BEGIN_VERSIONED_NAMESPACE_DECL
        class ACE_Reactor;
        ACE_END_VERSIONED_NAMESPACE_DECL

        namespace Foo = ACE_VERSIONED_NAMESPACE_NAME;
        namespace Foo {
          class ACE_Reactor;
        }
        using namespace Foo;

Versioned namespace support in ACE may be enabled by adding versioned_namespace=1 to your MPC default.features file and regenerating ACE's project/makefiles. Alternately, you can add the macro setting:

#define ACE_HAS_VERSIONED_NAMESPACE=1

This is a very handy feature to have when developing and deploying ACE-based applications. As with all new features, questions arise about how to best make use of this feature. ACE Annual Support customers can always enter a support request or call and talk through your questions. We're here to help!

To ensure that we're devoting resources to the ACE platforms that matter to our loyal customers, we recently surveyed the technical support contacts at all of our ACE Annual Support customers. We very much appreciate the time taken to complete this important survey! Based on the results, we're planning to make some minor changes to the set of computing platforms for which Riverace supports ACE.

First, an interesting statistic on ACE version usage. 80% of those responding to the survey are using ACE 5.4, and 52% are using ACE 5.5. ACE 5.5 is off to a great start, no doubt spurred by support for the new platforms added for the ACE 5.5 release. We are very grateful to the customers who sponsored the new platforms' porting and qualification.

Here are the planned changes in ACE platform support:

1. HP-UX 11.00 using g++ will be removed from support on all current and future ACE versions, effective April 1, 2006. This is the only platform with no reported usage in our survey.
2. ACE 5.5 is the last ACE version to support HP-UX 11.00. Hewlett-Packard discontinued HP-UX 11.00 on January 31, 2005. HP intends to end support for HP-UX 11.00 on December 31, 2006. Furthermore, HP stopped providing updated aC++ versions for HP-UX 11.00 after the A.03.56 update, and future ACE versions will require the functionality of the newer HP compilers available only on HP-UX 11i. For more information on HP's plans for HP-UX 11.00 and other OS versions, please see: http://www.hp.com/softwarereleases/releases-media2/history/slide2.html.
3. ACE 5.5 is the last ACE version to support the Sun Forte 7 compiler. Forte 7's inability to completely build ACE with implicit template support is the main issue in this decision. Future versions of ACE will require implicit template instantiation and this precludes Forte 7.
4. ACE 5.5 is the last ACE version to support the Microsoft Visual C++ 6 compiler. The MSVC6 compiler has too many shortcomings that restrict the coding strategies that can be employed in ACE; therefore, support for it will be removed from ACE during development towards ACE 6.0.

Note that Riverace's standard support policy is to support the current and previous ACE versions. This means that ACE 5.5 (including HP-UX 11.00, Sun Forte 7, and MSVC 6) will be supported until ACE 6.1 is released or March 6, 2007, whichever is later. This is based on the current plan that the next ACE release after ACE 5.5 will be ACE 6.0, followed by ACE 6.1.

Please contact Steve Huston with any questions about these platform change plans.

The ACE 5.5 source kit was recently released. Recent newsletters have briefly listed the highlights for the new ACE version including new platform support and new features. Once you've downloaded and expanded the kit, see the NEWS file for the highlights and the ChangeLog file for all the details!