CIDLib: C++ Development Environment
github.com
github.com
My thoughts are this guy is type of the developer I hate to work with most. The style and naming Windows and Borland C++ specific, so this probably grew organically from Win3.1/NT. This probably pre-dates STL, but holy cow. Given how he misuses some terminology, he is probably a self-taught programmer from days of old.
Generally, when I see that a developer has decided to use their own typdefs to represent intrinsic data types, it's a bad sign. However, what I see that this guy created his OWN class as a replacement for bool, I know I'm going to be rewriting a lot of code.
There is no way I would use this library, regardless of the terms.
It would have been ugly and asymmetric to have some done that way and some not. So all fundamental types are defined as part of the library.
I hope the author publishes more explaining some of the architecture and design choices and how they diverge from what the rest of the community has come up with. At the very least it will be an interesting comparison.
> Do not host in any public way your own versions of this code, in whole or in part. This repository should be the single source for the code base.
Author basically killed option to send PRs via github. I'd suggest author to use more thoughtful/professional licenses for this (LGPL) if he wants some protection. Otherwise, I'd stay away from this.
I hope the author reconsiders their custom license that prevents any public forks of the code base. It's already very hard to get anything out of non-standard monoliths like this, with a custom license that chance drops close to zero.
Since he mentioned wanting some 3D/gaming stuff, I randomly checked out his vector3 class. It's not usable, due to the usage of float8. Games use float4. And since it's not templated...
As for matrix4 multiplication, a core operation, it's beyond bad: https://github.com/DeanRoddey/CIDLib/blob/master/Source/AllP...
Since there is currently no 3D graphics in the system, there hasn't been any justification to really go back and make them better relative to a lot of other things that are more immediately needed.
Hopefully, if someone wanted to get involved and develop a graphics library they would start with those classes. Or just remove those altogether and make them part of such a new subsystem.
To be fair though, the custom implementations of standards could be very useful if they can be made free of dependencies.
That’s more dated than vague, IMO. See https://en.wikipedia.org/wiki/Object_request_broker.
And the related IDL compiler also allows for very powerful enumerations, far beyond what C++ itself offers.
One reason ORBs have never caught on in C++ is exactly because there's no comprehensive, monolithic framework. It only works really in those scenarios. When you have such a thing, then any class that supports the binary streaming mixing can be passed back and forth to remote ORB calls.
It's at the foundation of the CQC layer which has MANY complicated client/server interfaces. Without the ORB they would be a massive PITA. With it, they are quite manageable.
There's LOTS of descriptions out there of what ORBs are. I have a good video about how it works and what it does. I can't put ten books worth of explanation in a read me.
Here's a positive suggestion: In the GitHub readme, lead with the second paragraph. The first paragraph is not important to anyone but you. Having it as the project's intro makes you come off as a self-important wank.
Cut the first paragraph and the first sentence of the second out completely. Cut the third and forth paragraphs as well. Keep the fifth "Because it doesn't use the STL" paragraph, then skip straight to the Goals section. Rewrite it to explain itself in concrete, positive assertions instead of what it's not and what it's anti.
Portability should come next. Then Gotchas. But, Modern vs. Classical is mostly a rant that doesn't help me understand your project. You've already heard more than enough about the license :p
You've made something really cool. You have every right to be proud of it. But, other people don't know how cool it is and they never will if you don't improve how you communicate with them. It's not just a matter of stating the facts. It's understanding their point of view and tailoring your communication around that.
You are a busy person. You know that there's more stuff being published every day than you could possibly even glance over. And, you know that most of that stuff is useless crap created by self-important wanks. So, what would it take to get you to invest the time to understand some random wank's project?
If you are like most people, you aren't going to sit down with a cup of tea and read the backstory of some random project like it's a New Yorker article. You are going to read the first paragraph, then briefly skip around the rest of the doc before deciding to move on or not. It's the only efficient way to filter through the fire hose of crap.
When writing your description, you need to respect the reader's time and ignorance. They don't know the huge amount that you know. They especially don't know why this project is worth their attention. Your job is to sell them on your project by being as clear, concrete, brief and genuine as possible.
But on the ORB thing, wires got crossed there. There's no way I'd mention the ORB in the read me. That's very important but small piece of the overall thing. He was referring to some of the videos on my personal Youtube channel where I talk about some of the technologies I've created as part of this project. Some of them are related to the ORB.
Obviously, if you have never heard of an ORB before it might take a bit of effort to understand. But I can't really explain in-depth the foundations of technology concepts in a video. I can only give the basics and demonstrate how I've implemented that technology.
Beyond that, it would require a bit of study on the reader's part, as it does for pretty much all libraries of this type. Qt's 3D graphics docs probably don't include a fundamental tutorial on modern graphics architectures, right?
I'm trying to get across is that you need to figure out what makes this project valuable from the point of view of the user and broadcast that loud and clear.
"It is a complete environment with build tools, project definition language, loadable text system, a virtual kernel to isolate it from the underlying OS, up through a full set of 'standard libraries', wrappers around lots of common functionality, UI framework, Object Request Broker and IDL compiler, VM based OO macro language with IDE, custom implementations of many standards (XML, PNG, ZLib, JSON, SMTP, HTTP, etc...), and lots of other functionality."
That tells me what this project is. [note1]Hey! Object Request Broker was even in there and I didn't see it in all the noise. Make that paragraph into a bullet list. It's really the most important part of the whole doc. If you have videos, other docs, link them right there. That way a visitor should be able to get a high-level impression of the project a glance. Not after interpreting the entire doc as a holistic concept.
All of the backstory, theory, goals, etc... are only interesting at all after they know that what they're dealing with and that it is actually worth investigating. Then, after they're invested in the project, they might have motivation to go elsewhere to read up on concepts like the ORB.
Thank you for sharing your hard work with the world.
The common understanding would be "Hey, this is how it was implemented in the standard, and it totally caught on because it made sense and everything else did not."
But I do not believe in those arguments. I often look at alternate libraries/implementations for readability or for lost-in-time features.
There's a reason I read EASTL and BSD code. It makes me refreshed, understand nuances better and more importantly, know what I've been missing out on.
The (very complex and large) automation system built on top of it was really just because I needed something practical to do with all of the general purpose code I'd developed. Though that then drove the development of a lot more general purpose code.
presumably C++11 didn't exist back then.
Shame to see it spent on this instead of virtually anything else. After skimming this a bit, I feel that realistically no company, organization, or individual should rely on this codebase due to its license and contribution by only one individual. I'd rather use Boost or well-established and popular third-party libraries to solve the problems this repo attempts to solve.
What if you're delivering software to a client and they find an issue with the JSON parser? HA! Time to switch libraries, because you legally can't fix the issue for them. What a horrible idea.
It looks like a trap where decades long C++ programmers go into: Programming basic libraries which where done by other people so many times.
My assumption is that this happens because C++ libraries in general have a steep learning curve (thinking of some templated boost libs) and the obvious missing standard dependency management in CPP.
I made a few dot graphs if people are interested.
This is where I see this weird disconnect between communities. A C person doesn't want layers.
Really? So why are C persons then using formatted output libraries (printf, part of the standard library), libraries for regular expressions (PCRE), GUI toolkits (Gtk+, sitting ontop of Glib)?
I absolutely second that in the C/C++ world, we see shallow layers of abstraction, but nevertheless they are there. In my experience, the seperation happens frequently because people seperate basics from their code, such as in the given Glib/Gtk+ example.
In GTK+ everything has a clear purpose:
* glib: Portable OO and data structures for C
* gdk: Interaction with the windowing system
* cairo: Drawing
* gtk+: widgets
An application touches each of these directly according to its needs.
Nobody in their right mind would say "we need a wrapper to abstract glib". Which is a suggestion here for boost. Pretty senseless.
But I think the subtext of this discussion is that all the javascript kids expect 20 layers deep and the top ones get rewritten every year or they're considered obsolete, meanwhile the bottom 18 or so are "too close to the metal" for a reasonable person to work with. A C and C++ person of a particular mindset will seek to avoid such a thing. You want to be able to have the whole picture in your head.
From this angle it's a very weird complaint to say "I counted how many layers there were and it was too small!"
I remain baffled that anyone uses boost for anything in production.
Smart pointers (unique, shared, auto), now part of the standard <random> The new Filesystem TR unordered_{map,set} enable_if/type_traits
Some is probably less important, but they’ve been instrumental in moving the C++ standard library forward.
Unless they are crazy, someone doesn't spend a decade or more working on something that isn't worth it. I think people also grossly under-estimate the creative power of a singular vision (ie not done by committee with a million employees involved.)
It is clear this is not vaporware, give it a chance.
It reminds me of https://templeos.org/, which is also decades of a single man's work. CIDLib doesn't really do anything that isn't already done elsewhere, and its organization is very strange with odd, antiquated names. Definitely reminds me of C++ you'd find in Windows 3.1 programs.
For example: what is "CIDMacroDbg.hpp"? Ah,
This is the main public header for the facility. It is the single point
of contact for the outside world. By including it, they get what we
have to offer.
I see no conflict between the two approaches....As far as I am concerned, progress is progress.
I have been watching the CIDLib videos (ie CQC) and it appears to be a comprehensive IoT type platform covering almost every aspect of deploying an IoT type solution, including a drag-n-drop IDE to create control applications (think old DirectX filter programming but on steroid). I am sure there is room for improvement.
https://www.youtube.com/playlist?list=PLJojk5z5q10SRUTLqEGfJ...
I think it is worth looking at, regardless of license term.
This is more informative on what the project offers than the entire readme. I think this is the point people are making. Great that you took the time to watch some videos and summarize here but this sort of information would be much more useful in the first paragraph of the readme.
Anyway, that'a not what CIDLib is. That's what CQC is. CQC is something that's BUILT on top of CIDLib.
If you need some sort of reference point for CIDLib, think Qt without the STL plus build tools or something like that.