Tuesday, June 16, 2020

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 15 04:25PM -0700

On 6/15/2020 4:04 PM, Chris M. Thomasson wrote:
> On 6/15/2020 3:52 PM, Chris M. Thomasson wrote:
>> On 6/15/2020 9:44 AM, Juha Nieminen wrote:
>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
[...]
> rounded down then subtracted the size of the header.
 
> Take a cache line allocator, if the header fits in a cache line, then it
> can be the first element in an array of lines.
 
Check this shi% out:
_____________________________
#include <iostream>
#include <new>
#include <cassert>
#include <cstdlib>
#include <cstddef>
#include <cstdint>
 
 
// Doctor Hackinstein!
#define CT_RALLOC_ALIGN_UP(mp_ptr, mp_align) \
((unsigned char*)( \
(((std::uintptr_t)(mp_ptr)) + ((mp_align) - 1)) \
& ~(((mp_align) - 1)) \
))
 
#define CT_RALLOC_ALIGN_ASSERT(mp_ptr, mp_align) \
(((unsigned char*)(mp_ptr)) == CT_RALLOC_ALIGN_UP(mp_ptr, mp_align))
 
 
// Hackish indeed!
template<std::size_t T_size>
struct ct_local_mem
{
unsigned char m_bytes[T_size];
 
template<typename T>
unsigned char* align_mem()
{
return align_mem<T>(alignof(T));
}
 
template<typename T>
unsigned char* align_mem(unsigned long align)
{
if (!align) align = alignof(T);
 
unsigned char* base = m_bytes;
unsigned char* aligned = CT_RALLOC_ALIGN_UP(base, align);
 
assert(CT_RALLOC_ALIGN_ASSERT(aligned, align));
 
std::size_t size = aligned - m_bytes;
 
if (size + sizeof(T) + align > T_size)
{
throw;
}
 
return aligned;
}
};
 
 
 
// A test program...
struct foo
{
int m_a;
int m_b;
 
foo(int a, int b) : m_a(a), m_b(b)
{
std::cout << this << "->foo::foo.m_a = " << m_a << "\n";
std::cout << this << "->foo::foo.m_b = " << m_b << "\n";
}
 
~foo()
{
std::cout << this << "->foo::~foo.m_a = " << m_a << "\n";
std::cout << this << "->foo::~foo.m_b = " << m_b << "\n";
}
};
 
 
int main()
{
{
// create some memory on the stack
ct_local_mem<4096> local = { '\0' };
 
 
// create a foo f
std::cout << "Naturally aligned...\n";
foo* f = new (local.align_mem<foo>(alignof(foo))) foo(1, 2);
 
// destroy f
f->~foo();
 
 
 
// create a foo f aligned on a large byte boundary
std::size_t alignment = 2048;
std::cout << "\n\nForced aligned on a " << alignment << " byte
boundary...\n";
 
// ensure the alignment of foo is okay with the boundary
assert((alignment % alignof(foo)) == 0);
 
 
f = new (local.align_mem<foo>(alignment)) foo(3, 4);
 
assert(CT_RALLOC_ALIGN_ASSERT(f, alignment));
 
// destroy f
f->~foo();
}
 
return 0;
}
_____________________________
 
;^)
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 16 12:26AM +0100

On Mon, 15 Jun 2020 20:10:15 +0300
> > };
 
> Interpreting a malloc'ed piece of memory as an array of objects is a
> very old practice and standards have been carefully worded to allow that.
 
Unfortunately they haven't. It is a major fail in the standard that
pointer arithmetic on memory obtained by malloc rather than by the
new char[] expression is technically undefined behaviour. See
https://stackoverflow.com/questions/60465235/does-stdunitialized-copy-have-undefined-behavior
However practical implementations will allow it for reasonable uses.
 
Technically, constructing the 'header' object in the malloc'ed buffer
is also reputed to be undefined behaviour if you do it otherwise that
through placement new, even though 'header' is a trivial type. As a
consequence 'h->m_size = size' in header_alloc is technically defective
although I imagine most compilers will accept it. There was an
exchange on this newsgroup about it a year or so ago. Having
constructed 'header' by placement new, I think 'this + 1' in get_buf()
becomes valid (a single object is treated as an array of one element
for this purpose). But even so dereferencing the result of 'this + 1'
is I think technically also undefined behaviour if the buffer at that
address has not been constructed there by placement new[], but it will
probably work in practice. Having constructed the buffer with
placement new[], pointer arithmetic (such as with the std::strcat in
the example code) becomes valid.
 
Altogether the code looks too tricksy for its own good.
 
Paavo Helde <eesnimi@osa.pri.ee>: Jun 16 12:15PM +0300

16.06.2020 02:26 Chris Vine kirjutas:
> new char[] expression is technically undefined behaviour. See
> https://stackoverflow.com/questions/60465235/does-stdunitialized-copy-have-undefined-behavior
> However practical implementations will allow it for reasonable uses.
 
Huh, good to know 99% of C programs formally contain UB when compiled as
C++.
 
> for this purpose). But even so dereferencing the result of 'this + 1'
> is I think technically also undefined behaviour if the buffer at that
> address has not been constructed there by placement new[],
 
Just to clarify: are you speaking about dereferencing 'this+1' as
another header object? Or about converting 'this+1' to a char* pointer
and dereferencing this? For the latter, at least the dereferencing
should be kosher if the initial buffer was allocated by new char[].
Manfred <noname@add.invalid>: Jun 16 02:26PM +0200

On 6/16/2020 11:15 AM, Paavo Helde wrote:
 
>> However practical implementations will allow it for reasonable uses.
 
> Huh, good to know 99% of C programs formally contain UB when compiled as
> C++.
 
This sounds strange to me as well. Especially since it was an explicit
goal of Bjarne that most valid C code would be valid C++ code as well.
 
I think I had already seen the proposal (P0593R6), and it puzzled me
that they had to go through such length to try and fix this.
To my ignorance, why shouldn't a type cast on the pointer returned by
malloc() suffice?
Cast operators are explicitly meant to tell the compiler: look, this
pointer, irrespective of where it comes from, is a pointer to T, deal
with it.
The rationale for the ugly notation of reinterpret_cast<> was explicitly
that of not making this statement accidental, so that the compiler knows
the programmer thought about it when writing the thing.
 
I know there are a lot of details for the devil to hide in with these
things, however what puzzles me is why this wasn't taken care of
properly in the standard in the first place.
 
> another header object? Or about converting 'this+1' to a char* pointer
> and dereferencing this? For the latter, at least the dereferencing
> should be kosher if the initial buffer was allocated by new char[].
 
Why shouldn't a memory area returned by malloc() be good enough, as new
char[] supposedly is?
I mean, I understand that this may not currently be according to
standard (I didn't check), but even so I fail to understand what's the
problem with malloc.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 16 01:34PM +0100

On Tue, 16 Jun 2020 12:15:59 +0300
> > However practical implementations will allow it for reasonable uses.
 
> Huh, good to know 99% of C programs formally contain UB when compiled as
> C++.
 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r6.html
does shake your confidence in the competence of those who produce
the standard. You cannot produce a sensible home made std::vector
implementation in standard C++, nor implement an equivalent to
std::memcpy() for yourself, nor can you use std::uninitialized_copy
with a defined effect. The issue is still unresolved as of C++20. If
you want to see further ranting at deficiencies in the standard this is
quite amusing:
https://www.youtube.com/watch?v=IAdLwUXRUvg&list=PLHTh1InhhwT6KhvViwRiTR7I5s09dLCSw&index=32&t=0s
I love the tinfoil hat.
 
> another header object? Or about converting 'this+1' to a char* pointer
> and dereferencing this? For the latter, at least the dereferencing
> should be kosher if the initial buffer was allocated by new char[].
 
I am talking about converting 'this+1' to char* and dereferencing it as
char*. That would be OK if you applied placement new[] to that
region of memory first to establish an array of char there and then went
through std::launder (but see the tinfoil hat presentation for why in
fact placement new[], as opposed to placement new, is unusable). It
would also be OK if you abandoned std::malloc and constructed all your
memory with 'new unsigned char[sz]' or 'new std::byte[sz]', and cast
(this+1) to char* (I think that cast would be OK - I find the rules
quite opaque and clearly many on the standard committee share my lack
of a complete understanding).
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 16 10:02AM -0400

On 6/16/20 5:15 AM, Paavo Helde wrote:
> 16.06.2020 02:26 Chris Vine kirjutas:
...
>> However practical implementations will allow it for reasonable uses.
 
> Huh, good to know 99% of C programs formally contain UB when compiled as
> C++.
 
They don't have to be compiled as C++ for that to come up. Pointer
arithmetic in C is defined solely in terms of positions in arrays. Until
dynamically allocated memory acquires an effective type that is an array
type, technically the only position in that memory that you can create a
pointer to is the first one.
 
C doesn't have new[], but in C there are four other ways to give
dynamically allocated memory an effective type that is an array type.
One is to write the entire array in one assignment expression using a
lvalue of a struct or union type that contains an array as a member. If
you only wrote individual members of that array, those members would
acquire the effective type of the array element, but that would not give
the entire block of memory an array type. You could also use memmove(),
memcpy(), or explicitly copying something as an array of char, despite
the fact that in all three of those cases the behavior is defined in
terms of pointer arithmetic accessing the elements of an array. That's
because those three methods are explicitly described as giving an object
with no declared type an effective type that matches the effective type
of the object being copied (C2011 6.5p6).
 
In practice, it's generally understood that dynamically allocated memory
can, for the purposes of pointer arithmetic, be treated as if it were an
array of the pointed-at type - but there's nothing in either standard
that actually says so.
Bo Persson <bo@bo-persson.se>: Jun 16 04:12PM +0200

On 2020-06-16 at 14:26, Manfred wrote:
> Cast operators are explicitly meant to tell the compiler: look, this
> pointer, irrespective of where it comes from, is a pointer to T, deal
> with it.
 
Sorry, no. The compiler has seen all your code and can tell that nowhere
does it create a T object. So how could there be a pointer to T, when
there are no Ts?
 
 
Bo Persson
Scott Newman <scott69@gmail.com>: Jun 16 05:12PM +0200

Am 15.06.2020 um 09:03 schrieb Chris M. Thomasson:
>     return reinterpret_cast<char*>(this + 1);
>   }
> };
 
Don't care for the spec. It works with any compiler and
it will work with any compiler that will ever exist.
Manfred <noname@add.invalid>: Jun 16 05:22PM +0200

On 6/16/2020 4:12 PM, Bo Persson wrote:
 
> Sorry, no. The compiler has seen all your code and can tell that nowhere
> does it create a T object. So how could there be a pointer to T, when
> there are no Ts?
 
Short answer: because I say so:
T* p = reinterpret_cast<T*>(ptr);
 
Longer answer: I think you are missing my point (that you snipped); I
understand that this may be what the standard says (again, I didn't
check in detail) and how the language formally works.
 
However, my remark is about /why/ the standard states the rules of
object creation and lifetime so as to deny this possibility. In other
words, why did they make it this way?
I may add that at a first look it appears that allowing the following to
work for a non trivial type would be problematic:
T* p = const_cast<T*>(malloc(sizeof(*p));
 
But I fail to see this as an impossible problem when T is a C-style
struct, or anyhow a POD or a trivial type.
(Which means that yes, allowing this for a POD would make valid C code
of this kind valid C++ code as well)
 
By the way, denying the above would make reinterpret_cast (and even
static_cast from void* to T*) effectively unusable when it would be
actually needed.
 
 
Paavo Helde <eesnimi@osa.pri.ee>: Jun 16 06:29PM +0300

16.06.2020 15:26 Manfred kirjutas:
 
> Cast operators are explicitly meant to tell the compiler: look, this
> pointer, irrespective of where it comes from, is a pointer to T, deal
> with it.
 
The proposal to legislate malloc and friends for object creation
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r6.html"
contains explicit remark, stressing the opposite:
 
"Note that a pointer reinterpret_cast is not considered sufficient to
trigger implicit object creation."
 
I gather all this fuss is about allowing type-based alias analysis.
Reinterpret_cast works directly against this idea.
Bo Persson <bo@bo-persson.se>: Jun 16 05:53PM +0200

On 2020-06-16 at 17:29, Paavo Helde wrote:
> trigger implicit object creation."
 
> I gather all this fuss is about allowing type-based alias analysis.
> Reinterpret_cast works directly against this idea.
 
Yes, the idea was to not have to decorate every other pointer with a
'restrict' keyword (like some other language does).
 
 
Bo Persson
Christian Gollwitzer <auriocus@gmx.de>: Jun 16 07:28AM +0200

Am 15.06.20 um 23:44 schrieb Frederick Gotham:
 
> if ( !cond3 ) return;
 
> if ( !cond4 ) return;
 
> Do Something();
 
This is how I'd do it. If the conditions do error checking, i.e.
checking that the input parameters are valid, instead of "return" it
could also be "throw."
 
 
 
> Do Something();
 
> Label_At_End:
> ;
 
This is how I do it in C due to lack of exceptions. After the label I
release the resources. But why should it not be possible to do
return/throw here in C++? Because there is more unrelated code after the
label? Usually it makes sense to put the whole thing into a function on
its own, and then you can return.
 
 
 
> if ( !cond4 ) break;
 
> Do Something();
> }
 
Feels hackish.
 
Christian
David Brown <david.brown@hesbynett.no>: Jun 16 09:14AM +0200

On 15/06/2020 23:44, Frederick Gotham wrote:
> }
> }
> }
 
How about :
 
if (cond1 && cond2 && cond3 && cond4) {
DoSomething();
}
 
 
 
> if ( !cond3 ) return;
 
> if ( !cond4 ) return;
 
> Do Something();
 
That's good for some kind of tests. In particular, tests on the
parameters of a function followed by early exits are a popular style.
(Not everyone likes it - some people feel functions should only ever
have one exit.)
 
There is no single "best" method - it will depend on the code as well as
any style preferences or requirements for the project and team.
 
 
> Do Something();
 
> Label_At_End:
> ;
 
That's also a common idiom. It's not one I like - I don't find use for
gotos in my own code. But some people do.
 
 
 
> if ( !cond4 ) break;
 
> Do Something();
> }
 
That would be a code review fail right away - it's an unnecessarily ugly
hack and an abuse of switch. Your "do {} while (false);" is much less
bad (omitting the "default:").
 
 
> Do Something();
> } while (false);
 
> Does anyone else use fake switches and fake loops like this just to exploit the 'break' keyword?
 
I've never felt the need.
"Öö Tiib" <ootiib@hot.ee>: Jun 16 08:46AM -0700

On Tuesday, 16 June 2020 00:45:11 UTC+3, Frederick Gotham wrote:
> [I have multi-posted this to comp.lang.c and comp.lang.c++]
 
> Have you ever seen code written as follows?
 
I think that variant is most cute:
 
if (not cond1 || not cond2 || not cond3 || not cond4)
return;

DoSomething();

But I dislike when someone puts up pull request where they
pointlessly transformed between whatever was there and what
is their favorite. It just results with massive diff
that hides what they actually did if anything.
So unless whatever they remodeled it into is specified in
coding standard of project as preferred I will complain.
Bart <bc@freeuk.com>: Jun 16 01:00AM +0100

> and process it without having to jump through coding hoops to do so.
> The compiler hides all of the access code. You just deal with members
> as though they were fixed.
 
According to your initial posts, your binary data looks like this:
 
3 0 0 0 O n e 3 0 0 0 T w o 5 0 0 0 T h r e e 4 0 0 0 F o u r
 
Which ever way you do it, getting the length of the 4th string and the
start of the fourth string, involves reading the 1st length "3", using
that to calculate the offset of the 2nd length, reading that, using it
to calculate the offset of the 3rd length, and using that to get the
offset of the fourth length.
 
It's this business which you haven't gone into any detail over, and
hidden behind compiler magic.
 
You say this is fast; not if you /always/ have to this calculation to
randomly access the i'th string in the struct.
 
You then switched to arrays of a struct containing only one
length/string, but this is exactly the same; here ' marks the divisions
between elements:
 
3 0 0 0 O n e ' 3 0 0 0 T w o ' 5 0 0 0 T h r e e ' 4 0 0 0 F o u r
 
You now have an array of structs, with sizes of 7, 7, 9 and 8 bytes. The
problem is the same, but accessing by index instead of by name.
 
 
> int length;
> char variable_data[0..length];
 
> You can have as many of those as you want in your struct.
 
With the complications of getting the offsets of all those other strings.
 
 
>> access the same; see my example below.
 
> I know of no way to do that. And especially not with the simple syntax
> this extension has.
 
Syntax is easy to think up. But it has to make sense and it has to be
implementable. And worthwhile.
 
> };
 
> You pass the SEmail struct over the network, or write it to disk and
> read it back in later.
 
You've lost me. You've now changed from length/string/length/string, to
length/length/string/string. I guess further magic means the language
can figure out the format by itself and match each int to each string
(and I further guess that you can't have any other fields in there to
mess things up).
 
Remember the compiler sees only a series of:
 
T x;
U y;
V y;
....
 
And somehow, it has to know that some of those are counts, and are
associated with another member later on. Which is not necessarily an
array, according to your example.
 
I reckon what you want here is an embedded language to define binary
file layouts. That's fine, but keep it out of the way of the main
language. It is unnecessary to allow access via normal member/index
operations, but as I said, C++ can do that if you want (you may have to
write A.B() instead of A.B).
 
(BTW is that really an email header? I thought it was 100% text with
nothing as crude as binary string lengths.)
 
> length data items so beautifully in code, while hiding the variable
> access portions of everything.
 
> Yes it's a desirable feature.
 
How's how I might set that up in script:
 
email := ["From":"A", "To":B, "CC":"C", "BCC":"D",
"Subject":"E", "Header":"F", "Body":"G"]
 
 
I don't believe that email uses rigid binary formats, but even if it
did, that is an external format; you don't use such formats in program
data. You use whatever is simplest to do. This here is variable length
data. The elements can also be specified in any order.
 
If you don't have such a feature, then add that first. If you do it
properly, you can superimpose an auxiliary data structure on top of
flat, packed binary data.
rick.c.hodgin@gmail.com: Jun 15 05:37PM -0700

You're not getting it, Bart.
 
Don't worry about it.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 16 12:45PM +0100

> You're not getting it, Bart.
 
> Don't worry about it.
 
Oh Bart gets it alright: what you are proposing, as usual, is total nonsense.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne 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."
rick.c.hodgin@gmail.com: Jun 16 05:23AM -0700

Bart, consider this portion:
 
 
> int length;
> char variable_data[0..length];
 
> You can have as many of those as you want in your struct.
 
You said I changed from length/string length/string to length/length
string/string. I didn't change. It was a different layout of the
same type of example.
 
The point is: you have a variable length variable defined SOMEWHERE
in the struct BEFORE the variable portion, but it doesn't matter where
it's defined.
 
Once you have the length defined at some point, the variable-length
portion is fully accessible because the length provides access to it.
I made the email struct with the lengths up top so it's clearer visu-
ally.
 
The email example could've been written this way:
 
struct SEmail
{
int length_from;
char from [0..length_from];
 
int length_to;
char to [0..length_to];
 
int length_cc;
char cc [0..length_cc];
 
int length_bcc;
char bcc [0..length_bcc];
 
int length_subject;
char subject [0..length_subject];
 
int length_header;
char header [0..length_header];
 
int length_body;
char body [0..length_body];
 
// Label is an offset to a location in the structure, but
// one that doesn't consume data space.
int attachmentCount;
label attachments; // Begins a series of SAttachment
// structs of attachmentCount ele-
// ments long.
};
 
In each case, the "len" variable portion referenced inside the
[0..len] syntax simply has to be a named member defined up higher
in the struct.
 
Do you understand?
 
Access to each variable would be given by a calculation, assume
sizeof(int) = 4:
 
from = sizeof(length_from)
to = from + length_from + sizeof(length_to)
cc = to + length_to + sizeof(length_cc)
bcc = cc + length_cc + sizeof(length_bcc)
subject = bcc + length_bcc + sizeof(length_subject)
header = subject + length_subject + sizeof(length_header)
body = header + length_header + sizeof(length_body)
attachments = body + length_body + sizeof(attachmentCount)
 
The compiler injects functions or inline code to compute the off-
sets so you navigate each structure member as requested.
 
In this example, ++ would not work properly because it has an
extra variable portion not defined in the structure, but rather
defined behind program logic to access the attachments label
and process the content internally. Moving past that portion
would require determining the size the attachments and either
storing it on the original structure as an extra value that is
not computed, but can be referenced and used in pointer math,
or to traverse the SAttachment members and compute the value at
runtime and use that value.
 
If attachmentCount is 0, then ++ would work because the pointer
math would be correct in the absence of the "hidden" attachments
size.
 
--
Rick C. Hodgin
rick.c.hodgin@gmail.com: Jun 16 05:56AM -0700

On Tuesday, June 16, 2020 at 7:45:51 AM UTC-4, Mr Flibble wrote:
> "Snakes didn't evolve, instead talking snakes with legs changed
> into snakes." - Rick C. Hodgin
 
 
The correct statement would be
 
> "You won't burn in hell. But be nice anyway." – Ricky Gervais
 
Satan teaches that we'll be fine by doing positive things, that our
good will outweigh our bad, and that's good enough. That is a lie.
All of us carry sin, and that sin is like a charge on a rap sheet.
In God's court, that charge will be read aloud and the sentence
will be meted without mercy for all who are guilty. God has warned
us of this in advance, and given us the way out. Each person will,
therefore, send themselves to Hell by their personal rejection of
God.
 
> "I see Atheists are fighting and killing each other again, over
> who doesn't believe in any God the most. Oh, no..wait.. that
> never happens." – Ricky Gervais
 
All of the war, all of the disease, all of the death, all of the
pain, all of the harmful weather/elements, every poisonous thing,
every thorny thing, all of it comes from one original sin by Adam.
 
The world Jesus will restore is a return to an Eden-like existence,
where all animals will be at peace, where babies can lay down in
nests of snakes and not have any fear of being bitten.
 
The Bible promises a future of love and peace, and there will be
a 1,000 year reign of that peace here on Earth, after which Satan,
who was bound up for that 1,000 years unable to influence anybody,
will be loosed at the very end for a short time. And in that very
short time (likely weeks or months (much less than a year) at most),
a large percentage of mankind who has lived during the Millennium
with Jesus, in love and peace, will follow after Satan because of
his silvery tongue and appealing ways. And everyone who does will
be destroyed by fire from God from Heaven.
 
People do not want God. They invent every possible excuse to have
their own way, to do their own things. They hide behind national
pride, behind a constructed moral charter, behind anything that can
give them a rallying cry. But when they build up on something other
than Jesus Christ and His teachings, they are in rebellion against
God, no matter how "noble" their goals might seem.
 
Jesus provides us a framework for life and living which is expansive
and comprehensive. The only frames that are in place are to keep us
from going astray and becoming part of a force which would serve to
destroy His creation. He governs His creation with an iron rod, and
does not tolerate that which rises up against it.
 
Consider all of the wars, all of the death, all the disease, all the
pain, stemmed from ONE SIN by Adam. Sin is like cancer. Once it
shows up, it spreads. It destroys good tissue and replaces it with
cancerous tissue. Once sin shows up it destroys good society, and
replaces it with destructive society. It's evident everywhere.
 
God will not tolerate sin. Either we will pay the price for our sin,
or Jesus will. All who put their faith and trust in Jesus will never
see death, will never be ashamed, will never be cast down for their
sin, but have passed (past tense) from death to life and will enter
in to eternity alive.
 
It's the greatest gift imaginable. Despite our guilt, despite our on-
going rebellion against God in all our various ways, yet is He patient
and desirous of us. He goes out of His way to send message after mes-
sage and messenger after messenger to reach every last person.
 
> "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."
 
Here is where Fry errs. It is our fault. God created the perfect
paradise and created a special garden called Eden and put man in it.
There the Bible records "the cool of the day." Everything was pro-
vided for man. All Adam and Eve had to do was keep it, which I would
argue at that point would be via something we would call supernatural,
kind of how Jesus was able to perform miracles when He walked the
Earth. Adam and Eve could summon abilities we would consider magic.
Move things with their thoughts. Instantiate instances of things
here on the Earth likewise. It would be like looking in your back
yard and thinking to yourself, "I wish I had a rose garden there,"
and Adam and Eve could have that thought and then think, "Behold, a
rose garden," and it spontaneously appeared there based on the very
template of their thoughts.
 
That ability was lost because of sin. Everything God created for us
was lost because of sin, all except our physical life here in the
flesh. Our eternal nature, our spirit, the unity of our soul + body
+ spirit were all lost. We now stand in defeated isolation with ac-
cess to our physical body.
 
The enemy anti-Christ spirit is able to exert spiritual forces by
their will which manipulate our flesh. They can inject thoughts and
feelings and emotions into our physical reality. These things we
think we feel, including homosexuality, addiction, lusts, passions,
thoughts like those of severe criminals who say, "The voice told me
to kill that person," actually stem from a real source, which is
that of those evil spirits at work against all of us continually.
 
The Bible teaches us the nature of this attack, and how to overcome
it. The ability to overcome stems completely and totally from Jesus
Christ alone, because ONLY JESUS can take away our sin. When our
sin is taken away, those things we lost when our sin was taken away
are restored, and we begin the journey of learning how to be proper
people in this world, guided by God's Holy Spirit, guided by our
inner drive to seek and pursue the truth and learn of the truth God
teaches us, to un-learn the things of this world the enemy has
taught.
 
Leigh, you spin and toil in the world of physicality. And while
none of us can break the chains of our ties to this flesh, what
Jesus teaches us is that we don't have to be beholden to it. That
our spirit nature, which He gives us when He takes our sin away,
can overcome our flesh, that we can pursue the spirit rather than
the flesh and no longer be a slave to the flesh.
 
You reject that teaching because of the influences of the many evil
spirits you've let into your life by your choices over the years.
They give you thoughts, feelings, ideas, emotions, that rail against
all things related to Jesus Christ, so that you are a slave to your
flesh, which makes you a slave to them, which keeps you on the path
to destruction.
 
If you want to break free, you have to begin with an attitude of the
heart toward seeking the truth, of seriously wanting to know if
these things I teach, that the Bible teach, are really real or not.
When you come to that place of honestly seeking the truth of things
for knowledge' sake, God knows you are doing this and He comes to you
with truth ... because He is truth, and when you seek truth He sees
you seeking Him.
 
There's so much more to this world and eternity than your world-view
provides in your understanding. God has prepared the most amazing
things for us, His greatest creation, made in His own image and like-
ness. And it is that existence the enemies of God (evil spirits)
have lost, and it is the ability to be restored to that existence
that those same enemies try to prevent all of us from coming to the
knowledge of, so that we remain where we are, lost in sin.
 
You have the ability to be restored to eternity, Leigh. You can have
that amazing future God intended for each of us before sin entered in
and destroyed everything. Yet even in our sin, God has made the way
back for free.
 
You owe it to yourself to seek this out. Everybody owes it to them-
selves to seek this out. It's not a lie, and you'll find the extent
to which Jesus is truly and absolutely and totally and completely
amazing beyond words in that He still cares about us even in our
guilt and shame from sin.
 
> It's not right, it's utterly, utterly evil."
 
Satan twists things in people's thinking so that those things which
are of God are evil, and those things which are of Satan's own influ-
ence are pushed onto God as though He's the cause of the negative
things, when it is that very enemy of God who was the source of it
all.
 
Satan will soon be cast into the eternal lake of fire for what he
has done. The power and authority here in this world he affords
those who follow after him is temporal, fleeting, and has no real
foundation or stability and will not endure. People pursue after
it because it's tempting to the flesh. But if you press in and seek
the truth and come to Jesus and are forgiven of sin and your spirit
comes alive, you begin to receive true and proper input from God,
which re-focuses your attention on the important things to God,
which fills you with inner joy, peace, love, and overflowing to such
an extent that you reach out with both arms, proclaiming with your
mouth as you go, those things that are possible in Jesus Christ.
 
> "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."
 
God created a world that was perfect. Sin has introduced all of
those things Fry's railing against. What Fry hates is Satan and
the evil he brought. Fry's attributing the evil to God because
he is ignorant of the truth. It's how all people will wind up in
Hell. They ignore the offering of Jesus because they rely on
their flesh for understanding, and that enemy of God feeds their
flesh with a multitude of lies which are purported and held up by
a vast avenue of aligned resources to seem as though it's true.
 
But when one takes the time to investigate the alleged "facts" of
each of those lies, they crumble under scrutiny, because God is
still in control, His power is still absolute, and He doles out
victory after victory after victory in truth, and all of it is
there waiting for us to seek.
 
Were Fry to investigate his claims, he would realize that the very
thing he's railing against is sin and sin's effect on this world.
He would seek the world God created, and will restore, where there
is no cancer in babies, where there is no pain or death or hunger
or thirst as we know it.
 
The enemy is a liar and the father of lies. If you want to be set
free from the lies, seek the truth. Jesus is truth. Learn of Him
and He will set you free, and restore you to His eternal Kingdom of
power and love and peace and joy and beauty and honor.
 
--
Rick C. Hodgin
rick.c.hodgin@gmail.com: Jun 16 06:16AM -0700

> > "Snakes didn't evolve, instead talking snakes with legs changed
> > into snakes." - Rick C. Hodgin
 
> The correct statement would be
 
The correct statement would be:
 
The world God created in the beginning was markedly different
than the world we live in now. We live in the world of sin's
creation, which is a diminished world compared to that we had
in the Garden of Eden.
 
Lifespans are shorter. People changed after sin. The inner
character of their nature, the donning of reality has become
limited to flesh-focused things. We are lesser now that we
have lost our relationship with God, and His mighty hand of
direct daily intervention and protection as was in effect in
the garden.
 
How did this happen? The serpent introduced an alternative
idea, proposed something other than that which God had pre-
viously guided Adam and Eve toward. He introduced a lie, and
purported it as though it were truth. Adam and Eve believed
the lie and followed after the guidance of the serpent, which
then immediately introduced sin. The Bible records "their
eyes were opened" and they knew that they were naked, for ex-
ample.
 
God came to Adam and Eve after this and inquired as to why
they had hid themselves. When God discovered they had fol-
lowed after the guidance of the serpent, God's anger moved
toward the serpent and in that instant God changed the form-
erly beautiful creature into that which we would call a snake
today. No longer does it have legs and a form to move about,
but its spine was extended, its insides were altered, its
whole demeanor and type of existence was changed, so that now
the creature serves as the embodiment of how Satan moves.
 
Snakes lie in wait. They attack from hidden places. Many
have venom that can kill once it gets on the inside of your
flesh. They can unhinge their jaw and consume things that
are bigger than they are.
 
God has given us all of this knowledge about the serpent in the garden,
and the snakes we have today, to teach us some things about the nature
of what we all face.
 
You put a tag onto all of your messages where you mock me by putting a
quote I never originated, twisting it into something mocking because
you believe that you are being commensurately insulting back to me for
the "infliction" I subject this group to.
 
What you don't realize is that the things I post with regards to Christ
are the very things we need to have eternal life, to be restored, to
seek the truth, to know real love, real peace, real joy. And that, be-
cause of sin, you are listening to voices intent on keeping you pinned
up in your sin, condemned in eternity, so that you are not set free as
Jesus would allow you be, and has provided for you to be.
 
You take hold of the enemy's guidance within your flesh because the
flesh is all you know, and you're following it so intently. You are
not willing to step out into the area of questioning something that
your flesh peddles to you. You are not willing to ask yourself if
the behavior you're engaging in (constant profanity, always being in-
sulting and rude to people, mocking me, all of which are signals to
the general pattern you would have toward everyone in your daily
life) is actually beneficial, proper, desirable, fruitful, product-
ive, or other such things.
 
You continue on like a brute beast following only its flesh-focused
baser feelings and emotions, never using the ample mind of full-on
contemplation God gave you to consider something more.
 
You don't know the beauty you possess, Leigh. You don't know the
hand-crafted form you be restored to by God's creation. You don't
know the future of beauty and glory and honor and truth and power
and love you can be a part of. The enemy has deceived you into be-
lieving that this flesh-focused nature is where it's at, and you
have to get ahead by using your assets and pushing other people
down rather than lifting them up and being part of their lives in
some positive way.
 
"Talking snakes with legs didn't turn into snakes," as you put it.
The serpent deceived Adam and Eve, and as a result of that deception,
was forever altered in a way recorded for us to now use our minds and
examine so that we can see the significance God places on sin, and to
also see the incredible love given to us (man) because despite our
full-on guilt in sin, yet is He not only willing to forgive us, but
is exceedingly patient with us, effectively rescuing even the very
souls holding the hammer and nails to put Him on that cross from
their own folly:
 
http://mrmom.amaonline.com/forgiven.htm
 
You diminish everything around you, Leigh, when you do not pursue
the truth. When you ride high upon some lie. It's not part of any
aspect of our existence God calls us to. And that reality is self-
evident even to someone who does not believe in God, because it is
also true of simple life and living (falseness and lies never bring
about rightness, they always only bring about destruction and death).
 
--
Rick C. Hodgin
Ian Collins <ian-news@hotmail.com>: Jun 16 06:06PM +1200

> itself after deletions. Does it happen after every erase or only after a
> certain amount of imbalance occurs? When it does happen how long does it
> take and is there a way to force it to happen?
 
Have you learned how to count to three yet?
 
--
Ian.
boltar@nowhere.co.uk: Jun 16 09:04AM

On Tue, 16 Jun 2020 18:06:34 +1200
>> certain amount of imbalance occurs? When it does happen how long does it
>> take and is there a way to force it to happen?
 
>Have you learned how to count to three yet?
 
If you think a major rebalance would only involved updating 3 nodes then
you have no idea how balancing works.
Ian Collins <ian-news@hotmail.com>: Jun 16 09:21PM +1200


>> Have you learned how to count to three yet?
 
> If you think a major rebalance would only involved updating 3 nodes then
> you have no idea how balancing works.
 
I thought not.
 
--
Ian.
boltar@nowhere.co.uk: Jun 16 09:38AM

On Tue, 16 Jun 2020 21:21:24 +1200
 
>> If you think a major rebalance would only involved updating 3 nodes then
>> you have no idea how balancing works.
 
>I thought not.
 
You know there's this very useful tool called Google, you might want to
find out about it. In the meantime here's a useful page with a nice example
of a small 11 node tree before and after balancing. I suspect even a
beginner like you will be able to see that more than 3 node updates had to
happen to achieve that:
 
https://en.wikipedia.org/wiki/Self-balancing_binary_search_tree
 
HTH
Bonita Montero <Bonita.Montero@gmail.com>: Jun 16 06:53AM +0200

> If not, then you need to go rouge. Take careful note of the
> memory_order_acq_rel membar.
 
I inserted the appropriate fences.
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.

No comments: