is it a good idea to assign object to pointer without initialising it to NULL.

[nrhayyal]

hi all,
is it a good idea to assign object to pointers without initialising it
to NULL?
suppose if i have a class TEST

class ELEMENT
{
private:
int a;
string s1;
public:
func(a);
AddChild()
{
cout<<"some value";
}
};

i have object of TEST as shown below:
ELEMENT *inventors=bibl io->AddChild("Invs ");
ELEMENT *t2;
is it better to initialize while declaring itself?
i mean,if i say :

ELEMENT *t2= inventors->AddChild("Inv" );// is this safe enough?

or do i need to go with usual conventions like:
ELEMENT *t2=NULL;
t2= inventors->AddChild("Inv" );

so please help me which one is better and safe?

if not please explain me what could go wrong with

ELEMENT *t2= inventors->AddChild("Inv" );

thanks & regards
Nagaraj Hayyal

[Karl Heinz Buchegger]

nrhayyal wrote:

i have object of TEST as shown below:
ELEMENT *inventors=bibl io->AddChild("Invs ");
ELEMENT *t2;
is it better to initialize while declaring itself?
i mean,if i say :

ELEMENT *t2= inventors->AddChild("Inv" );// is this safe enough?

or do i need to go with usual conventions like:
ELEMENT *t2=NULL;
t2= inventors->AddChild("Inv" );

so please help me which one is better and safe?

There is no difference at all.
It all depends on the return value of AddChild if the pointer
is valid or not. In both cases.

'Prefer initialization above assignment'

--
Karl Heinz Buchegger
kb******@gascad .at

[nrhayyal]

thanks for ur reply Karl ,
is there any reason for 'Preferring initialization above assignment'.?
just curious to know about it.

[Karl Heinz Buchegger]

nrhayyal wrote:

thanks for ur reply Karl ,
is there any reason for 'Preferring initialization above assignment'.?
just curious to know about it.

In the worst case there is no difference between initialization and assignment.
Example:

int j = 5;

------

int j;
j = 5;

I would expect both codes to produce identical code.

But: There may be a difference if the variable you define is of
some class type:

std::string Name( "Compiler" );

------

std::string Name;
Name = "Compiler";

Those 2 code snippets do different things. The first snippet uses
a special constructor to create the Name object with a specific value.
The second code snippet however, creates the Name object and initialises
it to an empty string. The following assignment then discards that empty
string and assigns it a new value.
So while in the first case, the whole process is a one-step procedure (create
object with a specific value) it becomes a two-step procedure in the second
case (create empty object, alter empty object).

And then there is of course the case, where assignment simply doesn't work, eg.
because the 'variable' you define is a constant. A constant can only be initialized
but not assigned, hence initialization is the only thing that will work:

const int j = 5; // works

-------

const int j;
j = 5; // does not work. j is const, hence the compiler hinders you
// to change its value.

So all in all: There is no advantage in assignment in all those cases, so why use it?
Get used to use initialization and you have less problems in the long run.

--
Karl Heinz Buchegger
kb******@gascad .at

[Bangalore]

> nrhayyalwrote:

i have object of TEST as shown below:
ELEMENT *inventors=bibl io->AddChild("Invs ");
ELEMENT *t2;
is it better to initialize while declaring itself?
i mean,if i say :

ELEMENT *t2= inventors->AddChild("Inv" );// is this safe enough?
What is biblio, is it a object? If it's ,you are doing wrong,
First you have to new up the object, then you can call
any function with in that class, using pointer,
Eg:
ELEMENT *inventors=new ELEMENT();
inventors->AddChild("Inv" );

Thanks,
Bangalore

[Dave Rahardja]

On Wed, 21 Sep 2005 10:47:55 +0200, Karl Heinz Buchegger <kb******@gasca d.at>
wrote:

So all in all: There is no advantage in assignment in all those cases, so why use it?
Get used to use initialization and you have less problems in the long run.

Right. Also:

class A
{
public:
A(int) {} // Constructor taking an int
A(const A&) {} // Copy constructor
};

int main()
{
A a0(1);
A a1 = 2;
return 0;
}
When instantiating a0, the constructor taking an int is used in all cases.

When initializing a1, however, the semantic is A(A(2)), which technically
constructs a temporary object using the construtor taking an int, then passing
it to the copy constructor of a1.

-dr

[Bogdan Sintoma]

Dave Rahardja wrote:

On Wed, 21 Sep 2005 10:47:55 +0200, Karl Heinz Buchegger <kb******@gasca d.at>
wrote:

So all in all: There is no advantage in assignment in all those cases, so why use it?
Get used to use initialization and you have less problems in the long run.

Right. Also:

class A
{
public:
A(int) {} // Constructor taking an int
A(const A&) {} // Copy constructor
};

int main()
{
A a0(1);
A a1 = 2;
return 0;
}
When instantiating a0, the constructor taking an int is used in all cases.

When initializing a1, however, the semantic is A(A(2)), which technically
constructs a temporary object using the construtor taking an int, then passing
it to the copy constructor of a1.

Hi,

Are you sure about that? Please, just test your example.

Best regards,
Bogdan Sintoma

[Karl Heinz Buchegger]

Bogdan Sintoma wrote:

Dave Rahardja wrote:

Right. Also:

class A
{
public:
A(int) {} // Constructor taking an int
A(const A&) {} // Copy constructor
};

int main()
{
A a0(1);
A a1 = 2;
return 0;
}
When instantiating a0, the constructor taking an int is used in all cases.

When initializing a1, however, the semantic is A(A(2)), which technically
constructs a temporary object using the construtor taking an int, then passing
it to the copy constructor of a1.

Hi,

Are you sure about that? Please, just test your example.

Yes, he sure about that. And yes, he is right.
Your tests may show a difference, since the compiler is allowed to
optimize that temporary away. Nevertheless the semantics is indeed A(A(2))
which can easily be seen by making the copy constructor unaccessible. In this
case the compiler must refuse to compile this code, since it cannot use the
copy constructor (even if that copy constructor gets optimized away).

--
Karl Heinz Buchegger
kb******@gascad .at

[Bogdan Sintoma]

Karl Heinz Buchegger wrote:

Bogdan Sintoma wrote:

Dave Rahardja wrote:

Right. Also:

class A
{
public:
A(int) {} // Constructor taking an int
A(const A&) {} // Copy constructor
};

int main()
{
A a0(1);
A a1 = 2;
return 0;
}
When instantiating a0, the constructor taking an int is used in all cases.

When initializing a1, however, the semantic is A(A(2)), which technically
constructs a temporary object using the construtor taking an int, then passing
it to the copy constructor of a1.

Hi,

Are you sure about that? Please, just test your example.

Yes, he sure about that. And yes, he is right.
Your tests may show a difference, since the compiler is allowed to
optimize that temporary away. Nevertheless the semantics is indeed A(A(2))
which can easily be seen by making the copy constructor unaccessible. In this
case the compiler must refuse to compile this code, since it cannot use the
copy constructor (even if that copy constructor gets optimized away).

--

And yes, you are right. My mistake.

Best regards,
Bogdan Sintoma