Jump to content

  • Log In with Google      Sign In   
  • Create Account

Retro Grade

[Structure][C++11] The Auto Variable

Posted by , in Structure, C++11 30 November 2012 - - - - - - · 1,369 views

How many C++ programmers reading this know what an auto variable is. Come on, raise your hand. I count 1... 2... 3... Almost all of you!

However for those of you that don't know the basics of the new standard yet, auto is a new variable that works like this:


// Hooded.cpp : Defines the entry point for the console application.
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
auto Compiler_Determines_This_Is_An_Int = 5;
auto Compiler_Determines_This_Is_An_String = "I Am A Auto-String";
auto Compiler_Determines_This_Is_A_Float = 3.14;
auto Compiler_Determines_This_Is_A_Char = 'C';
auto Compiler_Determines_This_Is_A_Boolean = true;
std::cout << Compiler_Determines_This_Is_An_Int << std::endl;
std::cout << Compiler_Determines_This_Is_An_String << std::endl;
std::cout << Compiler_Determines_This_Is_A_Float << std::endl;
std::cout << Compiler_Determines_This_Is_A_Char << std::endl;
std::cout << Compiler_Determines_This_Is_A_Boolean << std::endl;
return 0;
I Am A Auto-String
Press any key to continue . . .

I can't believe it! It's the equivalent of a "var" in other, newer programming languages! It's perfect!

So, what just happened? The compiler used the values I initialized the variables with too set their type. Essentially, an auto variable that's type can be determined by the compiler.

There are some rules, however:
  • Auto variables have to be initialized to a value when they're created.
  • Auto variables can't have their types changed after initialization.
There are many uses for this in advanced and generic programming, however I'm going to talk about it's use for the beginning C++ programmer.

First off, I believe that using this for generic programming is fine, as clarified by Aardvajk.

The problem arises when beginning programmers want to be lazy and use these for everything. That is bad programming practice, and a lazy work ethic. You should know the types of your variables in your program, and using the auto variable because you don't want to memorize the names of the basic types defeats the purpose.

Now, where can I see myself using this variable? When I don't know the type of a variable I'm receiving. This generally doesn't happen very often unless you're dealing with generic programming, in which using this value is perfectly fine.

I also believe auto variables could be very confusing. If someone defines all their variables as auto variables, than I'll have no idea what the type of each variable is. This is especially noticeable in classes with an auto variable in them. If the variable is initialized in the constructor of the class, then I'd have to hunt through your code to find the type. This can be overcome by leaving a comment telling me what type the auto variable is, however that seem to defeat the purpose.

I hope you enjoyed my (now corrected) blog post. Cheers Posted Image!

[Structure] When To Seperate Classes and Functions?

Posted by , in Structure 23 October 2012 - - - - - - · 814 views

In the programming world (Object Oriented and Procedural) there is this meta-cognitive idea that if a class or function is too big, we should divide it into smaller classes and functions. From this spawned the basics of procedural programming. This way of thinking carried over to object oriented programming in the form of the Single Responsiblity Principle and more Principles I can't name.

So, when do you know when a class is too big? The single responsiblity principle nails it, however to me there seems to be a fuzzy line. The single responsibilty principle says every class should have one responsiblity. In my pong example, I had a GameLogic and GameDraw class to seperate these componets of my program. But imagine this: If my paddle stores it's own sprite, why don't I just have the Paddle draw my Sprite? Surely that won't interfere with handling the GameLogic!

However I kept the single responsibility principle? Why? Because without that line between what's doing what, my code would become extremely confusing. And like I said in my pong example, I want to make sure a change in my GameLogic doesn't mess Up GameDraw. Well, since the Paddle class' responsibility is to handle it's own logic, that means that making a change to my Paddle class' logic can affect how I draw the paddle. And even though I know I probably won't change the Paddle class, it's best to make sure that no matter what I'm keeping my code clean and expansive.

So back to the topic of seperation. There should be seperation between classes, since they should have one responsiblity. When you start getting into more detailed programming, we have to bring in composition. What's composition? Composition is idea that a class is "made-of" rather than "is a". However a class can be both.

If there's ever a blurry line for you, try thinking about what your class is made of and if anything in it should be it's own object. Likewise, if my Paddle Had four floats instead of a normal Rectange, I should create a new class called rectangle that my class is "made-of". My Paddle class is made of an image, a sprite, a position (Vector2f if we want to get more detailed ), and not much more. My Paddle isn't "made-of" a ball, so when I handle collision detection in my paddle I pass in a ball to the CheckCollision() function. You should always make sure the objects in your class make up the class, rather than the objects in your class being what the class uses.

I hope you enjoyed this, and if you don't know what my pong example is, you can find it here: Pong Example!