next »

[Klaim]

Nothing stop you to have a header with a namespace only with declarations only of your functions, and a cpp related to this header that have the function definition.
Still, a namespace is less costly and overkill than a class in this case.

I also do this with global constants. That's the C++ way to do this. If you think everythink should be class-related (aka everything is object) then it might be that you missed the main point of C++ that is "multi-paradigm".

[BorisTheBrave]

Multi-paradigm doesn't force you to use every paradigm at every opportunity! You don't take advantage of the fact #includes allow wacky file structures, do you? Of course not, there is value in having a standardized layout, which more often than not resembles what other languages enforce.

There's in fact extremely little difference between using a class and using a namespace, so what's wrong with the consistency? Using a class instead of a namespace doesn't force you to put all static data the header file (also, I don't tend to have static data anyway), and it makes porting to other languages easier. Nor does it add a significant amount of typing.

I'd still make file-scope functions for things where I am relying on argument dependant lookup (as I think static class members do not participate, even if you have using MyClass;).


Anyway, weren't we talking about variables, not functions originally. I was saying how I don't like the extern keyword, and use classes to avoid it, which is a more justifiable point than the above, though both are just taste.

[Klaim]

I don't agree and I think you misunderstood the paradigm point. You're using a class type in a way it's not done for and you have a better and simpler solution that cannot be misunderstood nor misused nor have a cost at runtime, like the class. Why use oriented objects when you don't even make objects?
Now, it's not very important and it's a bit offtopic in the end, so nevermind, use what works for you, it'll not make any difference in the point of view of a lot of people. 

[ASnogarD]

Hit a brick wall now...

Starting to get issues passing objects declared in other classes to a namespace.

I got objects of the Player and Timer classes defined in the global space of main.cpp , in game.h I have :

Code:

namespace K_GAME
{
extern Player *ptr_mPlayer;
extern Timer *ptr_mDelta;

function prototypes ...

}

in game.cpp:

Code:

namespace K_GAME
{
Player *ptr_mPlayer = NULL;
Timer *ptr_mDelta = NULL;
}

void K_GAME::init_game( Player &mPlayer, Timer &mDelta )
{
*ptr_mPlayer = mPlayer;
*ptr_mDelta  = mDelta;

ptr_mPlayer->set_player( 400, 500 );
}

The idea was to make the pointers and then assign the pointers to the objects passed to init_game, the code compiles and links fine but spits out a access violation error at runtime

First-chance exception at 0x00f2245c in kickstick.exe: 0xC0000005: Access violation writing location 0x00000000.
Unhandled exception at 0x00f2245c in kickstick.exe: 0xC0000005: Access violation writing location 0x00000000.

Seems that the address of the objects is not being passed to the ptr pointers for some reason.

If it relevant it was suspicious I had to use forward declaration of both Timer and Player classes to get the code to work, its suspicious as game.h includes IO.h which includes both Timer.h and Player.h.
I would of thought that as IO.h has the definition of Timer and Player it wouldnt need forward declarations.

Thanks for reading

[Netsu]

Shouldn't you pass the arguments by pointer instead of by reference?

[increpare]

Be very careful when storing references, they'll get invalidated when the object they are referencing, if it was made on the stack, goes out of scope.  Better for this case to use pointers, and construct them with 'new'.  (Or go the smart pointer route).

int* a;

void foo(int& b)
{
    a=&b;
}

void bar()
{
   int c=100;
   foo(c);
   // c goes out of scope here
}

void main()
{
   bar();
   //a is no longer pointing to valid data, so this will likely not print 100
   cout << *a;
}

[ASnogarD]

Thanks guys.

My mistake was 2 fold I think.

Mistake 1 was passing a refrence ( as Netsu pointed out ) , mistake 2 was at assigning, I needed to say ptr_mPlayer = mPlayer; ( where mPlayer is the pointer passed to the function ) and not *ptr_mPlayer = mPlayer; ( I guess saying *ptr_mPlayer = mPlayer is like making another pointer, and not assigning a existing pointer. )

now K_GAME::init_game() lookes like :

void K_GAME::init_game( Player *mPlayer, Timer *mDelta )
{
   ptr_mPlayer = mPlayer;
   ptr_mDelta  = mDelta;

   ptr_mPlayer->set_player( 400, 500 );
}

... phew, it works. I am not comfortable with pointers and refrences despite reading about them a number of times, it just doesnt stick in my nut. I even had the correct code in my previous version of the game, so I had done it correctly before ...

I have got a inclination to explore auto_ptr and shared_ptr from the boost library I have read about, but for the time being I also want to crack on this game... for a simple game it sure is getting complicated, which defeats the purpose of trying to start off small  

[increpare]

passing a reference is not a mistake in and of itself - references are made to be passed

[Netsu]

mistake 2 was at assigning, I needed to say ptr_mPlayer = mPlayer; ( where mPlayer is the pointer passed to the function ) and not *ptr_mPlayer = mPlayer; ( I guess saying *ptr_mPlayer = mPlayer is like making another pointer, and not assigning a existing pointer. )

If ptr_mPlayer is a pointer then:

*ptr_mPlayer = mPlayer;

means you're assigning mPlayer to the space ptr_mPlayer points to, not the pointer itself.