API Design

[Kaz Kylheku]

I'm aware of Boehm;

Yes, you are---now. Your earlier posting /clearly/ shows that you
are not aware that GC exists for C programs.

it doesn't really seem to be taking the world by
storm.

``Not taking the world by storm'' is not nearly the same thing
as ``not done yet''.

I don't intend it as a put down but it's not really the easiest
thing to set up.

$ ./configure
$ make ; make install

For the record I've used and have no problems with Boehm's GC lib.

Yet, ``[gc] isn't done yet''. Hmm!

 

[Keith Thompson]

stan a écrit : [...]

The truth is that for
most of the cases where GC would be most useful, C may not be the best
language choice.

Always the same story. C is bad language when you want to program
an application. Look, if you want, so be it. Please go to another
discussion group then.

jacob, I'm sure that you understand the difference between "C
may not be the best language choice" and "C is [a] bad language".
Please consider demonstrating that knowledge next time you post.

 

[stan]

stan a écrit :

With lcc-win there is nothing to setup. And anyway,if you
do not want to recompile it and use a binary library
it is as easy as using any other library. Use the
#include and link with the library.

My last brush with lcc was some time ago; I didn't know it had GC
until one of your earlier posts. I don't know anyone who is using
lcc-win but I admit that doesn't mean there aren't any.

This is just your opinion. It i widely used, has been ported to
a variety of systems, and there are thousands and thousands
of users. Gcc has adopted it too and distributes it with the
source code of gcc, zs far as I remember.

Where do those numbers come from? Admittedly, I don't personally know
every developer but in my small world I don't know any C developer who
is actively seeking GC for any of their current projects.

Well, you see?

Not really. I also regularly work without GC and I don't feel I need
it for everything I do nor do I see a need to add it to the language.

Yes. As everything. Nobody is telling here that is the solution for
all software problems.


Always the same story. C is bad language when you want to program
an application. Look, if you want, so be it. Please go to another
discussion group then.

Do you want everyone who disagrees with you to leave or just me?

Your request notwithstanding, I probably won't hang around clc all
that long. I've been coming and going for a long time and things don't
seem to really change much. The signal to noise is not really all that
good and it takes too much time and effort to weed through to find
anything useful.

As for GC I'm agnostic; I don't find much in common with the "never" or
the "must have" camps. But I'm unconvinced it needs to be added to the
C language. I have no reasonable doubt that C will not fade away
rapidly simply because it lacks GC. So far the arguments in this
thread haven't been convincing.

 

[stan]

Yes, you are---now. Your earlier posting /clearly/ shows that you
are not aware that GC exists for C programs.

Your guess would be wrong about my prior experience. The first time I
recall hearing about it was on clc++ from James Kanze. I don't
recall exactly when that happened, but it wasn't recent.

``Not taking the world by storm'' is not nearly the same thing
as ``not done yet''.

I seem to have lost you. The sentence was about Boehm's GC not taking
the C programmer world by storm.

While it has drifted way off the topic this thread was about API's and
the context of the statement was about developing a GC library. Since
Boehm's GC currently exists and yet this thread included developing GC
in a library a reasonable person could conclude that the status quo
isn't the "ULTIMATE GC LIBRARY". From there "not done yet" isn't much
of a stretch.

So we have:

1. Boehm - not taking the world by storm.
2. ULTIMATE GC library - not done yet.

Better?

I don't intend it as a put down but it's not really the easiest
thing to set up.

$ ./configure
$ make ; make install

For the record I've used and have no problems with Boehm's GC lib.

Yet, ``[gc] isn't done yet''. Hmm!

I won't argue, try to explain myself, or try to convince you. I don't
believe what I said was all that hard to understand, but I'll give you
the last word if you feel to need to interpret further.

For my money I've already contributed enough to thread drift.

 

[Keith Thompson]

Keith Thompson wrote: [snip]
GC has been implemented. See, for example,
<http://www.hpl.hp.com/personal/Hans_Boehm/gc/>.

I'm aware of Boehm;

Yes, you are---now. Your earlier posting /clearly/ shows that you
are not aware that GC exists for C programs.

Your guess would be wrong about my prior experience. The first time I
recall hearing about it was on clc++ from James Kanze. I don't
recall exactly when that happened, but it wasn't recent.

``Not taking the world by storm'' is not nearly the same thing
as ``not done yet''.

I seem to have lost you. The sentence was about Boehm's GC not taking
the C programmer world by storm.

While it has drifted way off the topic this thread was about API's and
the context of the statement was about developing a GC library. Since
Boehm's GC currently exists and yet this thread included developing GC
in a library a reasonable person could conclude that the status quo
isn't the "ULTIMATE GC LIBRARY". From there "not done yet" isn't much
of a stretch.

Kaz wasn't the only one who misunderstood what you wrote. And yes,
I'd say it's quite a stretch.

It seemed perfectly clear to me that your phrase "not done yet"
implied that GC had not been implemented for C. My own response,
citing Boehm, was simply intended to refute that implication.
Apparently that wasn't what you meant, but since there had been no
mention of an "ULTIMATE GC LIBRARY" (I question the existence,
even potentially, of an "ULTIMATE *anything* LIBRARY"), and
since you hadn't indicated that you knew about Boehm, I think our
interpretation was a reasonable one.

Again, here's what you wrote (taken slightly out of context, but I
don't think that alters the meaning):

The no-GC crowd is never going to code up a GC system
(understandably) and the GC crowd hasn't done so yet.

So we have:

1. Boehm - not taking the world by storm.
2. ULTIMATE GC library - not done yet.

Better?

Ok. I understand now that you didn't mean to say that GC hasn't
been implemented in (or for) C. But if you'll go back to what
you wrote and re-read it, without making too many assumptions,
I think you'll see why you were misunderstood.

[snip]

 

[Nobody]

Is programming in a considerably cutdown (and perhaps specially customised)
C language, actually programming in C, or in something that just looks like
C, complete with curly braces, semicolons and funny type declarations?

Modern C compilers for all but the very simplest microcontrollers
tend to follow the C standards quite faithfully. Not to the extent that
you can't find deviations, but to the extent that you don't need to
re-work real-world C code for the sake of the compiler.

Where C code written for such systems uses non-standard features, it's
more likely to be because it's appropriate to do so (e.g. because you need
to do things which aren't covered by the standard, or because the
extensions offer significant performance benefits) than because the
compiler forces you to do so.

 

[Colin Paul Gloster]

On Wed, 23 Dec 2009, Keith Thompson posted:

|-------------------------------------------------------------------------|
|> stan a écrit : |
|[...] |
|>> The truth is that for |
|>> most of the cases where GC would be most useful, C may not be the best|
|>> language choice. |
|> |
|> Always the same story. C is bad language when you want to program |
|> an application. Look, if you want, so be it. Please go to another |
|> discussion group then. |
| |
|jacob, I'm sure that you understand the difference between "C |
|may not be the best language choice" and "C is [a] bad language". |
|Please consider demonstrating that knowledge next time you post." |
|-------------------------------------------------------------------------|

Keith Thompson,

Jacob Navia actually posted: "C is bad language when you want to program
an application"
instead of "C is [a] bad language".
Please be fair. Anyhow, C actually is a bad language.

Sincerely,
Colin Paul Gloster

 

[jacob navia]

Colin Paul Gloster a écrit :

> Anyhow, C actually is a bad language.

Sincerely,
Colin Paul Gloster

OK. Then

(1) Do not use it

(2) Do not participate in this forum. Use Python/C++/LISP/whetever

What is the point in going to a forum about C and telling people that it is a bad
language?

Just trolling.

 

[Colin Paul Gloster]

On Mon, 21 Dec 2009, BGB / cr88192 posted:

|-------------------------------------------------------------------------|
|"[..] |
| |
|my reasons for using C are varried, although, part of it may be that [..]|
|[..], and also I use |
|some amount of "reflection", which does not work so well with C++ (mostly|
|giving the non-standardized name mangling and compiler behaviors, ...). |
| |
|[..]" |
|-------------------------------------------------------------------------|

Hi!

How and why do you use relection in C?

With kind regards,
Colin Paul Gloster

 

[Colin Paul Gloster]

On Thu, 24 Dec 2009, Jacob Navia posted:

|----------------------------------------------|
|"Colin Paul Gloster a écrit : |
| |
|> Anyhow, C actually is a bad language. |
|> |
|> Sincerely, |
|> Colin Paul Gloster |
| |
|OK. Then |
| |
|(1) Do not use it" |
|----------------------------------------------|

Thanks.

|----------------------------------------------|
|"(2) Do not participate in this forum." |
|----------------------------------------------|

This is an unmoderated forum and I participate.

|----------------------------------------------|
|" Use Python" |
|----------------------------------------------|

No, thanks.

|----------------------------------------------|
|"/C++/" |
|----------------------------------------------|

No, thanks.

|----------------------------------------------|
|"LISP" |
|----------------------------------------------|

No, thanks.

|----------------------------------------------|
|"/whetever |
| |
|What is the point in going to a forum about C"|
|----------------------------------------------|

I have noticed that the thread (which I have begun reading on another
newsgroup) was started only on so I looked at
for contributions which I had missed.

|----------------------------------------------|
|" and telling people that it is a |
|bad |
|language?" |
|----------------------------------------------|

Keith Thompson failed to correctly paraphrase the sentiment
"C is bad language when you want to program
an application"
issued by you. I pointed this out, and I confirmed that the statement
wrongly attributed to you was true anyway. If you really like garbage
collection and really are so naive as to like C, then perhaps you
should read the book "Modern Compiler Implementation in C", which does
not exactly flatter C and which uses garbage collection throughout
(without actually truly compiled and run C code).

Appreciation that something is bad is not the same as not using it
with due care and attention. Using something bad without realizing it
would be even worse.

|----------------------------------------------|
|"Just trolling." |
|----------------------------------------------|

No.

 

[Kenny McCormack]

jacob, I'm sure that you understand the difference between "C
may not be the best language choice" and "C is [a] bad language".
Please consider demonstrating that knowledge next time you post.

Technically, you are correct. However, in the language of character
assasination, and particularly, in the context of this newsgroup, the
phrase "X may not be the best" usually translates as "X is bad".

Be honest with yourself. When you hear that sort of phrase is real
life, from people who are not well-disposed towards you, that is the
message that you take from it. Isn't it?

 

[BGB / cr88192]

On Mon, 21 Dec 2009, BGB / cr88192 posted:

|-------------------------------------------------------------------------|
|"[..]
|
|
|
|my reasons for using C are varried, although, part of it may be that
[..]|
|[..], and also I use
|
|some amount of "reflection", which does not work so well with C++
(mostly|
|giving the non-standardized name mangling and compiler behaviors, ...).
|
|
|
|[..]"
|
|-------------------------------------------------------------------------|

Hi!

How and why do you use relection in C?

how:
piles and piles of code implementing it (this is hardly a small piece of
code);
some use of API's like ToolHlp, DbgHlp, ... (these are provided by Windows
to help implement debuggers). (much of this has Linux analogues, many via
libdl and extensions, ..., but keeping the Linux port alive and well has
been, well, lacking...).

customized in-memory linking code, a custom DLL loader and an x86
interpreter;
a database to manage metadata (shared variable, function, and type
declarations, ...);
an dynamic C cimpiler (more needed for eval and dynamic loading, not so much
for reflection, but it does have uses getting data loaded into the DB);
....

of note, machine code, and plain compiled C, does not, in itself, contain
sufficient information to allow for reflection, rather, it requires a whole
lot of "support machinery" which serves in part to gather and build this
information, and a lot of dynamic code generation to actually be able to
make use of it for anything.


for example, one can realize after writing a C compiler that, for its
internal operation, it generates piles of useful information, but nearly all
of this is lost with the generated code.

a database was then used to capture some of this data, so that data can be
mined from any code or headers which pass through this compiler (going
further, I eventually ended up adding a "dummy mode" to the compiler upper
end, which basically mines info but does not bother generating any code).

the info in the database is then used in conjunction with information in the
run-time linker, mostly to allow accessing variables, dynamically calling
functions, ... (basically, I can do something sort of like the LISP-style
'apply' with C function pointers, including with dynamically-typed
arguments, given limited static<->dynamic auto-marshalling exists).

a downside:
I am more recently using MSVC for building, and this strips symbols/... from
produced PE/COFF images, which hurts the ability of my dynamic code to
access any "non-exported" statically-compiled+linked code (say, in DLL's),
however, in practice this has not hurt too badly (some of this could be
helped if info from the PDB files were used, and it were required that code
always be built with debugging options, but given in MSVC this breaks
optimization, I have not been willing to generally accept this cost).

(when I was building with GCC, it left symbol info in the produced PE/COFF
images, and I would mine this info as well).


another downside:
dynamic C compilation seems nicer in theory, as it can be noted that C does
not compiler "instantly" (nor is my compiler entirely bug-free), which
someone hurts my motivation to compiler the C code at run-time (although,
dependency tracking and object-file caching does help here, since it can
limit re-compiles mostly to dependency-check failures...).

the result is that I end up doing a lot of dynamically generated code in
ASM, which is not a good option either, and I currently lack any good
"middle of the road" language (although, I had considered a wide range of
options, including allowing a C variant which was relaxed some and able to
"see" all of the declarations in the metadata DB without need for explicit
declaration or import, hence "header-free", ...).

similarly, the effort has not been extended to cover C++ for various reasons
(for example, MSVC and GCC have different ABIs, and my framework yet still
another ABI, ...).

(now consider that there is a half-assed Java implementation in the mix,
....).


and, further:
although it is possible to patch functions at runtime, this is ill-advised
with any statically compiled code (EXE and DLL images), since there is
little to say that the patch will actually effect said static code, or that
this patching will not instead crash the statically-compiled app. there are
also some edge cases where this patch will not be properly updated (say if
function pointers exist to the pre-patch version).

a workaround exists, however:
it requires being explicit about patchable functions (kind of defeats the
purpose of patching);
it requires compiling patchable code via my compiler;
the same effect is easily enough done in static land via specialized use of
function pointers (or via COM interfaces).


why:
all this is a harder issue...


sadly, I have since noted that there are many cheaper and simpler ways to do
nearly everything I have done, giving me doubts at times as to whether this
all was a worthwhile effort...

after all, one can hard-code nearly any of this, or address many of these
cases though special-purpose functions or by doing (generally terrible)
things with pointers, ...

I am left also thinking that maybe had all this actually been "designed"
(rather than hacked and extended in a piecewise manner), a much simpler
piece of technology could have addressed all these uses, ...


in some ways, it is sort of like .NET without the bytecode.
(and, hence, no direct binary compatibility between Win32/Linux
x86/Win64/Linux x86-64... or at least apart from using the interpreter...).

any what if one wants interpretation or bytecode, well then I have an
interpreter, which in turn does x86 (actually, this uses a POSIX-derived set
of APIs, and supports multiple processes, sockets, shared memory, ..., but
uses PE/COFF rather than ELF or similar...).

and, in turn, the world visible from the interpreter is not too much
different from that I tried to escape, as, once again, it is largely without
reflection or high-level abilities (although, these could be added as
APIs...).

but, nearly all of my stuff does not work cleanly between disjoint address
spaces, which is, lame...
(although, eval would not be difficult to pull off, since it would just
require sending the object over to the interpreter and linking it there).

instead I am left considering the possibility of something like DCOM, which
is something I initially terribly wanted to avoid...

 

[BGB / cr88192]

[...]
There seem to be two distinct and intractable camps involved. The
no-GC crowd is never going to code up a GC system (understandably) and
the GC crowd hasn't done so yet. It sounds a little too blunt to me
but maybe it's time to put up or shut up.

If GC really is a near silver bullet, why isn't it done yet? If it's
as simple as a library then it doesn't have to wait for anything or
anyone. Seems like a great candidate for either a commercial solution
or open source. Improved productivity with fewer errors and no
performance loss would certainly be of value to someone.

GC has been implemented. See, for example,
<http://www.hpl.hp.com/personal/Hans_Boehm/gc/>.

I'm aware of Boehm;

Yes, you are---now. Your earlier posting /clearly/ shows that you
are not aware that GC exists for C programs.

well, I guess, one could argue "it doesn't", well, so long as one sticks to
the standard and/or strictly modular practices (note that my definitions of
"modularity" may even deny the ability to use many aspects of the C runtime,
depending on situation and the allowed set of dependencies for a given piece
of code).

``Not taking the world by storm'' is not nearly the same thing
as ``not done yet''.


$ ./configure
$ make ; make install

actually, configure is evil, or at least if one happens to develop on
Windows (where configure rarely works even on "blessed" targets such as
Cygwin and MinGW...).

the situation is even worse, if one happens to have MSVC as a build
target...


granted, I have not checked personally if Boehm is set up to build with
MSVC, but then again I have my own GC which works well enough.


FWIW, Makefiles are better IMO, since one can make Makefiles for different
sets of build targets (including MSVC), even despite their drawback of not
being able to automatically probe every little aspect of the system (and
forcing on people the incredible terror of having to actually write
general-purpose code if they hope for portability...).

admittedly, there is no "perfect" solution.

For the record I've used and have no problems with Boehm's GC lib.

Yet, ``[gc] isn't done yet''. Hmm!

yep.

 

[Marco]

As for GC I'm agnostic; I don't find much in common with the "never" or
the "must have" camps. But I'm unconvinced it needs to be added to the
C language. I have no reasonable doubt that C will not fade away
rapidly simply because it lacks GC. So far the arguments in this
thread haven't been convincing.

I agree - future ISO C standards do not need to add a bunch of new
features they just need to do some "cleanup" such as security etc.

If someone really needs garbage collection, take a look at the D
programming language.

 

[stan]

stan <[email protected]> writes:

Again, here's what you wrote (taken slightly out of context, but I
don't think that alters the meaning):

The no-GC crowd is never going to code up a GC system
(understandably) and the GC crowd hasn't done so yet.

Fair enough.

Ok. I understand now that you didn't mean to say that GC hasn't
been implemented in (or for) C. But if you'll go back to what
you wrote and re-read it, without making too many assumptions,
I think you'll see why you were misunderstood.

I do understand. I also think I've provided another data point in
another too long and wandering thread so I'll just let this rest.

 

[Ed Prochak]

A good API emerges from iteration. You really can't know how to make a new
API work for you until you've used it in various situations. Tweak, use,
tweak use. Sometimes after two or three iterations you have a really solid
design, sometimes you need more. A couple of the authors suggestions in that
paper reflect this dilemmea, with the vain suggestions about documentation
and separating the caller from implementor.

Iteration is extremely hard to accomplish in a commercial environment with
other engineers because re-writing code is usually frowned upon, especially
once others have begun using the interface. (Thus if you separate caller
from implementor you'll never get the opportunity to change the API; and
it's foolish to think the first try will be even remotely optimal.)

The rule I try to follow is based somewhat on hardware development.:
throw away the prototype!

IOW, your first iteration is seldom optimal. As long as the project
manager understands that, you are okay.

Ed