lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Parallel blues


From: Vadim Zeitlin
Subject: Re: [lmi] Parallel blues
Date: Tue, 17 Aug 2021 01:23:19 +0200

On Mon, 16 Aug 2021 21:41:00 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2021-08-09 14:25, Vadim Zeitlin wrote:
GC> > On Sat, 7 Aug 2021 23:18:50 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:
GC> > 
GC> > GC> On 2017-06-20 17:09, Vadim Zeitlin wrote:
[...]
GC> >  I did read this message when you made this commit and decided that I
GC> > needed to return to it later, because I didn't fully understand the 
problem
GC> > on first reading. Unfortunately after rereading it again now, I still 
don't
GC> > quite understand it: what exactly is the peril that it is talking about?
GC> > Is it the one demonstrated by 048b2cc9d (Demonstrate a peril, 2021-08-04)?
GC> 
GC> Yes, exactly.

 Thanks for confirming this.

GC> > If so, couldn't we just outlaw changing null stream rdbuf in lmi code? Or
GC> > do we actually need to do it sometimes?
GC> 
GC> We can't outlaw it: we actually do need it sometimes.

 I hadn't realized it, sorry.

 So now that I know we have to do it, my short (because I feel like you
would probably appreciate it more than a long one right now) answer is:

GC> > GC> Otherwise, I fear I've painted myself into a corner, out of which I 
was
GC> > GC> hoping I could teleport without leaving a real problem behind. I 
suppose
GC> > GC> this could be resolved by overloading:
GC> > GC> 
GC> > GC> - void foo(int arg0, double arg1, std::ostream& os=null_stream()) 
{...}
GC> > GC> 
GC> > GC> + void foo(int arg0, double arg1, std::ostream& os) {...}
GC> > GC> + void foo(int arg0, double arg1)
GC> > GC> + {
GC> > GC> +     std::ostream os(&null_streambuf());
GC> > GC> +     os.setstate(std::ios::badbit);
GC> > GC> +     foo(arg0, arg1, os);
GC> > GC> + }
GC> > GC> 
GC> > GC> That's only somewhat ugly. I like it better than
GC> > GC> 
GC> > GC> - void foo(int arg0, double arg1, std::ostream& os=null_stream()) 
{...}
GC> > GC> + void foo(int arg0, double arg1, std::ostream* os=nullptr)
GC> > GC> + {
GC> > GC> +     if(nullptr == os)
GC> > GC> +         {
GC> > GC> +         std::ostream ephemeral_os(&null_streambuf());
GC> > GC> +         ephemeral_os.setstate(std::ios::badbit);
GC> > GC> +         os = &ephemeral_os;
GC> > GC> +         }
GC> > GC> + }
GC> > GC> 
GC> > GC> What do you think?
[...]
GC> For the long term, maybe std::format or <syncstream> is the answer.
GC> For the short term, there's no problem to fix, because lmi isn't
GC> using multiple threads. My only question is whether or not I should
GC> implement the simple overloading solution, above, at this time.
GC> I tend to favor doing that anyway because it's fresh in my mind.
GC> But do you see any reason not to proceed that way?

 No, I don't see any problems with doing it like this and I agree that the
first version is better.

VZ

Attachment: pgpkRejcN3yMk.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]