C++ Development: The Breviary Project

 Antiphons, in practice always accompany psalms and canticles.  (In a very, very few cases there are psalms without an associated antiphon, but they are the exception.  For the psalms in each hour there are two patterns: 1) There is one antiphon, said or sung before the psalms, and then repeated after.  In the Sarum and older Roman use this was varied by having the first iteration truncated after its incipit, but I decided (following the change to Roman use in the 20th Century) to drop this variant.  (The term Double to represent some feasts, retained for some decade after the change, originally meant the level of feast serious enough that an antiphon would be repeated in full, twice.). This pattern applies to all the minor hours, and to the major hours (Lauds and Vespers) under certain circumstances. 2) There is one antiphon per psalm/canticle, said before and after each psalm, with the Gloria Patri preceding the second iteration.  This is restricted to La...

 The PsalmParser is the first of three XML parsers used to support the Breviary. It would have been possible to simply provide the psalm data in a C++ rather than an XML format. The domain is closed; only 150 psalms exist, at least as far as the Western Rite is concerned.  But hardcoding it means that one can be stuck with typos, which require recompilation to fix; and it also constrains one's translation to that hardcoded (in this case, the original Coverdale text as it appears in the English BCP). The choice to use XML for this (as well as for hymns and most of the propers) leads to a further decision: how to parse the XML? I've been familiar with xerces for well over a decade. Using xerces is straightforward, gives a choice between DOM and SAX parsers, and can do additional validation. But as I'm doing this project, in part, to upgrade my skills, using a familiar third-party library -- and one with a C interface, to boot -- teaches me nothing. I decided to write my own p...

 The psalter representation is fairly simple, with one tiny quirk. The Psalter class -- which is the receptacle for the psalms derives from a one-function interface: class IPsalter { public:   virtual ~IPsalter();   virtual const Psalm &getPsalm(uint16_t inIndex) const = 0; }; However, the class itself has two functions: class Psalter : public IPsalter { public:   ~Psalter() override;   const Psalm &getPsalm(uint16_t inIndex) const override   {     if ((inIndex < 1) || (inIndex > 150) || (m_psalms[inIndex-1].get() == nullptr))       { return m_nullPsalm;       }     return *(m_psalms[inIndex-1]);   }   void addPsalm(std::unique_ptr<Psalm> &inPsalm); private:   std::array<std::unique_ptr<Psalm>, 150> m_psalms;   Psalm m_nullPsalm; }; Using a limited interface rather than a concrete class meant not only that the (many) classes referencing the interface ...

 The class for representing a psalm is at the opposite end of the spectrum from the PsalmSpec class.  It's a straightforward concrete class, with no interfaces or inheritance involved. (This has the drawback that one can't make it immutable, or provide a partial interface for it which is used as an immutable interface; I can live with that, given that this is very deep down in the library and wouldn't be a class that would be published if modules were in use.) A psalm isn't quite as simple as a set of verses.  In Anglican use, both psalms and subsections of psalms are associated with a tag in Latin which is the first two or three words of the psalm. (E.g. Psalm 23 has Dominus regit me  as a tag.) Most psalms have only one (implicit) section but some psalms have two or more subsections. Let's look at a section first:   class Section   {   public:     class IStreamer     {     public:       virtual ~IStre...