== The advantage of garbage collection for APIs Here's a question that interests me: why don't I have a standard C version of [[my Python _warn()_ function ../python/PythonStandardErrors]]? The Python version shows up in most programs I write, but in my C programs I generally directly _fprintf()_ errors to stderr, instead of having a utility function for it. Part of the reason is that a C version of _warn()_ really calls for a different and more complicated set of arguments. Instead of a single string, the natural C-ish approach is printf()-like, creating a prototype of '_warn(const char *fmt, ...)_'. In turn this makes _warn()_ a non-trivial function, because varargs functions in C are vaguely annoying. (Things get even more interesting when one implements _die()_, since you can't have it call _warn()_; either you duplicate _warn()_'s code or you wind up needing a _vwarn()_ with the prototype '((vwarn(const char *fmt, va_list ap)))' that both _warn()_ and _die()_ call.) But why does the C version of _warn()_ need a different API than the Python one? One answer is that Python has a first class operator to format printf-like strings (the string '_%_' operator, in a marvelous abuse of operator overloading) and C doesn't, so in Python it's idiomatic to format strings directly in your code, instead of handing the format and the arguments to another function. This isn't the whole story, though, since C has _sprintf()_ and could do much of the same tricks if people wanted to. The problem with _sprintf()_ (and why in practice it is not used for this) is that you have to give it a buffer. If you use _sprintf()_ you have to think about how big a buffer you need and what you do if it isn't big enough. If you use _fprintf()_, you don't have to think about all of that, so people use _fprintf()_; in C, people will go to a lot of effort to avoid having to think about buffer issues. And the reason that _sprintf()_ needs you to supply the buffer is so that no one has to worry about allocating and especially deallocating the buffer, because memory management is a pain in the rear in C. Not just because you have to do it, but also because you have to decide where it's done and which function has to look after it and this generally complicates the code. (For example, _warn()_ can't just free the string it's passed, which means that you can't write '_warn(strformat(fmt, ...))_' because this leaks the string.) Thus I come to the conclusion: > ~~A subtle advantage of garbage collection is that it enables APIs > that would otherwise be impossible, or at least dangerous.~~ Garbage collection is the essential glue that enables my Python versions of _warn()_ and _die()_ to have their simple APIs, because it is what makes Python's '_%_' operator convenient (among many other Python APIs). You could implement all of the operations of the Python version in C, but you shouldn't; in a non-GC'd language, object allocation is to be avoided as much as possible, and certainly turned into someone else's problem. (Hence _sprintf()_ does not allocate anything; finding a buffer for it is *your* problem.)