|
Is it possible we're talking about Quantum bool ????
Paulo Gomes
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
—Bill Gates
Everything should be made as simple as possible, but not simpler.
—Albert Einstein
|
|
|
|
|
Only this[^] knows.
Software Zen: delete this;
|
|
|
|
|
Maybe it's an existential program looking for the meaning of truth and it couldn't get a hold of Stephen Colbert.
|
|
|
|
|
Both patterns are bad. On most platforms bool is an integer. Therefore flags[x] might get corrupted to equal, say 42. Code that didn't explicitly check consistently for "==true" would take the wrong path. if(flags[x]) would be true, if(flags[x]==true) would be false. Then you also get the VB true, which is -1!
|
|
|
|
|
what if var TRUE = false; hey!? I betcha didn't think of it, did ya?!
|
|
|
|
|
This is C++, fortunately.
Software Zen: delete this;
|
|
|
|
|
well, you know
#undef TRUE
#define TRUE 0
|
|
|
|
|
This could make sense in a multithreaded situation, but somehow I've a feeling that's not what you're dealing with...
#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
|
|
|
|
|
While this code was in fact multithreaded, that had nothing to do with the sloppy way the logic was coded. I've had very few cases where comparing a bool variable to a constant made more sense algorithmically than just using the variable as-is. The second part comparing the variable to the Windows DWORD constant TRUE is just plain stupid. It works, but that's no credit.
Software Zen: delete this;
|
|
|
|
|
Count me in the Spoiled Rotten Club: I just discovered that you can define all the string resources you want, and your XAML editor won't see them until you run them through the resource compiler.
I say that I am spoiled because I am accustomed to having new strings immediately visible in the C# code editor.
I'm in VS 2017, as opposed to Blend for VS.
BTW, the blog that was the most help is at The Weird and The Wonderful.
Go figure.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
modified 7-May-19 15:23pm.
|
|
|
|
|
You are spoiled indeed!
Fortunately F6 to the rescue! F6! F6! F6! F6!
|
|
|
|
|
Indeed, but why must I?
BTW, for me, it's F7, because I use the old Visual Studio 6 key bindings.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
SHR LSB(D)→ DF; 0→ MSB(D) F6 So, how exactly is this Shift Right instruction going to help?
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.
|
|
|
|
|
Which processor instruction set is that?
Software Zen: delete this;
|
|
|
|
|
One I know in and out since over 40 years now: Chip Hall of Fame: RCA CDP 1802 - IEEE Spectrum[^]
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.
|
|
|
|
|
Ah. I thought it was an 8-bit opcode. I used to have most of the 8085 instruction set memorized.
Software Zen: delete this;
|
|
|
|
|
Oh, it's 8 bit all right. Looks like both processors are from 1976. Despite that, they are both very different. There actually seems to be one thing about the 8085 that seems even weirder than the unconventional 1802:
The 1802 multiplexed its address bus to save eight pins. The 8085 has 16 address lines, but multiplexes the lower half with the data bus. In both cases the obligatory bus drivers and/or latches on every board could handle (and hide) this very well, but multiplexing addresses and data seems weird.
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 first microprocessor I ever played with was an 1802. My stepdad bought a COSMAC ELF-II board, which included a hex keypad and two 7-segment displays. He bought a KSR-33 teletype and got it working with the ELF-II, and even machined an alternate gear for it that sped it up. We fat-fingered a Tiny BASIC interpreter (a whopping 1.5K) into the ELF-II's RAM with the hex keypad and used that for programming. We kept the machine's RAM alive using a car battery.
As they say, good times.
Software Zen: delete this;
|
|
|
|
|
The good times never ended for me. My first computer was an Elf II and I still have it. The old keys on the hex keyboard are worn out and that's why I don't use the hex keypad to enter programs anymore. I have a neat setup on the PC with a cross assembler, a C compiler and an emulator with VS as code editor for that now. Do you still remember the interrupt routines for the CDP1861 graphics chip?
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.
|
|
|
|
|
'Fraid not. The only programming I did on the ELF-II was using Tiny BASIC (I was in high school at the time). I did a lot of embedded programming on the 8085 for little data acquisition and process control apps in my first programming job while I was in college.
Software Zen: delete this;
|
|
|
|
|
I dug up a picture I have posted here last year: Dusty old Elf[^]
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.
|
|
|
|
|
Hmm. I define my 'resource' strings in my XAML:
<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:s="clr-namespace:System;assembly=mscorlib">
<s:String x:Key="Name" x:Uid="Name">Thing name</s:String>
... My localization gizmo assumes everything translatable lives there.
Software Zen: delete this;
|
|
|
|
|
Is it safe to assume that you rolled your own localization tool, rather than use the ones that come with the framework?
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I know it sounds like a bad case of not-invented-here, but we're stuck on VS2008. Back then, the only 'tool' available was a sample program called LocBaml. It used .NET facilities to traverse compiled XAML (aka BAML) and produce translated resource DLL's. Unfortunately LocBaml wasn't very capable and didn't handle a lot of cases. Fortunately the source code for LocBaml was provided.
I wrote my own tool to handle LocBaml's missing cases and to provide a better persistence format for translators. It also handles the typical use-case of updating an existing translation to new code, which LocBaml did not.
Software Zen: delete this;
|
|
|
|
|
No, it sounds more like the work of a resourceful engineer. Good on you!
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|