Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Initializers?

0 views
Skip to first unread message

mlt

unread,
Dec 28, 2008, 8:05:35 AM12/28/08
to
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

unread,
Dec 28, 2008, 8:39:13 AM12/28/08
to

"mlt" <as...@asd.com> wrote in message
news:495779a0$0$90269$1472...@news.sunsite.dk...

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

unread,
Dec 28, 2008, 8:41:16 AM12/28/08
to

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

Bill


nosbor

unread,
Dec 28, 2008, 8:52:25 AM12/28/08
to
//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

unread,
Dec 29, 2008, 6:59:30 AM12/29/08
to
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

unread,
Dec 29, 2008, 8:52:21 PM12/29/08
to

"asm23" <asmwa...@gmail.com> wrote in message
news:gjae46$9ql$1...@news.cn99.com...

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

unread,
Dec 29, 2008, 9:45:11 PM12/29/08
to
Bill wrote:
>
> 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

unread,
Dec 30, 2008, 5:33:30 AM12/30/08
to

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

> > private:
> > int size;
> > } ;

> > class A {

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

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.

--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

David Connet

unread,
Dec 30, 2008, 12:50:32 PM12/30/08
to
James Kanze <james...@gmail.com> wrote in
news:273d15eb-d31c-4847...@r15g2000prd.googlegroups.com:

> Bill wrote:
>> "asm23" <asmwa...@gmail.com> wrote in message
>> news:gjae46$9ql$1...@news.cn99.com...

>> > 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.

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

unread,
Dec 30, 2008, 9:16:12 PM12/30/08
to
David Connet wrote:
>
> 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

unread,
Dec 31, 2008, 2:37:33 AM12/31/08
to
On Dec 30, 6:50 pm, David Connet <st...@agilityrecordbook.com> wrote:
> James Kanze <james.ka...@gmail.com> wrote
> innews:273d15eb-d31c-4847...@r15g2000prd.googlegroups.com:
> > Bill wrote:
> >> "asm23" <asmwarr...@gmail.com> wrote in message

> >>news:gjae46$9ql$1...@news.cn99.com...
> >> > 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.

> 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.

0 new messages