> that C makes it too hard to use a sorting library that someone competent has written.
This makes no sense to me. What about C makes it hard to use a good library?
This makes no sense to me. What about C makes it hard to use a good library?
A lot of languages now have common tooling (cargo for rust, pip for python, etc) which makes it easier to find and incorporate the libraries you want. Apparently there are tools like https://conan.io/ but they're not as widely-adopted.
C's build system is similarly non-uniform. Many packages use Makefiles, others use different build mechanisms.
C has no universally-agreed error handling mechanism or convention. Whether exceptions or golang's error interface, you can generally assume that a random package in most languages will handle errors the way you expect. In C it's a lot more varied.
Similarly memory allocation - sometimes in a larger application you want to customize how malloc and friends work. How and whether you can do that for a C package is non-uniform.
Mind you the C standard library has a sort() function which will have sensible big-O behavior on pretty much any platform. I suspect this specific problem is more to do with this being kernel-mode code which has a lot of special conditions.
Really? Is it really considered hard to link a library without them? Am I so old that somehow I grew up in a world where linking a library was not considered black magic?
The first issue is actually downloading the dependencies, doing this manually quickly becomes infeasible for any non-trivial project.
The second issue is keeping everything updated, and making sure that all packages are compatible with all other packages. Doing this manually is also not easy.
With C specifically, you need to wrangle different build systems, and once you have them built and "installed", you need to figure out which linker and compiler flags are needed to consume the libraries.
If you are working on a small project with maybe a few dependencies you can do this by hand, but when you get to say, 15 dependencies, it quickly becomes very difficult.
You can use the system package manager on some systems to install libraries I guess (assuming it has the packages and versions that you need), in this case manually managing things could be a lot easier, but you still should be using pkg-config for portability purposes.
If the argument is really "it's impossible to make a good library in C", that's different. I'd very much disagree with that, but it would be to the point.
And I haven't mentioned the lack of a strong universal string type, the way many libraries typedef their own family of different kinds of integer, the way one library will require you to free() a returned structure and another will require you to call my_library_free()...
It all adds up to additional friction.
You don't have to agree! Maybe I am out of date, I haven't really dealt with this since the mid 2000's. I'd be thrilled to hear this isn't an issue any more.
It's not really a matter of whether or not I agree. I was just trying to understand what the assertion was!
I was baffled by the notion because I couldn't think of anything inherent in the language that made it hard to use good libraries. Now I understand that's not really what the assertion was.
With e.g. Java, Javascript, PHP, and Python it's clear to me.
With C, I don't know.
GOOD! I love that C lacks this pollution. Means that code is written for-purpose and tuned for-purpose.
Outside of that you don't need to deal with exceptions in a sorting library, and you can happily make it a single .c and .h
Now do it in C/C++. Absolute nightmare.
Look at how many header-only C++ libraries there are out there. They're making compilation time drastically worse purely to avoid the need to faff with a shitty build system. It's a good trade-off too. I use header-only libraries where possible. They're convenient and popular.
Actually vcpkg seems to be going some way to fixing that but I have yet to convince my co-workers to use it.
Then maybe don't use a shitty build system?
It's true, C is not trying to be a programming environment or tech stack. It's a language, that's it. Whether or not that's desirable depends on what you're trying to do, it's not something that is good or bad in some absolute sense.
You have your choice of build systems, so pick one that meets your needs.
Vcpkg isn't for me, either, because it doesn't solve any problem I have. If it does for you, awesome!
And can I pick the one that my dependencies use too? Didn't think so.
If the issue is that you don't like how the dependency has arranged to build (I'm not sure why you'd actually care, but just in case...), then port the makefile (or whatever) to your preferred system.
Or, another guess, is the issue that you want to build all your dependencies as if they were an integral part of your own project? If that's the case, I would argue that you're doing it wrong and another tech stack would make you happier.
Since we're talking FreeBSD here, thirty years ago we had Modula-3 whose build system is lightyears ahead of anything make based.
In the event you find yourself doing this constantly, write a shell script.
Again the problem is that no package/dependency management for C/C++ means that C is balkanized and more difficult to deal with compared to other languages. Using third party libraries in C is far more difficult and error prone than it ought to be.
Pretty much every language that provides more comprehensive dependency management also provides easy enough access to allow you to NIH/DIY it if you need/want to. For instance contrast this with something like rust where cargo is standard across all supported platforms and provides proper dependency management. You can still call the rust compiler (rustc) and whatever linker yourself if you so desire.
C and C++ dependency installation is "sub-optimal" but it is certainly well
understood. The fact that there are many cross platform, open source projects
written in C and C++ proves this.
If you can't deal with makefiles and scripts, maybe stick to Go and Rust?
* And, sure, in years past I wrote a drop-in replacement for automake/autoconf in perl whose big (speed) advantage was that it didn't spawn a new shell for each check. It was a neat hack, but that's all anything papering over the make(1) interface is.
Many people will in fact do just this.
Though this has not much relevance here as it is about assembly.
It's easy to lose sight of the climb once you're at the top.
It's a bit like criticizing a fish for having no legs.
The problem isn't that it doesn't need one, it's that it doesn't have one. I have no idea why you would think that it doesn't need one.
Well there is vcpkg now anyway so it finally does have one.
> I have no idea why you would think that it doesn't need one.
Is that I have no idea why anyone would think that it does need one.
Perhaps the disconnect is that you are wishing C addresses different use cases than it addresses? That you wish it were a different language? If so, that's fine. Use a more appropriate language for your task. I just find it odd if the criticism of C is that it isn't a different kind of language.
For the same reason any language needs one. What is it about C that you think excludes it from the basic requirement of "using third party libraries"?
# dnf install foo-develNot to mention kernel mode doesn't want a gigantic library package manager to pull in leftpad() from the internet. As mentioned, the kernel libraries on FreeBSD have a qsort, but they didn't in the original commit from 3 decades ago or whatever.
It doesn't have templates/generics.
curl_easy_option_by_name() is already up to 24 characters and there's only two "levels" in curl_easy_*.
Annoyance #2: There's no formal registrar for LIBNAME. This isn't a big deal for popular libraries, but it's a pain having to keep a locally-modified copy of a less popular dependency just because it shares its name with another less popular dependency.
Annoyance #3: LIBNAME_actual_function_name() is a pain to read and using either the preprocessor or static inlines to locally alias function names for the sake of readability is silly.
@2: Agree, although I don't recall this ever happening to me.
@3: Is it? How is libname::actual_function_name() much better?
I actually like to use libname__actual_function_name(), as it further separates "namespace" from function name (unless we need compatibility with C++, as IIRC it reserves all double underscores, not only at the beginning).
This is still the case in C11, Section 5.2.4.1. Did this change in the most recent standard?
> @2: Agree, although I don't recall this ever happening to me.
It happened to me once. I ran across a library from 1994 and another from the 2010s which shared a simple name like "libamc". I'll comb through my records later to figure out the actual name.
> @3: Is it? How is libname::actual_function_name() much better?
It's not, but I wasn't thinking of C++ specifically. (I don't know C++. I've somehow managed to avoid it in many years of writing C.)
I was thinking more like the file-local namespace clobbering offered by Python e.g., from LIBNAME import actual_function_name.
Well, no, it's still marked "just" obsolete. For it to be deprecated or removed there would need to be anybody caring about it enough to put some work. But since it doesn't affect vendors at all (they can just ignore) and users don't complain, it's just a forgotten "law" - still law, but a dead one.
> I was thinking more like the file-local namespace clobbering offered by Python e.g., from LIBNAME import actual_function_name.
Oh, that's... way more than just namespaces. Way more. That would require more fundamental changes and additions. C++ just added modules in C++20 (not sure how well those will catch on), but I don't think something like that is to be expected in C for feasible future.
Suppose I need to define a copy assignment operator for the library's sort function to use. Is there a good way to overload it? Can the library know what the size of each element is based on its type without having to pass it in as a parameter?
You can pass function pointers to the library, but that quickly becomes awful.
/* sort for basic integer types */
void lib_sort_u8(uint8_t *a, size_t count);
void lib_sort_i8(int8_t *a, size_t count);
void lib_sort_u16(uint16_t *a, size_t count);
void lib_sort_i16(int16_t *a, size_t count);
void lib_sort_u32(uint32_t *a, size_t count);
void lib_sort_i32(int32_t *a, size_t count);
void lib_sort_u64(uint64_t *a, size_t count);
void lib_sort_i64(int64_t *a, size_t count);
/* specify a comparator */
void lib_sort_comp(void *start, size_t nmemb, size_t size, int (*compar), const void *, const void *));
/* specify a comparator and an assignment operator */
void lib_sort_assign_comp(void *start, size_t nmemb, size_t size, void (*assign)(void *, const void *), int (*compar)(const void *, const void *));
/* specify a comparator, an assignment operator, and ... */
If my type needs a custom assignment operator, I need each library I use to take that as an argument. One expects the function pointer to take the arguments in the order (src, dst), another as (dst, src), a third specifies the return value as int instead of void, a fourth takes the source argument as "void *" instead of "const void *" in case you want to implement move semantics and a fifth doesn't support custom assignment operators at all.
It's no surprise that people prefer to avoid this.