Monday, May 25, 2020

Digest for comp.lang.c++@googlegroups.com - 21 updates in 5 topics

James Kuyper <jameskuyper@alumni.caltech.edu>: May 24 08:25PM -0700

On Saturday, May 23, 2020 at 1:22:47 PM UTC-4, Mr Flibble wrote:
> On 23/05/2020 18:09, James Kuyper wrote:
...
> > the message that you're responding to that isn't directly relevant to
> > your response, and in usenet it's conventional to post your response
> > underneath the thing that it's a response to. ...
...
> Do as I say but not as I do, eh, mate? ...
 
What in the world are you talking about? My response was a prime example
of doing precisely what I was advising him to do, and deliberately so. I
responded to a message containing 36 lines, by removing all but the 8
lines that were actually directly relevant to my response, and placing
my response directly after the particular line I was responding to.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 25 01:34PM +0100

On 25/05/2020 04:25, James Kuyper wrote:
> responded to a message containing 36 lines, by removing all but the 8
> lines that were actually directly relevant to my response, and placing
> my response directly after the particular line I was responding to.
 
I am talking about you conveniently snipping parts of MY reply to allow you to conveniently ignore them and post vomit instead.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Daniel P <danielaparker@gmail.com>: May 25 06:28AM -0700

On Friday, May 22, 2020 at 7:17:05 PM UTC-4, Mr Flibble wrote:
 
> the Standard clearly states that iterators are abstractions of pointers;
> a pointer isn't an iterator because a thing can't be an abstraction of
> itself
 
But consider: in mathematics, a field may be considered an abstraction
(generalization) of some properties of the rational numbers, and the rational
numbers are (meet the requirements of) a field.
 
 
> ... but the Standard, like me, doesn't call such a pointer an "iterator".
 
And as James pointed out, quoting footnote 261 in n4659, "This definition
applies to pointers, since pointers are iterators."
 
Daniel
James Kuyper <jameskuyper@alumni.caltech.edu>: May 25 07:33AM -0700

On Monday, May 25, 2020 at 8:34:14 AM UTC-4, Mr Flibble wrote:
> > lines that were actually directly relevant to my response, and placing
> > my response directly after the particular line I was responding to.
 
> I am talking about you conveniently snipping parts of MY reply to allow you to conveniently ignore them and post vomit instead.
 
I interpreted your comment as referring to the message it was responding
to, as the example you were referring to of me not following my own
advice. That's the normal interpretation of such a comment in such a
context. Since you actually intended to refer to a different message,
you could have avoided creating confusion by saying so explicitly.
 
However, "snipping parts of MY reply" was a prime example of following
my own advice, not violating it. I snipped those parts because, in my
judgment, they weren't relevant to my response. You obviously disagree
with that judgment, but that disagreement doesn't make my behavior a
violation of my own advice. Failing to snip the part that you're
criticizing me for snipping would have constituted a violation of that
advice.
 
If you wish, I can modify the wording of my advice to make the point
clearer:
 
"... remove any part of the message that you're responding to that is
not, according to your own judgment, directly relevant to your response,
..."
 
I didn't add that clause in my original advice, because I considered it
to be implicitly obvious that only the author's own judgment can be used
for this purpose. Even if the author goes to other people for advice on
how to write a given message, it is ultimately the author's
responsibility to judge which such advice to follow. It would, in my
opinion, be seriously bad advice if I changed "your own judgment" to
"Mr. Fibble's judgment".
 
In my opinion, the clause from the standard that you quoted and I
snipped clearly supports my interpretation, and not yours. In your
opinion, it clearly supports your opinion, and not mine. We have already
both expressed those opinions, and given our reasons for them - I didn't
see anything more worth saying about the matter. Therefore, I didn't say
anything about that citation, and therefore, I snipped it.
 
A useful response on your part would be to cite the clause in which the
standard defines the term "iterator" - I couldn't find one.
 
I found some relevant definitions in 27.2.1p2: "This International
Standard defines five categories of iterators, according to the
operations defined on them: input iterators, output iterators, forward
iterators, bidirectional iterators and random access iterators, ...".
Each of those category names is in italics, an ISO convention
identifying this clause as providing the definitions for those terms,
but the term "iterator" on it's own is not so marked, neither here nor
anywhere else that I could find.
 
I just realized that there's an important rule for interpreting ISO
standards that helps with this issue. When an ISO standard provides a
list like that, it is meant to be an exhaustive list unless otherwise
specified, which would imply that an iterator is anything that meets the
requirements of at least one of those categories. Note that forward,
bidirectional, and random access iterators are all defined as subsets of
input iterators, so that would imply that an iterator is anything that
meets the requirements for being either an input iterator or an output
iterator. But the standard fails to say so explicitly.
 
Every non-null pointer to an object type meets the requirements for a
random access iterator. Every non-null pointer to an object type which
isn't const-qualified also meets the requirements for an output
iterator. If you believe otherwise, the most useful response you could
make would be to identify at least one specific requirement that at
least one such pointer fails to meet.
 
From past experience, I don't expect a useful response from you, merely
more foul-mouthed insults - but I can hope.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 25 05:45PM +0100

On 25/05/2020 14:28, Daniel P wrote:
 
> But consider: in mathematics, a field may be considered an abstraction
> (generalization) of some properties of the rational numbers, and the rational
> numbers are (meet the requirements of) a field.
 
An apple might be green but it doesn't follow that all green things are apples.
 
 
>> ... but the Standard, like me, doesn't call such a pointer an "iterator".
 
> And as James pointed out, quoting footnote 261 in n4659, "This definition
> applies to pointers, since pointers are iterators."
 
Then the Standard is inconsistent. A thing cannot be an abstraction of itself; not all pointers are iterators.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Daniel P <danielaparker@gmail.com>: May 25 10:46AM -0700

On Monday, May 25, 2020 at 12:45:27 PM UTC-4, Mr Flibble wrote:
> On 25/05/2020 14:28, Daniel P wrote:
.> >
> > numbers are (meet the requirements of) a field.
 
> An apple might be green but it doesn't follow that all green things are
> apples.
 
The property "green" cannot be sensibly be regarded as an abstraction or
generalization of "apple".
 
> > And as James pointed out, quoting footnote 261 in n4659, "This definition
> > applies to pointers, since pointers are iterators."
 
> Then the Standard is inconsistent. A thing cannot be an abstraction of itself; not all pointers are iterators.
 
I don't know what "a thing cannot be an abstraction of itself" means.
 
In logic, if a pointer meets the requirements of an iterator category, then
it _is_ a member of that category. As James notes, "Every non-null pointer to
an object type meets the requirements for a random access iterator. Every
non-null pointer to an object type which isn't const-qualified also meets the
requirements for an output iterator."
 
Agree? Disagree?
 
Daniel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 25 09:57PM +0100

On 25/05/2020 18:46, Daniel P wrote:
>> apples.
 
> The property "green" cannot be sensibly be regarded as an abstraction or
> generalization of "apple".
 
I see you dislike my analogy probably because you enjoy indulging in pedantic fucktardary just like the other guy.
 
OK, I improve my fucking analogy:
 
An apple might be a fruit but not all fruits are apples,
 
i.e.
 
an iterator might be a pointer but not all pointers are iterators.
 
>>> applies to pointers, since pointers are iterators."
 
>> Then the Standard is inconsistent. A thing cannot be an abstraction of itself; not all pointers are iterators.
 
> I don't know what "a thing cannot be an abstraction of itself" means.
 
I will try re-wording so it is less technical to help you understand:
 
a thing cannot be an abstraction of itself
 
If you still don't understand then I suggest you learn fucking English.
 
> non-null pointer to an object type which isn't const-qualified also meets the
> requirements for an output iterator."
 
> Agree? Disagree?
 
Disagree.
 
A null pointer doesn't meet the requirements of an iterator ergo you have to accept that what a pointer points to is relevant; given that and the fact that the Standard itself states that iterators are an abstraction/generalization of pointers then you have to accept that a) the Standard is inconsistent and b) not all pointers are iterators. The footnote the other guy pointed out is probably non-normative but this doesn't stop the Standard from being inconsistent.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
James Kuyper <jameskuyper@alumni.caltech.edu>: May 25 03:00PM -0700

On Monday, May 25, 2020 at 4:57:58 PM UTC-4, Mr Flibble wrote:
 
> > The property "green" cannot be sensibly be regarded as an abstraction or
> > generalization of "apple".
 
> I see you dislike my analogy probably because you enjoy indulging in pedantic fucktardary just like the other guy.
 
There's nothing particularly pedantic about it, it's simply the fact that the concept of green is not in any sense (pedantic or otherwise) an abstraction of the concept of apples, so your analogy is completely unconnected with the point under discussion.
 
Now, the concept of green objects is an abstraction of the concept of green apples, so you could say "A green apple might be green object, but it doesn't follow that all green objects are green apples.", and that would be perfectly correct. The problem is, to complete that analogy, you'd have replace "green apple" with "pointer type" and "green object" with "iterator type", and that substitution doesn't produce the result you want to see.

 
> An apple might be a fruit but not all fruits are apples,
 
> i.e.
 
> an iterator might be a pointer but not all pointers are iterators.
 
The concept of a fruit is an abstraction of the concept of an apple,
just as the concept of an iterator is an abstraction of the concept of a
pointer. The category of fruits is a generalization of the category of
apples, just as the category of iterator types is a generalization of
the category of pointer types. As a result, your analogy is precisely
backwards. The correctly constructed analogy is:
 
A pointer might be an iterator, but not all iterators are pointers.
 
Which is also perfectly correct, for precisely the same reason. I can
understand why you wouldn't want to say it that way, but how in the
world can you justify trying to pass off the reverse order as if it were
a proper analogy?
 
...
> and the fact that the Standard itself states that iterators are an
> abstraction/generalization of pointers then you have to accept that a)
> the Standard is inconsistent and b) not all pointers are iterators.
 
 
Null pointers don't disqualify pointers from meeting iterator
requirements. They are examples of singular iterators: "Iterators can
also have singular values that are not associated with any sequence.
Example: After the declaration of an uninitialized pointer x (as with
int* x;), x must always be assumed to have a singular value of a
pointer. — end example ] Results of most expressions are undefined for
singular values ...". (27.2.1p7).
 
You can't pass a null pointer to most standard library functions that
require iterator types, for the same reason that you can't pass any
other kind of singular iterators to them. But that doesn't mean that
there's anything wrong with passing non-null pointers of the same type
to such functions.
 
If you know that something is a pointer type, you know you can safely do
some things with instances of that type which you would not know were
safe if all you knew about it was that it was an iterator type.
Specifically, you can compare null pointers for equality with any other
pointer of the same type, with well-defined behavior, something that is
not the case for singular iterators in general. That doesn't mean that
pointers violate iterator requirements. An iterator type is not
prohibited from having singular values that can be compared for equality.
It's the other way around: an iterator type is allowed to have singular
values that cannot be compared for equality, a very different concept.
 
Note: both of your conclusions are, however, perfectly correct.
a) The standard is inconsistent. This isn't an example of that fact, but
it would be extremely odd if any document as big as the standard were
perfectly consistent.
b) Not all pointers are iterators. Pointers to function types cannot be incremented, and neither can pointers to incomplete object types. Pointers to incomplete object type cannot even be dereferenced. Pointers to function types can be dereferenced, but the result of doing so does not satisfy any of the applicable iterator requirements.
 
However, all pointers to complete object types are iterators. I apologize for the fact that I failed to specify "complete" in my previous statements about this point.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 25 11:06PM +0100

On 25/05/2020 23:00, James Kuyper wrote:
> perfectly consistent.
> b) Not all pointers are iterators. Pointers to function types cannot be incremented, and neither can pointers to incomplete object types. Pointers to incomplete object type cannot even be dereferenced. Pointers to function types can be dereferenced, but the result of doing so does not satisfy any of the applicable iterator requirements.
 
> However, all pointers to complete object types are iterators. I apologize for the fact that I failed to specify "complete" in my previous statements about this point.
 
Wrong, for the following reason:
 
apples are NOT an abstraction or generalization of apples.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 25 11:18PM +0100

On 25/05/2020 23:06, Mr Flibble wrote:
 
>> However, all pointers to complete object types are iterators. I apologize for the fact that I failed to specify "complete" in my previous statements about this point.
 
> Wrong, for the following reason:
 
> apples are NOT an abstraction or generalization of apples.
 
And by that I mean the following is bogus:
 
1) Iterator is an abstraction of pointer
2) Given (1) pointer is an iterator
3) Given (1) and (2) iterator is an abstraction of iterator
 
If you don't think that is bogus then:
 
1) Learn logic
2) Learn fucking English
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Manfred <invalid@add.invalid>: May 26 12:44AM +0200

On 5/26/20 12:18 AM, Mr Flibble wrote:
> On 25/05/2020 23:06, Mr Flibble wrote:
>> On 25/05/2020 23:00, James Kuyper wrote:
 
[...]
 
 
> 1) Iterator is an abstraction of pointer
> 2) Given (1) pointer is an iterator
> 3) Given (1) and (2) iterator is an abstraction of iterator
 
Error: step 3 is wrong because step 2 states that pointer is /an/
iterator (and not all iterators are pointers), thus the correct step 3
becomes:
3) Given (1) and (2) iterator is an abstraction of *a specific type of*
iterator (which a pointer is)
 
Which is a perfecly valid statement
 
 
> If you don't think that is bogus then:
 
> 1) Learn logic
 
In fact logic is not something you can easily mess with.
 
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 25 11:57PM +0100

On 25/05/2020 23:44, Manfred wrote:
 
> Error: step 3 is wrong because step 2 states that pointer is /an/ iterator (and not all iterators are pointers), thus the correct step 3 becomes:
> 3) Given (1) and (2) iterator is an abstraction of *a specific type of* iterator (which a pointer is)
 
> Which is a perfecly valid statement
 
No, it isn't, because it makes no absolutely sense whatsoever to anyone who can correctly comprehend the English language.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Manfred <invalid@add.invalid>: May 26 01:00AM +0200

On 5/26/20 12:57 AM, Mr Flibble wrote:
 
>> Which is a perfecly valid statement
 
> No, it isn't, because it makes no absolutely sense whatsoever to anyone
> who can correctly comprehend the English language.
 
It is a basic example of the "is a" relationship.
 
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 26 12:21AM +0100

On 26/05/2020 00:00, Manfred wrote:
 
>>> Which is a perfecly valid statement
 
>> No, it isn't, because it makes no absolutely sense whatsoever to anyone who can correctly comprehend the English language.
 
> It is a basic example of the "is a" relationship.
 
No, it is, a) meaningless as far as the English language is concerned and b) circular reasoning from the point of view of logic. SELF-REFERENTIAL DEFINITIONS ARE BOGUS (SEE ANY DICTIONARY).
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
"Öö Tiib" <ootiib@hot.ee>: May 25 01:50AM -0700

On Sunday, 24 May 2020 15:45:24 UTC+3, Sam wrote:
 
> const apple &getApple() const & { return fuji; }
 
> apple getApple() && { return fuji; }
> };
 
Indeed, I still do not get your point.
 
The components of composite should not somehow be "maybe
movable away" because the composite is temporary. Move
has to be transfer of ownership regardless if owner is temporary
or not. Neither of "getApple" above is for to move so I do not
understand how it is relevant.
 
> This generally fixes prvalue-caused dangling references. However this fails
> with std::shared_ptr:
 
Shared ownership is tricky topic. In my own code there are two usages of
shared_ptr.
1) Totally and deeply immutable objects are shared to conserve
memory, no data race as there are no write accesses ever.
2) Only one owner, rest are weak references. Such object is typically
itself synchronization measure or its access is protected by such.
 
So I do still not understand what you are doing there. Throw the operators
aside for a sec and try to explain what are the conceptual purposes and
relations between your objects.
Sam <sam@email-scan.com>: May 25 08:37AM -0400

Öö Tiib writes:
 
 
> Indeed, I still do not get your point.
 
> The components of composite should not somehow be "maybe
> movable away" because the composite is temporary. Move
 
But it certainly can. Because, after all, movable can mean "movable into
Never-Never land". The great bit bucket in the sky is one of the possible
destinations of the move. Now, try to wrap your brain around the situation
where the temporary, that implements the member access overloads, is
std::unique_ptr.
 
 
> So I do still not understand what you are doing there. Throw the operators
> aside for a sec and try to explain what are the conceptual purposes and
> relations between your objects.
 
I already did. But focusing the conceptual purposes and relations is getting
off topic.
 
I'm noting that operator. can be made to preserve move semantics, as
demonstrated, but operator-> apparently can't.
"Öö Tiib" <ootiib@hot.ee>: May 25 06:27AM -0700

On Monday, 25 May 2020 15:37:40 UTC+3, Sam wrote:
 
I just copy-paste here that you never addressed:
Other confusing things ...
 
* The operator-> is not meant for returning references. It must return
pointers or (possibly references to) things that are capable to
become a pointer through implicit chain of operator-> calls. On any
case at end of the chain has to be a raw pointer.
 
* Pointers (irrelevant if raw or smart) to whatever references
(rvalue or lvalue) do not make sense in C++ language. Reference is
alias of actual object, not separate object.

* There is unary operator* that is meant for returning references and
so is always overloaded at same time with -> but your code does not.
.
We can return rvalue references to pointed at object like ...:
 
x && getX() { return std::move(*ptr); }
 
... but there we should also deeply consider the consequences if it
is safe and sensible thing to do. If you want to make copyable and
reseatable but not nullable pointers then std::reference_wrapper
is already what can be done in C++.
 
> destinations of the move. Now, try to wrap your brain around the situation
> where the temporary, that implements the member access overloads, is
> std::unique_ptr.
 
Pointers are never to references, pointers are always to objects. That
std::unique_ptr is meant for managing dynamically allocated objects
(and not temporaries that do not need to be programmatically managed).
If the object of std::unique_ptr is itself being temporary or not does
not make any difference since the object that it manages is not
temporary.
 
> off topic.
 
> I'm noting that operator. can be made to preserve move semantics, as
> demonstrated, but operator-> apparently can't.
 
Operator. is not overloadable; operator* is dereference operator and so
should return reference; operator-> is member access operator and so
should return pointer.
Sam <sam@email-scan.com>: May 25 10:48AM -0400

Öö Tiib writes:
 
> On Monday, 25 May 2020 15:37:40 UTC+3, Sam wrote:
 
> I just copy-paste here that you never addressed:
 
Feel free to copy-paste your random musings when you go off-tangent, and
start wandering the countryside looking for someone to argue with. But
that's all that you will accomplish with that: a perfectly-executed
copy/paste.
 
The original question, that was axed, was whether there's a Jedi mind-trick
that allows propagation of ref-overloading with the -> operator; i.e. if the
operator was a &&-qualified overload, so would be the overload in the object
returned by the operator.
 
This is trivially doable with operator*, but not with operator->, apparently.
 
That's all I wanted to know; and I'm now pretty sure that there isn't. It's
just a glitch in the matrix that this is doable with operator*() but not
with operator->(). That's unfortunate, but that's the way it is.
 
Whether you don't think much of the merits of doing this is a slightly
different topic, something that …I'm going to think about someday. But not
today.
 
> Other confusing things ...
 
> * The operator-> is not meant for returning references. It must return
 
I never claimed that they were.
 
> * Pointers (irrelevant if raw or smart) to whatever references
> (rvalue or lvalue) do not make sense in C++ language. Reference is
 
I never claimed that they do. Another thing that doesn't make any sense in
the C++ language is for operator++ to receive an int argument. This also
"irrelevant" to a simple mind. But it does serve a particular, important
purpose.
 
The same principle applies here as well, but if you're interested in
continuing this argument, you're welcome to find a nearby mirror to help you.
Juha Nieminen <nospam@thanks.invalid>: May 25 10:54AM

> in her solution she also sorts pairs, but the pair elements are disjoint
> in memory, which basically just means he has slowed down the most
> expensive step of the algorithm.
 
If you are thinking about cache optimization, if I understood correctly,
the pairs of values are always the a fixed offset from each other, so they
should work with the CPU cache as well as if they were adjacent (because
every access to one element will also access its pair at the fixed
offset.)
Bob Langelaan <bobl0456@gmail.com>: May 24 08:34PM -0700

On Sunday, May 24, 2020 at 12:07:42 PM UTC-7, Chris Vine wrote:
> template definition involved here, then assuming Chain::Node is indeed
> a type alias, in C++11 onwards 'typename' is harmless but redundant.
> With C++98/03 I think it would be an error.
 
I can confirm that Node a nested class defined inside of Chain.
 
I can also confirm that removing typename does not create any additional errors or warnings on the Community version of MS VS 2019. It is possible the code was written for another compiler which required the typename I suppose.
Sam <sam@email-scan.com>: May 24 10:47PM -0400

Chris M. Thomasson writes:
 
 
> https://oeis.org/A059893
 
> using a crude tree process:
 
> v += bit * std::pow(2, i);
 
Are you aware that the above line of code forces your computer to sacrifice
innocent electrons for the sake of performing the following task:
 
1) Convert i from integer to double
 
2) Compute the natural logarithm of 2.0, which is .69314718055994530941, and
then multiply it with the value calculated in step 1.
 
3) Calculate what is 2.71828182845904523536 raised to the power of the value
calculated in step 2.
 
4) Convert the variable "bit" from integer to double
 
5) Multiply the result of step 3 by step 4.
 
6) Convert the result of step 5 back to an integer value, perhaps rounding
it in an unexpected fashion. It's unlikely, but rules of C++ math
pendantically make it possible for 1*pow(2, 8), here, to result in 255
getting added to your "v". Surprise!
 
Was, all of that, your intent here?
 
What makes this so puzzling is that I see the previous line of code
demonstrated the knowledge and the correct use of the >> operator. So why
not, instead of all that, this can't be done as simply as:
 
v += bit * (1UL << i);
?
 
> Can you compile and run this thing?
 
Yes, I can. And I got the same results as you, so what's the next step?
 
> Notice the pattern in the ct (middle) column:
 
> 0, 1, 2, 3, 4, 6, 5, 7, 8, 12, 10, 14, 9, 13, 11, 15, ...
 
Yes, I noticed it. Happy to confirm 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)