1. You need a ";" after the closing "}" of your class declaration.
2. Your vec3 class is not going to let you access the x/y/z values because they're private by default. You can either declare them as public (add a "public:" above them) or declare it as a "struct" rather than a "class" (structs are the same as classes, except they default to public access).
3. Class declarations should go in a ".h" file, while function implementations in a ".cpp" file, which includes the ".h" file. There are reasons for this, but basically C++ library importing isn't as smart as BlitzMax / C#, so it's best to do it this way.
Here's how the above code should look, if done "properly":
File.h
The #ifdef / #define / #endif stuff is there to ensure the same file isn't included more than once (to access the code from another file, you add '#include "File.h"' to the top of the .cpp file that needs access. It's messy, and Microsoft C++ has a better way of doing it, but the above method is the only cross-platform way.
File.cpp
Yeah, learning C++ can take some time, but personally I don't think it's as hard as people make it out to be (probably because I'm so familiar with it though).
But now that I think about it, there was a time when I was totally confused and frustrated and hated C++ because I was getting strange errors all the time regarding declarations, etc., but that was because I didn't learn the proper relationship between .cpp and .h files initially.
2. Your vec3 class is not going to let you access the x/y/z values because they're private by default. You can either declare them as public (add a "public:" above them) or declare it as a "struct" rather than a "class" (structs are the same as classes, except they default to public access).
3. Class declarations should go in a ".h" file, while function implementations in a ".cpp" file, which includes the ".h" file. There are reasons for this, but basically C++ library importing isn't as smart as BlitzMax / C#, so it's best to do it this way.
Here's how the above code should look, if done "properly":
File.h
#ifndef _FILE_H__ #define _FILE_H__ struct vec3 { float x, y, z; }; class Entity { public: void SetPosition ( vec3 position, int global = 0 ); private: vec3 position; //private values aren't accessible from outside the class - the user is forced to use SetPosition() }; #endif
The #ifdef / #define / #endif stuff is there to ensure the same file isn't included more than once (to access the code from another file, you add '#include "File.h"' to the top of the .cpp file that needs access. It's messy, and Microsoft C++ has a better way of doing it, but the above method is the only cross-platform way.
File.cpp
#include "File.h" //.cpp files typically declare the actual code, while .h //files simply contain the "prototypes" of the code. It may //seem tedious to maintain two files (it can be), but it actually //has the advantage of giving you a quick overview of your //engine structure when you look at a .h header file. void Entity::SetPosition( vec3 position, int global = 0 ) { this->position = position; //no need for memcopy, C++ will optimize this to be just as efficient //however, if you absolutely must use memcpy, you can actually //overload the assignment (=) operator to use memcpy() as you like. }
>>C++ would still be a terrible move, I think, because it would kill productivity, even after I was completely familiar with it.<<
..i really couldnt resist..yayyy :)..
..i really couldnt resist..yayyy :)..
Yeah, learning C++ can take some time, but personally I don't think it's as hard as people make it out to be (probably because I'm so familiar with it though).
But now that I think about it, there was a time when I was totally confused and frustrated and hated C++ because I was getting strange errors all the time regarding declarations, etc., but that was because I didn't learn the proper relationship between .cpp and .h files initially.