David Brown <david.brown@hesbynett.no>: Feb 28 09:59AM +0100
On 27/02/18 23:07, Real Troll wrote:
>> thrd_sleep(&(struct timespec){.tv_sec=1}, NULL); // sleep 1 sec
>> printf("Time: %s", ctime(&(time_t){time(NULL)}));
>> }
Works fine for me with gcc. Did you remember to use "-std=c11", or a
gcc version new enough to have "-std=gnu11" as the default? Did you use
a new enough gcc? (I think 4.9 is needed.) Did you use a library with
the right support (not a Windows gcc version that uses MS's old and
limited C libraries)?
|
Keith Thompson <kst-u@mib.org>: Feb 28 10:03AM -0800
> a new enough gcc? (I think 4.9 is needed.) Did you use a library with
> the right support (not a Windows gcc version that uses MS's old and
> limited C libraries)?
On Linux systems, gcc typically uses GNU libc by default, and GNU
libc doesn't support <threads.h>. Specifying -std=... doesn't help.
I don't think Visual Studio supports it either. (<threads.h> is
optional, so this doesn't mean these implementations are non-conforming
as long as they predefine __STDC_NO_THREADS__.)
On Debian-based systems, you can install an alternative C library,
MUSL, which does support <threads.h>. You have to use a wrapper
called musl-gcc to compile with it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
|
David Brown <david.brown@hesbynett.no>: Feb 28 10:35PM +0100
On 28/02/18 19:03, Keith Thompson wrote:
> On Debian-based systems, you can install an alternative C library,
> MUSL, which does support <threads.h>. You have to use a wrapper
> called musl-gcc to compile with it.
Oh, you are correct. The gcc I tested was using MUSL.
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 07:15AM -0800
On Sunday, February 4, 2018 at 12:28:52 PM UTC-5, [Leigh Johnston pretending
to be Rick C. Hodgin] wrote:
> assembly of the LORD." -- Deuteronomy 23:2
> Jesus Christ was himself illegitimate as his Father was not married to
> the whore Mary.
I came across this today and wanted to address this point. There are various
teachings out there which state something like what you say above, or that
Mary was raped and therefore God is a tyrant and a brute ... but please know
the work that is in play in the world regarding the Bible. It's being targeted
by forces bent on hiding what it teaches, and for a very good reason ... because
it is the word of God and it speaks the truth. Those forces do not want people
to know the truth because the truth WILL set them free:
Begins at 24:56:
https://www.youtube.com/watch?v=tR_7tkC6ZiA&t=24m56s
"The NIV is now owned by (Rupert Murdoch) a secular publishing company.
So it's outside the hands of the Christian community. And as a matter
of fact it's with something called Harper San Francisco, which produces
very very blasphemous books about Jesus Christ saying He was a mystic,
and that His mother was raped and just horrible horrible things..."
-----
The facts:
An angel appeared to Mary to proclaim the good news. Pay special attention
to verse 38 where Mary gives her consent to that which the angel has proclaimed:
https://www.biblegateway.com/passage/?search=Luke+1%3A26-38&version=KJV
26 And in the sixth month the angel Gabriel was sent from God unto a city
of Galilee, named Nazareth,
27 To a virgin espoused to a man whose name was Joseph, of the house of
David; and the virgin's name was Mary.
28 And the angel came in unto her, and said, Hail, thou that art highly
favoured, the Lord is with thee: blessed art thou among women.
29 And when she saw him, she was troubled at his saying, and cast in her
mind what manner of salutation this should be.
==> 30 And the angel said unto her, Fear not, Mary: for thou hast found favour
with God.
31 And, behold, thou shalt conceive in thy womb, and bring forth a son, and
shalt call his name Jesus.
32 He shall be great, and shall be called the Son of the Highest: and the
Lord God shall give unto him the throne of his father David:
33 And he shall reign over the house of Jacob for ever; and of his kingdom
there shall be no end.
34 Then said Mary unto the angel, How shall this be, seeing I know not a man?
35 And the angel answered and said unto her, The Holy Ghost shall come upon
thee, and the power of the Highest shall overshadow thee: therefore also
that holy thing which shall be born of thee shall be called the Son of God.
36 And, behold, thy cousin Elisabeth, she hath also conceived a son in her
old age: and this is the sixth month with her, who was called barren.
37 For with God nothing shall be impossible.
==> 38 And Mary said, Behold the handmaid of the Lord; be it unto me according
to thy word. And the angel departed from her.
This declaration followed a prophesy given by God formerly, one of miraculous
construct, one which would demonstrate that Jesus, born of a virgin truly was
the Son of God, for virgins cannot have children, save by miracles given them
directly by God:
https://www.biblegateway.com/passage/?search=Isaiah+7%3A14&version=KJV
14 Therefore the Lord himself shall give you a sign; Behold, a virgin
shall conceive, and bear a son, and shall call his name Immanuel.
The name "Immanuel" in Hebrew means "God with us":
http://biblehub.com/text/isaiah/7-14.htm
http://biblehub.com/hebrew/6005.htm
-----
The truth is stronger than fiction and lies. It also has the unique trait of
being the only thing that's correct and foundational upon which to build.
If any of you want to know the truth, seek it out. When it comes to finding
God, and knowing who you are, what sin is, who He is, and why you need Him in
your life ... you will find it ... when you seek it with all your heart.
--
Rick C. Hodgin
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 04:27PM
On 28/02/2018 15:15, Rick C. Hodgin wrote:
> If any of you want to know the truth, seek it out. When it comes to finding
> God, and knowing who you are, what sin is, who He is, and why you need Him in
> your life ... you will find it ... when you seek it with all your heart.
Mary giving her consent doesn't change anything regarding Jesus Christ's
legitimacy: Mary was not married to God ergo Jesus Christ is still a
bastard.
But of course as Jesus is also the Father, Jesus fucked himself to give
birth to himself which makes perfect sense and isn't absurd in the
slightest.
#atheism
--
Thank you,
Rick C. Hodgin
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 09:14AM -0800
On Wednesday, February 28, 2018 at 11:27:57 AM UTC-5, Rick C. Hodgin wrote:
> Mary giving her consent doesn't change anything regarding Jesus Christ's
> legitimacy: Mary was not married to God ergo Jesus Christ is still a
> bastard...
I, the real Rick C. Hodgin, did not write this post.
Please examine the headers to see that there is someone usurping my
identity (and without my permission). I post from Eternal September
and Google Groups only.
--
Rick C. Hodgin
PS -- Leigh, you are absolutely disgusting in your vulgarity, a true
servant of Satan's twisting lies perpetrated upon your life. It
is unbecoming for a creation of God to behave as you are choosing.
May God open your eyes to the beautiful creation you are, and lead
you into understanding and repentance for your sin.
|
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 28 11:07AM -0800
On 2/4/2018 9:59 AM, Rick C. Hodgin wrote:
> On 2/4/2018 12:28 PM, Rick C. Hodgin wrote:
>> "No one of illegitimate birth ...
> I, the real Rick C. Hodgin, did not write this post.
We know.
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 11:16AM -0800
On Wednesday, February 28, 2018 at 2:11:27 PM UTC-5, Chris M. Thomasson wrote:
> >> "No one of illegitimate birth ...
> > I, the real Rick C. Hodgin, did not write this post.
> We know.
Blind and non-forward-thinking Chris ... I do not write these messages
for you or the others here who, today, know what's happening in this
group. I write it for the unknowing soul who searches for my name on
Google and arrives at some horrid blasphemy perpetrated against me by
a Class-A coward.
> > Please examine the headers to see that there is someone usurping my
> > identity (and without my permission). I post from Eternal September
> > and Google Groups only.
There is true, foundational wisdom that exists, Chris. Seek it.
--
Rick C. Hodgin
|
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 28 11:55AM -0800
On 2/28/2018 11:16 AM, Rick C. Hodgin wrote:
>>> identity (and without my permission). I post from Eternal September
>>> and Google Groups only.
> There is true, foundational wisdom that exists, Chris. Seek it.
Wow, you really are a nice guy... ;^o
|
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 28 12:35PM -0800
On Wednesday, February 28, 2018 at 2:55:39 PM UTC-5, Chris M. Thomasson wrote:
> Wow, you really are a nice guy... ;^o
You're so... flippant, Chris. Casual about everything. Never considering things
of substance, or seeking out solidity in things. I want to grab you by the ears
and shake you back and forth screaming into your thinking: WAKE UP!! WAKE UP!!
WAKE UP!! But I fear it would do no good. I fear you'll have to go through the
hardest things, being hurt significantly as you go, before you will wisen up.
One of the hardest things for me in this world is to know that no matter how
much I try and teach people the truth, with all the varying ways from simple
instruction to figuratively grabbing people by the ears and shaking them as I
indicated above ... some people will not be saved.
It breaks my heart. It's such a waste. And it's all lost to pride.
--
Rick C. Hodgin
|
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Feb 28 12:40PM -0800
On 2/28/2018 12:35 PM, Rick C. Hodgin wrote:
> and shake you back and forth screaming into your thinking: WAKE UP!! WAKE UP!!
> WAKE UP!! But I fear it would do no good. I fear you'll have to go through the
> hardest things, being hurt significantly as you go, before you will wisen up.
Shi% Just a matter of time?
|
scott@slp53.sl.home (Scott Lurndal): Feb 28 09:34PM
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
It's such a waste. And it's all lost to pride.
Indeed, your Hubris is astonishing.
|
Juha Nieminen <nospam@thanks.invalid>: Feb 28 05:45AM
> whether either of the two ways of doing this was noticeably superior to
> the other. What I've learned is that they're pretty similar for this
> kind of task.
Understanding <iostream> is ok, but be aware that most, if not all,
implementations of it are less efficient than those of <cstdio>.
Even std::istream::read() can be less efficient than std::fread(),
even though logically they do the exact same thing.
|
Melzzzzz <Melzzzzz@zzzzz.com>: Feb 28 05:58AM
> implementations of it are less efficient than those of <cstdio>.
> Even std::istream::read() can be less efficient than std::fread(),
> even though logically they do the exact same thing.
Why?
--
press any key to continue or any other to quit...
|
Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Feb 28 09:23AM +0100
Am 28.02.2018 um 06:45 schrieb Juha Nieminen:
> implementations of it are less efficient than those of <cstdio>.
> Even std::istream::read() can be less efficient than std::fread(),
> even though logically they do the exact same thing.
Another problem with <iostream> is that it does too good a job in hiding
the underlying file handle.
It is fine for basic file IO in simple single-process/single-user
applications, but in "real life" you will quickly run in into situations
where you need more control over the opening mode, need to set runtime
flags like record locks, or need to operate on non-file streams like
sockets. <iostream> can't do that, at least not without re-inventing the
wheel (by writing your own streambuf with it's highly complex and
awkward interface).
|
Ian Collins <ian-news@hotmail.com>: Feb 28 10:17PM +1300
On 02/28/2018 09:23 PM, Hergen Lehmann wrote:
> sockets. <iostream> can't do that, at least not without re-inventing the
> wheel (by writing your own streambuf with it's highly complex and
> awkward interface).
On the contrary, it is a very simple interface... I often use
specialised streambuf implementations as a teaching example. All that
is required for an underflow() override.
--
Ian.
|
Paavo Helde <myfirstname@osa.pri.ee>: Feb 28 12:01PM +0200
On 28.02.2018 7:58, Melzzzzz wrote:
>> Even std::istream::read() can be less efficient than std::fread(),
>> even though logically they do the exact same thing.
> Why?
I just stepped through a std::ifstream::read() in the MSVC++2017
debugger. In addition to an indirection (stream -> readbuf) it calls the
following virtual functions:
virtual streamsize basic_streambuf::xsgetn();
virtual int_type basic_filebuf::uflow();
xsgetn() is called once and uflow() is called when the read buffer gets
empty. So it's not so bad (I have an impression some other std::istream
features involve virtual calls per each character).
Underneath it uses the FILE* infrastructure, but does not use any public
FILE* functions for reading the bulk of the data; instead it uses the
internal read buffer in the FILE structure directly.
In short: std::ifstream::read() is built on top of FILE* mechanism with
some indirections and virtual calls added. As such, it cannot be faster
than fread(); if it is slower depends on a lot of things, most probably
the actual I/O speed will be the bottleneck anyway, but YMMV. And in
another implementation ifstream::read() might be implemented differently.
If the file is in the disk cache then the ifstream::read() overhead
seems to matter to some extent. I made a test reading a 8MB binary file
repeatedly and summing each 128-th byte, the results are (I also added
mmap/MapViewOfFile for curiosity):
istream::read: 3.48344 ms
fread: 2.09826 ms
mmap: 0.990501 ms
Cheers
Paavo
|
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 28 11:16AM
On Wed, 28 Feb 2018 22:17:07 +1300
> On the contrary, it is a very simple interface... I often use
> specialised streambuf implementations as a teaching example. All
> that is required for an underflow() override.
I agree that std::basic_streambuf is a reasonably designed and
simple-ish interface to implement. The bare minimum is to inherit from
std::basic_streambuf and override sync() and overflow() for output and
underflow() for input. If you want the most efficient block reads and
writes which bypass the internal buffers you might also want to
override xsputn() and xsgetn(), and you are also going to have to
override seekoff() and seekpos() if you want to implement seekability
on seekable files (irrelevant for things like sockets of course).
My objection is more having to do it at all for the most common case,
namely when you want to construct a stream object for a pre-opened
file descriptor. I find it surprising that, on unix-like platforms at
least, gcc and clang do not provide built in streambuffers for this.
The built-in streams provided by C++ do not actually enable you to
write a safe temporary file.
So in a unix-like environment you either have to write your own
streambuffer (which is what I have done) or you take the easier route
of using POSIX fdopen() and C streams instead.
Chris
|
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 28 11:36AM
On Wed, 2018-02-28, Ian Collins wrote:
> On the contrary, it is a very simple interface... I often use
> specialised streambuf implementations as a teaching example. All that
> is required for an underflow() override.
You should teach us ... I've spent a lot of time on it, then barely
understood enough to to implement something useful -- and forgotten it
again. The documentation in Stroustrup's book isn't enough, not for
me anyway.
ISTR that James Kanze had a web page on the subject.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
|
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 28 12:32PM
On 28 Feb 2018 11:36:29 GMT
> again. The documentation in Stroustrup's book isn't enough, not for
> me anyway.
> ISTR that James Kanze had a web page on the subject.
Josuttis's "The C++ Standard Library" gives an introduction and sample
implementation, which isn't bad (or at least the first edition does, I
don't have the second).
|
Melzzzzz <Melzzzzz@zzzzz.com>: Feb 28 12:52PM
> istream::read: 3.48344 ms
> fread: 2.09826 ms
> mmap: 0.990501 ms
Heh, I always use fstream/sstream, didn't know that this is that slower
;)
I even implemented simple database exclusivelly with fstream ;p
And parsing strings , I don't like snprintf/sscanf at all ;)
--
press any key to continue or any other to quit...
|
Paavo Helde <myfirstname@osa.pri.ee>: Feb 28 04:15PM +0200
On 28.02.2018 14:52, Melzzzzz wrote:
> Heh, I always use fstream/sstream, didn't know that this is that slower
> ;)
> I even implemented simple database exclusivelly with fstream ;p
Depends on the usage. If the file is not in the OS disk cache the
timings would probably be much longer and more equal. Also, whenever the
program does something more substantial with the file content then it
also does not matter if there is a millisecond lost somewhere.
> And parsing strings , I don't like snprintf/sscanf at all ;)
snprintf,sscanf et al are locale sensitive, meaning that a substantial
part of their work is spent on setting up and locking the global locale.
This can become significant in a massively multithreaded app. At least
C++ streams have the imbue() functionality for binding a non-global
locale which ought to remove this particular bottleneck.
Of course, if locale dependency is not needed at all, like when parsing
source code of a typical programming language, the most performing way
is to use special functions with built-in ASCII/C-locale behavior. But
again, all this matters only if the speed is important at that point.
|
