473,839 Members | 1,538 Online

# Boost process and C

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

Apr 29 '06
335 11909

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:44******** ********@news.x s4all.nl...
CBFalconer <cb********@yah oo.com> wrote:
Walter Roberson wrote:
CBFalconer <cb********@mai neline.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).)

Unary minus is a multiplicative operator. It represents a multiple of -1
multiplied by a positive number.

-b = b*-1

Subtraction is addition with a unary minus:

a-b=a+(-b)

which can be expressed as:

a-b=a+(b*-1)

Therefore, the precedence of unary minus is due to the precedence of
multiplication (or division).
Rod Pemberton
May 8 '06 #301
[...]
Unary minus is a multiplicative operator. It represents a multiple of -1
multiplied by a positive number.

-b = b*-1
No, unary minus is not a multiplicative operator. It happens to be
mathematically equivalent to multiplication by -1 -- but then how do
you express "-1" without using unary minus? It's also mathematically
equivalent to subtraction from zero.

The standard says that "The result of the unary - operator is the
negative of its (promoted) operand." It's not defined in terms of
other operators.
Subtraction is addition with a unary minus:

a-b=a+(-b)

which can be expressed as:

a-b=a+(b*-1)

Therefore, the precedence of unary minus is due to the precedence of
multiplication (or division).

Again, whatever subtraction might be mathematically equivalent to,
it's not defined in terms of other operations. "The result of the
binary - operator is the difference resulting from the subtraction of
the second operand from the first."

Consider INT_MIN - INT_MIN, which is well defined and yields zero.
Defining it in terms of addition with a unary minus introduces a
possible overflow.

--
Keith Thompson (The_Other_Keit h) 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.
May 8 '06 #302

jacob navia wrote:
I never said it did. I said that C++ and Ada, like C, are languages
It I need it, I use one of them.
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;

has a similar feature with its finalized types.

foo bar(1,2);
creates just as efficient code as
foo bar = {1, 2};

and I can use bar(1,2) in place where I cannot use {1,2}.

Plus, I find RAII to be a nice tool. But again, if I need it, I use a
language that has it.

<snip remainder>

REH

May 8 '06 #303

"Keith Thompson" <ks***@mib.or g> wrote in message
news:ln******** ****@nuthaus.mi b.org...
[...]
Unary minus is a multiplicative operator. It represents a multiple of -1 multiplied by a positive number.

-b = b*-1

No, unary minus is not a multiplicative operator. It happens to be
mathematically equivalent to multiplication by -1 -- but then how do
you express "-1" without using unary minus? It's also mathematically
equivalent to subtraction from zero.

As "-1", of course. The C language didn't implement it in such a fashion.
But, it could been
implemented as context dependent token just like the use of zero, when used
in a pointer context,
is recognized as the null pointer. A negative integer constant, like "=1",
could've eliminated
both subtraction and unary minus.
Subtraction is addition with a unary minus:

a-b=a+(-b)

which can be expressed as:

a-b=a+(b*-1)

Therefore, the precedence of unary minus is due to the precedence of
multiplication (or division).

Consider INT_MIN - INT_MIN, which is well defined and yields zero.
Defining it in terms of addition with a unary minus introduces a
possible overflow.

The keyword to your argument is _possible_. The compiler is free to use
associative, commutative, distributive, and other proofs of mathematics as
long as the correct result is produced.

For example, it could be done this way.
Given:
INT_MIN (-2147483647-1)

INT_MIN rewritten in terms of (-1):
INT_MIN ((-1)*2147483647+(-1)*1)

Difference of INT_MIN-INT_MIN, using integer promotions and distributive
multiplication,
and returning the correct result:
INT_MIN-INT_MIN
INT_MIN+((-1)*INT_MIN)
((-1)*2147483647+(-1)*1)+(-1)*((-1)*2147483647+(-1)*1)
(-2147483647+(-1))+(-1)*(-2147483647+(-1))
(-2147483647+(-1))+(-1)*(-2147483647+(-1))
(-2147483647+(-1))+2147483647+ 1
-2147483648+2147 483647+1
-1+1
0
In fact, the specification _seems_ to encourage using equivalent
mathematical calculations if it eliminates known possible overflows and
underflows.

5.1.2.3 Program execution
"3 In the abstract machine, all expressions are evaluated as specified by
the semantics. An
actual implementation need not evaluate part of an expression if it can
deduce that its
value is not used and that no needed side effects are produced (including
any caused by
calling a function or accessing a volatile object)."

5.1.2.3 Program execution
"10 EXAMPLE 2 In executing the fragment
char c1, c2;
/* ... */
c1 = c1 + c2;
the ''integer promotions'' require that the abstract machine promote the
value of each variable to int size
and then add the two ints and truncate the sum. Provided the addition of two
chars can be done without
overflow, or with overflow wrapping silently to produce the correct result,
the actual execution need only
produce the same result, possibly omitting the promotions."

6.3.1.1 Boolean, characters, and integers
"2 ... If an int can represent all values of the original type, the value is
converted to an int;
otherwise, it is converted to an unsigned int. These are called the integer
promotions.48) All other types are unchanged by the integer promotions."

Rod Pemberton
May 10 '06 #304
Rod Pemberton said:
"Richard Heathfield" <in*****@invali d.invalid> wrote in message
news:0O******** ************@bt .com...
jacob navia said:
> You can go on if you wish. I will go on posting here. Neither you nor
> anyone else has any authority to tell me what I should do or not do.
That's right. You are free to throw your reputation down the tubes, and
nobody here can stop you, try as they might.

His reputation is far better than yours.

Either that statement is true, or it is false, or it is undecidable. If it
is undecidable or false, there is no point discussing it further. But if it
is true, then we must ask ourselves how much longer it will /remain/ far
better than mine, if he continues to damage it at about the present rate.
Noone has ever heard of you.
Oh, that's not quite true. I have my little circles; and within them, I am
reasonably well-known.
And
if they did once learn of you, they sure don't remember you... The same
can be said of Keith Thompson, Martin Ambuhl, Chuck Falconer, etc...
Oh, that's not true either. Who could forget Martin? And of course I
remember Keith and Chuck too. So I am a counter-example to your claim that
nobody remembers Keith, Martin and Chuck.
Everyone knows about LCC-Win32 and Jacob Navia.

Well, no. My wife has never heard of either of them. Nor have my kids. Nor
have many of my friends. In fact, I would venture to suggest that, at a
bare minimum, 99.99% of people have never heard of either of them. And the
figure is probably much closer to 100% (although not, of course, exactly
100%).

Anyway, all this is academic. The point you have completely missed is this -
Jacob is damaging his reputation *here*, right here in comp.lang.c, and
that's not a good place for a C compiler-writer to make an idiot of
himself.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
May 10 '06 #305
CBFalconer <cb********@yah oo.com> wrote:
It could deprecate such obfuscative things as +=,

*Raises eyebrows*

Richard
May 10 '06 #306
Ian Collins <ia******@hotma il.com> wrote:
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'd still look at the prototype out of simple curiosity!

Of course. But with references, you _have_ to, even when you're pressed
for time and could have done with putting off the curiosity until after

Richard
May 10 '06 #307
On Tue, 09 May 2006 06:19:46 +0000, Richard Heathfield
<in*****@invali d.invalid> wrote:

Anyway, all this is academic. The point you have completely missed is this -
Jacob is damaging his reputation *here*, right here in comp.lang.c, and
that's not a good place for a C compiler-writer to make an idiot of
himself.

Consider the development of C as a team project. I am quite sure most
of those well paid consult companies specializing at team dynamics
would claim Jacob-like persons being valuable for this team project.
(available vacancies: advancer, refiner, executor, flexer and
creator)

Ok, if the 'C project' aim is to maintain the C, then the C language
would need to be declared as being perfect, since only perfect beings
don't need to evolve.

No, C is not yet 'perfect', In fact many C.L.C regulars are expression
dissatisfaction with numerous C issues. Just check...

So, clearly there needs to be some modernization into the C. The
classical C has and will have its important role, but would it hurt to
add some modern features into it. For example with a #PRAGMA attitude;

if (the environment allows a certain feature)
use_environment ;
else
(return some standard error code);

That would not take away anything from the original C and I think that
is just what Jacob, Rod et al. might want to achieve with requesting a
more tolerant attitude towards the 'C with extensions'.
Juuso Hukkanen
www.tele3d.com/wiki <-- one of the C's possibe futures

May 10 '06 #308
Richard Bos wrote:
Ian Collins <ia******@hotma il.com> wrote:

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'd still look at the prototype out of simple curiosity!

Of course. But with references, you _have_ to, even when you're pressed
for time and could have done with putting off the curiosity until after

Every language feature has a cost and a benefit. C doesn't have

--
Ian Collins.
May 10 '06 #309
On Tue, 09 May 2006 18:19:20 +0300,
Juuso Hukkanen <ju***********@ tele3d.net> wrote
in Msg. <ig************ *************** *****@4ax.com>
Ok, if the 'C project' aim is to maintain the C, then the C language
would need to be declared as being perfect, since only perfect beings
don't need to evolve.
The C language certainly is not perfect in the sense that it doesn't
leave anything to be desired, but it is perfect in the sense that it is
anything but a "work in progress".
No, C is not yet 'perfect', In fact many C.L.C regulars are expression
dissatisfaction with numerous C issues. Just check...
Of course there is plenty of dissatisfaction , but rarely is this
sentiment coupled with the desire to have the language changed on behalf
of them.
So, clearly there needs to be some modernization into the C.
I find that not so clear.

The
classical C has and will have its important role, but would it hurt to
add some modern features into it. For example with a #PRAGMA attitude;

if (the environment allows a certain feature)
use_environment ;
else
(return some standard error code);
This is what is called an extension, and most (if not all) compilers
have extensions of one sort or another.
That would not take away anything from the original C and I think that
is just what Jacob, Rod et al. might want to achieve with requesting a
more tolerant attitude towards the 'C with extensions'.

Nobody has anything against "C with extensions"; in fact you'd probably
be hard-pressed to find anybody on this group who hasn't used
implementation-specific extensions at one time or another, or even
constantly. The "intoleranc e" you are talking about is not against C
extensions, but against discussing C extensions in this newsgroup, in
which they simply don't belong.

robert
May 10 '06 #310

This thread has been closed and replies have been disabled. Please start a new discussion.