Jump to content

  • Log In with Google      Sign In   
  • Create Account

AlanSmithee

Member Since 19 May 2011
Offline Last Active Today, 10:33 AM

Posts I've Made

In Topic: Encapsulation through anonymous namespaces

Yesterday, 01:04 AM

Hi!

 

Thanks to everyone for contributing, I have learnt a few things.

 

Ravyne, you are pretty much spot on with everything you say, except me being against the idea of having free functions as a part of the interface - this is actually what I want to achive - sorry if I was unclear. What I did have a problem with was hiding away things that should not be in the public interface. This was a problem to me, because I was not using any form of  formal encapsulation (like a class). I was essentially moving from one extreme (using classes for everything) to another extreme (don't use classes at all). I think that was what was making it "not feel right".

 

So, gathering what has been said in this thread, this is the current solution I am considering: (psuedo code example)

// Public interface of texture manager
namespace TextureManager
{
    class Instance
    {
        public:
            void ChangeTheStateOfThisInstance()
            {
                 ++_secretVariable;
             }
 

            void ChangeTheStateOfThisInstanceTwo()
            {
                 --_secretVariable;
             }
 

            void ChangeTheStateOfThisInstanceThree()
            {
                 _secretVariable *= _secretVariable;
             }
 
         private:
             int _secretVariable = 0;
    };
 
    void IAmAPartOfTheTextureManagerInterface(Instance textureManager)
    {
        textureManager.ChangeTheStateOfThisInstance();
        textureManager.ChangeTheStateOfThisInstanceTwo();
        textureManager.ChangeTheStateOfThisInstanceThree();
    }
};
 
// Usage
int main()
{
    TextureManager::Instance textureManager;
 
    TextureManager::IAmAPartOfTheTextureManagerInterface(textureManager);
 
    // and/or
 
    textureManager.ChangeTheStateOfThisInstanceTwo();
   
    ...
 
    return 0;
}

This feels good to me, and if I am consistent with how I provide the public interface of different functionality, I think it could work well.

I do however realize that not all will agree with the usage of namespaces or the naming conventions used in the above example.

No need for any anonymous namespace here atleast. Should the need arise, it would be another tool in the toolbox though.

 

Naming conventions aside, I think this is pretty much what Ravyne is talking about?

Any feedback on this approach?

 

Thanks again!


In Topic: Encapsulation through anonymous namespaces

22 January 2015 - 08:46 AM

Hi, thanks for your input.

 

Yes, ofcourse the anonymous namespace would be in the source file, and the example was only to show what I mean.

I do understand your reasoning though and I agree that if I am going to use classes or structs, the need for anonymous namespaces more or less goes away.


In Topic: Encapsulation through anonymous namespaces

22 January 2015 - 07:41 AM

Thanks guys!

 



However, the 'there can only be one' and thus the singleton/global-state is a code smell. Why dictate that the library has to have a single global state and restrain it like that if you don't have to?

 

This is something I have been thinking about a lot.
For example; in a thread discussing something related, someone talked about using multiple instances of a rendering engine for debugging purposes.
This is a very valid point and I am taking this into consideration.
 
One approach I am considering is encapsulating all state-related information into a class or struct, say "Renderer", and leave the public interface as free functions (with anonymous "helper" namespace):
 
namespace // private helper methods and variables (constants etc)
{
    int DrawHelper(const RenderAPI::Renderer& renderer)
    {
        return renderer.GetSomething();
    }
}
 
namespace RenderAPI // public renderer API
{
    class Renderer
    {
        public:
            int GetSomthing() { return _something; }
 
        private:
            int _something;
    };

    Draw(const Renderer& renderer)
    {
        DrawHelper(renderer);
    }
};
 
Which seems like a good tradeoff to me.. Think this would be overengineering?

In Topic: Handmade Hero discussion thread

08 January 2015 - 03:28 AM

Watched the first episode yesterday after hearing Jonathan Blow talking about him (which I guess is not so weird, now that I know he was a coder for "The Witness") and was pleasently surprised.

 

Personally I am pretty good at coding, but very bad at everything "around" coding, such as build systems etc, and it looks like he is covering stuff like that, so I will continue watching it. =)


In Topic: Which parameter of CreateWindowEx() is incorrect in my code?

03 December 2014 - 05:18 AM

 

 

 

If you're starting it is fine, but creating your own library all you're doing is what you have to do in the future that is to build your own things not using third party or open source libraries. Having full control of your application is essencial in my opinion


Mind explaining why you think it is essential to have "full control" over such a well defined and solved problem as windowing, which SDL (amongst other frameworks) provides a good (platform independant) solution to? I can understand wanting to do it, but I cannot see how it would be essential to have low level control over such a thing..?

 

It's not like it isn't a useful thing to learn, I've had people ask me why I've used winapi in some of my programs, there are plenty of reasons.
  • SDL/SFML/Some windowing library, isn't always going to be good enough, it also introduces a dependency you may not want to have.
  • It's good to do it a few times, IMO, too many people here comment like you should avoid things they already learned even though understanding.
  • An example of learning might be: how the OS painting and GDI works is useful, or how raw OS messages are actually given and translated by libraries into a more friendly form. Things make a lot more sense after you learn them a bit.
My rule of thumb besides tinkering around with winapi to learn more about it, is only use it if I'm writing everything else from scratch anyway. I definitely would suggest SDL or SFML if your focus is more on just getting a game together though.

 

If is just a game you should use an existing game engine to the job since is 10x higher level than libraries such SDL, SFML, etc.

 

Agreed, unless you got some other motive, like you want to do it for fun or as a learning excercise. I also understand the reasons listed by Satharis and I agree that it is indeed useful to learn. What I dont get is why it would be essential to have full control over windowing..


PARTNERS