OpenFst Conventions

The OpenFst Libary has various conventions and assumptions about its objects and coding style.

Object Conventions

1. The StateIds of an FST are dense integers, numbered from 0 to NumStates() - 1.
2. A StateIterator returns StateIds in numerical order.
3. A user may not request info about a StateId s from an FST unless the FST has already returned a StateId t >= s (e.g. from Start(), NumStates(), StateIterator, or ArcIterator->Value().nextstate).
4. The empty machine has start state kNoState.
5. Labels are non-negative integers except kNoLabel (or library internals). The label 0 is reserved for epsilon.
6. Weights satisfy the properties described here.
7. Arc weights satisfy the property that the sum of the weights of one or more paths from some state S to T is never Zero(). In particular, arc weights are never Zero().
8. State iterators are invalidated if the number of states is modified.
9. Arc iterators are invalidated if the number of states or arcs is modified.
10. A reference/pointer to an arc is invalidated at the next Fst, state or arc iterator operation.
11. State and arc iterators should be destroyed prior to destroying their component FSTs.
12. All Fst classes F implement a copy constructor F(const &F).
13. The copy constructor and Copy() method of an FST have constant time and space complexity (shallow copy) unless otherwise noted.

Coding Conventions

FST Application Code:

1. Your code should rarely use int or float when referring to FST components. Use:
   • StateId for state Ids and number of states.
   • Label for labels.
   • size_t for other array lengths.
   • Weight for weights.

New FST classes:

1. All Fst classes will implement working versions of all pure virtual member functions; writing dummy or error-raising versions is not permitted.
2. If class C is templated on an Arc, then C::Arc will give that type.

-- MichaelRiley - 25 May 2007