Monday, October 2, 2017

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

Jerry Stuckle <jstucklex@attglobal.net>: Oct 02 02:08PM -0400


> writefile(j, "123") will fail etc
> v=readfile(j)
> produce error obj for v variable type etc
 
No, j is still a filestream object. It has a state which indicates an
error. But it's type has not changed.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
asetofsymbols@gmail.com: Oct 02 11:52AM -0700

Jerry Stuckle wrote:
 
- show quoted text -
 
No, j is still a filestream object. It has a state which indicates an
error. But it's type has not changed.
-----
I write
Yes j is still a filestream object
and "has a state wich indicates an error" and its type is not changed
 
Ok what about in the filestream class there is too one integer
int e;
If something goes in error with filestream j than it is written
j.e=1
and if j.e==1 than the object j is one error object
for the filestream type
 
If any operator or function is applied on j
first of all it will check if j.e==1 if yes
should produce fail operations and error objects of respective type
of return
 
For exaple String w=j.readline()
should copy in w the error object for the string
(because j.e==1)
 
So w.e==1 too for example
Jerry Stuckle <jstucklex@attglobal.net>: Oct 02 04:55PM -0400

> should copy in w the error object for the string
> (because j.e==1)
 
> So w.e==1 too for example
 
Yes, but that is because the fstream object is behaving properly - it
does not represent a file due to the error state, and does not allow any
operations on the object which require a file representation.
 
It is not an error object. It is a fstream object in an error state.
Something completely different.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
asetofsymbols@gmail.com: Oct 02 03:15PM -0700

For me "error object" is one special object (among all objects can be in its type)
 
one real object with its memory etc all ok, only differ with a bit on, or one its member for example int ==1
 
example for
0..255 type number (8 bit unsigned) would be the value 255
0..0xFFFFFFFF type number error object would be
0xFFFFFFFF
[one should have 0..0xFFFFFFFE for normal value and 0xFFFFFFFF for error ]
for
class name{int e; char*a; u32 sz};
with
name x;
should be the object with x.e==1
(if it is 0 than all ok)
And so on
legalize+jeeves@mail.xmission.com (Richard): Oct 02 05:28PM

[Please do not mail me a copy of your followup]
 
Marcel Mueller <news.5.maazl@spamgourmet.org> spake the secret code
 
>On 01.10.17 12.41, asetofsymbols@gmail.com wrote:
>But why not to use operator new which needs nether a cast nor sizeof?
 
Because naked new/delete is a code smell.
 
Use std::unique_ptr or std::shared_ptr as appropriate (and the vast
majority of the time, you do not need shared_ptr).
 
CppCon 2016: Herb Sutter "Leak-Freedom in C++... By Default"
<https://www.youtube.com/watch?v=JfmTagWcqoE>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
legalize+jeeves@mail.xmission.com (Richard): Oct 02 05:45PM

[Please do not mail me a copy of your followup]
 
(Richard) legalize+jeeves@mail.xmission.com spake the secret code
 
>Use std::unique_ptr or std::shared_ptr as appropriate (and the vast
>majority of the time, you do not need shared_ptr).
 
...and yes, you can use these with custom allocators. Learn how to
write C++ and stop writing C. (Don't use malloc/free.)
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
scott@slp53.sl.home (Scott Lurndal): Oct 02 06:15PM

>>majority of the time, you do not need shared_ptr).
 
>...and yes, you can use these with custom allocators. Learn how to
>write C++ and stop writing C. (Don't use malloc/free.)
 
Or just write code that performs correctly and optimally using any feature of
C++ (including those inherited from C) instead of relying on some
dogmatic approach to C++ programming.
 
And avoid using smart pointers when you care about performance.
Ian Collins <ian-news@hotmail.com>: Oct 03 08:08AM +1300

On 10/ 3/17 01:23 AM, David Brown wrote:
 
> Please - if you want people to help you, then follow Usenet conventions
> and quote properly. Posts without context do not help, nor do mixed
> quotations from different posts at different times.
 
You are wasting your time David. He/She has been posting
incomprehensible gibberish for years.
 
--
Ian
Ian Collins <ian-news@hotmail.com>: Oct 03 08:10AM +1300

On 10/ 3/17 07:15 AM, Scott Lurndal wrote:
> C++ (including those inherited from C) instead of relying on some
> dogmatic approach to C++ programming.
 
> And avoid using smart pointers when you care about performance.
 
Untrue, but one should avoid starting a sentence with "And" :)
 
 
--
Ian
"Öö Tiib" <ootiib@hot.ee>: Oct 02 12:42PM -0700

On Monday, 2 October 2017 21:15:19 UTC+3, Scott Lurndal wrote:
> C++ (including those inherited from C) instead of relying on some
> dogmatic approach to C++ programming.
 
> And avoid using smart pointers when you care about performance.
 
You guys are turning software engineering into some sort of mix of
dark art, magic and religion. :D
 
Everybody know that programmers who care about performance measure
and profile that very performance. Why they do that? Because
mechanical usage of whatever "incantations" be it malloc, free,
new, delete, smart pointers or ignorant pointers does not usually
improve performance. Performance is always improved by using skill
of programmer. Period. ;)
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Oct 02 12:47PM -0700


> This I understand.
 
>> that inform me for leaks and write out heap memory in some places where it should be not written
 
> I am curious how an allocator can report a leaks.
[...]
 
A radically simple and naive way would be that the allocator increments
a counter for each allocation, and decrements for each deallocation.
 
If this counter is not zero when the program terminates, there is a
leak. Stupid simple and naive, but it can help, in a sense.
Paavo Helde <myfirstname@osa.pri.ee>: Oct 03 12:40AM +0300

On 2.10.2017 22:47, Chris M. Thomasson wrote:
> a counter for each allocation, and decrements for each deallocation.
 
> If this counter is not zero when the program terminates, there is a
> leak. Stupid simple and naive, but it can help, in a sense.
 
Depends on the size of the program. If there were 10 million allocations
then knowing that 1000 of them were not freed is not very helpful. Also,
some programs allocate a lot of static or semi-static data structures
which are never freed (just because the OS will do it much better
anyway), so a single number at the end of the program would tell nothing.
 
A leak by definition is something which accumulates. To see the
accumulation you need to run something in a loop and report the
allocator diagnostics after each run. I have found it useful to
instrument the memory allocator so that I can define a bunch of memory
size intervals and a counter for each of them. When I see there is a
leak in some interval I redefine the intervals to be more fine-grained
in that area and rerun the program until I have identified the exact
culprit size(s). With some luck, there are not many places in the
program allocating this exact size and it becomes much simpler to find
the bug.
 
Of course, in proper C++ there are not many possibilities to create
accidental memory leaks, but still I occasionally find some, typically
in places where I have tried to be too clever like using placement new
and forgetting to call the destructor explicitly afterwards.
 
Cheers
Paavo
Paavo Helde <myfirstname@osa.pri.ee>: Oct 03 12:53AM +0300

On 2.10.2017 21:15, Scott Lurndal wrote:
 
> And avoid using smart pointers when you care about performance.
 
Some smart pointers might affect performance when used in a wrong place,
but as a generalization the above is definitely wrong. E.g. using
MT-safe std::shared_ptr in a situation which does not require MT-safety
or shared ownership might indeed be slower than the ideal, but the
solution is to use a more suitable smartpointer, not to throw them all away!
 
Cheers
Paavo
legalize+jeeves@mail.xmission.com (Richard): Oct 02 05:21PM

[Please do not mail me a copy of your followup]
 
*plonk*
 
Maybe you say something useful sometimes, but since you insist on
feeding the trolls and making them post more and more and more, welcome
to my KILLFILE.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 02 12:30PM -0700

Last night, I was listening to a sermon from a church in Hawaii,
and I heard the most amazing thing I've ever heard regarding Jesus
dying on the cross.
 
It was from the communion part of their service published on
YouTube (beginning at 1hr 19m 0s):
 
https://www.youtube.com/watch?v=XQj-_BVAG1U&t=1h19m0s
 
The pastor's talking about the bread and the wine, and how Jesus
said as often as you eat this bread, or drink this wine, do this
in remembrance of me.
 
He teaches of the two elements which came out of Jesus when he
was pierced by a spear at the cross. They were blood and water,
which are also the two elements which come forth when a woman
gives birth.
 
He teaches that it was the birth of the bride of Christ, which
is the church (believers in Jesus Christ), taken from the side
of Christ in His death, just as Adam's bride had been taken
from his side when God put Adam into a deep sleep and made Eve
from his rib. God made Eve for Adam, just as He made His own
bride for Himself.
 
Jesus literally created His own bride by His death on the cross,
birthed at the time of His death, with the seventh wound He
received (two in His feet, two in His hands, one on His back
from the scourging, one on the head from the crown of thorns,
and then one more, the seventh, was the piercing of His side
by the Roman soldiers -- seven is the number of Biblical
completion. It comes up time and time and time again in
Bible scripture, and is significant to God's design).
 
-----
It's the most amazing thing I've ever heard about the full
circle from man's original creation to Christ's redemption of
man, in the same pattern from pre-fall form, to salvation-from-
the-fall form.
 
I've never heard his piercing explained in that way in my
entire life, and even with a tremendous amount of active study
of the Bible since 2004, in listening to sermons, thinking
about these things, searching the matter out, etc.
 
God is so beautiful in what He conveys. You just have to be
looking for it. You just have to be willing to receive it.
 
Thank you,
Rick C. Hodgin
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Oct 02 12:37PM -0700

On 10/2/2017 10:21 AM, Richard wrote:
 
> Maybe you say something useful sometimes, but since you insist on
> feeding the trolls and making them post more and more and more, welcome
> to my KILLFILE.
 
Just joking around wrt the IPU and FSM.
woodbrian77@gmail.com: Oct 02 11:56AM -0700

legalize+jeeves@mail.xmission.com (Richard): Oct 02 05:26PM

[Please do not mail me a copy of your followup]
 
Barry Schwarz <schwarzb@dqel.com> spake the secret code
>that it almost guarantees you will not get a serious discussion about
>the "real" code.
 
>As for me, I just stop reading when I see these abominations.
 
Not only are macros like this annoying, they are completely
unnecessary. Just use std::uint32_t from <cstdint> if you really
insist on specifying the size of your integers.
 
Additionally, your macros are misleading because unsigned/int may not
be 32 bits. The macro for sizeof is just plain obfuscating and serves
no utilitarian purpose.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Jerry Stuckle <jstucklex@attglobal.net>: Oct 02 02:11PM -0400


> Indentation is one art very good
> Align code redundancies is good
> Multiple instruction for line can be very good too
 
That does not mean your experience is correct - and it definitely is not
the style most experienced C++ programmers use.
 
> The best layout on the page
 
> For example the just above code can not be seen by me better than in that way without spaces without indentation it is as one single operation for me, clear in what it can do.
> If someone say the same in plan English it not will be so clear
 
Maybe it can be seen by you better. But most programmers will disagree
with your style. And chances are it would not be allowed on a
multi-programmer project. I wouldn't even allow it in any of the C or
C++ classes I taught.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
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)