Quote: "But libarys have 1 rule, use it or waste space. I don't know how big the cstdlib is, but I don't see any other functions being used that aren't in iostream. So you have a libary included that declares mabey 100< functions, and it is doing nothing. I just don't see the logic."
Normally you'd be right, but seeing as how we're looking at a 530KB exe, nobody really cares.
Quote: "I never use that command, and I can still use cout..."
That's probably because you're using #include <iostream.h>, last I heard it was old and is only kept around for backwards compatibility. Use #include <iostream> and using namespace std; instead.
Quote: "I might be wrong, but doesn't this create a pointer in the stack that refers to an array that can be any size, and also creates a memory leak because he doesn't delete it?"
Typically VC/Windows will delete the memory for you, and the array is exactly 1 + the number of command line arguments. I don't even know if it creates a library (and if so how big it is) or if it's just built into console apps, but considering that all it does is count the number of command line arguments based on spaces and create the array it can't be very large at all.
Quote: "The Bad Practice comes in when people start to do more then simply tell what the function is, and what the vars are. But, yt depends on the person really, in my opinion; most of the commenting belongs where things are occuring, not listed above the codebrackets (for lack of broader term). Even then I like to have the simple what the function is and variables inside it, someone needs to start reminding me everyday that it I am NEVER clear when I keep linking to context (What I said was I consiter it bad practice, when I really should have used In My Opinion.) or I can do this"
Why on earth would you only comment what's happening inside of the function? Imagine some person just commented the function name and the list of variables and a very generic description of what it does. Now imagine that this guy wrotes hundreds of functions and tens of thousands of lines of code, and commented all functions and files in this vague method. Finally, imagine you have been paid to debug it. You would have an idea of where the program is breaking, but because the guy sucked at documentation you'd have to scroll through each of the functions that appear as though they might have what you're looking for instead of telling exactly what they do and how they do it in the documentation above the declaration.
That would
suck.
All of the Torque sample project scripts are like that, and it sucks. It took me all of one day to find one little function that I had to edit to include AIs when checking for inventory pickup because the script is so widespread and undocumented.
The author details is standard. If you're working for a company and the software engineer is compiling and finds a bad file he can have a quick look in the author section to find out who to yell at, otherwise he yells at everybody about documenting code, then on his duty roster finds out it was you, then yells at you double time. If you're distributing example or open source code on the internet don't you want to ensure you are clearly defined as the author? Hell, look in the codebase for any random snipped and they're usually clearly marked with authors.
We know it's your opinion, and we would like to tell you that your opinion is wrong. Sorry dude, but do things the way we're telling you and coding will be a lot smoother. And if you major in CS in college or take a C++ code they'll require you to do all these things.
I'm going to eat you!
