Discussion:
Preliminary C2x Charter
(too old to reply)
Keith Thompson
2016-03-17 15:53:01 UTC
Permalink
Raw Message
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm

There are (probably appropriately) no specifics on what changes
will be made in the new standard.

The preliminary charter mentions updating the Rationale for C11,
or at least creating a new Rationale document for C2x.

It includes a revision schedule (the dates are preliminary):

- CD Registration (bugfix) — December 2016
- CD Ballot (bugfix) — June 2017
- DIS Ballot (bugfix) — December 2017
- CD Registration (C2x) — December 2019
- CD Ballot (C2x) — December 2020
- DIS Ballot (C2x) — December 2021

This schedule allows for the formal adoption of a revised standard
by the end of 2021, with a publication date of 2022.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Rick C. Hodgin
2016-03-17 16:12:05 UTC
Permalink
Raw Message
Post by Keith Thompson
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm
There are (probably appropriately) no specifics on what changes
will be made in the new standard.
The preliminary charter mentions updating the Rationale for C11,
or at least creating a new Rationale document for C2x.
- CD Registration (bugfix) -- December 2016
- CD Ballot (bugfix) -- June 2017
- DIS Ballot (bugfix) -- December 2017
- CD Registration (C2x) -- December 2019
- CD Ballot (C2x) -- December 2020
- DIS Ballot (C2x) -- December 2021
This schedule allows for the formal adoption of a revised standard
by the end of 2021, with a publication date of 2022.
I would like to see the next standard remove the requirement of having
forward declarations.

Best regards,
Rick C. Hodgin
Jakob Bohm
2016-03-17 17:29:29 UTC
Permalink
Raw Message
Post by Rick C. Hodgin
Post by Keith Thompson
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm
There are (probably appropriately) no specifics on what changes
will be made in the new standard.
The preliminary charter mentions updating the Rationale for C11,
or at least creating a new Rationale document for C2x.
- CD Registration (bugfix) -- December 2016
- CD Ballot (bugfix) -- June 2017
- DIS Ballot (bugfix) -- December 2017
- CD Registration (C2x) -- December 2019
- CD Ballot (C2x) -- December 2020
- DIS Ballot (C2x) -- December 2021
This schedule allows for the formal adoption of a revised standard
by the end of 2021, with a publication date of 2022.
I would like to see the next standard remove the requirement of having
forward declarations.
Best regards,
Rick C. Hodgin
Disagree

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Rick C. Hodgin
2016-03-17 17:32:49 UTC
Permalink
Raw Message
Post by Jakob Bohm
Post by Rick C. Hodgin
Post by Keith Thompson
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm
There are (probably appropriately) no specifics on what changes
will be made in the new standard.
The preliminary charter mentions updating the Rationale for C11,
or at least creating a new Rationale document for C2x.
- CD Registration (bugfix) -- December 2016
- CD Ballot (bugfix) -- June 2017
- DIS Ballot (bugfix) -- December 2017
- CD Registration (C2x) -- December 2019
- CD Ballot (C2x) -- December 2020
- DIS Ballot (C2x) -- December 2021
This schedule allows for the formal adoption of a revised standard
by the end of 2021, with a publication date of 2022.
I would like to see the next standard remove the requirement of having
forward declarations.
Disagree
How could you possibly disagree with removing the REQUIREMENT of having
forward declarations? You could still have them and use them every day.
The option to remove the requirement would have to be enabled for this
relaxation to exist.

How could anyone, in 2016, possibly take an exception to having that
allowance in the language?

Best regards,
Rick C. Hodgin
Kaz Kylheku
2016-03-17 17:31:46 UTC
Permalink
Raw Message
Post by Rick C. Hodgin
Post by Keith Thompson
This schedule allows for the formal adoption of a revised standard
by the end of 2021, with a publication date of 2022.
I would like to see the next standard remove the requirement of having
forward declarations.
Sure; you just need to propose a detailed set of requirements of how
that is supposed to works that is reasonably complete, sound and
backward-compatible.
Rick C. Hodgin
2016-03-17 17:34:19 UTC
Permalink
Raw Message
Post by Kaz Kylheku
Post by Rick C. Hodgin
Post by Keith Thompson
This schedule allows for the formal adoption of a revised standard
by the end of 2021, with a publication date of 2022.
I would like to see the next standard remove the requirement of having
forward declarations.
Sure; you just need to propose a detailed set of requirements of how
that is supposed to works that is reasonably complete, sound and
backward-compatible.
What is involved in doing that? My proposal is the idea. There are
technical people involved with the C standard who know how it could
be implemented. I propose this:

Footnotes:

[a] The requirement of having forward declarations can be
overridden with a compiler switch which removes the
requirement allowing N-pass compilation until all
symbols are resolved.

Best regards,
Rick C. Hodgin
Kaz Kylheku
2016-03-17 18:30:58 UTC
Permalink
Raw Message
Post by Rick C. Hodgin
Post by Kaz Kylheku
Post by Rick C. Hodgin
Post by Keith Thompson
This schedule allows for the formal adoption of a revised standard
by the end of 2021, with a publication date of 2022.
I would like to see the next standard remove the requirement of having
forward declarations.
Sure; you just need to propose a detailed set of requirements of how
that is supposed to works that is reasonably complete, sound and
backward-compatible.
What is involved in doing that?
Something more than just "please remove the requirement for forward
declarations".

You could make a patch for GCC and actually start using it.

Standardization could come later.

It will be easier if it's demonstrated "in the wild".
Post by Rick C. Hodgin
My proposal is the idea. There are
technical people involved with the C standard who know how it could
be implemented.
[a] The requirement of having forward declarations can be
overridden with a compiler switch which removes the
requirement allowing N-pass compilation until all
symbols are resolved.
That's not enough. You need precise rules.

This isn't the removal of a requirement, but the insertion of a new
one.

You want there to be a particular behavior when a C translation unit
contains a call to a function which was not previously declared,
but which is declared or defined later.

Before that later definition is seen, what happens to the type of
the function call expression, and all checks which depend on it?

For instance, a special type called TBD (to be determined) can be
introduced, which marks the function call expression, and
everything else which depends on its type.

A TBD is keyed to the missing identifier.

Whenever a function is defined or declared, if that identifier
was previously involved as the basis of introducing a TBD,
that TBD is backfilled with a substitution of actual type; translation
of the previous function is resumed at the TBD node, and constraint
violations related to type are reported, if they arise.

By the end of a translation unit, all TBD nodes in the syntax
must be filled in, or else a diagnostic is required.

The more or less exact model of translation has to be
specified.

(Who says it has to be N-pass? A two-pass compromise that
handles only functions would be very useful.)
Rick C. Hodgin
2016-03-17 18:45:29 UTC
Permalink
Raw Message
Post by Kaz Kylheku
Post by Rick C. Hodgin
Post by Kaz Kylheku
Post by Rick C. Hodgin
Post by Keith Thompson
This schedule allows for the formal adoption of a revised standard
by the end of 2021, with a publication date of 2022.
I would like to see the next standard remove the requirement of having
forward declarations.
Sure; you just need to propose a detailed set of requirements of how
that is supposed to works that is reasonably complete, sound and
backward-compatible.
What is involved in doing that?
Something more than just "please remove the requirement for forward
declarations".
You could make a patch for GCC and actually start using it.
Standardization could come later.
It will be easier if it's demonstrated "in the wild".
Post by Rick C. Hodgin
My proposal is the idea. There are
technical people involved with the C standard who know how it could
be implemented.
[a] The requirement of having forward declarations can be
overridden with a compiler switch which removes the
requirement allowing N-pass compilation until all
symbols are resolved.
That's not enough. You need precise rules.
This isn't the removal of a requirement, but the insertion of a new
one.
You want there to be a particular behavior when a C translation unit
contains a call to a function which was not previously declared,
but which is declared or defined later.
Before that later definition is seen, what happens to the type of
the function call expression, and all checks which depend on it?
For instance, a special type called TBD (to be determined) can be
introduced, which marks the function call expression, and
everything else which depends on its type.
A TBD is keyed to the missing identifier.
Whenever a function is defined or declared, if that identifier
was previously involved as the basis of introducing a TBD,
that TBD is backfilled with a substitution of actual type; translation
of the previous function is resumed at the TBD node, and constraint
violations related to type are reported, if they arise.
By the end of a translation unit, all TBD nodes in the syntax
must be filled in, or else a diagnostic is required.
The more or less exact model of translation has to be
specified.
(Who says it has to be N-pass? A two-pass compromise that
handles only functions would be very useful.)
N-pass would allow tokens that aren't yet defined to be defined so
they can be parsed in macros, etc.

I appreciate the information. I don't understand why it would take all
of that except that the requirements of the C standard group require it.
Sounds far like a far more difficult process than it needs to be.

I'll just remove the requirement in CAlive and leave C [CDying] alone.

Best regards,
Rick C. Hodgin
Rick C. Hodgin
2016-03-17 20:03:07 UTC
Permalink
Raw Message
Post by Rick C. Hodgin
I'll just remove the requirement in CAlive and leave C [CDying] alone.
After Keith's post, correction:

... and leave the C Standard [C-Standard-Dying] alone.

C will never die. But I pray the C Standard does, if only to be replaced
with something more fluid.

I will strive greatly for this with CAlive. And I will strive greatly for
maintaining the core language definition, which will be conveyed by code
examples, along with a core virtual machine which runs each version that
is released correctly, allowing for an interpreted CAlive language to be
used for those applications which need to be portable, but don't need to
be super fast.

Best regards,
Rick C. Hodgin
BartC
2016-03-17 22:10:20 UTC
Permalink
Raw Message
Post by Kaz Kylheku
Post by Rick C. Hodgin
[a] The requirement of having forward declarations can be
overridden with a compiler switch which removes the
requirement allowing N-pass compilation until all
symbols are resolved.
That's not enough. You need precise rules.
This isn't the removal of a requirement, but the insertion of a new
one.
You want there to be a particular behavior when a C translation unit
contains a call to a function which was not previously declared,
but which is declared or defined later.
Before that later definition is seen, what happens to the type of
the function call expression, and all checks which depend on it?
For instance, a special type called TBD (to be determined) can be
introduced, which marks the function call expression, and
everything else which depends on its type.
A TBD is keyed to the missing identifier.
Whenever a function is defined or declared, if that identifier
was previously involved as the basis of introducing a TBD,
that TBD is backfilled with a substitution of actual type; translation
of the previous function is resumed at the TBD node, and constraint
violations related to type are reported, if they arise.
By the end of a translation unit, all TBD nodes in the syntax
must be filled in, or else a diagnostic is required.
The more or less exact model of translation has to be
specified.
(Who says it has to be N-pass? A two-pass compromise that
handles only functions would be very useful.)
I can see this proposal being a problem only on single-pass compilers
(forgetting preprocessing stages).

That is, compilers which have to start generating code as soon as a
function call is encountered.

Otherwise it's a non-issue. If the first proper pass produces an AST,
then I can't see that it needs to know anything about an unresolved
function at any point. Once the first pass is complete, then this will
be known.

(This doesn't mean it would be easy to modify a monstrous compiler such
as gcc, if you aren't already a developer.)
--
Bartc
Francis Glassborow
2016-03-17 18:54:04 UTC
Permalink
Raw Message
Post by Rick C. Hodgin
Post by Kaz Kylheku
Post by Rick C. Hodgin
Post by Keith Thompson
This schedule allows for the formal adoption of a revised standard
by the end of 2021, with a publication date of 2022.
I would like to see the next standard remove the requirement of having
forward declarations.
Sure; you just need to propose a detailed set of requirements of how
that is supposed to works that is reasonably complete, sound and
backward-compatible.
What is involved in doing that? My proposal is the idea. There are
technical people involved with the C standard who know how it could
[a] The requirement of having forward declarations can be
overridden with a compiler switch which removes the
requirement allowing N-pass compilation until all
symbols are resolved.
Best regards,
Rick C. Hodgin
It does not work like that. The technical people on WG14 have plenty to
do pursuing their interests. Remember that not are people not paid to be
on WG14 their presence either costs them or their employers money both
in attendance costs and in time spent on standards work that cannot be
spent on something else.

If you want a change you must either do the work yourself or find
someone to do it for you (by persuading them that it is important enough
to justify the cost)

Note that the Standard does not subset by mandating compiler switches.
There is nothing to prevent an implementer from providing such a
facility as a language extension and if everyone did so it would
probably be incorporated into the Standard.

Just remember that if you want something you have to work for it which
includes understanding all the implications of the proposed change
(which are often surprising)

Francis
s***@casperkitty.com
2016-03-17 20:21:32 UTC
Permalink
Raw Message
Post by Francis Glassborow
Note that the Standard does not subset by mandating compiler switches.
There is nothing to prevent an implementer from providing such a
facility as a language extension and if everyone did so it would
probably be incorporated into the Standard.
I would suggest that such an attitude is unfortunate, since different
programs have different semantic requirements, and there is no way that
one single set of language semantics can avoid either compelling
programmers to rely upon non-standard (but commonplace) extensions to
achieve required semantics, or forbidding what would otherwise be useful
and substantial optimizations.

A lot of the confusion and discord surrounding aliasing, for example, could
be eliminated if the language recognized two or more aliasing modes, at least
one of which offered programmers better semantics than the existing rule,
and at least one of which offered compilers more optimization opportunities
[in practice, I'd suggest three main modes; the first two would be C89
and C99 compatible, meaning that any program whose behavior is defined
under C99 would also be defined under either of the first two modes].

1. Free aliasing mode: compiler must behave as though all operations upon
any object whose address is taken is performed directly upon the
underlying storage.

2. Named-object caching mode: The compiler is allowed to cache named
objects of static or automatic duration in registers, even if their
address is taken, but must behave as thought they synchronize all
named objects of a given type with their cached values whenever an
access is made to a pointer of matching type or a character pointer,
whenever memcpy is performed, or whenever a pointer of matching type
is cast to another pointer type [in the latter case, the value must
remain synchronized until the next sequence point in the context
where the cast occurs]. I would suggest that this mode is essentially
what compilers used to implement in the 1990s.

3. Explicit aliasing mode: Operations upon storage using different types--
including character types--are unsequenced in the absence of intrinsic
macros to create sequencing barriers. This would effectively mean that
storage which has ever been used as any type may not be used as any
other unless code uses new intrinsic macros to indicate such reuse (in
mode 1, such macros would be no-ops; in mode 2, they could simply
perform a dummy cast of the appropriate pointer type.

If the source pointer to memcpy is a type other than void*, it will
be regarded as reading data of that type; if the destination is other
than void*, it will be regarded as writing that type. If the source
to memcpy/memmove is void*, reads must capture the result of the most
recent legitimate writes (in abstract-machine order). If the
destination is void, the memcpy must affect the result of the next
read as any type (in abstract-machine order).

Note that explicit aliasing mode would allow many optimizations not possible
in C99. For example,

void test(int *p1, float *p2)
{
for (int i=0; i<1000; i++)
{
p1[i] = i; p2[i] = i*1.5f;
}
}

The C99 rules require that generated code perform all operations in the
exact order specified in cases where the areas of storage accessed via the
two pointers overlap. Under explicit aliasing mode, a compiler would be
allowed to rewrite the code as:

void test(int *p1, float *p2)
{
for (int i=0; i<1000; i++)
p1[i] = i;
for (int i=0; i<1000; i++)
p2[i] = i*1.5f;
}

and could perform the two loops in parallel on separate execution units.

Note that for explicit aliasing mode to be usable for many kinds of code,
there *MUST* be a way by which code can indicate that memory will no longer
be used as one type and will instead be used as another. In some cases,
such notification may actually improve efficiency if there's a form which
allows memory to take on Unspecified values, since any pending writes
could not be deferred past such a directive, but could be omitted
altogether.
Richard Kettlewell
2016-03-17 20:42:25 UTC
Permalink
Raw Message
Post by s***@casperkitty.com
Note that explicit aliasing mode would allow many optimizations not possible
in C99. For example,
void test(int *p1, float *p2)
{
for (int i=0; i<1000; i++)
{
p1[i] = i; p2[i] = i*1.5f;
}
}
The C99 rules require that generated code perform all operations in the
exact order specified in cases where the areas of storage accessed via the
two pointers overlap.
Not a great example, as the C99 rules do not require that, and modern
compilers do take advantage of this freedom. For instance Clang will
vectorize both the integer and float operations.
--
http://www.greenend.org.uk/rjk/
s***@casperkitty.com
2016-03-17 21:47:57 UTC
Permalink
Raw Message
Post by Richard Kettlewell
Post by s***@casperkitty.com
void test(int *p1, float *p2)
{
for (int i=0; i<1000; i++)
{
p1[i] = i; p2[i] = i*1.5f;
}
}
Not a great example, as the C99 rules do not require that, and modern
compilers do take advantage of this freedom. For instance Clang will
vectorize both the integer and float operations.
While I don't doubt that some compilers violate the C99 rules, I see no
basis for that behavior within the C99 spec. Given e.g.

void *p = malloc(8000);
int *fp = (int*)p;
float *fp = ((float*)p) + 10;
test(ip, fp);

When test() is entered, none of the memory in the block identified by p
would have any effective type. During the first pass through the loop,
the storage identified by fp would have its effective type changed to
"float", but per N1570:

If a value is stored into an object having no declared type through an
lvalue having a type that is not a character type, then the type of the
lvalue becomes the effective type of the object for that access and for
subsequent accesses **that do not modify the stored value.**

I would suggest that the effective type would only remain "float" until the
i==10 pass through the loop; since that pass modifies the stored value,
the effective type "float" would get nullified, and since the object would
have no other effective type at that point its effective type would be set
to "int" until the next operation that modifies it.

If you are suggesting that writing to allocated storage permanently sets the
effective type until it's freed (which is no doubt what some compiler writers
would *like* the spec to say) what do you suppose is the intended meaning of
the words "that do not modify the stored value"?

In any case, I would suggest that if your reading is regarded as having any
legitimacy, that would in and of itself prove that the Standard fails the
most important requirement of any language standard, which is to ensure that
any ambiguities resolve themselves in the direction of compatibility (e.g.
by saying that in certain ambiguous corner cases programmers aren't allowed
to do something, but compilers aren't allowed to assume they won't). The
C99 Standard fails the other way, by implying that programmers are allowed to
reuse allocated storage memory if they ensure that it's written as a new
type before it's read as that new type but failing to clearly require that
compilers honor the semantics of code that does so.
Richard Kettlewell
2016-03-17 22:01:47 UTC
Permalink
Raw Message
Post by s***@casperkitty.com
Post by Richard Kettlewell
Post by s***@casperkitty.com
void test(int *p1, float *p2)
{
for (int i=0; i<1000; i++)
{
p1[i] = i; p2[i] = i*1.5f;
}
}
Not a great example, as the C99 rules do not require that, and modern
compilers do take advantage of this freedom. For instance Clang will
vectorize both the integer and float operations.
While I don't doubt that some compilers violate the C99 rules, I see no
basis for that behavior within the C99 spec. Given e.g.
Having stared more closely at the output I’m less convinced that the
vectorized version actually violates the apparent ordering.
Post by s***@casperkitty.com
void *p = malloc(8000);
int *fp = (int*)p;
float *fp = ((float*)p) + 10;
test(ip, fp);
When test() is entered, none of the memory in the block identified by p
would have any effective type. During the first pass through the loop,
the storage identified by fp would have its effective type changed to
If a value is stored into an object having no declared type through an
lvalue having a type that is not a character type, then the type of the
lvalue becomes the effective type of the object for that access and for
subsequent accesses **that do not modify the stored value.**
I would suggest that the effective type would only remain "float" until the
i==10 pass through the loop; since that pass modifies the stored value,
the effective type "float" would get nullified, and since the object would
have no other effective type at that point its effective type would be set
to "int" until the next operation that modifies it.
I think you’re right. Apologies.
--
http://www.greenend.org.uk/rjk/
s***@casperkitty.com
2016-03-17 22:36:15 UTC
Permalink
Raw Message
Having stared more closely at the output I'm less convinced that the
vectorized version actually violates the apparent ordering.
...
I think you're right. Apologies.
Do you agree with my premise that there are some kinds of application, as well
as a large corpus of existing code, where it is important to be able to reuse
storage as different types, but there are many situations where code doesn't
need to do that and where optimizations based on the assumption that code won't
do that could be very helpful?

BTW, I'd suggest also adding another memcpy variant which accepts five
parameters:

__tmemcpy(inferType *destBase, size_t destOfs,
inferType *srcBase, size_t srcOfs,
size_t n);

Unlike memcpy, this would add an additional stipulation that if given a
pointer of a type other than void*, srcBase would need to identify the
*start* of an object of the given type, destBase would likewise if not
void* need to identify the *start* of an object, and for types which have
a fixed size (no FAM at the end) accesses past the end of the identified
object must act upon consecutively-allocated objects of the given type;
for types with an FAM, accesses beyond the end of the given object would
be accesses to that array.

When not using aliasing analysis, there's no need to distinguish the cases
where a pointer given to memcpy identifies a location in the middle of an
object from those cases where the pointer identifies the start, and thus
memcpy/memmove functions make no such distinction, but if code needs to
overwrite part of a structure with bytes imported from another type, I see
no way a compiler can know what parts of the structure might be affected
without the programmer telling it.
Randy Howard
2016-03-18 04:12:57 UTC
Permalink
Raw Message
Post by Kaz Kylheku
Post by Rick C. Hodgin
Post by Keith Thompson
This schedule allows for the formal adoption of a revised standard
by the end of 2021, with a publication date of 2022.
I would like to see the next standard remove the requirement of having
forward declarations.
Sure; you just need to propose a detailed set of requirements of how
that is supposed to works that is reasonably complete, sound and
backward-compatible.
Golang sure handles that in a clean way. It obviously can be done.
--
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me
directly)
Keith Thompson
2016-03-17 19:40:50 UTC
Permalink
Raw Message
Post by Keith Thompson
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm
[...]

One relevant quotation, from the "Additional Principles for C11"
section:

13. **Unlike for C99, the consensus at the London meeting was
that there should be no invention, without exception.** Only
those features that have a history and are in common use by a
commercial implementation should be considered. Also there must
be care to standardize these features in a way that would make
the Standard and the commercial implementation compatible.

Which means, assuming that principle is applied to C2x, that anyone
who wants a *new* feature considered for C2x needs to make sure
that it's actually implemented and in common use.

(The use of the phrase "commercial implementation" *could* be
interpreted to exclude gcc. I don't know whether that was the
intent. Personally, I hope it wasn't.)

I'll also point out that though a few members of the Committee
have participated in this newsgroup, and zero or more members
read it, there is no official association between the Committee
and this newsgroup. Posting ideas here is not, as far as I know,
an effective way to get them to the attention of the Committee.

One of the zero or more aforementioned members can correct me if
I'm mistaken.
--
Keith Thompson (The_Other_Keith) kst-***@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
s***@casperkitty.com
2016-03-17 23:36:47 UTC
Permalink
Raw Message
Post by Keith Thompson
One relevant quotation, from the "Additional Principles for C11"
13. **Unlike for C99, the consensus at the London meeting was
that there should be no invention, without exception.** Only
those features that have a history and are in common use by a
commercial implementation should be considered. Also there must
be care to standardize these features in a way that would make
the Standard and the commercial implementation compatible.
I would suggest that a somewhat more helpful requirement would be that
for a feature to be added to the Standard, it must be possible to for
some existing compilers to process in semantically-correct fashion
programs which use the new features. That would be a somewhat looser
requirement than a "no new invention" rule, but would still avoid the
"chicken-and-egg" problem associated with the new features in C99.

Consider, for example, a predefined macro "__XX_ARBITRARY_CHOICE(x,y)"
which would map to an intrinsic authorizing a compiler to arbitrarily
substitute x or y, chosen in Unspecified fashion. Code using such a
feature could work on any compiler which doesn't define the identifier
in contrary fashion via:

#ifndef __XX_ARBITRARY_CHOICE
#define __XX_ARBITRARY_CHOICE(x,y) x
#endif

but a compiler which understands the directive could look to see whether
one form or the other would lead to more efficient code and generate that.
Even if a programmer is using a compiler which doesn't do anything with the
directive, the directive would usefully document that the two expressions
will be equivalent in all cases the programmer cares about. The directive
would be much more useful, of course, on compilers which could examine the
consequences of each alternative, but programmers could use it on just
about any compiler regardless of such support.
Randy Howard
2016-03-18 04:14:07 UTC
Permalink
Raw Message
Post by Keith Thompson
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm
There are (probably appropriately) no specifics on what changes
will be made in the new standard.
The preliminary charter mentions updating the Rationale for C11,
or at least creating a new Rationale document for C2x.
- CD Registration (bugfix) — December 2016
- CD Ballot (bugfix) — June 2017
- DIS Ballot (bugfix) — December 2017
- CD Registration (C2x) — December 2019
- CD Ballot (C2x) — December 2020
- DIS Ballot (C2x) — December 2021
This schedule allows for the formal adoption of a revised standard
by the end of 2021, with a publication date of 2022.
"Minimize incompatibilities with C++"

I might be done laughing over that item alone by tomorrow morning.
--
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me
directly)
Loading...