C++ Development: The Breviary Project

I t's not directly relevant to code in itself, but toolsets affect how one writes and refactors code. There's also the question of how the tools interact with ones own capacities. I work on Linux/Unix, though usually via Windows workstations in a work setting. I've worked around people who worked, in general, with three different toolsets. Many relatively younger developers use Visual Studio Code, even when working cross-platform. They're part of an IDE generation. I've never really seen the appeal, the few times I've used it. Well, I do, if you don't know what you are doing and need hand-holding. Most of the rest use vi/vim. If you're a command-line type, this seems to be the editor of choice in the Linux world. I've used vi since, oh, about the mid 1990s or so, but usually as an editor for quick jobs, usually not coding. I've used CLion on an evaluation basis. Its high degree of integration with cmake makes it an obvious editor if that's ho...

For many people, dependency injection implies the use of tools like Swing which allow configuration files to be used by a framework to sever the application code proper from direct dependency on concrete types. Dependency injection is not restricted to that model. C++, like any language which supports polymorphism, can do dependency injection. (See Dependency Injection Principles, Practices, and Patterns , by  Steven van Deursen and Mark Seemann, for extensive treatment of this general application of the term and for much useful coverage of details.) The top level of the simple breviary app is, more or less, what dependency injection looks like. int main(int argc, const char **argv) { JSBUtil::CommandLineOptions options(argc, argv); if (options.isSingleArg("?")) { printUsage(argv[0]); return 0; } std::unique_ptr<BreviaryLib::IDateCalculator> dateCalculator = BreviaryLib::DateCalculatorFactory(options).create(); std::unique_ptr<Brev...

 Most of the factories used in the text version of the breviary application, and provided in the library, needed no revisiting for the GUI.  However, the core formatting functionality is radically different when working with a GTKTextBuffer. What we had was: class OfficeFormatterFactory { public:   OfficeFormatterFactory(const IConfigSource &inConfig, const JSBUtil::ICommandLineOptions &inOptions);   std::unique_ptr<IEncapsulatedOfficeFormatter> create(); private:   std::string m_outputFileName;   int m_lineLength;   Use m_use; }; OfficeFormatterFactory::OfficeFormatterFactory(const IConfigSource &inConfig,                                                const JSBUtil::ICommandLineOptions &inOptions):     m_lineLength(inConfig.getLineLength()),     m_use(inConfig.getUse()),     m_offi...