ChannelArchiver I/O Library

index.htm: Class Reference.

Purpose

All Channel Archiver Tools are based on this I/O library. Currently it supports these data storage formats:

• BinArchive: A binary archive of interlinked files.
  For maintaining these files, see the cardminer tool as well as the ArchiveManager documentation.
• MultiArchive: A set of BinArchives. See doc/libio/MultiArchive.h
• Possible future ideas: some SDDS-based format, an RDB interface, etc.

Coding standards

Class design

I tried to follow the suggestions of Meyers' Effective C++ books and also aim to keep the I/O library open for replacement of the data file format. Please note that this tends to bloat the code a bit. Example: A number in a C program could be defined as simply

float number;

In a hardcore C++ program on the other hand this turns into

class Number : public ObjectTreeRoot
{
    Number (float number)       { _number = number;       }
    float get ()                { return _number;         }
    void set (float number)     { _number = number;       }
    ostream & << (ostream &o)   { o << _number; return o; }
private:
    float _number;
};

This is comparably more code. The advantage is that it allows for transparent changes of the number's type. If all inlined, the C++ code needn't be slower nor will the object code be bigger. But it sure is more source code. And I didn't even use an abstract number base class...
To remain reasonable, this standard is not applied to each "number" but it is being followed for the Archive, Channel and Value related I/O classes. This already kept the Manager, CGIExport and casi tools independent from the used Archive type (BinArchive or MultiArchive).
Layout.htm explains the class layout in more detail, index.htm is a commented Class Reference generated from the header files.

Standard C++ library

The standard C++ library as defined in the 1997 Stroustrup book contains string, list, map, exception, ... classes. It is used whenever possible to prevent reinvention. While there are some similar classes in EPICS base, those are not used because they don't constitute as complete a suite.
Unfortunately, std::string showed a memory leak with RedHat 6.1 (that version of egcs g++ to be specific). Tools/stdString was introduced as a replacement. It can be used like std::string but implements only what was necessary so far.

Namespaces

Whenever possible, code it enclosed in a namespace Tools or ChanArch. For MS Visual C++ this is even required because of conflicts with the "list" definition in resourceLib.h. It can be disabled via a #define in ToolsConfig.h.