Good idea to make all members static IF....

[fiji885]

I have been quite interested in what is considered "good practice" and "bad
practice" in C++ for a little while now. I've read and read, and have concluded
that some "standards" for what is considered good programming and bad
programming are be de-facto standards (code formatting, cleanliness, etc).
Heck, to be completely honest, I'm still a little fuzzy to what good
programming is. Anyways, to my actual question: if I have an extern object of a
class, and I only want to have one object of that class instantiated throughout
the whole program, is it a good idea to make all the member variables static? I
mean, I wont be instantiating another object of said class, so why not make all
variables static? I tell myself this, but then at the same time, I also think
if I'm only going to have one class object instantiated thruoghout the entirety
of the program, does it really matter? Is it one of those "doesn't really
matter" type things?

For example, this is a very underdeveloped class of a an asset manager for a 2D
rpg game that I'll be making... I only need one object of the class instantied,
and I'll make that object an extern object. But to make the variables all
static?... Would it be good programming, bad programmin, or for this case, will
it simply not matter?

#pragma once
#include <SFML/Graphics.hpp>
#include <SFML/Audio.hpp>
#include <map>

namespace fg {
/* ----------------------------------------------------------------------------
 * ENUM CLASS:
 *   
 * DESCRIPTION:
 *   Enum class for key use with std::map.
 * --------------------------------------------------------------------------*/
  enum class textureKey {
  };

/* ----------------------------------------------------------------------------
 * CLASS:
 *   assets class...
 * DESCRIPTION:
 *   Class that holds all assets. It will only have one object instantiated.
 * --------------------------------------------------------------------------*/
  class assets {
    public:
      assets();
      std::string _getTextStr(textureKey&) const;
    private:
      static std::map<textureKey, std::string> _textureStr;
  };

/* ----------------------------------------------------------------------------
 * Declare extern here
 * --------------------------------------------------------------------------*/
  extern assets aObj;
}

[JLBorges]

Why do you need a class and one object of that class at all? Why not just:

header fg.h

#ifndef FG_H_INCLUDED
#define FG_H_INCLUDED

#include <string>
#include <map>

namespace fg {

    enum class textureKey {
        // ...
    };

    namespace assets {

        std::string text( textureKey key ) ;
    }

}

#endif // FG_H_INCLUDED 

implementation fg.cpp

#include "fg.h"

namespace {

    std::map< fg::textureKey, std::string > texture_map {

        // map entries
    };

};

std::string fg::assets::text( textureKey key ) {

    const auto iter = texture_map.find(key) ;
    return iter == texture_map.end() ? "" : iter->second ;
}

[fiji885]

This is pretty cool... I would have never thought of information hiding like
this. The only information hiding What i practice really just deals with
classes so far. Can you explain:

#include "fg.h"

namespace {
    // I know this part is somewhat like the equivalent of the private area of a class.
    // But why is it encased in a namespace?
    std::map< fg::textureKey, std::string > texture_map {

        // map entries
    };

};

std::string fg::assets::text( textureKey key ) {

    const auto iter = texture_map.find(key) ;
    return iter == texture_map.end() ? "" : iter->second ;
}

I'm not too use to seeing a namespace keyboard just by itself... Can't you just
have

#include "fg.h"

std::map< fg::textureKey, std::string > texture_map {

    // map entries
};

std::string fg::assets::text( textureKey key ) {

    const auto iter = texture_map.find(key) ;
    return iter == texture_map.end() ? "" : iter->second ;
}

[JLBorges]

> I'm not too use to seeing a namespace keyboard just by itself... Can't you just have ...

The reason for using an unnamed namespace here is that we want texture_map to be an implementation detail which can't be made programatically visible to the rest of the program. In other words, we want the name texture_map to have internal linkage; it can only be accessed from within fg.cpp.

Note that this is true encapsulation: in contrast, private implies visible, but not accessible.