|
Super Lloyd wrote: For one thing it has little to do with "object lifecyle"
How could it possibly? Just fire and forget, do anything with an object as you like. Why waste a thought on where an object comes from or what becomes of it? The garbage collector takes care of everything. Until it does not.
Super Lloyd wrote: the only reason for leak in C# is if your referenced by static variable or (though is the same thing in disguise) static event.
If that only were true. Real hacks are excellent at combining things that are not problematic by themselves in a way that leads to maximum chaos.
Would you, for example, see anything wrong with storing controls that have been added dynamically to an ASP.Net page in the session instead of simply constructing new ones when Page.Load() is called? The irony is, that it is the misguided attempt to take control of the control's lifecycles that leads to the memory leak, and not fire and forget.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Super Lloyd wrote: For one thing it has little to do with "object lifecyle"
Perhaps we have a different definition of that term. I have seen problems in both Java and C# where the developers failed to properly account for how an object 'ended'. They had no problem with when the object 'started' but they never considered how to specifically control how it 'ended'.
Matter of fact I suspect that I have seen code that might have that sort of problem just in the past week.
Super Lloyd wrote: FYI, unless you do interop, which is less and less common those days, the only reason for leak in C# is if your referenced by static variable or (though is the same thing in disguise) static event. Or maybe too many live threads which don't die (and all the memory they collect), could typically come from wait handle hanging forever...
Probably been at least 15 years since I worked in a system where at least some threads did not die. Often quite a few of them. At least in Java the server frameworks build that in extensively. Most problems I have seen have been because the developers did not even seem to be aware that they were working in a threaded environment.
Java and C# both have complex thread pool support and the concept has existed since before C# existed. Might have existed before Java but I wasn't introduced to it until after I first used Java. For context I started with Java 1.1.4 (well before 1.4.)
|
|
|
|
|
ThreadPools have been around since long before java's inventor was a gleam in his grandfather's eye.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
CodeWraith wrote: I have also seen an entire team of Java guys sitting around a server that needed a reset every day because their opus hogged memory.
I was told by a number of unix admins that when C/C++ servers were the norm that was the standard operating procedure for any large enterprise. It was something that was planned for when putting the process together for a new server application.
And it wasn't just for memory. File descriptors and sockets also needed to be cleaned up.
|
|
|
|
|
I think to remember for the first windows servers that this was a standard procedure (not daily, but about weekely). This not because of the applications/services but because windows was the problem at that time.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
That's SOP for any data center. Mostly because of the OS, not the applications.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I reckon @CodeWraith answered it quite well, to rephrase it another way:
c, c++, c#, <name your="" favorite="" language=""> does not have memory leaks,
poorly written applications (and libraries) do.
so do the latest features to c++ solve the issues?
No. ...please re-read the statement in bold above.
This internet thing is amazing! Letting people use it: worst idea ever!
|
|
|
|
|
To be honest, I like the "feature" that I as the programmer is responsible for each and every resource and therefore need to pay attention to it. This is a clear straight forward situation and in case I'm not able to take care about the resource management then I better do not program.
Vs. c#, where there are hidden traps ... I need to take care e.g. wether sometng is IDisponable or not and so on. Case by case, not straight forward.
Only my 2 cents.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Yep, combo of std::unique_ptr, std::shared_ptr and std::weak_ptr are very good. I much prefer to use these than the IDispose pattern but I spend 80% time doing c++ and 20% doing c#
|
|
|
|
|
I was reading this article about how terrible JavaScript is:
The JavaScript phenomenon is a mass psychosis – Hacker Noon[^]
It got me thinking that the only reason that it stays around, to say nothing of its utter ubiquity nowadays, is because everyone uses it, and so everyone continues to use it because it would be too much of a pain to stop using it - which seems to me to be the definition of "technical debt".
|
|
|
|
|
|
Over time, curious to see what sort of adoption rate this gets. With Node.js, utilization of JavaScript seemed to be spreading instead of dying out (like it should).
The trend lately seems towards non-type-safe languages (like JavaScript and Python).
I'm hoping for a reversal in trend. Maybe WASM will help 
|
|
|
|
|
|
|
In 1995, Netscape Communications recruited Brendan Eich with the goal of embedding the Scheme programming language into its Netscape Navigator.Before he could get started, Netscape Communications collaborated with Sun Microsystems to include in Netscape Navigator Sun's more static programming language Java, in order to compete with Microsoft for user adoption of Web technologies and platforms.Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax, which excluded adopting other languages such as Perl, Python, TCL, or Scheme. To defend the idea of JavaScript against competing proposals, the company needed a prototype. Eich wrote one in 10 days, in May 1995.
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Article complains about JS then mentions Java in the list of better languages...  Not by much if at all. But even though TS is a temporary band-aid over the language in my opinion, framework hell isn't going anywhere 
|
|
|
|
|
Message Removed
modified 26-Aug-18 18:03pm.
|
|
|
|
|
Message Removed
modified 26-Aug-18 18:03pm.
|
|
|
|
|
Message Removed
modified 26-Aug-18 18:03pm.
|
|
|
|
|
Message Removed
modified 26-Aug-18 18:03pm.
|
|
|
|
|
Message Removed
modified 26-Aug-18 18:03pm.
|
|
|
|
|
Message Removed
modified 24-Aug-18 11:59am.
|
|
|
|
|
|
The goat has turned into a jellyfish !
|
|
|
|
|
I had my fruit basket stolen – I was left peachless.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
