Friday, May 11, 2018

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

woodbrian77@gmail.com: May 11 11:34AM -0700

In this talk:
https://www.reddit.com/r/cpp/comments/8ghtom/andrei_alexandrescu_expected_the_expected_cpp/
 
Andrei Alexandrescu says he thinks std::optional is
the worst thing to happen to humanity. I have a lower
opinion of std::any than std::optional. If you were
banished to an island with just a few active volcanoes,
and could only have one of these, which one would it be?
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
https://github.com/Ebenezer-group/onwards
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 11 11:47PM +0100


> Brian
> Ebenezer Enterprises - Enjoying programming again.
> https://github.com/Ebenezer-group/onwards
 
So what? Alexandrescu has become less relevant as a C++ "authority" in
recent times. std::optional is great IMO and certainly has more utility
than std::any which I hardly ever use. Sometimes you want type erasure
but most of the time you don't.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne 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."
boltar@cylonHQ.com: May 11 09:27AM

On Thu, 10 May 2018 12:45:58 -0700 (PDT)
>> ...
 
>What do you find that pthreads does for you that is not comparably
>straightforward using std::thread, etc?
 
I gave up using threads a long time back and went back to multiprocess, but
off the top of my head there is no equivalent of pthread_get/setspecific, there
can be issues with C libraries that use pthreads and (a minor point), you can't
use a c++ mutex in shared memory.
Paavo Helde <myfirstname@osa.pri.ee>: May 11 04:49PM +0300

>> straightforward using std::thread, etc?
 
> I gave up using threads a long time back and went back to multiprocess, but
> off the top of my head there is no equivalent of pthread_get/setspecific, there
 
Is this the same as thread_local variables? FYI, thread_local is a C++
keyword since 2011.
Jorgen Grahn <grahn+nntp@snipabacken.se>: May 11 03:25PM

> pthread_get/setspecific, there can be issues with C libraries that
> use pthreads and (a minor point), you can't use a c++ mutex in
> shared memory.
 
Although it doesn't fall under "a lot to be desired". there's always
good old inertia. People tend to be familiar with pthreads, have
documentation and books that cover it, they may be using it in C, and
so on. And cross-platform aspects aren't relevant to most software.
 
For these kinds of reasons, I'm no big fan of pulling system-specific
stuff in under the language umbrella. (I'd be more inclined to use the
higher-level concurrency stuff in C++11.)
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
woodbrian77@gmail.com: May 11 10:39AM -0700

On Friday, May 11, 2018 at 10:25:29 AM UTC-5, Jorgen Grahn wrote:
 
> For these kinds of reasons, I'm no big fan of pulling system-specific
> stuff in under the language umbrella. (I'd be more inclined to use the
> higher-level concurrency stuff in C++11.)
 
There's no shortage of stuff for std::junkpile. Some of it
gets used for awhile, but then is discarded.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
legalize+jeeves@mail.xmission.com (Richard): May 10 08:12PM

[Please do not mail me a copy of your followup]
 
Peng Yu <pengyu.ut@gmail.com> spake the secret code
> }
 
>The relevant functions are the following. But I don't see which C++ I/O
>function can not be used with stdin. Does anybody see? Thanks.
 
They probably just didn't understand how to deal with the fact that
istream's are not copyable. In this situation, the easiest solution
is to use a pointer:
 
{
std::ifstream ifs;
std::istream *input = nullptr;
if (args_->input == "-")
{
input = &std::cin;
}
else
{
ifs.open(args_->input);
input = &ifs;
}
dict_->readFromFile(*input);
}
 
(If we stick the ifstream in a local scope with {}'s we don't need to
explicitly close it and worry about someone using it later in the
function.)
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 10 10:36PM +0200

On 10.05.2018 22:12, Richard wrote:
 
> (If we stick the ifstream in a local scope with {}'s we don't need to
> explicitly close it and worry about someone using it later in the
> function.)
 
I don't understand the need for pointer?
 
if( args_->input == "-" )
{
dict_->readFromFile( std::cin );
}
else
{
std::ifstream f{ args_->input };
if( f.fail() ) { throw "Baluba!"; }
dict_->readFromFile( f );
}
 
Cheers!,
 
- Alf
legalize+jeeves@mail.xmission.com (Richard): May 10 08:52PM

[Please do not mail me a copy of your followup]
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
> if( f.fail() ) { throw "Baluba!"; }
> dict_->readFromFile( f );
> }
 
One cat, two ways to skin it :-).
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Sam <sam@email-scan.com>: May 11 06:47AM -0400

Peng Yu writes:
 
> }
 
> The relevant functions are the following. But I don't see which C++ I/O
> function can not be used with stdin. Does anybody see? Thanks.
 
For starters, stdin is a C library object. But that's neither here nor
there, since std::cin is C++ library's equivalent, that's available to be
used.
 
There must be some particular why this program cannot make use of std::cin,
and requires an actual file to be specified. You will have to figure out
what it is by reading the rest of the code and trying to understand it.
There could be many reasons. Perhaps the code requires a writable file, and
uses std::iostream, and std::istream, which is all that std::cin is, will
not be acceptable. Perhaps the code requires a seekable std::ifstream, and
the non-seekable std::istream will not work.
 
Or maybe one of several other, similar, reasons. You will need to read the
code and figure it out, if you want to.
Ben Bacarisse <ben.usenet@bsb.me.uk>: May 11 01:33PM +0100

>> }
 
>> The relevant functions are the following. But I don't see which C++
>> I/O function can not be used with stdin. Does anybody see? Thanks.
 
<snip>
> ... There could be many reasons. Perhaps the code requires
> a writable file, and uses std::iostream, and std::istream, which is
> all that std::cin is, will not be acceptable.
 
That seems unlikely since the code reads the data by calling a function
that takes a std::istream& argument.
 
<snip>
--
Ben.
Jorgen Grahn <grahn+nntp@snipabacken.se>: May 11 02:43PM

On Fri, 2018-05-11, Ben Bacarisse wrote:
>> all that std::cin is, will not be acceptable.
 
> That seems unlikely since the code reads the data by calling a function
> that takes a std::istream& argument.
 
Seems likely that it's a bug, then. I had a quick look at the code,
and my impression was that the authors had focused on the linguistics
algorithms (as researchers tend to do) and not so much on the user
interface.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Paavo Helde <myfirstname@osa.pri.ee>: May 11 06:47PM +0300

On 10.05.2018 22:51, Peng Yu wrote:
> throw std::invalid_argument("Cannot use stdin for training!");
> }
 
> The relevant functions are the following. But I don't see which C++ I/O function can not be used with stdin. Does anybody see? Thanks.
 
Maybe the program is interactive, at least in the mentioned "training
mode", and expects interactive commands from std::cin.
Bo Persson <bop@gmb.dk>: May 10 05:49PM +0200

> I don't use std-library, most of my codes are 'home-made', only few are
> using std:: things (std::terminate(), std::numeric_limits, <typeinfo> )
> So is it doable? Any sugestion will be appreciated.
 
Before putting too much work into this, you might want to check what
your compiler does by default.
 
For example, the compiler I'm using does this:
 
 
void* __CRTDECL operator new(size_t const size)
{
for (;;)
{
if (void* const block = malloc(size))
{
return block;
}
 
if (_callnewh(size) == 0)
{
if (size == SIZE_MAX)
{
__scrt_throw_std_bad_array_new_length();
}
else
{
__scrt_throw_std_bad_alloc();
}
}
 
// The new handler was successful; try to allocate again...
}
}
 
 
 
 
Bo Persson
wyniijj@gmail.com: May 11 06:44AM -0700

Alf P. Steinbach於 2018年5月10日星期四 UTC+8下午11時12分18秒寫道：
 
> > An application example is to implement 'new *this'.
 
> That's not valid C++ syntax.
 
> So, it's not really an example of anything.
 
I think the related 'clone()' problem had been an topic long long ago.
Probably it's just a quick though flashed in my brain.
 
 
> I would suggest not doing this. ;-)
 
> Cheers!,
 
> - Alf
 
pretty encouraging!
wyniijj@gmail.com: May 11 06:56AM -0700

Bo Persson於 2018年5月10日星期四 UTC+8下午11時49分51秒寫道：
> }
> }
 
> Bo Persson
 
Thanks for the example, helpful to know C's malloc can implement new.
 
Probable I had used a wrong word (reimplement new).
Paavo Helde <myfirstname@osa.pri.ee>: May 11 06:42PM +0300


>> So, it's not really an example of anything.
 
> I think the related 'clone()' problem had been an topic long long ago.
> Probably it's just a quick though flashed in my brain.
 
The cloning issue should become nicely resolved by the metaclasses
proposal, but I'm told this is still far away.
 
Anyway, I don't see how malloc would help in any way with cloning.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 10 09:29PM +0100

On 09/05/2018 22:32, Richard wrote:
> - std::launder()
> - Pack expansions in using declarations
 
> There's a second feature table for the standard library.
 
Good luck avoiding the std::auto_ptr shit storm.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne 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."
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)