Tuesday, January 23, 2018

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

asetofsymbols@gmail.com: Jan 23 01:35PM -0800

I will speak more, and would organize preaching on Bible: but I am lazy and don't like to speak too much... I think this is one my error
 
Now as now I would say of save well, old Bibles because the new traductions seems to me not so good; and read only Bible + technical ( Mathematic physic informatics) books; because other book, philosophers the first and news paper have evil thinks
"James R. Kuyper" <jameskuyper@verizon.net>: Jan 23 09:28AM -0500

On 01/21/2018 01:41 PM, Melzzzzz wrote:
> On 2018-01-21, James Kuyper <jameskuyper@verizon.net> wrote:
...
>> array, so the implicit destructor should be a nop, with no failure modes
>> of it's own. What else can I check?
 
> Care to show that new/delete in question?
 
Sorry - yours was the very first response, and I just breezed past it
without making a response. To be fair, I didn't see how the answer would
be particularly useful, but here it is:
 
// Allocate continuous 2-dim engdata array
uint8_t **engdata = new uint8_t *[maxsc];
engdata[0] = new uint8_t[9318*maxsc];
for (int i=1; i<maxsc; i++) engdata[i] = engdata[i-1] + 9318;
...
 
delete[] engdata[0];
delete[] engdata;
 
Note, in particular, the use of the "magic number" 9318. Lovely code.
"James R. Kuyper" <jameskuyper@verizon.net>: Jan 23 09:33AM -0500

On 01/22/2018 10:21 AM, Scott Lurndal wrote:
> the abort(3) and/or raise(3) library functions. In other words,
> the application (or one of its libraries) are causing the abort
> (perhaps via an assertion failure).
 
I eventually learned that the abort() was the result of an assert() in a
free() wrapper triggered when it detected memory corruption. I hadn't
known that the program was linked to such a utility, and wouldn't have
been sure that delete would be implemented in terms of free(). By the
time I found that out, I'd already located the corrupting statement.
"James R. Kuyper" <jameskuyper@verizon.net>: Jan 23 09:43AM -0500

On 01/22/2018 04:07 AM, Paavo Helde wrote:
> breakpoint 4 or 8 bytes *before* the array, where the memory allocator
> control block resides. Now continue the run and voila, the data
> breakpoint ought to be triggered exactly by the culprit buffer overrun code.
 
I've used precisely that approach before with C code, but somehow I
didn't think of doing it when working with C++ code. It worked
perfectly. A different array with room for 513 packets was dynamically
allocated prior to the one whose deletion aborted. 513 is the absolute
maximum number of packets that could validly be collected during one
scan of data (and it's used as a "magic number" in several locations in
the code, with no corresponding named macro). The code added packets to
the array without bothering to test for the end of the array. Due to an
error in a different piece of code, there were actually 959 packets in
one particular scan, and the code just kept merrily adding them to it.
I'm amazed that execution of the code ever successfully reached the
delete statement, I would have expected something else to go
catastrophically wrong first.
Paavo Helde <myfirstname@osa.pri.ee>: Jan 23 05:07PM +0200

On 23.01.2018 16:43, James R. Kuyper wrote:
> I'm amazed that execution of the code ever successfully reached the
> delete statement, I would have expected something else to go
> catastrophically wrong first.
 
Glad to hear you found the bug!
 
C++ memory management is often just a thin wrapper around
malloc()/free() and even if it isn't there is a good chance that there
is still some kind of a control block before the allocated array which
can get corrupted, so that this debugging technique still works.
 
Cheers
Paavo
Gareth Owen <gwowen@gmail.com>: Jan 23 09:35PM


> I'm amazed that execution of the code ever successfully reached the
> delete statement, I would have expected something else to go
> catastrophically wrong first.
 
Oh, it did. Sometimes the most catastrophic that can possibly happen is
for the code to keep happily running :)
Gert-Jan de Vos <gert-jan.de.vos@onsneteindhoven.nl>: Jan 23 12:53PM -0800

Whenever I use fstream for file IO, I have to look up the details on
how to detect IO errors like file not found, access violation or disk
full. Sometimes I need to check failbit or badbit, sometimes only
badbit and I can't remember when to choose what.
 
Ideally I would like to get exceptions with the OS error details
included as proposed in N2503. Unfortunately with MSVC2017
I just get "iostream error" in the exception object.
 
In an attempt to improve the error message detail level, I
implemented a winfile_streambuf directly on the Win32
CreateFile/ReadFile/WriteFile api's. On an IO error It throws an
exception which includes the os error details. This now works
and improves the file IO error messages, but it wasn't exactly
trivial to implement. This leaves me with a number of questions:
 
- Is there really no straightforward way to get IO error details
from fstream?
 
- Is it allowed for an streambuf implementation to throw?
 
- should my winfile_streambuf differentiate between default
and binary mode? I did this with a textmode_streambuf
adapter.
 
- My copy of the Josuttis Standard Library book contains one
example of a custom input stream buffer. It calls setg() to
initialize the putback area as empty (eback() == gptr()). Is this
correct? I guess eback() should be less that gptr() to allow for
character putback.
 
- What is file_streambuf<wchar_t> supposed to do? I guessed
it would read or write a sequence of wchar_t in a file. Yet
std::wofstream produces a file with 8 bit characters, just like
std::ofstream does.
 
I learned a lot about the iostream architecture during this
exercise but I'm not yet sure if I'm on the right track. I'm
interested to hear on your thoughts or experiences with
iostreams and IO error detection.
cdalten@gmail.com: Jan 23 01:19PM -0800

Based on my limited experience, well, I don't think this is a good idea. Because my last project at work involved helping write a wireless network interface. And based on this gawd awful programming experience, getting the details from the exception object would have been misleading at the very best.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 23 07:15PM

"The problem with today's world is that everyone believes they have the
right to express their opinion AND have others listen to it.
 
The correct statement of individual rights is that everyone has the
right to an opinion, but crucially, that opinion can be roundly ignored
and even made fun of, particularly if it is demonstrably nonsense!" --
Brian Cox
 
--
 
Thank you,
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 23 11:25AM -0800

On Tuesday, January 23, 2018 at 2:15:57 PM UTC-5, Rick C. Hodgin wrote:
 
> --
 
> Thank you,
> Rick C. Hodgin
 
I, the real Rick C. Hodgin, did not write this post. It is written
by someone impersonating me.
 
Examine the headers and you will see the source of all posts which
are written under my name.
 
Every post I write about Jesus going forward will be tagged with [Jesus
Loves You], and will include text which points to Jesus Christ, the
Bible, our personal need of Him, our guilt in sin, His willingness to
forgive our sin, and how to obtain that forgiveness and eternal life.
 
The word "gospel" means "good news." When people share the gospel
message with you, it is the good news that God has made peace with
man, and that you too can be saved from judgment for your sin.
 
I urge each of you to check this out, and you will learn why sinful
men and women step forward and attack the messenger. They cannot
change the message, so they try to trick and deceive you into some
falseness ... but that falseness will not stand on that final day.
And everyone who embraces that falseness will be cast into the eternal
lake of fire, from which there are no do-overs, no second chances, no
paroles.
 
Sin carries with it a death sentence ... and not just death in our
physical bodies, but spiritual death. And because we are eternal
beings, the spiritual death there goes on for eternity, meaning total
confinement and isolation from everything in God's universe, wrapped
up in torment and agony so encompassing you will never have another
thought about anything else ever again -- the only punishment suitable
for an eternal being of great power and majesty, made in the very
image and likeness of God, who rejects truth, and embraces falseness.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 23 11:41AM -0800

On Tuesday, January 23, 2018 at 2:15:57 PM UTC-5, <strike>Rick C.
Hodgin</strike>Leigh Johnston wrote:
> right to an opinion, but crucially, that opinion can be roundly ignored
> and even made fun of, particularly if it is demonstrably nonsense!" --
> Brian Cox
 
Here's the fundamental problem you possess, Leigh:
 
You think only in Earthly terms.
 
You do not have a thought given to eternity, or that there could be a
real eternal God. Because of that your perspectives are skewed and you
are able to believe lies because all you see is this world and within
the confines of this limited existence what you believe may be true.
 
But there is more. And until you realize that, you will remain on the
wholly wrong path.
 
--
Rick C. Hodgin
scott@slp53.sl.home (Scott Lurndal): Jan 23 07:56PM


>I, the real Rick C. Hodgin, did not write this post.
 
NOBODY CARES.
 
>It is written
>by someone impersonating me.
 
If you shut up, stop posting or set yourself on fire, they'll
stop.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 23 12:18PM -0800

On Tuesday, January 23, 2018 at 2:57:12 PM UTC-5, Scott Lurndal wrote:
> >by someone impersonating me.
 
> If you shut up, stop posting or set yourself on fire, they'll
> stop.
 
If tyranny guides the course of a person's life, they wind up being
led by the strongest bullies with the most evil guidance.
 
The goal of each Christian is to teach people the truth. It's a
high calling because mockers will always be here with us until the
day the Lord returns. We are not to be guided by them and their
purposes in silencing us and His message, but rather we are to live
for Christ, to take up our cross daily and follow Him and His many
purposes for our lives ... all of which stem back, in one way or
another, to teaching people the truth.
 
--
Rick C. Hodgin
Real Troll <real.troll@trolls.com>: Jan 23 02:25PM -0400

Few weeks ago somebody asked a question about formatting numbers with
commas or some locale customs. The short answer is it can be done as in
this example:
 
<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
 
// imbue example
#include <iostream> // std::cout
#include <locale> // std::locale
 
using namespace std;
 
int main()
{
locale mylocale(""); // get global locale
cout.imbue(mylocale); // imbue global locale
cout << 1000000 << endl;
return 0;
}
 
<+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
 
This code works in all versions of Visual Studio since 2010 but none of
the Embarcadero products support this!!
 
I haven't tested this in other compilers yet. The result of the above
program should be:
 
1,000,000
 
NOT 1000000.
Paavo Helde <myfirstname@osa.pri.ee>: Jan 23 09:30PM +0200

On 23.01.2018 20:25, Real Troll wrote:
> program should be:
 
> 1,000,000
 
> NOT 1000000.
 
Depends on the locale. I just tested it and on my machine the output is:
 
1á000á000
 
This is not even close to anything expected. I don't even feel like
curious any more where and how it goes wrong. IMO all the locale stuff
is just misfeatures, starting from the hidden global state up to just
not working at all. In my code I have spent lots of efforts to avoid any
locale-dependent behavior. The last occasion was when I discovered that
stricmp() appears in the profiler output, in a program which ought to
just crunch numbers basically.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 23 02:34PM -0500

On 01/23/2018 01:25 PM, Real Troll wrote:
> program should be:
 
> 1,000,000
 
> NOT 1000000.
 
Can you write your own algorithm and move on? It's a quick task.
 
--
Thank you, | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician
Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA
mcheung63@gmail.com: Jan 23 03:05AM -0800

Rick C. Hodgin於 2018年1月23日星期二 UTC+8上午3時00分44秒寫道：
 
> --
 
> Thank you,
> Rick C. Hodgin
 
FUCK OFF ASSHOLE
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 23 07:42AM -0800


> > Thank you,
> > Rick C. Hodgin
 
> .. .. ..
 
Peter, you replied to someone impersonating me.
 
Impersonation posts are very confusing to people. They're an attack
against everybody, but all of the harm done for those posts is credited
back to the person doing the impersonation, and not the ones being in-
jured by the impersonation, though those injuries are real, and increase
the degree to which the impersonator is held accountable.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 23 05:53PM

On 23/01/2018 15:42, Rick C. Hodgin wrote:
> back to the person doing the impersonation, and not the ones being in-
> jured by the impersonation, though those injuries are real, and increase
> the degree to which the impersonator is held accountable.
 
Be careful Rick, slander is illegal and, unlike impersonation/identity
theft, satire in the form of mimicry is not. Every satirical post I
have made mimicking you has had the following Usenet header field:
 
Organisation: Rick C. Hodgin Enterprises
 
If I wanted to impersonate/commit identity theft I wouldn't have
included that header field. When satirising a public figure (and you
have put yourself into the public sphere with your spam (see below)) one
has to take on the outward appearance of that individual in some way and
unfortunately for the medium of Usenet that means posting using your
name/e-mail address as an alias; the satirical effect would be lost if
this was not done. If you can suggest a better way to satirise your bad
behaviour in this Usenet newsgroup then I am all ears.
 
I have made the offer on several occasions (which I make again now) that
the satirical Usenet posts will stop when you stop spamming this
technical Usenet newsgroup with your religious nonsense: this spam is
disruption that nobody except you wants.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jan 23 10:24AM -0800

On Tuesday, January 23, 2018 at 12:54:21 PM UTC-5, Mr Flibble wrote:
> theft, satire in the form of mimicry is not. Every satirical post I
> have made mimicking you has had the following Usenet header field:
 
> Organisation: Rick C. Hodgin Enterprises
 
You are a coward and an identity thief. You are unwilling or unable
(due to your cowardice) to stand upon your own two feet, and use your
own mouth under your own identity, and state your beliefs. Instead,
you step forward wearing a mask and espouse nothing but mockery and
hate toward that which is truly most precious in this universe ...
your very Creator, the very Lord I try and teach you about.
 
You ignore the teachings and proceed forward in your own ignorance
and twisted beliefs.
 
Oh how I pray for you, Leigh, because today I fear for your soul.
 
--
Rick C. Hodgin
Juha Nieminen <nospam@thanks.invalid>: Jan 23 07:11AM

> AIM: To copy a file
 
You could use filesystem::copy_file() in the new TS.
Chances are that it will be more efficient than anything
you could implement (at least with standard C++).
Juha Nieminen <nospam@thanks.invalid>: Jan 23 07:15AM

> arnuld <sunrise@invalid.address> wrote:
>> AIM: To copy a file
 
> You could use filesystem::copy_file() in the new TS.
 
I meant to say C++17. I don't know why I wrote "TS". It's not a TS anymore.
Juha Nieminen <nospam@thanks.invalid>: Jan 23 07:07AM

> GigaNews was not breaking any laws, but only violating their
> own stated public policy, apparently not an act of fraud in
> Texas.
 
Excellent! Now fuck off.
Christian Gollwitzer <auriocus@gmx.de>: Jan 23 07:44AM +0100

Am 22.01.18 um 14:24 schrieb arnuld:
> cout << "arr[" << i << "][" << j << "] = arr[" << arr[i] << "["
> << arr[j] << "]\n";
> //cout << arr[i][j] << " ";
 
Replace this line by:
 
cout << "arr[" << i << "][" << j << "] = " << arr[i] << "["
<< j << "] = " <<arr[i][j] << std::endl;
 
to see how the compiler resolves the expression a[i][j]
 
> }
 
> return 0;
> }
 
Christian
ram@zedat.fu-berlin.de (Stefan Ram): Jan 23 12:03AM

Barry Schwarz <schwarzb@dqel.com> writes: When an
>expression is evaluated as the operand of an operator, the result is a
>value that has a type.
 
Ignoring the preprocessor and templates, the type of each
expression already is know from the source text.
The expression does not have to be evaluated to get to know
the type. So, some say that in C, expressions have a type,
not values.
 
With preprocessors and templates, the type information can
be shifted from the source-text model to the compile-time
model, but still not to the run-time model.
 
An exception should be objects of derived classes, who
indeed might have a run-time type, while the /expressions/
for those objects still have a compile-time type.
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)