Hacker News Reader

Comment by tptacek | Hacker News Reader

Library of data structures and algorithms (STL) is part of the language. With C I would have to either depend on a 3rd party library or had to write basic algorithms of my own in 1970's manner.

Broken record here: there is a middle ground between importing a "3rd party" library (usually this means GLib) and writing your own Red-black tree: you can just port a lot of the STL back to C. I did that 10 years ago to get a workable straight-C RB tree by specializing STLPort's <map> on void-star. It's been tremendously helpful.

Another idea that more C code should adopt from STL is <vector> --- making a thin wrapper around resizable arrays the go-to container, rather than linked lists which are the de-facto go-to today.

View on HN

> With C I would have to either depend on a 3rd party library

I can never quite get past this one. There seems to be this fantasy that you can write your code without any kind of dependencies whatsoever, and that the user can just drop it into their environment and have it work. Here's what ZeroMQ says about how to install their software:

1. Make sure that libtool, autoconf, automake are installed. 2. Check whether uuid-dev package, uuid/e2fsprogs RPM or equivalent on your system is installed. 3. Unpack the .tar.gz source archive. 4. Run ./configure, followed by make. 5. To install ØMQ system-wide run sudo make install. 6. On Linux, run sudo ldconfig after installing ØMQ.

How is depending on the presence of a massive build system, a set of file system utilities, and a compression utility different from depending on a "3rd party" library that contains an implementation of an RB tree?

How is depending on the presence of... a compression utility different from depending on a "3rd party" library that contains an implementation of an RB tree?

The other nits are fair, but this one is not. You mean gzip and tar? Even in whatever hell has banned these tools, it is possible to develop in both C and C++. Downloads just take longer.

OK, so you need some stuff to build.

The point is the runtime dependencies are small.

It also requires a compiler to build. Where's your rant about that?

(I keep promising myself to stop reading HN threads about C and C++ due to so much inanity. Looks like I caved.)

> The point is the runtime dependencies are small.

Is that the point? Because that makes absolutely no sense to me at all in a world of modern linkers, shared libraries, etc.

My assumption is that the OP was concerned about reducing the user's dependency list. And on that score, yes: I could have added a compiler to my list.

If "the user" is compiling code then yes, that is a dependency for them or their package manager/ports system to track. However many times the user installs a binary and never needs the source.

The other thing, I think this highlights one difference between C programmers and others, and maybe explains our disagreement. People coding in C often care a lot about the object code. It's not all that uncommon to look at the assembly and question what your compiled has done and make tweaks to get the binary looking better. Hence the disconnect between me saying runtime dependencies are the most important thing and you saying you don't want to install autotools to build. To me the latter complaint comes from a completely different planet.

I think you're making it too complex (or else I am). I think the OP is making a kind of "batteries included" argument (a la Python) -- that is to say, "it's better when the language has everything built in, as opposed to farming things off to external, 3rd party libraries."

All's I'm saying is that that seems to me pretty silly. It can't be about reducing the user's burden, because you're going to burden the user anyway with all kinds of toolchain dependencies. It can't be about the runtime, because the user will, except in rare circumstances, hardly notice; if they have autotools, they have glib.

I can think of million reasons not to use C. But, "Well, I don't know. I'd have to use a third party library. . ." Really?

A lot of third party libraries are just header files you can put into your application directly. How is this even worth complaining about?

Actually, I wish C had support for templates. It doesn't seem like templates go against C's core philosophy, and not having to cast void*'s back and forth would be nice.

For a while I thought C + templates would be a great idea as well. In theory templates are a much more powerful and expressive way of generating code than macros/xmacros.

However after playing around with the idea in a few C++ modules I was writing I came to the conclusion that it's just not worth it. Part of what makes C so enjoyable to write is its relatively "weak" typing and the flexibility that comes with that, primarily freely casting between pointer types including void*'s where necessary. Templates fight against that at every opportunity and I found myself spending more time trying to figure out how to wrangle my code into the template type system than actually making progress on the problem at hand. Newer additions like C++11 constexprs take that type-system frustration to an entirely new level.

> I wish C had support for templates

Generics. Polymorphic functions and collections don't require the complexity of C++ templates.

C sort-of-does have a template facility through macros. Some things about it are awkward - e.g., if you need to generate identifiers (which is traditionally done with __LINE__, which is not safe) - but it can mostly give you what templates do, if you know what you are doing.

You don't have to cast void * back and forth to anything.

   void *p = /* ... */;
   char *q = p;

Despite what the C++ weenies will say this is valid C! Please do not commit this cardinal sin:

   char *p = (char*)malloc(n);

No no no! No need to cast that! Please just write:

   char *p = malloc(n);

And if somebody tells you that won't compile without an explicit cast, please kindly remind them what language you are writing.

[Actually I agree with you that C++ templates are really nice, chiefly for the reason that they allow you to avoid function pointers. In C++ you can pass your "callback" to a template and it gets inlined right with the body of the function.]

Very true. It's my biggest annoyance with Visual Studio when I write straight C code that the intellisense error checker moans about this.

The compiler is of course perfectly happy when it's running in C mode. But then I'm still upset about <stdbool.h> it should get off my damn lawn.

Specializing a STL container to void-star is a far cry from what you get with the STL templates. You lose type safety (casts everywhere) and give up the nice value semantics of C/C++ (no vector<some_struct>).

Side note: red-black trees are actually pretty terrible on modern hardware for the same reason linked lists are, b-trees are usually a better alternative.

Obligatory Sean Barrett reference: http://nothings.org/stb/stretchy_buffer.txt - (though, see the warning on http://nothings.org/ about strict aliasing optimizations)

Why does this code have to be so ugly :'( I'm sure it's useful, but I could never bring myself to use "that".

Have you ever looked at the STL internal implementation of <vector>?

Different strokes for different folks, but ... I think stb arrays are beautiful in comparison.

Most of the ugliness in stdlibc++ comes from the ugly ass naming conventions that are (or were) inherited to prevent conflicts. The quality of implementation in the STL is fairly high, if a bit old.

Reply on news.ycombinator.com