1

My C++ project is getting huge. In some situations I'm passing arguments by reference just for my own convenience, in some I don't. Here's an example:

struct foo{
    foo(int &member){
        this->member = &member;
    }
    private:
        int *member;
};

I'm using this pattern when I don't want to create two instances of the int variable. I don't have to implement the get or modify methods to manipulate its value. Instead I can change the variable without even accessing the foo object. However sometimes I'm using a different way of managing the member variables:

struct foo{
    foo(int member){
        this->member = member;
    }
    void modify_member(){
        this->member = 6;
    }
    int get_member(){
        return this->member;
    }
    private:
        int member;
};

I'm not sure whether mixing these two methods of managing members in the same struct is a good practice. Should I normalize it? So for example EVERY function in the given struct will be using the "pass by value" method?

Tomasz Kasperczyk
  • 1,991
  • 3
  • 22
  • 43
  • 2
    If you ask me, you should completely ditch the first method, because it looks confusing and compromises data encapsulation. Other than that, the question is primarily opinion-based. – Christian Hackl Feb 05 '16 at 14:12
  • @ChristianHackl Well I just wanted to know if there's some kind of a rule which I could follow in this situation. For example everyone should format their code, so it's more readable. Everyone should use the singleton pattern in certain situations. You know - there are some rules dictating how should we program. – Tomasz Kasperczyk Feb 05 '16 at 14:18
  • 2
    *"Everyone should use the singleton pattern in certain situations."* - I disagree. In all my years of practical experience, I've found out that it's a deeply flawed anti-pattern. – Christian Hackl Feb 05 '16 at 14:20
  • @ChristianHackl Oh, I didn't know. As you can guess I'm not an experienced programmer, I read about that pattern long time ago. I mentioned it just to provide an example of a "code design" rule. – Tomasz Kasperczyk Feb 05 '16 at 14:24
  • 1
    @user3125731: http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list (Scott Meyers' books + "Coding Standards" by Sutter and Alexandrescu may be precisely what you are looking for). – Christian Hackl Feb 05 '16 at 14:27
  • @ChristianHackl Yep, thank you very much. That's exactly what I needed. – Tomasz Kasperczyk Feb 05 '16 at 14:31

2 Answers2

7

Your first case is a recipe for disaster. You'll end up with dangling pointers and a truck load of undefined behaviour.

Your second case is a poor attempt at encapsulation. There's no need for it. Just use the int. That will reduce the size of your code base.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
0

Code should be simple to read and simple to change, that is in a way that does not break your program. Example one will lead to code, where you can hardly tell where foo instances are altered. Not to forget all the others issues mentioned already.

Example two is okay. In general, providing getters and setters let you add constraints later such as checking value ranges. So I recommend using them, unless you have good reasons not to do so. It also makes refactoring easier.

When passing parameters in a function: As a rule of thumb use pass by value in case of primitive types: int, double, etc.. When passing objects use constant References foo(const MyClass &myClass).

class MyClass {
    public:
    MyClass(const MyOtherClass &member1, int member2){
         this->member1 = member1;
         this->member1 = member1;
    }

    // other functions, getters, setters omitted...

    private:
    MyOtherClass member1;
    int member2;
};
Axel Meier
  • 1,105
  • 2
  • 18
  • 28