// © 2016 and later: Unicode, Inc. and others. // License & terms of use: http://www.unicode.org/copyright.html // edits.h // created: 2016dec30 Markus W. Scherer #ifndef __EDITS_H__ #define __EDITS_H__ #include "unicode/utypes.h" #if U_SHOW_CPLUSPLUS_API #include "unicode/uobject.h" /** * \file * \brief C++ API: C++ class Edits for low-level string transformations on styled text. */ U_NAMESPACE_BEGIN class UnicodeString; /** * Records lengths of string edits but not replacement text. Supports replacements, insertions, deletions * in linear progression. Does not support moving/reordering of text. * * There are two types of edits: <em>change edits</em> and <em>no-change edits</em>. Add edits to * instances of this class using {@link #addReplace(int32_t, int32_t)} (for change edits) and * {@link #addUnchanged(int32_t)} (for no-change edits). Change edits are retained with full granularity, * whereas adjacent no-change edits are always merged together. In no-change edits, there is a one-to-one * mapping between code points in the source and destination strings. * * After all edits have been added, instances of this class should be considered immutable, and an * {@link Edits::Iterator} can be used for queries. * * There are four flavors of Edits::Iterator: * * <ul> * <li>{@link #getFineIterator()} retains full granularity of change edits. * <li>{@link #getFineChangesIterator()} retains full granularity of change edits, and when calling * next() on the iterator, skips over no-change edits (unchanged regions). * <li>{@link #getCoarseIterator()} treats adjacent change edits as a single edit. (Adjacent no-change * edits are automatically merged during the construction phase.) * <li>{@link #getCoarseChangesIterator()} treats adjacent change edits as a single edit, and when * calling next() on the iterator, skips over no-change edits (unchanged regions). * </ul> * * For example, consider the string "abcßDeF", which case-folds to "abcssdef". This string has the * following fine edits: * <ul> * <li>abc ⇨ abc (no-change) * <li>ß ⇨ ss (change) * <li>D ⇨ d (change) * <li>e ⇨ e (no-change) * <li>F ⇨ f (change) * </ul> * and the following coarse edits (note how adjacent change edits get merged together): * <ul> * <li>abc ⇨ abc (no-change) * <li>ßD ⇨ ssd (change) * <li>e ⇨ e (no-change) * <li>F ⇨ f (change) * </ul> * * The "fine changes" and "coarse changes" iterators will step through only the change edits when their * `Edits::Iterator::next()` methods are called. They are identical to the non-change iterators when * their `Edits::Iterator::findSourceIndex()` or `Edits::Iterator::findDestinationIndex()` * methods are used to walk through the string. * * For examples of how to use this class, see the test `TestCaseMapEditsIteratorDocs` in * UCharacterCaseTest.java. * * An Edits object tracks a separate UErrorCode, but ICU string transformation functions * (e.g., case mapping functions) merge any such errors into their API's UErrorCode. * * @stable ICU 59 */ class U_COMMON_API Edits final : public UMemory { … }; U_NAMESPACE_END #endif /* U_SHOW_CPLUSPLUS_API */ #endif // __EDITS_H__