A project you might find useful
I recently open sourced a very large project of mine, called CIDLib, on GitHub. I just wanted to make it known to this community. I've posted a bit about it elsewhere, but I thought it might be of interest to some folks here.
I have a pretty large (1.1M lines) personal code base. The top half is an automation system called CQC (still proprietary.) The bottom half (~450K lines) is a large, full featured development environment, which I've open sourced.
https://github.com/DeanRoddey/CIDLib
It's a full soup to nuts system, from build tools, to loadable resources, to virtual kernel platform abstraction layer, to a full set of standard type libraries, implementations of various standards like XML, JSON, PNG, ZLib, Blowfish, AES, Websockets, etc.... support for sockets, serial ports, speech recognition, HTTP, SMTP, ODBC, UPnP, UI framework, secure sockets, text transcoding, threads and processes, embeddable OO macro language engine with IDE, a really powerful Object Request Broker, test framework, and a bunch of other stuff.
* In light of some confusion below 'build tools' doesn't mean a compiler/linker, it means project definition system and bespoke build tool (make type program.)
For now, it's mostly just there for evaluation. I'm just starting to dig in hard to the external documentation (never needed any before because I was the only user.) The docs are in XML and built via a little utility that's part of the code base, but I'm keeping a running copy of it on my company web site. So far it's mostly high level topic stuff (the Big Picture section) that will be linked to from other places to provide background. But you can learn a lot about it from going those that stuff.
https://www.charmedquark.com/Web2/CIDDocs/CIDDocs.html?topic=/&page=/Overview
There's also a good bit of stuff on my personal Youtube channel. A couple are slightly out of date. The one on smart enums was prior to as massive rework to the new 'enum class' style.
https://www.youtube.com/channel/UCAxCoATHgFBvqZhxFRnZsfw
And some written articles on CodeProject as well, which typically cover the same topics as the videos but some folks prefer written info. There were more but they deleted a couple because I was so gauche as to mention my proprietary software.
https://www.codeproject.com/script/Articles/MemberArticles.aspx?amid=2285461
An interesting thing about CIDLib (or loathsome slash ludicrous slash whatever, depending on your particular point of view) is that it does not use the C++ STL/standard libraries. It has its own.
Some people will immediately scream 'not invented here' or claim there's no valid reason for not using that stuff these days. But there are exceptionally good reasons for not doing so. CIDLib is a highly integrated system. It includes some very powerful capabilities that only work if everything can participate in them.
If I used the standard libraries, I could never impose these things on them. At best it would end up being an enormously inconsistent hack. Without them, it's a very clean, very consistent system that is the opposite of the pieces and parts approach that is typical of the C++ world (and that has been a part so long now that many people get incensed if you imply it's not the only or best way to go about it.)
Just a couple examples... My IDL compiler (which supports the Object Request Broker but also can generate types and constants) allows me to have very powerful enumerations. C++ enums are weak at best. Mine have all sorts of capabilities. I could never make the standard libraries use them, so it would just be a mess.
Another example is the ORB itself. The standard libraries' story on streams is also weak at best. Mine are very nice, supporting binary data portability. And everything that implements the MStreamable interface can be passed across remote calls via the ORB with no extra work. It makes client/server systems so clean and easy.
There are lots more such examples. Obviously I know that many people will not use a non-standard system no matter what. But for those who aren't necessarily enamored of the way C++ is going, it might be interesting, for personal projects if nothing else.
CIDLib is very portable. Currently it's only deployed on Windows. But it strictly limits the use of language and system APIs to a virtual kernel layer, and everything else is written purely in terms of CIDLib interfaces. The virtual kernel layer provides a split implementation scheme, with common interface headers and per-platform implementations. The build tool understands this setup.
There used to be, long ago, a Linux platform driver, but it's long out of date. I've recently been spinning myself back up on Linux to start working on that. If anyone would be interested in helping with that effort, let me know.
CIDLib's version of multi-platform isn't the 'conditional code all over the place' type. It will be able to cleanly support Windows and Linux.
There is also an extensive UI framework. It is fully encapsulated as well, but I don't foresee that ever being portable. So we'd be looking at the backend for portability. But that would still be a powerful cross platform tool.
If you want to see what CIDLib is capable of, check out CQC, which is an enormously complex and powerful product built purely on CIDLib.
Anyhoo, don't get me started or I'll be showing you pictures of CIDLib's first birthday party and potty. Feedback is welcome, though experience has shown it will primarily be negative, this being the internet and all :-)
I have a pretty large (1.1M lines) personal code base. The top half is an automation system called CQC (still proprietary.) The bottom half (~450K lines) is a large, full featured development environment, which I've open sourced.
https://github.com/DeanRoddey/CIDLib
It's a full soup to nuts system, from build tools, to loadable resources, to virtual kernel platform abstraction layer, to a full set of standard type libraries, implementations of various standards like XML, JSON, PNG, ZLib, Blowfish, AES, Websockets, etc.... support for sockets, serial ports, speech recognition, HTTP, SMTP, ODBC, UPnP, UI framework, secure sockets, text transcoding, threads and processes, embeddable OO macro language engine with IDE, a really powerful Object Request Broker, test framework, and a bunch of other stuff.
* In light of some confusion below 'build tools' doesn't mean a compiler/linker, it means project definition system and bespoke build tool (make type program.)
For now, it's mostly just there for evaluation. I'm just starting to dig in hard to the external documentation (never needed any before because I was the only user.) The docs are in XML and built via a little utility that's part of the code base, but I'm keeping a running copy of it on my company web site. So far it's mostly high level topic stuff (the Big Picture section) that will be linked to from other places to provide background. But you can learn a lot about it from going those that stuff.
https://www.charmedquark.com/Web2/CIDDocs/CIDDocs.html?topic=/&page=/Overview
There's also a good bit of stuff on my personal Youtube channel. A couple are slightly out of date. The one on smart enums was prior to as massive rework to the new 'enum class' style.
https://www.youtube.com/channel/UCAxCoATHgFBvqZhxFRnZsfw
And some written articles on CodeProject as well, which typically cover the same topics as the videos but some folks prefer written info. There were more but they deleted a couple because I was so gauche as to mention my proprietary software.
https://www.codeproject.com/script/Articles/MemberArticles.aspx?amid=2285461
An interesting thing about CIDLib (or loathsome slash ludicrous slash whatever, depending on your particular point of view) is that it does not use the C++ STL/standard libraries. It has its own.
Some people will immediately scream 'not invented here' or claim there's no valid reason for not using that stuff these days. But there are exceptionally good reasons for not doing so. CIDLib is a highly integrated system. It includes some very powerful capabilities that only work if everything can participate in them.
If I used the standard libraries, I could never impose these things on them. At best it would end up being an enormously inconsistent hack. Without them, it's a very clean, very consistent system that is the opposite of the pieces and parts approach that is typical of the C++ world (and that has been a part so long now that many people get incensed if you imply it's not the only or best way to go about it.)
Just a couple examples... My IDL compiler (which supports the Object Request Broker but also can generate types and constants) allows me to have very powerful enumerations. C++ enums are weak at best. Mine have all sorts of capabilities. I could never make the standard libraries use them, so it would just be a mess.
Another example is the ORB itself. The standard libraries' story on streams is also weak at best. Mine are very nice, supporting binary data portability. And everything that implements the MStreamable interface can be passed across remote calls via the ORB with no extra work. It makes client/server systems so clean and easy.
There are lots more such examples. Obviously I know that many people will not use a non-standard system no matter what. But for those who aren't necessarily enamored of the way C++ is going, it might be interesting, for personal projects if nothing else.
CIDLib is very portable. Currently it's only deployed on Windows. But it strictly limits the use of language and system APIs to a virtual kernel layer, and everything else is written purely in terms of CIDLib interfaces. The virtual kernel layer provides a split implementation scheme, with common interface headers and per-platform implementations. The build tool understands this setup.
There used to be, long ago, a Linux platform driver, but it's long out of date. I've recently been spinning myself back up on Linux to start working on that. If anyone would be interested in helping with that effort, let me know.
CIDLib's version of multi-platform isn't the 'conditional code all over the place' type. It will be able to cleanly support Windows and Linux.
There is also an extensive UI framework. It is fully encapsulated as well, but I don't foresee that ever being portable. So we'd be looking at the backend for portability. But that would still be a powerful cross platform tool.
If you want to see what CIDLib is capable of, check out CQC, which is an enormously complex and powerful product built purely on CIDLib.
Anyhoo, don't get me started or I'll be showing you pictures of CIDLib's first birthday party and potty. Feedback is welcome, though experience has shown it will primarily be negative, this being the internet and all :-)
Last edited on
So what would be the use case for something like this? The way you're describing it it sounds like you made an entire virtual platform that a developer would build their application on top of. Why do that instead of building directly on top of the operating system?
I guess the primary reason is that it's a lot nicer environment than the direct OS interface. Far nicer, and much higher level, and a lot more functionality than would be available in the raw OS interfaces. You could think of it, roughly anyway, as providing something like the Java SDK or C# libraries for C++.
And of course the promise of Windows/Linux (possibly other) platform portability. That's not there now, but it's clearly possible (having been done in the past.) I'm starting to work on that myself, though I'm not a Linux dude myself, and it may take me six months without any help from someone Linux savvy.
And of course the promise of Windows/Linux (possibly other) platform portability. That's not there now, but it's clearly possible (having been done in the past.) I'm starting to work on that myself, though I'm not a Linux dude myself, and it may take me six months without any help from someone Linux savvy.
Did you consider developing a JRE or CLR language with associated libraries instead, and if so, why did you decide against it? I mean, the thing you implement is already not C++, since it doesn't support standard containers. If I have C++ code that does use those, I can't just compile it on your platform, I have to port it. I'm not saying your solution is good or bad, I'm just trying to understand the rationale behind it. By leveraging an existing platform you could have gotten some pretty nice features, such as memory safety.
It's just not a system for porting existing stuff to really. It's for building stuff on. And that's fine. The world doesn't need yet another set of C++ libraries that follow the standard scheme. There are already lots of them. CIDLib is an alternative for those who would like one.
I would disagree with the statement that it's not C++. C++ is a language. The STL is a library that comes with the language. You don't have to use the latter to write C++.
If I'd leveraged an existing platform, it would have been no different than if I'd built it using the standard C++ libraries. I wouldn't have been able to create a consistent architecture because you can't impose any functionality on any external code. It would have been just a big compromised hack in comparison.
I would disagree with the statement that it's not C++. C++ is a language. The STL is a library that comes with the language. You don't have to use the latter to write C++.
If I'd leveraged an existing platform, it would have been no different than if I'd built it using the standard C++ libraries. I wouldn't have been able to create a consistent architecture because you can't impose any functionality on any external code. It would have been just a big compromised hack in comparison.
| I would disagree with the statement that it's not C++. C++ is a language. The STL is a library that comes with the language. You don't have to use the latter to write C++. |
Yes, there are C++ programs that don't use the standard library. There are also C++ programs that don't use classes, or templates, or polymorphism, but I doubt you'd think a compiler that omits those features is compiling C++. At best it would be compiling a subset of C++.
I think it's fair to say that "C++" is everything that's defined in the standard, and that an implementation that implements the standard differently or incompletely is at best non-compliant.
| If I'd leveraged an existing platform, it would have been no different than if I'd built it using the standard C++ libraries. I wouldn't have been able to create a consistent architecture because you can't impose any functionality on any external code. It would have been just a big compromised hack in comparison. |
What functionality would you have needed to impose on the JRE? All you needed was a virtual machine that could execute portable bytecode and that can call into those utility libraries, right? Basically having the client code as glue between those external modules. Why do you think the JRE would have been less capable?
Clearly you can write C++ that doesn't use the STL, and pass it to a C++ compiler and it compiles and runs. Given such, clearly the STL is optional and therefore something that doesn't use it is still clearly C++. I'm not going to get into yet another argument about that. It's not an invalid implementation of the standard, it's code written in C++.
Last edited on
The build tool is bootstrapped up with a standard make file type deal, can't use the build tool to build the build tool. I was looking at the old make file for the Linux platform and I'm not even sure what make utility it is for. someone else wrote this make file long ago and there's no command file that invokes it, so I don't know what it is.
Anyone recognize what make program this type of content would be for on Linux?
It looks kind of like files for the make program, but it doesn't seen to use := type assignment operators, just =. And the cmake examples I saw were completely different seemingly.
Anyone recognize what make program this type of content would be for on Linux?
|
|
It looks kind of like files for the make program, but it doesn't seen to use := type assignment operators, just =. And the cmake examples I saw were completely different seemingly.
Last edited on
| It's not an invalid implementation of the standard, it's code written in C++. |
Last edited on
No, no compiler. That would be a bit too much to bite off, even for me. It's built on Windows with Visual C++, and presumably with gcc on Linux once I get that far.
You may have interpreted 'build tools' as meaning a compiler, but it just means project definition language, a tool that reads those definitions and invokes compilers and linkers and other tools, etc... So basically a 'make' system, but a built in one that understands how CIDLib works and makes it vastly simpler to define projects for building.
Sorry for the confusion. In retrospect it makes sense what you were saying above, which I thought was a kind of strange and backwards argument. But it makese sense in terms of that interpretation of my original post.
Under other conditions I might have asked why you were making that type of argument, but this is the internet and I've had so many negative and twisted arguments made against this project that I kind of stopped questioning.
You may have interpreted 'build tools' as meaning a compiler, but it just means project definition language, a tool that reads those definitions and invokes compilers and linkers and other tools, etc... So basically a 'make' system, but a built in one that understands how CIDLib works and makes it vastly simpler to define projects for building.
Sorry for the confusion. In retrospect it makes sense what you were saying above, which I thought was a kind of strange and backwards argument. But it makese sense in terms of that interpretation of my original post.
Under other conditions I might have asked why you were making that type of argument, but this is the internet and I've had so many negative and twisted arguments made against this project that I kind of stopped questioning.
Last edited on
No worries. Good thing I gave your last reply a third read before I hit submit, heh.
I may have completely misunderstood what your project is about. I'll try to make some time to give it a better read later.
I don't know much about make variants unfortunately, sorry.
I may have completely misunderstood what your project is about. I'll try to make some time to give it a better read later.
I don't know much about make variants unfortunately, sorry.
Topic archived. No new replies allowed.