Jump to content

  • Log In with Google      Sign In   
  • Create Account

Juliean

Member Since 29 Jun 2010
Offline Last Active Today, 09:46 AM

Posts I've Made

In Topic: C++ header inclusion question

Today, 02:09 AM


I'm not trying to be argumentative here, I am truly confused at some of the responses to this post. Apart from the odd circular definition, when do you need one and not the other? I can't think of many places where I need a pointer to an object but never call or access the object in any way?

 

Thats why the suggestion is not to include a header of any class where you only need the declaration in another header file. As washu has said, consider this situation:

// Foo.h

class Foo
{
public:
	void func();
}

// Bar.h

// at this point, we don't need to know anything of the foo-class other than that it exists
class Foo;

class Bar
{
public:
	
	void func();
	
private:
	Foo* foo;
}

// Bar.cpp
#include "Foo.h" // at this point, we need the full definition of Foo

void Bar::func()
{
	foo->func();
}

In Topic: C++ header inclusion question

Yesterday, 03:46 AM


Hence the "Sometimes you'll need to deviate from these rules, but in the rare occasion that you do, you'll know." It's very rare that you can't get away with forward declarations.

 

Unless you are using/writing templated classes. It's c++ after all, so templates are a (good) thing. Anything else though, should really be forward declared.

 


Its quite common to #include headers in header files.

 

Its also quite common to use i.e. the Singleton anti-pattern, that doesn't make it a good thing.

 


Manual creation of forward declarations is gonna lead to lots of subtle errors as you now have your dependencies spread across many files.

 

Care to elaborate how this is a bad thing? I never ever had an error directly related to forward declaration, and having depencies spread is really a good thing - now if I have to include "X.h" into "Y.h" I can be asured that Y only has the barely minimum depencies that X relies on in its declaration, mostly due to templates/typedefs. Instead of having Y.h now suddenly contain every single include that might be there in the include-chain, which gives you nothing but increased compile times. Even with #pragma once, having all header-files included in other header-files will still lead to recompilation of half your project if you make a change to the header of certain classes.


In Topic: Is there a way for me to see my game`s performance or frame rate?

21 October 2014 - 09:33 AM

Fraps for example:

http://www.fraps.com/

The trial-version will do, just start it & you should note a yellow frame-counter in one of the edges of your application/screen.


In Topic: Can you give me an example shows the meaning of the concept?

17 October 2014 - 11:05 AM


so you are talking about the human not the teacher ,, between the bracket i type the object right ??

so now saying human has-a name not teacher right ?

 

In the bracket, you type the current classes parent class, so thats "is-a". See https://docs.python.org/2/tutorial/classes.html chapter 9.5.


In Topic: Can you give me an example shows the meaning of the concept?

17 October 2014 - 09:26 AM

I can't think of any practical example for "is-a" in programming right now, but conceptually, take this:

 

A teacher is a human. This can be modelled by having a class inheritance:

class Human

class Teach(Human)

A teacher also might have a schoolbook. This is a "has-a" relation, as the teacher doesn't derive of schoolbook, but instead uses it:

class Human

class Schoolbook

class Teacher(Human)

    def __init__(self)
        self.book = Schoolbook()

This is achieved via aggregation, as I've shown here. Thats whats meant by "reference each other". The Teacher references a Schoolbook, in that it posses & possibly uses it.

 


def __init__(self, name):

self.name = name

why we must type this line ?? (self.name = name)

 

__init__ is a function, executed with a bunch of parameters. at that point "name" is merely a local variable, but you want to use it as a class variable. So in order to do that, you have to assign the local "name" variable to the instance of the class ("self"), by calling "self.name" (this instances "name" variable) "= name" (is assigned the local "name").


PARTNERS