Friday, April 5, 2019

Digest for comp.lang.c++@googlegroups.com - 25 updates in 6 topics

Bonita Montero <Bonita.Montero@gmail.com>: Apr 05 01:01PM +0200

> Have you considered using a C++11 fence?
 
The C++11-fence results in a logical as well as a physical fence.
 
> In gcc, asm volatile ("" ::: "memory") is a compiler barrier.
 
Yes, it is a logical barrier, but it has aquire as well as release
-behaviour.
 
> This is /not/ the same as fences, which affect the order and
> synchronisation of data between threads.
 
No, ''("" ::: "memory")'' is a _logical_ barrier.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 05 01:02PM +0200

>> Need to actually compile this, and take a closer look. However,
>> one little point. Beware of the fact that sem_wait can return
>> EINTR, and needs to be waited on again in a loop.
 
I'm waiting in a loop in the forced_wait anyway.
David Brown <david.brown@hesbynett.no>: Apr 05 02:22PM +0200

Bonita, if you want to reply to me, then please learn to quote properly,
and cite properly, using standard Usenet conventions. You'll find it a
pain with Google's appallingly bad "groups" interface, so I recommend
getting a real news client and a real news server (Thunderbird and
news.eternal-september.org are free and popular). Proper tools make the
job extremely simple.
 
If you wish to continue with your disrespectful, non-standard and
unhelpful posting habits, then you can do so without me - and please do
not quote what I write without giving proper citations.
 
On 05/04/2019 13:01, Bonita Montero wrote:
>> Have you considered using a C++11 fence?
 
> The C++11-fence results in a logical as well as a physical fence.
 
That makes no sense - we are talking programming, not gardening. There
is no such concept as a "physical fence".
 
>> In gcc, asm volatile ("" ::: "memory") is a compiler barrier.
 
> Yes, it is a logical barrier, but it has aquire as well as release
> -behaviour.
 
You asked for an "acquire and release barrier".
 
>> This is /not/ the same as fences, which affect the order and
>> synchronisation of data between threads.
 
> No, ''("" ::: "memory")'' is a _logical_ barrier.
 
I just said it is a compiler barrier, but not a fence. Why did you say
"no" to that?
Bonita Montero <Bonita.Montero@gmail.com>: Apr 05 02:38PM +0200

> That makes no sense - we are talking programming, not gardening.
> There is no such concept as a "physical fence".
 
There is!
A logical fence keeps the compiler away from reordering the load-/store
-intructions. A physical fence keeps the processor away from doing this
in the intruction-stream. The fences you have with C++11 do both both.
 
 
 
>> Yes, it is a logical barrier, but it has aquire as well as release
>> -behaviour.
 
> You asked for an "acquire and release barrier".
 
Separate!
David Brown <david.brown@hesbynett.no>: Apr 05 04:28PM +0200

On 05/04/2019 14:38, Bonita Montero wrote:
<snip>
 
What part of proper Usenet posting conventions seems to be troubling you?
 
When you can communicate politely in the same way as others in the
group, you will get far better answers.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 05 08:49PM +0200

Don't you recognize your own posting parts?
I'm so sorry for you!
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 05 05:51AM +0200

On 04.04.2019 14:13, James Kuyper wrote:
 
>>> Thanks, now it appears to be clear where the nonsense comes from,
>>> namely the "optimization" in the GCC compiler.
 
>> That's unlikely. The wording in the C standard predates gcc.
 
The last line above assumes the interpretation that it seeks to prove.
Which is the usual circular argumentation fallacy in debates about GCC.
Which goes to show that as an online discussion that involves GCC grows
beyond the first few remarks, the probability of clearly fallacious
reasoning being used in earnest, approaches 1.
 
 
> Note that while the wording in the C standard dates back to C89, the
> fact that it has this meaning was sufficiently unclear that it had to be
> resolved with DR #017 in 1992, 5 years after gcc came out.
 
This however is good, and proves me wrong about the interpretation.
 
At least it does if one doesn't argue pedantically (and misguided) that
the part of the C++ standard that says it incorporates the C standard,
is non-normative. It is, though, which to me reaffirms that the standard
is practical document intended to be interpreted with common sense, and
not a perfect formal document. Which sometimes, when the practicality is
arguable as it is here, leads to doubts and misunderstandings...
 
Quoting the resolution of question 16 in C Defect Report #17 at <url:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_017.html>:
 
[quote]
For an array of arrays, the permitted pointer arithmetic in subclause
6.3.6, page 47, lines 12-40 is to be understood by interpreting the use
of the word ``object'' as denoting the specific object determined
directly by the pointer's type and value, not other objects related to
that one by contiguity. Therefore, if an expression exceeds these
permissions, the behavior is undefined. For example, the following code
has undefined behavior:
int a[4][5];
 
a[1][7] = 0; /* undefined */
Some conforming implementations may choose to diagnose an ``array bounds
violation,'' while others may choose to interpret such attempted
accesses successfully with the ``obvious'' extended semantics.
[/quote]
 
 
> I sincerely doubt that gcc had anything in particular to do with that
> decision, but the timing of the events does not rule out that possibility.
 
It's all GCC's fault.
 
Including all apparently natural catastrophes.
 
Well, more seriously, if it wasn't the folks involved with optimization
in GCC, then it was the same mindset at work, the idea of /supporting
the compiler/ at the expense of programmers having to know about and
perfectly, consistently avoid a large number of unnatural possible UBs,
i.e. making it easy to write incorrect code and making the effect
unpredictable, instead of the opposite, making it hard to write
incorrect code and making the code predictable, at cost to compiler
writers who must then work harder to effect the desired optimizations.
 
 
Cheers!,
 
- Alf
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 05 08:46AM -0400

On 4/4/19 11:51 PM, Alf P. Steinbach wrote:
>>>> namely the "optimization" in the GCC compiler.
 
>>> That's unlikely. The wording in the C standard predates gcc.
 
> The last line above assumes the interpretation that it seeks to prove.
 
How? In the last line, he's attempting to prove that it's unlikely that
gcc influenced the committee's decision. The only assumption he's using
is that gcc didn't exist yet at the time the decision was made. I don't
see any circularity there. He was incorrect about that point, but only
by a couple of years; and it is indeed unlikely that the newly released
compiler was already sufficiently influential to control the committee's
decisions. It's not impossible, as it would have been if he'd been
right, but it's still implausible.
 
I'm not sure whether the FSF had any representatives on the committee at
that time. I know that they had no representatives on the committee at
the time C99 was approved, because some of them complained in this forum
about the committee's failure to incorporate many of gcc's innovations.
The response from a committee member was to point out that there was no
one on the committee who felt sufficiently familiar with those
innovations to promote them. He said that the FSF should have put at
least one member on the committee. The FSF people responded by claiming
that membership was too expensive in both money and time for them to
participate.
 
But many organizations much smaller than the FSF had no trouble finding
people to volunteer for the committee. Participating in the US committee
was only $800/year at the time that complaint was made, and open to
foreign nationals - many people join the US committee because their own
country either doesn't have a standards group participating in ISO, or
if there is such a group, membership is too expensive. The US committee
gets only 1 vote in ISO, just like any other country, but is
disproportionately influential on the ISO committee, and that's one of
the reasons (having a lot more members than the other countries to work
on tasks is the other main factor).
Voting membership also requires attending at least 2(?) of the three
meetings per year that are held at various places around the world. The
travel costs can be significant - but the FSF is sufficiently large and
sufficiently international that it should have been able to send a
representative to at least 2 meetings per year without having to use an
airplane to get there. Many members have no organizational support -
they cover the costs entirely from their own funds.
 
 
> At least it does if one doesn't argue pedantically (and misguided) that
> the part of the C++ standard that says it incorporates the C standard,
> is non-normative.
 
Several distinct points, each of which is separately sufficient to
deflate that argument.
 
1. I was making no use of the concept that the C++ standard incorporates
any part of the C standard.
 
2. The particular clauses from the C standard that the C committee used
as a basis for it's decision on DR017 were copied into the C++ standard
with modifications, rather than being incorporated by reference.
 
This is not particularly unusual - the only significant part of the C
standard that was incorporated into the C++ standard by reference was
the description of the C standard library. Section 1.7, "Normative
references", includes references to the C99 standard and to the next
three Technical Corrigenda to that standard, but referring to a standard
does not mean incorporating it by reference. For instance, POSIX is
another standard listed in that section, but it's mentioned there only
so the standard can refer to POSIX when discussing compatibility with
that standard, not because any of that standard's requirements are
incorporated into C++ by reference.
 
None of the modifications that were made during the copy affected the
validity of the C committee's conclusions. If the C++ committee had ever
said anything to repudiate those conclusions, at least so far as C++ is
concerned, it would be a different matter. But as far as I know, they
haven't.
 
3. The only clause that does incorporate parts of the C standard by
reference is 17.5.1.5p1, which is fully normative - what makes you think
otherwise? If that weren't the case, there'd be no normative definition
of the behavior of most of the functions that C++ borrows from the C
standard library. Are you really prepared to say that there is no
normative description of the behavior of std::memcpy()?
 
>> decision, but the timing of the events does not rule out that possibility.
 
> It's all GCC's fault.
 
> Including all apparently natural catastrophes.
 
I'll assume that was a joke. Given the faceless nature of usenet, it's
best to mark such comments with an appropriate emoticon, tag, or emoji -
it's easy to confuse such jokes with the mad but serious ravings of
fanatics, because such fanatics do in fact post such things to usenet
fairly often.
 
> unpredictable, instead of the opposite, making it hard to write
> incorrect code and making the code predictable, at cost to compiler
> writers who must then work harder to effect the desired optimizations.
 
You've got the motivations backwards. Hard as it may be for you to
believe, the relevant rule was written in the belief that code which
violates it is fundamentally flawed, and should therefore NOT be
allowed. You clearly do not agree - but your failure to agree doesn't
change the fact that this is in fact the motivation for the rule.
 
However, given the nature of the language, detection of violations of
that rule at compile time without any false positives or false negatives
is provably equivalent to solving the halting problem. It is therefore
not feasible for the standard to mandate such detection, so it cannot be
made a constraint violation. The most it can do is declare that such
code has undefined behavior.
 
Run-time detection of such problems using heavy pointers is entirely
feasible - and is permitted precisely because the behavior is undefined.
Optimizations such as the one I mentioned are simply allowed by the fact
that such code has undefined behavior - they were not the motivation for
the rule.
jameskuyper@alumni.caltech.edu: Apr 05 07:21AM -0700

On Friday, April 5, 2019 at 8:47:09 AM UTC-4, James Kuyper wrote:
> On 4/4/19 11:51 PM, Alf P. Steinbach wrote:
...
> Optimizations such as the one I mentioned are simply allowed by the fact
> that such code has undefined behavior - they were not the motivation for
> the rule.
 
I let myself get sidetracked while writing that. The reasons why this
can't be a constraint violation are stronger and less esoteric than just
the halting problem issue. A constraint violation is supposed to be
detectable during translation of a program. Determining whether or not
this rule has been violated requires knowing which array a given pointer
expression points at, and what location in that array it points at, and
the length of the array, as well as the value of the integer expression
being added or subtracted from the pointer expression. NONE of that
information need be available during translation - it could all vary at
run time. Decent implementations are free to produce a warning in cases
where it's easy to determine that it's been violated, but it's not
feasible for the standard to mandate detection in all cases, which is
what would happen if it were a constraint violation.
 
They could have made an exception to this rule for cases, such as
arrays of arrays, where contiguity is guaranteed. They did end up having
to make such an exception for pointer equality comparisons in the case
where two objects happen to be adjacent. The fact that they didn't make
a similar exception for the addition of an integer to a pointer reflects
the committee's judgement that you shouldn't be writing such code.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 05 05:56PM +0200

On 05.04.2019 14:46, James Kuyper wrote:
 
>> The last line above assumes the interpretation that it seeks to prove.
 
> How? In the last line, he's attempting to prove that it's unlikely that
> gcc influenced the committee's decision.
 
Well, keep in mind that we were talking about two opposing
interpretations of a piece of the standard, not that wording itself.
 
The circular assumption is that the committee's intent, what it tried to
express, was the favored interpretation.
 
Without that circular assumption the above would express in a
Spock-incompatible way that GCC folks could not have made an
interpretation of wording that already existed, which is a much worse
fallacy.
 
As it happened the conclusion turned out to probably not be wrong (it
was I who was wrong), but the logic is just missing.
 
Wikipedia about this:
 
[quote]
Circular reasoning is not a formal logical fallacy but a pragmatic
defect in an argument whereby the premises are just as much in need of
proof or evidence as the conclusion, and as a consequence the argument
fails to persuade. Other ways to express this are that there is no
reason to accept the premises unless one already believes the
conclusion, or that the premises provide no independent ground or
evidence for the conclusion. Begging the question is closely related to
circular reasoning, and in modern usage the two generally refer to the
same thing.
[/quote]
 
You showed me, I can't speak for others really though I think they'd
have stated it if they'd known, that some time after C Defect Report 17
the committee ruled on what the wording should mean, and decided that it
meant that interpretation, that I had been sure was nonsense on grounds
of practicality. That resolution is definitive for me. If the above had
referred to the DR's resolution then it would have been roughly valid,
since presumably that resolution is known to compiler writers
 
 
> The only assumption he's using
> is that gcc didn't exist yet at the time the decision was made.
 
Nope.
 
 
> compiler was already sufficiently influential to control the committee's
> decisions. It's not impossible, as it would have been if he'd been
> right, but it's still implausible.
 
Again, keep in mind that we were talking about two opposing
interpretations of a piece of the standard, not that wording itself.
 
 
> deflate that argument.
 
> 1. I was making no use of the concept that the C++ standard incorporates
> any part of the C standard.
 
I'm sorry, I didn't mean to imply that.
 
Rather I intended to note that in the context of admitting that I was
wrong. Sort of, hey, I'm not going into some artificial formal idiocy to
show how right I could have been with a literal no-common-sense reading
of the standard. I'm very much in favor of clarity, not obscurity. :)
 
 
> references", includes references to the C99 standard and to the next
> three Technical Corrigenda to that standard, but referring to a standard
> does not mean incorporating it by reference.
 
I was referring to
 
C++14 17.5.1.5
[quote]
Paragraphs labeled "See also:" contain cross-references to the relevant
portions of this International Standard and the ISO C standard, which is
incorporated into this International Standard by reference.
[/quote]
 
It was there from the beginning, but in C++17 the part after the comma
has been removed.
 
Anyway it was in a non-normative section of the standard.
 
I'm not sure how e.g. the issue of guaranteed ranges of basic types is
specified in C++17 and later, without that incorporation.
 
With C++14 and earlier one could just, with a reasonable common sense
interpretation, use the C standard's wording.
 
 
> so the standard can refer to POSIX when discussing compatibility with
> that standard, not because any of that standard's requirements are
> incorporated into C++ by reference.
 
 
[snip rest]
 
 
Cheers!,
 
- Alf
Richard Damon <Richard@Damon-Family.org>: Apr 05 12:15PM -0400

On 3/31/19 6:21 PM, Bonita Montero wrote:
>> changes unless the iterator itself is changed.  What you propose would
>> ruin the iterator concept.
 
> But there's no technical necessity for this concept.
 
It seems that if you want an way to specify the n'th element of the
vector, you don't want an iterator, but an numerical index, and use
indexing operations on the vector.
 
An iterator IS a concept, and part of that is that the idea that it is
an extension of a pointer that when working on a sequence always points
to a GIVEN item, and the invalidation rules tells you when that
assumption no longer holds.
 
Note, that in normal implementations, the invalidation of those
iterators doesn't actually do anything to them, so they could be used to
access the shifted elements, and unless the iterator has an extensive
debugging scaffolding to check this (which is in my experience
unusually, especially if not asked for) it will work the way you
describe in the case you describe. The key here is YOU need to know
enough of what is happening behind the scenes to know what unpromised
behavior exists. The Standard, because it does include the concept that
an Iterator will continue to point to the same element unless explicitly
changed (or invalidated) doesn't want to add the overhead to have all
those iterators updated, so it invalidates them. This concept is useful
because it is meaning full for a wide range of data structures, and
given data structures are constrained by the various complexity limits
and iterator invalidation rules. Changing invalidation to some specific
changing of what certain iterators now point to adds a complexity to the
standard and to understanding it.
 
As I pointed out in the beginning, the behavior you are looking for IS
available.
David Brown <david.brown@hesbynett.no>: Apr 05 07:39PM +0200

On 05/04/2019 17:56, Alf P. Steinbach wrote:
> interpretations of a piece of the standard, not that wording itself.
 
> The circular assumption is that the committee's intent, what it tried to
> express, was the favored interpretation.
 
Ah, so the "circular assumption" comes from reading the words in the
standard, and assuming the authors wrote what they intended to write?
 
That is a very strange use of the phrase "circular assumption" or
"circular reasoning" - not one that I had come across before. I thought
it was just an example of "reading".
jameskuyper@alumni.caltech.edu: Apr 05 11:41AM -0700

On Friday, April 5, 2019 at 11:56:44 AM UTC-4, Alf P. Steinbach wrote:
> interpretations of a piece of the standard, not that wording itself.
 
> The circular assumption is that the committee's intent, what it tried to
> express, was the favored interpretation.
 
He made no use of that assumption in the line you identified as
containing a circular argument. Regardless of what the committee's
intent was, if gcc did not exist at the time (which is the false
assumption he did make), then gcc could not have possibly influenced the
committee's decision on the matter. While gcc did exist, it was very
young at that time, so it would still be unlikely to have much influence
on the committee's decision. Again, that is true, regardless of what the
committee's actual intent was.
 
> Spock-incompatible way that GCC folks could not have made an
> interpretation of wording that already existed, which is a much worse
> fallacy.
 
I agree that it would be Spock-incompatible, but only because I can't
figure out any way to produce that conclusion from his argument, with or
without the circular assumption you incorrectly claim he relied upon.
If, as he incorrectly assumed, gcc did not exist yet, how could the gcc
folks have possibly formed any interpretation at all, of anything?
That's completely independent of what the committee's intent was.
 
Since gcc did actually exist in 1989 when those words were first
published, they could in fact interpret those words - but because it was
still in it's infancy at that time, gcc was unlikely to have influenced
how those words were written. Even in 1992 when the committee resolved
DR#017, gcc was still so new that it was unlikely to have significantly
influenced the committee's resolution.
 
> You showed me, I can't speak for others really though I think they'd
> have stated it if they'd known, that some time after C Defect Report 17
> the committee ruled on what the wording should mean, and decided that it
 
To be specific, the committee made that ruling when it resolved DR017.
You seem to be assuming that the committee used that ruling to change
their mind about what their wording meant. I don't have any details
about their deliberations on the matter, so I can't be sure, but it's at
least as likely that they merely used that ruling to confirm that the
wording had always been meant to be interpreted in that fashion,
particularly since it seems quite clear to me that this was in fact the
meaning of that wording. Note that the resolution of that DR did not
specify any changes to the wording.
 
> of practicality. That resolution is definitive for me. If the above had
> referred to the DR's resolution then it would have been roughly valid,
> since presumably that resolution is known to compiler writers
 
We're talking about the possibility that gcc influenced the way the
words were originally written, or perhaps the decision that was made
when resolving the defect report (it's your claim that they had such
influence, but I'm not clear from your wording which of those two
possibilities you were thinking of). Any such influence, in order to be
effective, would have had to have occurred, at the very latest, before
the resolution of the DR. Therefore, whether or not gcc folk ever read
the resolution is completely irrelevant to that possibility.
 
> > right, but it's still implausible.
 
> Again, keep in mind that we were talking about two opposing
> interpretations of a piece of the standard, not that wording itself.
 
We're also talking which of those interpretations is consistent with the
wording. I've seen many explanations of the other interpretation, but
I've never seen an explanation that was consistent with the actual
words.
The key point is that, given
int a[4][5];
The array a has only 4 elements, of the type int[5]. The array a[1] has
only 5 elements, of type int. The expression a[1][7] is equivalent to
*(*(a+1)+7).
 
Applying the wording in n4762.pdf:
"If the expression P points to element x[i] of an array object x with n
elements, the expressions P + J and J + P (where J has the value j)
point to the (possibly-hypothetical) element x[i + j] if
0 <= i + j <= n; otherwise, the behavior is undefined."
 
The relevant expression is *(a+1)+7, for which P is "*(a+1)", J is "7",
x is a[1], i is 0, n is 5, and j is 7, thereby violating the requirement
for defined behavior.
Can you identify what P, J, x, i, n, and j are for an interpretation of
these words that does not violate that requirement? A popular choice is
to interpret x as referring to "a". The problem is that P does not
point at any element of a itself, it points into a[1], but it points at
a[1][0], which is an element of a[1], but not an element of a itself.
If you think "point at" could be interpreted as including "point into",
then i=1, and x[i+j] would be a[8], which does not match anyone's claims
for the location that this expression points at, and would violate the
relevant requirement just as badly.
 
What you'd really have to do is justify identifying *(int(*)[20])a as
the array that you're referring to (I've seen people give arguments
equivalent to that approach) - but the standard doesn't define the
behavior of that expression.
 
...
> portions of this International Standard and the ISO C standard, which is
> incorporated into this International Standard by reference.
> [/quote]
 
In the latest draft that I have access to, the closest equivalent to
that wording is in section 15.4.1.5, titled "C library".
 
> It was there from the beginning, but in C++17 the part after the comma
> has been removed.
 
I hadn't realized that there'd been such a change in the relevant
wording. At work, where I am now, I refer to n4762.pdf, which doesn't
use the phrase "incorporated by reference" anywhere. At home I've got a
copy of an older draft, which uses that phrase in exactly one location.
The newer draft does, however, say, in 15.2p2, that
 
"The descriptions of many library functions rely on the C standard
library for the semantics of those functions. In some cases, the
signatures specified in this document may be different from the
signatures in the C standard library, and additional overloads may be
declared in this document, but the behavior and the preconditions
(including any preconditions implied by the use of an ISO C restrict
qualifier) are the same unless otherwise stated."
 
which has essentially the same meaning as the older version, even if it
doesn't use the phrase "incorporated by reference". Does your copy have
comparable wording, somewhere?
 
> Anyway it was in a non-normative section of the standard.
 
I'm curious - what renders it non-normative? Notes, examples, and
footnotes are non-normative, and the same is true of any part of the
standard which is explicitly labelled "informative". The rest of the
standard is normative. Which of these cases applies to 17.5.1.5 in your
copy?
Bart <bc@freeuk.com>: Apr 04 08:34PM +0100

On 04/04/2019 20:20, Rick C. Hodgin wrote:
 
> I'm curious about people's thoughts on the introduction of this new
> information into C/C++?
 
What's the difference between this and nested functions?
 
(It is possible to implement nested functions without necessarily
sharing access to an outer function's stack-frame variables, which is
where the problem areas lie in implementation.)
 
 
int func1(void)
{
int func2(int* p)
{
// Direct use without NULL testing
*p = *p + get_step_size();
} int* p;
 
if ((p = populate_the_pointer()))
return func2(p);
 
return -1;
}
Ian Collins <ian-news@hotmail.com>: Apr 05 01:29PM +1300

On 05/04/2019 08:43, Rick C. Hodgin wrote:
> as well, don't they? Childof functions would be separate entities
> without the parent context, and they could theoretically be the
> child of multiple parents, including itself through recursion.
 
The perils of cross posting...
 
Bart's example, with slight modification to use a lambda, is valid in
C++. In this case, you can choose whatever parent context you wish to
encapsulate.
 
int func1()
{
auto func2 = [](int* p)
{
// Direct use without NULL testing
*p = *p + get_step_size();
return 0;
};
 
int* p;
 
if ((p = populate_the_pointer()))
return func2(p);
 
return -1;
}
 
--
Ian.
David Brown <david.brown@hesbynett.no>: Apr 05 10:03AM +0200

On 04/04/2019 21:20, Rick C. Hodgin wrote:
 
> -----
> I'm curious about people's thoughts on the introduction of this new
> information into C/C++?
 
What does this give you, that you can't get by making "func2" a static
function? If func2 is declared static (and you haven't passed a pointer
to it to something outside the current translation unit), then the
compiler can easily see that it is only ever called from "func1". That
lets it know just as much as you could get via the "childof" feature.
 
(And the way to handle this in a new language would be to make all
functions effectively "static" by default, and require explicit marking
of functions to export from a module.)
Robert Wessel <robertwessel2@yahoo.com>: Apr 05 12:15PM -0500

On Fri, 5 Apr 2019 10:03:32 +0200, David Brown
 
>(And the way to handle this in a new language would be to make all
>functions effectively "static" by default, and require explicit marking
>of functions to export from a module.)
 
 
Even if the function isn't static, there's nothing to prevent a
compiler from building specialized versions of it for local use.
Without the static, the compiler may have to build an unspecialized
version in case it is used elsewhere. In the context of (automatic)
inlining, most big compilers do that sort of thing already.
blt_2yo_bz@rbh38tg7h62l1onmhoof.edu: Apr 05 09:14AM

On Thu, 4 Apr 2019 03:49:21 -0700 (PDT)
 
>> Thats a nice cosy myth.
 
>There are a handful of devoted people changing the world negatively
>right now.
 
If one of them is Trump then a lot of people might disagree with you there.
 
>We (the silent majority) are not just a majority, but a far and
>away supermajority of grand stature.
 
Off you go and change the world then.
 
>Calling people "idiots" and laughing at their ignorance and cala-
>mity is not something one person should do to another. You make
>yourself part of the problem.
 
The *average* IQ in the west is 100. Thats a long way from rocket scientist.
And in africa its 70, so good luck persuading those morons to do anything
in their own favour.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 05 02:42AM -0700


> The *average* IQ in the west is 100. Thats a long way from rocket scientist.
> And in africa its 70, so good luck persuading those morons to do anything
> in their own favour.
 
You get lost in your own misconceptions and unfounded judgments.
They keep you pinned down and diminished. If you desire to change
that the ability to overcome does exist, but you must pursue it.
 
--
Rick C. Hodgin
blt_30sk@2kluo9b5zdn94iicm.co.uk: Apr 05 10:44AM

On Fri, 5 Apr 2019 02:42:22 -0700 (PDT)
 
>You get lost in your own misconceptions and unfounded judgments.
>They keep you pinned down and diminished. If you desire to change
>that the ability to overcome does exist, but you must pursue it.
 
You sound like a budget cut and paste motivational speaker - lots of words
but not much actually said.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 05 03:58AM -0700

> >that the ability to overcome does exist, but you must pursue it.
 
> You sound like a budget cut and paste motivational speaker - lots of words
> but not much actually said.
 
We hear what we want to hear.
 
You have an attitude of nonchalance and disdain for helping
others. You choose to call me names, other people names, and
you discard them as idiots and morons, even mocking people's
intelligence, something a person is born with an does not have
an ability to adjust by work or effort. You come across as
one who would mock someone also who is handicapped or has an
appearance unlike others based on those superficial qualities
alone, even though each of us is more than our mere outward
appearance, and the opportunities and what we do with those
opportunities set a course for our life that can be beyond
our apparent abilities.
 
Because you live in that place of casting negativity upon all
others around you, it is only natural you would also discount
the wisdom offered to you by me and others, and not hear any
of it when it's plainly before you able to be received.
 
You erect walls around yourself to keep you where you are.
Until you are willing to tear down those walls, you will
remain isolated from the truth.
 
The choice is yours. You harm yourself by keeping those
walls erected. The path of wisdom is coming to that first
realization in your heart, "Maybe I am wrong. Maybe there
is something I don't know that would serve me and my life
better than where I am and what I have today."
 
Get to that place and those walls will start coming down
quickly.
 
Note: I was the same one for the first 30+ years of my life.
It took me searching for the truth before it was revealed to
me. Seek the truth and watch your entire world change.
 
--
Rick C. Hodgin
blt_ZxpzjZzjv@kb3vbmyoqnmqhk0l1.edu: Apr 05 04:06PM

On Fri, 5 Apr 2019 03:58:55 -0700 (PDT)
 
>> You sound like a budget cut and paste motivational speaker - lots of words
>> but not much actually said.
 
> We hear what we want to hear.
 
[snip]
 
I re-iterate my original statement above.
fir <profesor.fir@gmail.com>: Apr 05 05:06AM -0700

im not sure how todays that old flame wars stays but for fun wana share my present view
 
im a c coder (code almost (99%) axclusively in c, almost all things that interestm me in programming are in c etc) but sporradicaly i see here or there some lines of c++ and i got funny look at it like its cobol of modern times
(which i already was knowing when i was starting c in 2001 and in thet times c++ was more popular)
 
i mean why i see a c++ lines the level of how interseting it to me to know what even that means is tital zero, in fact i think im more interesting in cobol than in c++
 
and.. c still being so much great (also as c i add some basic lov level implementation mechanisms, like how dlls are implemented, hov things map to assembly and so on..someone could say this is not c bu in my reckognition its like c programmer realm, too)
 
so....
 
 
ps note im not saying this to aggreviate c++ people its more for peacefull fun
Sam <sam@email-scan.com>: Apr 04 11:51PM -0400

gcc 8.3.1 compiles the following without a single complaint:
 
=========================================================================
 
struct foo {
 
int hello_world=0;
};
 
 
typedef const foo c_foo;
 
struct bar : c_foo {
};
 
void foobar()
{
bar baz;
 
baz.hello_world=4;
}
 
=========================================================================
 
It seems likely there's a gcc bug hiding in here. The only other explanation
that lets gcc off the gook is that the standard allows inheritance from a
const-qualified base class, specifying that the const qualification gets
ignored. That seems somewhat unlikely to me. So, is the gcc bug here that:
 
1) "struct bar : c_foo" is ill-formed, can't inherit from a const-qualified
type.
 
2) "struct bar : c_foo" is not ill-formed, but gcc ignores that the parent
class is effectively const, and allows me to modify its members.
 
If inheriting from a const-qualified superclass is allowed, then there might
be another bug, because gcc doesn't like the following:
 
struct bar : const foo {
};
"Öö Tiib" <ootiib@hot.ee>: Apr 05 12:53AM -0700

On Friday, 5 April 2019 06:52:07 UTC+3, Sam wrote:
> that lets gcc off the gook is that the standard allows inheritance from a
> const-qualified base class, specifying that the const qualification gets
> ignored. That seems somewhat unlikely to me.
 
Why? it is exactly so specified in [class.name]:
| A typedef-name that names a class type, or a cv-qualified version
| thereof, is also a class-name. If a typedef-name that names a
| cv-qualified class type is used where a class-name is required,
| the cv-qualifiers are ignored. A typedef-name shall not be used
| as the identifier in a class-head.
 
> be another bug, because gcc doesn't like the following:
 
> struct bar : const foo {
> };
 
That is ill-formed because it expects class-name there (or template
simple-template-id or decltype-specifier) with optional access-specifier.
It does not expect cv-qualified class type there and so can't parse it.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)