C for all: Parametric polymorphism in C | Hacker News Reader

C for all: Parametric polymorphism in C

plg.uwaterloo.ca

68 pointsr0naa25 comments

> Structure Prototypes: This was proposed in February 1998 in comp.std.c by bill@cafe.net (Kaz Kylheku). The idea is that eliding member names in a structure prevents access to the members.

Hey, thanks for the credit.

This has no chances of going mainstream, but this is a thoughtful and careful exploration of a C extension. Type system [1] is nicely done (though I think it looks a bit clunky in application).

Tangentially related - once you worked with C long enough, the lack of of "templates" becomes pretty obvious. If you need two functions that do the same thing for two different input types, you have two options - wrap it into a multiline define or use one generic function and use a callback to deal with type differences, a'la qsort(). Neither is exactly ideal.

Does anyone know of C dialects with some form of template support?

[1] http://plg.uwaterloo.ca/~cforall/typesystem.html

> Does anyone know of C dialects with some form of template support?

C++, but I'm sure it's not the answer you want.

It would be nice if C++ compilers had more fine grained switch to activate only functionality people want to use. It would be better, IMHO, than creating a new incompatible language each time. A "C + template" would be useful for many people who don't want the full C++.

How does the extra functionality impact the final binary ? Or do the compilers add extra things you don't need even if you don't use them ?

C lang has certain features that C++ doesn't. Most notably the "restrict" keyword to make the compiler aware that you don't intend to alias a pointer. AFAIK there is no portable way to do this in C++. This is relatively important feature in HPC. So yeah, I'd very much support the idea of "C plus templates", at least in my field this would get a lot of usage.

The feature may not be in the C++ standard but the main compilers support it anyway (__restrict__ in GCC and Clang, __restrict in MSVC).

Most of the C++ features does not require compiler to add anything extra to the binary, there are however some exceptions from this rule, e.g. exceptions (no pun intended) and RTTI.

The biggest problem with using full C++ as C + <small subset of C++ features> is that at some point people will stop writing in C style and start to use STL and design code using C++ idioms. You can probably try to fight this with coding standards, linters and other tools but policing people will require some additional effort.

Just never put STL into your environment. What's what I've seen at a number of C purist dev shops. At first, younger C++ developers complain about the missing STL, but if they actually know how to write the algorithms STL provides, their complaints die after some ribbing from the old guys. It's actually something of beauty when a developer realizes how much of a crutch STL had been to them, and the ease of working without it. Code complexity reduces too, because STL seems to encourage creating complexity over simplicity. Teah, it's not supposed to be that way, but we live in the real world.

I'll be the last one to say the STL (or, rather, its standard library port) is pretty, but damned should I be if I need to reimplement the same data structures and algorithms over and over.

Parametric polymorphism is something every statically typed programming language should have in 2015. I'm aware templates aren't quite parametrically polymorphic, but it's still better than nothing.

Like what? You can turn off exceptions.

C11 does have _Generic to make those multiple functions a little easier.

There's a third (still clunky) option: `#define` parameters before `#include`ing a template file.

Peter Buhr also teaches CS343: Concurrent and Parallel Programming.

CS343 uses uC++ which has coroutines, threads, monitors and other constructs used to teach advanced control flow.

[0] http://plg.uwaterloo.ca/~usystem/uC++.html

[1] https://www.student.cs.uwaterloo.ca/~cs343/

[2] http://plg.uwaterloo.ca/~usystem/pub/uSystem/uC++book.pdf

Just when I was looking for C-with-tuple-and-destruct. Brilliant.

This is almost 20 years old, isn't it?

The text refers to a C9x standard, so it must predate the standardization of C99.

Nope, they link to a draft of the spec (http://plg.uwaterloo.ca/~cforall/refrat.pdf) which dates from May this year.

Interesting. I guess it's been resurrected because most of the other materials are dated between 1997 and 2003.

We're reaping the benefits of C's resistance to feature bloat.

C powers the daemons and operating systems of the world.

When you're working in the field, C's transparency and absence of esoteric programming voodoo is a feature, not deficit.

Interest posting made today similar: https://news.ycombinator.com/item?id=9827051

How does "undefined behavior" not qualify as "esoteric programming voodoo"?

UB is not something that a competent programmer does intentionally.

You shouldn't ever run into a situation where you'd tell your fellow programmer, "Hey, on line 300 here, you're doing UB, stop it", only for them to say "No, I'll do UB if I please".

With C++ on the other hand, you could very well run into situations where you plead with your fellow programmer, e.g., "please stop overloading operators in this opaque and unmaintainable way", and then they tell you, "so what, that's our in-house style and it has official language blessing".

Sadly I am yet to work in an enterprise environment that fully understands the meaning of "competent programmer" in their hiring process, specially for offshore resources.

C++ has roughly the same undefined behaviors as C, plus a bunch of additional ones for the C++ specific features.

Also, you'd be surprised how many stubborn C programmers apparently think that mutable global variables are an excellent and convenient time-saver. (Not that C++ programmers do inherently any better here, cf. Singleton)

The C spec also has a handy appendix listing all undefined behavior, which IIRC the C++ spec does not have.

Yet even the most competent programmers will have UBs crawl into their code where they do not expect them. Sure, C has less pitfalls than C++ ; but it has its own as well. (see previous discussion on HN "What is C", John Regehr's blog, ...)

In the field?

Reply on news.ycombinator.com