Hacker News new | past | comments | ask | show | jobs | submit login
CIDLib: C++ Development Environment (github.com)
70 points by ingve 10 days ago | hide | past | web | favorite | 56 comments





I've been developing C/C++ for over 20 years on everything from large scale high-performance clusters to 8 bit embedded devices. Most of my career I have been consulting and I've had the opportunity to work in almost every domain, and I've had to work with a lot of other developers.

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's designed to be portable. There needs to be well defined types that each per-platform driver can define such that they always are the same.

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.


There is a huge difference in actually being portable and “designed to be portable”. I think library’s usefulness would increase many fold if former was the case.

Well, that's one of the reasons for open sourcing it. I'm no a Linux guy. But I know the issues very well, having worked on a lot of portable code before. And there's an existing platform driver for Linux already there, it's just very old and needs to be caught up.

I think it's cool to see projects like this! It's sort of like an "alternate history" for a C++ programming model. I agree that it doesn't seem immediately useful for most projects, but that's okay :)

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.


Part from license:

> 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.


It's interesting to see code bases like this. It does sort of have it all, custom build system, IDL, implementations of things like XML and JPEG. Very symptomatic of the need slowly being filled in the C++ community for a popular build system and package manager.

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.


I have a feeling that the author doesn't really want people to get anything out of the library in the first place but instead people build on it as a monolith.

The GitHub terms of service allow forking any repository, regardless of what the license says.

It's been changed. I'll look into some of the standard licenses soon when I have a chance. It's not even really important at moment, given that no one can even build it yet. I have to do some work to split my environmental setup stuff up because it's all currently up above the CIDLib/CQC layer. The CIDLib stuff needs to moved down into the repository visible directory.

Not Invented Here Syndrome, level: over 9000

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...


That vector/matrix code is ancient and hasn't been used for a long time. There are obviously going to be some bits like that. I used to really be into fractals and ray tracing and those were just done to support that.

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.


This was posted to the cpp sub-reddit. The wacky non-standard license and the denouncing of modern C++ are large red flags, as well as vague terms like 'Object Request Broker' and custom implementations of standards.

To be fair though, the custom implementations of standards could be very useful if they can be made free of dependencies.


”vague terms like 'Object Request Broker'”

That’s more dated than vague, IMO. See https://en.wikipedia.org/wiki/Object_request_broker.


The ORB is incredibly powerful. There's good video on it on my Youtube channel that demonstrates what it can do.

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.


This doesn't do a terribly good job at the moment of explaining why I might want to investigate it further or consider using it. What are the advantages it offers?

Agreed. A huge amount of text goes into explaining how much work it was to make and tons about what it's not. But, I'm having a hard time finding explanation of what it is.

He has done the same thing on the cpp subreddit with regards to his 'object request broker'. Lots and lots of text talking about how many lines it is and what it isn't, while never giving an example of a problem that it solves that couldn't be done easier with other simpler and more established libraries.

It's a pretty common problem when explaining tech. You (non-specific "you") have spent so much time thinking about a topic that all knowledge about it is assumed. You feel the need to defend your position from misunderstanding and misrepresentation. Contrasting it against other tech is of great interest to you. Meanwhile, I have no idea what you are talking about because you haven't actually explained what it is. But, explaining this big, complicated thing you've been working on forever is hard and could potentially expose you to criticism. Much more fun to continue bragging about how it's different/better than other people's stuff.

This is the kind of positive response that makes me glad I did this.

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.


I don't need a book. I just need something. The word "ORB" is not even present in the GitHub readme. You don't link your blog or your videos. You know that the explanations are sitting there waiting for me. I don't and you didn't tell 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.


I'll take another shot at it.

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?


Again, it doesn't need a book. Apparently the ORB feature is important enough that it has been mentioned many times in the discussion of this project. But, it's not given a single mention(note1) in the 1946 word description of the project.

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.


OK, it's been updated.

Tremendous improvement!

Thank you for sharing your hard work with the world.


I honestly think that having alternate implementations let people go back to when they were written; They are important.

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.


This is a textbook example of why Lean Startup exists.

To those surprised, this is exactly what million LOC pre-modern C++ programs looked like. Including the implementation of "basic" things. I thank god we're not in that world anymore, but it wasn't all that long ago either.

This is a little programming time capsule. Before open source, you had little choice but to build essentially everything yourself.

Well, to be fair, I didn't do it because I had to, I did it because I wanted to. General purpose object frameworks are what I enjoy doing.

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.


I am pleased to see that, among many other things, it comes with its own regex implementation.

Regex is included in C++11, not sure why you'd need a library for that.

"decades of work by the author"

presumably C++11 didn't exist back then.


So? It does now. Only as a museum piece is this project interesting, if that even.

>CIDLib is the product of decades of work by the author

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.


While that is a quite negative comment, it was also my first though. Even worse, I've seen another codebase veeery similar to this one, implementing all kind of stuff which is part of the standard library in "sane", I e. more higher level programming languages (thinking of "batteries included" Python).

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.


In no small part it's because C++ has lacked a package manager. The barrier for a library to become common and canonical is much larger as a result.

We also see remarkably shallow dependency graphs in the C++ world. Many projects are only a few layers on top of Boost!

I made a few dot graphs if people are interested.


How many layers atop boost would satisfy you? Boost seems pretty high level to me, and not like it needs a lot of abstraction atop its ... abstractions.

This is where I see this weird disconnect between communities. A C person doesn't want layers.


> 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.


The sense I mean this in is "layers for no reason".

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!"


C++ is not C. For that we have C.

I know C++ is not C, I have worked in both on both distinct and common occasions, and if you know what I mean by that shorthand, you know that the point stands. C++ people aren't superfans of layers upon layers for no reason either. Boost doesn't need a wrapper.

It's funny you mention JSON parsers and Boost in particular. The Boost JSON parser is an abomination. It's written as a parser generator in template code, so any file which includes it gets about 10 seconds of compile time just for that. It also blatantly violates the JSON spec and gives little to nothing in terms of parse error messages. Oh and until recently it was neither thread safe nor reentrant (you could not parse two JSON files on two different threads in the same process because it used shared global state for all parsing).

I remain baffled that anyone uses boost for anything in production.


I'm sure there are good parts to boost. I have no idea what they are, but just by sheer quantity, something must be worth using.

You’re right. For a few examples:

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.


Those were influential and have a had a very positive effect on modern C++ without a doubt. Now that they are part of the standard though there are fewer reasons to use anything from boost, largely because it is a double edged sword of compile times and dependencies.

This is honestly one of the most bizarre projects I have seen. I fail to understand the "open-source-but-not-quite" attitude of the author.

I don't do C++ anymore but for folks interested in C++ and what the project is describing, I'd urge dropping the knee-jerk prejudice against the license terms and actually try to see what it is all about.

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.


Okay, here's my feedback ignoring license terms:

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.
Uhh..

I had read Terry's story and was sadden by it.

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.


> 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).

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.


Sorry for the changed name, I closed the tab before before entering an e-mail and had forgotten the password...

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.


why it's got down voted? there are reasonable points.

The bar is not "possibly has some value" it is "plausibly has more value than other interesting projects one could spend time investigating". That includes other projects that are the product of a singular vision, like the STL somewhat ironically.

Before that, there's the documentation bar of "does it claim to do something useful enough, in a special enough and/or good enough way, to consider its possible use". The "singular vision" needs to be explained in detail.



Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: