Initializers?

[mlt]

What is the best way to create objects as private fields that take
arguments?

I have class A that contains an instance of class B. In A's constructor I
would like to control a field in B:

class A {

private:
B b;
int size;

public A(){
size = 22;
b = B(size);
}

};


class B{

public B() {}

public B(int s) {
this.size = s;

}

private:
int size;

}

But is there a more elegant way to do this (without using static const int
size)?

 

[Bill]

What is the best way to create objects as private fields that take
arguments?

I have class A that contains an instance of class B. In A's constructor I
would like to control a field in B:

class A {

private:
B b;
int size;

public A(){
size = 22;
b = B(size);
}

};


class B{

public B() {}

public B(int s) {
this.size = s;

}

private:
int size;

}

But is there a more elegant way to do this (without using static const int
size)?

I think use of an initializer list (in A's contructor) is more appropriate,
and from your subject line you are apparently onto this.

As it is, your program has a design errors in that in constructing an A
object, Bs default constructor is invoked BEFORE the body of As constructor
is even executed. Your existing constructor for A relies on B having an
appropriate assignment operator.

As constructor should look something like:

A(): size(22), B(size){...}.

For this to work, I think you will need to reorder the private elements of A
since they are allocated in the same order that they are declared--not the
order in which they appear in the initializer list.

Bill

 

[Bill]

By the way, "this" is a pointer in C++ (unlike in Java).

Bill

 

[nosbor]

//something like this

class B{

public:
B() {}

public:
B(int s_):size(s_) {
}

private:
int size;

} ;

class A {

private:
B b;

public:
A(int size_):b(size_){}

};

int main(int argc, char* argv[])
{
A a(22);

return 0;
}

 

[asm23]

The OP's code have many errors. He use this.XXXX which is totally wrong.
I add a variable named "size" as A's member.

//==================================================
class B {

public:
B() {}

public:
B(int s_):size(s_) {
}

private:
int size;

} ;

class A {

private:
B b;
int size;

public:
A(int size_):b(size_),size(size_) {}

};

int main(int argc, char* argv[]) {
A a(22);

return 0;
}
//====================================================================
since as Bill said.
A(int size_):b(size_),size(size_) {}
A(int size_):size(size_),b(size_) {}
are the same function.

But the latter give some warning in mingw compiler:

D:\test\test_console\main.cpp:26: warning: 'A::size' will be initialized
after
D:\test\test_console\main.cpp:25: warning: 'B A::b'
D:\test\test_console\main.cpp:29: warning: when initialized here

So, the initialize sequence is depend on the declaration in class A.

 

[Bill]

The OP's code have many errors. He use this.XXXX which is totally wrong.
I add a variable named "size" as A's member.

//==================================================
class B {

public:
B() {}

public:
B(int s_):size(s_) {
}

private:
int size;

} ;

class A {

private:
B b;
int size;

public:
A(int size_):b(size_),size(size_) {}

};

int main(int argc, char* argv[]) {
A a(22);

return 0;
}
//====================================================================
since as Bill said.
A(int size_):b(size_),size(size_) {}
A(int size_):size(size_),b(size_) {}
are the same function.

But the latter give some warning in mingw compiler:

D:\test\test_console\main.cpp:26: warning: 'A::size' will be initialized
after
D:\test\test_console\main.cpp:25: warning: 'B A::b'
D:\test\test_console\main.cpp:29: warning: when initialized here

So, the initialize sequence is depend on the declaration in class A.

I think I acquired my understanding from Stroustrup's great book: The C++
Programming Language. I just tried both versions of the program on VC++
(version 6.0), and both compiled without a warning. So the bottom line is
your compiler's requirements--no matter what the language definition says!


Bill

 

[asm23]

I think I acquired my understanding from Stroustrup's great book: The C++
Programming Language. I just tried both versions of the program on VC++
(version 6.0), and both compiled without a warning. So the bottom line is
your compiler's requirements--no matter what the language definition says!


Bill

Yes.
Thanks Bill for your reply.
It's exciting to discuss on this forum, and I gain my understanding a lot.

 

[James Kanze]

The OP's code have many errors. He use this.XXXX which is totally wrong..
I add a variable named "size" as A's member.
//==================================================
class B {
public:
B() {}
public:
B(int s_):size(s_) {
}
private:
int size;
} ;
class A {
private:
B b;
int size;
public:
A(int size_):b(size_),size(size_) {}
};
int main(int argc, char* argv[]) {
A a(22);
return 0;
}
//====================================================================
since as Bill said.
A(int size_):b(size_),size(size_) {}
A(int size_):size(size_),b(size_) {}
are the same function.
But the latter give some warning in mingw compiler:
D:\test\test_console\main.cpp:26: warning: 'A::size' will be initialized
after
D:\test\test_console\main.cpp:25: warning: 'B A::b'
D:\test\test_console\main.cpp:29: warning: when initialized here
So, the initialize sequence is depend on the declaration in class A.

I think I acquired my understanding from Stroustrup's great
book: The C++ Programming Language. I just tried both
versions of the program on VC++ (version 6.0), and both
compiled without a warning.

Warnings are always optional. In this case, g++ warns that the
order of initialization isn't the order in which you wrote the
initializations (since it is always the order of the
declarations in the class body). It really doesn't make any
difference in this case, but it's easy to construct cases where
it does.

So the bottom line is your compiler's requirements--no matter
what the language definition says!

The requirements here are the same for all of the compilers I
know. And if you want to write even halfway portable C++, you
do have to go beyond just what the compiler accepts. And if
you're compiler doesn't accept standard conformant code, or does
something which isn't conform with it, you should complain.

 

[David Connet]

Warnings are always optional. In this case, g++ warns that the
order of initialization isn't the order in which you wrote the
initializations (since it is always the order of the
declarations in the class body). It really doesn't make any
difference in this case, but it's easy to construct cases where
it does.

I wish all compilers would complain about this... MS doesn't, even at
warning level 4 (unless I'm missing something that you have to
specifically turn on). And I've worked with many (good) programmers who
think the order of initializers determines the initialization order. I
sure they won't forget after the debugging session finally uncovered what
the bug was...

Dave Connet

 

[asm23]

I wish all compilers would complain about this... MS doesn't, even at
warning level 4 (unless I'm missing something that you have to
specifically turn on). And I've worked with many (good) programmers who
think the order of initializers determines the initialization order. I
sure they won't forget after the debugging session finally uncovered what
the bug was...

Dave Connet

Yes, I have using C++ for about 4 years, but I nearly forget this issue.
It seems that G++ have some advantage. Thanks for your reply. Happy New
Year!

 

[James Kanze]

I wish all compilers would complain about this... MS doesn't,
even at warning level 4 (unless I'm missing something that you
have to specifically turn on). And I've worked with many
(good) programmers who think the order of initializers
determines the initialization order. I sure they won't forget
after the debugging session finally uncovered what the bug
was...

It probably wouldn't hurt. Most of the time, it really doesn't
matter; it's good programming practice to avoid dependencies in
the order anyway. But there are some reasonable exceptions, and
every place I've worked at has insisted that the order in the
initialization list be the same as the order as the
declarations, to avoid any such surprises.

Failing a compiler warning, of course, it's pretty simple to
check for it explicitly in code review.