J
Joe keane
1. it's not twos' complement
2. an 'int' may have a trap value
-who- -cares-
go have sex with youselves
2. an 'int' may have a trap value
-who- -cares-
go have sex with youselves
K
Keith Thompson
If you don't care, you don't have to participate in such discussions.
They are certainly on topic for a group that discusses the C
programming language. Would you suggest another forum to discuss
such issues, or would you censor them entirely?
You are teetering on the edge of my killfile.
J
jacob navia
Le 12/03/12 00:05, Joe keane a écrit :
As you have seen from the promoters of those sterile discussions
(thompson for instance) they need to go on forever with those
discussions...
The prototype of main() is a hot topic for them too.
At the same time, thompson and the others shun REAL discussions about
REAL progress that can be done to improve the language.
In all my discussions about the C containers library thompson and the
other "clc regulars" were conspicuously ABSENT. Technically they have
absolutely NOTHING to say.
As you have seen from the promoters of those sterile discussions
(thompson for instance) they need to go on forever with those
discussions...
The prototype of main() is a hot topic for them too.
At the same time, thompson and the others shun REAL discussions about
REAL progress that can be done to improve the language.
In all my discussions about the C containers library thompson and the
other "clc regulars" were conspicuously ABSENT. Technically they have
absolutely NOTHING to say.
D
Don Y
Hi Jacob,
I can't comment re: your personality assessments as I
have a short/transient tenure, here.
And, I don't see the "containers" thread you mentioned
(possibly old or something I marked as "read" without
having actually *read* it).
The "problem" with any public forum is that participants
dome to it with different expectations and needs. Some
might want to argue minutia of the language specification;
or a particular implementation; etc. Others might want
help understanding some *basic* feature of the language;
still others might look for suggestions on techniques or
algorithms to approach a particular problem.
If you've ever dealt with a "building inspector", you've
seen how they might (and *are*, LEGALLY!) be the epitome of
what is allowed/expected in the construction of a building.
But, chances are, you'd never hire any of them to *design*
a building for you! Or, furnish it. Sure, it might meet
all the structural, electrical, plumbing, etc. requirements
of the current Codes... but that doesn't mean it would be a
pleasant or *useful* place to live/work!
E.g., an inspector can tell you whether you *must* have a
dedicated electrical outlet for your refrigerator. *And*,
the ampacity of that circuit. He can tell you if a single
outlet is required or if a duplex outlet is sufficient.
But, he probably won't explain (or know!) why you should or
shouldn't (in your particular case) -- if you have a choice!
I prepare a lot of formal documentation for my projects.
I'll have an "English major" check my grammar, spelling,
etc. But, I'd never trust any of them to *write* (or
rewrite) the documents -- even if they were as knowledgeable
about the material as I! E.g., they might not appreciate
the choice and role of analogies used in the descriptions.
Or, might write a "text book" that no one is inclined to
*read*!
If you're unhappy with a particular discussion -- or
*aspect* of a discussion -- skip past it. Pick the fruit
that is more to your liking!
Of course, YMMV.
I can't comment re: your personality assessments as I
have a short/transient tenure, here.
And, I don't see the "containers" thread you mentioned
(possibly old or something I marked as "read" without
having actually *read* it).
The "problem" with any public forum is that participants
dome to it with different expectations and needs. Some
might want to argue minutia of the language specification;
or a particular implementation; etc. Others might want
help understanding some *basic* feature of the language;
still others might look for suggestions on techniques or
algorithms to approach a particular problem.
If you've ever dealt with a "building inspector", you've
seen how they might (and *are*, LEGALLY!) be the epitome of
what is allowed/expected in the construction of a building.
But, chances are, you'd never hire any of them to *design*
a building for you! Or, furnish it. Sure, it might meet
all the structural, electrical, plumbing, etc. requirements
of the current Codes... but that doesn't mean it would be a
pleasant or *useful* place to live/work!
E.g., an inspector can tell you whether you *must* have a
dedicated electrical outlet for your refrigerator. *And*,
the ampacity of that circuit. He can tell you if a single
outlet is required or if a duplex outlet is sufficient.
But, he probably won't explain (or know!) why you should or
shouldn't (in your particular case) -- if you have a choice!
I prepare a lot of formal documentation for my projects.
I'll have an "English major" check my grammar, spelling,
etc. But, I'd never trust any of them to *write* (or
rewrite) the documents -- even if they were as knowledgeable
about the material as I! E.g., they might not appreciate
the choice and role of analogies used in the descriptions.
Or, might write a "text book" that no one is inclined to
*read*!
If you're unhappy with a particular discussion -- or
*aspect* of a discussion -- skip past it. Pick the fruit
that is more to your liking!
Of course, YMMV.
O
osmium
Don Y said:
I assumed twos' complement was mentioned because of the way it was spelled.
Who knows? And does anyone *really* care?
D
Don Y
A language pedant might. :>
Or, someone poking around at the edges of the language
(strange things lurk in dark corners!)
It's good to be *aware* that things aren't ever as *simple*
as they seem -- so you aren't surprised, one day, when you
stumble into one of these "dark corners". But letting that
sort of preoccupation get in the way with "useful work"
tends to be a waste of time, IMO (YMMV).
(E.g., product starts running code at location 0x00..0.
How do you dereference that address for a reset() routine?)
J
James Kuyper
That's just how jacob perceives it when someone disagrees with him about
whether or not one of his proposals counts as "progress" or an
"improvement". He only wants to discuss how his proposals should be
implemented. Any disagreement with the fundamental concept of his
proposals is treated as a personal attack; which tends to discourage
those who would otherwise be willing to engage in a "REAL" discussion of
why they think the proposals should not be implemented.
Google for clc and comp.std.c messages with "containers" in the
Subject:; most of the messages after 2009 are part of the discussion
he's referring to. As you'll see, a fair number of the messages are from
Keith Thompson, though I agree that he's far from being the most active
participant.
That none of the more active participants in that discussion counts as a
"clc regular" in jacob's eyes surprises me, but then the definition of
that term has always been rather peculiar. The term is used, and
therefore defined, almost exclusively by people who don't consider
themselves a member of the group it describes - even though many of
those people are among the ones who post to clc most regularly.
Therefore, it certainly doesn't mean "people who post to clc regularly".
D
Don Y
Hi James,
Again, I can't comment re: "personalities" as I don't
know histories, etc.
------------------------------------------^
Yikes! Can you spell "ancient history"?
(sigh) Unfortunately, this is often the case when people
"talk".
As I said, each has his/her own motivations, goals, etc.
which might not coincide with your own. One has to learn to
"cherry pick" the useful (in your *own* assessment) from
that which is "less" useful.
In my case, I care little about the formal specification
of the language and how it is (or will) evolving. I'll pick
what aspects appeal to me and deprecate those that don't.
(I can always fall back on any of the previous "versions").
OTOH, others (Jacob?) concerned with standards efforts would
have a far different outlook
Again, I can't comment re: "personalities" as I don't
know histories, etc.
------------------------------------------^
Yikes! Can you spell "ancient history"?
(sigh) Unfortunately, this is often the case when people
"talk".
As I said, each has his/her own motivations, goals, etc.
which might not coincide with your own. One has to learn to
"cherry pick" the useful (in your *own* assessment) from
that which is "less" useful.
In my case, I care little about the formal specification
of the language and how it is (or will) evolving. I'll pick
what aspects appeal to me and deprecate those that don't.
(I can always fall back on any of the previous "versions").
OTOH, others (Jacob?) concerned with standards efforts would
have a far different outlook
J
James Kuyper
Yes, and for me it starts a millennium or two earlier than it does for
you. I come from a background in science and in particular astronomy -
for some purposes, I consider anything less than a billion years old to
be relatively young
While the start of that discussion is several years old, the most recent
messages are relatively recent. Jacob's still working on it, and is
still interested in discussing it, so it's still current.
D
Don Y
Hi James,
On 3/12/2012 3:21 PM, James Kuyper wrote:
[snip]
Ah, women-folk must *love* you at the local bars!! ;-)
It's not uncommon for people to fixate on *an* issue. There's
a guy in one of the database groups that keeps harping on a
certain *feature* that he wants but that others (i.e., the
*implementers*) have decided against. That doesn't stop him
from bringing up the subject regularly...
<frown> OK, maybe I should go take a peek to see if there's
any fire behind the smoke. Though if it is some part of the
"Standard", I probably wouldn't be interested.
("OK, so you want the steering wheel to be on the *RIGHT*
side? <shrug> Just tell me where I insert the key...")
On 3/12/2012 3:21 PM, James Kuyper wrote:
[snip]
Yes, and for me it starts a millennium or two earlier than it does for
you. I come from a background in science and in particular astronomy -
for some purposes, I consider anything less than a billion years old to
be relatively young
Ah, women-folk must *love* you at the local bars!! ;-)
It's not uncommon for people to fixate on *an* issue. There's
a guy in one of the database groups that keeps harping on a
certain *feature* that he wants but that others (i.e., the
*implementers*) have decided against. That doesn't stop him
from bringing up the subject regularly...
<frown> OK, maybe I should go take a peek to see if there's
any fire behind the smoke. Though if it is some part of the
"Standard", I probably wouldn't be interested.
("OK, so you want the steering wheel to be on the *RIGHT*
side? <shrug> Just tell me where I insert the key...")
J
jacob navia
If you are interested in knowing what the container's library is about
look at
http://code.google.com/p/ccl/
There you will find the whole containers library for C, the
documentation, and the source code.
"containers" means lists (single/double linked), hash-tables,
flexible arrays, buffers, circular buffers, trees, and several others.
My proposal is to standardize this in a similar way to C++
stl and allow you to use lists and hashtables in your C code without
reinventing the wheel.
The other people here that do not like this project complain that
there will be never a single package that satisfy all needs, etc.
They are in general against any modification of the language, except
trivialities like the prototype of main() (thompson).
have fun with the library and tell me if you find any bug
jacob
look at
http://code.google.com/p/ccl/
There you will find the whole containers library for C, the
documentation, and the source code.
"containers" means lists (single/double linked), hash-tables,
flexible arrays, buffers, circular buffers, trees, and several others.
My proposal is to standardize this in a similar way to C++
stl and allow you to use lists and hashtables in your C code without
reinventing the wheel.
The other people here that do not like this project complain that
there will be never a single package that satisfy all needs, etc.
They are in general against any modification of the language, except
trivialities like the prototype of main() (thompson).
have fun with the library and tell me if you find any bug
jacob
K
Kenny McCormack
It is to laugh. For so long, Kiki was the champion of "I don't use a
killfile, because only peons use killfiles, and I am above that sort of
thing."
Now, he can't resist the urge to do that stupidest of all things: Use his
(supposed) killfile as a weapon in battle.
How things change...
--
One of the best lines I've heard lately:
Obama could cure cancer tomorrow, and the Republicans would be
complaining that he had ruined the pharmaceutical business.
(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it. We've constructed an economy in which eliminating
cancer would be a horrible disaster. There are many other such examples.)
D
Don Y
Hi Jacob,
But what is the *philosophy* behind the language maintainers?
I.e., *should* C's libraries continue to grow to creep further
into the application domain? Where do you stop -- what about
cryptographic functions? Infinite precision/decimal math?
etc.
I've always assumed a big part of the reasoning behind the STL
was to bootstrap the adoption and "learning" of C++. Not
things that would really translate to C (this late in the game)
C always had a nice, light "feel" -- something that C++ can't
approach. The existing libraries almost seem to be pushing the
limits of that (though they tend not to be as bloated as C++'s
approach to things).
[If you've ever tackled Ada, you understand the difference in
"attitude" taken/portrayed by the language(s)]
But what is the *philosophy* behind the language maintainers?
I.e., *should* C's libraries continue to grow to creep further
into the application domain? Where do you stop -- what about
cryptographic functions? Infinite precision/decimal math?
etc.
I've always assumed a big part of the reasoning behind the STL
was to bootstrap the adoption and "learning" of C++. Not
things that would really translate to C (this late in the game)
C always had a nice, light "feel" -- something that C++ can't
approach. The existing libraries almost seem to be pushing the
limits of that (though they tend not to be as bloated as C++'s
approach to things).
[If you've ever tackled Ada, you understand the difference in
"attitude" taken/portrayed by the language(s)]
I
Ian Collins
Nice analogy.
It can probably be stretched a little further to say a building company
benefits from an inspector and a software company benefits from a
language lawyer!
J
jacob navia
Le 13/03/12 01:17, Don Y a écrit :
No. The containers library is not an application; A container is used
in most applications though, and that is the difference.
Most serious programs use lists, need flexible arrays, hash tables, etc.
The "solution" now is that each program redevelops a linked list
package, a hash table package, etc from scratch at each project.
Since there isn't a common interface all this programs are incompatible
and need to be adapted when used together.
If I use package "A" with its list module and package "B" with another
incompatible lost module, I have to write adapter code to pass lists
written in package "A" to lists in package "B".
And you know very well what I am talking about. Never done
a list package? You never used a list in your programs?
Many of those functions are provided by my compiler system
lcc-win but I am not proposing to generalize them. What I am
proposing is standardizing the principal containers.
No. The containers library is not an application; A container is used
in most applications though, and that is the difference.
Most serious programs use lists, need flexible arrays, hash tables, etc.
The "solution" now is that each program redevelops a linked list
package, a hash table package, etc from scratch at each project.
Since there isn't a common interface all this programs are incompatible
and need to be adapted when used together.
If I use package "A" with its list module and package "B" with another
incompatible lost module, I have to write adapter code to pass lists
written in package "A" to lists in package "B".
And you know very well what I am talking about. Never done
a list package? You never used a list in your programs?
Many of those functions are provided by my compiler system
lcc-win but I am not proposing to generalize them. What I am
proposing is standardizing the principal containers.
D
Don Y
That depends on the role he plays in the organization.
A building inspector, in theory, serves a vital role.
OTOH, he can also be an *impediment* to progress -- by
insisting on detail that may or may not be significant.
I suspect you will find most "building companies" don't have
inspectors on their payroll. Rather, they have "normal
employees" with a working knowledge of the pertinent issues.
This might not be enough to keep them out of every screw-up.
But, it is usually enough to enable them to get their
work done *efficiently*.
D
Don Y
I didn't claim it was an application. Rather, I said "creep
further into the application domain". I.e., where do you
draw the line between "part of the language" and "*part* of
the application"?
I use lots of geometric functions. Should the language tout
a library that provides these to me in some "standard" way?
What about crypto functions? Secure hashes? etc.
Why not support for *tasking* -- native to the language
(instead of in a library!) like Limbo?
You *really* don't want to pose that question to me! :>
I often rewrite major portions of the standard libraries
as I move from project to project -- because the execution
environments frequently differ and I don't need the "generality"
that most of the libraries provide. Or, I am bastardizing a
standard data type, etc.
When was the last time you used:
digits = INT_MAX
decimals = INT_MAX
printf("The answer is %*.*e", value, digits, decimals)
In fact, when was the last time you used the '*' flag in printf??
Will your copy of the libraries even *handle* this specific
case??
I.e., I tend to err on the side of "leaner" vs. "fatter".
So, need to see a real reason for *adding* something in
that can't already be handled some other way.
E.g., Limbo's support for tasking and IPC "belongs" in the
language (Limbo, that is). It noticeably changes the
feel and capabilities of the language -- and the applications
it tries to address (moreso than a "library" would have)
I
Ian Collins
One of my clients is a medical electronics company so there are plenty
of inspectors!
G
gwowen
jacob said:
Your proposal will fail, and your energy will be wasted. Among the
many reasons for this not least because using void* as your
fundamental type shifts makes the compiler implenters life easy by
shifting all the effort onto to the programmer. No one want generics
where type safety is the responsibility of the programmer, and they
have to keep casting their object pointers back and forth.
That why C++ templates win - compile time type safety. You haven't got
that, and you haven't got exceptions, and that means that your
interfaces and error handling is horrible to the point of
unusability. So what you have will never be widely accepted.
Other reasons include your inability to accept any technical criticism
of your design. You simply won't be able to persuade anyone of
anything without a change in attitude.
You may now accuse be of making personal attacks thereby proving my
point.
G
Guest
why?
Are they untrue? (plainly not as The Standard says so)
tedious? (but int main(), and don't cast malloc() are ok?)
irrelevent to modern implementations? (non 8-bit chars, 16 bit ints and a pointer may not fit in a long are ok?)
why not ban mentions of EBCDIC or DSPs having 32 bit chars?