The ACE_Message_Block class is one of the most useful and widely-used in ACE. It's central to many of ACE's most popular frameworks, including the Task, Stream, and Proactor frameworks. It's very efficient means for duplicating and chaining blocks make it a natural fit in many applications.

To make the most of ACE_Message_Block's features and understand it's fit in the rest of ACE, it's very important to understand how ACE_Message_Block maintains its records of how much valid data and free space are available in the block. To fully understand the various areas, it's important to review the concept of ACE_Message_Block's read and write pointers (rd_ptr and wr_ptr).

To make transport of data through various pieces of a networked application easier, ACE_Message_Block maintains a valid data area, delimited by the rd_ptr and wr_ptr. When an ACE_Message_Block is initialized, both rd_ptr and wr_ptr start at the base. As data is written into the block, the wr_ptr is advanced. As data is read out of the block, the rd_ptr is advanced. The valid data area is represented by the hashed area in the figure.

The various size-related data about each block are shown in the figure. They are:

• Length, obtained by the length() method. This is the number of bytes in the valid data area. The length is what's counted toward the water mark when a block is inserted onto an ACE_Message_Queue.
• Space, obtained by the space() method. This is the number of free bytes available to write into the block after the current write pointer.
• Size, obtained by the size() method. This is the maximum amount of space available for data. It's the amount of space between the base pointer and the end pointer. Thus, it includes any space before the read pointer, the valid data area, and the free space area after the write pointer.
• Capacity, obtained by the capacity() method. This is the amount of space allocated for the block. This value is only different from size() if the size() was subsequently shrunk after the block was allocated. This is rarely done, but it's important to understand the distinction.

There you have it. If you keep the distinctions between these pieces of information clear, you'll avoid overrunning the ends of blocks and miscalculating data in blocks and queues. Additionally, it's critical to remember these distinctions when using the Proactor framework and CDR classes, as both of these use the information and update it for you.

The figure accompanyong this article was extracted from the "Using ACE Effectively" course material for Riverace's new ACE training class. See the related news in this issue for more information on how you can take advantage of this new class.

The ACE development community is hard at work on the next version of ACE. Here are some of the things you can look forward to (items in bold are new or changed since last month):

• Native library path-searching. Previous ACE versions's implementation of ACE_DLL (used in loading dynamic services) implemented a search of the configured path-search to try and locate the desired library file (DLL) and then used the full pathname to load the library. This skirted some platforms's rules for path search and security settings. This has been changed in the next ACE version to make use of all of the native platform's path-search and security facilities.
• Improved wide-character support. Wide- character support has been included in ACE for many years on Windows (also known as Unicode builds). However, wide-character support for POSIX platforms has been sorely lacking. As ACE's reach expands, this has become a more important issue. Riverace is leading the completion of wide-character support in the next version of ACE. This support is also available now in the ACE 5.4b fix kit.
• GNU autotools support. Riverace is the lead developer in charge of adding auto-configure support to ACE. For native-build, non-Windows systems, autoconf will very likely become the way to configure and build ACE. This will help insure that ACE uses the latest features available on each supported platform, and reduce the work required to build ACE. No more picking the right config.h or platform_macros.GNU file. Just do ./configure then make. Ahhh...
• New compiler support. Support for g++ 3.4 and Microsoft Visual C++ 2005 are being added.
• Newer C++ Features Being Used. As the range of ACE-supported compilers matures and older compilers are taken out of service, ACE can make more use of newer C++ features while still maintaining its stellar portability record. For example, many methods that returned 1 or 0 as an int now return bool. Small steps, yes, but significant ones. You'll see more modern C++ usage as time goes on.
• The ACE and ACE_OS classes, previously containing a number of static member functions, are now C++ namespaces. Similar ACE-internal classes, such as ACE_Sock_Connect, are no longer in use.

As you can see, the pace of changes is slowing and the ACE development team is beginning to focus more on testing in preparation for the release of ACE 5.5. The current estimate for ACE 5.5's release is mid- 2005, so there's time to get a bit more in. In particular, the ACE_Dev_Poll_Reactor implementation for Linux would be a great addition. This was mentioned in last month's newsletter - please check it out using the link below for more information!