They aren't C++ inventions, but I wasn't calling them as such.

I did not really mean to say that was what you meant so much as I was questioning the wording because I felt that it could make it a little confusing as to the origin of such techniques. I did indeed misread generic as genetic. I did a little reading, and have a bit of a question on that. From what I have seen, with generic algorithms, it seem that we are talking in terms of templates, essentially. While I am guessing that there would be good reason not to do this, would it be possible to implement something similar to templates via unions in C? Perhaps I am thinking along the wrong lines, and it may be something that would be ridiculous amounts of work to build something that is handily available elsewhere, or some other technique can take the place of. Primarily, I just wonder as to the possibility as a matter of curiousity.

Sorry, I realize that they are not the same, I was just asking if there was some roundabout, not necessarily sensible way that you could massage similar behaviour (the part about accepting different types), and create something similar. I realize that it may make no sense to actually do that, just wondered if it would be possible.

It may also be that I am misunderstanding more than one thing (history suggests this is indeed a worthwhile consideration). It was just intended as a question of idle curiousity.

Most of this thread is rather vacuous.

Differences in program implementation are much more a function of the programmer(s) involved than the language(s) involved. You can write C-like code in C++, you can write C++-like code in C. You can write Haskell-like code in both with enough boilerplate.

Of course, there's also languages like Java, in which all programs asymptotically approach utter crap.

*snip*

I really have to agree with what ApochPiQ is saying here. It really make a lot of sense and I have come to the same conclusions over the years. There really is no point to making one language into another language. For instance with C it is a procedural language. There is really no need to force it to be object oriented. I understand for instance GTK built an entire object system in C to make GUI programming easier but why X11 got by without doing this and so did ncurses. Sure the API's are a mess but it works and is reliable. If you want objects it would be better to just use a language that provides OOP.

The general idea is that it is not worth the effort to fight against your language unless it is the only language you have available (often in the case of embedded all you have is C).

The largest problem I see is that programmers are stubborn and form religions around what they enjoy to use and defend it tooth and nail even if they are totally off base.

It is not just languages it is also editors, ides, gui kits, and the list goes on and on. It is really just hot air flying around it is best to just evaluate and learn and then choose what you want to use for the job. It is best not to over complicate the evaluations and it is best to avoid the classic holy war information out there. Educated decisions always win out over the head bashing baseless arguments.

but why X11 got by without doing this and so did ncurses.

X11, ncurses, and GTK each do completely different things. Structural dissimilarity should be unexpected.

Differences in program implementation are much more a function of the programmer(s) involved than the language(s) involved. You can write C-like code in C++, you can write C++-like code in C. You can write Haskell-like code in both with enough boilerplate.

Between possibility and practice lies a gulf as deep and as broad as that between practice and perfection. I can play baseball, but the difference between me and a baseball player is significant. Calling a conversation vacuous because it concerns the real differences between languages, is contrarianism at its least useful.