Friday, October 30, 2020

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

David Brown <david.brown@hesbynett.no>: Oct 30 11:34AM +0100

On 29/10/2020 17:55, olcott wrote:
> Because I have no experience writing academic journal quality papers and
> most poorly written papers tend to be rejected out-of-hand without
> review I must go through several levels of review.
 
You are not getting any reviews here, nor any help towards learning how
to write academic papers. If you had invented a new way of raising
sheep, would you talk to a farmer, or would you insist on taking your
sheep to McDonald's every day? All you achieve is people yelling at you
to get out, and that is /not/ helpful.
 
 
> If I don't do this I simply blow my credibility with the academicians so
> that no one ever bothers to pay enough attention to see that I was right
> all along.
 
Certainly any credibility to you had in Usenet groups is blown.
 
Please re-read the advice I gave you. It is /real/ advice - intended to
be useful. I am not suggesting you send your paper to an academic
journal - I am suggesting you talk to some academics at a university.
Maybe you should take a course or two.
 
>> extraordinary evidence.  You can't present such evidence in this medium.
 
> For all people that know the material very well and are paying very
> close attention I have already totally proved my point.
 
That's not the impression I get from people who have tried to give you
replies. But be that as it may - if you have a proof of your point,
write it up and put it on a blog. Let people read and comment on the
paper. Based on that, re-write it as needed until you have something
you are happy to show to academics or journals. That way you make some
progress - rather than just irritating everyone else and frustrating
yourself.
 
 
> The input to the halt decider cannot possibly do the opposite of
> whatever the halt decider decides because the very first step of the
> halting decision is to terminate the execution of its input.
 
Write a proper paper (to the best of your abilities and experience), and
put it on a blog. Usenet is /not/ the right medium for this kind of
thing. And even if it were, these groups are not the right audience for
it. No C, C++ or Prolog programmers cares about the "halting problem"
or "halt deciders". How is that so hard to comprehend?
 
ijw wij <wyniijj@gmail.com>: Oct 30 03:50PM -0700

David Brown 在 2020年10月30日 星期五下午6:35:08 [UTC+8] 的信中寫道：
> >> comp.theory, and work from there.
 
> >> But /please/ stop cross-posting. It does not help you in any way, and
> >> it most certainly irritates other people.
 
IMOH, a halting deciding algorithm should interest (nearly)every programmer
and mathematician. The problem with what olcott said is that I, probably along
with others, do not understand what was really told while the algorithm should
be easy to explain if possible. Not to say it could be implemented in few days.
 
Saying so is because I had just posted a very unpoular question "1/∞!=0..." like
olcott's post, immediately got enough down vote to deleting it.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 30 08:01AM +0100

Can anyone tell me why the above prototype has a rvalue ([*]) "input"
but the state if input isn't moved away ? And why I can pass a lvalue
basic_istream<...> here (VC++2019) in C++17-mode ?
 
[*] https://en.cppreference.com/w/cpp/string/basic_string/getline
Bonita Montero <Bonita.Montero@gmail.com>: Oct 30 09:30AM +0100

Am 30.10.2020 um 08:01 schrieb Bonita Montero:
> [*] https://en.cppreference.com/w/cpp/string/basic_string/getline
 
I think my code works because the old version isn't deprecated.
But for what is the version with the rvalue-"input" good ?
Bonita Montero <Bonita.Montero@gmail.com>: Oct 30 10:01AM +0100

>> [*] https://en.cppreference.com/w/cpp/string/basic_string/getline
 
> I think my code works because the old version isn't deprecated.
> But for what is the version with the rvalue-"input" good ?
 
Maybe it's good for accepting temporaries. But what kind
of temporaries should this be ? One-shot ifstreams ???
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 30 10:10AM

On Fri, 30 Oct 2020 08:01:35 +0100
> but the state if input isn't moved away ? And why I can pass a lvalue
> basic_istream<...> here (VC++2019) in C++17-mode ?
 
> [*] https://en.cppreference.com/w/cpp/string/basic_string/getline
 
The overload taking a lvalue reference is (for good reason) not const
so it cannot take a rvalue reference. The overload taking a rvalue
reference is presumably there in order to fill that gap.
 
Why would anyone want to pass a temporary to std::getline? Dunno, it
seems somewhat improbable. Probably it is there just for the purposes
of symmetry.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 30 11:45AM +0100

On 30.10.2020 08:01, Bonita Montero wrote:
> but the  state if input isn't moved away ? And why I can pass a lvalue
> basic_istream<...> here (VC++2019) in C++17-mode ?
 
> [*] https://en.cppreference.com/w/cpp/string/basic_string/getline
 
You can do things like
 
getline( istringstream( poem ), first_line );
 
But I don't know if that's the rationale.
 
It seems a little weird to me.
 
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Oct 30 05:58AM -0700

On Friday, 30 October 2020 09:01:54 UTC+2, Bonita Montero wrote:
> but the state if input isn't moved away ? And why I can pass a lvalue
> basic_istream<...> here (VC++2019) in C++17-mode ?
 
> [*] https://en.cppreference.com/w/cpp/string/basic_string/getline
 
Read up on "perfect forwarding". Basically, since it is template these
are not rvalue references but universal references.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 30 01:15PM

On Fri, 30 Oct 2020 05:58:47 -0700 (PDT)
 
> > [*] https://en.cppreference.com/w/cpp/string/basic_string/getline
 
> Read up on "perfect forwarding". Basically, since it is template these
> are not rvalue references but universal references.
 
They 'input' argument of std::getline is not taken by universal
reference. If it were, the lvalue reference and rvalue reference
overloads would be unnecessary.
 
The non-const argument 'std::basic_istream<CharT,Traits>& input' takes
an lvalue only. The argument 'std::basic_istream<CharT,Traits>&& input'
takes a rvalue only. The argument 'std::basic_string<CharT, Traits,
Allocator>& str' is an out parameter which takes a lvalue only.
 
Given a template type T, an argument 'T&& t' represents a universal (aka
forwarding) reference. That is not the case here.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 30 01:44PM

On Fri, 30 Oct 2020 13:15:27 +0000
> Given a template type T, an argument 'T&& t' represents a universal (aka
> forwarding) reference. That is not the case here.
 
Perhaps I should add for any learners that this only applies if T is a
deduced type. So (2) below does not represent a forwarding reference:
 
template <class T> struct S {
 
template <class U>
void do_it1(U&& u) { ... } // (1) forwarding reference
 
void do_it2(T&& t) { ... } // (2) rvalue reference
 
template <class U>
void do_it3(std::list<U>&& l) { ... } // (3) rvalue reference
 
void do_it4(std::list<T>&& l) { ... } // (4) rvalue reference
 
};
"Öö Tiib" <ootiib@hot.ee>: Oct 30 11:02AM -0700

On Friday, 30 October 2020 15:44:50 UTC+2, Chris Vine wrote:
> void do_it3(std::list<U>&& l) { ... } // (3) rvalue reference
 
> void do_it4(std::list<T>&& l) { ... } // (4) rvalue reference
 
> };
 
OK, I apparently mixed it up, mea culpa. Thanks for clarifying.
red floyd <no.spam.here@its.invalid>: Oct 30 11:44AM -0700

On 10/30/2020 3:10 AM, Chris Vine wrote:
 
> Why would anyone want to pass a temporary to std::getline? Dunno, it
> seems somewhat improbable. Probably it is there just for the purposes
> of symmetry.
 
maybe for this:
 
std::getline(std:istringstream("some text ...."), ...);
Bonita Montero <Bonita.Montero@gmail.com>: Oct 30 08:11PM +0100

Am 30.10.2020 um 19:44 schrieb red floyd:
> maybe for this:
> std::getline(std:istringstream("some text ...."), ...);
 
std::getline( std::istringstream( "some text" ), str );
is the same as
str = "some text";
So there's no need for this pattern.
red floyd <no.spam@its.invalid>: Oct 30 02:50PM -0700

On 10/30/20 12:11 PM, Bonita Montero wrote:
> is the same as
> str = "some text";
> So there's no need for this pattern.
 
Fine.
 
std::string some_text; // may have new lines
std::string str;
 
std::getline(some_text, str);
red floyd <no.spam@its.invalid>: Oct 30 02:50PM -0700

On 10/30/20 2:50 PM, red floyd wrote:
 
> std::string some_text; // may have new lines
> std::string str;
 
> std::getline(some_text, str);
 
That's
 
std::getline(std::istringstream(some_text), str);
David Brown <david.brown@hesbynett.no>: Oct 30 11:02AM +0100

On 29/10/2020 19:55, Mike Terry wrote:
> TrollPoster post from such a long time ago that it's not recorded in my
> local newsreader.  (Neither of these is down to posters using poor
> newsreaders.)
 
The cause of this is not a problem with newsreaders - it is a problem
with Olcott. Roughly speaking (assuming I understand it myself), it
goes like this.
 
First, he makes a cross-posting to several off-topic groups. Then
someone tries to be helpful by replying to him with these extra groups
removed, leaving only comp.theory (this is normally the correct way to
handle bad cross-posting). But when Olcott replies again, he adds the
off-topic groups once more. As far as anyone (or any newsreader)
viewing these other groups is concerned, that reply from Olcott has come
from nowwhere - it is not a reply to anything in the group, and it
therefore counts as a new thread.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Oct 30 10:52AM


> On 29/10/2020 19:55, Mike Terry wrote:
>> On 29/10/2020 18:20, Manfred wrote:
>>> On 10/29/2020 4:17 PM, Mike Terry wrote:
<cut>
 
>>> The problem is that some repliers use poor newsreaders that break thread
>>> ID consistency, and their replies manage to get through the "ignore
>>> subthread" killfile directive.
<cut>
>> Interesting - I'm not familiar with that problem.  Perhaps you give me a
>> couple of recent examples of such responses, and the newsgroup where
>> you're seeing them?  (msgid values would be enough)
<cut>
> viewing these other groups is concerned, that reply from Olcott has come
> from nowwhere - it is not a reply to anything in the group, and it
> therefore counts as a new thread.
 
That is a problem with newsreaders. They should be able to see that
these "replies from nowhere" are indeed all in one thread -- a thread
that simply has some missing posts. This was normal in the old days
with slow and sometimes unreliable feeds, and old newsreaders can
usually fill in a thread as posts arrive, and happily work with threads
that are sparse. They should be able to do this even in when the
subject header gets edited. Maybe some newer ones can't?
 
--
Ben.
Ralf Goertz <me@myprovider.invalid>: Oct 30 12:55PM +0100

Am Fri, 30 Oct 2020 11:02:08 +0100
> viewing these other groups is concerned, that reply from Olcott has
> come from nowwhere - it is not a reply to anything in the group, and
> it therefore counts as a new thread.
 
But usually there are many references in the header of a deep thread
message. In yours for instance they are:
 
References: <4o2dnVXM88fR6AXCnZ2dnUU7-K3NnZ2d@giganews.com>
<rneee3$d0j$2@solani.org> <1bd011ccls.fsf@pfeifferfamily.net>
<3c6dndQ5KJWQQAfCnZ2dnUU78InNnZ2d@brightview.co.uk>
<rnf161$m68$1@gioia.aioe.org>
<x_idnannRP6KjQbCnZ2dnUU78I3NnZ2d@brightview.co.uk>
 
The last of these is the one you replied to and is also mentioned in the
<In-Reply-To:> field. Maybe it's just that some newsreaders only care
about this field and therefore are unable to put the message in context
when it is absent in that group.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 30 07:47PM

On Fri, 2020-10-30, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
...
> usually fill in a thread as posts arrive, and happily work with threads
> that are sparse. They should be able to do this even in when the
> subject header gets edited.
 
Yes. It's simple: the References: header has[1] an incomplete list of
postings on the path back to the original. Given a set of postings
(with Message-Id and References headers) you can build a set of trees,
with gaps if necessary.
 
The hardest part may be protecting yourself from malicious postings
which try to form a non-tree DAG, or introduce cycles, or something.
 
> Maybe some newer ones can't?
 
/Jorgen
 
[1] From memory. The RFC would tell.
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Leo <usenet@gkbrk.com>: Oct 30 12:27PM +0300

On 10/29/20 11:30 PM, Mr Flibble wrote:
> troll (so stop feeding it) or batshit crazy (so arguing is pointless).
 
> Please just stop replying to his posts.
 
> /Flibble
 
As with all the other nonsensical people on Usenet, add to killfile and
move on.
Brian Wood <woodbrian77@gmail.com>: Oct 29 11:12PM -0700

On Thursday, October 29, 2020 at 12:40:07 PM UTC-5, Bonita Montero wrote:
> The language isn't irrational. The choice for one of the variants isn't
> also irrational. Irrational is to advocate to one variant if it is the
> the only on logical.
 
The merits of east const have been presented in the links
posted previously. At least a few people are persuaded.
Probably there are others who haven't joined the list, but
that are likewise convinced.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 30 07:23AM +0100

> posted previously. At least a few people are persuaded.
> Probably there are others who haven't joined the list, but
> that are likewise convinced.
 
Programmers should be able to read both without any aversions.
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)