C Object System

[Laurent Deniau]

I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/c...la07-draft.pdf

I would be interested by any feedback from C programmers (with little OO
knowledge) to improve the paper quality, even if I don't know yet if the
paper will be accepted. It is not intended to be a manual nor an
introduction to OOP. Just to mention it (not in the paper), my
programming background is 10+ years of C/C++.

Kind regards,

ld.

ABSTRACT:
The C Object System (COS) is a recent framework entirely written in C
which implements high-level concepts available in CLOS, OBJECTIVE-C and
other object-oriented programming languages: uniform object model
(class, metaclass and property-metaclass), generics, multimethods,
delegation, exceptions, contracts and closures. It relies on the
programmable capabilities of C to extend its syntax and to implement the
aforementioned concepts as first-class objects. COS aims at satisfying
several general principles like simplicity, flexibility, extensibility,
efficiency and portability which are rarely met in a single programming
language. Its design is tuned to provide efficient and portable
implementation of message dispatch and message forwarding which are
the heart of code flexibility and extensibility. With COS features,
software should become as flexible and extensive as with scripting
languages and as efficient and portable as expected with C programming.
Likewise, COS concepts should significantly simplify adaptive,
aspect-oriented and subject-oriented programming as well as distributed
systems.

[klaushuotari]

On 18 huhti, 18:37, Laurent Deniau <[e-mail]:

I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/c...la07-draft.pdf

I would be interested by any feedback from C programmers (with little OO
knowledge) to improve the paper quality, even if I don't know yet if the
paper will be accepted. It is not intended to be a manual nor an
introduction to OOP. Just to mention it (not in the paper), my
programming background is 10+ years of C/C++.

Kind regards,

ld.

ABSTRACT:
The C Object System (COS) is a recent framework entirely written in C
which implements high-level concepts available in CLOS, OBJECTIVE-C and
other object-oriented programming languages: uniform object model
(class, metaclass and property-metaclass), generics, multimethods,
delegation, exceptions, contracts and closures. It relies on the
programmable capabilities of C to extend its syntax and to implement the
aforementioned concepts as first-class objects. COS aims at satisfying
several general principles like simplicity, flexibility, extensibility,
efficiency and portability which are rarely met in a single programming
language. Its design is tuned to provide efficient and portable
implementation of message dispatch and message forwarding which are
the heart of code flexibility and extensibility. With COS features,
software should become as flexible and extensive as with scripting
languages and as efficient and portable as expected with C programming.
Likewise, COS concepts should significantly simplify adaptive,
aspect-oriented and subject-oriented programming as well as distributed
systems.

Very interesting paper and lots of mind-food. I'm not sure if C is
suitable for re-decoration as we have C++, but nevertheless it's a
thing to consider. I have to study this one.

[jacob navia]

Laurent Deniau a écrit :

I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/c...la07-draft.pdf

I would be interested by any feedback from C programmers (with little OO
knowledge) to improve the paper quality, even if I don't know yet if the
paper will be accepted. It is not intended to be a manual nor an
introduction to OOP. Just to mention it (not in the paper), my
programming background is 10+ years of C/C++.

Kind regards,

ld.

ABSTRACT:
The C Object System (COS) is a recent framework entirely written in C
which implements high-level concepts available in CLOS, OBJECTIVE-C and
other object-oriented programming languages: uniform object model
(class, metaclass and property-metaclass), generics, multimethods,
delegation, exceptions, contracts and closures. It relies on the
programmable capabilities of C to extend its syntax and to implement the
aforementioned concepts as first-class objects. COS aims at satisfying
several general principles like simplicity, flexibility, extensibility,
efficiency and portability which are rarely met in a single programming
language. Its design is tuned to provide efficient and portable
implementation of message dispatch and message forwarding which are
the heart of code flexibility and extensibility. With COS features,
software should become as flexible and extensive as with scripting
languages and as efficient and portable as expected with C programming.
Likewise, COS concepts should significantly simplify adaptive,
aspect-oriented and subject-oriented programming as well as distributed
systems.

Salut Laurent!

Very interesting paper.

Some comments after a fast first reading:

A: EXCEPTION HANDLING
------------------
1) lcc-win32 implements try/catch exception handling in
a slightly similar way than what you propose.
For instance

void fn(void)
{
char *p=NULL;
unsigned code;
__try {
*p = 0;
printf("No exceptions\n");
}
__except(code=GetExceptionCode(),EXCEPTION_EXECUTE _HANDLER) {
printf("Ooops, there was a problem with this program.”);
printf("Error code: %#x\n",code);
}
return 0;
}

This could be made functionally equivalent to what you propose with a
switch statement within the __except clause, that would handle the
different values of the exception being thrown.

Of course your exception handler handles not just an integer code but
(apparently) a message to an object/class...

This is easy to do under windows, but very difficult to do in systems
that do not support exception handling natively like linux, for
instance. I have found no easy solution under linux, but it is true
that I haven't researched a lot about how could be done.

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).
I would like to know the position of COS about this subject.

B: DESIGN BY CONTRACT
------------------

I have developed an extension for lcc-win32 to implement DBC, but after
some thought about it, I can't see the advantage of that with the simple
method of just using assert. Preconditions can be very easily
implemented with asserts before the main body of the function, post
conditions can be done in a similar easy way by adding assertions after
the body of the function.

Since the C Comitee has started examining the Microsoft proposition for
a safer C library, I implemented the "require" macro using that proposed
mechanism, what is surely an improvement over just the assert macro.

The 'require' macro would fit nicely as the precondition part of DBC.

Obviously your proposal is different than that, since you advocate oo
programming, and the preconditions/post conditions are part of the
class hierarchy, and accordingly executed probably from the most
specific to the least specific class constraints (or the other way
around, I do not remember seeing this in your document).

C: GENERICS
--------
It is difficult to understand what do you want from the description of
generics in your document. You refer to objective C behavior as
explanation but with my very limited knowledge of Objective C this
leaves quite a lot of dark places...
Generics within the context of lcc-win32 are understood as a single
function that can have different implementations for different
arguments. This corresponds (more or less, probably less than more) to
the C++ usage. Your definition of generics seems to be a function that
receives an unidentified object as arguments, tests if the object
responds to some message and if it does it sends the message...
I do not see quite the interest of that, and it would be nice if you
would use a more down to earth example for this.


jacob

P.S. I referred above to 'lcc-win32'. That is an experimental
compiler system available at

http://www.cs.virginia.edu/~lcc-win32

[Ian Collins]

Laurent Deniau wrote:

I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/c...la07-draft.pdf

I would be interested by any feedback from C programmers (with little OO
knowledge) to improve the paper quality, even if I don't know yet if the
paper will be accepted. It is not intended to be a manual nor an
introduction to OOP. Just to mention it (not in the paper), my
programming background is 10+ years of C/C++.

Given your background, I have to ask why? The features you describe in
the paper have already been added to C, in the form of C++.

--
Ian Collins.

[CBFalconer]

Ian Collins wrote:

Laurent Deniau wrote:

>I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/c...la07-draft.pdf

I would be interested by any feedback from C programmers (with
little OO knowledge) to improve the paper quality, even if I don't
know yet if the paper will be accepted. It is not intended to be a
manual nor an introduction to OOP. Just to mention it (not in the
paper), my programming background is 10+ years of C/C++.

Given your background, I have to ask why? The features you describe
in the paper have already been added to C, in the form of C++.

C++ is another language, and off-topic here.

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

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

jacob navia wrote:

>

.... snip ...

>
1) lcc-win32 implements try/catch exception handling in
a slightly similar way than what you propose.
For instance

void fn(void)
{
char *p=NULL;
unsigned code;
__try {
*p = 0;
printf("No exceptions\n");
}
__except(code=GetExceptionCode(),EXCEPTION_EXECUTE _HANDLER) {
printf("Ooops, there was a problem with this program.”);
printf("Error code: %#x\n",code);
}
return 0;
}

This has nothing to do with standard C, the subject of this
newsgroup.

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

--
Posted via a free Usenet account from http://www.teranews.com

[Ian Collins]

CBFalconer wrote:

Ian Collins wrote:

>>Laurent Deniau wrote:

>>>I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/c...la07-draft.pdf

I would be interested by any feedback from C programmers (with
little OO knowledge) to improve the paper quality, even if I don't
know yet if the paper will be accepted. It is not intended to be a
manual nor an introduction to OOP. Just to mention it (not in the
paper), my programming background is 10+ years of C/C++.

Given your background, I have to ask why? The features you describe
in the paper have already been added to C, in the form of C++.

C++ is another language, and off-topic here.

So? I was asking the OP why he proposes to reinvent a wheel, not
discussing C++.

--
Ian Collins.

[CBFalconer]

Ian Collins wrote:

CBFalconer wrote:

>Ian Collins wrote:

.... snip ...

>>>
Given your background, I have to ask why? The features you
describe in the paper have already been added to C, in the
form of C++.

C++ is another language, and off-topic here.

So? I was asking the OP why he proposes to reinvent a wheel,
not discussing C++.

Probably because he wants to use that language on a system that
doesn't sport a C++ compiler. I think you use what you can get.

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

--
Posted via a free Usenet account from http://www.teranews.com

[Laurent Deniau]

Ian Collins wrote:

Laurent Deniau wrote:

>I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/c...la07-draft.pdf

I would be interested by any feedback from C programmers (with little OO
knowledge) to improve the paper quality, even if I don't know yet if the
paper will be accepted. It is not intended to be a manual nor an
introduction to OOP. Just to mention it (not in the paper), my
programming background is 10+ years of C/C++.

Given your background, I have to ask why? The features you describe in
the paper have already been added to C, in the form of C++.

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

To conclude on C++, I knew that it would be a major concern for many C++
programmers. Earlier releases of the paper had a full section discussing
of pros and cons of main stream languages with a special attention for
C++ (with 14 references which are still in the latex version ;-) ). But
I had to suppress it, due to the limits of 18 pages. My believe is that
on one hand, programmers to who COS doesn't look attractive don't need
its features to solve the problems they encounter. On the other hand,
programmers to who COS does look attractive already faced the same
problems I had to solve and understand the motivation.
<OT>

[Laurent Deniau]

CBFalconer wrote:

Ian Collins wrote:

>CBFalconer wrote:

>>Ian Collins wrote:

... snip ...

>>>Given your background, I have to ask why? The features you
describe in the paper have already been added to C, in the
form of C++.
C++ is another language, and off-topic here.

So? I was asking the OP why he proposes to reinvent a wheel,
not discussing C++.

Probably because he wants to use that language on a system that
doesn't sport a C++ compiler. I think you use what you can get.

I hope that people will not see COS as yet-another C++ since it has
nothing to do with C++ and it is not intended to replace it when it is
not available. If this is the conclusion of the paper readers, it would
mean that I completely failed to explain the interest of COS (sic!).

a+, ld.

[Ian Collins]

Laurent Deniau wrote:

Ian Collins wrote:

>Laurent Deniau wrote:

>>I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/c...la07-draft.pdf

I would be interested by any feedback from C programmers (with little OO
knowledge) to improve the paper quality, even if I don't know yet if the
paper will be accepted. It is not intended to be a manual nor an
introduction to OOP. Just to mention it (not in the paper), my
programming background is 10+ years of C/C++.

Given your background, I have to ask why? The features you describe in
the paper have already been added to C, in the form of C++.

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

In that case, I will study the paper in greater depth than I did this
morning. I just shudder when I see all those macros!

<OT>

--
Ian Collins.

[llothar]

This has nothing to do with standard C, the subject of this
newsgroup.

Sorry but i don't see that this newsgroup is bound to ANSI-C or K&R-C
only.
It's name is "comp.lang.c" and this is a whole ranges of different C
languages.

I'm reading here for a few weeks and i'm really getting pissed off
from people like
you and Mr. Heatfield. You might not want to discuss this but others
like. Sorry
but you seem to be dogma addicted in the same way as for example the
Pope or
Al-Sadr.

Why isn't it possible to discuss evolution of the language?
At least if there is a precompiler that converts an extended C into
ANSI-C.

I must say, i liked to read this paper.

[Ian Collins]

llothar wrote:

Please don't snip attributions.

>>This has nothing to do with standard C, the subject of this
newsgroup.

Sorry but i don't see that this newsgroup is bound to ANSI-C or K&R-C
only.
It's name is "comp.lang.c" and this is a whole ranges of different C
languages.

Which doesn't include lcc-win32, a compiler with its own group. The bit
of lcc-win32 specific code you snipped was OT, it wasn't standard C or
even a common extension.

--
Ian Collins.

[Laurent Deniau]

jacob navia wrote:

Salut Laurent!

Very interesting paper.

Some comments after a fast first reading:

A: EXCEPTION HANDLING
------------------
1) lcc-win32 implements try/catch exception handling in
a slightly similar way than what you propose.
For instance

void fn(void)
{
char *p=NULL;
unsigned code;
__try {
*p = 0;
printf("No exceptions\n");
}
__except(code=GetExceptionCode(),EXCEPTION_EXECUTE _HANDLER) {
printf("Ooops, there was a problem with this program.”);
printf("Error code: %#x\n",code);
}
return 0;
}

This could be made functionally equivalent to what you propose with a
switch statement within the __except clause, that would handle the
different values of the exception being thrown.

Of course your exception handler handles not just an integer code but
(apparently) a message to an object/class...

This is easy to do under windows, but very difficult to do in systems
that do not support exception handling natively like linux, for
instance. I have found no easy solution under linux, but it is true
that I haven't researched a lot about how could be done.

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.

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/C....h?view=markup

B: DESIGN BY CONTRACT
------------------

I have developed an extension for lcc-win32 to implement DBC, but after
some thought about it, I can't see the advantage of that with the simple
method of just using assert. Preconditions can be very easily
implemented with asserts before the main body of the function, post
conditions can be done in a similar easy way by adding assertions after
the body of the function.

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.

Since the C Comitee has started examining the Microsoft proposition for
a safer C library, I implemented the "require" macro using that proposed
mechanism, what is surely an improvement over just the assert macro.

The 'require' macro would fit nicely as the precondition part of DBC.

Obviously your proposal is different than that, since you advocate oo
programming, and the preconditions/post conditions are part of the
class hierarchy, and accordingly executed probably from the most
specific to the least specific class constraints (or the other way
around, I do not remember seeing this in your document).

pre-conditions are bottom-top, post-conditions are top-bottom which is
the natural way of thinking of an average programmer (like me).
Invariant is a special case intrinsic to the class.

C: GENERICS
--------
It is difficult to understand what do you want from the description of
generics in your document. You refer to objective C behavior as
explanation but with my very limited knowledge of Objective C this
leaves quite a lot of dark places...
Generics within the context of lcc-win32 are understood as a single
function that can have different implementations for different
arguments. This corresponds (more or less, probably less than more) to
the C++ usage.

This is overloading which is usually resolved by mangling the function
name with some signature encoding (not including the return type in
C++). Overloading is resolved statically at link time.

Your definition of generics seems to be a function that
receives an unidentified object as arguments, tests if the object
responds to some message and if it does it sends the message...
I do not see quite the interest of that, and it would be nice if you
would use a more down to earth example for this.

Generics work like overloading with dynamic resolution (i.e. virtual
member functions in C++). This is just the merge of both concepts in one
at the same time. Paragraph "Method ranks" (p.11) explains how the
specialization is selected. Generics are also explained for CLOS in the
ref. 9 of the paper.

Example of multimethods in pseudo C++:

class Number { .. };
class Integer : Number { .. };
class Double : Number { .. };

// defgeneric OBJ operator+(OBJ,OBJ);

Double operator+(Integer &a, Double &b) { .. } // (1)
Double operator+(Double &a, Integer &b) { .. } // (2)

int main() {
// concrete instances.
Integer a(10);
Double b(5.5);

// abstract representation.
Number &n1 = a;
Number &n2 = b;

// double dispatch
Number &c = n1+n2; // call (1)
Number &d = n2+n1; // call (2)

return 0;
}

With static typing but late binding, this is a nightmare to implement
and use because of the object-dependent covariant and contravariant
typing rules (google for the Scala language for more info).

hope this help to clarify the points.

a+, ld.

[jacob navia]

llothar wrote:

>>This has nothing to do with standard C, the subject of this
newsgroup.

Sorry but i don't see that this newsgroup is bound to ANSI-C or K&R-C
only.
It's name is "comp.lang.c" and this is a whole ranges of different C
languages.

Exactly.

This group has no chart, and nobody can tell you with any authority
that something is "off topic". The people around Heathfield
should be just ignored :-)

They have nothing to say, their only "argument" is "off topic"
"off topic"...

jacob

[Ian Collins]

jacob navia wrote:

llothar wrote:

>>This has nothing to do with standard C, the subject of this
newsgroup.

Sorry but i don't see that this newsgroup is bound to ANSI-C or K&R-C
only.
It's name is "comp.lang.c" and this is a whole ranges of different C
languages.

Exactly.

This group has no chart, and nobody can tell you with any authority
that something is "off topic".

I'm not a card carrying member of the topicality police, but you have to
admit your lcc-win32 specific exception code wasn't what most reasonable
people would call C.

No one is bashing the OP, the paper describes a system based on standard C.

--
Ian Collins.

[CBFalconer]

Laurent Deniau wrote:

CBFalconer wrote:

>Ian Collins wrote:

>>CBFalconer wrote:
Ian Collins wrote:

... snip ...

>>>>Given your background, I have to ask why? The features you
describe in the paper have already been added to C, in the
form of C++.

C++ is another language, and off-topic here.

So? I was asking the OP why he proposes to reinvent a wheel,
not discussing C++.

Probably because he wants to use that language on a system that
doesn't sport a C++ compiler. I think you use what you can get.

I hope that people will not see COS as yet-another C++ since it has
nothing to do with C++ and it is not intended to replace it when it is
not available. If this is the conclusion of the paper readers, it would
mean that I completely failed to explain the interest of COS (sic!).

This has nothing to do with your post, just Mr. Navia's off-topic
addition (and somebody snipped the attribution).

--
<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
--
Posted via a free Usenet account from http://www.teranews.com

[llothar]

So? I was asking the OP why he proposes to reinvent a wheel, not

discussing C++.

Because it is not the same wheel. Your posting would make more sense
if you asked why he reinvent Object-C.
And it is a nice addition which is easy enough to describe it in 18
pages - something you surely can't say about
C++.

Or why does he reinvent D ?

[Al Balmer]

On 19 Apr 2007 02:23:56 -0700, llothar <ll*****@web.dewrote:

>

>This has nothing to do with standard C, the subject of this
newsgroup.

Please don't snip attributions, and retain enough to make sense of
what you do include. I had to chase the header references to find out
that this sentence had nothing whatsoever to do with the subject, but
was a reply to Jacob Navia, regarding something *he* wrote.

>
Sorry but i don't see that this newsgroup is bound to ANSI-C or K&R-C
only.
It's name is "comp.lang.c" and this is a whole ranges of different C
languages.

I'm reading here for a few weeks and i'm really getting pissed off
from people like
you and Mr. Heatfield. You might not want to discuss this but others
like. Sorry
but you seem to be dogma addicted in the same way as for example the
Pope or
Al-Sadr.

I suggest that you use Google Groups to research the topic of
topicality in c.l.c. It may help you understand why we attempt to keep
the group's focus narrowly on standard C.

>
Why isn't it possible to discuss evolution of the language?

There is another group which discusses the C standard itself and its
evolution, comp.std.c.

>At least if there is a precompiler that converts an extended C into
ANSI-C.

I must say, i liked to read this paper.

And of course the paper is based on standard C and probably topical
here.

--
Al Balmer
Sun City, AZ

[llothar]

On 19 Apr., 08:36, Al Balmer <[e-mail]:

There is another group which discusses the C standard itself and its
evolution, comp.std.c.

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.

I'm not saying that jacob's and other persons changes should go into
the standart but they need to be discussed and if are good we can
move the topic up to "comp.std.c" (which is nobody reading).

[jacob navia]

Laurent Deniau wrote:

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/C....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.

>B: DESIGN BY CONTRACT
------------------

I have developed an extension for lcc-win32 to implement DBC, but after
some thought about it, I can't see the advantage of that with the simple
method of just using assert. Preconditions can be very easily
implemented with asserts before the main body of the function, post
conditions can be done in a similar easy way by adding assertions after
the body of the function.

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

[Ben Pfaff]

llothar <ll*****@web.dewrites:

On 19 Apr., 08:36, Al Balmer <[e-mail]:

>There is another group which discusses the C standard itself and its
evolution, comp.std.c.

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.
--
Comp-sci PhD expected before end of 2007
Seeking industrial or academic position *outside California* in 2008

[jacob navia]

Ben Pfaff wrote:

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.

[Richard Tobin]

In article <87************@blp.benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.eduwrote:

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[jacob navia]

Laurent Deniau wrote:

Ian Collins wrote:

>Laurent Deniau wrote:

>>I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/c...la07-draft.pdf

I would be interested by any feedback from C programmers (with little OO
knowledge) to improve the paper quality, even if I don't know yet if the
paper will be accepted. It is not intended to be a manual nor an
introduction to OOP. Just to mention it (not in the paper), my
programming background is 10+ years of C/C++.

Given your background, I have to ask why? The features you describe in
the paper have already been added to C, in the form of C++.

<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

[Ben Pfaff]

jacob navia <ja***@jacob.remcomp.frwrites:

Ben Pfaff wrote:

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

OK, then predecessors, plural, including C95, C89, K&R C, and
even pre-K&R C on occasion.
--
Comp-sci PhD expected before end of 2007
Seeking industrial or academic position *outside California* in 2008

[Richard Heathfield]

jacob navia said:

Ben Pfaff wrote:

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

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>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Kelsey Bjarnason]

[snips]

On Thu, 19 Apr 2007 17:20:23 +0000, Richard Tobin wrote:

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.

--
Do not contact me at kb********@ncoldns.com

[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++.

[Charlton Wilbur]

>>>>"l" == llothar <ll*****@web.dewrites:

lSo i whish that there will be a C09 standart with a few new
lextensions.

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

lAnd if large companies like MS or HP do not follow that
lstandart then it is a good way for smaller companies to come
lup. A C compiler is very easy to write, it can be done by small
lcompanies 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

--
Charlton Wilbur
cw*****@chromatico.net

[Ben Pfaff]

Charlton Wilbur <cw*****@chromatico.netwrites:

>>>>>"l" == llothar <ll*****@web.dewrites:

lSo i whish that there will be a C09 standart with a few new
lextensions.

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.
--
Comp-sci PhD expected before end of 2007
Seeking industrial or academic position *outside California* in 2008

[Charlton Wilbur]

>>>>"BP" == Ben Pfaff <bl*@cs.stanford.eduwrites:

BPCharlton Wilbur <cw*****@chromatico.netwrites:

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

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

URL?

Charlton
--
Charlton Wilbur
cw*****@chromatico.net

[Ian Collins]

Charlton Wilbur wrote:

>>>>>>"BP" == Ben Pfaff <bl*@cs.stanford.eduwrites:

BPCharlton Wilbur <cw*****@chromatico.netwrites:

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

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

URL?

Charlton

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

Is close enough.

--
Ian Collins.

[Mark McIntyre]

On 19 Apr 2007 02:23:56 -0700, in comp.lang.c , llothar
<ll*****@web.dewrote:

>

>This has nothing to do with standard C, the subject of this
newsgroup.

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

[Mark McIntyre]

On Thu, 19 Apr 2007 13:11:10 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>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

[Mark McIntyre]

On 19 Apr 2007 10:01:53 -0700, in comp.lang.c , llothar
<ll*****@web.dewrote:

>On 19 Apr., 08:36, Al Balmer <[e-mail]:

>There is another group which discusses the C standard itself and its
evolution, comp.std.c.

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

[Mark McIntyre]

On Thu, 19 Apr 2007 19:18:40 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Ben Pfaff wrote:

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

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

[Mark McIntyre]

On 19 Apr 2007 17:20:23 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:

>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

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.netwrites:
[...]

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Mark McIntyre wrote:

llothar <ll*****@web.dewrote:

.... snip ...

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

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>
--
Posted via a free Usenet account from http://www.teranews.com

[Laurent Deniau]

jacob navia wrote:

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]

In article <4u********************************@4ax.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>On Thu, 19 Apr 2007 19:18:40 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>>Ben Pfaff wrote:

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

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Friedrich Dominicus]

Charlton Wilbur <cw*****@chromatico.netwrites:

>>>>>"l" == llothar <ll*****@web.dewrites:

lSo i whish that there will be a C09 standart with a few new
lextensions.

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.

>
lAnd if large companies like MS or HP do not follow that
lstandart then it is a good way for smaller companies to come
lup. A C compiler is very easy to write, it can be done by small
lcompanies 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
--
Please remove just-for-news- to reply via e-mail.

[Friedrich Dominicus]

Ian Collins <ia******@hotmail.comwrites:

Charlton Wilbur wrote:

>>>>>>>"BP" == Ben Pfaff <bl*@cs.stanford.eduwrites:

BPCharlton Wilbur <cw*****@chromatico.netwrites:

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

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

URL?

Charlton

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

--
Please remove just-for-news- to reply via e-mail.

[Laurent Deniau]

jacob navia wrote:

Laurent Deniau wrote:

>Ian Collins wrote:

>>Laurent Deniau wrote:

I just put the draft of my paper on the web:

http://cern.ch/laurent.deniau/html/c...la07-draft.pdf

I would be interested by any feedback from C programmers (with
little OO
knowledge) to improve the paper quality, even if I don't know yet if
the
paper will be accepted. It is not intended to be a manual nor an
introduction to OOP. Just to mention it (not in the paper), my
programming background is 10+ years of C/C++.

Given your background, I have to ask why? The features you describe in
the paper have already been added to C, in the form of C++.

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

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]

Richard Tobin wrote:

In article <87************@blp.benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.eduwrote:

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

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

JS

[Ian Collins]

Friedrich Dominicus wrote:

Ian Collins <ia******@hotmail.comwrites:

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

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.

--
Ian Collins.

[Mark McIntyre]

On Thu, 19 Apr 2007 16:32:32 -0700, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>Mark McIntyre <ma**********@spamcop.netwrites:
[...]

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

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

On 20 Apr 2007 10:51:16 GMT, in comp.lang.c , ri*****@cogsci.ed.ac.uk
(Richard Tobin) wrote:

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

Mark McIntyre wrote:

Keith Thompson <ks***@mib.orgwrote:

>Mark McIntyre <ma**********@spamcop.netwrites:

[...]

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

--
Posted via a free Usenet account from http://www.teranews.com