The OpenFst Libary has various conventions and assumptions about its objects and coding style.
StateIds of an FST are dense integers, numbered from 0 to
NumStates() - 1.
StateIds in numerical order.
- 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
- The empty machine (no states) has start state
kNoStateId; a non-empty machine (has states) has a valid start state.
Label is a non-negative integer except
kNoLabel (or library internals). The label
0 is reserved for epsilon.
Weight satisfies the properties described here.
- 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().
StateIterator is invalidated if the number of states is modified.
ArcIterator for a state is invalidated by any mutation of the arcs at that state.
MutableArcIterator is invalidated by any mutation of the arcs at that state other than by the iterator itself.
Matcher is invalidated by any mutation of an FST.
- A reference/pointer to an arc is invalidated at the next operation on an FST, state iterator, arc iterator, or matcher.
- State iterators, arc iterators and matchers should be destroyed prior to destroying their component FSTs.
- All Fst classes F implement a copy constructor
- The copy constructor and
Copy() method of an FST have constant time and space complexity (shallow copy) unless otherwise noted.
FST Application Code:
- Your code should rarely use
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:
- All Fst classes will implement working versions of all pure virtual member functions; writing dummy or error-raising versions is not permitted.
- If class
C is templated on an Arc, then
C::Arc will give that type.