|
I've once managed to create a memory leak in Mono by creating an object in an event handler and using the object in another event handler. Worked fine in .NET, ran over on RPi in Mono. Granted, the code hasn't been clear to begin with.
|
|
|
|
|
Sorry, I don't remember what you just said...
enum HumanBool { Yes, No, Maybe, Perhaps, Probably, ProbablyNot, MostLikely, MostUnlikely, HellYes, HellNo, Wtf }
|
|
|
|
|
I once spent close to three months eliminating leaks from a C#/WPF application. There were basically two sources of leaks.
One were the false optimizations I had done as a matter of course due to my prior experience as a C++ programmer. I tended to cache resources, which caused them to leak event handlers and such. I also found that data bindings constructed in code rather than XAML leaked, and had to be cleared manually when you were done.
The second were the WPF flow document and page navigation mechanisms. Both of them leaked horribly - several megabytes per operation. I replaced them with HTML/WebBrowser (which leaks, but much less) and a home-grown navigation mechanism.
When I thought I had all of the leaks figured out, I ran the app over a four day weekend with a tiny test driver that navigated randomly through the UI every couple of seconds. When I came in, the app was still running and had peaked at 400MB, which wasn't bad considered it took up 275MB just starting up. All of the leaks were attributable to the WebBrowser control.
Many thanks to the folks at SciTech Software for .NET Memory Profiler.
Software Zen: delete this;
|
|
|
|
|
This may not address your issue, but I address memory leaks as a preventive process, and have done so going back to VB6 days. In short, I clean up my resources and objects before I allow an instance of a class to go away.
In C#, I almost ALWAYS use try-catch-finally. I declare an object as null before "try", instantiate it in the try code block, catch any exceptions (a whole other discussion), then clean up my objects in the finally block. If they have a Dispose or Clear method, I execute that then set the variable to null. No waiting on the GC or coding shortcuts like "using" that get compiled as try-catch-finally anyway.
If my class has an class-level objects, I use my Dispose template that also includes the finalizer.
Since taking this approach years ago (which is mostly copy and paste snippets), the little added effort has helped me to have zero memory leaks, and as an added bonus (that "catch" thing again), I get excellent debugging info.
Sometimes consistency in how we code eliminates a lot of problems later.
|
|
|
|
|
In C#, I almost ALWAYS use try-catch-finally.
That's the "Padre Nostro" of alldays.
|
|
|
|
|
(Cue Alec Guiness) I've been writing C and C++ for a long time... a long time. I thought the preprocessor was my bitch. I had some code that compiles only for debug that I wanted removed temporarily, so I did this:
#if defined(_DEBUG) && false
#endif Not only does the VS2008 (don't ask) compiler not like that [1>.\Document.cpp(1216) : fatal error C1017: invalid integer constant expression] , it's actually right! The #if expression is integral, not a boolean.
You have to do this:
#if defined(_DEBUG) && FALSE
#endif (in the Windows world anyway), or this
#if defined(_DEBUG) && 0
#endif to get the effect I wanted.
Software Zen: delete this;
|
|
|
|
|
Another quote by Alec Guinness: Quote: Who is more foolish? The fool or the fool that follows it?
|
|
|
|
|
One of the disadvantages of being an old bull is that you've been in both positions many, many times.
Software Zen: delete this;
|
|
|
|
|
This is a good one and you wrote it up clearly too.
I like to read about stuff like this. Quite interesting.
The interesting thing of course is also that false (bool) and FALSE (0) are two different things.
|
|
|
|
|
raddevus wrote: false (bool) and FALSE (0) are two different things Yes indeed, a notion I noticed a month or two back in this very forum.
Software Zen: delete this;
|
|
|
|
|
As far as I'm concerned, case sensitive languages are a design flaw. This flaw can't happen in case insensitive languages.
|
|
|
|
|
Hmm. You have an interesting point of view. In the end, I think programmers like what they're used to.
In my case, I've been programming in C or C-derived languages since the mid 1980's, so I expect case-sensitivity as a matter of course. I was shocked when I read that Ada was case-insensitive, as I spent three years writing Ada at one point and didn't remember that (it was a loooong time ago).
Well, at least you're not one of those heathen scum who still advocate using K&R braces in preference to the vastly superior and esthetically perfect Allman brace style[^] ...
Software Zen: delete this;
|
|
|
|
|
You guys have problems.
[Label] Opcode [Operands] [Comment]
That's all th syntax you will ever need.
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.
|
|
|
|
|
The last time I wrote a significant amount of assembly language was the late 90's. It was an OS/2 device driver for a piece of custom hardware. 18,000+ lines of assembler in the driver, relatively little of which was 'cruft' required to connect the driver to OS/2. We had a lot of functionality in that driver in order to avoid the latency of passing information out to our primary application and then back into the driver for reaction.
To date in my career I think that's the smallest body of code that I've spent that much time (three years or so) concentrating on.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: To date in my career I think that's the smallest body of code that I've spent that much time (three years or so) concentrating on. Size does not matter.
The real question is: Was it worth it? Sounds like you spent most of that time optimizing the hell out of that code and making it 200% reliable. That sort of code tends to become 'spaghettish' and hard to maintain. No time to waste hopping up and down the stack calling neat subroutines.
Still, that's what I like to spend my time on, not where I put some braces or what syntactic sugar makes the code more beautiful or not.
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.
|
|
|
|
|
CodeWraith wrote: Sounds like you spent most of that time optimizing the hell out of that code and making it 200% reliable Not really. There were lots of bug fixes, but there were also a lot of features added. The feature additions caused almost continuous refactoring in order to manage the hardware properly without thrashing the bus or triggering glitches due to race conditions. We make commercial inkjet printers, and this hardware managed the principal signals used to know where and when to spray ink. At 1000 ft/minute (17 ft/second) of paper movement, there's not a lot of time to allow for interrupt latency and such when you're printing at 600dpi.
Software Zen: delete this;
|
|
|
|
|
Sounds like fun. I'm going to try something similar at a smaller scale. Why not generate a low res VGA signal with a PIC microcontroller as a custom graphics chip for a very old 8 bit computer?
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.
|
|
|
|
|
You're oversimplifying. Evidently you need indicator columns, fixed column layout, and more. Here's subroutine from IBM's RPG language...
*------------------------------------------------------------------------*
* Subprocedure -- calculates overtime pay. *
*------------------------------------------------------------------------*
P CalcPay B
D CalcPay PI 8P 2
D Rate 5P 2 VALUE
D Hours 10U 0 VALUE
D Bonus 5P 2 VALUE
D Overtime S 5P 2 INZ(0)
/free
// Determine any overtime hours to be paid.
if Hours > 40;
Overtime = (Hours - 40) * Rate * 1.5;
Hours = 40;
endif;
// Calculate the total pay and return it to the caller.
return(H) Rate * Hours + Bonus + Overtime;
/end-free
P CalcPay E
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Actually it's really that simple. Assembly may not be my weapon of choice for and against everything anymore, but I still use it a lot. Even a C compiler may sometimes not be practical on very small processors with limited resources.
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.
|
|
|
|
|
The interesting thing of course is also that false (bool) and FALSE (0) are two different things. Smile |
|
|
|
|
|
I just use #if 1 and #if 0
Or
#define SOMETHING 1
...
#if SOMETHING
Never liked bool (not Boole ) anyway
|
|
|
|
|
Im still stuck on the truth compare.
#if defined(_DEBUG) && FALSE
Maybe a C/C++ thing, but wouldn't asserting to a value instead of truth logic be more readable?
defined(_DEBUG) != TRUE
unless this still has the integer/bool issue that you where trying to deal with?
|
|
|
|
|
I was trying to disable the block surrounding by #if defined(_DEBUG) ... #endif temporarily, while compiling for debug. Therefore the && FALSE , which disabled it leaving the _DEBUG block in place.
Software Zen: delete this;
|
|
|
|
|
I just discovered, quite by accident, that if you drag the hairline at the right end of the value property of the list box that displays the names and values of the MsBuild macros, the hairline keeps moving to the right even when you drag outside the bounds of the control. Thus, you can keep dragging until it is sufficiently wide to show the end of the property of interest, such as, in my case, $(ProjectDir).
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
My hair line has moved on it own, revealing more of the head property
|
|
|
|