Skip to main content
gamedev.net
🔒 Locked

Java vs. C++

Started by jarod83 12 replies 1.4k views
Original Post
jarod83
jarod83
Hello guys! A simple question... In Jave I can say 

class SomeClass {
public SomeClass() {
init();
}
private init() {
// initialize here...
}
but if I do similary in C++ nothing happens when i call the init() function! Does the function have to be virtual ore something like that, because I've tried to make it virtual, seems like the init() function never get called. Can anyone help ?
eleusive
eleusive
Could you paste how you're coding it in c++?
"What are you trying to tell me? That I can write an O(N^2) recursive solution for a 2-dimensional knapsack?" "No, programmer. I'm trying to tell you that when you're ready, you won't have to." -Adapted from "The Matrix"
Meridian
Meridian 
class SomeClass {public:   void SomeClass()    {     init();   }private:    void init()    {     // initialize here...   }};


works perfect for me ;-)
What exactly is the problem? And how did you worte it in cpp
Saandman
Saandman 
class SomeClass{public:    SomeClass() // no return type since it's a constructor    {        init();    }private:    void init()    {        cout << "oi\n";    }};
________pro.gram.mer - an organism that turns caffeine into code
jarod83
jarod83 
const int FACE_COUNT = 6;	// 6 faces for a boxclass Box {public:	Box(float w, float h, float l, char *img[FACE_COUNT]);	~Box() {}	void drawBox();	int LoadGLTextures();	void setWidth(float w) { width = w; }	void setHieght(float h) { height = h; }	void setLength(float l) { length = l; }	void setLocation(float x, float y, float z) {		location[0] = x;		location[1] = y;		location[2] = z;	}	void addToLocation(float x, float y, float z) {		location[0] += x;		location[1] += y;		location[2] += z;	}private:	AUX_RGBImageRec *LoadBMP(char *Filename) {		// FIle handler		FILE *File = NULL;		// Check if name of the file is valid, ei. the file path existed ?		if (!Filename) {			return NULL;		}		// Read the file		File = fopen(Filename, "r");		// Close file handler and return a pointer to bitmap		if (File) {			fclose(File);			return auxDIBImageLoad(Filename);		}		return NULL;	}	float location[3];	float width;	float height;	float length;	GLuint boxTextures[1];};Box::Box(float w, float h, float l, char *img[]) {	width = w;	height = h;	length = l;	LoadGLTextures();}void Box::drawBox() {	// TODO: add rotations and other stuff here...		glBindTexture(GL_TEXTURE_2D, boxTextures[0]);	// *** Front of the box ***	glBegin(GL_QUADS);	glTexCoord2f(0.0f, 0.0f);	glVertex3f(-1.0f, -1.0f, 1.0f);	glTexCoord2f(0.5f, 0.0f);	glVertex3f(1.0f, -1.0f, 1.0f);	glTexCoord2f(1.0f, 1.0f);	glVertex3f(1.0f, 1.0f, 1.0f);	glTexCoord2f(0.0f, 1.0f);	glVertex3f(-1.0f, 1.0f, 1.0f);	// *** Back of the box ***	glTexCoord2f(1.0f, 0.0f);	glVertex3f(-1.0f, -1.0f, -1.0f);	glTexCoord2f(1.0f, 1.0f);	glVertex3f(-1.0f, 1.0f, -1.0f);	glTexCoord2f(0.0f, 1.0f);	glVertex3f(1.0f, 1.0f, -1.0f);	glTexCoord2f(0.0f, 0.0f);	glVertex3f(1.0f, -1.0f, -1.0f);	// *** Top of the box ***	glTexCoord2f(0.0f, 1.0f);	glVertex3f(-1.0f, 1.0f, -1.0f);	glTexCoord2f(0.0f, 0.0f);	glVertex3f(-1.0f, 1.0f, 1.0f);	glTexCoord2f(1.0f, 0.0f);	glVertex3f(1.0f, 1.0f, 1.0f);	glTexCoord2f(1.0f, 1.0f);	glVertex3f(1.0f, 1.0f, -1.0f);	// *** Bottom of the box ***	glTexCoord2f(1.0f, 1.0f);	glVertex3f(-1.0f, -1.0f, -1.0f);	glTexCoord2f(0.0f, 1.0f);	glVertex3f(1.0f, -1.0f, -1.0f);	glTexCoord2f(0.0f, 0.0f);	glVertex3f(1.0f, -1.0f, 1.0f);	glTexCoord2f(1.0f, 0.0f);	glVertex3f(-1.0f, -1.0f, 1.0f);	// *** Right of the box ***	glTexCoord2f(1.0f, 0.0f);	glVertex3f(1.0f, -1.0f, -1.0f);	glTexCoord2f(1.0f, 1.0f);	glVertex3f(1.0f, 1.0f, -1.0f);	glTexCoord2f(0.0f, 1.0f);	glVertex3f(1.0f, 1.0f, 1.0f);	glTexCoord2f(0.0f, 0.0f);	glVertex3f(1.0f, -1.0f, 1.0f);	// *** Left of the box ***	glTexCoord2f(0.0f, 0.0f);	glVertex3f(-1.0f, -1.0f, -1.0f);	glTexCoord2f(1.0f, 0.0f);	glVertex3f(-1.0f, -1.0f, 1.0f);	glTexCoord2f(1.0f, 1.0f);	glVertex3f(-1.0f, 1.0f, 1.0f);	glTexCoord2f(0.0f, 1.0f);	glVertex3f(-1.0f, 1.0f, -1.0f);	glEnd();}int Box::LoadGLTextures() {	int Status = FALSE;	AUX_RGBImageRec *TextureImage[1];	memset(TextureImage, 0, sizeof(void *)*1);	// Loading the texture image	if ( TextureImage[0] = LoadBMP("images/NeHe2.bmp") ) {		Status = TRUE;	}	// Create and generate the texture	glGenTextures(1, &boxTextures[0]);	glBindTexture(GL_TEXTURE_2D, boxTextures[0]);	// Generating the actual texture	glTexImage2D(GL_TEXTURE_2D, 0, 3, TextureImage[0]->sizeX, TextureImage[0]->sizeY,		0, GL_RGB, GL_UNSIGNED_BYTE, TextureImage[0]->data);	// Set the filtering for the texture	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);	// Free up the memory	if (TextureImage[0]) {		if (TextureImage[0]->data) {			free(TextureImage[0]->data);		}		free(TextureImage[0]);	}	return Status;}
jarod83
jarod83
I've solved the problem: I was trying to create the textures before I had a valid OpenGL context... dough!!!
TheBluMage
TheBluMage
This isn't the cause of the problem, but you should probably make it your practice to declare member function implementation separately from the class declaration. Some compilers might interpret functions implemented inside the class as requests for inlining, which you won't want in most cases (with larger functions anyway). Many compilers are smart enough to decide on their own whether or not to inline, but not all of them are.

For example do this:
class Foo {    public:      void bar();};void Foo::bar() {    //implement}


Instead of this:
class Foo {    public:      void bar() {          //implementation      }};
HughG
HughG
I think that comes from a long use of Java where everything dealing with the class is inside one .java file. To me that makes much more sense and my early studies of C++ were very confusing until I figured out what that dern :: was for (scope resolution operator i think it's called). This is the first time I've heard that there is any sort of difference between where we implement the functions.
Drakkcon
Drakkcon
This is something you may not know, but every time you define a function within your class header instead of its implementation, the function is automatically declared inline. You add quite a bit of bloat to the executable/binary doing that.
C-Junkie
C-Junkie
Quote:
Original post by Drakkcon
every time you define a function within your class header instead of its implementation, the function is automatically declared inline.

Come on guys. Compilers are smarter than you know.
nprz
nprz
Quote:
Original post by C-Junkie
Quote:
Original post by Drakkcon
every time you define a function within your class header instead of its implementation, the function is automatically declared inline.

Come on guys. Compilers are smarter than you know.


Well, if I programmed it, then it wouldn't be very smart, so it depends on what compiler you use. Smart compilers don't always inline even if you tell it to always inline because they are smarter than YOU :)
HughG
HughG
Ok I am still in the process of learning C++ and am now very confused. Why does it matter if class functions are declared inline or not? It is my understanding that inlining is used for function calls like so

void g(){

blah...
blah...
h(blah, blah); <-- function call
blah..
h(blah, blah); <-- function call

}

So now if h() is inline with g() the program will run faster because there aren't excessive stack pushes and pops, but if it's not inline the code will be smaller and take longer to run. So why does it matter for a class declaration where everything is declared only once? Is it because if the function is inline in the class declaration it will be declared inline when it is called in another function? Ahh that would make sense..

So if that is the answer I dont think anyone can say whether inlining is good or bad absolutely. Increased speed may be desirable over bloated code... Thoughts?
TheBluMage
TheBluMage
Inlining is perfect for small functions that are around 1-3 lines long. For large functions, though, they can and do lead to code bloat if they are called at many places. When a function is inlined, the whole function is essentially copied to wherever the function is "called". This not only leads to a larger executable, but can also make it so that the processor needs to load code into its cache more frequently than normal, causing a loss in performance.

Most decent compilers won't care where you put the implementation and will decide to inline by themselves, but since the original standard was that the functions implemented inside the class got inlined, I tend towards implementation outside the class. Personally, I think this keeps the code more organized, but that's just my opinion. When I was learning C++ (with a C# and Java background) at first I prefered implementation inside the class, but after using C++ a bit more, the other method soon became more natural and now, even for functions I want inlined, I implement them outside of the class and use the inline keyword instead. (Again, just a personal preference, but it just goes to show that a new language can change your programming style if you give it enough time.)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.