[...] We've seen, in the case of things like C99, that the
imprimatur is insufficient to get people to use the thing, and
we've seen, in the case of things like BSD sockets, that
usefulness does not require official imprimatur to proliferate.
PH> So there's no "standard sockets" that anyone can assume -- its
PH> just a platform specific idea.
Of course! Not all systems have sockets. Not all systems use TCP/IP.
ANSI and ISO are in no position to mandate that they do, or should!
I don't have a specific proposal about sockets. I was just using it
as an example of the problem of the compiler specific fragmentation
that we see today. But having more generalized stream IO would go a
long way to solving the problem.
PH> My proposals tend to be limited to the library. Perhaps you
PH> can enlighten me with examples where my proposals would lead
PH> to actually giving something up (to be a trade off you have to
PH> gain something in balance with giving something up)? When
PH> people try to challenge me on this, the best I get is the
PH> typical circular reasoning: "that's not in the standard,
PH> therefore its not portable" or some crap like that, when
PH> clearly I am trying to suggest something to be standardized.
I haven't given you that; I've asked, three times now, why you think
your library needs the ANSI/ISO imprimatur. You've just given me
bafflegab.
What the hell are you talking about? I have given very precise, and
so far unchallenged reasons for each of my proposals. They either
expose ubiquitous (or easily emulated) existing platform capabilities,
more closely match platform functionality or help solve a very common
problem with the C language.
If your library is useful, people will use it regardless of whether
ANSI or ISO bless it.
*Libraries* (plural). This has turned out to be the case with the
Better String Library, a hash function I have made, and pstdint.h, as
far as recent examples go. I don't know how much of my old public
code is being used out there. In the specific case of the Better
String Library, one of its features requires that the source be
available (which is contrary to what ANSI has done with C so far) and
I didn't really want the ANSI C committee touching it to be honest.
As to other libraries, such as >= 64 bit file I/O, this isn't *my*
library. Its just something that is a logical extension of what has
been implemented in numerous C compilers already.
As to improved heaps, as you might well imagine, mine is *VERY* non-
portable, and may be too slow for some benchmarks (its slower at
malloc/free speed, but its generally faster on realloc speed, and
tends to give less fragmented results than other heaps I have tested
-- so it will tend to win more *real world* benchmarks as opposed to
direct API test benchmarks.) I am also entertaining the idea of
selling it, since fixing poor C platforms seems to be a real business
opportunity.
Since I am very comfortable with assembly language, it doesn't phase
me much to code up mulhi's or bitcount or bitscan by myself. I just
know that this is not really sustainable in code that's more
widespread.
[...] If your library is not useful, people won't
even bother to implement it, regardless of whether ANSI or ISO bless
it. There's evidence for both of these.
No ... people avoided C99's library, because it came with language
changes to C99 which were either unimplementable or required major
rewrites of the compiler. When they are just changes to the library
which are isolated and straightforward, compiler vendors which are
maintaining their compilers will generally adopt them.
PH> So who says I have not? The problem is that my various
PH> efforts are in pieces, not well documented, sporadically
PH> tested, very context dependent, not portable, not peer
PH> reviewed, etc (the main exception of this being Bstrlib which,
PH> by now, is at compiler-level quality). And I know there are
PH> thousands of different developers who have written
PH> substantially the same thing with different degrees of quality
PH> (probably at least some are better).
So you want ANSI and ISO to standardize something that's in pieces,
not well documented, sporadically tested, very context dependent, not
portable, and not peer reviewed?
So many straw men, so little time huh? What I've implemented and what
I am proposing are two different things. Compiler vendors don't
automatically get free access to my code regardless of whether or not
that would be a good idea.
[...] Or is your hope that ANSI or ISO
standardization will somehow magically cause all this to happen?
That is the entire point of standardization. They are implemented in
the compiler which is a critical tool -- so clearly the code would
have to go through that kind of a process.
PH> ANSI accomplished one thing -- and they did it back in 1989.
PH> They got all the compiler vendors to agree to a common
PH> standard. This meant that people could write common code. It
PH> meant that people did not duplicate effort in redesigning and
PH> reimplementing common things like FILE IO, some math, etc. If
PH> you don't see the value of this, then this discussion is over.
I see the value of it. I don't see the value in standardizing every
other library you think someone, somewhere might find useful.
Oh you must be right. Debugging memory corruption problems must be
such a marginal problem that nobody has run into. Geez louise. And
high performance encryption? I suppose nobody bothers to do that in C
code, otherwise you would see user accounts and passwords on *ALL*
major operating systems shipping today. And its a good thing that
nobody ever tries to randomly access a large single file on a
rewritable DVD, since there's never a good reason to have a > 4GB
file, apparently (and we can safely ignore supercomputer applications
that write really large output, since simulating the climate, and
nuclear seems to be an issue that nobody cares about anymore).
Someone somewhere indeed. These are problems *already solved*, by
*WORKING AROUND* the limitations of the standard and going to non-
portable solutions.
One of the reasons ANSI achieved what it did was by focusing on the
common core subset.
That made sense in 1989 because pr. In 1999? They now are the object
of shunning at best, but more appropriately deserving of ridicule and
disappointment.
[...] As soon as you start adding networking libraries
or graphics libraries or threading libraries, you're imposing
requirements on that common core subset that are not applicable to all
or even most platforms.
We need to get a photograph of you for the wikipedia entry on straw
man.
Obviously, you wont challenge me on what I've actually said or the
positions I represent.
So in the real world that I live in, this is accomplished by keeping
ANSI/ISO C as the standard for the language, and using additional
libraries that are standard but not necessarily universal. I'm trying
to figure out why this is not an acceptable solution for you.
Its fine for me! In fact I would love it if we all still programmed
assembly code! Great for my job security! On this gross and twisted
nightmare of non-portable nonsense that we all engage in, I am
something of a specialist. That's obviously not the point. There is
a "computer scientist" in me that says that we would all be a hell of
a lot more productive if we were programming on the same page and
could make the same assumptions. I want to solve *new* problems, not
old ones that are obvious and uninteresting.