Boost process and C

[extrudedaluminiu]

Hi,

Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?

Thanks,
-vs

[Richard Bos]

jacob navia <ja***@jacob.remcomp.fr> wrote:

Richard Bos a écrit :
[snip]

Three restrictions. And bright red uniforms. But those are not
references as it is generally understood. They're also mostly useless. I
cannot imagine wanting such a type when I already have normal pointers.
OTOH, they're also - being toothless - not harmful, the way a real
reference is.

For enlightenment on what is generally meant by "reference" in
programming, see the C++ Standard.
I do not really care, I am not trying to copy C++. The only advantage of
references is that they are never NULL in my implementation, and they
are (maybe) not as powerful as the C++ ones.

Then, as I said, they're neither useful nor references.

We need length prefixed strings,

...like we need a hole in the head.

What is wrong with length prefixed strings Richard?

That's been discussed here so often that I really can't be arsed to
repeat the whole argument for the N+1th time.
Can you put forward your *arguments* instead of just sending polemic to
the discussion?

WHY are length prefixed strings wrong?

I am waiting for an argument Richard.

Don't cite other people's names like that jacob navia.

It does not make your posts any easier to read nor any more to the point
jacob navia.

Frankly, it makes you sound like a bit of a twerp jacob navia.

Richard

[Richard Bos]

Ian Collins <ia******@hotmail.com> wrote:

Richard Bos wrote:

Functions which take a reference can change _my_ object behind my back,
and the only way I'd know about it is if I dug up the prototype. You
cannot tell from a single call. With pointers, the difference is always
clear. To illustrate:

That's why we have const. If a function isn't going to change the value
passed in, it should reference (or pointer) to a const object. If the
parameter isn't const, assume the worst. No difference between pointers
and references in this case.

But you still can't tell from any particular _call_ to a function
whether that function is likely to change its arguments, or is
guaranteed not to. As long as you have references (real ones, not
navia-references), you cannot trust a single function call - you have to
look up all prototypes, even if you're only trying to understand someone
else's code.

Richard

[Richard Bos]

Robert Latest <bo*******@yahoo.com> wrote:

On 2006-05-02, Keith Thompson <ks***@mib.org> wrote:

If you don't like the features of C, you can either:

[ suggestions (1) through (4) snipped ]

(5) Write a compiler that supports the needed features,
preferably for a popular platform with a wide user
base such as Windows, and make it available for free.

If people like the language extensions, they will become popular
quickly and make it into other implementations as well, thus
creating what is known as a "de facto standard". No need to wait
for an ISO committee.

Perfectly good idea, _but_ if you do so, do not post samples of your
extended-not-quite-C here as if it were normal C, or a good solution to
a general problem.

Richard

[REH]

"Ben C" <sp******@spam.eggs> wrote in message
news:sl*********************@bowser.marioworld...

On 2006-05-05, REH <[e-mail]> wrote:

"Ben C" <sp******@spam.eggs> wrote in message
news:sl*********************@bowser.marioworld...

Yes I know. But you do get constructors, destructors and references, so
you can fit explicit memory management "under the hood" of operator
overloading.

I can understood people's dislike of references (though I don't agree
with
the reasons), but what is wrong with constructors and destructors?

Nothing, I like constructors and destructors.

Then I have completely misunderstood your point, which wouldn't be a first
for me.

REH

[Robert Latest]

On 2006-05-04, we******@gmail.com <we******@gmail.com> wrote:

I think the point is that there are *many* such application. In fact I
would be suspicious of anyone who claimed to be an experienced
programmer who hasn't *written* one of these.

....and I would be suspcious of anyone who claimed to be an
experienced programmer who can't write the necessary routines
from scratch in less time than it takes to download, install, and
understand a dedicated string library. In fact I want to see a
single experienced programmer who hasn't written his own little
string library at some point in his career -- be it as a
homework assignment or just to kill time on a rainy weekend.

All these points are moot anyway -- it is very likely that the
people manipulating millions of tiny string needs a completely
different library than the huge-document-in-memory crowd. For
obvious reason, there is no one-size-fits-all solution.

robert

[Robert Latest]

Maybe I'm just too slow, too kind-hearted, too patient, or I gave
Jacob Navier too much credit because he backs up his ideas about
what C should look like by having written an actual piece of
softwar that implements his views. But the following exchange
that just took place convinced me that Jacob Navier is indeed a
full-blown, pathological fuckwit:

-----

JN:
It just makes NO SENSE. The same thing when you apply the addition
operator to dates: it makes NO SENSE to ADD dates.

RT:
mid_date = (start_date + end_date) / 2;

JN:
You obviously meant:
mid_date = (end_date - start_date)/2

RT:
No I didn't. That is something completely different.
(end_date - start_date) / 2 would give me half the interval
between the dates, but that is not what I wanted. I wanted the
average of the dates, which is a date.

JT:
Ahh ok, you mean then
mid_date = startdate + (end_date-start_date)/2

-----

robert

[Robert Latest]

On 2006-05-05, Robert Latest <bo*******@yahoo.com> wrote:

But the following exchange
that just took place convinced me that Jacob Navier is indeed a
full-blown, pathological fuckwit:

Actually I think I did do Jacob injustice here because the
expressions

(start_date + end_date) / 2 (1)

and

start_date + (end_date - start_date) / 2 (2)

are indeed not equivalent if the date type behaves like a pointer
type in C, as it should. (1) is invalid, (2) is valid, as can be
demonstrated by trying to compile this program:

-----
int main(void)
{
char array[100];
char *s, *e, *m;

s = array;
e = array + sizeof array;

m = (s + e) / 2;

m = s + (e - s) / 2;

return 0;
}
----

I apologize.

robert

[Ben C]

On 2006-05-05, REH <[e-mail]> wrote:

"Ben C" <sp******@spam.eggs> wrote in message
news:sl*********************@bowser.marioworld...

On 2006-05-05, REH <[e-mail]> wrote:

"Ben C" <sp******@spam.eggs> wrote in message
news:sl*********************@bowser.marioworld...
Yes I know. But you do get constructors, destructors and references, so
you can fit explicit memory management "under the hood" of operator
overloading.

I can understood people's dislike of references (though I don't agree
with
the reasons), but what is wrong with constructors and destructors?

Nothing, I like constructors and destructors.

Then I have completely misunderstood your point, which wouldn't be a first
for me.

The original point was just that if you want the "full power" of
operator-overloading, combined with manual memory management, you also
need constructors, destructors and references. Or something like them.

That's all. Whether C should be extended with any or all of:

1. operator overloading
2. references
3. constructors and destructors

is a matter of opinion.

[Richard Tobin]

In article <_Z********************@comcast.com>,
Joe Wright <jo********@comcast.net> wrote:

Adding date values is nonsense.

Why? The averaging example I gave shows a perfectly clear use of it.

It might be nonsense to claim that adding date values gives you a
date, but that's not what I said.

Another analogy: I have heard it claimed that adding celsius
temperatures is nonsense, yet people do it all the time when averaging
temperatures.

-- Richard

[Richard Tobin]

In article <sl**********************@localhost.localdomain> ,
Robert Latest <bo*******@yahoo.com> wrote:

Actually I think I did do Jacob injustice here because the
expressions

(start_date + end_date) / 2 (1)

and

start_date + (end_date - start_date) / 2 (2)

are indeed not equivalent if the date type behaves like a pointer
type in C, as it should. (1) is invalid, (2) is valid

Yes, of course. My objection is not to date (or pointer) addition
being disallowed, it's to the claim that it's *meaningless*. The
second expression above is a workaround for the fact that the first
one is illegal, but the fact that one can come up with a workaround
proves that the original wasn't meaningless. If it didn't mean
anything, you couldn't come up with an alternative to express the same
thing!

-- Richard

[John F]

"Richard Tobin" wrote:

Joe Wright wrote:

Adding date values is nonsense.

Why? The averaging example I gave shows a perfectly clear use of
it.

It might be nonsense to claim that adding date values gives you a
date, but that's not what I said.

Another analogy: I have heard it claimed that adding celsius
temperatures is nonsense, yet people do it all the time when
averaging
temperatures.

There is a difference between

(date1+date2)/2 (adds dates and divides by two)

and

date1+(date2-date1)/2 (proportionally adds the difference between two
dates to another date)

The former is meaningless (in a mathematical sense), the latter is
perfectly legal.

If you argue that adding dates is legal then I suggest you define the
binary operator and the division-operator in a serious way. (e.g. it
should tell: What is (March, 13th 2003) / 2? )

Temperatures are a different thing. They have another mathematical
structure. Adding them does not make sense in a physical way... As it
is for dates. Averaging dates would be legal too but you would have to
find a mapping to the real numbers to do so.

That means you need to define the offset and the scale you want to
use. This does not give a meaning to the sum of two dates but enables
you to define the average date in a series.

regards
John

[REH]

"Ben C" <sp******@spam.eggs> wrote in message
news:sl*********************@bowser.marioworld...

Then I have completely misunderstood your point, which wouldn't be a
first
for me.

The original point was just that if you want the "full power" of
operator-overloading, combined with manual memory management, you also
need constructors, destructors and references. Or something like them.

That's all. Whether C should be extended with any or all of:

1. operator overloading
2. references
3. constructors and destructors

is a matter of opinion.

Ah, I gotta ya. Personally, I'd like C to stay small, simple, and compact.
I use C++ or Ada when I want those extra features, and still have a language
that is designed for efficiency.

REH

[jacob navia]

REH wrote:

"Ben C" <sp******@spam.eggs> wrote in message
news:sl*********************@bowser.marioworld...

Then I have completely misunderstood your point, which wouldn't be a
first
for me.

The original point was just that if you want the "full power" of
operator-overloading, combined with manual memory management, you also
need constructors, destructors and references. Or something like them.

That's all. Whether C should be extended with any or all of:

1. operator overloading
2. references
3. constructors and destructors

is a matter of opinion.

Ah, I gotta ya. Personally, I'd like C to stay small, simple, and compact.
I use C++ or Ada when I want those extra features, and still have a language
that is designed for efficiency.

REH

The operator overloading change do not affect efficiency at all. One of
the most "dreaded" features of C++ is the problem of avoiding
copy-constructors, constructors and destructors in apparently efficient
and simple statements like

a = *b;

or similar. This is nowhere required by operator overloading.

Of course some people will say that this is not the "full power" of
operator overloading, and I would just say that they are right. But I
would rename that to "full bloat" :-)

The problem of C++ is that it wasn't able to say STOP. It was unable to
see when features become misfeatures because of the incredible bloat
that they continued to accept.

One feature (operator overloading) led to another and to another and
they ended up with a language that nobody in the world can grasp as a
whole. Still, most C++ compilers do not arrive at full compliance
because of the incredible feature set. Look at the incredible efforts
done by the gcc team and still there is no 100% compliance.

This is a lesson to be learned.

Still, we must not fall in the opposite direction, and refuse any
change. I suspect that most of the animosity against the changes I
propose is precisely this feeling that C is going to disappear again in
a bloated stuff where the efficiency and the surface of the language is
extended beyond repair.

This is not AT ALL my intention. The proposed changes do not affect the
efficency at all, and they are really optional in the sense that the
efficiency loss is only paid by people that use them. In C++ you get
your constructors/destructors whether you want it or not. Operator
overloading is a change that will affect only people that use that
feature. Nobody else has to pay for it.

The same thing for ALL other changes that are done in lcc-win32:

o overloaded functions: No efficiency lost since the compiler generates
the same machine code as before. This is just compile time changes.
o operator overloading: No efficiency lost for people that do not use
this feature. Some cycles (minimal) of extra cost are there for simple
implementations like the one in lcc-win32. An optimizing compiler
would have no trouble in eliminating it.
o Default arguments: No efficiency loss at all. This is just some
syntatic sugar.

Note that in contrast to C++ C remains NOT object oriented!

jacob

[Al Balmer]

On Fri, 05 May 2006 20:28:51 +0200, jacob navia
<ja***@jacob.remcomp.fr> wrote:

REH wrote:

"Ben C" <sp******@spam.eggs> wrote in message
news:sl*********************@bowser.marioworld...

<snip>

That's all. Whether C should be extended with any or all of:

1. operator overloading
2. references
3. constructors and destructors

is a matter of opinion.

It's also off-topic here. Take it to comp.std.c.

<snip>

--
Al Balmer
Sun City, AZ

[Keith Thompson]

"John F" <sp**@127.0.0.1> writes:

"Richard Tobin" wrote:

Joe Wright wrote:

Adding date values is nonsense.

Why? The averaging example I gave shows a perfectly clear use of
it.

It might be nonsense to claim that adding date values gives you a
date, but that's not what I said.

Another analogy: I have heard it claimed that adding celsius
temperatures is nonsense, yet people do it all the time when
averaging
temperatures.

There is a difference between

(date1+date2)/2 (adds dates and divides by two)

and

date1+(date2-date1)/2 (proportionally adds the difference between two
dates to another date)

The former is meaningless (in a mathematical sense), the latter is
perfectly legal.

[...]

The former includes a subexpression that yields a result that's not
meaningful, but the expression has a whole is meaningful.

Dates, temperatures, and pointers are all similar in the sense that
each can be thought of as a pair: base+offset, where the base is
respectively an arbitrary epoch, an arbitrary zero temperature, or a
zero address (or the base address of a containing object). In each
case, the "base" is some fixed point, and the "offset" is a scalar
quantity. Offsets by themselves can be added and subtracted freely;
the base is meaningful only if you have exactly zero or one of it.
(With no base, you have an interval or distance; with a base, you have
a position.)

(Assume Celsius or Fahrenheit temperatures; the zero base of Kelvin
scale is uniquely meaningful, so it's not restricted to this model.)

Subtracting two dates
date1 - date2
is equivalent to:
(base+offset1) - (base+offset2)
which reduces to:
offset1 - offset2
which is meaningful; it's an interval, measurable in seconds, with no
defined base.

Adding two dates:
date1 + date2
is equivalent to:
(base+offset1) + (base+offset2)
which reduces to:
2*base + offset1 - offset2
which is not directly meaningful because of the 2*base term.

However, if it's used as an intermediate expression, as in:
(date1 + date2) / 2
we have
((base+offset1) + (base+offset2)) / 2
or
(2*base + offset1 - offset2) / 2
or
base + (offset1 - offset2)/2
a meaningful expression that denotes the midpoint between the two
dates.

Ideally, we'd like to make expressions with meaningful results legal,
and expressions without meaningful results illegal. Theoretically, we
could do this by allowing meaningless intermediate results, as long as
the result of the full expression is meaningful.

There are (at least) two problems with this approach. First, it makes
the language rules more complex, which affects both compiler writers
(who can deal with it) and users (who likely can't). Try explaining
to a newbie that (date1 + date2), or (pointer1 + pointer2), is usually
illegal, except that it's allowed as a subexpression if and only if
the expression as a whole obeys certain constraints. Second, it makes
it difficult to define the circumstances in which overflow can occur.
Pointer arithmetic in C is defined only within a single object (or
just past its end); allowing pointer+pointer gives you intermediate
results that not only don't have an obvious meaning, but may not be
representable, depending on where in the address space the object
happens to be allocated.

Ignoring the overflow problem, if you're using raw numbers to
represent dates, something like (date1+date2)/2 is ok, as long as you
have the discipline to avoid writing a full expression that's not
meaningful:
x = date1 + date2; /* meaningless, but the compiler won't complain */

If you're using a hypothetical language that does this kind of smart
type checking, allowing date1+date2 as a subexpression but not as a
full expression, you can add dates to your heart's content and depend
on the implementation to detect any type matching errors. It would be
interesting to design this kind of thing, either as a language feature
(off-topic here), or as a library with run-time checking (doable in
standard C, with functions rather than overloaded operators). Again,
overflow is a concern unless you can either use extended precision for
intermediate results, or rely on the implementation to rearrange the
expressions for you.

Finally, if you're using standard C and operating on pointers, you'll
just have to rearrange the expression yourself. If you need to know
the address halfway between two pointers, you can't write:
mid = (ptr1 + ptr2) / 2;
You'll just have to bite the bullet and write:
mid = ptr1 + (ptr2 - ptr1) / 2;

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

[Ian Collins]

Richard Bos wrote:

Ian Collins <ia******@hotmail.com> wrote:

Richard Bos wrote:

Functions which take a reference can change _my_ object behind my back,
and the only way I'd know about it is if I dug up the prototype. You
cannot tell from a single call. With pointers, the difference is always
clear. To illustrate:

That's why we have const. If a function isn't going to change the value
passed in, it should reference (or pointer) to a const object. If the
parameter isn't const, assume the worst. No difference between pointers
and references in this case.

But you still can't tell from any particular _call_ to a function
whether that function is likely to change its arguments, or is
guaranteed not to. As long as you have references (real ones, not
navia-references), you cannot trust a single function call - you have to
look up all prototypes, even if you're only trying to understand someone
else's code.

I must be missing something, you have the same problem with pointers,
don't you?

If you see someFn( &x ), how do you know if someFn's prototype is

void someFn( int* ); or
void someFn( const int* );

without looking it up?

In new code, how can you call a function without knowing its prototype?

--
Ian Collins.

[Keith Thompson]

Ian Collins <ia******@hotmail.com> writes:
[snip]

I must be missing something, you have the same problem with pointers,
don't you?

If you see someFn( &x ), how do you know if someFn's prototype is

void someFn( int* ); or
void someFn( const int* );

without looking it up?

In new code, how can you call a function without knowing its prototype?

If you see someFn(x), you can be sure that someFn will not change the
value of x, even without understanding everything about someFn.

In a language with references, or with some sort of pass-by-reference
parameter mechanism, you can't be sure of that.

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

[Ian Collins]

jacob navia wrote:

The operator overloading change do not affect efficiency at all. One of
the most "dreaded" features of C++ is the problem of avoiding
copy-constructors, constructors and destructors in apparently efficient
and simple statements like

a = *b;
Case 1:

int a;
int *b;

a = *b;

Show me where con/destructors are used.

Case 2:

struct x { int a, int b; };

struct x a;
struct x *b;

a = *b;

Show me where con/destructors are used.

You keep rambling on about this without any solid evidence.
This is not AT ALL my intention. The proposed changes do not affect the
efficency at all, and they are really optional in the sense that the
efficiency loss is only paid by people that use them. In C++ you get
your constructors/destructors whether you want it or not. Operator
overloading is a change that will affect only people that use that
feature. Nobody else has to pay for it.
Twaddle.

In case 2 above, both C and C++ compiler can generate the same code.
The same thing for ALL other changes that are done in lcc-win32:

o overloaded functions: No efficiency lost since the compiler generates
the same machine code as before. This is just compile time changes. But opens up that other can of worms, name mangling and all the
incompatibilities that can introduce.
o operator overloading: No efficiency lost for people that do not use
this feature. Some cycles (minimal) of extra cost are there for simple
implementations like the one in lcc-win32. An optimizing compiler
would have no trouble in eliminating it.
o Default arguments: No efficiency loss at all. This is just some
syntatic sugar.

Note that in contrast to C++ C remains NOT object oriented!

None of this realy belongs in C, you can get all these features from C++
without any loss of efficiency.

Ian
--
Ian Collins.

[Richard Tobin]

In article <44***********************@tunews.univie.ac.at>,
John F <ca************@gmx.at> wrote:

There is a difference between

(date1+date2)/2 (adds dates and divides by two)

and

date1+(date2-date1)/2 (proportionally adds the difference between two
dates to another date) The former is meaningless (in a mathematical sense)
That's OK, I understand mathematics, tell me the "mathematical sense"
in which it's meaningless. Perhaps you could start with a mathematical
definition of "meaningless", since I've never come across one.
If you argue that adding dates is legal then I suggest you define the
binary operator
What binary operator?
and the division-operator in a serious way. (e.g. it
should tell: What is (March, 13th 2003) / 2? )

It's something which when multiplied by 2 gives you March 13 2003,
and which when added to (March 11 2003) / 2 gives youy March 12 2003.
It is not, of course, a date. There isn't any conventional way to
write it, nor is there a conventional name for its type. But we can
perfectly well define various operations on it.

-- Richard

[Ian Collins]

Keith Thompson wrote:

Ian Collins <ia******@hotmail.com> writes:
[snip]

I must be missing something, you have the same problem with pointers,
don't you?

If you see someFn( &x ), how do you know if someFn's prototype is

void someFn( int* ); or
void someFn( const int* );

without looking it up?

In new code, how can you call a function without knowing its prototype?

If you see someFn(x), you can be sure that someFn will not change the
value of x, even without understanding everything about someFn.

In a language with references, or with some sort of pass-by-reference
parameter mechanism, you can't be sure of that.

I see your point.

I'd still look at the prototype out of simple curiosity!

--
Ian Collins.

[Keith Thompson]

Ian Collins <ia******@hotmail.com> writes:

Keith Thompson wrote:

Ian Collins <ia******@hotmail.com> writes:
[snip]

I must be missing something, you have the same problem with pointers,
don't you?

If you see someFn( &x ), how do you know if someFn's prototype is

void someFn( int* ); or
void someFn( const int* );

without looking it up?

In new code, how can you call a function without knowing its prototype?

If you see someFn(x), you can be sure that someFn will not change the
value of x, even without understanding everything about someFn.

In a language with references, or with some sort of pass-by-reference
parameter mechanism, you can't be sure of that.

I see your point.

I'd still look at the prototype out of simple curiosity!

Sure, but it might not be obvious which of a dozen included headers
contains the prototype. Knowing that someFn can't modify x can be
useful in getting a quick partial understanding of the code in a
fairly quick look.

For example, suppose the code looks like this:

int x = 42;
/* do some stuff */
someFn(x);
/* do some other stuff */
printf("x = %d\n", x);

If you expect the printf to print "x = 42", and it instead prints
"x = -3" you can be sure that the problem is either before or after
the function call, not in the function itself.

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

[CBFalconer]

jacob navia wrote:

.... snip ...
This is not AT ALL my intention. The proposed changes do not affect
the efficency at all, and they are really optional in the sense
that the efficiency loss is only paid by people that use them. In
C++ you get your constructors/destructors whether you want it or
not. Operator overloading is a change that will affect only people
that use that feature. Nobody else has to pay for it.

The same thing for ALL other changes that are done in lcc-win32:

o overloaded functions: No efficiency lost since the compiler generates
the same machine code as before. This is just compile time changes.
o operator overloading: No efficiency lost for people that do not use
this feature. Some cycles (minimal) of extra cost are there for simple
implementations like the one in lcc-win32. An optimizing compiler
would have no trouble in eliminating it.
o Default arguments: No efficiency loss at all. This is just some
syntatic sugar.

Not so.

default arguments:
The compiler has to generate default parameter values. It can now
no longer detect omitted parameters during a call. One more source
of evil gotchas.

operator overloading:
Already exists in some places, since you can add floats, or
integers. Any further extension needs a complex set of automatic
cast rules and/or a set of implementing runtime routines, with
attendant source errors possible.

Overloaded functions:
The objections to default arguments apply. I could probably think
of more, including bloating the compiler proper.

If you examine the raw size of the C standard, you will find it is
roughly twice that of better designed languages already, to spell
out all the ifs, buts, and just in cases required by the baroque
syntax. The C++ standard eliminates much of this by simply
referring to the C standard. You would get further proposing
simplifications rather than complexities. C just grew, and the
standard shows it.

For example, a future standard could restrict 'precedence' to three
levels (e.g. logical, additive, and multiplicative) only, requiring
parentheses for any further control, yet allowing the actions of
the present silly system. The result would be clearer code without
necessarily breaking older code. It could deprecate such
obfuscative things as +=, without efficiency losses, since
optimizers can easily handle the longer phrases.

I can mention these possibilities, but I don't seriously expect
them to take place. And I will not run about weeping and whining
if the general readership does not enthusiastically rally behind
them.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Ian Collins]

Keith Thompson wrote:

Ian Collins <ia******@hotmail.com> writes:

Keith Thompson wrote:

If you see someFn(x), you can be sure that someFn will not change the
value of x, even without understanding everything about someFn.

In a language with references, or with some sort of pass-by-reference
parameter mechanism, you can't be sure of that.

I see your point.

I'd still look at the prototype out of simple curiosity!

Sure, but it might not be obvious which of a dozen included headers
contains the prototype. Knowing that someFn can't modify x can be
useful in getting a quick partial understanding of the code in a
fairly quick look.

For example, suppose the code looks like this:

int x = 42;
/* do some stuff */
someFn(x);
/* do some other stuff */
printf("x = %d\n", x);

If you expect the printf to print "x = 42", and it instead prints
"x = -3" you can be sure that the problem is either before or after
the function call, not in the function itself.

All good and let me reiterate: I don't think references belong in C.

--
Ian Collins.

[jacob navia]

Ian Collins a écrit :

jacob navia wrote:

The operator overloading change do not affect efficiency at all. One of
the most "dreaded" features of C++ is the problem of avoiding
copy-constructors, constructors and destructors in apparently efficient
and simple statements like

a = *b;

Case 1:

int a;
int *b;

a = *b;

Show me where con/destructors are used.

Case 2:

struct x { int a, int b; };

struct x a;
struct x *b;

a = *b;

Show me where con/destructors are used.

You keep rambling on about this without any solid evidence.

Maybe. If b is a pointer to a class... That was case 3) in your list
that you left out. Why?

And what about an array of classes ???

Etc Etc. Please consult ANY C++ textbook and they will tell you many
ways to cleverly avoid that problem.

This is not AT ALL my intention. The proposed changes do not affect the
efficency at all, and they are really optional in the sense that the
efficiency loss is only paid by people that use them. In C++ you get
your constructors/destructors whether you want it or not. Operator
overloading is a change that will affect only people that use that
feature. Nobody else has to pay for it.

Twaddle.

This is a great argument.

"Twaddle".

I am impressed.
In case 2 above, both C and C++ compiler can generate the same code.

The same thing for ALL other changes that are done in lcc-win32:

o overloaded functions: No efficiency lost since the compiler generates
the same machine code as before. This is just compile time changes.

But opens up that other can of worms, name mangling and all the
incompatibilities that can introduce.

Only if you want the compiler to generate automatically the overloaded
names. If you provide the names, no mangling is done:

double fn1(double);
int fn2(long double,int);

double overloaded FN.fn1(double); // This will resolve to a call to fn1
int overloaded FN.fn2(long double); // Will resolve to a call to fn2

FN(2.3); --> will resolve into a call to fn1
FN(2.3L,1); --> will resolve into a call to fn2

No name mangling is done in this case. The overloaded function FN will
resolve to a call of fn1 in one case, fn2 in another case.

[jacob navia]

CBFalconer a écrit :

jacob navia wrote:

... snip ...

This is not AT ALL my intention. The proposed changes do not affect
the efficency at all, and they are really optional in the sense
that the efficiency loss is only paid by people that use them. In
C++ you get your constructors/destructors whether you want it or
not. Operator overloading is a change that will affect only people
that use that feature. Nobody else has to pay for it.

The same thing for ALL other changes that are done in lcc-win32:

o overloaded functions: No efficiency lost since the compiler generates
the same machine code as before. This is just compile time changes.
o operator overloading: No efficiency lost for people that do not use
this feature. Some cycles (minimal) of extra cost are there for simple
implementations like the one in lcc-win32. An optimizing compiler
would have no trouble in eliminating it.
o Default arguments: No efficiency loss at all. This is just some
syntatic sugar.

Not so.

default arguments:
The compiler has to generate default parameter values. It can now
no longer detect omitted parameters during a call. One more source
of evil gotchas.

No. Only functions with a prototype specifying default arguments can
have them. All other functions stay exactly the same.

Required arguments must come first in the call, and all optional
arguments come later. The compiler generates them from the prototype of
the function. This reduces the memory footprint for many functions.

Not RAM of course. Human memory, that is far more precious. Can't buy a
Gig of human memory at the next store to accomodate functions with 8 or
even 10 arguments!

operator overloading:
Already exists in some places, since you can add floats, or
integers. Any further extension needs a complex set of automatic
cast rules and/or a set of implementing runtime routines, with
attendant source errors possible.

Yes, and they are possible even now with the overloading of
int/floats/doubles/complex additions :-)
Overloaded functions:
The objections to default arguments apply. I could probably think
of more, including bloating the compiler proper.

The whole module for operator overloading and overloaded functions is
1723 lines of C including comments and lines with just an opening brace.

[Mark McIntyre]

On Sat, 06 May 2006 00:48:45 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

Maybe. If b is a pointer to a class... That was case 3) in your list
that you left out. Why?
I'll take a wild guess - because C doesn't have classes?
And what about an array of classes ???
What, some sort of school assembly?
Etc Etc. Please consult ANY C++ textbook and they will tell you many
ways to cleverly avoid that problem.

What, *any* c++ text book? Hmm, I checked in "Learn Visual C++ in 21
days" and it barely mentioned classes...
--
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]

CBFalconer <cb********@yahoo.com> writes:
[...]

For example, a future standard could restrict 'precedence' to three
levels (e.g. logical, additive, and multiplicative) only, requiring
parentheses for any further control, yet allowing the actions of
the present silly system. The result would be clearer code without
necessarily breaking older code.
You'd need at least four level, unless you want to require
x = y + z;
to be written as
x = (y + z);

But if you did reduce the number of precedence level, an automatic
tool could translate existing C to add newly required parentheses.
It could deprecate such
obfuscative things as +=, without efficiency losses, since
optimizers can easily handle the longer phrases.

<OPINION>LHS += RHS can be much clearer than LHS = LHS + RHS if LHS is
a complex expression</OPINION> -- and it's not equivalent if LHS has
side effects. (The counterargument is that, in cases where it
matters, you should write simpler code.)

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

[Ian Collins]

jacob navia wrote:

Ian Collins a écrit :

jacob navia wrote:

The operator overloading change do not affect efficiency at all. One of
Case 1:

int a;
int *b;

a = *b;

Show me where con/destructors are used.

Case 2:

struct x { int a, int b; };

struct x a;
struct x *b;

a = *b;

Show me where con/destructors are used.

You keep rambling on about this without any solid evidence.

Maybe. If b is a pointer to a class... That was case 3) in your list
that you left out. Why?

Sorry but you are digging yourself into a hole. Ignoring the face that
C doesn't have classes, in C++ there is one difference between a struct
and a class - the default access. I could have written

Case 3:

class x { public: int a, int b; };

x a;
x *b;

a = *b;

But it isn't C and it adds nothing to the argument.

I say again, show me an example of con/destructor use in any of the above.
And what about an array of classes ???
What about one?
Etc Etc. Please consult ANY C++ textbook and they will tell you many
ways to cleverly avoid that problem.

This is not AT ALL my intention. The proposed changes do not affect the
efficency at all, and they are really optional in the sense that the
efficiency loss is only paid by people that use them. In C++ you get
your constructors/destructors whether you want it or not. Operator
overloading is a change that will affect only people that use that
feature. Nobody else has to pay for it.

Twaddle.

This is a great argument.

"Twaddle".

I am impressed.

Thank you, it was the most concise summary I could use without being rude :)

In case 2 above, both C and C++ compiler can generate the same code.
You didn't address the body of the argument, the line above.

The same thing for ALL other changes that are done in lcc-win32:

o overloaded functions: No efficiency lost since the compiler generates
the same machine code as before. This is just compile time changes.

But opens up that other can of worms, name mangling and all the
incompatibilities that can introduce.

Only if you want the compiler to generate automatically the overloaded
names. If you provide the names, no mangling is done:

double fn1(double);
int fn2(long double,int);

double overloaded FN.fn1(double); // This will resolve to a call to fn1
int overloaded FN.fn2(long double); // Will resolve to a call to fn2

FN(2.3); --> will resolve into a call to fn1
FN(2.3L,1); --> will resolve into a call to fn2

No name mangling is done in this case. The overloaded function FN will
resolve to a call of fn1 in one case, fn2 in another case.

Maybe not, but it's dead ugly and not recognisable C syntax. It's
introducing more complexity into the language.

--
Ian Collins.

[websnarf]

Robert Latest wrote:

On 2006-05-04, we******@gmail.com <we******@gmail.com> wrote:

I think the point is that there are *many* such application. In fact I
would be suspicious of anyone who claimed to be an experienced
programmer who hasn't *written* one of these.
...and I would be suspcious of anyone who claimed to be an
experienced programmer who can't write the necessary routines
from scratch in less time than it takes to download, install, and
understand a dedicated string library. In fact I want to see a
single experienced programmer who hasn't written his own little
string library at some point in his career -- be it as a
homework assignment or just to kill time on a rainy weekend.

Can you write 102 well tested functions that are aliasing safe, support
write protection, have a performance advantage over comparable straight
C across the board on multiple platforms, in portable C, immune to
buffer overflows and size overflowing in less than an hour? That I
would like to see.

You also make the mistake of thinking experienced programmers are C
programmers. C (and C++) is the only language where someone would want
to *write* a string library. No other language needs it. And of
course, the fact the many C programmers might be writing string
libraries doesn't seemed to have affected the number of buffer overflow
flaws that are commonly shipped in applications written in C.
All these points are moot anyway -- it is very likely that the
people manipulating millions of tiny string needs a completely
different library than the huge-document-in-memory crowd. For
obvious reason, there is no one-size-fits-all solution.

Right -- Bstrlib is sometimes less than optimal for some instances of
those cases (though it is *always* safer and easier), and is really
only universally targetted at every single other case.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Ian Collins]

we******@gmail.com wrote:

Robert Latest wrote:

On 2006-05-04, we******@gmail.com <we******@gmail.com> wrote:

I think the point is that there are *many* such application. In fact I
would be suspicious of anyone who claimed to be an experienced
programmer who hasn't *written* one of these.

...and I would be suspcious of anyone who claimed to be an
experienced programmer who can't write the necessary routines
from scratch in less time than it takes to download, install, and
understand a dedicated string library. In fact I want to see a
single experienced programmer who hasn't written his own little
string library at some point in his career -- be it as a
homework assignment or just to kill time on a rainy weekend.

Can you write 102 well tested functions that are aliasing safe, support
write protection, have a performance advantage over comparable straight
C across the board on multiple platforms, in portable C, immune to
buffer overflows and size overflowing in less than an hour? That I
would like to see.

You also make the mistake of thinking experienced programmers are C
programmers. C (and C++) is the only language where someone would want
to *write* a string library. No other language needs it. And of
course, the fact the many C programmers might be writing string
libraries doesn't seemed to have affected the number of buffer overflow
flaws that are commonly shipped in applications written in C.

That's one of the things that hurts C, think how much more productive
those programmers would be if they didn't have to write their own string
library.

--
Ian Collins.

[Ed Jensen]

CBFalconer <cb********@yahoo.com> wrote:

That all depends on the license under which the source code was
released. Linking a bunch of C libraries under various licenses can
involve non-trivial amounts of legal hassle to ensure compliance.
If you publish your source under GPL, there is very little chance
of conflicts. In the case of things I have originated, all you
have to do is contact me to negotiate other licenses. I can be
fairly reasonable on months with a 'R' in them.

Many years ago, I helped write a moderately large project in C. More
recently, I helped rewrite the project in Java. Due to the standard
Java library, here are some of the advantages I encountered:

1. Much less time spent evaluating dozens of third party libraries.

2. Much less time spent ensuring legal compliance with dozens of third
party libraries.

3. Much less time spent keeping third party libraries updated (when
new features became available that we wanted to leverage or exploits
in older versions were discovered).

4. Many fewer cross platform issues.

Alas, I can already tell this post will make me look like a wild eyed
Java zealot. All I can do is state that my only real intention with
this post is to demonstrate the value of a comprehensive standard
library.
No, there is nothing wrong with expanding the standard library.
Nothing forces anyone to use such components anyhow. There is
provision in the standard for "future library expansion". This is
a far cry from bastardizing the language with overloaded operators
and peculiar non-standard syntax, as recommended by some of the
unwashed.
I mostly agree. C++ already fills that role, for those who care to
use it. (I say mostly because I would like to see some minor changes
to C syntax, but nothing too wild.)
Go ahead and advocate. I would certainly like to see at least
strlcpy/cat in the next standard, with gets removed, and possibly
my own hashlib and ggets added. What all of those things are is
completely described in terms of the existing C standards, so the
decisions can be fairly black and white.

I think those changes would be an excellent start. I'm not sure C
will be able to continue to grow without starting to break from the
past (at least a little bit).

[Keith Thompson]

Ian Collins <ia******@hotmail.com> writes:
[...]

That's one of the things that hurts C, think how much more productive
those programmers would be if they didn't have to write their own string
library.

Nobody *has* to write his own string library. There are a number of
them floating around, as a quick Google search will show.

In some cases, if you only need a few operations, writing your own
might turn out to be easier than tracking down an existing library and
learning to use it.

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

[Ian Collins]

Keith Thompson wrote:

Ian Collins <ia******@hotmail.com> writes:
[...]

That's one of the things that hurts C, think how much more productive
those programmers would be if they didn't have to write their own string
library.

Nobody *has* to write his own string library. There are a number of
them floating around, as a quick Google search will show.

In some cases, if you only need a few operations, writing your own
might turn out to be easier than tracking down an existing library and
learning to use it.

But if there was a standard one...

I fear that C is in danger of shrinking into that ever diminishing niche
where other languages can't go. Give the language library some standard
containers, string, regular expressions and let it compete on a level
playing field with more recent languages.

--
Ian Collins.

[Walter Roberson]

In article <44***************@yahoo.com>,
CBFalconer <cb********@maineline.net> wrote:

For example, a future standard could restrict 'precedence' to three
levels (e.g. logical, additive, and multiplicative) only, requiring
parentheses for any further control, yet allowing the actions of
the present silly system.

People might possibly grudgingly accept needing parens for
~ and !, but there is a long history of unary minus in indicating the
sign of constants and I'm not sure how happy people would be with
needing parens around every negative number.

I think people might also object to needing to put parens around
the elements of the triple in a for loop:

for ((i=10);(i>(-1));(i--)) ({ ((A[(i*2)])=(A[(i+1)])) });

since you also eliminated the precedence associated with
array indexing, assignment, and compound blocks..

Hmmm, how should that assignment be written? As
parens would be needed to demark lvalues (since they
are not logical, additive, or multiplicative)... but
the parens would imply taking the value of the array
element at that point, rather than the address...
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

[websnarf]

Ian Collins wrote:

we******@gmail.com wrote:

You also make the mistake of thinking experienced programmers are C
programmers. C (and C++) is the only language where someone would want
to *write* a string library. No other language needs it. And of
course, the fact the many C programmers might be writing string
libraries doesn't seemed to have affected the number of buffer overflow
flaws that are commonly shipped in applications written in C.

That's one of the things that hurts C, think how much more productive
those programmers would be if they didn't have to write their own string
library.

I don't know if you are being sarcastic or not. Certainly C
programmers would be more productive if they were not wasting time
debugging buffer overflows. I think C is the only language or
mechanism which has hundreds CERT advisories for the exact same bug. C
programmers might be more productive if they didn't need to reroll a
hash table, or vector or myriad of other data structures that come
prepackaged in other languages (and debug them) as well.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Ian Collins]

we******@gmail.com wrote:

Ian Collins wrote:

we******@gmail.com wrote:

You also make the mistake of thinking experienced programmers are C
programmers. C (and C++) is the only language where someone would want
to *write* a string library. No other language needs it. And of
course, the fact the many C programmers might be writing string
libraries doesn't seemed to have affected the number of buffer overflow
flaws that are commonly shipped in applications written in C.

That's one of the things that hurts C, think how much more productive
those programmers would be if they didn't have to write their own string
library.

I don't know if you are being sarcastic or not. Certainly C
programmers would be more productive if they were not wasting time
debugging buffer overflows. I think C is the only language or
mechanism which has hundreds CERT advisories for the exact same bug. C
programmers might be more productive if they didn't need to reroll a
hash table, or vector or myriad of other data structures that come
prepackaged in other languages (and debug them) as well.

No sarcasm intended. I agree with all you say.

--
Ian Collins.

[CBFalconer]

Ed Jensen wrote:

CBFalconer <cb********@yahoo.com> wrote:

That all depends on the license under which the source code was
released. Linking a bunch of C libraries under various licenses can
involve non-trivial amounts of legal hassle to ensure compliance.
If you publish your source under GPL, there is very little chance
of conflicts. In the case of things I have originated, all you
have to do is contact me to negotiate other licenses. I can be
fairly reasonable on months with a 'R' in them.

Many years ago, I helped write a moderately large project in C. More
recently, I helped rewrite the project in Java. Due to the standard
Java library, here are some of the advantages I encountered:

1. Much less time spent evaluating dozens of third party libraries.

What evaluation? You do it once. You can also evaluate the
source.
2. Much less time spent ensuring legal compliance with dozens of third
party libraries.
If you operate under GPL what compliance problems? If you want
something for nothing and also want to absorb it, that's another
matter.

3. Much less time spent keeping third party libraries updated (when
new features became available that we wanted to leverage or exploits
in older versions were discovered).
What updates? If things are written in standard C they won't need
updating, apart from insects. The older the source files dates the
better (up to a point).

4. Many fewer cross platform issues.

Once again, use standard C. Virtually eliminates platform issues.

Please don't strip attributions for material you quote.

If you want a specialized library for the DeathStation when fitted
with three Mark XVII missiles, then you should probably resign
yourself to writing it for yourself.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[CBFalconer]

Walter Roberson wrote:

CBFalconer <cb********@maineline.net> wrote:

For example, a future standard could restrict 'precedence' to three
levels (e.g. logical, additive, and multiplicative) only, requiring
parentheses for any further control, yet allowing the actions of
the present silly system.

People might possibly grudgingly accept needing parens for
~ and !, but there is a long history of unary minus in indicating the
sign of constants and I'm not sure how happy people would be with
needing parens around every negative number.

The unary minus is a chimera. C does not parse these things in
that form. The action of "-32768" is to apply a negation to the
positive integer 32768. If that creates an overflow, tough.

Examining the definition of INT_MIN in limits.h may be informative.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[CBFalconer]

we******@gmail.com wrote:

Ian Collins wrote:

.... snip ...

That's one of the things that hurts C, think how much more
productive those programmers would be if they didn't have to
write their own string library.

I don't know if you are being sarcastic or not. Certainly C
programmers would be more productive if they were not wasting
time debugging buffer overflows. I think C is the only language
or mechanism which has hundreds CERT advisories for the exact
same bug. C programmers might be more productive if they didn't
need to reroll a hash table, or vector or myriad of other data
structures that come prepackaged in other languages (and debug
them) as well.

Well, I can't remember debugging a buffer overflow in my own code.
I do regularly use the standard string package.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Joe Wright]

CBFalconer wrote:

we******@gmail.com wrote:

Ian Collins wrote:

... snip ...

That's one of the things that hurts C, think how much more
productive those programmers would be if they didn't have to
write their own string library.

I don't know if you are being sarcastic or not. Certainly C
programmers would be more productive if they were not wasting
time debugging buffer overflows. I think C is the only language
or mechanism which has hundreds CERT advisories for the exact
same bug. C programmers might be more productive if they didn't
need to reroll a hash table, or vector or myriad of other data
structures that come prepackaged in other languages (and debug
them) as well.

Well, I can't remember debugging a buffer overflow in my own code.
I do regularly use the standard string package.

No you don't. Not all of it. I'll bet you haven't used gets() in years. :-)

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Ed Jensen]

CBFalconer <cb********@yahoo.com> wrote:

1. Much less time spent evaluating dozens of third party libraries.

What evaluation? You do it once. You can also evaluate the
source.

Even once can involve a lot of overhead if you need a few dozen
libraries and there are 3 or 4 competitors in each area. Take a look
at the sometimes obscene dependencies list on non-trivial projects.

Having the source available is always an advantage.

2. Much less time spent ensuring legal compliance with dozens of third
party libraries.

If you operate under GPL what compliance problems? If you want
something for nothing and also want to absorb it, that's another
matter.

Operating under the GPL is often not an option. In addition,
sometimes the solution you've chosen is not available under the GPL.

3. Much less time spent keeping third party libraries updated (when
new features became available that we wanted to leverage or exploits
in older versions were discovered).

What updates? If things are written in standard C they won't need
updating, apart from insects. The older the source files dates the
better (up to a point).

If you're linking in a few dozen libraries, I should hope you're
keeping abreast of updates to see if newer versions fix exploits.

4. Many fewer cross platform issues.

Once again, use standard C. Virtually eliminates platform issues.

It's possible to write extremely portable C code. It can also be an
extremely non-trivial exercise.

[jacob navia]

Ed Jensen a écrit :
[snip]

It's possible to write extremely portable C code. It can also be an
extremely non-trivial exercise.

Portable C will never have the speed of fine tuned assembler/optimized
libraries that have been written by the compiler system writers and use
each advantage for the specific platform they are writing to.

If you want to remain portable, you can't use any speedups, shortcuts or
system specific stuff by definition.

The advantage of language wide libraries like the C library is that the
compiler vendors can optimize it for each platform, underneath a common
interface visible by the library user.

jacob

[websnarf]

CBFalconer wrote:

we******@gmail.com wrote:

Ian Collins wrote:

... snip ...

That's one of the things that hurts C, think how much more
productive those programmers would be if they didn't have to
write their own string library.

I don't know if you are being sarcastic or not. Certainly C
programmers would be more productive if they were not wasting
time debugging buffer overflows. I think C is the only language
or mechanism which has hundreds CERT advisories for the exact
same bug. C programmers might be more productive if they didn't
need to reroll a hash table, or vector or myriad of other data
structures that come prepackaged in other languages (and debug
them) as well.

Well, I can't remember debugging a buffer overflow in my own code.
I do regularly use the standard string package.

And therefore there are no CERT advisories related to buffer overflows
when using C string functions. Right? Wow -- pure genius, you just
solved far and away the biggest software security problem in existence
(by a ridiculous margin) with mere force of your eloquent disposition.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[websnarf]

CBFalconer wrote:

Ed Jensen wrote:

CBFalconer <cb********@yahoo.com> wrote:

That all depends on the license under which the source code was
released. Linking a bunch of C libraries under various licenses can
involve non-trivial amounts of legal hassle to ensure compliance.

If you publish your source under GPL, there is very little chance
of conflicts. In the case of things I have originated, all you
have to do is contact me to negotiate other licenses. I can be
fairly reasonable on months with a 'R' in them.
Many years ago, I helped write a moderately large project in C. More
recently, I helped rewrite the project in Java. Due to the standard
Java library, here are some of the advantages I encountered:

1. Much less time spent evaluating dozens of third party libraries.

What evaluation? You do it once. You can also evaluate the
source.

What exactly do you think he's talking about? There is a lot of
unusuable crap out there, and you have to examine things seriously
before you use them. You end up evaluating everything you use as well
as everything you consider to be a candidate but do not use.

2. Much less time spent ensuring legal compliance with dozens of third
party libraries.

If you operate under GPL what compliance problems? If you want
something for nothing and also want to absorb it, that's another
matter.

Tell that to Microsoft, SCO or other proprietary vendors. BSD and MIT
tend to be far more compatible licenses. You only use the GPL if you
are supporting the FSF adgenda -- i.e., if you intentionally want to
keep proprietary vendors from using your code (even if they make a
widely deployed C compiler).

3. Much less time spent keeping third party libraries updated (when
new features became available that we wanted to leverage or exploits
in older versions were discovered).

What updates? If things are written in standard C they won't need
updating, apart from insects. The older the source files dates the
better (up to a point).

You write bug free, scalable code that never needs to be updated? Oh
wait, I *know* you don't do that -- perhaps its some code you don't
publish on your website that we never get to see that is written to
such perfection.

The truth is that for all serious non-trivial libraries, you have to
make provisions for periodic updates. And C libraries are worse
because there is a much higher probability of being bitten by a flaw of
catastrophic proportions. The standard JPEG library flaw, that allowed
people to arbitrarily take over client machines remotely by hosting
specially constructed exploit images is merely the latest in classic
examples of this.

4. Many fewer cross platform issues.

Once again, use standard C. Virtually eliminates platform issues.

Use any other modern language and it does a better job at eliminating
platform issues.
If you want a specialized library for the DeathStation when fitted
with three Mark XVII missiles, then you should probably resign
yourself to writing it for yourself.

This problem of dealing with control of WMDs is something completely
different -- it affects more people that the people creating them. In
that event you throw money at the problem, by paying for review, not
operating on deadlines set by marketing and you program them in serious
and verifiable languages like Ada.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Malcolm]

"Ian Collins" <ia******@hotmail.com> wrote

I must be missing something, you have the same problem with pointers,
don't you?

If you see someFn( &x ), how do you know if someFn's prototype is

void someFn( int* ); or
void someFn( const int* );

without looking it up?

If the function takes a pointer to a single integer it must either change
that integer, sometimes change the integer, or sometimes go through versions
which change the integer. Otherwise the author would have written it to take
an int.
(The unfortunate exception is functions which are written in Fortran but
called from C. Fortran takes all arguments as pointer.)

When x is an array, there is a problem. With hindsight K and R should have
incuded some sort of syntactical marker, such as puting writable arguments
in <> brackets, to mark arrays as writeable. It is too late now.

--
www.personal.leeds.ac.uk/~bgy1mm
Programming goodies.

[Ian Collins]

Malcolm wrote:

"Ian Collins" <ia******@hotmail.com> wrote

I must be missing something, you have the same problem with pointers,
don't you?

If you see someFn( &x ), how do you know if someFn's prototype is

void someFn( int* ); or
void someFn( const int* );

without looking it up?

If the function takes a pointer to a single integer it must either change
that integer, sometimes change the integer, or sometimes go through versions
which change the integer. Otherwise the author would have written it to take
an int.

OK, int was a bad choice, replace it with someStruct and the argument is
more compelling.

--
Ian Collins.

[John F]

"Richard Tobin" wrote:

John F <ca************@gmx.at> wrote:

There is a difference between

(date1+date2)/2 (adds dates and divides by two)

and

date1+(date2-date1)/2 (proportionally adds the difference between
two
dates to another date)

The former is meaningless (in a mathematical sense)

That's OK, I understand mathematics, tell me the "mathematical
sense"
in which it's meaningless. Perhaps you could start with a
mathematical
definition of "meaningless", since I've never come across one.

It's no longer a date. So you are no longer within the same set. You
leave the domain, which is not acceptable and thus not meaningful for
an inner binary operator as the usual addition is.

If you argue that adding dates is legal then I suggest you define
the
binary operator

What binary operator?

"+"

and the division-operator in a serious way. (e.g. it
should tell: What is (March, 13th 2003) / 2? )

It's something which when multiplied by 2 gives you March 13 2003,
and which when added to (March 11 2003) / 2 gives youy March 12
2003.
It is not, of course, a date. There isn't any conventional way to
write it, nor is there a conventional name for its type. But we can
perfectly well define various operations on it.

Sure we can. But here you agree that the result is meaningless in the
sense of being a date (thus not staying within the domain). You may
define an outer binary operator.

--
regards
John

[John F]

"Keith Thompson" wrote:

"John F" <sp**@127.0.0.1> writes:

"Richard Tobin" wrote:

Joe Wright wrote:
Adding date values is nonsense.

Why? The averaging example I gave shows a perfectly clear use of
it.

It might be nonsense to claim that adding date values gives you a
date, but that's not what I said.

Another analogy: I have heard it claimed that adding celsius
temperatures is nonsense, yet people do it all the time when
averaging
temperatures.
There is a difference between

(date1+date2)/2 (adds dates and divides by two)

and

date1+(date2-date1)/2 (proportionally adds the difference between
two
dates to another date)

The former is meaningless (in a mathematical sense), the latter is
perfectly legal.

[...]

The former includes a subexpression that yields a result that's not
meaningful, but the expression has a whole is meaningful.

Thanks for clarification. I was referring to the math behind it where
it yealds an error in the domain ot the binary operator +...
Dates, temperatures, and pointers are all similar in the sense that
each can be thought of as a pair: base+offset, where the base is
respectively an arbitrary epoch, an arbitrary zero temperature, or a
zero address (or the base address of a containing object). In each
case, the "base" is some fixed point, and the "offset" is a scalar
quantity. Offsets by themselves can be added and subtracted freely;
the base is meaningful only if you have exactly zero or one of it.
(With no base, you have an interval or distance; with a base, you
have
a position.)

(Assume Celsius or Fahrenheit temperatures; the zero base of Kelvin
scale is uniquely meaningful, so it's not restricted to this model.) Subtracting two dates
date1 - date2
is equivalent to:
(base+offset1) - (base+offset2)
which reduces to:
offset1 - offset2
which is meaningful; it's an interval, measurable in seconds, with
no
defined base.
Exactly. At least if you assume the same base for the representation,
and the same scale for the offset too.
Adding two dates:
date1 + date2
is equivalent to:
(base+offset1) + (base+offset2)
which reduces to:
2*base + offset1 - offset2
which is not directly meaningful because of the 2*base term.
Exactly. You can't tell what it should be. Same applies as above. Same
scale for the offset and a common base can be found to set the base_x
values. Which should be quite hard for a time-scale. One can always go
back and back... With temperature a natural limit showed up with
absolute zero.

Have you ever tried to translate a chinese date into the gregorian
calendar? It is really nice.
However, if it's used as an intermediate expression, as in:
(date1 + date2) / 2
we have
((base+offset1) + (base+offset2)) / 2
or
(2*base + offset1 - offset2) / 2
or
base + (offset1 - offset2)/2
a meaningful expression that denotes the midpoint between the two
dates.
Again assuming a common base and the same scale for the offset. (just
to remind :-)
Ideally, we'd like to make expressions with meaningful results
legal,
and expressions without meaningful results illegal. Theoretically,
we
could do this by allowing meaningless intermediate results, as long
as
the result of the full expression is meaningful.
Agreed.
There are (at least) two problems with this approach. First, it
makes
the language rules more complex, which affects both compiler writers
(who can deal with it) and users (who likely can't). Try explaining
to a newbie that (date1 + date2), or (pointer1 + pointer2), is
usually
illegal, except that it's allowed as a subexpression if and only if
the expression as a whole obeys certain constraints.
I don't want to do that. Really. Avoiding objects where intermediate
results can't be illegal as a whole would fix 80% of all bugs, I
guess.
Second, it makes
it difficult to define the circumstances in which overflow can
occur.
Yes.
Pointer arithmetic in C is defined only within a single object (or
just past its end); allowing pointer+pointer gives you intermediate
results that not only don't have an obvious meaning, but may not be
representable, depending on where in the address space the object
happens to be allocated.
Exactly. It would be hard to implement too.
Ignoring the overflow problem, if you're using raw numbers to
represent dates, something like (date1+date2)/2 is ok, as long as
you
have the discipline to avoid writing a full expression that's not
meaningful:
x = date1 + date2; /* meaningless, but the compiler won't
complain */
At least with weak checking. One could argue that we could define a
type

"SOD" (Sum of dates" and you would need to make this type illegal for
an lvalue.

the "2" in the expression
x=(date1 + date2)/2 should get type "DD" (DateDevider)

and [SOD]/[DD] = [D] such that x would get type D again. It is a lot
of brainy stuff, but should work. (never seen a language with such a
feature (except VB with its "Variant", where almost every operation
yealds a meaningful result (regarding the type)))

I'd rather have a function x = mediandate( date1, date2 ); for that
job.
If you're using a hypothetical language that does this kind of smart
type checking, allowing date1+date2 as a subexpression but not as a
full expression, you can add dates to your heart's content and
depend
on the implementation to detect any type matching errors. It would
be
interesting to design this kind of thing, either as a language
feature
(off-topic here), or as a library with run-time checking (doable in
standard C, with functions rather than overloaded operators).
Again,
overflow is a concern unless you can either use extended precision
for
intermediate results, or rely on the implementation to rearrange the
expressions for you.
Using the natural division: char for day, char for month, long long
for year and double for the seconds within a day it shouldn't be any
problem. It is all a matter of promotion :-)
Finally, if you're using standard C and operating on pointers,
you'll
just have to rearrange the expression yourself. If you need to know
the address halfway between two pointers, you can't write:
mid = (ptr1 + ptr2) / 2;
You'll just have to bite the bullet and write:
mid = ptr1 + (ptr2 - ptr1) / 2;

One should add: for ptr2 >= ptr1.
(never seen a negative pointer in C)

(sorry for the long post, thanks for reading up till here)

--
regards
John

[Keith Thompson]

"Malcolm" <re*******@btinternet.com> writes:

"Ian Collins" <ia******@hotmail.com> wrote

I must be missing something, you have the same problem with pointers,
don't you?

If you see someFn( &x ), how do you know if someFn's prototype is

void someFn( int* ); or
void someFn( const int* );

without looking it up?

If the function takes a pointer to a single integer it must either change
that integer, sometimes change the integer, or sometimes go through versions
which change the integer. Otherwise the author would have written it to take
an int.
(The unfortunate exception is functions which are written in Fortran but
called from C. Fortran takes all arguments as pointer.)

When x is an array, there is a problem. With hindsight K and R should have
incuded some sort of syntactical marker, such as puting writable arguments
in <> brackets, to mark arrays as writeable. It is too late now.

You can't have a parameter of array type in C. This:
void foo(int x[]);
is precisely equivalent to this:
void foo(int *x);

In my opinion it would have been better to drop the [] syntax for
parameters, and require them to be written as the pointers they really
are.

Either that, or somehow make arrays first-class objects and actually
support passing them as parameters.

C99 adds some new syntax for array parameters, which complicates the
discussion -- but it is, as you say, too late now.

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

[Richard Bos]

CBFalconer <cb********@yahoo.com> wrote:

Walter Roberson wrote:

CBFalconer <cb********@maineline.net> wrote:

For example, a future standard could restrict 'precedence' to three
levels (e.g. logical, additive, and multiplicative) only, requiring
parentheses for any further control, yet allowing the actions of
the present silly system.

People might possibly grudgingly accept needing parens for
~ and !, but there is a long history of unary minus in indicating the
sign of constants and I'm not sure how happy people would be with
needing parens around every negative number.

The unary minus is a chimera. C does not parse these things in
that form. The action of "-32768" is to apply a negation to the
positive integer 32768.

That is precisely Walter's point. Under your restricted precedence
rules, -32768 would have to be written as -(32768) (and in most contexts
as (-(32768)) ), since unary minus is not a logical, additive or
multiplicative operator. (In particular, despite appearances it is not
the additive minus operator, since it must have a different precedence
in expressions such as -3*4, which is (-3)*4, not -(3*4).)

Richard