Bug List

Class BerrySethiAlgo< T_auto, S, T >

FIXME: Change the zero-letter.

FIXME: Check efficiency.

FIXME: Check results of derivation.

Member BerrySethiAlgo< T_auto, S, T >::BerrySethiAlgo (const series_set_t &series, const exp_t &exp)
FIXME: Is it necessary to give the series as a separate argument?

Member BrzozowskiAlgo< T_auto, Exp >::on_state (const Exp &e)
FIXME: Optimize!

Member FreeMonoid< A >::alphabet ()
FIXME: this interface should not exist (s.e. are const once instantiated)

Member FreeMonoidProduct< F, S >::first_monoid ()
FIXME: this interface should not exist (s.e. are const once instantiated)

Class KRatExpAciCanonical< Series, T, Dispatch >
FIXME: The algorithm is correct, but the implementation may not be efficient!

Class KRatExpInitialDerivation< Series, T, Dispatch >
FIXME: The algorithm is correct, but the implementation may not be efficient!

File letter_to_letter_composition.hh
FIXME: Document!

Class PRatExpDerivationVisitor< Series, T >

FIXME: This class heavily lacks of documentation.

FIXME: Make list be a unique container.

Member SetSlotAttribute< S, true >::SetSlotAttribute (const S &other)

For a number of reasons (see the mailing list), this constructor creates a fresh copy on the heap which is never deallocated.

Make a better self-contained description of the bug.

Class SupportIterator< C >
is not STL compliant yet.

Member vcsn::algebra::op_contains (const algebra::Series< W, M > &, const rat::exp< Tm, Tw > &)
FIXME Operators in krat.hxx are of the form:

Member vcsn::auto_translate_transitions (lhs_t &dst, const rhs_t &from, const F &translate_fun)
Write documentation and tests.

Member vcsn::co_minimization_moore (const Element< A, AI > &a)
The precondition is not checked.

Member vcsn::partial_elimination (const Element< SA, TA > &a, M &state_exp_pair)
The algorithm should be inplace.

Member vcsn::search (const Element< Automata< Series, Kind >, T > &a, const InputIterator &begin, const InputIterator &end, typename Element< Automata< Series, Kind >, T >letter_t eol, FoundFunctor &f)
Multiple implementations of search() should be implemented. When a call to search is performed an heuristic should decide which implementation to use. For the moment there is no such mechanism since only one implementation of search is provided.