class object initialisation

Hi,

I have always been taught to use an inialization list for initialising data
members of a class. I realize that initialsizing primitives and pointers use
an inialization list is exactly the same as an assignment, but for class
types it has a different effect - it calls the copy constructor.

My question is when to not use an initalisation list for initialising data
members of a class?


Regards
Adi



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.516 / Virus Database: 313 - Release Date: 1/09/2003

re: class object initialisation

"A" <A@iprimus.com.au> wrote in message
news:3f61b50b_1@news.iprimus.com.au...
| I have always been taught to use an inialization list for initialising
data
| members of a class. I realize that initialsizing primitives and pointers
use
| an inialization list is exactly the same as an assignment, but for class
| types it has a different effect - it calls the copy constructor.
|
| My question is when to not use an initalisation list for initialising data
| members of a class?

Only when you are unable to, e.g. when a complex computation involving
several intermediate variables is needed and a dedicated function doesn't
make sense.

IMO the initialization list should always be preferred.


Regards,
--
http://ivan.vecerina.com

re: class object initialisation

"A" <A@iprimus.com.au> wrote in message
news:3f61b50b_1@news.iprimus.com.au...[color=blue]
> Hi,
>
> I have always been taught to use an inialization list for initialising[/color]
data[color=blue]
> members of a class. I realize that initialsizing primitives and pointers[/color]
use[color=blue]
> an inialization list is exactly the same as an assignment, but for class
> types it has a different effect - it calls the copy constructor.
>
> My question is when to not use an initalisation list for initialising data
> members of a class?[/color]

The basic rule of thumb is that anything that can go in the initialize list
should go there. Obviously, you can't put something like this in there:
if (a)
i = 2;
else
i = 4;

re: class object initialisation

> > Hi,[color=blue][color=green]
> >
> > I have always been taught to use an inialization list for initialising[/color]
> data[color=green]
> > members of a class. I realize that initialsizing primitives and pointers[/color]
> use[color=green]
> > an inialization list is exactly the same as an assignment, but for class
> > types it has a different effect - it calls the copy constructor.
> >
> > My question is when to not use an initalisation list for initialising[/color][/color]
data[color=blue][color=green]
> > members of a class?[/color]
>
> The basic rule of thumb is that anything that can go in the initialize[/color]
list[color=blue]
> should go there. Obviously, you can't put something like this in there:
> if (a)
> i = 2;
> else
> i = 4;[/color]

Many, if not most, of those cases can be covered by the ?: operator:
MyClass(int a) : i(a ? 2 : 4) {}

/ Erik

re: class object initialisation

Erik wrote:
....[color=blue][color=green]
>>should go there. Obviously, you can't put something like this in there:
>>if (a)
>> i = 2;
>>else
>> i = 4;[/color]
>
>
> Many, if not most, of those cases can be covered by the ?: operator:
> MyClass(int a) : i(a ? 2 : 4) {}
>[/color]

Yep - and sometimes it makes sense to create a function that does more
complex things so that everything is in the initializer list.

re: class object initialisation

"Gianni Mariani" <gi2nospam@mariani.ws> wrote in message
news:bjsqne$oou@dispatch.concentric.net...[color=blue]
> Erik wrote:
> ...[color=green][color=darkred]
> >>should go there. Obviously, you can't put something like this in there:
> >>if (a)
> >> i = 2;
> >>else
> >> i = 4;[/color]
> >
> >
> > Many, if not most, of those cases can be covered by the ?: operator:
> > MyClass(int a) : i(a ? 2 : 4) {}
> >[/color]
>
> Yep - and sometimes it makes sense to create a function that does more
> complex things so that everything is in the initializer list.[/color]

And how exactly do you propose calling such a function from the initializer
list?

re: class object initialisation

"Erik" <no@spam.com> wrote in message news:bjspcn$r22$1@news.lth.se...[color=blue][color=green]
> > The basic rule of thumb is that anything that can go in the initialize[/color]
> list[color=green]
> > should go there. Obviously, you can't put something like this in there:
> > if (a)
> > i = 2;
> > else
> > i = 4;[/color]
>
> Many, if not most, of those cases can be covered by the ?: operator:
> MyClass(int a) : i(a ? 2 : 4) {}[/color]

Yeah, maybe simple "if" cases like that, but you can't put logic or function
calls (other than base class constructors) in the initializer list. You
added an expression, not a statement.

re: class object initialisation

"jeffc" <nobody@nowhere.com> wrote in message news:3f622ea6_1@news1.prserv.net...[color=blue]
>[/color]
[color=blue][color=green]
> > Yep - and sometimes it makes sense to create a function that does more
> > complex things so that everything is in the initializer list.[/color]
>
> And how exactly do you propose calling such a function from the initializer
> list?[/color]

Same way you call any other function. It behooves you not to use the
yet uninitialized parts of the object being constructed though.

re: class object initialisation

"jeffc" <nobody@nowhere.com> wrote in message news:3f622fa7_4@news1.prserv.net...
[color=blue][color=green]
> > Many, if not most, of those cases can be covered by the ?: operator:
> > MyClass(int a) : i(a ? 2 : 4) {}[/color]
>
> Yeah, maybe simple "if" cases like that, but you can't put logic or function
> calls (other than base class constructors) in the initializer list. You
> added an expression, not a statement.[/color]

Who says you can't have function calls?

re: class object initialisation

Ying Yang wrote:
[color=blue][color=green]
>>
>>Never.
>>Initialization lists are the only way to *initialize* members of a class
>>or to specify which constructor from a base class should be used.[/color]
>
>
> No, it's not the only way - as i mentioned you can use an assignment
> operator for initialising primitive data members, which is the same as using
> an initialization list.[/color]

No, you cannot initialize anything with an assignment operator ever.
Assignment operators assign, they don't initialize. If you don't the
difference, you should look it up.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: class object initialisation

Kevin Goodsell <usenet1.spamfree.fusion@neverbox.com> wrote in message news:<7tv8b.918$UN4.802@newsread3.news.pas.earthli nk.net>...
[color=blue][color=green]
> > No, it's not the only way - as i mentioned you can use an assignment
> > operator for initialising primitive data members, which is the same as using
> > an initialization list.[/color][/color]

(NB: This is true for all POD types, not just primitive types.)
[color=blue]
> No, you cannot initialize anything with an assignment operator ever.
> Assignment operators assign, they don't initialize. If you don't the
> difference, you should look it up.[/color]

int n; // n is not initialized
n = 0; // 0 assigned to n

Using an uninitialized lvalue as an rvalue is undefined (4.1/1). If
assignment doesn't initialize, ever, then

printf("%d\n", n);

results in undefined behavior. I, for one, highly doubt that.

- Shane

re: class object initialisation

Shane Beasley wrote:
[color=blue]
>
>
> int n; // n is not initialized
> n = 0; // 0 assigned to n
>
> Using an uninitialized lvalue as an rvalue is undefined (4.1/1).[/color]

Using an indeterminate lvalue is undefined. "Uninitialized" is used to
mean "indeterminate" sometimes, apparently even in the standard.
[color=blue]
> If
> assignment doesn't initialize, ever, then[/color]

It doesn't. It assigns.
[color=blue]
>
> printf("%d\n", n);
>
> results in undefined behavior. I, for one, highly doubt that.[/color]

The value is not indeterminate at this point.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: class object initialisation

[color=blue]
> Ying Yang wrote:
>[color=green][color=darkred]
> >>
> >>Never.
> >>Initialization lists are the only way to *initialize* members of a class
> >>or to specify which constructor from a base class should be used.[/color]
> >
> >
> > No, it's not the only way - as i mentioned you can use an assignment
> > operator for initialising primitive data members, which is the same as[/color][/color]
using[color=blue][color=green]
> > an initialization list.[/color]
>
> No, you cannot initialize anything with an assignment operator ever.
> Assignment operators assign, they don't initialize. If you don't the
> difference, you should look it up.[/color]

To initialize means you give a variable it's initial value. An assignment
operator can be used to give a variable it's initial value, and it can also
be used to re-assign a variable with a different value, providing the
variable is not defined as constant. The point is, you can initialise data
members via two of the following ways: assignment or an initialisation list.
However, the behaviour of the two is different depending whether is it a
primitive or class type data member you want to initialize. If you don't
agree with my definition of assignment and initialisation then I like to
hear your definitions.

re: class object initialisation

A wrote:
[color=blue]
>
> To initialize means you give a variable it's initial value.[/color]

Agreed.
[color=blue]
> An assignment
> operator can be used to give a variable it's initial value,[/color]

No, it can't. If you believe it can, please give an example.
[color=blue]
> and it can also
> be used to re-assign a variable with a different value, providing the
> variable is not defined as constant. The point is, you can initialise data
> members via two of the following ways:[/color]

Well, you can't give something its initial value twice, so I assume you
mean "one of the following ways".
[color=blue]
> assignment or an initialisation list.[/color]

....But you're still wrong. Assignment does not give an initial value to
something. Assignment can only happen to an existing object. Since the
object must exist prior to the assignment, it clearly has already
received its initial value.
[color=blue]
> However, the behaviour of the two is different depending whether is it a
> primitive or class type data member you want to initialize. If you don't
> agree with my definition of assignment and initialisation then I like to
> hear your definitions.[/color]

Initialization happens when an object is initially constructed.
Assignment can only happen after that time (or not at all, for certain
types of objects).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: class object initialisation

"jeffc" <nobody@nowhere.com> wrote in message news:<3f622fa7_4@news1.prserv.net>...[color=blue]
> "Erik" <no@spam.com> wrote in message news:bjspcn$r22$1@news.lth.se...[color=green][color=darkred]
> > > The basic rule of thumb is that anything that can go in the initialize[/color][/color]
> list[color=green][color=darkred]
> > > should go there. Obviously, you can't put something like this in there:
> > > if (a)
> > > i = 2;
> > > else
> > > i = 4;[/color]
> >
> > Many, if not most, of those cases can be covered by the ?: operator:
> > MyClass(int a) : i(a ? 2 : 4) {}[/color]
>
> Yeah, maybe simple "if" cases like that, but you can't put logic or function
> calls (other than base class constructors) in the initializer list. You
> added an expression, not a statement.[/color]
There are plenty of things you can put in the initializer list.
You can put functions, additions, conditon logic, and more.
Example:

class foo
{
public:
foo(int x, const std::string &Src)
:m_i((x > 3)?Func2(8):x),
m_data((Src == "test")?Func1("good"):Func1(Src)+" test"),
i(m_i)
{
}

private:
std::string Func1(const std::string &Src){return "Hello World " + Src;}
int Func2(int y){return y + 44;}
int m_i;
public:
const std::string m_data;//Needs to be in an initialized list
const int &i; //Needs to be in an initialized list
};

int main(int argc, char* argv[])
{
foo myfoo(2, "bla bla");
cout << myfoo.m_data << endl;
cout << myfoo.i << endl;

system("pause");
return 0;
}

re: class object initialisation

"A" <A@iprimus.com.au> wrote in message news:<3f61b50b_1@news.iprimus.com.au>...[color=blue]
> Hi,
>
> I have always been taught to use an inialization list for initialising data
> members of a class. I realize that initialsizing primitives and pointers use
> an inialization list is exactly the same as an assignment, but for class
> types it has a different effect - it calls the copy constructor.
>
> My question is when to not use an initalisation list for initialising data
> members of a class?
>
>
> Regards
> Adi
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.516 / Virus Database: 313 - Release Date: 1/09/2003[/color]

You need to have an item in the initialize list if it's a constant or
a reference data member.
You also need to have the base class constructor in the initializer
list if the base class does not have a default contructor.

I recommend that you always TRY to use the initialize list.

An initializer list may not be appropriate when you have multiple
constructors, and serveral member variables that have common
initialization values with all the constructors.
In such cases, it's common to create an function initializer to
consolidate the logic.
Example:
class car
{
public:
car(){Initialize();}
car(int x){Initialize();}
car(const char* s){Initialize();}
inline void Initialize()
{
QtyWheels = 4;
ID = -1;
Make = "n/a";
}
private:
int QtyWheels;
int ID;
std::string Make;
};

re: class object initialisation

Kevin Goodsell <usenet1.spamfree.fusion@neverbox.com> wrote in message news:<LRI8b.1863$UN4.213@newsread3.news.pas.earthl ink.net>...
[color=blue]
> Using an indeterminate lvalue is undefined. "Uninitialized" is used to
> mean "indeterminate" sometimes, apparently even in the standard.[/color]

"Apparently"? You make it sound like you know the terminology better
than the authors of the standard. Regardless, they chose to use
"initialization" to describe both syntax (direct- and
copy-initialization) and semantics (the act of giving a variable its
first value, even through assignment), and so that's what it means.

- Shane

re: class object initialisation

Shane Beasley wrote:[color=blue]
> Kevin Goodsell <usenet1.spamfree.fusion@neverbox.com> wrote in message news:<LRI8b.1863$UN4.213@newsread3.news.pas.earthl ink.net>...
>
>[color=green]
>>Using an indeterminate lvalue is undefined. "Uninitialized" is used to
>>mean "indeterminate" sometimes, apparently even in the standard.[/color]
>
>
> "Apparently"? You make it sound like you know the terminology better
> than the authors of the standard. Regardless, they chose to use
> "initialization" to describe both syntax (direct- and
> copy-initialization) and semantics (the act of giving a variable its
> first value, even through assignment), and so that's what it means.[/color]

Please show me where in the standard this definition is given.

I know what the intent of the language in the standard is. The
difference between initialization and assignment has been frequently
pointed out by people who helped write the standard, not to mention
Stroustrup himself:

http://www.research.att.com/~bs/glossary.html

So, do you know the terminology better than Bjarne Stroustrup?

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: class object initialisation

Kevin Goodsell <usenet1.spamfree.fusion@neverbox.com> wrote in message news:<dw19b.3274$BS5.2819@newsread4.news.pas.earth link.net>...
[color=blue]
> Please show me where in the standard this definition is given.[/color]

As previously quoted, 4.1/1 clearly states that an lvalue may not be
used as an rvalue unless it was previously initialized. Apparently,

int n;
n = 0;

qualifies as initialization for these purposes. But it's not done via
direct- or copy-initialization syntax in the declaration of n; rather,
it's done via an assignment expression, so called because it performs
assignment.
[color=blue]
> I know what the intent of the language in the standard is. The
> difference between initialization and assignment has been frequently
> pointed out by people who helped write the standard, not to mention
> Stroustrup himself:
>
> >
> http://www.research.att.com/~bs/glossary.html
>
> So, do you know the terminology better than Bjarne Stroustrup?[/color]

I know that PODs aren't initialized by constructor (indeed, they
needn't be initialized at all, useless as that would be). Short of
saying that he's wrong, my guess is that he's talking about non-PODs,
which accounts for most types (excluding pointers), and about which
he's entirely correct.

As for PODs, consider the following:

// Assign n to x. (That *is* what it does, no?)
template <typename T> void assign (T &x, T n) { x = n; }

int main () {
int i = 0, j;
assign(i, 0);
assign(j, 0);
i = j;
}

If you're right, then either j isn't initialized and this program is
undefined by 4.1/1, or assign(x, n) performs assignment sometimes and
initialization other times -- all with the same code. (It could also
use a better name -- assign_or_initialize, maybe.) More likely,
assign(x, n) performs assignment all the time and initialization
sometimes.

You're free to disagree, I guess. Of course, it doesn't matter what
your opinion (or mine) is; neither of us will learn anything about C++
that we didn't already know before this thread, nor do I think that
either of us will convince the other of his point. To quote somebody:

"Arguing on the Internet is like competing in the Special Olympics...
Even if you win, you're still retarded."

With that, I hereby agree to disagree and resign.

- Shane

re: class object initialisation

Shane Beasley wrote:[color=blue]
> Kevin Goodsell <usenet1.spamfree.fusion@neverbox.com> wrote in message news:<dw19b.3274$BS5.2819@newsread4.news.pas.earth link.net>...
>
>[color=green]
>>Please show me where in the standard this definition is given.[/color]
>
>
> As previously quoted, 4.1/1 clearly states that an lvalue may not be
> used as an rvalue unless it was previously initialized. Apparently,[/color]

No, it says it can't if the object to which the lvalue refers is
"uninitialized". I can't find a definition for that term in the
standard, but I think it's fairly clear that in this context they are
using it to mean "having an indeterminate value". This use of this term
here may be a defect. In my opinion, it's very clear in the standard
itself that "initialization" refers to giving a value to an object when
it is created.
[color=blue]
>
> int n;
> n = 0;
>
> qualifies as initialization for these purposes.[/color]

It qualifies as giving it a determinate value, but initialization only
occurs when an object is created.
[color=blue][color=green]
>>
>>>>
>>http://www.research.att.com/~bs/glossary.html
>>
>>So, do you know the terminology better than Bjarne Stroustrup?[/color]
>
>
> I know that PODs aren't initialized by constructor (indeed, they
> needn't be initialized at all, useless as that would be).[/color]

Stroustrup seems to be of the opinion that all types have constructors
(though the standard disagrees with him). I believe this has been
discussed here before. See, for example, page 131 of TC++PL3. I think he
was referring to all types here.
[color=blue]
> Short of
> saying that he's wrong, my guess is that he's talking about non-PODs,
> which accounts for most types (excluding pointers), and about which
> he's entirely correct.
>
> As for PODs, consider the following:
>
> // Assign n to x. (That *is* what it does, no?)
> template <typename T> void assign (T &x, T n) { x = n; }
>
> int main () {
> int i = 0, j;
> assign(i, 0);
> assign(j, 0);
> i = j;
> }
>
> If you're right, then either j isn't initialized and this program is
> undefined by 4.1/1, or assign(x, n) performs assignment sometimes and
> initialization other times -- all with the same code.[/color]

I don't see where you are getting that from. The function clearly does
an assignment. 4.1/1 deals with conversion from an lvalue to an rvalue,
which does not apply in this case. See 8.5.3/5-7:

5 A reference to type "cv1 T1" is initialized by an expression of type
"cv2 T2" as follows:

--If the initializer expression

6
--is an lvalue (but not an lvalue for a bit-field), and "cv1 T1" is
reference-compatible with "cv2 T2," or

--has a class type (i.e., T2 is a class type) and can be implicitly

converted to an lvalue of type "cv3 T3," where "cv1 T1" is refer-
ence-compatible with "cv3 T3" 9) (this conversion is selected by
enumerating the applicable conversion functions (_over.match.ref_)
and choosing the best one through overload resolution
(_over.match_)), then

7 the reference is bound directly to the initializer expression lvalue
in the first case, and the reference is bound to the lvalue result
of the conversion in the second case. In these cases the reference
is said to bind directly to the initializer expression. [Note: the
usual lvalue-to-rvalue (_conv.lval_), array-to-pointer
(_conv.array_), and function-to-pointer (_conv.func_) standard con-
versions are not needed, and therefore are suppressed, when such
direct bindings to lvalues are done. ]


Summarized, when initializing (e.g., through function argument passing)
a reference, if the initializer expression is a lvalue (clearly the case
here) that is reference-compatible with the destination reference type
(also applicable here), the reference is bound directly to the lvalue,
and the usual lvalue-to-rvalue conversion is suppressed. If you need
proof that function argument passing qualifies as initialization, please
see 8.5/1
[color=blue]
> (It could also
> use a better name -- assign_or_initialize, maybe.) More likely,
> assign(x, n) performs assignment all the time and initialization
> sometimes.
>
> You're free to disagree, I guess. Of course, it doesn't matter what
> your opinion (or mine) is; neither of us will learn anything about C++
> that we didn't already know before this thread, nor do I think that
> either of us will convince the other of his point. To quote somebody:
>
> "Arguing on the Internet is like competing in the Special Olympics...
> Even if you win, you're still retarded."[/color]

Well, for one thing neither of us is going to win. Which is pretty much
what you said above.
[color=blue]
>
> With that, I hereby agree to disagree and resign.[/color]

That's a bit premature. Here are a few more quotations to emphasize my
point (that the intent of the standard, if not the precise wording, is
that initialization occurs only at the time of creation):

8.5 Initializers [dcl.init]

1 A declarator can specify an initial value for the identifier being
declared. The identifier designates an object or reference being ini-
tialized. The process of initialization described in the remainder of
_dcl.init_ applies also to initializations specified by other syntac-
tic contexts, such as the initialization of function parameters with
argument expressions (_expr.call_) or the initialization of return
values (_stmt.return_).

The very fact that "Initializers" comes under declarations is a pretty
strong statement about where initialization occurs, I think. The
phrasing of this passage also implies that initialization is done at
object creation.


12.8 Copying class objects [class.copy]

1 A class object can be copied in two ways, by initialization
(_class.ctor_, _dcl.init_), including for function argument passing
(_expr.call_) and for function value return (_stmt.return_), and by
assignment (_expr.ass_). Conceptually, these two operations are
implemented by a copy constructor (_class.ctor_) and copy assignment
operator (_over.ass_).


This again shows the distinction between initialization and assignment
(applied only to classes in this case).

Maybe stronger proof is in there somewhere. I'm kind of tired of looking
for it, though. I'll agree that the standard appears to be not entirely
consistent on this point, but my feeling is that the intent of the
standard is to create a logical distinction between initialization
(which occurs when an object is created) and assignment (which can only
occur when the target already exists).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

re: class object initialisation

"Kevin Goodsell" <usenet1.spamfree.fusion@neverbox.com> wrote in message
news:f6P8b.2536$UN4.1551@newsread3.news.pas.earthl ink.net...[color=blue]
> A wrote:
>[color=green]
> >
> > To initialize means you give a variable it's initial value.[/color]
>
> Agreed.
>[color=green]
> > An assignment
> > operator can be used to give a variable it's initial value,[/color]
>
> No, it can't. If you believe it can, please give an example.[/color]

int i; //declared but not initialised
i =5; // variable i is initialised with value 5.
[color=blue][color=green]
> > and it can also
> > be used to re-assign a variable with a different value, providing the
> > variable is not defined as constant. The point is, you can initialise[/color][/color]
data[color=blue][color=green]
> > members via two of the following ways:[/color]
>
> Well, you can't give something its initial value twice, so I assume you
> mean "one of the following ways".[/color]

what are you smoking?
[color=blue]
> ...But you're still wrong. Assignment does not give an initial value to
> something. Assignment can only happen to an existing object. Since the
> object must exist prior to the assignment, it clearly has already
> received its initial value.[/color]

Assignment can be used for both objects types and primitive types. And i was
referring to initialising data members of a class type. Again, what are you
smoking?
[color=blue][color=green]
> > However, the behaviour of the two is different depending whether is it a
> > primitive or class type data member you want to initialize. If you don't
> > agree with my definition of assignment and initialisation then I like to
> > hear your definitions.[/color][/color]

re: class object initialisation

> > Hi,[color=blue][color=green]
> >
> > I have always been taught to use an inialization list for initialising[/color][/color]
data[color=blue][color=green]
> > members of a class. I realize that initialsizing primitives and pointers[/color][/color]
use[color=blue][color=green]
> > an inialization list is exactly the same as an assignment, but for class
> > types it has a different effect - it calls the copy constructor.
> >
> > My question is when to not use an initalisation list for initialising[/color][/color]
data[color=blue][color=green]
> > members of a class?
> >
> >
> > Regards
> > Adi[/color]
>
>
> You need to have an item in the initialize list if it's a constant or
> a reference data member.
> You also need to have the base class constructor in the initializer
> list if the base class does not have a default contructor.[/color]

If my class does not extend any class then there would be no base class your
referring to. Maybe you mean a default constructor of a class must always be
present when you use an initialisation list. Can you be more clear?


PPP

re: class object initialisation

Ying Yang wrote:[color=blue]
>[color=green]
> > A wrote:[color=darkred]
> > >
> > > Hi,
> > >
> > > I have always been taught to use an inialization list for initialising[/color][/color]
> data[color=green][color=darkred]
> > > members of a class. I realize that initialsizing primitives and pointers[/color][/color]
> use[color=green][color=darkred]
> > > an inialization list is exactly the same as an assignment, but for class
> > > types it has a different effect - it calls the copy constructor.[/color]
> >
> > No. It calls whatever constructor you specify in the initializer list.
> >[color=darkred]
> > >
> > > My question is when to not use an initalisation list for initialising[/color][/color]
> data[color=green][color=darkred]
> > > members of a class?[/color]
> >
> > Never.
> > Initialization lists are the only way to *initialize* members of a class
> > or to specify which constructor from a base class should be used.[/color]
>
> No, it's not the only way - as i mentioned you can use an assignment
> operator for initialising primitive data members, which is the same as using
> an initialization list.[/color]

But then it is no longer *initialization*.
It is assignment.

Those are different things.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

re: class object initialisation

Ying Yang wrote:[color=blue]
>
>
> int i; //declared but not initialised[/color]

wrong. initialized to an undetermined value. Initialization.
[color=blue]
> i =5; // variable i is initialised with value 5.[/color]

replacing the undetermined value with a determined value. Assignment.

Initialization happens when a variable comes to live. Note: A variable
can also be initialized to an undetermined value! Once a variable
is 'alive', you can't initialize it any more. But of course you
can assign values to it (except in some cases, eg. references).

--
Karl Heinz Buchegger
kbuchegg@gascad.at

re: class object initialisation

> Ying Yang wrote:[color=blue][color=green]
> >
> >
> > int i; //declared but not initialised[/color]
>
> wrong. initialized to an undetermined value. Initialization.[/color]

disagree.

Initialization of an object or primitive means to give a determined value to
them for the first time.

[color=blue][color=green]
> > i =5; // variable i is initialised with value 5.[/color]
>
> replacing the undetermined value with a determined value. Assignment.
>
> Initialization happens when a variable comes to live. Note: A variable
> can also be initialized to an undetermined value! Once a variable
> is 'alive', you can't initialize it any more. But of course you
> can assign values to it (except in some cases, eg. references).[/color]

In light of the above, this is no longer valid.

re: class object initialisation

Karl Heinz Buchegger wrote:[color=blue]
> Ying Yang wrote:[color=green]
>>
>>
>> int i; //declared but not initialised[/color]
>
> wrong. initialized to an undetermined value. Initialization.[/color]


Wrong. This i, if it has an automatic storage, is not initialized.
Accessing it for anything else then writing (assigment or initialization) it
(well, reading it in any way) is undefined behavior.

--
Attila aka WW

re: class object initialisation

Attila Feher wrote:[color=blue]
>
> Karl Heinz Buchegger wrote:[color=green]
> > Ying Yang wrote:[color=darkred]
> >>
> >>
> >> int i; //declared but not initialised[/color]
> >
> > wrong. initialized to an undetermined value. Initialization.[/color]
>
> Wrong.[/color]

OK.
(it was just a wild guess, apologies for that).

This i, if it has an automatic storage, is not initialized.[color=blue]
> Accessing it for anything else then writing (assigment or initialization)[/color]

If it has not been initialized, how can it be initialized later?
I thought that initialization can only occour when a variable
is created. Afterwards it is always assignment.

--
Karl Heinz Buchegger
kbuchegg@gascad.at

re: class object initialisation

On Mon, 15 Sep 2003 20:41:24 +0930, "Ying Yang" <YingYang@hotmail.com>
wrote:
[color=blue][color=green]
>> Ying Yang wrote:[color=darkred]
>> >
>> >
>> > int i; //declared but not initialised[/color]
>>
>> wrong. initialized to an undetermined value. Initialization.[/color]
>
>disagree.
>
>Initialization of an object or primitive means to give a determined value to
>them for the first time.[/color]

Your "definition" of initialization is at odds with the C++ standard:

"1 When no initializer is specified for an object of (possibly
cv*qualified) class type (or array thereof), or the
initializer has the form (), the object is initialized as specified in
8.5. [Note: if the class is a non*POD, it is
default*initialized. ]"

Here's the bit in 8.5:
"9 If no initializer is specified for an object, and the object is of
(possibly cv*qualified) non*POD class type (or array thereof), the
object shall be default*initialized; if the object is of
const*qualified type, the underlying class type shall have a
user*declared default constructor. Otherwise, if no initializer is
specified for an object, the object and its subobjects, if any, have
an indeterminate initial value;"

In other words, if you don't explicitly initialize an int (which is a
POD type), it is initialized with an indeterminate initial value.

Tom

re: class object initialisation

Karl Heinz Buchegger wrote:[color=blue]
> This i, if it has an automatic storage, is not initialized.[color=green]
>> Accessing it for anything else then writing (assigment or
>> initialization)[/color]
>
> If it has not been initialized, how can it be initialized later?
> I thought that initialization can only occour when a variable
> is created. Afterwards it is always assignment.[/color]

I was not clear. Of course it can only be assigned later on. Except of
course if someone is "clever enough" (remember! we talk about an int, POD)
and call placement new on its address. It would be an initialization,
although a pretty questionable one. :-)

--
Attila aka WW

re: class object initialisation

On 14 Sep 2003 19:07:41 -0700, sbeasley@cs.uic.edu (Shane Beasley)
wrote:
[color=blue]
>Kevin Goodsell <usenet1.spamfree.fusion@neverbox.com> wrote in message news:<dw19b.3274$BS5.2819@newsread4.news.pas.earth link.net>...
>[color=green]
>> Please show me where in the standard this definition is given.[/color]
>
>As previously quoted, 4.1/1 clearly states that an lvalue may not be
>used as an rvalue unless it was previously initialized. Apparently,
>
> int n;
> n = 0;
>
>qualifies as initialization for these purposes. But it's not done via
>direct- or copy-initialization syntax in the declaration of n; rather,
>it's done via an assignment expression, so called because it performs
>assignment.[/color]

That is a defect in the standard. It should say "indeterminate value":

http://std.dkuug.dk/jtc1/sc22/wg21/d...ctive.html#240

The intent of the standard is clear: initialization and assignment are
not ever meant to mean the same thing.

Tom

re: class object initialisation

On Mon, 15 Sep 2003 14:14:13 +0300, "Attila Feher"
<attila.feher@lmf.ericsson.se> wrote:
[color=blue]
>Karl Heinz Buchegger wrote:[color=green]
>> Ying Yang wrote:[color=darkred]
>>>
>>>
>>> int i; //declared but not initialised[/color]
>>
>> wrong. initialized to an undetermined value. Initialization.[/color]
>
>
>Wrong. This i, if it has an automatic storage, is not initialized.
>Accessing it for anything else then writing (assigment or initialization) it
>(well, reading it in any way) is undefined behavior.[/color]

The lvalue to rvalue conversion is undefined for indeterminate values
(use of the term "initialized" has been recognized as a defect in the
standard).

According to other parts of the standard (see my other posts), the
above does count as initialization to an indeterminate value.

Tom

re: class object initialisation

"Karl Heinz Buchegger" <kbuchegg@gascad.at> wrote in message
news:3F65AC45.3F1CD53D@gascad.at...[color=blue]
>
>
> Attila Feher wrote:[color=green]
> >
> > Karl Heinz Buchegger wrote:[color=darkred]
> > > Ying Yang wrote:
> > >>
> > >>
> > >> int i; //declared but not initialised
> > >
> > > wrong. initialized to an undetermined value. Initialization.[/color]
> >
> > Wrong.[/color]
>
> OK.
> (it was just a wild guess, apologies for that).
>
> This i, if it has an automatic storage, is not initialized.[color=green]
> > Accessing it for anything else then writing (assigment or[/color][/color]
initialization)[color=blue]
>
> If it has not been initialized, how can it be initialized later?
> I thought that initialization can only occour when a variable
> is created. Afterwards it is always assignment.[/color]

Would this allow for assigning a value to a const variable during
construction of the object containing the variable? (Or does it have to be
initialized in the declaration statement?)
Assigning the initial value of a variable (even const, called "final") is
allow in (for example) Java. They appear to keep track of a variable's state
as "uninitialized" and define the assigning of a value during construction
as initialization. Does C++ do this? If it did, then calling a constructor
as part of an initialization list is perfectly valid; and I think it is!
--
Gary

re: class object initialisation

On Fri, 12 Sep 2003 16:34:29 -0400, "jeffc" <nobody@nowhere.com>
wrote:
[color=blue]
>
>"Gianni Mariani" <gi2nospam@mariani.ws> wrote in message
>news:bjsqne$oou@dispatch.concentric.net...[color=green]
>> Erik wrote:
>> ...[color=darkred]
>> >>should go there. Obviously, you can't put something like this in there:
>> >>if (a)
>> >> i = 2;
>> >>else
>> >> i = 4;
>> >
>> >
>> > Many, if not most, of those cases can be covered by the ?: operator:
>> > MyClass(int a) : i(a ? 2 : 4) {}
>> >[/color]
>>
>> Yep - and sometimes it makes sense to create a function that does more
>> complex things so that everything is in the initializer list.[/color]
>
>And how exactly do you propose calling such a function from the initializer
>list?[/color]

How do you think?

MyClass(int a): i(someFunction(a))
{
}

someFunction might be a member (static or otherwise), or a namespace
scope function.

Tom

re: class object initialisation

tom_usenet wrote:[color=blue]
> specified for an object, the object and its subobjects, if any, have
> an indeterminate initial value;"
>
> In other words, if you don't explicitly initialize an int (which is a
> POD type), it is initialized with an indeterminate initial value.[/color]

No "in other words". They will have an "indeterminate initial value". They
are *not* initialized. Furthermore (let's not force me to look up the
paragraph) accessing such an uninitialized variable is undefined behavior.
(BTW it is in 4.1 paragraph 1)

--
Attila aka WW

re: class object initialisation

tom_usenet wrote:[color=blue]
> On Mon, 15 Sep 2003 14:14:13 +0300, "Attila Feher"
> <attila.feher@lmf.ericsson.se> wrote:
>[color=green]
>> Karl Heinz Buchegger wrote:[color=darkred]
>>> Ying Yang wrote:
>>>>
>>>>
>>>> int i; //declared but not initialised
>>>
>>> wrong. initialized to an undetermined value. Initialization.[/color]
>>
>>
>> Wrong. This i, if it has an automatic storage, is not initialized.
>> Accessing it for anything else then writing (assigment or
>> initialization) it (well, reading it in any way) is undefined
>> behavior.[/color]
>
> The lvalue to rvalue conversion is undefined for indeterminate values
> (use of the term "initialized" has been recognized as a defect in the
> standard).
>
> According to other parts of the standard (see my other posts), the
> above does count as initialization to an indeterminate value.[/color]

If that is what the standard is being changed to, then it is pretty silly.
Initialization is an _action_ being taken. So we say (for automatic/member
PODs): if they are are not initialized then we call this initialization
which never happened as initialization to an indetermined value. Great. It
goes to the deepness of the quantum physics. Furthermore: it has a value,
but that value cannot be read... That suggests me that it is *not*
initialized. It has an indetermined, and non-determinable value. Like the
female-mind vs. male-mind. ;-)

--
Attila aka WW

re: class object initialisation

<Shane Beasley>[color=blue]
>it doesn't matter what your opinion (or mine) is; neither of us will
>learn anything about C++ that we didn't already know before this
>thread[/color]
</>

I do learn from this thread. There are always people lurking. And,
for once, it's on topic!
[color=blue]
> "Arguing on the Internet is like competing in the Special Olympics...
> Even if you win, you're still retarded."[/color]

:-)

-X

re: class object initialisation

On Mon, 15 Sep 2003 15:29:36 +0300, "Attila Feher"
<attila.feher@lmf.ericsson.se> wrote:
[color=blue]
>tom_usenet wrote:[color=green]
>> specified for an object, the object and its subobjects, if any, have
>> an indeterminate initial value;"
>>
>> In other words, if you don't explicitly initialize an int (which is a
>> POD type), it is initialized with an indeterminate initial value.[/color]
>
>No "in other words". They will have an "indeterminate initial value". They
>are *not* initialized. Furthermore (let's not force me to look up the
>paragraph) accessing such an uninitialized variable is undefined behavior.
>(BTW it is in 4.1 paragraph 1)[/color]

You snipped these words from my post (reproduced in paraphase):

"When no initializer is specified for an object of class type the
object is initialized as specified in 8.5."

Yes, when you don't give an initializer, it is still initialized.
"Initializer" and "Initialization" are different things. Even if you
don't use an initializer, initialization still takes place.

The lvalue to rvalue thing applies to things that have been
initialized too:

int* p = new int;
delete p; //p now indeterminate (but obviously initialized)
int* q = p; //error, lvalue-to-rvalue conversion

Tom

re: class object initialisation

On Mon, 15 Sep 2003 15:35:09 +0300, "Attila Feher"
<attila.feher@lmf.ericsson.se> wrote:
[color=blue]
>If that is what the standard is being changed to, then it is pretty silly.
>Initialization is an _action_ being taken. So we say (for automatic/member
>PODs): if they are are not initialized then we call this initialization
>which never happened as initialization to an indetermined value. Great. It
>goes to the deepness of the quantum physics. Furthermore: it has a value,
>but that value cannot be read... That suggests me that it is *not*
>initialized. It has an indetermined, and non-determinable value. Like the
>female-mind vs. male-mind. ;-)[/color]

If you choose your words carefully it makes more sense: "If we don't
provide an initializer for a POD, the object is initialized to an
indeterminate value."

"initialize" and "provide an initializer for" are best thought of as
different things. initialize is something the compiler (or exe) does
to a variable. It does it whether you provide an initializer or not.

Tom

re: class object initialisation

<tom_usenet>[color=blue]
> If you choose your words carefully it makes more sense[/color]

I am not very into this business of initialization (hard to type)
and assignment, so I try to understand it in a metaphore. The
magician with the White rabbit in the hat. First, there is no hat.
It is flat, doesn't need space. Then, the magician pops up the
hat. It takes up space and provides space. But it is 'empty'.
Is it? Is there a rabbit in the hat?

1. Yes, the rabbit was nicely folded flat in the hat.
2. No, the magician is about to put the rabbit in the hat.

For assignment, putting another rabbit in the hat, we must
visualize a flapdoor at the top of the hat. Is a rabbit POD or
is that not the question?

-X

re: class object initialisation

Excuse me, I must add a third possibility (and a fourth)


I am not very into this business of initialization (hard to type)
and assignment, so I try to understand it in a metaphore. The
magician with the White Rabbit in the hat. First, there is no hat.
It is flat, doesn't need space. Then, the magician pops up the
hat. It takes up space and provides space. But it is 'empty'.
Is it? Is there a rabbit in the hat?

1. Yes, the rabbit was nicely folded flat in the hat.
2. No, the magician is about to put the rabbit in the hat.
3.. No, but the rabbit will jump in by itself
4. The Lovely Lady will put the rabbit in the hat

For assignment, putting another rabbit in the hat, we must
visualize a flapdoor at the top of the hat. Is a rabbit POD or
is that not the question?

-X

[color=blue]
>
>[/color]

re: class object initialisation

tom_usenet wrote:
[SNIP][color=blue]
> Yes, when you don't give an initializer, it is still initialized.
> "Initializer" and "Initialization" are different things. Even if you
> don't use an initializer, initialization still takes place.[/color]

Initialization is the action. An action of giving a determined value to
some object. If this is not done, well, then it is not initialized.

This is a sort of foxymoron. A smart way of telling that if I do not
initialize (give a value) to an object I still initialize (give a value) to
an object. Something is not right here. Later of course we say: well, we
have initialized the value but..., hm, khm, we still cannot use it until we
give a value to it. Something is not right. We have to be brave enough to
say: no initialization happens. The POD is not necessarily itself. That
int might not be int! How could we say: it is initialized? If the standard
says that - it is wrong. We can vote to say the Earth is flat and the fixed
center of the universe it will still not be. :-)
[color=blue]
> The lvalue to rvalue thing applies to things that have been
> initialized too:
>
> int* p = new int;
> delete p; //p now indeterminate (but obviously initialized)[/color]

Nope. It is invalid, not indetermined.
[color=blue]
> int* q = p; //error, lvalue-to-rvalue conversion[/color]

Totally different case.

And it is still moving... ;-)

--
WW aka Attila

re: class object initialisation

Gary Labowitz wrote:
[SNIP][color=blue][color=green]
>> This i, if it has an automatic storage, is not initialized.[color=darkred]
>>> Accessing it for anything else then writing (assigment or
>>> initialization)[/color]
>>
>> If it has not been initialized, how can it be initialized later?
>> I thought that initialization can only occour when a variable
>> is created. Afterwards it is always assignment.[/color]
>
> Would this allow for assigning a value to a const variable during
> construction of the object containing the variable?[/color]

Nope. My wording was not clear.
[color=blue]
> (Or does it have
> to be initialized in the declaration statement?)[/color]

It has to be initialized in an initializer list in the a class, or in case
of a static member in its definition (or inside the class if it is an
integral constant). "Normal" constant variables has to be initialized at
their definition.
[color=blue]
> Assigning the initial value of a variable (even const, called
> "final") is allow in (for example) Java.[/color]

OK. In C++ it is called initialization. A const value can only be
initialized and must be initialized. You cannot assign a new value to it
(whatever value means for it).
[color=blue]
> They appear to keep track of
> a variable's state as "uninitialized" and define the assigning of a
> value during construction as initialization. Does C++ do this?[/color]

Nope. The closest thing to this in C++ is the way static variables in a
function scope are initialized. But those are the exception, C++ does nto
keep track of initialized state - in the name of the "cause of all evil",
optimization. :-)
[color=blue]
> If it
> did, then calling a constructor as part of an initialization list is
> perfectly valid; and I think it is![/color]

Caling a constructor on the _member_ intiializer list is valid. But not for
the reasons you mention.

--
WW aka Attila

re: class object initialisation

tom_usenet wrote:
[SNIP][color=blue]
> If you choose your words carefully it makes more sense: "If we don't
> provide an initializer for a POD, the object is initialized to an
> indeterminate value."[/color]

Initialization == giving an initial value

not giving an initial value (but leave garbage there) != initialization
[color=blue]
> "initialize" and "provide an initializer for" are best thought of as
> different things. initialize is something the compiler (or exe) does
> to a variable. It does it whether you provide an initializer or not.[/color]

Yes. But the compiler (or the exe) does *nothing* to uninitialized PODs!

--
WW aka Attila

re: class object initialisation

"Ying Yang" <YingYang@hotmail.com> wrote in message news:3f65764e_1@news.iprimus.com.au...
[color=blue]
> If my class does not extend any class then there would be no base class your
> referring to. Maybe you mean a default constructor of a class must always be
> present when you use an initialisation list. Can you be more clear?[/color]

Some constructor has to be defined to use an initializer list (doesn't necessarily
have to be the default). This only makes sense simce the initialization list is
part of the constructor definition syntax.

He said IF you have a base class with no default constructor. If you derive from
the derived constructors need to provide initializers so that a valid constructor can
be invoked.

re: class object initialisation

On Mon, 15 Sep 2003 16:43:58 +0300, "White Wolf" <wolof@freemail.hu>
wrote:
[color=blue]
>tom_usenet wrote:
>[SNIP][color=green]
>> Yes, when you don't give an initializer, it is still initialized.
>> "Initializer" and "Initialization" are different things. Even if you
>> don't use an initializer, initialization still takes place.[/color]
>
>Initialization is the action.[/color]

Ok
[color=blue]
> An action of giving a determined value to
>some object.[/color]

Who says? Not the standard.

struct A
{
int i;
A(int){}
};

A a(1); // initialized? yes. determinate value? no.
[color=blue]
> If this is not done, well, then it is not initialized.[/color]

Your definition of initialized is wrong. e.g. 6.7/2
"Variables with automatic storage duration (3.7.2) are initialized
each time their declaration*statement is executed."

It doesn't say that you initialize them. It says that they are
initialized (maybe by you, maybe by the compiler, maybe by the great
goddess of undefined behaviour).
[color=blue]
>This is a sort of foxymoron. A smart way of telling that if I do not
>initialize (give a value) to an object I still initialize (give a value) to
>an object.[/color]

Why the use of "I"? The compiler can give a value to an object (aka
initialize it). This value might be indeterminate. Here is an example
of just that (from 8.5.1/8):

"An empty initializer*list can be used to initialize any aggregate. If
the aggregate is not an empty class, then each member of the aggregate
shall be initialized with a value of the form T() (5.2.3), where T
represents the type of the uninitialized member. "

Here, "initialized" means "initialized by the compiler/runtime",
whereas the "uninitialized" means "not directly initialized by an
initializer".
[color=blue][color=green]
>> The lvalue to rvalue thing applies to things that have been
>> initialized too:
>>
>> int* p = new int;
>> delete p; //p now indeterminate (but obviously initialized)[/color]
>
>Nope. It is invalid, not indetermined.[/color]

Ahh, yes, although it might be useful to allow it to fall under 4.1 by
changing the language in both places to "inderminate value" or
similar.

The standard seems to be a bit sloppy about its use of the word
"initialize" and this could probably do with clearing up...

Tom

re: class object initialisation

On Mon, 15 Sep 2003 16:51:15 +0300, "White Wolf" <wolof@freemail.hu>
wrote:
[color=blue]
>tom_usenet wrote:
>[SNIP][color=green]
>> If you choose your words carefully it makes more sense: "If we don't
>> provide an initializer for a POD, the object is initialized to an
>> indeterminate value."[/color]
>
>Initialization == giving an initial value[/color]

Indeed, however this doesn't have to involve an initializer.
[color=blue]
>not giving an initial value (but leave garbage there) != initialization[/color]

Nope, the compiler gives an initial value to PODs if you don't bother.
This is also initialization.
[color=blue]
>[color=green]
>> "initialize" and "provide an initializer for" are best thought of as
>> different things. initialize is something the compiler (or exe) does
>> to a variable. It does it whether you provide an initializer or not.[/color]
>
>Yes. But the compiler (or the exe) does *nothing* to uninitialized PODs![/color]

Are you saying that the bytes making up the value representation of a
POD have to be changed for initialization to have occurred? I don't
think the standard backs you on this!

Tom

re: class object initialisation

"foo" <maisonave@axter.com> wrote in message
news:c11783b0.0309131929.a7b14fe@posting.google.co m...[color=blue]
> "jeffc" <nobody@nowhere.com> wrote in message[/color]
news:<3f622fa7_4@news1.prserv.net>...[color=blue][color=green]
> > "Erik" <no@spam.com> wrote in message news:bjspcn$r22$1@news.lth.se...[color=darkred]
> > > > The basic rule of thumb is that anything that can go in the[/color][/color][/color]
initialize[color=blue][color=green]
> > list[color=darkred]
> > > > should go there. Obviously, you can't put something like this in[/color][/color][/color]
there:[color=blue][color=green][color=darkred]
> > > > if (a)
> > > > i = 2;
> > > > else
> > > > i = 4;
> > >
> > > Many, if not most, of those cases can be covered by the ?: operator:
> > > MyClass(int a) : i(a ? 2 : 4) {}[/color]
> >
> > Yeah, maybe simple "if" cases like that, but you can't put logic or[/color][/color]
function[color=blue][color=green]
> > calls (other than base class constructors) in the initializer list. You
> > added an expression, not a statement.[/color]
> There are plenty of things you can put in the initializer list.
> You can put functions, additions, conditon logic, and more.[/color]

And there are plenty of things you can't. You can put expressions in there,
but you can't put statements in there. You can't call functions (alone),
you can't use for or while loops, you can't... well, you already know what
you can't do.

re: class object initialisation

"Ron Natalie" <ron@sensor.com> wrote in message
news:3f622fa9$0$51871$9a6e19ea@news.newshosting.co m...[color=blue]
>
> "jeffc" <nobody@nowhere.com> wrote in message[/color]
news:3f622ea6_1@news1.prserv.net...[color=blue][color=green]
> >[/color]
>[color=green][color=darkred]
> > > Yep - and sometimes it makes sense to create a function that does more
> > > complex things so that everything is in the initializer list.[/color]
> >
> > And how exactly do you propose calling such a function from the[/color][/color]
initializer[color=blue][color=green]
> > list?[/color]
>
> Same way you call any other function.[/color]

Yeah, right.

re: class object initialisation

"Ron Natalie" <ron@sensor.com> wrote in message
news:3f62303f$0$51808$9a6e19ea@news.newshosting.co m...[color=blue]
>
> "jeffc" <nobody@nowhere.com> wrote in message[/color]
news:3f622fa7_4@news1.prserv.net...[color=blue]
>[color=green][color=darkred]
> > > Many, if not most, of those cases can be covered by the ?: operator:
> > > MyClass(int a) : i(a ? 2 : 4) {}[/color]
> >
> > Yeah, maybe simple "if" cases like that, but you can't put logic or[/color][/color]
function[color=blue][color=green]
> > calls (other than base class constructors) in the initializer list. You
> > added an expression, not a statement.[/color]
>
> Who says you can't have function calls?[/color]

You can only have function calls as part of expressions, not statements.
You can't simply call a function such as initialize() as Gianni suggested
(as you well know.)

re: class object initialisation

On Mon, 15 Sep 2003 11:29:54 -0400, "jeffc" <nobody@nowhere.com>
wrote:
[color=blue]
>
>"Ron Natalie" <ron@sensor.com> wrote in message
>news:3f62303f$0$51808$9a6e19ea@news.newshosting.c om...[color=green]
>>
>> "jeffc" <nobody@nowhere.com> wrote in message[/color]
>news:3f622fa7_4@news1.prserv.net...[color=green]
>>[color=darkred]
>> > > Many, if not most, of those cases can be covered by the ?: operator:
>> > > MyClass(int a) : i(a ? 2 : 4) {}
>> >
>> > Yeah, maybe simple "if" cases like that, but you can't put logic or[/color][/color]
>function[color=green][color=darkred]
>> > calls (other than base class constructors) in the initializer list. You
>> > added an expression, not a statement.[/color]
>>
>> Who says you can't have function calls?[/color]
>
>You can only have function calls as part of expressions, not statements.
>You can't simply call a function such as initialize() as Gianni suggested
>(as you well know.)[/color]

I think you completely misunderstood him:

struct A
{
int a;
static int doCalc(int val);
A(int val): a(doCalc(val))
{
}
};

That was exactly the kind of thing that Gianni was suggesting - if you
can't put the logic inline, make a function for it. If your member is
const or a reference, you have no choice but to do so.

Tom