C Object System

J

jacob navia

Laurent said:
jacob navia wrote:
[snip]
2: Another subject, within the exception handling theme is the behavior
concerning traps. Are traps exceptions? As you can see above, for
lcc-win32 the answer is yes. For C++ it is no, as far as I know.
(Please correct me if I am wrong the C++ experts here).


You are right.

OK
I would like to know the position of COS about this subject.


COS is only C and therefore it has to rely on whether the C compiler
supports signaling traps or not. What COS provides is a service which
converts automatically registered signals into exceptions.

http://cos.cvs.sourceforge.net/cos/COS/src/cos/signal.h?view=markup

Since COS uses SIGSEGV I suppose that COS too considers that a trap
is an exception; what contradicts C++ but seems more logical to me.

I would say that the failure to treat traps as exceptions is more
a bug of C++ rather than a feature.
Except if the body does return in the middle, you still need to run
post-condition. You can always rewrite the code to avoid this but then
you put the burden on the programmer shoulders.

True, but this makes the resulting language smaller.
A beneficial side effect of this simpler design is that the
post-conditions can be very different according to which
type of return you use.


Another subject matter:

What about the garbage collector Laurent?
lcc-win32 offers a gc as a standard feature. Wouldn't this be an
advantage for OO programming in C?

jacob
 
B

Ben Pfaff

llothar said:
So it is now even more clear that you, Ian, and Mr. Heatfield are
in the wrong group. If there is a standart C group then this here is
the right place for all the mutant-C's.

You are not the first one to make this mistake, but you are still
wrong.

comp.lang.c discusses standard C (and its predecessor, K&R C).
comp.std.c discusses the C standard.

The distinction is really not that difficult to understand.
 
J

jacob navia

Ben said:
You are not the first one to make this mistake, but you are still
wrong.

comp.lang.c discusses standard C (and its predecessor, K&R C).

This is not true since Heathfield and Co. insist on using c89, what is
surely not the current standard.

In general, they try to bring C to the stand of 1989 and FREEZE it
there. Not even the C99 standard is accepted, being far too progressive
for this people, since it introduces // comments and other heresies...

They want this group for "questions" like

Hi

Exercise 9.23

Write a C program that ... etc

or for the other interesting questions like

Hi

I wrote
a[i++] = i++;
and it doesn't work...

This are mostly the discussion topics those people accept.

All other questions that concern real world programming,
software engineering, etc are banned.
 
R

Richard Tobin

Ben Pfaff said:
comp.lang.c discusses standard C (and its predecessor, K&R C).
comp.std.c discusses the C standard.

The distinction is really not that difficult to understand.

But to have two newsgroups devote to C, with neither of them admitting
discussion of C outside the standard, seems excessive.

In the past, comp.lang.c was not restricted to standardised C, and if
it has become so it is only because of the views of frequent posters.
It can perfectly well change again if enough posters reject the
restriction.

I suggest that those who want to re-widen the scope of comp.lang.c do
so simply by posting, without bothering to continually respond to the
complaints of those who don't want them to. I'm sure I'm not alone in
finding the endless arguments more annoying even than requests for
help with obscure proprietary APIs (which really don't have a place
here). In accordance with this suggestion, I probably won't reply to
posts disagreeing with me on this.

-- Richard
 
B

Ben Pfaff

jacob navia said:
This is not true since Heathfield and Co. insist on using c89, what is
surely not the current standard.

OK, then predecessors, plural, including C95, C89, K&R C, and
even pre-K&R C on occasion.
 
J

jacob navia

Laurent said:
<OT>
In fact, this is the usual answer I get when I am talking about OOP in
C. But the object model of COS has nothing to do with the one of C++.

COS is very close to CLOS from the point of view of the object model
with many similarities to ObjC due to the fact that it is built on top
of C. But it is very far from C++. As an example, one can look at the
GoF patterns and check for each one why it is needed. Most of them are
there to solve either a problem related to static typing and/or coupling
and/or dynamic behavior and/or missing meta-knowledge. As soon as you
jump on the dark side (i.e. dynamic typing, dynamic dispatch,
meta-classes), they become much less useful. Code and design become
simpler but more permissive.

My point of view is that all the paradigms (SI, MI, template, overload,
override, namespace) introduced by C++ provide (powerful) static glue
(coupling) except dynamic_cast which is not the heart of C++
programming. C++ can be very flexible with meta-programming which is the
modern approach of libraries design (i.e. STL, Boost). But this
flexibility exists only statically at the code level and often makes
unforeseen extension very difficult and/or complex to add. To achieve
flexibility and extensibility in C++ at the level of frameworks, one
need to think in term of roles and components (see ref 21 and 22 of the
paper). Pushing this reasoning to the limits (i.e. one method per role)
and the roles become generics. For a global approach to the problem but
specific to C++, one can read the book of John Lakos "Large-Scale C++
Software Design".

The reasoning behind the C++ fixation with static construction of
software is efficiency.

Objective C and all dynamic typed systems need a run time cost that
the designers of C++ thought it would not be worthwhile to implement.

This obsession with efficiency has some advantages (speed, for instance)
but imposes certain constraints to the language, constraints that
preclude introspection at run time, dynamic class definitions or similar
constructs.

It would be interesting if you would explain your viewpoint about this
concerning your design. Is the cost of run time message lookup an
important part of the runtime in a typicall program?

jacob
 
R

Richard Heathfield

jacob navia said:
This is not true since Heathfield and Co. insist on using c89,

For as long as it is the de facto Standard and my health holds, it is
true that I will continue to use C89.
what is surely not the current standard.

Well, that's debateable, as you know.
In general, they try to bring C to the stand of 1989 and FREEZE it
there.

No, the industry has done that, by not producing C99 implementations
sufficiently widely to replace C90.
Not even the C99 standard is accepted, being far too
progressive for this people, since it introduces // comments and other
heresies...

You are attempting to parody a perfectly sensible decision to do with
conformance to available ISO Standards, as opposed to conformance with
fairy pipedreams.

<snip>
 
K

Kelsey Bjarnason

[snips]

I suggest that those who want to re-widen the scope of comp.lang.c do
so simply by posting, without bothering to continually respond to the
complaints of those who don't want them to.

Problem with this is, those who are going to complain will continue to do
so unless and until the "wideners" cease and desist. So you end up with a
newsgroup which is more noise than signal.

The problem seems to stem from the odd notion that "C" is, somehow, a
random concept, equally applied to anything convenient: if it has structs
and ints and a function called main, it's C.

This is not the case. C is a very well-defined entity; it has an
internationally ratified standard, one designed precisely to ensure that,
as much as possible, the language is the same across all systems, all
implementations, free from ties to particular hardware, operating systems
and the like. It is designed to be maximally usable, maximally portable.

If Joe Sixpack comes along, extolling the virtues of some new language
feature he's created in his compiler, that's all well and good, but it is
*not* something usable by others using different compilers, is it?
Whatever it might be, it is not _C_, as it is neither proper portable code
according to the standard, nor is it a proposed addition to the language,
something which other compilers might benefit from.

If it _were_ proper C code, it wouldn't require his compiler. If it was
being offered as a proposed enhancement to C, it would be in the group
discussing the language standard.

The same is true of all sorts of extensions. Compiler A supports "void
main()". Fine, great... but so what? That's _a compiler_. The language,
C, expressly forbids this, at least for hosted environments. Discussing
the use of void main() is *not* discussing C, it is discussing "Vendor X's
not-quite-C".

If you have a thousand different dialects of C come in here, and all of
them are "acceptable", you're going to quickly run into a problem: when
someone asks "What am I doing wrong" the only possible response is "We
can't tell, because we don't know what language you're using."

This is not helpful. By keeping the group focused on C - real C, C as
defined by the standards - it prevents such degeneration, it keeps the
group useful and vibrant. Proposed extensions to the language _already_
have a place to be discussed, they don't need to be discussed here.
Implementation-specific extensions also often have a place to be
discussed, they don't need to be discussed here.

What does someone working on a Vax care about some Windows-only extension
to C provided by a single implementation, one which he cannot run on his
system? Nothing. Yet if the issue were an actual _C_ question, he would
be just as able to offer answers, just as able to test the code as anyone
else. That benefits not just him, but everyone in the group; keeping the
group focused on C, not C-plus-random-additions, maximizes the likelihood
of getting - or being able to provide - help and guidance for all.

Why would anyone want to intentionally degrade such a useful resource,
simply to bring in things which have no business in here in the first
place? If they dislike the forum that much, they could simply stop
following it; there is no need to actively participate in hastening its
downfall.

CLC is what it is because it has always adhered to a simple rule: keep it
C. That's what it's here for. C is for _everybody_, not just those using
particular tools, particular OSen. This rule maximizes the benefits for
all; breaking it might make one or two people happy, but at the cost of
degrading the group as a whole.

Keep CLC what it is - helpful, useful, available to all... but remember
that it is only useful to all _because_ it adheres to the rule that it
only discusses a language available to all.

Just my pair of skunks.
 
L

llothar

CLC is what it is because it has always adhered to a simple rule: keep it
C. That's what it's here for. C is for _everybody_, not just those using
particular tools, particular OSen. This rule maximizes the benefits for
all; breaking it might make one or two people happy, but at the cost of

Well i don't think so. C is almost removed from application
development
because it is only C. This might not be your domain but it is mine
and
i'm not happy with this development.

So i whish that there will be a C09 standart with a few new
extensions.
And if large companies like MS or HP do not follow that standart then
it is a good way for smaller companies to come up. A C compiler is
very
easy to write, it can be done by small companies which is not true for
C++.
 
C

Charlton Wilbur

l> So i whish that there will be a C09 standart with a few new
l> extensions.

Why? Nobody's bothered to implement all of C99 yet.

l> And if large companies like MS or HP do not follow that
l> standart then it is a good way for smaller companies to come
l> up. A C compiler is very easy to write, it can be done by small
l> companies which is not true for C++.

Be our guest! But please, before you start playing with C09,
implement C99 first. Notice that it's 2007 and C99 is not
implemented; this suggests that it's either not as easy as you think
or not at all profitable; and a standard that's not implemented
anywhere is pretty useless as a standard.

Charlton
 
B

Ben Pfaff

Charlton Wilbur said:
l> So i whish that there will be a C09 standart with a few new
l> extensions.

Why? Nobody's bothered to implement all of C99 yet.

There are several implementations of C99. It's just that none of
them are widely known or in mainstream use.
 
C

Charlton Wilbur

BP> There are several implementations of C99. It's just that none
BP> of them are widely known or in mainstream use.

URL?

Charlton
 
M

Mark McIntyre

Sorry but i don't see that this newsgroup is bound to ANSI-C or K&R-C
only.

Then you didn't read the welcome message, FAQ or other defining
materials.
I'm reading here for a few weeks

Probably you missed the welcome message then, its only posted
sporadically.

What you have probably also missed is that the topic of this group is
the platform-neutral C language as codified by ISO/ANSI. Extensions,
specific platforms, toolsets and so forth are not topical.
Why isn't it possible to discuss evolution of the language?

It is, provided that can be done in the context of a platform-neutral
and toolset-independent framework.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
M

Mark McIntyre

This group has no chart,

You seem to think that having no charter means its a free-for-all.
You're quite incorrect.

You know this of course, you're just making mischief again.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
M

Mark McIntyre

So it is now even more clear that you, Ian, and Mr. Heatfield are
in the wrong group. If there is a standart C group then this here is
the right place for all the mutant-C's.

You misunderstood.
comp.std.c discusses the actual standard document and its evolution.
comp.lang.c discusses the language a defined by the standard.

comp.lang.lcc-win32 and the ilk discuss specific implementations of
the language.
"comp.std.c" (which is nobody reading).

Not true, but you've only been around for a few weeks.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
M

Mark McIntyre

This is not true since Heathfield and Co. insist on using c89, what is
surely not the current standard.

Where did Ben say "current" in his quote above?

I'm sure you feel proud to be trolling all the time, but don't you
ever get bored too?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
M

Mark McIntyre

In the past, comp.lang.c was not restricted to standardised C,

Actually in my memory it has always been so. I've been posting here
since the mid nineties.
I suggest that those who want to re-widen the scope of comp.lang.c do
so simply by posting,

.... and the signal-to-noise ratio will go through the ceiling, to the
point where the regulars all stop reading the group and it becomes
like rec.motorcycles, nothing more than worthless drivel interspersed
with very occasional snippets. This happened to comp.lang.c++ a while
back, and it took a major effort to save it.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
K

Keith Thompson

Mark McIntyre said:
comp.lang.lcc-win32 and the ilk discuss specific implementations of
the language.

There's no comp.lang.lcc-win32 newsgroup, but there is a
comp.compilers.lcc.
 
C

CBFalconer

Mark said:
.... snip ...

Then you didn't read the welcome message, FAQ or other defining
materials.


Probably you missed the welcome message then, its only posted
sporadically.

What you have probably also missed is that the topic of this
group is the platform-neutral C language as codified by
ISO/ANSI. Extensions, specific platforms, toolsets and so
forth are not topical.

Try the following links:

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html> (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware.com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,780
Messages
2,569,611
Members
45,278
Latest member
BuzzDefenderpro

Latest Threads

Top