• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
chiranjivi

Help me understand .cpp vs .h in C++

20 posts in this topic

This is a hard topic unless you know just a bit about what's going on behind the scenes when compiling. What happens is basically the compiler looks at what .cpp files you have in the project (or folder or the ones you tell it to compile, this depends), turns each one of them into an object file (.obj with visual studio, .a and .o also exist with some compilers IIRC) and it's done. After this the linker jumps onto the scene and starts looking at what pieces of code it needs to make the program into an actual executable - this is why you, for example, tell the linker, not the compiler, where the execution starts. Here you can have so called statically linked libraries too, that's the list of .lib files you feed to your linker. The most usual linker errors occur when you either forget to link against something or have multiple definitions - the same variable or function exists in several object files and the linker can't figure out which one to use.

 

Now, you might notice I didn't mention headers at all. This is because a header is never compiled itself, it's just included into (usually several) other files. So if your header has a global variable definition (for example "int x = 5;"), it'll be in all of the .cpp files and the linker won't like this. So you want your headers to only hold declarations, not definitions. int foo(int x); is okay, int foo(int x){return x*2+1;} isn't. Unless it's code you only use in one file, though then you don't even have to keep it in the header at all.

Edited by powly k
2

Share this post


Link to post
Share on other sites

Like I said I was not up on my CPP and also asked for help in clarification,  So I guess by trying and asking fo help you get knocked down.

This is why people do not try.

If you know CPR, or if you're a paramedic, it's cool to help a person who collapsed on the street.

I would think twice before electrocuting people, or going "scalpel!" when I don't really know what I'm doing.

Even if I just want to help, try at home first - it won't mess up other peoples' interpretation of "correct".
 

[I] have been out of CPP for awhile and I am trying to get back into it.  I realize newer versions of CPP have changed and so has the format.

That part never changed, though.

Edited by SuperVGA
0

Share this post


Link to post
Share on other sites

A part of the confusion of .h(pp) files comes from the preprocessor, this is an important concept to grok for C++, but it isn't intuitive, especially if you come from a language where they don't exist or are much less prevalent.

 

 

Essentially the pre-processor is a process that runs on your program *BEFORE* it is compiled.

 

When the preprocessor runs, it scans through your code looking for pre-processor directives.  Those are the lines that start with the pound (#) symbol, such as #define #pragma or #ifdef.

 

Most of the time, the preprocessor is simply generating the code file that will be sent to the compiler.  Consider the following common scenario with the preprocessor:

 

 

#ifdef _WIN32

int i = 42;

#else

int i = 43;

#endif

 

The preprocessor see this directives, and if you are running on Windows the final result is:

int i = 42;

If you are running on any other platform, the result becomes:

int i = 43;

 

 

Similarly, thats how header guards work, when you encounter:

 

#ifndef _BOB_H

#define _BOB_H

 

... your code here

 

#endif

 

The preprocessor starts processing this file, checks if _BOB_H has been defined, if it hasn't it continues as usual, defining the value _BOB_H.  Therefore, the next time this .h file is #included, it fails the test ( since _BOB_H was defined on the prior pass ) and skips the file.  #pragma once is a shorthand (slightly un-standard, but standard enough to use it freely ) for the exact same thing.

 

 

 

Finally back to #include "bob.h".

 

When the preprocessor runs through your code and see's the line 

#include "bob.h"

 

It simply is opening that file and copying the contents into where it was included.  

0

Share this post


Link to post
Share on other sites
Hi all,

Many thanks for the posts, Cornstalks and giant city games especially for your detailed and informative breakdowns of what was going on. After reading your responses and googling a little more I think I have a much better grasp of things. The problem was defining functions/variables in the sdl_functions header and then trying to include the header at every point where they were required; not understanding what the header files did meant I didn't understand why this wasn't a good idea! I appreciate all the feedback and everyone's attempts to help.
0

Share this post


Link to post
Share on other sites

Hi there's, i think you can make a precompiled header like "stdafx.h" and include all sdl header there, then you can include this header to all of your program

some think like this :

 

stdafx.h

#ifndef STDAFX_H_INCLUDED
#define STDAFX_H_INCLUDED
 
//include all needed header after this line
#include "sdl_functions.h"
  
#endif // STDAFX_H_INCLUDED

 

level.h

#ifndef LEVEL_H_INCLUDED
#define LEVEL_H_INCLUDED
 
#include "stdafx.h"
 
//program class code/definition
 
#endif // LEVEL_H_INCLUDED

 

what you need to do is just include the precompiled liblary in all of your class definition file(.h)

 

hmm, i don't know is that would solve your problem but i just want to show you how i manage to include my external liblary and distribute it to all of my code smile.png

good luck wink.png

Edited by Fs02
0

Share this post


Link to post
Share on other sites

Hi there's, i think you can make a precompiled header like "stdafx.h" and include all sdl header there, then you can include this header to all of your program

some think like this :

 

stdafx.h

#ifndef STDAFX_H_INCLUDED
#define STDAFX_H_INCLUDED
 
//include all needed header after this line
#include "sdl_functions.h"
  
#endif // STDAFX_H_INCLUDED

 

level.h

#ifndef LEVEL_H_INCLUDED
#define LEVEL_H_INCLUDED
 
#include "stdafx.h"
 
//program class code/definition
 
#endif // LEVEL_H_INCLUDED

 

what you need to do is just include the precompiled liblary in all of your class definition file(.h)

 

hmm, i don't know is that would solve your problem but i just want to show you how i manage to include my external liblary and distribute it to all of my code smile.png

good luck wink.png

 

While stdafx.h is what it used for precompiled headers, and what you are suggesting is perfectly valid, you are mixing up your expressions a little bit.

 

A precompiled header is actually a compiler optimization, you need to enable it.  The idea is to include all the header files that don't change often and have the compiler compile them all once in advance.  This is where the "pre-compiled" part comes in.  That means the next time you compile your code, these header files wont have to be compiled, speeding the process up.

0

Share this post


Link to post
Share on other sites

While stdafx.h is what it used for precompiled headers, and what you are suggesting is perfectly valid, you are mixing up your expressions a little bit.
 
A precompiled header is actually a compiler optimization, you need to enable it.  The idea is to include all the header files that don't change often and have the compiler compile them all once in advance.  This is where the "pre-compiled" part comes in.  That means the next time you compile your code, these header files wont have to be compiled, speeding the process up.

 

Yupp, that's what i mean, thanks for making it clear smile.png

0

Share this post


Link to post
Share on other sites

I dont think its a good idea to tell someone who barely understands what a header is to stuff everything into one header to avoid learning how headers are supposed to be working. That some people who know already how headers work use precompiled headers to speed up compilation is some completely unrelated subject.

0

Share this post


Link to post
Share on other sites

Compiler compiles only cpp files . Cpp and h file should be in one file, but the need to have them separate caused for #include directive, so you simply put them to file you need to compile (literaly). The reason to separatet them is, that other projects may need to use your library, but would like to do so without compiling your library, so they just put your h. files to their cpp files and compile them, and on runtime your library internal routine is run. When you will code modules/libraries/projects, whatever is the termine, you will understand also obstacles this design brings.

-1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0