FST Conventions

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

Object Conventions

1. The StateIds of an FST are dense, 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 except kNoLabel (or library internals).
6. State iterators are invalidated if the number of states is modified.
7. Arc iterators are invalidated if the number of states or arcs is modified.
8. A reference/pointer to an arc is invalidated at the next Fst, state or arc iterator operation.
9. State and arc iterators should be destroyed prior to destroying their component FSTs.
10. All Fst classes F implement a copy constructor F(const &F).
11. The copy constructor and Copy() are constant time and space operations (typically reference-counted shallow copies).

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 not allowed.
2. If class C is templated on an Arc, then C::Arc will give that type.

-- CyrilAllauzen - 21 Nov 2006