Do C programmers usually create and curate a personal library for their own use?
I've been using mostly C at my current job for about half a year now, and I find myself reusing some little function that I've written for another code base in current projects. I'm relatively new to this, so I'm wondering if it makes sense to have a repertoire of general purpose utility functions and whatnot for future use.
I mean, the language's pretty established and whatever I think of must have been written by somebody else already, so is there even a need for what I'm talking about? Are there well-known open source libraries that resemble what I am talking about? Should I just include them instead of writing my own?
Sorry if this is a bit vague. General purpose as in string manipulation, debug output, buffer operations, implementations of data types not in C, etc., just to name a few examples.
yes, I think this is common. C's lackluster (by modern standards) standard library makes this desirable.
for example, Colin Percival (a FreeBSD developer who also wrote Tarsnap, spiped, and scrypt) has a library called libcperciva containing a bunch of common code used by all of them.
glib (not to be confused with glibc, which is entirely different) fills a similar role - originally part of the GNOME / GTK codebase, it's lower-level library code that is useful on its own, even for non-GUI stuff, so they separated it out into its own library.
Nevertheless, I couldn't help notice that C language doesn't have a community of sorts that also acts as package ecosystem like most other languages have it.
Be it Python's pypi, PHP's composer or Ruby's gems, these other languages have some organization to their common libraries and components for things like text processing, database interaction, serialization, etc. There is no such thing with C.
It's always been my understanding that PHP, Python, Rust, et al developed their respective package ecosystems as a direct response to the wild west nature of C, Fortran, Lisp and other predecessors. Though Fortran and Lisp, notably, have package managers nowadays.
I think cpan acted as a blueprint for other programming-language-specific package managers.
The Corecursive podcast has an excellent episode about CPAN
Wow, learned more than any given day at the job just now. Thanks for the links, I will check them out after work (burning the Sunday oil in office at this moment).
I have made utility libraries for every language I've ever used: C, VB, JS, Perl, PHP, Go.
I do C for my university work & classes (when I'm not swamped w/ SystemVerilog :| ) and I don't have an explicit general purpose library (that does sound really interesting though, just do an #include <genlib.h> or something would be neat), but I do reuse a lot of my old code I've written before. I mainly reuse makefiles, any file I/O stuff, memory manageable, and the occasional struct implementation.
To your questions (assuming they aren't rhetorical), I've never heard of any open source library like that, but as you mentioned since C is very well established and used, I wouldn't be surprised if it existed. As to your question about if you should include them (should they exist) instead of writing your own, it really is up to you & your time constraints and any potential licensing issues if you're using it for work or commericial applications. Personally I'd use/write my own because then I can optimize exactly what I want it to do, I understand how it works, plus the personal satisfaction of using those building blocks :D
I don't do it as an actial library, because I don't want to include code into an application that never gets used. But I do keep a personal list of utility functions that I use commonly. Although nowadays, with stuff like GitHub Copilot, a lot of common utility stuff can just be auto completed for you know.
It would be nice if I could use copilot at my job... it's somewhat fed related so they won't let something that phones home touch the source code.
Yeah, it took us a while to be able to use it. We just started piloting it for certaint types of projects where the code isn't put into our products.
That's actually a sensible stance, my company similarly asked to not use such tool. Part was that product is also offered to the federal government, but the bigger issue making lawyers anxious is that such tools can introduce copyrighted code into our base. Those tools were trained with other people's code.
I don't think ML tools like CoPilot copies code verbatim, though the legal consequences of using code generated from a model that was trained on other people's code escape me. I think workplace is primarily concerned with Microsoft slurping up the whole codebase to their servers or something like that, since the code itself is supposed to be somewhat kept secret. IDK the details; I'm just the dumbass junior they hired to write the most critical piece of their application.
I do this with Python, particularly a set of wrappers around matplotlib that do a decent job of styling generic plots (with many series). They originated during my PhD where I was continually plotting stuff and got extremely tired of customizing each and every plot to be even somewhat legible.
General-purpose utility libraries tend to end up as junk piles so it's better to divide them up by functionality, so there is a string library, a logging library, and so on. Borrowing someone else's is often better than writing your own, if you're selective. In the old days before Java had package management, I would download jar files of my favorite libraries and drop them in lib. I think that's how header-only libraries are used in C++?
I do a bit of embedded C++ programming using Arduino or PlatformIO, mainly for the common API and package management. I have favorite libraries like elapsedMillis.
I'm wondering what other C package managers people use? I think using OS-level package management (like Debian packages) is pretty common, but somewhat unfortunate since it's non-portable.
Jart seems to be building up an interesting portable C environment with Cosmopolitan libc and Blink. Haven't used it, but it's inspiring to watch.
I don’t have a library that I include or anything. I do have a few snippets that I reuse every so often. Like with my string concatenation snippet. It works and does what I want it to do so, I use it often.
This is what I am currently doing (sort of). Wonder if it's worth the effort to make it into more of a Thing that I can include...
For C in particular, IMO it's easier if you make sure it's header-only, such that you can drop it in to any project you're working on, and not worry about shipping a proper library.
Wouldnt mind some basic dynamic array etc data structures to be standardized for C.
Personally my stuff so far is just per project, but if i can utilize old code i will.
C is not expressive enough for even basic, generic data structures unfortunately — you can’t create a c++’s vector-like dynamic array that could store arbitrary sized elements without indirection.
Its macro system is also.. let me just say.. bad, so that’s no help either.
I'm curious to know why you're not using C++ instead. I've been helping a team switch a firmware from C to C++ and it was relatively easy (but it's off-topic, you don't need to answer this).
For your question, yes, sometimes people do create their own "library" from reusable functions. But most of the time, they try to use generic functions first, and use their own library if the task is too specific.
For example, you can use GLib, the STL, Conan, the Microsoft GSL, but if have a specific need like streaming logs to a weird server, your own code can be the solution. And this code can be cleaned, refactored, and reused in other projects as a library.
You described "string manipulation, debug output, buffer operations, implementations of data types not in C," and I'm sure there are libraries that already exist for this. The difficult task would be to find a good package manager for C to use those dependencies.
This is what I'm sort of thinking of. My code interfaces with embedded hardware, and many ANSI C functionalities are kind of shady on said hardware. The hardware I'm working with will straight up stop working if I do "too much" dynamic allocation of memory, and the manual doesn't even mention it -- weird stuff like that.
I suppose I could've, but my C++ skills did not get honed due to months of C usage at this here current job, and the deadlines are too tight for me to dive into the world of learning C++ better. All the C++ code I wrote looked like C, and I have no energy to learn after work... I know I'll need to really know C++ at some point, but I suppose I shall wait until push comes to shove.
Truthfully I think it depends on the application. If you're just writing a plain old CLI application, you should probably just use C++ because of C's lackluster out of the box functionality.
In the case of specific microcontrollers you may need to write a utility library. I wrote some rust code for the GBA and had to do just that (stdlib doesnt work on embedded platforms of course).
In general i think having a single utility library you move from project to project is probably not the way to go, but building one up per-project is totally reasonable. This may involve some copying and pasting :p
I did start the current RTOS-based program with a hardware abstraction layer that was quite specific to the platform itself but also had some generic utilities that I could have copy and pasted, so I think you are right. Maybe I should save a collection of snippets to copy-paste and modify, then. Probably faster than slightly reinventing the wheel whenever a wheel is needed.
Most languages without some sort of package manager, you'll end up doing a lot more work yourself.
C especially, given the minimal batteries included.
The issues with using someone else's library in C is