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.

unions aren't the same thing as templates.

You can do something similar by writing complicated macros using the token pasting operator ## to build new names out of the macro arguments (e.g.

#define DEFINE_CREATE_LIST(type) type* CreateListof##type { /* code goes here, need to be all on one line or extend line using \ */ }

so when you use DEFINE_CREATE_LIST(int) it pastes a function definition called CreateListOfint into the source. You need another macro to create a list of pointers though. And it is nasty code templates much nicer (although the syntax is hairy).

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.

Yes, use macros and token pasting as I said above. You need to use several macros (one to paste all the code in to the source) and others to call the functions by building the correct names from the types (so you could have

#define LIST_PUSH_BACK(type, data) ListOf##type##_push_back(data)

etc.

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.


But again, this has less to do with the language that most people here seem to think. Ultimately, languages are almost irrelevant for most software, and mostly irrelevant if you're still learning to program. It takes a lot of experience and objective insight to understand the strengths and weaknesses of various languages, and it takes extraordinary discipline to effectively leverage multiple languages. Chances are your code will have a style that resembles idiomatic code in your "preferred" language and paradigm, regardless of what host language you're actually writing in.

This is why people never can agree on what languages are capable of what, and what languages are preferable for what.

Ultimately it's all a giant holy war and not worth wasting brain cycles on. Turing equivalence is a rather cliche thing to bring up in a language war, but it's basically true: with enough work, you can write anything in any language that's Turing complete. The only important difference between languages is how easily they express certain concepts.

When it comes down to it, most programmers don't actually understand how concepts and languages map to each other, except in the vaguest of senses. (I include myself in this indictment, by the way.) They have an idea of how they personally would do things, but it's rarely really objective. In the end this just fuels the holy war.


My advice for the OP: don't sweat it. Learn many languages if you can, because that will help you understand what tools are suited for particular jobs. But don't bother getting mired in the minutiae of how to make language X behave like language Y.

Just write some fucking software.

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.

I really don't follow your point here.

I didn't say the thread was vacuous because it "concerns the real differences between languages." I called it vacuous (and not all of it, just most of it) because the discussion here has virtually nothing to do with real differences between languages! It has to do with how to make one language act like another, and techniques for that, with a little bit of waffling over whether or not it's a good idea.

Over the course of the thread, conversation has steadily drifted away from what actually separates languages, and more towards how to kludge things so they feel identical.


Hence my followup statement: differences in program implementation are much more a function of the programmer(s) involved than the language(s) involved. I stand by that fully and see nothing in your analogy to baseball that contradicts what I said.

Then there's the rest of my post, which also stands, and again I don't really see why you're calling it "contrarianism" or not-useful.


Obviously some people have found it useful, so it isn't objectively worthless. If you have genuine objections to what I wrote on a factual level, I'd love to hear them. Otherwise, just complaining because I didn't jump into the holy war is rather silly.