Avoid wasting time or how to avoid initialization

  • Thread starter Alexander Malkis
  • Start date
A

Alexander Malkis

A real-life example:

int alpha_beta(unsigned depth,Position p, Move& m /*,other args*/) {
//...do smth with p
if(depth) {
Move m;
int val=alpha_beta(depth-1,p,m /*,other args*/);
}
//...
//sometimes change m, e.g.:
if(depth==global_depth) m=best_move;
//...return...
}

The problem here is that the (perhaps, default) constructor for m is
called. It may do as little as he wish, but nevertheless he inits all
the members of Move. It's time-consuming. But we don't need initializing
at all, since the "Move m" declaration is needed only to let the
recursively called fucntion sometimes change m.

In C, if M were a struct, no init were performed and we had no problem.
But what to do in C++ without too much hack?
 
J

John Harrison

Alexander Malkis said:
A real-life example:

int alpha_beta(unsigned depth,Position p, Move& m /*,other args*/) {
//...do smth with p
if(depth) {
Move m;
int val=alpha_beta(depth-1,p,m /*,other args*/);
}
//...
//sometimes change m, e.g.:
if(depth==global_depth) m=best_move;
//...return...
}

The problem here is that the (perhaps, default) constructor for m is
called. It may do as little as he wish, but nevertheless he inits all
the members of Move. It's time-consuming. But we don't need initializing
at all, since the "Move m" declaration is needed only to let the
recursively called fucntion sometimes change m.

In C, if M were a struct, no init were performed and we had no problem.
But what to do in C++ without too much hack?

What's in Move?

If Move is a POD type (the only type you are allowed in C) then
initialisation will not happen in C++ either. Something like this

struct Move
{
char from_square;
char to_square;
char captured_piece;
char promoted_piece;
};

isn't going to get initialised in either C or C++.

john
 
L

Leor Zolman

A real-life example:

int alpha_beta(unsigned depth,Position p, Move& m /*,other args*/) {
//...do smth with p
if(depth) {
Move m;
int val=alpha_beta(depth-1,p,m /*,other args*/);
}
//...
//sometimes change m, e.g.:
if(depth==global_depth) m=best_move;
//...return...
}

The problem here is that the (perhaps, default) constructor for m is
called. It may do as little as he wish, but nevertheless he inits all
the members of Move. It's time-consuming. But we don't need initializing
at all, since the "Move m" declaration is needed only to let the
recursively called fucntion sometimes change m.

In C, if M were a struct, no init were performed and we had no problem.
But what to do in C++ without too much hack?

If, in C, there were "no init" performed, you'd have garbage in the struct.

What does Move look like? Is it a POD (plain old data) type? If so, and
you don't care whether the POD data members get initialized or not
(presumably there's something in the logic of your code that would know not
to actually look into the object in that case, since you're saying that was
the case in C), then the constructor, such as it is, would be "trivial" and
optimized away to nothing.

If, on the other hand, Move is not POD and there needs to be a constructor,
then you're doing something differently than you did in C anyway, and you
probably wouldn't /want/ the initialization skipped...
-leor
 
B

bartek

A real-life example:

int alpha_beta(unsigned depth,Position p, Move& m /*,other args*/) {
//...do smth with p
if(depth) {
Move m;
int val=alpha_beta(depth-1,p,m /*,other args*/);
}
//...
//sometimes change m, e.g.:
if(depth==global_depth) m=best_move;
//...return...
}

The problem here is that the (perhaps, default) constructor for m is
called. It may do as little as he wish, but nevertheless he inits all
the members of Move. It's time-consuming. But we don't need initializing
at all, since the "Move m" declaration is needed only to let the
recursively called fucntion sometimes change m.

In C, if M were a struct, no init were performed and we had no problem.
But what to do in C++ without too much hack?

I don't quite understand the rationale... Is the 'Move& m' meant as an
output argument?

Anyway... why don't you use a pointer to Move then? (or better ... a
smart pointer?) You could then construct an instance at the point it's a
ctually needed.

Cheers!
 
A

Alexander Malkis

//Here is the Move. It's not chess,
//but an edge-moving game which is a bit complex here to explain.
//Edge is also a class.

class Move {
public:
Edge from, to; //where do we take an edge and where do we place it
//constructor
Move(Edge from_e, Edge to_e): from(from_e), to(to_e) { }
//default-constructor
Move() { }
class ErrorBadInput { }; //the caller has to eat the input itself
friend std::eek:stream& operator<<(std::eek:stream&, const Move&); //output
friend std::istream& operator>>(std::istream&, Move&); //input
};

/* So as far as I understood, changing it to struct would suffice. The
problem is that the other (nondefault) constructor should be removed
also. It works but is not quite what I want, since the class is going to
grow and will sooner or later need some more member functions.

In my example, I really want to avoid initialization in this case and
"garbage" in m is ok:
*/
//...
if(depth) {
Move m;
int val=alpha_beta(depth-1,p,m /*,other args*/);
}
//...
/* The idea of a pointer gets quite messy, since the Move object would
be destroyed not in the call of alpha_beta that has created it, in
general not in alpha_beta at all. And the additional logic has to be
implemented to tell when to delete an m and when not, which has nothing
to do with algorithm itself.
*/
int alpha_beta(..., Move* &m) {
....
Move *m;
int val=alpha_beta(depth-1,p,m /*,other args*/);
if(m)...
else ...
....
if(...) m=new Move(...); else m=NULL;
}
/*
The smart pointer implies (as far I understand these) an time-overhead.
*/
 
J

John Harrison

Alexander Malkis said:
//Here is the Move. It's not chess,
//but an edge-moving game which is a bit complex here to explain.
//Edge is also a class.

class Move {
public:
Edge from, to; //where do we take an edge and where do we place it
//constructor
Move(Edge from_e, Edge to_e): from(from_e), to(to_e) { }
//default-constructor
Move() { }
class ErrorBadInput { }; //the caller has to eat the input itself
friend std::eek:stream& operator<<(std::eek:stream&, const Move&); //output
friend std::istream& operator>>(std::istream&, Move&); //input
};

/* So as far as I understood, changing it to struct would suffice. The
problem is that the other (nondefault) constructor should be removed
also. It works but is not quite what I want, since the class is going to
grow and will sooner or later need some more member functions.

Struct make no difference at all.

Give Edge a similar constructor to Move and I would expect a compiler to be
smart enough to optimise away both constructor calls.

john
 
T

tom_usenet

A real-life example:

int alpha_beta(unsigned depth,Position p, Move& m /*,other args*/) {
//...do smth with p
if(depth) {
Move m;
int val=alpha_beta(depth-1,p,m /*,other args*/);
}

I assume you can't just do:

if(depth) {
int val=alpha_beta(depth-1,p,m /*,other args*/);
}

i.e. just pass on the move from the level above? That would solve the
problem...

Tom
 
H

Howard

I assume you can't just do:

if(depth) {
int val=alpha_beta(depth-1,p,m /*,other args*/);
}

i.e. just pass on the move from the level above? That would solve the
problem...

That's what I thought you'd want, too. I'm confused by your declaring a
local m when one of the parameters is also named m. That's an indicator of
something wrong, usually.

-Howard
 
A

Alexander Malkis

tom_usenet said:
I assume you can't just do:

if(depth) {
int val=alpha_beta(depth-1,p,m /*,other args*/);
}

i.e. just pass on the move from the level above? That would solve the
problem...

Tom
Good idea. This would change the other code parts a bit, but it seems to
be fine enough for spped.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top