Generic programming in C

[Ian Collins]

It can, with a little effort, implement qsort as an inline function,
which then allows at least as much optimization as templates do.

Do you know of any that do?

 

[Ian Collins]

Ian Collins a écrit :

Another point is that in my implementation (I do not know if in C++ that
holds)
you can customize the generated code. For instance it doesn't make sense to
have a pointer to objects that are smaller than a pointer size. It would be
much better to store directly the object in the place of the pointer and
access it directly.

I think that's what I said above!

 

[Michael Foukarakis]

you don't give that impression. It seems more like "I don't think this
is a good idea in C and I can't see any reason for it". This is even
after a couple of people have pointed out the possible benefit.

I keep re-reading my first post in the thread, it still seems like "I
don't think this is a good idea in C, can you give me some reasons for
it?". I'm sorry if you feel I should be addressing people and issues
in a certain way different than the one I'm currently doing so.

other than e-penis size.
idiot

[...]

If you disagree, what is the
real incentive behind C metaprogramming?
type safety. A quick and easy way to produce efficient container code..

Finally, a real answer. Comment below.
[...]

given that the language is, by
design, inadequate for that purpose?
well if he's done it plainly isn't inadequate

C is not fully capable of introspection. This is a fact. It is the
reason behind the following:
- the extra preprocessing step(s) in producing the "template library".

C++ jumps through rather similar hoops under the hood

You are correct. C++ is equally inadequate (for JN's approach, that
is).

again you just say that

OK, let's revisit each point:
- Is the library generic? Not if you have to preprocess it for each
different data type you want to store. The void * approach/
implementation, on the other hand, is.
- Is the library user friendly? Not if it introduces an extraneous
step in the building process, which gives more room for errors and
aggravates developers.
- Is the library usable? Yes, if one ignores the above two points.

I don't see those things as saying the same thing. I thought you were
asking for a particular application. Containers don't work that way.
What application *wouldn't* it work on.

You misunderstood, again. The choice (or not) of a custom container
like JNs in a purely academic discussion (such as this, so far) is
irrelevant; the real question is what constraints does it operate
under, what problems it solves (besides storing things in a black
box), what benefits does it have over other container libraries. Do
you still disagree?

find a C++ that uses an STL container and explain why the same sort of
thing couldn't be used with a generic container in C

I didn't realize this was about turning C into C++. Do continue.

ok you've memorised the puffin book of freud...

I am guessing that was meant as an insult, can I choose to ignore you?

I think we're probably done here

Indeed we are.

 

[Nick Keighley]

I perhaps misunderstood your tone but early comment on penis size
doesn't seem like a good way to kick off a purely technical exchange.
Perhaps this is some sort of cultural difference (I've no idea of your
national or cultural background so don't take this as an attack on
either). Where I come from this sort of remark is rude. If I was
having a problem getting through to someone or they were being
particularly arrogant I might say something like that. But I'd pretty
well expect meaningful technical discussion to be over by then.

On Apr 20, 5:19 pm, Nick Keighley <[email protected]>

other than e-penis size.
idiot
[...] what is the real incentive behind C metaprogramming?
type safety. A quick and easy way to produce efficient container code.

C++ jumps through rather similar hoops under the hood

You are correct. C++ is equally inadequate (for JN's approach, that
is).

why i C++ inadegate for egneric programming (I'm not trying to be
argumentative, I'm curious). The template syntax is pretty horrid but
it seems to work ok for basic containers.

OK, let's revisit each point:
- Is the library generic? Not if you have to preprocess it for each
different data type you want to store. The void * approach/
implementation, on the other hand, is.

well we're both expressing opinions here. But I don't see the
preprocessing step as particularly onerous (and C++ does it as well)
and with void* you've lost type safety (and possibly efficiency). If
you rate the simplicity of void* over type safety then I doubt someone
who is willing to suffer the code generation step in exchange for the
tyep saety is goign to chage your mind. This is why I thought your
mind was already made up (not necessarily a bad thing).

- Is the library user friendly? Not if it introduces an extraneous
step in the building process, which gives more room for errors and
aggravates developers.
ibid

- Is the library usable? Yes, if one ignores the above two points.
ibid



You misunderstood, again. The choice (or not) of a custom container
like JNs in a purely academic discussion (such as this, so far) is
irrelevant; the real question is what constraints does it operate
under, what problems it solves (besides storing things in a black
box), what benefits does it have over other container libraries. Do
you still disagree?

no. But I can't see an application that needs a container that
couldn't work with Jacob's containers. I wrote a nodddy graphical
editor (in C++) it had a container of graphical objects. Which I think
was a std::vector of pointers to graphical objects. One of Jacob's
containers would do the job if I wanted to rewrite it in C.

I disagree with his desing decision to have a "generic" container
interface that might be an array, a linked list or a tree etc. But
that's another issue.

I didn't realize this was about turning C into C++. Do continue.

well there aren't going to be many examples from C as it doesn't have
standard containers...

You don't think the code gen overhead is worth the tyep safety and
possible efficiency. Ok.

I am guessing that was meant as an insult, can I choose to ignore you?

Puffin books were published by the Penguin publishing company and were
specifically aimed at children. Amateur Freudian analysis like this I
fell deserves such a comment. I'm amazed! You mean you weren't trying
to be rude to me? What? you were trying to help me over psycho-sexual
hangups? Why thank you! [saracasm]

Indeed we are.

I think we've made our points both on the technical and on the psyco-
sexual fronts

happy programming

 

[jacob navia]

Michael Foukarakis a écrit :

OK, let's revisit each point:
- Is the library generic? Not if you have to preprocess it for each
different data type you want to store. The void * approach/
implementation, on the other hand, is.

Please, I have told many time in this discussion that the void *
approach is supported by the library. Additionally (and NOT instead of)
the library supports a templated form.

- Is the library user friendly? Not if it introduces an extraneous
step in the building process, which gives more room for errors and
aggravates developers.

If preprocessing a template is too much for you, you can always
use the void * approach.

- Is the library usable? Yes, if one ignores the above two points.

Thanks. The library is usable then, because it supports the void * approach.

For *me* the templated approach was necessary since I want to propose
a version of ALL containers for the standard data types of C
int, long long, double, long double, and character strings.

Templates allow me to build the bulk of the code for those with no
extra effort, and add a specialization when needed. Numeric containers
will support extra functions like "Accumulate", and the four operations
(element-wise)

You misunderstood, again. The choice (or not) of a custom container
like JNs in a purely academic discussion (such as this, so far) is
irrelevant; the real question is what constraints does it operate
under, what problems it solves (besides storing things in a black
box), what benefits does it have over other container libraries. Do
you still disagree?

Each container solves a particular problem. Bitstrings are good at
boolean operations, flexible arrays allow easy to use storage of
like-elements, trees allow you for fast searching, dictionaries allow
you easy searching for symbol tables, etc etc. Containers are a general
data structure and there is almost no application that doesn't use them
in some way.

 

[bartc]

- Is the library user friendly? Not if it introduces an extraneous
step in the building process, which gives more room for errors and
aggravates developers.

It sounds like this step is only done infrequently (when the template is
first applied to a new type), and not needed for every compile or build.

 

[lawrence.jones]

Do you know of any that do?

Not off hand. I don't think qsort is generally considered a common
bottleneck deserving of special optimization.