Is C99 the final C?

[James Kuyper]

is easier for me to grasp. And I think (but this is just IMH
and uneducated O) that C++ compilers need a lot of extra baggage
to deal with constant "consts," and I wouldn't want to foist all
that on C compilers.

I'm curious - why do you think that? I don't know that you're wrong,
but I can't think of any reason why it would be a significant cost.

 

[James Kuyper]

So, you're going to second this proposal?

No - I think that &&& and ||| would be so rarely used that their
meanings would become trivia questions.

 

[Dan Pop]

That might be the case, if you're talking about implementing C,
but I beleive that Arthur J. O'Dwyer,
was talking about the the C programmer's choice
for when it comes to choosing a type, while writing C code.

The C programmer's choice is not that clear. See below.

I use long to implement psuedorandom number generators
which generate 32 bit values, portably.
I can't do that with int.

It depends on your definition of portability. For current hosted
implementations, int will give you 32 bits, while long may give you more
than that. If you think that being portable to MSDOS is a great idea,
than you have to use long and accept the fact that you're wasting memory
on other platforms. No big deal for scalars, but it may become a
performance issue when dealing with arrays.

Dan

 

[Mark McIntyre]

A type which is guaranteed to have at least 32 bits, is a better choice
than one which isn't guaranteed to have at least 32 bits,
for when you need an exactly 32-bit integer type.

*shrug*. I understand your point, but when in implementation-dependent
territory, its quite immaterial what ISO requires, its never going to
safely port anyway so abandon all hope, ye who enter here....

 

[CBFalconer]

Mark Gordon wrote:
.... snip ...

That would have been me. I was aiming for about the same status
for 'enum' types as enumeration types have in Pascal. However,
in C you can of course assign definite integer values to members
of an enum, including duplicates - this complicates matters
considerably.

I guess the only thing that could be done without breaking too
much code is mandating a compiler diagnostic on implicit
conversion of an enum value to an int value. Personally, I think
that would be a good idea.

IMO you cannot correct the existing enum without breaking valid
code. To gain the abilities of the Pascal enumeration requires an
entirely new type. This could be conveniently combined with the
addition of sub-range types, none of which would break old code,
but would provide much additional safety.

 

[CBFalconer]

.... snip ...

But those are used in freestanding implementations only, and we
ignore such implementations by default, here.

"We" don't, but maybe you do. Such implementations are among the
most important users of C today.

 

[E. Robert Tisdale]

[Are there any] features that the C specification currently lacks
and which may be included in some future standardization.

The future of C is C++. The question now is,
"Will any future C++ standard adopt the features introduced in C99?"

restricted pointers,
variable-length arrays,
etc.

 

[andrew29]

There was a quote some years ago, I believe by one of the authors of the
original Fortran compiler, though it is hard to verify the source.

Nah, not really hard at all. It was Tony Hoare (now living here in
Cambridge!):

"I don't know what the language of the year 2000 will look like, but
it will be called Fortran."
- C. A. R. Hoare, 1982

Something like:

"I don't know what the language of the year 2000 will look like, but it
will be called Fortran." (That is from memory, hopefully it is close.)

Perfect!

Andrew.

 

[Sidney Cadot]

Besides the syntactic shift (from being parsed as "&& &b" today),
I think it is worth pointing out that if "a" is false, it must compare
equal to 0; so assuming "a &&& b" means "if a then b else a", it
also means "if a then b else 0", which can be expressed today as
"a ? b : 0".

(GCC offers "a ||| b" as "a ?: b", which means "a ? a : b" without
evaluating "a" twice.)

Especially this latter form is quite useful, expressing the idea that
'a' is to be used if it has a non-zero value, else use 'b' as a
fallback. This could be threaded, as in 'a ?: b ?: c'... I'd seriously
hope the next committee would consider this. This actually /is/ useful.

The expression "x = ~x" can always be transformed into "x ^= ~0U",
although the constant may need to be written as 0UL, 0ULL,
(uintmax_t)0, or some such. (Using ^= ~(uintmax_t)0 probably
always works, but probably draws warnings on some compilers.)

Ok, then I'd rather stick to 'x=~x', which is clearer. It has always
sort-of annoyed me that the binary operators '+' '-' .... and so on have
assignment forms, while the unary '~' hasn't.

It is also worth noting that Dennis Ritchie's early C compiler(s)
*had* min and max operators, spelled \/ and /\ respectively. They
were dropped, most likely from lack of use.

Funny, I didn't know that - weird syntax.

Personally, I would like to see min/max operators make a comeback. They
are quite often needed in practice, supported by some hardware, and
have clear algebraic foundations (max-plus algebras, and all that).

Someone else asked (further down in the thread) whether some CPUs
might have "min" and "max" instructions. I have never seen precisely
this myself, but many architectures have "synthetic" (and branchless)
min/max sequences -- usually involving the carry bit (many CPUs)
or "set if less than" instructions (MIPS) or the like -- and even
the x86 now has conditional-move. GCC will generate these for the
branch-ful "a < b ? a : b" sequence, e.g.:

int imin(int a, int b) { return a < b ? a : b; }

compiles to, e.g.:

cmpl %eax, %ecx
cmovle %ecx, %eax

when gcc is given the right options (-msse). (V9 sparc also has
conditional move, and ARM has conditional *everything*. )

Interesting. The only processor I've seen that has this is the Philips
Trimedia, an embedded processor optimized for multimedia streaming. It's
a VLIW processors with five parallel instruction units. Branch
prediction failure rollback is quite expensive on these beasts.

Best regards,

Sidney

 

[Sidney Cadot]

* triple-&& and triple-|| operators: &&& and ||| with
semantics like the 'and' and 'or' operators in python:

a &&& b ---> if (a) then b else a
a ||| b ---> if (a) then a else b
[snip]

result = a? b: 0; /* &&& */

ITYM a ? b : a

surely its the same thing ?

Eg.

a() ? b() : a()

is not equivalent to

a() ? b() : 0

if a() has side-effects.

Regards,

Sidney

 

[Sidney Cadot]

It doesn't make any difference where you advance it: it will get ignored,
anyway.

If you want to promote an idea, either become a committee member

Right-o. How does one become a committee member?

or convince one committee member that it's worth promoting it.

.... My idea was to convice one reader to convince one committee member
that it's worth promoting it.

At least about the stack-fault thing. That really ought to be fixed next
time 'round.

Best regards,

Sidney

 

[Sidney Cadot]

A type which is guaranteed to have at least 32 bits, is a better choice
than one which isn't guaranteed to have at least 32 bits,
for when you need an exactly 32-bit integer type.

Not if the int has 32-bits, and the long has 64 bits.

An other answer is: why? We're not in a casino, tring to improve the
odds. If you need exactly 32-bit integers, nothing besides a 32-bit
integer type will do.

Regards, Sidney

 

[Sidney Cadot]

Hmm, something like
#pack n
and
#pack default
to reset to whatever the compiler normally does?

Many compiler support something similar to this, via a #pragma pack(n).
I'd prefer something that's a bit more natural-looking though... This
that start with a '#' look like preprocessor-food to me.

Best regards,

Sidney

 

[Sidney Cadot]

If that's the case, then it hardly seems likely that the C0X extensions
which may or may not help you out will be any more useful than any of
the stuff in C99?

Don't get me wrong, this is an interesting thread, but regardless of
the outcome, one has to wonder how many current C programmers will
live long enough to see C99 be available "practically everywhere",
much less whatever comes after it.

We have to think about our grandchildren ... It's bad enough we're
leaving them a world without whales and a polar ice cap, let's not
worsen things by denying them a "|||" operator.

Best regards,

Sidney

 

[Mark Gordon]

IMO you cannot correct the existing enum without breaking valid
code. To gain the abilities of the Pascal enumeration requires an
entirely new type. This could be conveniently combined with the
addition of sub-range types, none of which would break old code,
but would provide much additional safety.

If we are stealing bits from Pascal then I would like a set type with a
full set of set operators including cardinality (number of elements in
set if I remember my sets properly).

 

[Sidney Cadot]

No - I think that &&& and ||| would be so rarely used that their
meanings would become trivia questions.

I sort of hoped that role would be reserved for my soon-to-be-proposed
quadruple |||| and &&&& operators.

Ah well.

Best regards,

Sidney

 

[Sidney Cadot]

[Are there any] features that the C specification currently lacks
and which may be included in some future standardization.

The future of C is C++. The question now is,
"Will any future C++ standard adopt the features introduced in C99?"

restricted pointers,
variable-length arrays,
etc.

I would think so. More problems are expected with the C++ committee
deprecating classes, templates, and exceptions. However, the old lesson
that it's never too late to mend your ways should prevail.

The future of C++ is C.

Best regards,

Sidney

 

[Sidney Cadot]

If we are stealing bits from Pascal then I would like a set type with a
full set of set operators including cardinality (number of elements in
set if I remember my sets properly).

A hybrid monster is heaving into view....

Integer main(input, output)
{
PrintLn('Hello World')
}

Best regards,
Sidney

 

[glen herrmannsfeldt]

Dan Pop wrote:

(snip)

C++ didn't invent // comments, it merely inherited them from C's ancestor,
B. One could argue that they belonged to C since day one ;-)

Does anyone know where /* comments came from?

There is a discussion in another group related to them, as /* is
the end of input signal for some IBM OS's. (starting in column 1).

So /* comments in those OS can't start in column 1 unless the
end of input sequence is changed.

-- glen

 

[Arthur J. O'Dwyer]

"We" don't, but maybe you do. Such implementations are among the
most important users of C today.

Nit: "We" do (for values of "we" equivalent to "the general topicality
of comp.lang.c"), but the *C standard* and committees pertaining thereto
don't -- and that's the audience to which Sidney implicitly directed
his post.
Such [free-standing] implementations are indeed among, etc., etc.


-Arthur