Which is "safer"

There are two commonly used methods of using the constructor
to initalize data members, so I wondering, purley to improve
my program security, which is safer out of these two methods.

method one:

Code:

---

class Foo
{
public:
  Foo();

private:
  int data1;
  int data2;
  int data3;
};

Foo::Foo() :
  data1(0),
  data2(10),
  data3(100)
  {}

---

method two

Code:

---

class Foo
{
public:
    Foo ( int, int, int );

private:
  int data1;
  int data2;
  int data3;
};

// assume the argument values are passed from main
Foo::Foo ( int d1, int d2, int d3  )
{
  data1 = d1;
  data2 = d2;
  data3 = d3;
}

---

Thinking again, is calling a set member function on each data
member to initalize more safer? As it would be possible to do this:

Code:

---

void Foo::setData1 ( int  d1 )
{
  if ( d1 < 0 )
  {
      std::cout << "\nPassed value is negative!\n";
  }

  else
  {
      data1 = d1;
  }
}

---

I know the above code is not correct in general, but that is the general idea.

I am wondering, which method is considered the most safe for initalizeing data
members?

Any help greatly appreciated! :)

On above the other is not safer per se, it's more about efficiency. Using the initializer list calls the constructor.
If you don't, then the default constructor will be called and the operator =.

Quote:

---

Thinking again, is calling a set member function on each data
member to initalize more safer?

---

I don't think this is particularly safe. User code should not be responsible for putting an object into a usable state (you may forget to call some setters, you may call them in an incorrect order) and in your example there is a possibility that the variable is left uninitialized (if input is negative).

There is also no reason why you can't check the arguments of the constructor and use a default value or throw an exception if the condition is not met. (If you have a good validating setter, you might use it in the constructor as well.)

It seems even possible to use the throw statement in ternary operator to use in initializer list:

Code:

---

class X
{
    int n;
    public:
    X(int x):
        n(x < 0 ? throw std::range_error("Input must not be negative") : x)
    {}
    //...
};

---

In any case, if your object is in a good usable state (all members initialized etc) after the constructor finishes that is "safe", and if that is not true (user needs to do something else to make the object usable, e.g call setters to "initialize" members) that is "unsafe".

Quote:

---

Originally Posted by anon

Code:

---

class X
{
    int n;
    public:
    X(int x):
        n(x < 0 ? throw std::range_error("Input must not be negative") : x)
    {}
    //...
};

---

---

I dont think this will compile, both expressions in the ternary operator must yield the same type

The standard draft says this:

Quote:

---

--The second or the third operand (but not both) is a throw-expression
(_except.throw_); the result is of the type of the other and is an
rvalue.

--Both the second and the third operands have type void; the result is
of type void and is an rvalue. [Note: this includes the case where
both operands are throw-expressions. ]

---

swgh, you might want to be "const-correct":

Code:

---

    Foo ( int const&, int const&, int const&);

---

instead of

Code:

---

    Foo ( int, int, int );

---

This first uses a reference, so it does not copy the argument, and second it is const-correct: it makes the compiler help you spotting some unwanted changes in the argument (which didn't occur for the copy, however).

Why would you want to use references here? It adds overhead without adding anything of value. If you want to protect against changing the int (which usually isn't necessary) then make the parameters const int instead of int or const int&.

MarkZWEERS: passing by const reference is only really beneficial for objects that are bigger than integer - this particularly applies to std::string, std::vector, struct/class with more than a couple of (simple) member variables and other "potentially huge" objects.

However, passing a simple integer actually ADDS overhead in that it passes the address of the integer, and for the relevant code to get to the actual value it will first have to fetch the address, then fetch the number.

I'd personally say that anywhere "const int &" occurs is probably a good place to remove the & - having const there would indicate to anyone else that the value is just taken as is, and not changed, which can help the compiler in it's task of optimizing under some circumstance, but otherwise serves little purpose [and good compilers probably figures out that it's not changing anyways].

--
Mats