Is it common practice to include the header file more then once? In my main file i just have .h after .h listed. I always thought this way was better since I used to do it like

a.h

a.cpp

b.h

b.cpp

c.h

c.cpp

Now a days I do

a.h

b.h

c.h

with the .cpp included from the .h

If you really wanted to compile everything together in one big file, why not put just the cpp files into that one big file? Each cpp file should include all the headers it needs.

However... you can compile a bunch of cpp files separately and let the linker do the linking.

Unfortunately, I work somewhere that does "bulk builds", and I work on one particular piece of software that basically includes every relevant cpp file into one big cpp file, so my "professional" environment is almost exactly how you work, though it doesn't sound like you knew there was a choice. The main difference I guess it the build step that makes the one file that includes all the cpp files for me. After a few years of neglect, none of the cpp files have a meaningful set of headers on them any more, and static is practically meaningless as a storage type or as a way to throw a simple helper function into a file. Trust me, it's more fun to have separate compile units.

It's common practice for a header file to include what needs to be shared with other cpp files, while the cpp file includes only what it needs to compile all by itself. For example, SmartImage.cpp would include SmartImage.h, because that cpp needs to know the definition of the SmartImage class in order to compile. In your situation, it doesn't even look like you really use header files for anything, and if you got into some circular dependency situation where you really needed headers, you probably wouldn't be able to fix it without changing how you include files.

So, how do you compile your code? Depending on what tools you use, I'm sure someone here can help you set up your project.

As a poster previously said - you gotta make sure you do SDL initializations before you try and create any copies of your class instances

because you call an SDL function in your copy constructor

As for the comment on your including the cpp - usually you would include your files in the following manner

SmartImage.h

#ifndef SMARTIMAGE_H     // Include header guards (so your declarations wont be included more than once)
#define SMARTIMAGE_H

class SmartImage
{
    public:
           // your class declarations
    private:
           // your class declarations
};

#endif

SmartImage.cpp

#include "SmartImage.h"   // Include your header file from your .cpp file - only include cpp files if there is no other way

SmartImage::SmartImage()
{
     // your code    
}

SmartImage::~SmartImage()
{
     // your code  
}

// copy constructor
SmartImage::SmartImage (const SmartImage& param)
{         
    // your code      
}

void SmartImage::load(std::string filename)
{
   // your code
}

void SmartImage::copy_surface(SDL_Surface *temp_surface)
{
     // your code
}

main.cpp

#include "SmartImage.h"     // now you can use SmartImage here

int main()
{
    // your code - make sure you initialize SDL before you make any instance copies of your image class
}

Here is my realization of your class.

[source='SmartImage.h']/*

[/source]

[source='SmartImage.cpp']/*

[/source]

And here some of using this class example:

[source='smartimg.cpp']/*

[/source]

I put here some of debug information. So if u don't need it. U can delete it.

I hope my solution will help you.

Here is my realization of your class.

1. Why do you use a separate boolean variable to indicate if the surface member is NULL or not?
2. You do not provide an assignment operator, thus violating the rule of three. You're going to be in for a bad time.
3. Separate resource acquisition from construction is very 1970s C-retro and all, but what possible advantage does it convey in this scenario? It means you need to explicitly acquire and release resources separately from variable scope, which means each end every use of the object has to check to see if the object is valid. It means each and every possible scope exit needs to explicitly check if the object is valid and then release the resources, otherwise resources leak. It means more code and more opportunity for coding errors. It means harder to find bugs. It means your project will probably never ship.

Other than that, it looks fine.

All right!

You got me ;)

Here class with "rules of three":

[source]/*

[/source]

[source]

[/source]