Write me a routine to dump a struct foobaz, using a void pointer
It is imposible right now, but it is very easy using some conventions
like inheritance in OOP sence.
Really? How? In OOP, someone has to write the method to dump the
object. Even though inheritance can save a lot of work, if this
object has some special private data, you need code to handle that
data.
So your proposal is to include the hole database managment code into
every C program, and to make it the part of the C compiler. This is an
ambigous task. And the only problem is that I know very little (none)
peaple who needs it. There *is* an existing databases and they work, use
one. The object to hold type information is called SQL query.
Have you ever *WRITTEN* a database (in C)? You've got the schema (most
SQL queries, except those that actually create or change tables,
don't contain type information), however you represent it. It's
got, say, a 32-bit int, a 16-bit int, and a double in each record. You
have a buffer you have read a record into. Now, how do you get to
the double? There's probably some ugly casts and adding an offset
to char *, and perhaps either some handwaving about correct alignment,
or it uses memcpy() to copy it into a variable of the right type.
Yes, if you're just USING the database, you don't have to worry
about this stuff.
Try to figure out what you really need. Do you want to implement
something that really requires your run-time type handling. Do you think
No, I said up front it was impractical and required too much overhead,
especially the infinite-size type_t's and carrying around all the type
information.
that the code using type_t will be simplier or smaller then that using
C++ with it's run-time type handling being developed scince 70th? Do you
think that your type_t is better than all OOP techniques?
type_t probably violates a heck of a lot of things that OOP holds
dear. It may be the antithesis of OOP: you can have one function
which handles printing ALL the types, not one method for each type,
and it gets at all the private data for every type.
However, type_t and the related proposal will allow a function
passed a struct or pointer to struct to print out a list of all
that structure's member names and their values *WITHOUT* writing
any function (method) to deal with that particular structure. Just
the structure definition, and declaring one variable of that type
(or pointer to that type).
Good idea but do you expect to include the code for printing every
possible C type (infinity) to a Standart library.
It really isn't that hard. See that %d? Is the matching argument
an int? Nope, error. Each existing printf() conversion has only
a small number of types that should match it. A possible exception
is %p, which just might allow *ANY* pointer type to match it, or
maybe just allow void *.
Code to print every type isn't that hard, and probably isn't that
large. Is it a structure? Print each member name and member value.
Is it an array? Print each element. Is it a pointer? Print it as
a pointer. Is it an integer data type? Print it as an integer.
Using a recursive approach, it's probably not much bigger than printf().
The thing about type_t is that if it's a structure, you can find out
that it is, and you can get a list of the member names and types.
Write some wrapers for string and scanf functions using
struct {
void *ptr;
size_t size;
};
and you are done. It's much easier then implementing general run-time
type handling.
The problem with such wrappers is that you have to actively TRY to
get correct data into them.
Does ir really bother you?
No, but there are some people it bothers a lot. It's probably the same
people who expect free()ing a structure to recursively free everything
member pointers point at, even if what they point at wasn't dynamically
allocated.
Gordon L. Burditt