glVertexAttribPointer error

[Brian Beuken]

hmmm see that question makes me worry that you still have a little bit to learn on the basics of C++ and this might be a bit too much for you at the moment,

But i will do my best to help, I would like to know if you can cope with it.

All the CPP files in your solution are compiled by the gcc compiler. each cpp file if successfully compiled produces an obj file of the same name
If all files compile, the linker then links all obj files and if all is correct produces the executable file.

Now a classname.H or header file, contains the definition of a class, and the classname.cpp file needs that to make sure that it has properly built the class as the definition requires.

Other cpp files might need to know or create an instance of a class which is contained in another CPP/OBJ file, so it includes the definition of the class as an include file.h
That then tells the compiler, what kind of class object it expects, what its methods and members are, and lets the compiler produce the obj file. And again, the linker makes sure that you are using the values correctly and if all ok, patches in the address to find the methods and members.

So while MyFiles.cpp uses the Myfiles.h header to correctly produce the class code,

Your main.cpp or game.cpp file, only need to include the MyFiles.h so they know what a MyFiles class is, if they want to make one as part of the code in main, or game.

Does that help?

[pahendriks]

hmmm see that question makes me worry that you  still have a little bit to learn on the basics of C++ and this might be a bit too much for you at the moment,

But i will do my best to help, I would like to know if you can cope with it.

All the CPP files in your solution are compiled by the gcc compiler. each cpp file if successfully compiled produces an obj file of the same name
If all files compile, the linker then links all obj files and if all is correct produces the executable file.

Now an classname.H  or header file, contains the definition of a class, and the classname.cpp file needs that to make sure that it has properly built the class as the definition requires.

Other cpp files might need to know or create an instance of a class which is contained in another CPP/OBJ file,  so it includes the definition of the class as an include file.h
That then tells the compiler, what kind of class object it expects, what its methods and members are, and lets the compiler produce the obj file. And again, the linker makes sure that you are using the values correctly and if all ok, patches in the address to find the methods and members.

So while MyFiles.cpp uses the Myfiles.h header to correctly produce the class code,

Your main.cpp  or game.cpp file, only need to include the MyFiles.h so they know what a MyFiles class is, if they want to make one as part of the code in main, or game.

Does that help?

Well yes. So when I include xxx.h, xxx.cpp is included also for compiling?

I included myfiles.h in the game.cpp and it did compile now without errors but I get an error when executing that the image file can not be loaded...

I will first reread my c and c++ books before I continue.

Thanks for your help.

[Brian Beuken]

"So when I include xxx.h, xxx.cpp is included also for compiling?"

not quite, you are making xxx.obj and the xxx.cpp file contains all the code, and xxx.h is the definitions of the code in that xxx.cpp file, once the obj is successfully made, it is put to one side

Now suppose xxx.cpp contains the class MyObject.
the xxx.h file, should really be called MyObject.h

But it was compiled ok, that means we have MyObject.obj and the code to make MyObject's exists

If we now take another file, like our bootstrap file, containing main()

if we want to do something like
main()
{
MyObject MO; // create an instance of an obj
}

Then clearly the main.cpp file has no idea what a MyObject is... its never heard of it before, so it will complain, out of scope, or undefined.
but..

#include "MyObject.h"
main()
{
MyObject MO; // create an instance of an obj
}

tells the main.cpp file, that there are things called MyObject and now it knows what they are made of, the definition of them is in the MyObject.h file.

The code for them is still very much in the MyObject.obj file, but main.cpp can compile and make a MyObject called MO...which it can then use. The compiler is trusting that the MyObject class is properly defined, and puts markers in the main.obj wherever there is a use of MyObject, for the linker to fill in, because its job is to take all the obj files and fill in the blanks.

When the linker comes along it has main.obj, and MyObject.obj and fills in the markers with the correct code, if the files are properly used and no extra undefined or mis defined usage has occurred, the 2 objs are combined into 1 executable file and we're good to go.

That's a simply way to think of the build process, edit, compile, link...run.

[pahendriks]

"So when I include xxx.h, xxx.cpp is included also for compiling?"

not quite, you are making xxx.obj and the xxx.cpp file contains all the code, once the obj is successfully made, it is put to one side

Now suppose xxx.cpp contains the class MyObject.
the xxx.h file, should really be called MyObject.h

But it was compiled ok, that means we have MyObject.obj and the code to make MyObject's exists

If we now take another file, like our bootstrap file, containing main()

if we want to do something like
main()
{
MyObject MO; // create an instance of an obj
}

Then clearly the main.cpp file has no idea what a MyObject is... its never heard of it before, so it will complain, out of scope, or undefined.
but..

#include "MyObject.h"
main()
{
MyObject MO; // create an instance of an obj
}

tells the main.cpp file, that there are things called MyObject and now it knows what they are made of, the defintion of them is in the MyObject.h file.

The code for them is still very much in the MyObject.obj file,  but main.cpp can compile and make a MyObject called MO...which it can then use. The compiler is trusting that the MyObject class is properly defined, and puts markers in the main.obj wherever there is a use of MyObject, for the linker to fill in, because its job is to take all the obj files and fill in the blanks.

When the linker comes along it has main.obj, and MyObject.obj and fills in the markers with the correct code, if the files are properly used and no extra undefined or mis defined usage has occured, the 2 objs are combined into 1 executable file and we're good to go.

Thats a simply way to think of the build process, edit, compile, link...run.

Thanks for you long answers. In my project there are two .cpp files. The GameProject1.cpp and MyFiles.cpp.

MyFiles.cpp is as follows:

#include "MyFiles.h"
#define STB_IMAGE_IMPLEMENTATION
#include "stb_image.h"
MyFiles::MyFiles()
{}

MyFiles::~MyFiles()
{}

char* MyFiles::Load(char const *filename, int* width, int* height)
{
    unsigned char *data = stbi_load(filename, width, height, &comp, 4);
    return (char*) data;
}


So this MyFiles.cpp is compiled and linked when the project is build? So that the Load function can be used. Why is the content of MyFiles.cpp not put into GameProject1.cpp? Because #include "MyFiles.h" is now in both .cpp files!

[Brian Beuken]

Well that's the nature of OOP, we create classes that do things, and we define the classes as small easy to alter concepts that are transportable.

If you want a MyFiles, you simply include the header, which has the definition of the class. NOT THE ACTUAL CODE.
Then another "class" or "classes" can create a new instance of MyFiles, and use it to suit its particular needs.

Code that is plugged into other code, is not flexible, and can't be interchanged.

But any class can include a MyFiles class in its own make up, if it needs to load an image, or...as I use it, I create 1 instance of a filehandler in the main code, and pass its address to any other classes that want to use it, but those classes also need to know what the MyFiles class can do, so you include the header in them also.
So in a sense you do put the content of Myfiles.cpp in to GameProject1.cpp, but you access it by creating an instance of a class.

As I say...the nature of OOP, which is the key design concept of the C++ language.