/a/ - anime/random

Oh, and I apologize for taking this thread into an off-topic direction. I just felt like a new thread wasn't quite justified.

>>25075
>>25074
No problem, mate. It is topical enough at that.
I kind of wish I didn't give up on programming when I was younger. I was thinking of sitting down and trying to learn some language this summer, but I will probably be too busy to have that time for that.

>>25074
I wanna go back to writing my library in C. Got interrupted by another project where we did all the needed lower-level coding like 4-5 months ago.

>>25074
I find C a lot easier to manage than higher level languages, and even harder to shoot yourself in the foot with than C++ or python. Higher level languages have a lot more ways of doing things, which means a lot more ways of doing things wrong, and it is a lot harder to find where things went wrong. There's not much you can fuck up at the conceptual level in C and have to rewrite most of your program because of some complex inheritance rule, most of the things where you'll trip up are far more obvious errors in keeping the bounds of a string array or memory management. It is a lot easier to keep an integer that is the end of a string to pass to strncmp than to deal with the thousand methods of string management that a higher level language gives you to hide that it's doing exactly that.

>>25077
I regret quitting a lot activities as a teenager. I hope you find some time, anon. Just an hour a day is enough to get the ball rolling. Maybe you can share your experiences here.

>>25080
What kind of library is it?
I had to switch to writing Java a few months ago, and it was quite boring. There's something about writing lower-level code that really excites me.

>>25088
Its relatively explicit nature is a very nice feature of the language. (I hear that Rust is similar in that respect.) You mentioned Python, and I think that's a good example of something that's ostensibly simple but has some parts that can aggravate newcomers.
Another thing I like about C and similar languages is that it is indeed small enough where you'll be able to master the language without either extending your life via dark magic or evolving to some higher being.
Somewhat related, but I've been looking at D's BetterC (https://dlang.org/spec/betterc.html) compiler switch, and it looks nice compared to using a very restricted subset of C++. I think I'm going to try it out next week.

>>25093
Small is nice when most common functions are just iterations of simple building blocks. Every single built in type in ruby has more methods than the entire C spec. It's nice in the program design as well, ed is a rather extensible simple line editor, vi is a mess with a ton of specific cases that don't do well in iteration. Python has a lot of issues, the one that has killed it for serious discussion has always been its speed, but even if python was the fastest language it would still be full of bad ideas. Of the four methods of program design it falls by default into the last and least one, "faux O", of immutable data where the operations are tied to the data. This is not conducive to good program design or real understanding of what is being done by the code at any given time. As far as improvements to C go I doubt there are many that actually work other than the obvious, which is remove the legacy features like strcmp, because the quality of C code is dependent on the programmer and no changes to the base or piles of template code are going to make you a better programmer with better understanding of the execution of the program, especially not if they were written with a more general case in mind and suddenly you have a large object with tons of properties when you only need to use a struct with two fields. It's the same problem even many C libraries have, you want to use a tool and it imports the entire chain of production from the mining to production of every tool that exists.
Don't use rust, everyone involved in the project either doesn't know what they're doing, hates you for being a programmer and wants to file the edges off of anything that might be potentially even vaguely useful, or wants to make it the new javascript with all the same failings in the same order that javascript has.

>>25093
>D's BetterC
I hate all these new weird languages that have been popping up, but this actually looks good.
C++ templates kill me a little every time I use them and I've heard D templates were better.

>>25093
>What kind of library is it?
Just some simple lens shading correction for the colors. I think Quallcomm has more or less the same thing, tho I've no idea if they do separate corrections for each frame in a video or do the more sensible thing to accumulate.

>>25102
INTERCAL is seriously a more well developed language than PHP.

>>25094
>Don't use rust, everyone involved in the project either doesn't know what they're doing, hates you for being a programmer and wants to file the edges off of anything that might be potentially even vaguely useful, or wants to make it the new javascript with all the same failings in the same order that javascript has.
Do you mind giving me some examples? From my understanding, it's designed to be a safe low-level language. And while "safe" and "low-level" ostensibly appear to be mutually exclusive, I think it's a laudable goal since the bevy of bad bugs in C programs have cost caused big problems. These bugs were, of course, caused by poor choices or forgetfulness on behalf of the programmers, but that's the crux of the issue: programmers should be focused on meeting their objectives not–for example–memory management and bounds-checking. And Rust appears to be just that: a low-level programming language where if you want to do something potentially dangerous but necessary, then you have to explicitly state your intention of doing so; that and its memory model is "automatic," which takes some burden off the programmer. (Though you have to learn it, which I hear is a trial.)
I've only even done trivial stuff in Rust; most of the things I know about it are from reading about the language. So I'd be interested in hearing another perspective.

>>25095
What's interesting is that D isn't "new." I think its first version was released in 2000 or something. So it's more of a middle-aged man compared to Go and Rust. (Fuck, even Go isn't that new anymore.)
Here's some posts about BetterC if you're interested: https://dlang.org/blog/2018/02/07/vanquish-forever-these-bugs-that-blasted-your-kingdom/ and https://dlang.org/blog/2018/06/11/dasbetterc-converting-make-c-to-d/

>>25099
Regardless, it sounds fun, anon. Is it only a personal project?

>>25102
>>25114
You're going to make Tinyboard-chan cry!

>>25138
It is very hard to make something in rust that is not trivial, those underpinnings that hide things from the programmer obfuscate what are necessary and not really dangerous tools. There are very few things you should absolutely not be doing as a programmer, and they all fall into the purview of violating scope, goto and memory offset calculations from within functions. What rust does is it takes away tools with the promise that it will do the same thing but better without them.
The first and most obvious failing of rust is the same as javascript: it doesn't break well. If you run into something that is wrong in C the program stops and this is a very good thing, in Rust and JS however an attempt is made to do what it thought you may be trying to do and this is never a good idea. The obvious example in JS is that if you call a method from a variable and it does not have that method execution of the program, or even the parts of the program only relating to that variable, does not stop. Rust on the other hand will do that as well but also simply swaps out things it believes are common mistakes, such as swapping various unicode characters that are visually similar to syntax for that syntax.
Bounds checking and memory management are already trivial, if someone is spending enough time on getting them right that it cuts into actual development time they aren't a very good programmer to begin with, I remember a presentation passed around at some point about how parenthesis cost the industry some ungodly amount of money to type each year by using the average developer salary and average number of parenthesis per code file and it's the same kind of business hogwash, there is no magic bullet to fix a programmer's understanding of basic data structures and hiding how they work will only lead to everything collapsing down the road when they realize they've made the wrong assumptions about them. It's the same problem I have with C++ vectors, yes it is sort of nice to have in theory, but why do I have to initialize it as <STD::VECTOR> and access it with push and pop which need to be dumped into more variables to get their output when just making a large array with an index variable takes two assignments and I can just use the values? Not to mention the underpinnings of STD::VECTOR are what I imagine hell must be like, pushing mallocs a new area in memory with size+1 and then memcpys the whole thing over, pop does the same but size-1.
As for automatic memory, all memory is automatic and handled by the OS, not being able to trivially suggest the size when you know what it will be is a great hindrance and you can get this same safety by just using fixed arrays instead of allocs.
Dealing with noops and forwarding is already abstracted enough at the level C operates on to make most non-conceptual tripups moot, taking away the manual assignment of memory in all cases means taking away the ability to trivially set up cache-line optimized data and architecture aware data passing.
But there is this:
https://github.com/rust-lang/rust/blob/master/src/test/compile-fail/issue-19692.rs

>>25138
>Is it only a personal project?
I'm receiving salary for it if that's what you're asking. But it's been just me for now.

>>25138
I fucking love Wailord (or is that Wailmer, I can't tell it looks a bit like a mix of the two)

>>25152
I think it's just a normal whale plushie.

>>25152
Wailmer, Wailord is thinner and longer and has his mouth open enough to see a row of teeth.

>>25152
Top tier taste in pokeymen.

>>25161
Yeah I thought so but it doesn't look spherical enough to be Wailmer
Maybe it's just a whale yeah

>>25139
I don't necessarily disagree with your points (The part about Rust not stopping when it should is concerning.), but I think you're arguing under the assumption that most programmers are good and easily handle trivial issues; this is not true. As I've stated before, the multitude of terrible bugs that were exploited because of programmers' negligence is too great of a problem to ignore. Perhaps Rust isn't the solution to the problem, but bounds checking and manual memory management (e.g. alloc and free) are a mental overhead that decreases performance, and they can be quite detrimental when the programmer forgets to free a pointer, forgets to check the length of an array (Thanks pointer decay!). Fuck, many programmers think that using linked lists everywhere is a good idea. Since programming languages are tools, they should come with safety built into them.

Also, is Rust really that hard to write non-trivial programs with? There's an OS in development that's built in it, and then there's Servo. Not only that, but if you need to really have fine grain control over optimizing cache-lines, then you can do that. I think you just have to place the code into an unsafe block. (Though if the argument goes that most of your important work is in these unsafe blocks and thus you lose your safety checks, then I will concede that Rust is truly broken.)

>>25144
Cool. I like the idea of being the only one to work on an internal project.

>>25191
This line of thinking of course comes with a huge caveat. If you make a language to be foolproof then you are teaching your programmers to be fools. No matter how much padding you put in a language and how much abstraction is piled on to minutia management if you don't understand the flow and bounds of a program it will be just as bad in rust as in C as in adobe flash. What happens under the hood absolutely will not save you from having to understand where it should be creating and freeing memory or where it should be checking the bounds of an array, the interpreter will be wrong in a semantically correct program. Even in C if you don't know where the no-ops should be due to data dependency GCC will sometimes fuck it up and LLVM will fuck up a good 60% of the time. This abstraction will absolutely not save a programmer who was negligent enough to stumble over a serious bug, the only solution to that is to have more and or better progammers looking over the code, the vast majority of these things are due to everything now being written once by one programmer and taken as red into the main project of whatever it is and then just rewriting from scratch when a problem arises instead of bugfixing because no one does bugfixing it's not part of the CADT software model. These "mental overhead"s must be taken into account no matter how safe and useless the language is promised you to be and no matter what level of sandboxing and abstraction you are at. If languages are tools I'd much rather cut my paper with lawn shears than safety scissors, and I have no doubt that someone will be foolish enough to impale themselves even on a rubber toy mallet.

Yes people will go to great lengths to make these monolithic trivial proofs that every language is turing complete, you can make an OS running on lua inside of minecraft if you want as well. What can be done without understanding and utilizing the underlying structures quickly diminishes the farther up you go. There are certainly parts of the hardware minutia you can abstract for free, the NIC and disk cache for instance, but without control over your own bounds you can't do much in the way of alligning arrays to PXE bandwidth or TCP payload size. Forget handling user input properly if you cannot trivially do the alloc, copy out, free cycle. The purpose of a language as a tool is to interpret a finite state automata by way of a psuedo turing machine. If you do not understand the transformations the grammar will not know that no matter how convoluted it is nor how much it keeps you from easily doing. What mistakes are made that make it out the door are the product of a failure in managerial design, personnel problems are not solved by separating people from their work.
There are plenty of programmers out there who do not understand the difference between passing reference and copying over an array as it is presented in C++, and there is almost no one who understands why what is really going on under the hood is such a mess,. It is not worth it to try and save every program and programmer, even PIC and tom duff unrolling machines in standard compilers are a nightmare of complexity that barely do anything for a huge cost in the name of patching over that more serious human issue.
You cannot fix people by withholding utility or disguising responsibility, they will only manage to out-stupid the new tools as well.

>>25139
> Bounds checking and memory management are already trivial
And yet people fuck it up over and over again. It's easy to declare yourself an EXPERT PROGRAMMER for getting supposed trivialities right, but the authors of all this broken software thought their bounds checks were fine, too – until it turned out they weren't and the program turned into a security liability. It's a fact that automatic bounds checking is easy to implement and adds no noticeable overhead to programs that aren't number crunching in tight loops (e.g. video codecs or arbitrary precision arithmetic routines), so there is no reason to make the programmer do it manually every single time. It should be enough to provide an escape hatch in case it's really, absolutely necessary for performance, but even that might just tempt people irradiated by prolonged exposure to C to enable it everywhere for "optimization".

You don't compile and assemble by hand either, even though a lot of generated code is rather questionable. Is it because doing trivial nonsense like bounds checks manually feels raw and therefore fast? This isn't intended as an attack, I really would like to understand this mindset since I used to have it and now can't understand the reason for the life of me.

> As for automatic memory, all memory is automatic and handled by the OS
This is complete sophistry and you know that.

>>25191
>>25192
>>25230
You guys seem pretty knowledgeable.
Do you post on any /prog/ spin-offs?
I know goatfinger and tinychan, but they're full of off-topic junk!

>>25358
I post on tinychan now and then, but its quality dropped a lot recently. Never used Goatfinger because the admin was a cancerous crossie who advertised on /g/.
It's really annoying how every programming-related place is infested with rampant shitposting, rabid fanboys and/or teenagers trying to impress others, but out of all the three, /prog/'s shitposting is the most bearable in my opinion.

>>25192
A language that provides safe constructs will at least more easily warn its users about potential or definite issues. And does a language that helps prevent common bugs make its users more ignorant and foolish? At worst, it'll at least raise a flag to the reckless ones, and at best the extra information will help the regular programmer learn and obviate future problems. The tool isn't the main impetus for negligent programming; it's the learning resources and the programmer himself.
Let me ask you this hypothetical question, anon: if there were a language that introduced constructs and abstractions that emphasized safety, but allowed one to effortlessly dip into low-level and thus unsafe workings, would you be interested in it?

>>25386
People really like flame wars. That's why you need a dictator to run these shitholes.

>>25230
As easy as it is to wave away bounding as freely abstractable it can’t really be done unless you understand every possible use case. Sure there are plenty of idiots who got into programming because that’s where they heard the money is, but that is no reason to make tools that encourage idiocy. If you don’t understand the algorithm you’re working on the language won’t save you. If you’re using so many arrays or allocs that you can’t keep track of them your design needs reworking regardless of the language. In C these things are already abstracted to a point where they are easy, you don’t need to know the offset from a pointer that an integer or char is as it is built in to the type, people will fuck it up with edge cases and stupid ideas at any higher level if they fuck it up here and the only solution is get better developers.

>>25358
I could get the same reddit meme spam signing up to a linux kernel developer offtopic mailing list, even the Lisp evangelism.

>>25468
>A language that provides safe constructs will at least more easily warn its users about potential or definite issues.
So will a sufficiently annoying compiler, but either way it will either be ignored or get in the way of doing something non-standard, or both if someone is trying to do something interesting and also fucks up then all attempts to help will get in the way unless the language devs planned for your weird special construct.
Generally I would not be interested, language level abstract tends to get in the way of OS level abstraction.

>>25469
Bounds checks don't exist to "encourage idiocy", they are there to prevent silent catastrophic failures like the ones caused by almost any error in C. They exist to aid debugging because there is no good reason to make something harder to use than it needs to be on purpose. The idea that an out of bounds write can corrupt something internal to the language's implementation with essentially random effects is buttfuck insane and would be grounds for a firing squad in any serious discipline. To be honest, the way you reply to all of this with "get better developers" smells of elitist dick stroking, consequences be damned. Would you cross a river if bridges were built with that philosophy? I doubt it.

There's one more thing I'm confused about. Why should bounds checking not be easily abstractable? Literally all you have to do is check the bounds before you access something. In fact, it seems like you simultaneously argue that bounds checks are a triviality (and thus people who fuck it up are stupid) yet it can't be done easily; which one is it?

It'd be really nice if you answered my question about Assembly, by the way. What's so special about C to you? It isn't particularly close to the hardware actually. C is just very primitive so a lot of it's primitives map directly to something in the hardware.

What projects are you working on, anons? Anything you'd like to show?
Are you learning a new language? Are you enjoying it?

I'm continuing to casually use D as my "scripting" language of choice. Ranges and the algorithm library really make for a good time.

>>26899
>>23107
>>23175
This girl must be stopped.

I've been creating a minecraft mod, which means a lot of Java. God what a horrible language, so many things are implemented as a ghastly visage of maintaining coding style but the front falls off if you try to actually use it anywhere. Like how the comma operator only works inside of for loop initialization blocks. There's also the classic ever-present "Object Oriented" language bullshit, like some functions returning the object they're called on, versus simply changing the object they're called on, so there is no consensus in the code whether it should be a = a.b(); or just a.b(); I guess the saving grace is it's not python3. Give me your public key if you want to contribute/check out the tower of AIDS and bad decisions on everyone's, but especially my, part.

For work I've been dealing with google's OAuth2 abortion in a variety of shell and C scripts to try and get calendar exporting to work on the CLI; and on the more fun side creating C battering algorithms to try and reverse-engineer ZTE garbage machines that are documented wrong.

>>26899
Currently I'm utterly fascinated with functional programming for some reason. I've checked out a few languages but I'm loving Scheme the most. I was put off at first by the bad portability and whatnot, but I no longer care: the language's too much fun, plus I actually find the lispy syntax clearer and easier to translate thoughts into - guess I have the right kind of brain damage for it.

I just wrote a sudoku solver in it. The algorithm's slow, because I don't know maths and can't write algorithms for shit, but it made for good practice and was fun.

>>26899
Playing with some easy geometry for surround cameras for a car. I'll start writing it in C in a few weeks time, but for now we're tuning the algorithm side of things. That included a whole day spent on thinking that the length of the (x, x^2) curve is (x^3)/3, so I'm currently considering checking myself for brain damage. The literal kind, not like >>26904

>>26905
What's worse is dealing with GPS+ground station to xyz+rpy conversion, and for our autonomous car project dealing with the fucking FGPA "machine learning" garbage output.

>>26903
>This girl must be stopped.
Impossible. In another six months, she'll resurrect this thread once more.
>Give me your public key if you want to contribute/check out the tower of AIDS and bad decisions on everyone's, but especially my, part.
Is the codebase not public? I haven't programmed anything with Java in a while, but I do remember disliking their brand of OO and its intrusiveness. Some of the bullshit could easily be eliminated if free-standing functions were allowed. Though I hear that something like that will be included into the language.
>For work I've been dealing with google's OAuth2 abortion in a variety of shell and C scripts to try and get calendar exporting to work on the CLI
What specifically is causing you issues? Is it the API?
>and on the more fun side creating C battering algorithms to try and reverse-engineer ZTE garbage machines that are documented wrong.
This sounds really cool, anon. Are you reverse-engineering them because of the poor documentation?

>>26904
How are you learning it? (SICP?) My favorite thing about the functional paradigm is being able to have compact code that's readable. It's especially great for scripting I've found.
>I just wrote a sudoku solver in it. The algorithm's slow, because I don't know maths and can't write algorithms for shit, but it made for good practice and was fun.
That's a good motivation to better your math skills. A nice thing about programming is that it's a great way to apply your math skills and see concrete results.

>>26905
>>26907
Good stuff. So how much of that ML data do you see being processed onboard and effectively integrated into the system in the end? (Pretty sure this a dumb question.)

>>26935
Her destruction must be completed, for the safety of the future.
The codebase is not public, mainly because setting up a private git requires "create a directory on the server" and setting up a public one requires "chose between a dozen terrible clones of github and gitlab, the least bad of which is cgit, and then go through the effort of dealing with nginx userdir handling and permissions so the web user can access the git user's files on a selective basis". Its OO-nes is a sham, a whole hell of a lot of special casing to get around the OO and allow some semblance of normal code. Some of the base types and classes (like Random) are fully Java style objects, others (like int) pretend to be C style so no one freaks out that you need to do 1.add(1) to get 2 but get muddled in OO when you want to do anything with them (like make an array).
As with anything google, half the documentation is wrong and half is contradictory and they're not the same half. OAuth2 is their replacement for API keys, for some things, but can only be turned on if you change your account style and set up service logins and encode tokens to ask for certain domains but you have some three conflicting things in the dashboard that say they do the same thing but don't tell you what service they actually belong to. Their implementation of the actual request tokens (jwt) seems to use the wrong algorithm to hash instead of the one listed on their page.
Poor documentation, poor support, poor functionality. The enterprise way of doing what we want involves a bunch of operators assigned to operate switches all day by the proletariat, using their software that is not scriptable. In this great old capitalist United States a company must hire the same number of operators to man the customer phones instead of the switches, so of course this needs to be automated through interactions with at least 6 different webshits and hundreds of lines of sed commands to change "Customer has paid their bill with your faux bank webshit" into "giant mess of ZTE trash on snmp oh and a couple of the snmp locations lock the CPU when you access them, good luck finding any of that information". This is the best GPON switch OEM, the next tier down are people who think "Redundant power" means "two cables plugged into the same converter unit".

>>26935
4 out of 6 times it saw a stop sign it responded that there was a stop sign ahead. When processing the sample data it can draw boxes around the pedestrians, which will be great if we start seeing sample pedestrians walking around the city any time soon.

>>26936
>4 out of 6 times it saw a stop sign it responded that there was a stop sign ahead. When processing the sample data it can draw boxes around the pedestrians, which will be great if we start seeing sample pedestrians walking around the city any time soon.
This sounds exactly like the gripes with ML of half of my team. Fortunately, I don't deal with this. I however had to deal with some cameras for Continental/Renesas who wanted to use them for something like that. And, of course, they had no fucking idea what they actually wanted from the project, which just wasted months of my time.

>>26935
>How are you learning it? (SICP?)
I am in fact going through SICP but I started learning Scheme for its own sake before that. I read some intro wikibook and Teach Yourself Scheme In Fixnum Days, and for anything else I mostly refer to my implementation's docs.

I never created a parser before because even for niche languages, there are libraries to enable my laziness, but now I have a chance, and it's been an exercise in tolerating my retardation.
I've learned one thing, however: read. Read the fundamentals and basics of what you're trying to build. Don't go out on a limb and create something from mere intuition unless you have sufficient experience and intelligence. Even for a hobby project where I'll probably be the sole person to ever maintain it or interact with it as an end user, the results have been nothing short of frustrating and perturbing. Initially, it wasn't too bad. I created tree structures and linked lists, and it was all good, but that wasn't sufficient in my eyes because all values were stored as strings. Thus, while it passed most test cases, it was not the best thing to hand to the user of the library, I thought. So I started to use sum types and its kin–but wait, those are self-referential. So now the abstraction level has exceeded my tiny little brain's cognitive ability.
I'm on the third version, and I don't know if this is fun or not anymore. Those inefficient and ugly linked lists are starting to look appealing now.

>OAuth2 is their replacement for API keys, for some things, but can only be turned on if you change your account style and set up service logins and encode tokens to ask for certain domains but you have some three conflicting things in the dashboard that say they do the same thing but don't tell you what service they actually belong to. Their implementation of the actual request tokens (jwt) seems to use the wrong algorithm to hash instead of the one listed on their page.
I would imagine Google of all places would have technical writers and reviewers worth a damn, but apparently that's not the case. Horrific stuff, anon.

Printer.

>>27734
Fun fact: when working for automotive, the clients will start demanding various standards.

Which are so restrictive that you literally can't write a parser that passes them.

>>27734
https://pyvideo.org/pycon-us-2012/stop-writing-classes.html
Various people in the google food chain regularly abdicate responsibility for the atrocities of code and documentation. Their endpoints have always been fundamentally broken (their IMAP ssl is a trashfire) but now people take their services seriously for some reason.

The answer to storage is usually hashmaps, linked lists are fine for chaining hash maps but the benefit of hashmaps is very high unless you're regularly restructuring data, and even then the difference between logn and n isn't going to be much unless you are doing constant lookups on enormous datasets.

>>27737
That doesn't sound very fun.

>>27742
Various people in the google food chain regularly abdicate responsibility for the atrocities of code and documentation. Their endpoints have always been fundamentally broken (their IMAP ssl is a trashfire) but now people take their services seriously for some reason.
After watching that video, I'm curious as to why they made that shit so big? Why didn't they break down the library into smaller ones? I don't see the point in requiring users to download a shitload of code when they only want one component. Enterprise programming at its finest. (Along with that amusing example of the "Muffin" API from the video.)

>The answer to storage is usually hashmaps, linked lists are fine for chaining hash maps but the benefit of hashmaps is very high unless you're regularly restructuring data, and even then the difference between logn and n isn't going to be much unless you are doing constant lookups on enormous datasets
Currently, it's a discriminated union composed of several fairly basic types that map to the data format, and then it contains a self-referential list and a self-referential hashmap.
So, DataFmtObj = DUnion = {Type1, Type2, Type3, DUnion[], HashMap<Type1, DUnion>}
I wish I could use a mere hashmap, but I'm using a statically typed language. I can't think of another suitable implementation.
Related to this, the data format specifies that strings aren't necessarily character strings; that is they're byte strings in general. However, in practice, most strings are composed of characters and are encoded in UTF-8. So I'm left with two choices: store strings as either a character-encoded string or a byte array and have the user convert when necessary; store both types of strings in the union. (This will require an additional accessor function and overloading some operators.)

Metaprogramming is glorious. Instead of having a user manually register a type to use in my system, all they have to do is define the type in a certain module. Then, at compile time, an array to be used by the system is automatically built from the types in the aforementioned module. Of course, those types will be verified against some parameters to ensure their validity before being added to the array.
Now I have to wonder how well this would work in a large project and not a hobby one like mine.

>>29142
So it does what void* did before C++ broke it? Or what the old
struct tunion{ int typ; union{ float a; …};}; did with switch on typ.
Generic data isn’t new, but never before has it been so hideous and irregular. It is an impossible nightmare to scale this nonsense compared to something like qsort(void** a, void** b, int nelm, int (func*)compar(void**,void**)); which uses regularity to scale effortlessly to any type.

>>29145
Initially, the plan was to use tagged unions that would allow safe extraction of data thanks to templates, but I've set it up such that after the types are harvested from the module, an array is defined for each type. Something like Type1[SIZE] _type1, Type2[SIZE] _type2 would be fields in a struct/class. Transactions with the system would require the user to specify the type at compile-time when using the interface functions that would then map the type to the array. All type-safe and hassle-free.
The only question is how all of this would impact the compilation time given a number of types and whatever template goodness I'm using in the other parts of the codebase.

>So it does what void* did before C++ broke it?
Are you talking about C++ requiring explicit casting of void*?

I cannot finish any of my damn programs because I demand perfection, but I'm also incapable of designing and implementing such immaculate computing. Truly an enteral struggle that only the gods may conceive.

>>30723
The Tom Duff device is perfection, the more Duff devices you have in your code the more perfect it is.

I've been trying out C3 (https://c3-lang.org) as of late to satisfy my curiosity, and I find it amusing that the language disallows local type inference (outside of macros), while its obvious inspiration's latest iteration (C2x) now has it as a feature following C++'s example, albeit in a restricted manner.
Overall C3 is more powerful and convenient, assuming you don't need to use C for its ubiquity or plentiful implementations, but it comes up short like this.