|
For basic loops I've wanted this type of syntax for a while, especially if I can replace the start and end items with variables.
|
|
|
|
|
Haskell ranges:
let items = [1..10]
|
|
|
|
|
Every software developer likes analysing memory leaks, don't we? 
Last friday, I had to work on such a thing. After interacting with a different machine, our WPF application allocated some 100 MB per second, and there is no machine which will stand that for a reasonable time span.
The interaction with that other machine is via WCF. Since some hardware actions take time, I implemented it as a Task. Sometimes, the hardware failed and raised an exception. Our WCF implementation failed to cope with the faulted task. An UnobservedTaskException was raised instead (see also Unobserved TaskException[^] ).
The exception handler still assumed .Net 4 behavior: that the application is about to crash now. It logged the exception, and then showed a MessageBox with the exception details, but that MessageBox hid behind the main window of the application becoming invisible for the user.
And now the memory leak started...
Why? Well, the handler of the Unobserved TaskException runs in the Finalizer thread. The MessageBox is modal. I.e. the MessageBox blocks the thread of the Garbage Collection required for unmanaged memory cleanup...
Some things go terribly wrong.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
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 ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) 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?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
