Tuesday, October 17, 2017

Digest for comp.lang.c++@googlegroups.com - 23 updates in 7 topics

Christopher Pisz <christopherpisz@gmail.com>: Oct 17 02:41PM -0700

On Friday, October 13, 2017 at 1:30:27 PM UTC-5, Stuart Redmann wrote:
> is: std::less<MyClass>!
 
> Regards,
> Stuart
 
 
Indeed, in the end, it was the comparator. 5 days of searching. 4 people looked over the comparator and none saw the problem.
 
Let this be a lesson learned. Unit Test that (A < B) && (B < A) should never be true.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 17 01:18PM -0700

Is there a proper name for encoding meta data on something like a bool,
where actual data value is 0 for false, !0 for true, but to then use
that additional storage to encode information within the value so that
it still reads as true and false as expected, but also contains some
meta data or additional information beyond just yes/no?
 
union
{
char value;
bool flag;
};
 
flag = true; // value is 0x01
flag = false; // value is 0x00
 
value = 10;
std::cout << ((flag) ? "True" : "False") << std::endl;
 
Is there a proper term for populating value (flag's internal value)?
And does anyone know if C or C++ compilers will ever strip the value
down to its true/false state when passing the value to a function?
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 17 11:49AM -0700

Do you want a body like the angels? Young, strong, beautiful, never
getting tired, never aging, never wearing out, but always at the
absolute top of its game. Remember what it was like when you were
in your early 20s? Imagine that level of bodily ability with the
aging and mature mind you have as an adult, but with greater mental
clarity, greater strength, greater agility, greater endurance, the
ability to go without limit.
 
Do you want to know the secrets of the universe? The things that
today we don't understand? The things that are out there waiting
to be understood?
 
Do you want to see God? To talk to Him face-to-face? To ask Him
many questions and listen to His comprehensive answers? Do you
want to be able to fellowship with God, to collaborate with Him on
your ideas and projects? To rely upon Him and His infinite purses
for the funding and resources you need to accomplish those deep and
wide masterpieces lurking inside of you?
 
-----
Jesus Christ is offering you eternity in paradise. He extends the
offer for free to all people.
 
Sin separates us from God. It pins us down, puts us under judgment
and condemnation per God's own Holy Laws. God will not sacrifice
His own integrity, and He will not recant His Laws. But He still
wants to save us from our sin.
 
He made a way out of no way. He setup a system whereby our sin
could be transferred to another, and the one receiving our sin would
pay the price. He didn't do this arbitrarily, but had you in mind
when He did it. He wanted to make a way out for man when man sinned.
He wanted to give us a second chance, while maintaining full order.
 
-----
If you ask Jesus to forgive your sin, God restores you to the plans
He had for you before sin entered in and destroyed everything.
 
If you'd like to be a part of that eternal future outside of time,
then come to Jesus today. Ask Him to forgive you and gain eternal
life in that self-same instant.
 
He is ready, willing, and able, to have you be part of His Kingdom.
He's even gone ahead and prepared a place for you that is just your
own, tailored to your personal tastes and likes. When you see it
you will weep tears of joy. And there is so much more than that
ahead for all put their faith and trust in Him.
 
-----
This is your call to eternity and immortality. It's free for the
asking. No matter what you've done, He's ready to forgive you and
wipe the slate clean like it never happened. He loves you that
much to give you a second chance, even after your sin has grown so
high after these many years.
 
Call upon His name today. Reserve your departure ticket for when
you leave this world. Know that your destination is secure, and
that you have never seen anything like what's coming, that even the
streets there are paved with gold ... so how much more are the many
beautiful things adorned?
 
Call upon His name today and find out.
 
Love you,
Rick C. Hodgin
Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 17 05:37AM

On Mon, 2017-10-16, Richard wrote:
 
>>Interesting. Very specific though. And I have been watching Go very
>>loosely.
 
> Refactoring? More like rewrite.
 
Not even a rewrite: he started out with a program with N features, and
ended up with a library or a microservice for a subset of them.
 
> Not knowing the difference I suppose is par for the course -- many
> people don't seem to understand the difference.
 
> Still, it makes me wonder about the rest of the observations in there.
 
I don't see any real observations related to C++ versus Go/Go!/Golang.
I mostly see a guy who had a chance to do a rewrite from scratch, was
allowed to drop features, and succeeded.
 
His arguments for Go are limited to a supportive community, and it
being easy to start working with.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Melzzzzz <Melzzzzz@zzzzz.com>: Oct 17 06:06AM

> catching newbies into their farms to implement prototypes in easily
> reverse-engineered languages.
 
> Every of those monsters makes most of their own software in C++. ;)
 
Don't forget Rust ;)
 
 
--
press any key to continue or any other to quit...
"Öö Tiib" <ootiib@hot.ee>: Oct 16 11:55PM -0700

On Tuesday, 17 October 2017 09:06:42 UTC+3, Melzzzzz wrote:
> > reverse-engineered languages.
 
> > Every of those monsters makes most of their own software in C++. ;)
 
> Don't forget Rust ;)
 
I think that D and Rust are fair attempts of making "better C++".
Rust is language supported by Mozilla. That moz://a is known to be the
wraith of Netscape. However Rust lacks reflection feature. Run-time
reflection is the typical source of inefficiency and ease of
reverse-engineering.
asetofsymbols@gmail.com: Oct 17 12:38AM -0700

I think that C++ (some subset of it) could be already a better C++. I would like if they extend operators symbol to 10% of unicode symbols: Because the clue of one programming language are, for what I see, 3
all that have something in common with readability
 
And that goes to implement point 2
 
1) do all easily and safety
if that is possible
2) reduce the amount of characters for doing some operation
3) scale well until micro instructions (could be assembly) and toward more hll
asetofsymbols@gmail.com: Oct 17 01:10AM -0700

1) do all easily and safety
if that is possible
 
this would be not possible when there are functions that has to elaborate array, near the machine
as implementing multiprecision number operations
 
But in the hll function safety should be increased
For to be easy: There are operations that could not be easy
so it is perhaps better
 
1) do all as easy and safety as possible in a generic computer language
woodbrian77@gmail.com: Oct 17 09:59AM -0700

On Tuesday, October 17, 2017 at 12:37:52 AM UTC-5, Jorgen Grahn wrote:
> allowed to drop features, and succeeded.
 
> His arguments for Go are limited to a supportive community, and it
> being easy to start working with.
 
After reading that article, some might think C++ was
doomed. C++ has had its ups and downs. I think online
code generation is going to be an increasingly important
part of computing and C++ will be part of that.
 
 
Brian
Ebenezer Enterprises - "America isn't great because America
is powerful. America is powerful because America is great."
Ben Shapiro (dailywire.com)
 
http://webEbenezer.net
scott@slp53.sl.home (Scott Lurndal): Oct 17 06:26PM

>> being easy to start working with.
 
>After reading that article, some might think C++ was
>doomed.
 
Only if one is as moronic as the current american president.
David Brown <david.brown@hesbynett.no>: Oct 17 05:16PM +0200

On 17/10/17 16:56, Stefan Ram wrote:
> specified.
 
> What are the reasons one sometimes prefers undefined
> behavior to implementation-specified behavior?
 
If it is implementation-defined, then the compiler (more accurately, the
compiler authors) has to pick a specific behaviour and document it. If
it is undefined behaviour, then the compiler can produce different
results each time, and it can also assume that the effect never occurs
in order to get better optimisation.
 
Taking your example, if the specs said that "division by 0 has
implementation-defined behaviour", then the compiler would have to give
documented behaviour. This could be to cause a processor trap, to
return 0, to return +inf (for floating point), to return x for x/0. The
compiler authors can pick the behaviour they want to match the
convenience of the hardware, but it must be specified.
 
However, if the hardware has a "div" instruction that is defined as "div
rA, rB, rC" with behaviour "if rB != 0, then rC is set to rA/rB" then
there is a problem. When trying to divide by 0, the behaviour of the
cpu itself is undefined. Perhaps it traps, perhaps it returns a random
value in rC, perhaps it leaves rC untouched. Perhaps the behaviour
depends on cpu flags, or different versions of the processor microcode.
 
The only way the compiler can generate code with definable behaviour is
to add an extra check for divide by 0 first.
 
 
Also, when something is undefined behaviour, the compiler "knows" it
cannot happen. So given this:
 
int foo(int x) {
int y = 100000 / x;
if (x == 0) {
printf("You are dividing by 0!\n");
exit(1);
}
return y;
}
 
the compiler can omit the "if (x == 0)" clause altogether. (It is
different if the check comes /before/ the division, of course.)
 
Some people think such optimisations are a good thing, others think they
are a bad thing - but they are clearly allowed by the way C and C++ work.
 
 
Finally, note that even though the standards may say something is
"undefined behaviour", other things - including compiler documentation,
or additional standards such as POSIX, or a particular target cpu or OS
- are free to define the behaviour. A compiler may, if they authors
desire, define the behaviour of division by 0.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 17 05:04PM +0100

On 17 Oct 2017 14:56:58 GMT
> specified.
 
> What are the reasons one sometimes prefers undefined
> behavior to implementation-specified behavior?
 
§3.12, 3.28 and 3.29 of the C++17 standard defines three behaviors of a
program or parts of a program that cannot automatically be deduced from
the standard itself - implementation-defined behavior, undefined
behavior and unspecified behaviour.
 
Unspecified behavior seems to me to be an oddity. It is similar to
implementation-defined behavior except that the implementation does not
have to document what the behavior is. A program with unspecified
behavior is still "well formed": unspecified behavior is said to be
"behavior, for a well-formed program construct and correct data, that
depends on the implementation", and a note suggests that "the range of
possible behaviors is usually delineated by this International
Standard". I do not fully understand the purpose of having well formed
code which is not required to make known how it will behave before it
is first run.
 
As to why sometimes undefined behavior is preferred to implementation-
defined behavior, I guess it is probably a combination of the
usefulness of requiring a non-mandatory behavior to be documentated, the
difficulty in implementing a particular behavior, and whether
requiring a specified behavior will cause inefficiency in some target
platforms.
 
Probably, speaking to a compiler writer would give you more insight into
the choices made in the standard. Part of it may just be historical.
 
Chris
"James R. Kuyper" <jameskuyper@verizon.net>: Oct 17 12:05PM -0400

On 2017-10-17 10:56, Stefan Ram wrote:
> specified.
 
> What are the reasons one sometimes prefers undefined
> behavior to implementation-specified behavior?
 
Whenever the behavior is unspecified, the standard is supposed to, at
least implicitly, provide a set of different possible behaviors to
choose from. The main reason for preferring undefined behaviour is when
the range of possible behaviors gets too big and complicated to describe
correctly.
 
Example: overwriting the end of an array. On most systems, there's three
main possibilities. Such overwrites might end up writing to protected
memory, causing your program to abort(). That's not particularly
problematic to describe. An unlikely possibility is that it will simply
be a no-op, also easy to describe. However, if memory protection is not
triggered, such attempts will generally cause an arbitrary piece of
memory to be filled in with a representation of the value you provided.
That piece of memory might or might not be currently in use by some
other part of your program, or by some other program. However, that
can't be used as the description of the behavior. That description must
be in terms of what actually happens as a result of that write. What
will happen depends upon how that piece of memory is being used. For
instance, it might contain the code address that the current function
will jump to when it exits, in which case the function will jump to a
location that depends upon what you wrote to that piece of memory. Or it
might contain one of the other variables in your program, causing that
variable to unexpectedly change value. Or it might contain errno, or
argv[0]. Listing all of the possible consequences of writing to an
arbitrary location in memory is simply impossible. The easiest thing
that covers all of those possibilities is "undefined behavior".
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 17 05:13PM +0100

On Tue, 17 Oct 2017 17:04:48 +0100
> the difficulty in implementing a particular behavior, and whether
> requiring a specified behavior will cause inefficiency in some target
> platforms.
 
On reflection I think that the question is in a sense the wrong way
around. Undefined behavior is behavior for which the standard imposes
no requirements. That will always be with us: not everything can be
implementation specified where the standard mandates no particular
behavior. So I guess the question is rather why sometimes
implementation-defined behavior is preferred in the standard to
undefined behavior.
"James R. Kuyper" <jameskuyper@verizon.net>: Oct 17 01:18PM -0400

On 2017-10-17 12:04, Chris Vine wrote:
> Standard". I do not fully understand the purpose of having well formed
> code which is not required to make known how it will behave before it
> is first run.
 
When something is unspecified but not implementation-defined, that
serves as a warning that your code should be prepared to deal with all
of the permitted possibilities. For instance:
 
"All objects with static storage duration shall be initialized (set to
their initial values) before program startup. The manner and timing of
such initialization are otherwise unspecified." (5.1.2p1). That
statement serves to warn you that you should not write code which
depends upon that initialization occurring in a particular manner or timing.
 
"If the return type [of main] is not compatible with int, the
termination status returned to the host environment is unspecified."
(5.1.2.2.3p1). This means that if an implementation chooses to support a
main() that doesn't return int, and if you write a program that takes
advantage of that fact, you should not have any particular expectations
about whether that function will return a successful or unsuccessful
termination status to the host environment. For instance, if you're
using a scripting system that stops executing command lines after the
first command line that returns an unsuccessful status, you should be
equally unsurprised if the script halts, or doesn't halt, after
executing your program. If that would be a problem for your program,
don't write it that way.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 17 07:07PM +0100

On Tue, 17 Oct 2017 13:18:51 -0400
> unsuccessful status, you should be equally unsurprised if the script
> halts, or doesn't halt, after executing your program. If that would
> be a problem for your program, don't write it that way.
 
Those are helpful examples, thank you. Doing a grep on the standard
brings up many similar ones.
 
The common thread seems to be that something reasonable will happen, but
it is not practicable, or not helpful, to say what. I see that these
are described elsewhere in the standard as "the nondeterministic
aspects of the abstract machine".
ram@zedat.fu-berlin.de (Stefan Ram): Oct 17 02:56PM

In several cases of UB, one also could imagine a
hypothetical language, where the behavior would be merely
implementation specified.
 
For example, the division by 0 is undefined behavior, but it
could as well have been defined to be implementation
specified.
 
What are the reasons one sometimes prefers undefined
behavior to implementation-specified behavior?
Daniel <danielaparker@gmail.com>: Oct 16 08:33PM -0700

On Monday, October 16, 2017 at 3:03:24 PM UTC-4, Rick C. Hodgin wrote:
 
> None ...
 
Jesus is calling to you, Rick, that he doesn't want you to spam Usenet.
He wants you to cast your net somewhere else.
 
> the fool ... the foolish
 
"but whosoever shall say, Thou fool, shall be in danger of hell fire."
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 16 10:09PM -0700

On Monday, October 16, 2017 at 11:33:20 PM UTC-4, Daniel wrote:
> On Monday, October 16, 2017 at 3:03:24 PM UTC-4, Rick C. Hodgin wrote:
> > the fool ... the foolish
 
> "but whosoever shall say, Thou fool, shall be in danger of hell fire."
 
I refer to those already called fools and foolish. They are those
who will reject Christ, His teachings, His guidance:
 
https://www.biblegateway.com/passage/?search=Luke+12%3A20-21&version=KJV
20 But God said unto him, Thou fool, this night thy soul
shall be required of thee: then whose shall those
things be, which thou hast provided?
21 So is he that layeth up treasure for himself, and is
not rich toward God.
 
https://www.biblegateway.com/passage/?search=Galatians+3%3A1&version=KJV
1 O foolish Galatians, who hath bewitched you, that ye
should not obey the truth, before whose eyes Jesus
Christ hath been evidently set forth, crucified among
you?
 
You must understand the Bible, not just quote a few memorized
verses from it. To know it requires study and much contemplation.
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 16 10:24PM -0700

On Monday, October 16, 2017 at 5:06:35 PM UTC-4, Öö Tiib wrote:
 
> > None that I am aware of.
 
> What is wrongly then? Christian faith is (as I have read) among most
> popular and accepted on the planet of ours.
 
Jesus makes us fishers of men. We cast out, but we don't know
if we'll catch anything.
 
 
> I did not suggest you to deny your God. All what I tried to tell
> with those questions was that you have to respect other people
> in order to expect them to listen you.
 
It is not me they are not hearing. It is the message. They
will not hear the truth ... so there is nothing I can do except
persist in teaching because for everyone saved, there was also a
time before they were saved.
 
> of your repulsive behavior). Only few fools who have nothing better
> to do like me read you now and then.
 
> That can not be fault of Jesus nor those people.
 
There are two kinds of wisdom: worldly, and spiritually.
 
https://www.biblegateway.com/passage/?search=1+Corinthians+3%3A18&version=KJV
 
18 Let no man deceive himself. If any man among you
seemeth to be wise in this world, let him become a
fool, that he may be wise.
 
The wisdom of God is foolishness to those who are without
spiritual discernment, without the spirit:
 
https://www.biblegateway.com/passage/?search=1+Corinthians+2%3A14&version=KJV
 
14 But the natural man receiveth not the things of the
Spirit of God: for they are foolishness unto him:
neither can he know them, because they are spiritually
discerned.
 
A person must seek the truth, honestly and truly, so that God
will enable them to find it.
 
This current age is fast approaching its end. Biblical signs are
everywhere. Get on board today, while you still can.
 
Thank you,
Rick C. Hodgin
Daniel <danielaparker@gmail.com>: Oct 17 03:33AM -0700

On Tuesday, October 17, 2017 at 1:09:59 AM UTC-4, Rick C. Hodgin wrote:
 
> 20 But Rick said unto him, Thou fool ...
 
Got it!
 
Seriously, Jesus doesn't want you to spam Usenet, Rick.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 17 04:29AM -0700

On Tuesday, October 17, 2017 at 6:33:39 AM UTC-4, Daniel wrote:
> Seriously, Jesus doesn't want you to spam Usenet, Rick.
 
People call it spam today because they cannot imagine a future
day where they will be summoned by name to stand before God and
give an account of their life, being judged for their sin.
 
On that day everyone will know what I tried to do here by pointing
people to Jesus Christ, to ask forgiveness for their sin and be
saved.
 
Until then, all those who are not being saved will continue to
see no value in Jesus Christ, in being saved, and will mock me,
Him, the whole idea as ludicrous, calling on me to stop causing
them harm and annoyance.
 
But God is not constrained by man's sinful state of ignorance
to eternal things. He commands us to follow Him, not sinful
man.
 
These messages are for people's best well-being and future,
Daniel. They will not be voluntarily silenced by me no matter
how many people in pursuit of sin instead of Christ stand up
and say, "Be quiet, Rick."
 
When the Lord calls me Home, then will I be silent on Earth.
Until that time I will continue to point people to the foot of
the cross, teaching them about Jesus offering them eternal life
for free.
 
It is the proper thing to do with one's time.
 
-----
Are you forgiven for your sin? Or will you be cast into Hell?
 
That is the most important question of your life.
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 17 04:45AM -0700

On Tuesday, October 17, 2017 at 6:33:39 AM UTC-4, Daniel wrote:
> On Tuesday, October 17, 2017 at 1:09:59 AM UTC-4, Rick C. Hodgin wrote:
> > 20 But Rick said unto him, Thou fool ...
 
Ever hear about the five who didn't make it, Daniel? They
had the appearance of being Christians, but no substance,
nothing real. Only facades.
 
This parable is about us. Jesus will return and who will
be ready? The one ready today, right now, because we do not
know the time. We must be ready at all times, continually
in service to Him. He is worthy of our life's labor.
 

https://www.biblegateway.com/passage/?search=Matthew+25%3A1-13&version=KJV
1 Then shall the kingdom of heaven be likened unto ten
virgins, which took their lamps, and went forth to
meet the bridegroom.
2 And five of them were wise, and five were foolish.
3 They that were foolish took their lamps, and took
no oil with them:
4 But the wise took oil in their vessels with their lamps.
5 While the bridegroom tarried, they all slumbered and
slept.
6 And at midnight there was a cry made, Behold, the
bridegroom cometh; go ye out to meet him.
7 Then all those virgins arose, and trimmed their lamps.
8 And the foolish said unto the wise, Give us of your oil;
for our lamps are gone out.
9 But the wise answered, saying, Not so; lest there be
not enough for us and you: but go ye rather to them
that sell, and buy for yourselves.
10 And while they went to buy, the bridegroom came; and
they that were ready went in with him to the marriage:
and the door was shut.
11 Afterward came also the other virgins, saying, Lord,
Lord, open to us.
12 But he answered and said, Verily I say unto you, I
know you not.
13 Watch therefore, for ye know neither the day nor the
hour wherein the Son of man cometh.
 
I wish that vs. 10 locking out end on no one. I desire that all
would be saved.
 
People are so beautiful, so amazing. I want every person
set free from sin and thriving in eternity, living "happily ever
after," as it were.
 
Thank you,
Rick C. Hodgin
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)