Prevent member variable from being modified after construction

I've ran into situations once or twice where the class constructor sets a member variable, after which it should not be modified.

Is there a way of getting a member to behave as if it were const, but only after the constructor runs?

Some example code:

Code:

---

class Foo {
    public:
    Foo(int in) {
        member = in;    // initial assignment in constructor is legal
    };
   
    void testMember() {
        if(member = 1);    // accidental assignment should be illegal
          //do something
       
        // legitimately modify other class data besides member
    };   
   
    private:
    int member; // should not be modified by any function besides constructor
};

---

The code executes. I'm just curious if there is someway to make the accidential reassignment in testMember() illegal.

Thanks.

You could have everything private, and modifiable only by the use of member functions (I think that's called properties...). Have these functions check for a flag set when the constructor runs before altering the variable.

>Is there a way of getting a member to behave as if it were const, but only after the constructor runs?
Make it const. :)

Code:

---

class Foo {
public:
  Foo(int in): member(in) {
  }

  void testMember() {
    if(member = 1) // Illegal
      ;
  } 

private:
  const int member;
};

---

Because the constructor initializer list can initialize const members, you can use it to perform the initialization while still benefitting from the member being const.

Quote:

---

Make it const.

---

Or that :D. It just seemed to obvious!

Code:

---

Foo(int in): member(in) {
}

---

Ah. It works. But could you explain that syntax?

I had tried:

Code:

---

Foo(int in) {
      member = in;
};

---

and gotten an "illegal assignment of read-only data member" from dev-c++.

I don't understand the difference between the two.

Quote:

---

Originally Posted by AH_Tze

Code:

---

Foo(int in): member(in) {
}

---

Ah. It works. But could you explain that syntax?

I had tried:

Code:

---

Foo(int in) {
      member = in;
};

---

and gotten an "illegal assignment of read-only data member" from dev-c++.

I don't understand the difference between the two.

---

In the first syntax the variable is initalised as it constucted. In the second the variable is initialised after it is constructed which is illegal since the variable is const.

Ah. I'd seen something similiar using user-defined types, but I'd never seen a primitive data type being initialized that way. Very clever.

Thanks all, and I am once again in Preludes debt. :)

>but I'd never seen a primitive data type being initialized that way. Very clever.
I would recommend getting into the habit of using the initialization list rather than assignment in your constructors. It's always legal, and often more efficient. Of course, it could be impractical if you have a huge number of members to initialize, but that's really a sign of bad design IMO. ;)

Quote:

---

Originally Posted by AH_Tze

Code:

---

Foo(int in): member(in) {
}

---

Ah. It works. But could you explain that syntax?

I had tried:

Code:

---

Foo(int in) {
      member = in;
};

---

and gotten an "illegal assignment of read-only data member" from dev-c++.

I don't understand the difference between the two.

---

Imagine that member is ... a vector, and you want it to have at first 10 elements allocated. Calling

Code:

---

Foo(int in) {
      member = vector<int>(10);
};

---

isn't the same as

Code:

---

Foo(int in) : member(10){}

---

Why you may ask?
When as class is declared, memory is allocated. If the class is derived, the base class constructor is called. The variables constructors are called, and last the main constructor for that class. This behaviour is extremely important because when the body of a contructor is executed, every variable must have been correctly initialized, otherwize, manipulating those variable could result fatal. Making an assignement to a int in the body isn't bad practice, but it's not also good, because it can lead to bad habits.
But making an assignement to a vector class is very bad!!! Because when your constructor is executed your vector class is already constructed. Assingning it another value through '=' implies creating a new temporary vector, calling operator=(), then deconstructing the temporary vector. This is EXTREMELY ineficient.

EDIT: here's an example of this behaviour

Code:

---

#include <iostream>

class A{
        int val;
public:
        A(int n=0) : val(n){std::cout  << "A  constructed and val "<<val<<std::endl;}
        ~A(){std::cout  << "A deconstructed and val "<<val<<std::endl;}
        A& operator=(const A& a){
                val=a.val;
                std::cout  << "A  operator=() called and val "<<val<<std::endl;
        return *this;}
};
class B{
        int val;
public:
        B(int n=1) : val(n){std::cout  << "B  constructed and val "<<val<<std::endl;}
        ~B(){std::cout  << "B deconstructed and val "<<val<<std::endl;}
};
class C{
        int val;
public:
        C(int n=2) : val(n){std::cout  << "C  constructed and val "<<val<<std::endl;}
        ~C(){std::cout  << "C deconstructed and val "<<val<<std::endl;}

};
class D: public C{
public:
        A a;
        B b;
        D(){
                std::cout  << "D  constructed\n";
                a = A(10);
                b = B(56);

        }
        ~D(){std::cout  << "D deconstructed"<<std::endl;}
};
int main(){
        D d;
        return 0;
}

---

And the output

Code:

---

//beginning - D class initialization
C  constructed and val 2    //base C class of D constructed
A  constructed and val 0    //class A var in D constructed
B  constructed and val 1    //class B var in D constructed
D  constructed                  //D constuctor executed
A  constructed and val 10  //temporary A class for assignement created
A  operator=() called and val 10  //a assigned
A deconstructed and val 10 //temporary var desconstructed
B  constructed and val 56  //temporary B class for assignement
B deconstructed and val 56 //temporary B class deconstructed
// - My compiler seemed to create a default B::operator=()
//I dont' know if this is standard behaviour

//end
D deconstructed
B deconstructed and val 56
A deconstructed and val 10
C deconstructed and val 2

---

If you call the constructors for the variables, recomended, instead of assigning values to then, like showed above, the output would be

Code:

---

C  constructed and val 2
A  constructed and val 10
B  constructed and val 56
D  constructed

D deconstructed
B deconstructed and val 56
A deconstructed and val 10
C deconstructed and val 2

---

Each constructor called only once. Good behaviour

Quote:

---

In the second the variable is initialised after it is constructed which is illegal since the variable is const.

---

Actually in the second one the very is left uninitialized and it attempts to assign a value to a const object.

Remember initalization is done once and only once at creation. Everything after that point is assignment.

edit: @AH_Tze: If you want to make sure that none of your data members are changed by a particular member function you can declare that function const. Example:

Code:

---

class Foo
{
  int x;
  const iny y;
  public:
    Foo(int i) : x(1), y(i) {}
    int getX() const { return x; }
    int getY() const { return y; }
    int changeY(int i) { return y=i; } // error y is const
    int changeX(int i) const { return x=i; } // error function is const
};

---

By putting const after the () you ensure that nothing is changed in the object regardless of constness

Quote:

---

By putting const after the () you ensure that nothing is changed in the object regardless of constness

---

The exception being of course mutable variables. ;)

Another note about intializer list:
- If you are constructing an object of a derived type, and need to pass data down to the constructor of the base type, this is the only place to do it.
- If you have member data (of user defined types) which do not have default constructors, then they must be initialized at construction via the initializer list.

Yeah I forgot about mutable mainly because I've never seen it's usage. I should point out that const is just a compiler guarantee and the clever (or very unlucky) programmer can easily get around it.

>>Actually in the second one <snip detailed explanation>
>The exception being of course mutable variables. ;)
Does this ever seem to anyone like a geek's ........ing contest?

Geek 1: "I'm smart. Here's why."
Geek 2: "You're smart, but there's a miniscule error here. So I'm smarter."
Geek 3: "You're smart too, but not smarter than me because your correction makes an assumption."
Geek 4: "You're the smartest one of all because you knew that, but I'm even smarter because I know that in the Real World(TM), you can't do anything serious without making assumptions."
Geek 1: (defending his honor) "The question was theoretical to begin with, so you're all not as smart as me because I answered it with that in mind. MUAHAHAHAHAHA!"

* Thread degenerates into flames about trivial mistakes in grammar and spelling *

;)

Some greek philosopher used a similar argument. I think it was Plato:

Geek #5: "I must be the smartest one here because I'm the only one that knows I don't know everything!"
Geek #6: "Your fly's open."

Geeks arguements are still better then nerds arguring about Sci Fi TV shows :)

Or the pronunciation of 'gif'.

I love a good Strong Bad reference:
http://homestarrunner.com/sbemail51.html

Beam me up Scotty.

Well "gif" has a set pronucation setforth by the creators. As such there is no argument.

@OP: The way I've always understood it is, as the class is being constructed, everything in the ':' section of the class constructor is basically a list of the parameters to pass to each of the member variables' constructors as they in turn are being created. If you have a member variable which is an object of another class that doesn't have a default constructor, then you are required to specify parameters in the ':' block for that member; otherwise, the default constructor is used. The same goes for POD types: You can choose to provide a value for its 'constructor' (or initialization for POD types, maybe), or you can choose not to - but in the case of declaring a const variable, there is nowhere else in your program that you can give it a value, so it must be done in the ':' block via the constructor argument.

@Hijackers: I just found it funny that we're talking about Greek philosophers talking about Geek arguments :D

Don't worry Prelude, we all know you're the smartest Geek around. :D

My goodness, Prelude... it's gonna take me a while to get used to that new avatar...

Quote:

---

Originally Posted by sean_mackrory

My goodness, Prelude... it's gonna take me a while to get used to that new avatar...

---

Whoa! Now I'm confuzzled too. :p

Seeing as how this thread has already been hijacked mercilessly..
I see Prelude's avatar problems have finally been resolved :)

What avatar problem?

>I see Prelude's avatar problems have finally been resolved
Yes, I'm happy. :)

>What avatar problem?
I couldn't change my avatar.

>it's gonna take me a while to get used to that new avatar...
Just stare at it for a few minutes and the overwhelming cuteness will cause all of your worries to evaporate. Though it may hurt my credibility a bit.

"Wow, this Prelude person sure seems to know a lot about C++."
*Look at the avatar*
"Whoa, neko kawaii! ^_^"
*Look back at the post*
"What was I just thinking? I can't remember."

;)

http://cboard.cprogramming.com/showt...326#post418326
Last post, by Prelude.. and she's referring to some earlier post, but I don't feel like searching through 20 bazillion pages for it :)

**EDIT**
Hm, reminds me of that world domination thread somewhere...

Oh! I remember that! That was about the same time as that little RobC incident...

edit: Prelude - there's an idea for your list of memorable moments on Cboard *wink* *wink*

>there's an idea for your list of memorable moments on Cboard *wink* *wink*
Bleh, I'd rather forget about that ordeal. You can record it in the annals for me.

use const

Um algi thats already been mentioned and the thread has been properly hijacked. Please do not attempt to rerail :)