How do I share information in multifile project

[rmxhaha]

this last few days I've been coding this one particular file

Hero.cpp

namespace Hero {
   namespace {
     // all data here
   }
}

then the code grew a bit to about 700 line

Then now I want to implement hero skill system
It needs the access to data inside the unnamed namespace where I put just about everything..

but it's unnamed namespace, it's only valid within one file
and I should hide all that data from Hero interface in Hero.h


How should I do this ?

[coder777]

It needs the access to data inside the unnamed namespace where I put just about everything..

what kind of data resides inside a namespace? Why do you use unnamed namespaces?

but it's unnamed namespace, it's only valid within one file

Um, no?

[MikeyBoy]

Um, no?

Huh? I thought the entire purpose of using an anonymous namespace was to limit the scope of the definitions within it to the translation unit it's in.

[coder777]

Huh? I thought the entire purpose of using an anonymous namespace was to limit the scope of the definitions within it to the translation unit it's in.

Nope, you can access data defined there just like any other data, read this:

http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/unnamed_namespaces.htm

Items defined in an unnamed namespace have internal linkage.

it's for linkage only (or is that what you mean?)

In other words: unnamed namespace are pretty useless

[rmxhaha]

I overlook that sentence before since I don't understand it
internal linkage what is that ?

I guess unnamed namespace are useless...
so why are they invented in the first place... ?

Data is pretty much expose everywhere,,
but it isn't since other file just include header file instead of the source...

if I include the main source file ( Hero.cpp ) to extend it just to make it looks organized, would there is any disadvantages ?

[coder777]

internal linkage what is that ?

that means that the linker doesn't see that particular symbol outside the compiler unit (which is usually a *.cpp)

For instance:
a.cpp and b.cpp both can contain static int x; where x in a.cpp and b.cpp may have different value.
But a.cpp and b.cpp must not contain int x;. The compiler would complain about multiple definitions

I guess unnamed namespace are useless...

More so: if you have t.h:

namespace
{
  int x;
}

There will be no complain from the compiler or linker. It's just that you have an instance of x with internal linkage in each compiler unit you include t.h

By the way: if you put a function prototype in such a unnamed namespace you have to implement that function in each .cpp you include t.h (and use that function) otherwise the linker cannot find definition.

And more strange effects to come.

Data is pretty much expose everywhere,,

What does that mean? Global variables?

but it isn't since other file just include header file instead of the source...

I don't get it

if I include the main source file ( Hero.cpp ) to extend it just to make it looks organized, would there is any disadvantages ?

What do you mean? #include in another cpp? Don't do that

[rmxhaha]

I want to divide this one file into a multiple file

perhaps like this

Hero.h
Hero.cpp
Skill/Tempest.cpp
Skill/Boost.cpp
Skill/Jump.cpp

everything in Skill folder used to be inside Hero.cpp
but I want to divide them so it looks more organized
Those files in Skill folder would need the variables declared inside Hero.cpp



I include header files in each source files
so one source file wouldn't find another source files variables..
except if declared extern in the header file
something like that I think..

[coder777]

Yes, there's no problem to distribute the code.

But, why not provide 'skill' it's own class with header and all? I'd say that the hero has a list of skills and the enemy too

[rmxhaha]

because they need access to data from Hero.cpp
I shouldn't put Hero data inside Hero.h, shouldn't I ?
because it will become a global variable and I don't want that

yes Skill will probably have Skill header file as well
Probably I should just include Hero.cpp inside Skill header file ??

[coder777]

Probably I should just include Hero.cpp inside Skill header file ??

For heaven sake, no

because they need access to data from Hero.cpp

No. A skill shouldn't know anything about the hero. The other way round: The hero should perform his action according to the information stored in the skill struct/class

For instance:

The user command 'J' to the hero. The hero looks in his skill list for skill according to 'J'. If not found: animation 'hero scratches head'. If found: animation 'jump'. The skill contains following information: 10 in y direction. 0 in x direction. 1 sec performance.

Use gravity to get the hero down.

So why would the skill need any information about the hero?

[rmxhaha]

Pretty much every skill is unique
There are some that uses math graphics for their velocity
and deliver many complex things
it's hard to generalized if not impossible

are you trying to say I should do it like this ?

struct Skill {
    vec2 velocity;
    int gaugeUsage;
};

map<char, Skill> SkillsDB;

void init()
{
    Skill jump_skill;
    jump_skill.velocity.x = 0;
    jump_skill.velocity.y = 10;
    jump_skill.gaugeUsage = 10;
    SkillsDB['j'] = jump_skill;
}

There are skill that have something like apply this to hero velocity every 0.1 second or something like that
it's just not one time use

So why would the skill need any information about the hero?

because it's easier to code this way..

struct Skill {
   virtual void update( float dt );
   virtual void force_use();
   float gaugeUsage;
};

struct Jump : public Skill {
    void update( float dt ){
        // Gauge coming from Hero.cpp
        if( keyPress( Key::Space ) && Gauge.getNow() > gaugeUsage ){
        // body coming from Hero.cpp
        auto velo = body->GetVelocity();
        velo.y = 10
        body->SetVelocity( velo );
        Gauge.use( gaugeUsage );
        }
    }
    
};

vector< Skill* > SkillsDB;

and update them periodically

[rmxhaha]

Bump

[coder777]

are you trying to say I should do it like this ?

I wouldn't recommend the usage of global variables...

because it's easier to code this way..

why not doing it like so:

struct Skill {
   virtual void update( SomethingWithGaugeAndVelocity *obj );
   virtual void force_use();
   float gaugeUsage;
};

struct Jump : public Skill {
    void update( SomethingWithGaugeAndVelocity *obj ){
        // Gauge coming from Hero.cpp
        if( keyPress( Key::Space ) && obj->Gauge.getNow() > gaugeUsage ){
        // body coming from Hero.cpp
        auto velo = obj->GetVelocity();
        velo.y = 10
        obj->SetVelocity( velo );
        obj->Gauge.use( gaugeUsage );
        }
    }
    
};

So everything that stems from SomethingWithGaugeAndVelocity can process a jump