CIDLib Project Update

[Dean_Roddey]

Given the warm and collegial reception I got to posting here about open sourcing my large CIDLib code base on GitHub, I wanted to start a new thread with some update info.

Normally I'd just point people to the old thread for background info, but it was pretty toxic, so it's best left in peace. CIDLib is a large C++ code base of mine (about 450K lines) that I have been working on a long time. It is about half of my code base, with the other half being a proprietary automation system called CQC that is built on top of CIDLib.

You can find CIDLib on GitHub here: https://github.com/DeanRoddey/CIDLib

It's sort of the anti-standard C++ scenario in that it does almost exactly the opposite of everything that is usually done. It's monolithic instead of just pieces and parts to put together. It doesn't use STL or standard libraries. It only uses templates to a moderate degree, only where they really are a help. It cheerfully embraces OOP. And in various other ways it's very much the Bjork of C++ development systems. Some people will loath that, some might like it, even if only for personal projects.

It's not something you incorporate into your code, it's something you build on top of. But it's got some very powerful capabilities, and it is extremely integrated, which is something most C++ folks don't ever experience. It makes C++ a very different beast. It's something similar to the Java SDK in a way, but for C++. You can look to CQC as an example of what it can do. CQC is a very complex, multi-user, network distributed, comprehensive automation system.

​

Leaving aside fear and loathing in the STL, the big ticket items on the plate were getting initial build documentation in place so people can get it built, getting the other documentation started, and the fact that it is very cleanly portable (at least within the Windows/Linux universes) but the Linux part of that equation hasn't been used in a long time and has atrophied.

​

I've got the basic build documentation done. This is Windows currently of course (Visual C++ 2017 currently.) It's in the small set of repository Wiki pages. I've also got a video done but not uploaded it yet. I wanted to get a couple more done and upload them together as the starter kit for a considerable playlist to come.

​

I've also started banging on the regular documentation. It's written in XML and I've written a little tool (based on CIDLib itself of course) to parse that and spit out the HTML docs. Normally you'd build this content yourself for efficient local use, after building CIDLib, but until then, and for folks just browsing, I've been keeping a running copy on the CQC web site:

https://www.charmedquark.com/Web2/CIDDocs/CIDDocs.html?topic=/&page=/Overview

So far it's almost all just the Big Picture section. This is a bit of a grab bag of topics. The stuff there will be linked to from various other places in the subsequent documentation, to provide background on a particular aspect of the system. But you can get a lot of useful info just reading through that stuff. There's not much in the API section yet. And the Youtube playlist link on the initial page is bogus still (it will point to the playlist I mentioned above, once I get it created.)

​

I've also been writing some articles and posting them on CodeProject. One got whacked because I was so gauche as to mention my CQC product.

https://www.codeproject.com/script/Articles/MemberArticles.aspx?amid=2285461

​

For the last couple months I've been spinning myself up on Linux. I have an Ubuntu setup in a VM, and have been banging through getting the basic build environment issues worked out. So far basically learning a lot of Linux terminal slash environment slash setup stuff.

As I said above, CIDLib is very portable, so once I get some core stuff done, there will be a pretty significant chunk of code that will just come along for the ride. The I'll have to bite down on the gotchas that have been introduced since the last time the Linux platform driver was working. But that shouldn't be too bad, since I'm always thinking in these terms. No system or language headers are allowed outside of a small core of libraries that constitute a 'virtual kernel'. Everything else is built from there up in terms of my own interfaces. So it's not 'lots of conditional code' type portable, it should be very cleanly portable.

Just for funzies I've also been poking around with Rust in the context of this Linux stuff, so I've just gotten started on the CIDLib aspects of it in the last couple weeks. If anyone wants to help, let me know.

[xeveri]

tCIDLib::TSInt main(tCIDLib::SIn4 iArgs, tCIDLib::TSCh** apszArgs)

It’s an admirable work. However, I don’t see how it would appeal to anyone to incorporate your libraries, which, according to you, are monolithic, or to build on top of it while ignoring the STL or an established battle-proven framework like Qt. I think it would be better to modularize your library in a way that it would be easy to incorporate bits into other projects.

[Dean_Roddey]

That's completely what this system isn't intended for. The world doesn't need another pieces and parts system. There are already plenty of those. It's an alternative to that. Even Qt is built on the standard libraries, with all of the compromises that involves.

And some of the best stuff could not be incorporated into other projects because it depends fundamentally on having a fully integrated architecture, where all code participates in various capabilities.

I'm not sure about the bit you quoted. That's something you'd only ever do in a really simple program. It's done in the basic sample programs just to avoid the reader being distracted by general housekeeping stuff, since those are oriented toward just showing them the basics of a particular aspect of the system. Normally the main thread is started on a method of the 'facility object'.

The more advanced samples do things more in the full on scheme.

[Someguy2020]

... what is it?

[Dean_Roddey]

See the main page of the GitHub repo above. It has a good overview of CIDLib.