I am unlikely to get support from Evil_Greven himself on this, but that's OK. It wouldn't be a learning experience without like six bajillion hurdles. My high school chemistry teacher, Dr. Landorf, once gave us a universal problem-solving method. I forget most of it, but the two parts that stuck with me were: "A problem is not when you simply have to get from A to B. A problem is when you have to get from A to B and have no idea how. Otherwise you merely have a number crunch," and, "When you can't find the solution to a problem, start at the answer and derive the question." I couldn't find the list itself on the internet (this was a handout from before the internet was everywhere, and apparently drew from several sources), but I did find a really great joke while I was looking:
A mechanical engineer, an electrical engineer, and a software engineer are in a car that breaks down. The mechanical engineer says, "Maybe is's a stuck valve." The electical engineer says, "Maybe it's a dead battery." The software engineer says, "I know. Let's all get out and get back in again, and see if that fixes it."BWAHAHA! Oh, what a groaner! Love it! OK, so I've now got it down to three errors:
1>------ Build started: Project: Fetris, Configuration: Debug Win32 ------Much more manageable than the two dozen I had on Friday. I can handle this. I think. I Googled the first error, in accordance with the prophecy (the prophecy is "JFGI") and found this thread, which led me to this other thread., which led me to this excellent article. The article is called "Making Wrong Code Look Wrong," and the author goes on about the true history of Hungarian notation (which I did not know was a thing until today) and how to be your own best friend with your programming conventions. Since one of my errors from this very day was an extra "}" nestled amongst some 50 lines of nested "how to make teh bloxxxorz," I really wish that Evil_Greven had followed rule 5: "Don't put closing braces more than one screen away from the matching opening brace." It would've been gallons easier to spot that extra brace, had he done so. But no worries! I learned a valuable lesson. And I bookmarked that guy's blog, because it's rad as Hell.
1> main.cpp
1>c:\users\d\documents\visual studio 2010\projects\fetris\fetris\main.cpp(187): error C2440: '=' : cannot convert from 'const char [7]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>c:\users\d\documents\visual studio 2010\projects\fetris\fetris\main.cpp(196): error C2664: 'CreateWindowExW' : cannot convert parameter 2 from 'const char [7]' to 'LPCWSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1>c:\users\d\documents\visual studio 2010\projects\fetris\fetris\main.cpp(260): error C2664: 'BitMapObject::Load' : cannot convert parameter 2 from 'const char [11]' to 'LPCTSTR'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1> BitMapObject.cpp
1> Generating Code...
OK, so the guy in thread number two said that I could either switch the compiler settings to multibyte character set, or use unicode strings instead (the recommended option). I can't find that option after combing through them all, and I don't know how to make it unicode compliant quite yet, so I'm calling it a night. It's quarter after ten, I have learned some things and done some things, and I'm happy.
For now.
Another useful tool when dealing with brackets is a good IDE. I'm pretty sure (but not 100% certain) that Visual Studio has support for finding matching braces; I would look through the menu options in edit for that. Also, in formatting, there should be an option to "highlight matching brace" so when your cursor is over a brace, the matching one gets highlighted.
ReplyDeleteOther IDEs, such as Komodo Edit and Eclipse, have this support built in.
As for the persistent error you're getting, this requires a bit more in-depth knowledge. Basically, in C++ any uncast string -- anything within double-quotes -- is converted automatically to a "const char*". The * indicates that it's a pointer, which there's a lot to discuss but in this particular case means it indicates an array; const means that the value is non-mutable, so you can't actually CHANGE the value of the char array; and char means just what it sounds like, characters. so you can think of a string, such a "hello, world", as an array of individual characters that cannot be changed.
The problem is that "LPCWSTR" is a redefinition of a standard library string indicating that the string is comprised of unicode characters instead of the standard ascii characters (a 'char' type is ascii). By using "#include " in your code (#include is a preprocessor directive, meaning it defines something that happens before compilation. Includes are the most important because they tell the compiler to fetch code that exists in other files) you can follow the instructions here: http://social.msdn.microsoft.com/Forums/en-US/Vsexpressvc/thread/0f749fd8-8a43-4580-b54b-fbf964d68375/ to fix the problem.
I will say this about hungarian notation: it's fucking garbage. Literally do not use it ever for any reason. Variables should be named in a sensible, easy-to-read way; there should be no need to "decode" something. If you can't tell if a variable is a bool or an int or a string, then rename your variable until it bloody makes sense. Which is easier to read: lpiaItems, or item_list? Hungarian notation only serves to HURT readability, not help, by embedding type information in a place it does not belong and demanding the reader and writer of code futz about with types before they actually get into the meat of what they're working on. Hungarian Notation is the reason you're dealing with a "LPCWSTR" instead of a "LONG_POINTER_TO_CONST_STRING". We don't live in the age of 64k memory, it's okay to have long human-readable strings. It's really okay.
(a note; if you REALLY need to specify type in a variable name because it's an unexpected or rare type, just use the full bloody name, or a shortened abbreviation that's understandable; a single character does not readability make).
As always, thank you for the tips and the link! I'll be digging into that this evening.
ReplyDeleteOn Hungarian: you're clearly talking about Systems Hungarian, which Joel agrees is garbage. The interesting part was about Apps Hungarian, which is not garbage. The reason there's a difference, and the reason Systems Hungarian is so terrible, is because Simonyi used the word "type" in his paper when he meant it colloquially (as in "kind"). Simonyi explained this, but that didn't help.
When Word went WYSIWYG, all the coordinates in the scrollable windows had to be defined relative to the window or to the page, and keeping these straight is obviously of huge importance. This led to the implementation of Apps Hungarian (in the Word and Excel divisions only), and the idea was to prefix your variables with what kind of thing you're working with, so you know by looking whether you need a conversion factor or not.
From the article:
"In Excel’s source code you see a lot of rw and col and when you see those you know that they refer to rows and columns. Yep, they’re both integers, but it never makes sense to assign between them. In Word, I'm told, you see a lot of xl and xw, where xl means 'horizontal coordinates relative to the layout' and xw means 'horizontal coordinates relative to the window.' Both ints. Not interchangeable. In both apps you see a lot of cb meaning 'count of bytes.' Yep, it’s an int again, but you know so much more about it just by looking at the variable name. It’s a count of bytes: a buffer size. And if you see xl = cb, well, blow the Bad Code Whistle, that is obviously wrong code, because even though xl and cb are both integers, it’s completely crazy to set a horizontal offset in pixels to a count of bytes."
...
"Apps Hungarian had very useful, meaningful prefixes like 'ix' to mean an index into an array, 'c' to mean a count, 'd' to mean the difference between two numbers (for example 'dx' meant 'width'), and so forth.
"Systems Hungarian had far less useful prefixes like 'l' for long and 'ul' for 'unsigned long' and 'dw' for double word, which is, actually, uh, an unsigned long. In Systems Hungarian, the only thing that the prefix told you was the actual data type of the variable.
"This was a subtle but complete misunderstanding of Simonyi’s intention and practice, and it just goes to show you that if you write convoluted, dense academic prose nobody will understand it and your ideas will be misinterpreted and then the misinterpreted ideas will be ridiculed even when they weren’t your ideas. So in Systems Hungarian you got a lot of dwFoo meaning 'double word foo,' and doggone it, the fact that a variable is a double word tells you darn near nothing useful at all. So it’s no wonder people rebelled against Systems Hungarian."
In Conclusion: Your suggestion to make my variables understandable at a glance is an excellent one, and I plan on following it; but this is actually in keeping with Simonyi's original intent for Apps Hungarian (which almost nobody outside of the Word and Excel development teams ever used or heard of).