How would you design C's replacement?

T

Tim Rentsch

Keith Thompson said:
James Kuyper said:
On 05/14/2012 05:37 PM, Robert Wessel wrote:
...

You've got the syntax wrong. _Pragma("string literal") is equivalent to

#pragma string literal

C99 was the first version of the standard to introduce standard-defined
pragmas, and it also established naming conventions which should be
adhered to by any additional pragmas that are proposed. Every standard
pragma has a name which is all capitals, and contains at least two
words, the first of which is "STDC". Those which turn a feature either
on or off do so by simply appending "ON" or "OFF" to the pragma's name.

Therefore, that should be _Pragma("STDC TRIGRAPHS ON")

The standard says:

A unary operator expression of the form:
_Pragma ( string-literal )
is processed as follows:
[snip]

Which implies (I think) that _Pragma(...) may appear only in a context
where an expression is permitted.

In particular, it implies that you can't have a _Pragma as the first line of
a source file.

But the example, showing a way of rewriting a #pragma directive as an
equivalent _Pragma(), doesn't support that interpretation, nor does the
C99 Rationale. The phrase "unary operator expression" is also a bit
odd; the grammatical construct is a "unary-expression".

I agree the phrasing is a little odd. Despite that, I think
the meaning is clear enough, especially when read in conjunction
with other parts of the Standard describing the preprocessor
and what happens with _Pragma, and when.
I'll post to comp.std.c and see if I can get some clarification.

I'd support a recommendation to add a clarifying footnote or two
to help fix this; IMO nothing more than that is warranted.
 
T

Tim Rentsch

Walter Banks said:
Tim said:
Or perhaps more simply, _Pragma

It seems like it would be easier to leave them alone. [snip]

Note that I wasn't advocating doing anything about trigraphs,
just mentioning an alternative to #pragma or %:pragma.

However, if people do want to do something about trigraphs,
there's an easy idea that doesn't break conformance and doesn't
need to wait on revising the Standard.

In almost all cases when a source files is using (ie, choosing
to use) trigraphs, the very first trigraph will be on a
preprocessor line, eg, ??=include or ??=ifndef. Furthermore
the existence of such a line early in a source file makes
it highly likely that the author is intentionally using
trigraphs in that source file, not using them just by chance
or accident.

So, upon encounterting a trigraph, the implementation could give
a warning diagnostic if the first trigraph in that source file
were not a ??= on a valid preprocessor line. The warning could
explain that an unexpected trigraph was encountered, and report
some compiler options to (a) disable the warning altogether, or
(b) disallow trigraph processing at all. (Obviously there could
also be file-level pragmas for those who want more fine-grained
control.) The warning would not prevent compilation or change
the semantics of trigraphs, just flag the unexpected uses.

If this were done, and done by default, most cases would work as
desired/expected, without having to know about trigraphs or learn
in advance about exotic compiler options. Developers new to C
who didn't know about trigraphs would still be very unlikely to
stumble onto them wrongly, but would not be confused if or when
compiling other sources that use trigraphs deliberately. Best of
all, this approach is one implementors can act on now, without
having to wait for any action or change as far as ISO C goes.
 
J

Joe keane

Or perhaps they *could* BUY THE CORRECT HARDWARE ?????????

It's obvious that redefining ASCII codes was a stopgap.

It's obvious that ISO 8859-1 was a stopgap.

It's obvious that anything which fixes things for Europeans but does
nothing for the Koreans is not that hot.

Or perhaps they *could* BUY THE CORRECT SOFTWARE ?????????
 
M

Marco

So, you end up with something like D if you set out to replace C++. That's
extensively covered in D's overview section.

The only thing we can take from D's relative popularity shortcomings is
that, as a replacement for C++, it failed to provide any meaningful benefits
over C++.

I disagree and feel that folks that would have adopted D probably committed to Java/JVM or C#/CLR already (in lieu of C++). D language stabilization may have been too late.

Vala is another interesting language in the applications area.
But that says nothing about C, doesn't it?

agreed - leave C alone
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top