|
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?
|
|
|
|
|
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 
|
|
|
|
|
LOL
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
This works great for Task Manager to see really long command line paths.
You can do it multiple times such that the width of the column can be many times wider than the width of your monitor.
|
|
|
|
|
englebart wrote: This works great for Task Manager to see really long command line paths.
You can do it multiple times such that the width of the column can be many times wider than the width of your monitor.
That's good to know for reference.
Making columns wider than my monitor wasn't the part that surprised me, though. The aspect that did was that dragging continued to work even as the mouse pointer went beyond the border of the containing window.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
This is known as "Mouse Capture". Native Windows and dotNET apis are available.
Same effect if you press a native command button with a mouse but do not release it. You can roam the mouse all over the place, but if you come back to the button it will depress again. The button captured the mouse. Pretty standard for any dragging operation.
That all being said, resizing beyond the borders is not very intuitive. It seems like you are breaking a rule or something.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
