Saturday, May 4, 2019

Digest for comp.lang.c++@googlegroups.com - 18 updates in 4 topics

Ian Collins <ian-news@hotmail.com>: May 04 11:42AM +1200

On 04/05/2019 10:36, Scott Lurndal wrote:
 
> I beg your pardon. I wasn't aware that smart pointers were part of C++
> back in 1989 when we used a language called C++ to write an operating system
> for a massively parallel processing system called OPUS.
 
Smart pointers have been part of C++ programming since C++ had automatic
object destruction; which it always has. I may not have been using C++
in 1989 (I didn't start until around 1990) but one of the features that
attracted me from C to C++ was the ability to manage memory and other
resources with objects.
 
> simply returning from the fork function caused the destructor to run which cleaned up
> the partially allocated new process as it automatically ran the destructor for the local stack
> instance of the cleanup class.
 
You got it backwards, smart pointers are an example of RAII. They could
be described as the canonical example of RAII.
 
> Even then, allocate in constructor, deallocate in destructor works just fine
> without smart pointers.
 
Which is exactly what a smart pointer does, so I don't see your point.
 
--
Ian.
Manfred <noname@add.invalid>: May 04 01:49AM +0200

On 5/3/2019 10:52 PM, Vir Campestris wrote:
 
> It is not impossible. I have an Android based satnav that has to be
> rebooted every couple of weeks...
 
> Andy
 
Apropos 'harder'...
In C# exposing a COM object and having it properly Release()'d is
surprisingly hard.
Melzzzzz <Melzzzzz@zzzzz.com>: May 03 11:50PM


> I beg your pardon. I wasn't aware that smart pointers were part of C++
> back in 1989 when we used a language called C++ to write an operating system
> for a massively parallel processing system called OPUS.
 
In 1989? CFront? C++ in 1989 was not C++ of today. I can imagine what
that code looked like :P
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Melzzzzz <Melzzzzz@zzzzz.com>: May 03 11:53PM

> in 1989 (I didn't start until around 1990) but one of the features that
> attracted me from C to C++ was the ability to manage memory and other
> resources with objects.
 
Heh, I started to learn it around 1993-4 can't remember, but haven't use
it for anything seriously until 1999 ;)
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Paavo Helde <myfirstname@osa.pri.ee>: May 04 08:34AM +0300

On 3.05.2019 23:22, Thiago Adams wrote:
>> diligence.
 
> Just add some memory leak detector and you will be disciplined.
> It is very easy to create one and use in debug.
 
Easy in toy programs, you mean. It only catches the leaks which are
triggered by the tests for which you have time to run through in this
mode. And it produces false alarms for long-lived static data
structures. And it expands the process memory so it might not fit in RAM
any more. Etc, etc.
James Kuyper <jameskuyper@alumni.caltech.edu>: May 04 07:14AM -0400

On 5/4/19 1:34 AM, Paavo Helde wrote:
> On 3.05.2019 23:22, Thiago Adams wrote:
...
> triggered by the tests for which you have time to run through in this
> mode. And it produces false alarms for long-lived static data
> structures.
 
What algorithm would a memory leak detector use that would confuse
"long-lived static data structures" for allocated memory?
 
The only things I would bother calling proper "memory leak detectors"
are integrated into the memory allocation and deallocation routines, and
as such always know precisely which pieces of memory are dynamically
allocated, and which are not (or at least, in the event of heap
corruption, are no more confused than those routines themselves would be).
wyniijj@gmail.com: May 04 06:24AM -0700

wyn...@gmail.com於 2019年5月3日星期五 UTC+8下午10時27分22秒寫道：
> cerr << "Unknow throw type" MY_ENDL;
> throw;
> };
 
Correction:
1.The last tow "OK" should be "Ok"
2."catch(Errno e)" should be "catch(Errno& e)"
3.socket can't be constructed from "fpath"
 
But, have you noticed that the basic of 'My' filesystem API is easy to grasped.
Compared with standard library, from my point of view, no need to add that
many "implementational" names (and the accompanying rules).
 
From mathematical point of view, new names reduce reuse-ability of existing
names(components). Optimization-ability, along with other quality might
as well be sabotaged.
wyniijj@gmail.com: May 04 06:59AM -0700

Ian Collins於 2019年5月4日星期六 UTC+8上午7時42分20秒寫道：
 
> Which is exactly what a smart pointer does, so I don't see your point.
 
> --
> Ian.
 
I guess what Scott said is similar to what I do currently, e.g.
 
My::RegFile regf("tmpfile", O_CREAT|O_TRUNC|O_RDWR, S_IRUSR|S_IWUSR);
My::AtDestroy<My::Errno,const char*> rrad(My::unlink,regf);
...
 
Class AtDestroy collects info. needed to call resource release function
(RRAD Resource Release At Destruction), which may be ::free(), delete,
::clost(int), ::freeaddrinfo, unlock...
However, such usecase is not often encountered but necessary.
Paavo Helde <myfirstname@osa.pri.ee>: May 04 11:27PM +0300

On 4.05.2019 14:14, James Kuyper wrote:
>> structures.
 
> What algorithm would a memory leak detector use that would confuse
> "long-lived static data structures" for allocated memory?
 
The one posted by grandparent which just redefines malloc/new and
instruments each call in the same way.
 
> as such always know precisely which pieces of memory are dynamically
> allocated, and which are not (or at least, in the event of heap
> corruption, are no more confused than those routines themselves would be).
 
The static data structures I talked about are allocated dynamically.
Rough example:
 
static std::map<std::string, std::shared_ptr<Module>> gTheGlobalMap;
 
int main() {
InitGlobalMap(gTheGlobalMap); // many dynamic allocations
RegisterPlugins(gTheGlobalMap); // many dynamic allocations
while (!terminated) {
ServiceRequests();
}
}
 
As long as the global map contents exist these are considered as
"leaked" by such a leak detection tool. In the program end it might get
deleted so it might make the picture clearer, but to be honest there
would no point in destroying such a global map, as it just makes the
program shutdown slower. So some programs and some third-party libraries
may skip the deletion step, causing a huge avalanche of false alarms
where real leaks are lost in. Been there, seen that.
 
Alas, the leaks may appear and cause problems long before the program
end. And in some cases the leaks are not leaks "by definition", but just
some hierarchic data structure which tend to grow indefinitely, eating
up all the memory and crashing the program all the same, not caring
about if somebody defines them as leaks or not. Such offenders might be
even nicely destroyed at the program end, making it impossible to
discover at the program end. Been there, seen that.
 
Yes, you can instrument the memory allocation calls, and you can detect
leaks that way, but in large and complicated programs it would not be so
simple and not so easy (hint: a statistic analysis of allocations' size
distribution might appear useful).
Manfred <noname@add.invalid>: May 04 07:02PM +0200

On 5/3/2019 7:53 AM, Öö Tiib wrote:
 
> Perhaps you haven't put it clearly forward that you dislike Leigh's ways
> of "fighting" with religious spam even more than religious spam that
> you also dislike?
 
I see a reason for that (even if I tend to keep out of this stuff at
least it is a reason for me): however annoyingly off-topic Rick's posts
may be, I have seen enough of Flibble's replies be straight rude and
insulting to dislike them even more.
 
Both of them represent one kind of attitude that justifies restricting
internet freedom.
And freedom (of speech) is a precious value, it shouldn't be wasted this
way.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 04 06:52PM +0100

On 04/05/2019 18:02, Manfred wrote:
> it is a reason for me): however annoyingly off-topic Rick's posts may be,
> I have seen enough of Flibble's replies be straight rude and insulting to
> dislike them even more.
 
That's nice, dear. Now run along to your padded cell and play with your legos.
 
/Flibble
 
--
"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," 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."
Richard Damon <Richard@Damon-Family.org>: May 04 03:05PM -0400

On 4/27/19 12:23 PM, peteolcott wrote:
> sequence of
> valid deductions from true premises to a true conclusion)  thus unlike the
> formal proofs of symbolic logic provability cannot diverge from truth.
 
I will admit that I haven't followed this thread closely, but to me this
seems to imply that this 'sound deductive inference model' must be
somewhat weak in what it can express to be able to make such a claim.
 
Yes, there are many statements which are provable true, and this can be
shown with a valid proof from true premises and valid inferences leading
to the conclusion. There are also many statements which are provable
false, as you can prove their converse.
 
If the logic system is sufficiently rich in capability, it would seem
like, in general, proving that something can not be proven true or false
is not easy, so it would seem hard to determine that something is
'unsound'. The issue is that there can be an incredibly large number of
possible paths to combine known true premises with valid deductions to
get more statements that are provably true, which can be combined with
each other to get even more provably true statement. To be able to say
that it will be impossible to find a path to the specified statement
seems hard, unless the logic system is naturally weak and able to prove
only a very limited set of statements.
 
A great example of this would be the Four Color Map Theorem. For a very
long time it was 'Unproved' and thus would seem to be declared 'Unsound'
by this logic, but was eventually proved true.
peteolcott <Here@Home>: May 04 03:07PM -0500

On 5/4/2019 2:05 PM, Richard Damon wrote:
 
> I will admit that I haven't followed this thread closely, but to me this
> seems to imply that this 'sound deductive inference model' must be
> somewhat weak in what it can express to be able to make such a claim.
 
Deductively Sound Formal Proofs
https://www.researchgate.net/publication/332864362_Deductively_Sound_Formal_Proofs
 
It simply filters out semantically incoherent expressions of language.
These expressions were not filtered out previously because formal systems
ignored semantic constraints.
 
> shown with a valid proof from true premises and valid inferences leading
> to the conclusion. There are also many statements which are provable
> false, as you can prove their converse.
 
Every closed WFF left over is semantically incoherent.
 
> like, in general, proving that something can not be proven true or false
> is not easy, so it would seem hard to determine that something is
> 'unsound'.
 
Its all in my linked one page paper.
 
> that it will be impossible to find a path to the specified statement
> seems hard, unless the logic system is naturally weak and able to prove
> only a very limited set of statements.
 
If we simply leap to the chase:
∃F ∈ Formal_System ∃G ∈ Closed_WFF(F) (G ↔ ((F ⊬ G) ∧ (F ⊬ ¬G)))
The above logic sentence asserts that there are some closed WFF that
are neither true or false.
 
Axiom Schema(3) Deductively_Sound_Consequence(x) ↔ (True(x) ∨ False(x))
excludes expressions of language that do not evaluate to true or false
as not belonging to the set of deductively sound consequences.
 
 
--
Copyright 2019 Pete Olcott All rights reserved
 
"Great spirits have always encountered violent
opposition from mediocre minds." Albert Einstein
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 04 02:38PM +0200

On 03.05.2019 20:51, Bart wrote:
 
> But since 'abc' is actually being defined here, it is confusing:
 
> * Is this whole definition itself inside 'foo'? (If so, then why have
> foo::?)
 
No it's outside.
 
 
> * Is this definition, despite being inside it its own namespace,
> defining a function belonging to another? (And if so, why? Why can't it
> be defined inside foo:: ?)
 
Some people prefer this way, defining a function `foo::abc`, because if
`abc` hasn't previously been declared in namespace `foo` then they will
get a compilation error.
 
So that's a way of automating the checking that the definition
correspond exactly to a previous declaration.
 
 
> * Or does foo:: here mean that every unresolved identifier inside the
> function should be searched for inside foo?
 
No no. :D
 
Though it has that effect too, by virtue of `abc` belonging to (having
been declared there) namespace `foo`.
 
 
Cheers & hth.,
 
- Alf
Manfred <noname@add.invalid>: May 04 06:40PM +0200

On 5/3/2019 3:40 PM, Öö Tiib wrote:
> }
 
> // ...
 
> }
 
This is equivalent, yet preferable, IMO.
Since this is a /definition/ of fancyFunction, it has to be coded in the
context of foo; often this will happen together with other functions, in
which case it is clearly better to embrace them all inside namespace foo
{ ... }.
And then, for uniformity, even in the rare case of a single function (in
a translation unit) this syntax is preferable to me.
Richard Damon <Richard@Damon-Family.org>: May 04 02:26PM -0400

On 5/3/19 2:54 AM, Öö Tiib wrote:
 
> IOW the rules can be set so that it is always clear enough from
> what namespace a name comes and then there is no need to
> stutter about "foo" within "foo".
 
int n = bar() (inside a function in the foo:: namespace) doesn't say
that bar MUST come the foo:: namespace, it will come from the foo::
namespace if one exists, or if not, it could come from the global
namespace, or from any namespace that has been imported or from which a
bar has been imported with a using declaration. Adding the foo:: prefix
makes it clearer that this function HAS been defined in the foo::
namespace. I thought that this might even be required if there has been
something like a using baz::bar(); statement as now an unadorned bar()
call is ambiguous.
 
You might even need to use a ::foo:: prefix if some namespace that has
been imported with using has a foo namespace inside of it, so their is
ambiguity between ::foo::bar() and ::baz::foo::bar()
rick.c.hodgin@gmail.com: May 04 03:20AM -0700

Came across this today. Do you seek the truth? Do you want to know the
truth, or are you content believing whatever you believe without knowing
if it's the truth or not?
 
https://mobile.twitter.com/ShapedByTruth/status/1124541930271121409
 
All who seek the truth will find it, because God Himself personally will
bring it to you.
 
Seek the truth ... And live.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 04 02:45PM +0100


> All who seek the truth will find it, because God Himself personally will
> bring it to you.
 
> Seek the truth ... And live.
 
And Satan invented fossils, yes?
 
/Flibble
 
--
"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," 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."
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)