My first task in my current company, a few years ago.

I had to add features to a 10 year old microcontroller-based device written in C.

There was a struct named "global", which held hundreds of other structs that held variables or even more structs.
If one would have printed the structure of this mess it would haven needed several pages.

This "global"-struct was used in every single sourcefile to store and pass data around. Obviously there was no documentation and often useless comments.

Additionally there were a few protocol stacks involved, mainly similar, only differing in one or two protocol layers.
The implementation of the protocol stack was by setting flags in the "global"-struct in every protocol layer and having the application data in a buffer.
The complete telegram with all layer specific data (header, checksums, etc.) was then build at one single point right before sending it, based on the flags and the data buffer.

As there was no chance to reuse protocol layers with this implemenation. Three protocol implementations with special telegram builder existed in parallel, although they were nearly identical.

I needed a fourth variant of the protocol stack, so I had no chance but to make another copy with some minor changes.

But there was a benefit from this task.
As I had to do the software for the successor of this device from scratch I learned for many things how not to do them :-)

I really am not a fan of the contortions you have to go through in Golang to deserialize a fucking JSON blob. If this were any other language I would have already had a data structure I could query rather than wasting hours twiddling structs that will be filled properly.

Feeling kinda ashamed.. I couldn't implement a graph in python using classes without resorting to a library.
Wanted to test my skills but I guess I'm not quite to that level yet :/

Note: I have deleted my previous version of this question as I found it lacking crucial information and therefore being prone to misunderstandings.

Question : In C/C++ you can position the keyword 'const' either left or right of the left-most type specifier. Which variant do you prefer?

I ask that because I'd like to hear your opinion. Although I have been working with C over three decades now, I only learned this a couple of years ago. After some experimentation I decided for myself, that I like the placement to the right more. Although the positioning to the left is taught in literally every book and course, the original placement suits me better.

One reason, of many, is the listing of many member variables in structs or classes. To have them nicely aligned, I always had to put 'const' either on the previous line or put in extra indention to everything non-const. That was quite irritating sometimes.

Another, and my main reason is, that when reading from right to left, the rhs variant just makes more sense than the lhs variant. Reading from left to right almost never makes much sense without straining your eyes. But that is, of course, highly subjective.

This is even more so if you have pointers. The 'const' keyword modifies the type identifier(s) to the left. So if the 'const' is (anywhere) left of the '*', the data is const. If the 'const' is right of the '*', the pointer address itself is const. The same applies to references.

Examples, read right-to-left:
int* const i; // i is a const pointer to int data
int const* i; // i is a pointer to const int data
int const* const obj; // i is a const pointer to const int data

The "classical" or "taught" way, that is found almost everywhere would read, still right-to-left:
int* const i; // i is a const pointer to int data
const int* i; // i is a pointer to int data const
const int* const obj; // i is a const pointer to int data const

Not only that the second "lhs" form reads worse, it also looks worse. In my opinion, the first "rhs" variant makes it simpler to quickly determine that we are dealing with three ints, while on the second "lhs" variant, one has to first get past the 'const' keywords.

I know that this is not only a matter of taste, but of course of agreement, too. You can not just go and switch the 'const' placement in long standing projects. That would surely piss of a lot of people. Or even cost you your job.
But I like to know what you people think and why.

Thanks a lot in advance!

Am I the only one that doesn't think purely data-oriented programming is a particularly good idea?

I mean we're throwing out all the principles that have been established over the last 20 years of OOP like encapsulation and implementation hiding. And you can say what you want about OOP and yes it's not perfect, but there are things that work quite well. Implementation hiding is a perfect example of something that I don't think I just want to give up.

DOP feels like going back to programming C in the 80's with fully procedural functions and completely open structs.

Am I just going mad?

Crypto. I've seen some horrible RC4 thrown around and heard of 3DES also being used, but luckily didn't lay my eyes upon it.
Now to my current crypto adventure.
Rule no.1: Never roll your own crypto.
They said.
So let's encrypt a file for upload. OK, there doesn't seem to be a clear standard, but ya'know combine asymmetric cipher to crypt the key with a symmetric. Should be easy. Take RSA and whatnot from some libraries. But let's obfuscate it a bit so nobody can reuse it. - Until today I thought the crypto was alright, but then there was something off. On two layers there were added hashes, timestamps or length fields, which enlarges the data to encrypt. Now it doesn't add up any more: Through padding and hash verification RSA from OpenSSL throws an error, because the data is too long (about 240 bytes possible, but 264 pumped in). Probably the lib used just didn't notify, silently truncating stuff or resorting to other means. Still investigation needed. - but apart from that: why the fuck add own hash verification, with weak non-cryptographic hashes(!) if the chosen RSA variant already has that with SHA-256. Why this sick generation of key material with some md5 artistic stunts - is there no cryptographically safe random source on Windows? Why directly pump some structs (with no padding and magic numbers) into the file? Just so it's a bit more fucked up?
Thanks, that worked.

Okay, so I had an object consisting of tables (basically classes) and structs (classes with only scalars as their properties).

I was about to serialize the object with vectors of classes and structs and wrote some nice tests for it wondering why they fail to validate the data after deserialization and why I only got garbage for the vectors of structs whilst the tables worked just fine.

Turns out there is an undocumented function called CreateVectorOfStructs which shall be used for structs instead of the regular CreateVector ...

There go three hours of blaming memory issues and running Valgrind over and over again ...