Monday, January 4, 2021

Digest for comp.lang.c++@googlegroups.com - 25 updates in 6 topics

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 29 09:46PM -0800

On 12/29/2020 6:26 AM, Rick C. Hodgin wrote:
> On 12/29/20 2:21 AM, Juha Nieminen wrote:
>> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
[...]
> You're missing the point.  Jesus is saying that our righteousness does
> not come from us, but from Him.  [...]
 
Are you real? Our merely a projection of your God?
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 30 06:31PM -0500

On 12/30/20 5:20 PM, Ian Collins wrote:
 
> https://www.smithsonianmag.com/science-nature/dinosaur-shocker-115306469/
> https://biologos.org/articles/soft-tissue-in-dinosaur-bones-what-does-the-evidence-really-say
> https://letterstocreationists.wordpress.com/dinosaur-soft-tissue/
 
It's not debunked. It's damaged controlled. They've made over 80
separate finds now that people started looking for soft tissue.
 
There's a war on for your mind. If you'll seek and follow the truth,
you'll see the truth because Jesus is truth and He'll come to you
teaching you all things you're able to receive.
 
--
Rick C. Hodgin
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 29 09:31PM -0800

On 12/29/2020 9:30 PM, Chris M. Thomasson wrote:
>> you're getting some one up on me, which you aren't.
 
>> Satan's deceiving you,
 
> You as a Human thinks that... But Satan is brutally deceiving you! ;^)
 
God is infinite. Only the Devil makes you think of finite wrt GOD!
 
;^)
 
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 29 10:50PM -0800

On 12/25/2020 7:06 AM, Rick C. Hodgin wrote:
> sin, and enter in to eternal life literally beginning today.
 
> Do you have sin?  You need a Savior.  Jesus is that one you need.
 
> Peace and love, in Jesus Christ.  Amen.
 
God Manifesting Itself:
 
 
https://youtu.be/SIxi2uqFVmc
 
;^)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 30 01:40PM -0500

On 12/30/20 5:12 AM, Anton Shepelev wrote:
>> Many have forgotten the true meaning of CHRISTmas.
> That is true. First they started to distort it as X-mas,
> then to avoid the term altogether...
 
I used to be one of them. I used to say "Happy Christmas" and write
down XMAS. Also Turkey Day and things like that. As I've drawn close
to Jesus, I see what those transformations are -- a way for the enemy of
God to assert his guidance to not have Thanksgiving, and not remember
Christ, and all that goes with it, in our societies.
 
People will always hear a Merry Christmas from me, and a Happy Thanksgiving.
 
>> Thanks to Jesus: "Oh death, where is thy sting?"
> The invocative particle is O, not Oh.
 
:-) My bad. Thank you.
 
> A Mickle Merry Christmas to you and everyone!
 
A Mickle Merry Christmas to you as well!
 
--
Rick C. Hodgin
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Dec 30 10:27PM

On 30/12/2020 20:46, Rick C. Hodgin wrote:
>>> Probably very few before.
 
>> Fossils exist.  They were laid down millions of years ago.  No credible scientist denies this.
 
> Scientists are now discovering soft tissue inside bones they allege are 65M years old.  Blood vessels.  Blood cells.  Some cells have various components still in tact.
 
FOREIGN CONTAMINATION UNRELATED TO THE FOSSIL ITSELF.
 
Fossils are not bones, fossils are mineral deposits (stone) and in the case of dinosaur fossils have been dated to millions of years old using radiometric dating.
 
/Flibble
 
--
😎
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 29 09:24PM -0800

On 12/29/2020 4:16 PM, Rick C. Hodgin wrote:
> information about your vaccinations embedded within it.
 
> I don't know.  Something's coming.  Something major will happen in
> January, 2021.  That's my prediction.  What it is?  I don't know. [...]
 
If it is the rapture, you will suddenly stop posting right?
Ian Collins <ian-news@hotmail.com>: Dec 31 09:09AM +1300

On 31/12/2020 07:50, Rick C. Hodgin wrote:
>> matter what contrary evidence! Isn't that right Rick?
 
> Fossils exist. They were laid down in the flood mostly. Some after.
> Probably very few before.
 
Fossils exist. They were laid down millions of years ago. No credible
scientist denies this.
 
Open your eyes to the truth, look beyond your blinkered superstition and
crackpot YouTube videos.
 
Happy coding in 2021
--
Ian.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 29 07:28PM -0500

On 12/29/20 7:16 PM, Rick C. Hodgin wrote:
> On 12/29/20 5:51 PM, Bo Persson wrote:
>> [snip...]wiki/Predictions_and_claims_for_the_Second_Coming_of_Christ
 
> My January 2021 prediction is the Rapture.
 
Should read "is NOT the Rapture."
^^^
 
 
--
Rick C. Hodgin
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 01 04:50PM -0800

On 1/1/2021 7:45 AM, Rick C. Hodgin wrote:
> Happy 2021 to everyone.  2020 brought much drama and stress.  May 2021
> bring peace.
[...]
 
Happy New Year. :^)
Thomas Koenig <tkoenig@netcologne.de>: Jan 01 04:01PM


> And Satan invented fossils, yes?
 
According to some, he invented fossil fuels, at least.
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Jan 01 03:47PM

On 01/01/2021 15:45, Rick C. Hodgin wrote:
[snip - tl;dr]
 
And Satan invented fossils, yes?
 
/Flibble
 
--
😎
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 01 10:45AM -0500

Happy 2021 to everyone. 2020 brought much drama and stress. May 2021
bring peace.
 
<3 :) <((><
:) <3 <((><
 
-----
[Jesus Loves You]
 
I've reading back through the book of Exodus these past days, after
having begun again through Genesis before that. I noted a few things
this morning:
 
It was in the ancient Hebrew calendar month of Abib that Moses, led by
God, led the people out of Egypt, and the Egyptians were destroyed in
the Red Sea (Exodus 13:4).
 
The Red Sea has been likened to the blood of Christ, and that through
the Red Sea we gain salvation from our enemies, and witness their
destruction. The red blood, the read sea. The red sea closing back up
on the Egyptians who were bent on destroying the children of Israel
(Exodus 14:27-28).
 
It's the month of Abib I found interesting.
 
On our modern calendar, the month of Abib in 2021 would be the
March-April time frame, and modern / current month of Nisan. It is
indicated in scripture that the children of Israel were to observe the
first Passover, which was in this month beginning on the 14th day, and
proceeding seven days through to the 21st.
 
On that night, at midnight, the Lord sent His angel through to kill all
the firstborn in Egypt, and it was after this that Pharaoh let the
children of Israel go. Pharaoh summoned Moses by night (Exodus 12:31)
and instructed them to leave! To get out! So the Exodus would've begun
on the 22nd.
 
The ancient month of Abib, current month of Nisan, occurs in 2021 in
March through April. Passover begins on March 28, and the last day of
Passover is April 4.
 
Given all that's happening in our world, given the age of Israel (since
May 14, 1948), given the coming seven-year great tribulation, given that
Israel's government is in limbo, given the pronouncement in December
that the U.S. military and intelligence agencies have a maximum of 180
days to hand over everything they know about aliens, given the fact that
our election is in dispute (and our presidency may go into limbo for a
time before the courts and Congress and whatever other issues there are
resolve it as President Trump believes solidly the election was stolen
by fraud and evil forces at work against truth), and given the fact it
will take some time between the Rapture and the start of the seven-year
tribulation ... it's looking like there is a definite season of the
Rapture coming up.
 
No one knows the day or hour, and this season may not be the correct
one. How many people have predicted dates that have come and gone?
Still, we are commanded to be watchmen, to keep our eyes peeled, to
always be looking for the season, which Jesus said we would know.
 
Once again many signs aligning. This trek out of Egypt occurring at
this time of the year, aligning with world events today, is interesting.
It piques the curiosity and brings some resolution and focus online.
 
-----
Peace to each of you in 2021. The time to come to Jesus is now.
Whether the rapture comes or not, none of us are promised tomorrow.
Today is the day of our salvation. Ask Jesus to forgive your sin, and
enter in to eternal life today, right now even.
 
Peace.
 
--
Rick C. Hodgin
Bonita Montero <Bonita.Montero@gmail.com>: Jan 01 08:35PM +0100

>> CPU cycles and needlessly slows the program down.
 
> std::array is no less efficient in this situation.
> The bounds checking is a compile time operation.
 
Bounds-checking can be compile-time only if the index is a constant.
Ian Collins <ian-news@hotmail.com>: Jan 02 08:21AM +1300

> and could be in a tight loop where performance matters. Constantly doing
> bounds checking on a fixed size array in this situation is a waste of
> CPU cycles and needlessly slows the program down.
 
std::array is no less efficient in this situation. The bounds checking
is a compile time operation.
 
--
Ian.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 01 07:12PM +0100

> and could be in a tight loop where performance matters. Constantly doing
> bounds checking on a fixed size array in this situation is a waste of
> CPU cycles and needlessly slows the program down.
 
I think he has in mind the iterator-debugging facility when you arm
them with the proper #defines.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 01 09:59AM

On Thu, 2020-12-31, TDH1978 wrote:
> *a++ = 0;
> *a = 0;
> }
 
As an aside, a std::array<uint8_t, 6> would be a better choice for a
MAC address. If some API wants a C array, it's easy to write a
conversion function.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
spudisnotyourbuddy@grumpysods.com: Jan 01 04:18PM

On Fri, 1 Jan 2021 12:10:31 +0100
>> does the job.
 
>std::array is fixed size, too, but provides strict type safety, provides
>bounds checking and allows the use of the standard algorithms library.
 
If a piece of code is checking MAC addresses its probably very low level
and could be in a tight loop where performance matters. Constantly doing
bounds checking on a fixed size array in this situation is a waste of
CPU cycles and needlessly slows the program down.
 
>The classic C syntax can not safely distinguish between an actual array
>and a bare pointer, which might not point to an array of the appropriate
>size in some special case missed by the developer.
 
I doubt it would need to. I can't imagine you'd pass a MAC address to a
function that takes a generic pointer as input. It needs special attention.
David Brown <david.brown@hesbynett.no>: Jan 01 02:46PM +0100

On 01/01/2021 12:10, Hergen Lehmann wrote:
 
> The classic C syntax can not safely distinguish between an actual array
> and a bare pointer, which might not point to an array of the appropriate
> size in some special case missed by the developer.
 
An alternative for C is to put the array in a struct:
 
typedef struct {
uint8_t d[6];
} mac_address_t;
 
That is better than using a std::array in C++, because it gives a name
to the type - and functions dealing with mac addresses can be restricted
to taking only mac address types. Putting the array into the struct
makes it a fixed size and type-safe.
 
(Of course, for C++ you would make it a class, and put a std::array in
the class instead of a C array.)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 01 02:19PM +0100

On 01.01.2021 12:10, Hergen Lehmann wrote:
>> does the job.
 
> std::array is fixed size, too, but provides strict type safety, provides
> bounds checking and allows the use of the standard algorithms library.
 
The standard algorithms work nicely with raw arrays. `std::end(a)` gives
you an end iterator for the array whether `a` is `std::array` or a raw
array. But when `a` is a pointer one must usually calculate an end
pointer like `a+n`, which means that `std::array` is more /practical/.
 
 
> The classic C syntax can not safely distinguish between an actual array
> and a bare pointer, which might not point to an array of the appropriate
> size in some special case missed by the developer.
 
Additionally, `std::array` can be easily returned from a function.
 
- Alf
Ian Collins <ian-news@hotmail.com>: Jan 01 11:52AM +1300

On 01/01/2021 11:11, TDH1978 wrote:
 
> warning: writing 16 bytes into a region of size 6 [-Wstringop-overflow=]
 
> Does anyone know what the problem is? I tried using "0x00" instead of
> "0", to no avail. What "16 bytes" is the compiler referring to?
 
A compiler bug? Which build are you running? If it was a bug, it may
have been fixed already.
 
There is no warning with the latest Ubuntu release (10.2.0) or with the
latest snapshot (11.0.0 20201220).
 
--
Ian.
TDH1978 <thedeerhunter1978@movie.uni>: Dec 31 05:11PM -0500

I have the following piece of code:
 
void clear_mac(uint8_t a[6])
{
*a++ = 0;
*a++ = 0;
*a++ = 0;
*a++ = 0;
*a++ = 0;
*a = 0;
}
 
 
This code compiled cleanly for the last 15 years. When I upgraded to
the latest gcc/g++ 10.2.1 compiler on Fedora 33, I got the following
warning:
 
warning: writing 16 bytes into a region of size 6 [-Wstringop-overflow=]
 
 
Does anyone know what the problem is? I tried using "0x00" instead of
"0", to no avail. What "16 bytes" is the compiler referring to?
Lynn McGuire <lynnmcguire5@gmail.com>: Dec 30 05:17PM -0600

"Firsts in 2020 (or, A little dose of good news)" by Herb Sutter

https://herbsutter.com/2020/12/30/firsts-in-2020-or-a-little-dose-of-good-news/
 
"2020 has been mostly terrible. That includes for the C++ committee and
many of our communities, where just this month we lost Beman Dawes.
Beman was one of the most important and influential C++ experts in the
world, and made his many contributions mostly behind the scenes. I and
everyone else who has ever benefited from any of the standardized STL,
Boost, C++Now, std::filesystem, C++98/11/14/17, and more — so, really,
most people who have ever used C++ — all owe Beman a debt of gratitude.
We miss him greatly."
https://isocpp.org/blog/2020/12/remembering-beman-dawes
 
"To end the year with a little dose of good news, I thought I'd mention
a just few positive C++ accomplishments that did happen for 2020, and
were happier "first-ever" achievements."
 
"First, the big one…"
 
"C++20 is the first ever "D&E-complete" release of C++. In February, we
completed C++20, which is the first release of Standard C++ that
includes every feature that Bjarne Stroustrup envisioned for C++'s
evolution in his 1994 book The Design and Evolution of C++ (aka D&E),
including concepts, coroutines, modules, and more, except only for one
minor feature (unified function call syntax). Thank you to Bjarne for
sticking with it until we got there, and personally doing the heavy
lifting to drive important features like concepts into Standard C++!"

https://www.amazon.com/Design-Evolution-C-Bjarne-Stroustrup/dp/0201543303
 
Lynn
olcott <NoOne@NoWhere.com>: Jan 04 08:49PM -0600

On 1/4/2021 8:52 AM, Andy Walker wrote:
> real computer has for enabling function calls and recursion -- stash
> away return addresses, stack parameters, put return values onto the
> stack, blah-de-blah. ...
 
Thanks for adding some real software engineering to this dialogue.
 
>> shown to not be a Turing Complete environment.
 
>     ... The real problems are (a) recursion is not the only way
> a program can fail to halt;
 
I don't have to solve the halting problem to refute the conventional
proofs. My system already detects some cases of infinte loops.
 
> and (b) PO's recursion detection works
> only in very trivial cases.  Oh, and of course
 
No sense making the system more elaborate than required to refute the
conventional proofs. This would only confuse people making it more
difficult for them to see that I refuted the conventional proofs.
 
> (c) the fact that his
> "H_hat" doesn't [yet] correspond to his "H" in the correct way;
 
Bullshit. My Halts() corresponds to my H_Hat() in the simplest "do the
opposite of whatever the halt decider decides" template that all the
conventional halting problem proofs are based on.
 
> seems to want to construct an "H" that defeats "H_hat" rather than
> seeing that "H_hat" defeats a /given/ "H".  These have been explored
> far too much in these threads, and I don't propose to add to that.
 
There is no longer any "given" H that can be defeated. The standard
template that all the conventional halting problem, undecidability
proofs are based has been defeated.
 
All three halt deciding modes now are fully operational:
(a) Global
(b) Local
(c) Disabled
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Lynn McGuire <lynnmcguire5@gmail.com>: Jan 04 07:23PM -0600

"GotW #97: Assertions (Difficulty: 4/10)" by Herb Sutter

https://herbsutter.com/2021/01/01/gotw-97-contracts-part-1-assertions-and-postconditions/
 
Wow, we do not have any asserts in our 450,000 lines of C++ code.
 
Lynn
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)