|
djdanlib wrote: the definition of NULL is "THIS DATA DOES NOT EXIST and cannot be compared or evaluated."
To me, that is more an indicator that the "NULL character" is named poorly, not that .NET should exclude it from allowed characters in strings. NULL terminating strings seems silly to me.
|
|
|
|
|
aspdotnetdev wrote: NULL terminating strings seems silly to me.
I agree.
I've had trouble when receiving data from a serial connection.
|
|
|
|
|
IMO one needs to choose one of two extremes for comfort:
1.
use a "printable protocol", i.e. only transmit printable characters, i.e. the ASCII range [0x20,0x7E] and ignore everything else (including tabs, CR, LF, NULL). Every part in the serial chain (drivers, protocol stacks, modems, ...) will let them through unmodified.
2.
use binary data, i.e. make sure your serial path is fully binary and doesn't touch any byte, does not replace CR by CRLF, does not swallow NULL, etc.
I normally start out with #1 as it tends to work right away. When performance would become important, I'd consider switching to #2.
|
|
|
|
|
I was communicating with some sort of device -- I think the terminal server was causing the trouble.
|
|
|
|
|
.Net strings are Unicode and the type of encoding is therefore important. Could it be that, somewhere along the way, the strings are read with the wrong encoding? This easily could produce some strange results.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'.
I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
|
|
|
|
|
That was my thought too. Unicode encoded with UCS-2 will commonly have every other byte NULL. So, yes, you can have NULLs in a string and its perfectly vaid in that encoding.
|
|
|
|
|
Nothing's wrong with strings that can contain embedded NULLs. The fact that NULL terminated strings are so popular is mainly historic. There are times when it's handy or even necessary for a string to contain embedded NULLs, for example the Win32 SHFileOperation[^] function uses strings that have embedded NULLs.
Steve
|
|
|
|
|
Back in my first year of programming, I was in a Visual Basic class, but I didn't like Visual Basic so I spent a good amount of my time coding in QuickBasic 4.5. In my infinite wisdom, I decided that it would be easier to use draw commands to show text on the screen rather than loading a font from the file system. So I created a function that took the top left coordinate of where to draw the string and it would draw the string... with Quick Basic draw commands. As I recall, there was a for loop to split the strings into individual characters. Then, there was a giant switch command on those characters (or was it a chained if statement... hmmm) to decide which draw commands to use. I then fine-tuned each letter so that large groups of pixels would be drawn as rectangles and individual pixels would be drawn with the command to set a single pixel. I was very impressed with my code, which I'm pretty sure was over 400 lines long! You can see it in action in my Tetris game at the link below, which also used only procedurally drawn textures (i.e., no image files were loaded):
Tetris (scroll to bottom of page)
I will see if I can find this chunk of code, so that you can be mesmerized by this astounding masterpiece. 
|
|
|
|
|
I don't think I understand how this is a coding horror... I see this as a great learning experience. The more you learn the under-the-hood stuff, the better
|
|
|
|
|
Every coding horror might be considered a learning experience (assuming you learn from it). In this case, I think I learned patience. Doesn't make it any less horrific.
|
|
|
|
|
I agree; not much of a horror. I think its pretty cool actually Not that I'd prefer to do it over using a font, but it looks like you did a pretty good job of procedurally rendered text.
|
|
|
|
|
I did something similar long ago (around 1977): lots of measurements on electronic circuitry, getting automated using a PDP11 minicomputer (RSX11 operating system) and Fortran IV, and results plotted by an HP plotter lacking any (or any decent?) text output capability. So I did create a font, not as a giant switch statement, as a big table of strokes. The result was nice graphics (for that era at least) with labeled axes and legends.
|
|
|
|
|
Luc Pattyn wrote: table of strokes
Visited the massage parlor recently, eh? 
Actually, I did something like that for my Cargobay game (listed on the same page as that Tetris game). I stored the game board as an array or something like that. I found that to be somewhat more reasonable than hardcoding the building of each game board.
Luc Pattyn wrote: 1977
They had computers then? I wasn't born for another 8 years.
|
|
|
|
|
aspdotnetdev wrote: They had computers then?
yes, that was the computer era. It ended in the eighties, when they introduced "PC's", which weren't computers at all.
They were a bit large; you could easily fit the content of your wardrobe in them without disturbing much; a 10MB (later 50MB) harddisk had the size of a modern dish washer.
And that was more than enough to drive a pen plotter and more.
|
|
|
|
|
Yup and if you wanted to use any Maths Libraries on a Prime Computer that I used, you had to grab the MathsLibrary, literally!
It was something a similar size to a drum in a washing machine and you had to screw it into the top of the computer. It did have a disk/human interface to make it more interactive, yeah ok it was just a plastic handle but it was bloody heavy with all those disk platters inside.
He took it all too far, but boy could he play guitar!
|
|
|
|
|
Sounds like you wrote some cool code. I suspect that it was a lot more work than simply using an available font. 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Hey, I don't see anything wrong with that. One of my first coding tasks at university was the other way round: a 'function plotter' that would take a function as input and 'draw' the graph on a text-only line printer using a 'resolution' of 132x66 characters (and using 'x' as pixels).
I later adapted this little gem to print out a two-dimensional representation of a four-dimensional simplex (four dimensional equivalent of a three dimensional 'cube' if you will). Ok, it was a bit hard to actually 'see' anything, but it worked
Now, if I still had the code (IIRC I let the stack of punch cards drop and eventually discarded them to save me the bother of sorting) I could try and combine it with yours to actually draw the 'x' characters that were meant to represent the pixels of what I wanted to draw. 
|
|
|
|
|
It is portable, I'll give it that. 
|
|
|
|
|
As some of you may know, I created a Tip/Trick recently about converting numbers to the word equivalent (523 to "Five hundred and twenty three"). With my tongue firmly rammed into my cheek, I suggested that a switch statement would be a good way to do it.
Well, it's Saturday, and I thought to myself "A switch has got to be faster than the proper way - I wonder how much faster?" So I thought I'd check.
I wrote and tested a proper version and used it to generate the Big Switch code I'd need, writing it to a text file "BigSwitch.cs". Then I could include this and do a side-by-side comparison. Initial testing of the "proper" way to do it suggested that one million iterations should test all code paths and eliminate cached jitter in the results.
So, I made my mistake. I double clicked on the "BigSwitch.cs" file I had created. VS2008 started to load it.
I'm still not sure if it would have suceeded; I killed the process after 30 minutes. Note to self: Do not attempt to load 82.7 Mb code fragments into VS again...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Indeed, just compile it at the command line.
|
|
|
|
|
 I knew there was a simple solution!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
I suspect that a Web service, backed by a database, might be worth a try...
|
|
|
|
|
OOO! Now there is an idea for the "Extra Credit" version - can I steal it?
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
That's waaaaay over 9000 lines o_O
|
|
|
|
|
Two million and six, indented for readability! 
(that may have contributed to the load time... )
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
