BasisDoctrina Cross Platform Library for Desktops and Embedded Systems Development

**currently requires C++17 **

Introduction

BasisDoctrina is a brand new UTF-8 based C++ cross platform library
project for desktops and embedded systems. As such it is taking its
first baby steps now so those wishing to help build a proper foundation
for a next generation class library should hop on board.

When we get to creating the widget and other graphics classes we will be
immediate mode. The one-ugly-bloated-switch-to-run-it-all application
frameworks have really been used for far too long. They were created on
GUI DOS (Windows 3.x) and OS/2 when single core computers ruled the land.
Requiring a main event loop that runs in the primary thread through which
almost everything executes makes an application operate mostly single
threaded. When you create new threads, unless you force it to another core,
it will run on the same core as your main event loop leaving all other
cores basically idle.

Project focus is on Desktop computers and embedded systems, mostly
embedded systems that will be part of medical devices. Project does
not care nor will it ever care about phones. Initial embedded
development will be focused on NXP derived ArmV8 mostly because that
is what we have to work with.

Ideally this library will be architected much like DEC ACMS (Application
Control Management System). There will be a Benevolent Overlord on one
core and vassals (or task server) spread across other core. Most likely
publish-subscribe or some other, possibly persistent, message queue.
Preferably these will be child processes, not threads.

Project Motto:

** Don't Insist on Building Your Own **

Reason for Existence

In the days of GUI DOS, you had no choice but to roll your own. The
problem with that is you get trapped.

A manager screamed at the systems analyst, "You guys tell me you're
programming gods so how can it take you six months to deliver the
new system when God created the universe in seven days?"

Systems analyst thought for a moment and responded "God didn't have an
installed base."

That's how we ended up still using application architectures designed
in the early 1990s today, when they cannot fully use the computer they
are running on. Intel started shipping Core 2 Duo machines in 2006.
Today you can purchase used computers with 24-core for under $800 U.S.
There are 12-core ARMv8 modules on the market with 4-core and 6-core
being quite common.

It's time to stop messing with Docker and other containers just to
nurse along what is a single core architecture. Yes, you can keep
throwing hardware at it, but in the battery powered medical device
world you shouldn't have to.

Philosophy

C++11 gave us a regular expression library which is well tested by now.
Why have more than a wrapper around it? The same is true for map and
list containers. IBM dumped a ton of resources into Xerces so there
would be a free, industry standard library. We could also choose to
wrap libxml++. Glib::ustring exists everywhere so why not wrap it?
The library is well maintained and proven.

Why wrap? Application cleanup. One of the things the legacy application
frameworks brought to C++ was garbage collection. At the end, all of
the objects would get cleaned up.

Smart pointers aren't so smart.
https://www.logikalsolutions.com/wordpress/information-technology/smart-pointers/
As soon as you need to pass the pointer to a system service call or
third party library, your program has no real method of determining
when it is safe to delete. If your smart pointer decides to delete the
item and the third party later reaches for it you will have
inexplicable crashes that could happen hours or weeks after deletion.

System Requirements

We will not use C++20 or any C++ compiler standard that forces twos
complement binary integers. Unisys mainframes as well as many devices in
the embedded systems world use ones compliment and we have to communicate
with them. Given our use of C++17 it is theoretically possible the
project could support Windows XP if you used a version of GLFW from
earlier in the year. According to check-in comments GLFW only
recently dropped support for Windows XP.

Current development is currently being done on MX Linux.

Eratta

LICENSE.TXT contains a copy of Eclipse Public License 2.0. Files in the
3rdParty directory tree may contain source with MIT or Public Domain
license, but this project uses Public License 2.0.

You can visit the roadmap at
https://basisdoctrina.com/RoadMap.html

Project blog.
https://sourceforge.net/p/basisdoctrina/blog/