vilhelmen / os_library Goto Github PK

Dyn_shift supports it, we just don't allow it because I'm tired of writing test code uggghhhhh.

Like it sounds, for_each, but backwards

Never actually used a linter. Seems like a good thing to figure out how to use. Now if only there was a homebrew package for clang-tidy.

Consider attaching the .clang-format I'm using to the project for obvious reasons, though I'm still not 100% happy with it.

clist is going to use test since we're transitioning, but the old stuff will need to be updated. I'm mixed on gtest since there's no order to tests, but something will be figured out, somehow. Also need to figure out how to reference/package with gtest properly

Libs are built with -O0 mainly for debugging, and it's helpful when debugging student code, but it's inefficient. Switch to -O3 (Os?) and move -O0 (as well as Wall, Werror (and add Wpedantic)) to a testing version.

It's probably important to run the tester with both forms, but since the testers are hooked into the backend, it can't generically attach to the library. Maybe need to make two testers? Investigate this and disable tester compilation by default.

Vague title, but capacity as a constructor parameter just confuses people, especially since we usually tell them to "just put a 0 there." I miss C++. So I'm thinking, toss that parameter, add a shrink_to_fit, and reserve. Thrilling.

dyn_array but more anal about the contents of the remaining capacity (always enforcing that extra space is 0'd out, or just that all erased space is cleared) and, perhaps, maintained capacity is always +1'd for a terminator.

It would really need to be based off dyn_array, but not use the same API or backend. Vectors and strings really have different needs and use cases, so they are going to end up diverging/specializing quickly.

That will make maintenance a bit of a pain, but hey, dyn_array's really only had one issue so far.

It's been mentioned before, but this repo could be transitioned to a project that just contains submodules. I believe submodules have to be manually updated, but that could be fixed with an automated hook, maybe?

Main cmake here could define the things needed for #5 and the modules could simply detect the project string, if it exists.

Probably just asking for more trouble; it's hard enough to get student to keep one repo up to date :/

Preventing the end user from seeing/touching the data structure contents is nice, but it's just not as fun to use and makes it very inflexible in some ways.

OSLIB/* ?

???