Boost process and C

[Rod Pemberton]

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

 

[Keith Thompson]

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.

 

[REH]

The operator overloading change do not affect efficiency at all.

I never said it did. I said that C++ and Ada, like C, are languages
designed with efficiency in mind, but also support operator loading.
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;

or similar. This is nowhere required by operator overloading.

Dreaded by whom? I think constructor and destructors are great. Ada
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

 

[Rod Pemberton]

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.

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

 

[Richard Heathfield]

Rod Pemberton said:

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

It could deprecate such obfuscative things as +=,

*Raises eyebrows*

Richard

 

[Richard Bos]

I see your point.

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

Richard

 

[Juuso Hukkanen]

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

http://groups.google.com/group/comp.lang.c/search?q="unfortunately+C"&start=0&scoring=d&

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
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com/wiki <-- one of the C's possibe futures

 

[Ian Collins]

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

Every language feature has a cost and a benefit. C doesn't have
polymorphism or operator overloading, so there would be little to be
gained by adding references.

 

[Robert Latest]

On Tue, 09 May 2006 18:19:20 +0300,

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

 

[Robert Latest]

On Tue, 09 May 2006 18:19:20 +0300,

www.tele3d.com/wiki <-- one of the C's possibe futures

Oh? let's look at the webpage:

(complete) t3d function prototype is:
langsign_mainverb_aaaaaa_bbbbbb_cccccc_dddddd_Reeeeee_ADJECTIVE_PART1_n_ADJECTIVE_PART2_ARG1XXX_ARG2XXX_ARG3XXX

I can't wait until this is finally incorporated into C2007.

robert

 

[Juuso Hukkanen]

I can't wait until this is finally incorporated into C2007.

Don't laugh, t3d function prototype is really handy to use in calling
complex functions ( Once a programmer learns the two page rules, he
automatically learns to use complex functions which he actually didn't
need to know to exist) like

t3d_measure_barray_LENGTH
t3d_convert_file_Rfile_GSM2WAV
t3d_convert_Rfile_READ_ONLY
t3d_calculate_iarray_Rdouble_STD_DEVIATION
t3d_add_byte_Rbarray_RANDOM_n_END
t3d_environment_barray_SET_KEYBOARD_n_LANGUAGE

If you doubt its usefullness challenge me to show how it can be
(easily) used in defining any programmable task.

The idea is to do the functions as much as possibel with C99 but when
it is not possible then by using platform specific "C with extensions"
code.

Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
"t3d programming language" and the structure of t3d function prototype
are trademarks of Juuso Hukkanen. (Curently in discussing the transfer
of to a major charity organization).

 

[Rod Pemberton]

Rod Pemberton said:


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.

The damage is minimal. CLC and Usenet are the extreme "backwoods" of the
internet. It is only eclipsed by P2P networks.

Your reputation is based on one insignificant chapter in a book. That's it.
His reputation is based on a compiler that has been seen, used, and heard of
by hundreds of thousands if not millions. I'd easily bet that there are as
many people that know of his LCC-Win32 compiler as there are people who've
visited Randall Hyde's HLA website (7 million). And, it's not like HLA is
way up there on the popularity list...

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.

I didn't see anything damaging, but I skipped a few articles. If you or few
others choose to perceive him as damaging his reputation, it's irrelevant.
The millions of people who've heard of his compiler don't read CLC or use
usenet.


Rod Pemberton

 

[Richard Heathfield]

Rod Pemberton said:

The damage is minimal. CLC and Usenet are the extreme "backwoods" of the
internet.

Yeah, right - the backwoods where compiler writers, standard library
writers, and ISO committee members hang out. Some backwoods.

Your reputation is based on one insignificant chapter in a book.

For a start, it was rather more than one chapter - well over 300 pages, in
fact. But I didn't expect accuracy from you. And the other mistake you made
is that the book is not the source of whatever reputation I might have
acquired in the C community. Rather, it was an outcome of acquiring that
reputation. (I didn't approach the publisher. The publisher approached
/me/.)

That's
it. His reputation is based on a compiler that has been seen, used, and
heard of
by hundreds of thousands if not millions.

Sure. And that's good. But now he's damaging that reputation. When I first
saw a Jacob Navia article in clc, I thought "wow, what a cool place this
is, even people like Jacob Navia post here". But now I think "oh, what
idiocy is he going to come out with next?" So in my eyes at least, he has
significantly damaged his reputation here. And I'm not the only one who
thinks so, I suspect.

I didn't see anything damaging, but I skipped a few articles. If you or
few others choose to perceive him as damaging his reputation, it's
irrelevant. The millions of people who've heard of his compiler don't read
CLC or use usenet.

Word gets around.

 

[Dave Thompson]

jacob navia <[email protected]> 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:

With or without references, you know that
function1(*object);

Of course you mean function1(&object) for the call
or T function(S*object) for the declaration/definition.

Aside: I wanted to phrase that as "Shirley, you mean ..."
because the DVD of Airplane just went on discount, but considering the
participants in this thread not to mention the group I shouldn't.

might well change object, because it takes a pointer.
Without references, you can rest assured that
function2(object);
will never change object, because it does not take a pointer.

Not through that parameter, but it may if object is accessible through
some other path. You can be sure it's not only if it's local and its
address is not taken, or at least not passed out, within this function
or block; or 'static' (file-scope internal) and similarly not passed
out of this t.u. and the called function is in another t.u. or the
called function is in the same t.u. and doesn't access the object or
use any pointer that could be pointing to it.

_With_ references, though, you always have to assume that
function3(object);
could change object, because you just cannot tell from that call whether
it takes a normal parameter or a reference.

Assuming the C++ form, since I don't know if lcc-win32 has this
feature: unless object is const, in which case you know that the
called function must have accepted it as a const reference and can't
try to change it without casting away const, and even then is U.B.

Three restrictions. And bright red uniforms. But those are not

Now, _I_ don't understand that one, about the uniforms.

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.

Actually, 'reference' has been used by many other languages and people
long before C++, and by more since, with a range of related but subtly
different meanings. C++ is one thoroughly-worked-out and widespread
thus important example but not the universal for-all-time definition.


- David.Thompson1 at worldnet.att.net

 

[Robert Latest]

On Wed, 10 May 2006 16:42:01 +0000,

For a start, it was rather more than one chapter - well over 300 pages

300 quite chatty pages, we might add. You should have traded the
teddybear with sunglasses for some more real-world software engineering
anecdotes.

robert

 

[Richard Heathfield]

Robert Latest said:

On Wed, 10 May 2006 16:42:01 +0000,


300 quite chatty pages, we might add. You should have traded the
teddybear with sunglasses for some more real-world software engineering
anecdotes.

<shrug> As far as I'm concerned, it's a hot tip. It actually does work. I
still use that technique today. (The sunglasses are optional.) We all have
war stories - and indeed I put a few of those in, although as few as I
could manage - but what people actually want to know is the general tips
that have widespread applicability. Heck, the teddy-bear thing even works
when I'm wandering randomly around the kitchen!

"Clint, where on earth is the kett... oh, I'm holding it, aren't I?"


As for the chattiness, well, I can't help that. I'm a naturally chatty
person.

Thing is, in my chatty way I have helped a great many people (not just here
but in IRC as well) to understand C concepts which non-chatty folks failed
to help them to understand.

If I'm telling you something you already know, it makes sense to say it in
as abbrev'd a way as possible.

But when I'm telling you something you /don't/ already know, it makes sense
to say it in a way that you will actually be able to understand, quickly
and easily. The best way to do this, in my experience, is to avoid the
temptation to express everything in no more than ten words, each of no
fewer than ten syllables.

And since nothing is universally known, it makes sense to address those who
don't know, in /every/ case. After all, why bother to learn something you
already know?


But on the other hand, if you really really want terse, I can do terse too.

"C Unleashed - 2ed." by RH.

Ch 1

Do everything properly.

The end.

Index

Everything: 1
Properly, doing everything: 1

 

[Robert Latest]

On 5 May 2006 14:42:12 GMT,

Yes, of course. My objection is not to date (or pointer) addition
being disallowed, it's to the claim that it's *meaningless*.

But it is. The expression (p1 + p2) in itself is meaningless, even if it
makes sort of sense in (p1 + p2) / 2.

the fact that one can come up with a workaround [ p1 + (p2 - p1) / 2 ]
proves that the original [ (p1 + p2) / 2 ] wasn't meaningless.

Proof by example. All this means that "the sum of two pointer variables
is meaningless unless the sum is divided by two".

If you wanted to prove that the sum of two dates (or two pointers) has a
meaning, you'd better start telling us ehat that meaning could possibly
be. Not what it could mean if and only if used in a particular, singular
arithmetic context

robert

 

[Robert Latest]

On Sun, 7 May 2006 23:08:10 +0200,

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

That alone isn't enough to make it meaningless. After all, the
difference of two dates makes perfect sense although it is not a date.

robert

 

[Robert Latest]

On 5 May 2006 18:13:17 -0700,

Can you write 102 well tested functions

I said "the necessary functions".

that are aliasing safe, support
write protection, have a performance advantage over comparable straight
C across the board

How can they have a performance advantage over "straight C" functions if
they add functionality to them and, more paradoxically, are written in
straight C themselves?

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.

True. More to the point, every C programmer builds more or less his own
C library over the years.

robert