
C for all: Parametric polymorphism in C - r0naa
http://plg.uwaterloo.ca/~cforall/
======
kazinator
> 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.

------
huhtenberg
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](http://plg.uwaterloo.ca/~cforall/typesystem.html)

~~~
Rexxar
> 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++.

~~~
Qantourisc
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 ?

~~~
mbel
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.

~~~
bsenftner
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.

~~~
catnaroek
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.

------
filereaper
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](http://plg.uwaterloo.ca/~usystem/uC++.html)

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

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

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

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

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

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

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

------
anon3_
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](https://news.ycombinator.com/item?id=9827051)

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

~~~
xamuel
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".

~~~
the_why_of_y
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)

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

