C Object System

[Laurent Deniau]

True, but this makes the resulting language smaller.

pre- and post-conditions are not assertion, they are statements which
use assertions. This is just a convenient way to declare the contract.
This is why I put post-conditions between pre-conditions and the body
instead of after the body.

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.

I do not understand this point. One feature of COS which is may be
useful for post-conditions is that you can still access the value
returned in the body even if the body has multiple return points.

Another subject matter:

What about the garbage collector Laurent?

Well, COS is in alpha release 0.2 even if it is more stable and tested
than some 0.99 releases ;-) Writing a GC is a huge task (more complex
than COS itself and *not portable*) so for the moment, COS is compliant
with the Boehm GC (see ownership p.3) for those who want one.

lcc-win32 offers a gc as a standard feature. Wouldn't this be an
advantage for OO programming in C?

Yes and no. Controlling the object allocation is not only in the spirit
of C, but it is also more efficient (in absolute about x3 for speed and
x1.5-3 for memory usage). And tuning a GC is also a difficult task
required in most large application (even Sun agrees with that).

With the COS ownership semantic, it is much simpler to manage memory
comparing to C and it allows much better tuning than GCs. People from
Objective-C are using it for a decade now with success.

I don't know yet if objects allocation (with or without GC) will be a
bottleneck for real applications since COS supports automatic objects
for fast local uses (where bottlenecks usually occur). But since
automatic objects are strengthened by multimethods -- a different
situation comparing to Objective-C -- it is possible that using a GC
would have no impact at all. If it does or if malloc is not enough
efficient, I would probably import the allocator of OOC-2.0 (which is x2
faster than GNU malloc). But this is not my priority and the decision
can be postponed until a large amount of code is available to do some
tests at the level of applications.

Another point is that objects are bound to their classes by an id, not
by a pointer, which may lead to some problem with dynamic classes in the
presence of a GC. Not to say that the GC may see many inexistent
references in objects ids.

a+, ld.

 

[Richard Tobin]

On Thu, 19 Apr 2007 19:18:40 +0200, in comp.lang.c , jacob navia

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

Technically Jacob is correct, since C99 "cancels and replaces" C89.
ISO C89 is no longer a standard. In practice of course, C89 is still
a widely-used standard.

-- Richard

 

[Friedrich Dominicus]

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.

sure, but at least a few try.

Howerver if they could not do C99 fully, they should at leat to comply
to C89. And IMHO it's fine to include that here also, although it's
not the "actual" Standard, but if one uses C99 then that should be
accepted also.

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;

It's in first line probably non profitable. I dare to say most here
would happily go on using gcc even if a C99 compiler would exist, but
if one had to pay for it.

and a standard that's not implemented
anywhere is pretty useless as a standard.

Well maybe because the extensions are not what the people are really
looking after?

I do not think that talkign about extensions would hurt so much, and
well if it's yet another OO system, so be it. I can not see that this
thread is in any way off-topic here.

Regards
Friedrich

 

[Friedrich Dominicus]

http://developers.sun.com/sunstudio/index.jsp

I'm sorry I can not comment on it, howerver it just adds to my last
mail. Even if such a thing would exist, I doubt it would be
bought. Well and the systems with Solaris on it are probably not all
too much, and well if one sees what Sun does with Java I doubt they
advertise it very much...

Regards
Friedrich

 

[Laurent Deniau]

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.

They point are more related to static typing than to efficiency.

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?

For conclusion on real application, I am afraid that you will have to
wait a bit. But since you have read the paper, you understand that I am
also very concerned by this point. So I will do my best to make the
answer being 'no'.

My experiences has shown that when polymorphism (flexibility, reuse) is
a gain, then speed matters less (say within an average factor of 1.5 to
3, not 15 for Java or 100 for Python). When speed matters, polymorphism
is often much less important. COS is an OO layer on top of C, so
efficient algorithms can still be written in C and methods
specialization call them when available. This is the typical approach of
Cocoa (MacOS X) where half of the Objective-C API has an equivalent in
bare C. The higher abstraction of OO also allows to make some better
designs which often lead to better *average* efficiency.

The same apply to C++ except that with meta-programming (templates), it
is possible to have the best of the two worlds as soon as everything is
*statically known*. Unfortunately, in real application, a lot of
information is loaded at runtime and translated into static information
if it is possible. If it is not possible (often the case), you have to
deal with various design patterns to write a framework equivalent to an
interpreter and then complexity starts to grow exponentially. So the
gain or the loss of efficiency with C++ is not that obvious. Not to say
that C++ programs can be slowed down by many tricky pitfalls like badly
written copy constructors or bad strategic choices of objects ownership.

As a conclusion, I believe that simplicity leads to better design which
leads to good efficiency. Ultimate efficiency can still be achieved on
the 5-20% part of your code which may need it. This is the target of
COS. Here is a table summarizing my point of view (note are over 10):

C++ COS Java/C# Python/Ruby
flexibility 1-3-6 8-9-10 4-6-8 7-9-10
efficiency 6-8-10 5-8-10 3-5-7 1-2-4

in the form of worst/avrg/best cases from 1 (worst) to 10 (best).
Obviously, commenting these values would take some time...

a+, ld.

 

[John Smith]

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

You sir, are a voice of sanity (unfortunately, coming from the
wilderness).

JS

 

[Ian Collins]

I'm sorry I can not comment on it, howerver it just adds to my last
mail. Even if such a thing would exist, I doubt it would be
bought.

True, it's free.

Well and the systems with Solaris on it are probably not all
too much,

You'd be surprised. Sun Studio is also available on Linux.

 

[Mark McIntyre]

There's no comp.lang.lcc-win32 newsgroup,

Quite possibly you're right. However I don't give two hoots. T'was
merely an example of how to differentiate between comp.lang.c and some
arbitrary implementation's newsgroup.



--
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

 

[Mark McIntyre]

Technically Jacob is correct, since C99 "cancels and replaces" C89.

No. As far as the publication of the Standard goes, this is correct.
As far as the implementation of standards goes, its not.

Consider: your favorite car maker brings out the new, improved Edsel.
Does that stop your older model being an Edsel? No, its just an older
model.

In practice of course, C89 is still a widely-used standard.

And its highly amusing to see the antipedants here complaining
continually that the pedants don't want 'real world solutions' when
this entire debate is about sticking to precisely those....
--
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

 

[CBFalconer]

[...]

comp.lang.lcc-win32 and the ilk discuss specific implementations
of the language.

There's no comp.lang.lcc-win32 newsgroup,

Quite possibly you're right. However I don't give two hoots. T'was
merely an example of how to differentiate between comp.lang.c and
some arbitrary implementation's newsgroup.

There is a "comp.compilers.lcc" newsgroup. Not very active.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Keith Thompson]

Quite possibly you're right. However I don't give two hoots. T'was
merely an example of how to differentiate between comp.lang.c and some
arbitrary implementation's newsgroup.

Fair enough.

In general, the nonexistence of an appropriate newsgroup for some
topic does not excuse the assumption that comp.lang.c is appropriate.
But in this particular case, the existence of comp.compilers.lcc
removes even that excuse.

 

[Richard Tobin]

Technically Jacob is correct, since C99 "cancels and replaces" C89.

[/QUOTE]

No. As far as the publication of the Standard goes, this is correct.
As far as the implementation of standards goes, its not.

Presumably implementations of standards cease to be such when the
things they implement cease to be standards. They become
implementations of former standards.

Consider: your favorite car maker brings out the new, improved Edsel.
Does that stop your older model being an Edsel? No, its just an older
model.

I don't know much about cars, but I assume car makers do not say that
new models "cancel" old ones.

-- Richard

 

[Mark McIntyre]

No. As far as the publication of the Standard goes, this is correct.
As far as the implementation of standards goes, its not.

Presumably implementations of standards cease to be such when the
things they implement cease to be standards. They become
implementations of former standards.[/QUOTE]

IMHO this is a gratuitously fine line out here in the Real World, and
one being drawn for ulterior reasons. In the hypothetical world of ISO
and other standards orgs, no doubt you're correct.

I don't know much about cars, but I assume car makers do not say that
new models "cancel" old ones.

You don't know much about cars, as you say...
--
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

 

[Marco]

It seems the proper place to discuss this topic is
comp.lang.misc
[But it seems you didn't post there.]
This is where new programming languages and systems are usually
presented and discussed.

Even though COS is written in C it is not really about the C language.

I think it is perfectly valid to announce here to get "views" but you
should have suggested to visit comp.lang.misc for an in depth
discussion.

my humble opinion

 

[Old Wolf]

Consider: your favorite car maker brings out the new, improved Edsel.
Does that stop your older model being an Edsel? No, its just an older
model.

Irrelevant example. C99 cancels C89. New Edsels don't cancel old
Edsels.

 

[Richard Bos]

No. As far as the publication of the Standard goes, this is correct.
As far as the implementation of standards goes, its not.

Presumably implementations of standards cease to be such when the
things they implement cease to be standards. They become
implementations of former standards.

Consider: your favorite car maker brings out the new, improved Edsel.
Does that stop your older model being an Edsel? No, its just an older
model.

I don't know much about cars, but I assume car makers do not say that
new models "cancel" old ones.[/QUOTE]

Ah. And there's the rub. To the mechanics, they do not. To the
salesweasels, they do.

Richard

 

[Laurent Deniau]

It seems the proper place to discuss this topic is
comp.lang.misc
[But it seems you didn't post there.]
This is where new programming languages and systems are usually
presented and discussed.

My post what targeting comments from C programmers, not COS as a new
language. The reason is that I plan to use it for development with C
programmers in a near future and I wanted to know if it looks simple
enough to be handled by C programmers in a couple of days (say after
having read a more in-depth manual).

Even though COS is written in C it is not really about the C language.

I think it is perfectly valid to announce here to get "views"

That was the idea.

but you
should have suggested to visit comp.lang.misc for an in depth
discussion.

I didn't know about this group but usually groups *.misc get either
little valuable information, either little bandwidth. Still, I will do a
post to see what happens ;-) Thanks for the suggestion.

As an example, I also posted to comp.object, but because 'C' appears in
the title, I think nobody read the post or the paper. Which is a bit
amusing, because COS proposes an object model (CLOS object model) which
answers to discussions like "Why OOP failed?" and variant. Since this
kind (very long religious) discussion appear every two weeks on this
group, so I thought that people would be interested by the paper and
feedback valuable opinions, but it seems that they prefer to repeat
discussions about known problems than to see how to solve them.

In the same way, it is not because I asked to C programmers their
opinion that I am not interested by feedback on the object model or any
other aspects of the paper. A lot of C programmers have a good
(sometimes deep) knowledge of other OO languages.

a+, ld.

 

[Mark McIntyre]

Irrelevant example. C99 cancels C89.

This argument is tautological and therefore not an actual argument...

"A cat is a mammal" "why?" "because its a sort of mammal"

New Edsels don't cancel old Edsels.

Try telling that to the marketing dept.
--
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

 

[Richard Heathfield]

Richard Bos said:

(e-mail address removed) (Richard Tobin) wrote:


Ah. And there's the rub. To the mechanics, they do not. To the
salesweasels, they do.

Quite so. And comp.lang.c is a technical newsgroup, not a sales channel.
From a practical perspective, ISO/IEC 9899:1990, no matter how obsolete
it is supposed to be, is not merely extant but dominant.

 

[Richard Tobin]

Quite so. And comp.lang.c is a technical newsgroup, not a sales channel.
From a practical perspective, ISO/IEC 9899:1990, no matter how obsolete
it is supposed to be, is not merely extant but dominant.

Though I of course agree that C90 is still the dominant standard, I
can't help feeling that your argument is inconsistent with your usual
position. If this group is dedicated to the discussion of standard
C, and the current C standard itself declares that C90 is obsolete
and "cancelled", surely the group should comply.

Since I am not making a serious point here, don't feel obliged to
expend effort rebutting me.

-- Richard