what can be optimized?

[Grizlyk]

Hello.

What can be optimised in C++ code and how i can garantee stable
behaviour below

1.
Are expression "auto volatile" can deny removing as "unused temporary"
like this:

auto volatile const class_name tmp;

If not, how can i do it else?

2.
Can C++ garantee, that unnamed temporary object will not be removed as
"unused temporary" here:

class A{ A(){cout<<"star t..."; } }
class B{ B(){cout<<"ok"< <endl; } }

void inp();
void test(){ A(); inp(); B(); }

[peter koch]

On Jan 24, 11:50 am, "Grizlyk" <grizl...@yande x.ruwrote:

Hello.

What can be optimised in C++ code and how i can garantee stable
behaviour below

Anything might be optimised as long as visible behaviour is not
affected. Visible behaviour is anything output by the program, but not
e.g. how long time something takes.

>
1.
Are expression "auto volatile" can deny removing as "unused temporary"
like this:

auto volatile const class_name tmp;

No.

>
If not, how can i do it else?

What is your problem? Optimisation should not cause problems (unless
the optimised code is wrong, of course).

>
2.
Can C++ garantee, that unnamed temporary object will not be removed as
"unused temporary" here:

Yes. Anything that has a side-effect will normally not be optimised
away. Also, removal of your temporary objects below would change output
which is visible behaviour.

>
class A{ A(){cout<<"star t..."; } }
class B{ B(){cout<<"ok"< <endl; } }

void inp();
void test(){ A(); inp(); B(); }

/Peter

[Grizlyk]

"peter koch" wrote:

What can be optimised in C++ code and how i can garantee
stable behaviour below

Anything might be optimised as long as visible behaviour is not
affected.

I said, that compiler and programmer can think about "visible
behaviour" differently. Compiler for example, often eliminate
"unusable" code if compiler think code is not used.

1.
Are expression "auto volatile" can deny removing as "unused temporary"
like this:

auto volatile const class_name tmp;No.

What is your problem?

In the case of temporary object compiler could remove object to the
point, where object will be used, for example:

{
int tmp=0;

if(!is_ready)re turn tmp;
return 1;
}

can be optimized to

{
if(!is_ready){ int tmp=0; return tmp; }
return 1;
}

Can "auto volatile" force object to be placed into stack, not into CPU
registers?

2.
Can C++ garantee, that unnamed temporary object will not be
removed as "unused temporary" here:

In the case of temporary object

class A;
class B;
void test(){ A(); inp(); B(); }

compiler could eliminate objects, that created but after that never
used:

void test(){ inp(); }

because A(); and B(); are never used unnamed objects.

[Rolf Magnus]

Grizlyk wrote:

"peter koch" wrote:

>
What can be optimised in C++ code and how i can garantee
stable behaviour below

Anything might be optimised as long as visible behaviour is not
affected.

I said, that compiler and programmer can think about "visible
behaviour" differently. Compiler for example, often eliminate
"unusable" code if compiler think code is not used.

The compiler doesn't just do random guesses about what isn't needed. It
usually removes code that actually isn't used, even if you might think it
is. There are some special circumstances in low-level programming (direct
interaction with hardware, operating system kernels and such) where more
control is needed. That's what volatile is there for.

1.
Are expression "auto volatile" can deny removing as "unused temporary"
like this:

auto volatile const class_name tmp;No.

What is your problem?

In the case of temporary object compiler could remove object to the
point, where object will be used, for example:

{
int tmp=0;

if(!is_ready)re turn tmp;
return 1;
}

can be optimized to

{
if(!is_ready){ int tmp=0; return tmp; }
return 1;
}

It can even optimize it to:

{
if(!is_ready){ return 0; }
return 1;
}
Or it might even do:

{
return is_ready != 0;
}

But why would that be a problem?

Can "auto volatile" force object to be placed into stack, not into CPU
registers?

On some compilers, it does, but I'm not sure if that's required by the
standard.

2.
Can C++ garantee, that unnamed temporary object will not be
removed as "unused temporary" here:

In the case of temporary object

class A;
class B;
void test(){ A(); inp(); B(); }

compiler could eliminate objects, that created but after that never
used:

void test(){ inp(); }

because A(); and B(); are never used unnamed objects.

The compiler might optimize those objects away only if their construction
and destruction are guaranteed to have no side effects, i.e. if you
wouldn't notice it anyway.

[Grizlyk]

Rolf Magnus wrote:

1.
Are expression "auto volatile" can deny removing as "unused temporary"
like this:

auto volatile const class_name tmp;No.
What is your problem?

In the case of temporary object compiler could remove object to the
point, where object will be used, for example:

{
int tmp=0;

if(!is_ready)re turn tmp;
return 1;
}

can be optimized to

{
if(!is_ready){ int tmp=0; return tmp; }
return 1;
}It can even optimize it to:

But why would that be a problem?

Instead of "int tmp" can be "myclass tmp", so non-trivial ctor exist,
and I want to be shure, that myclass::myclas s() ctor will be
unconditional executed. And I do not want rewite class's ctors into
static function calls.

2.
Can C++ garantee, that unnamed temporary object will not be
removed as "unused temporary" here:

In the case of temporary object

class A;
class B;
void test(){ A(); inp(); B(); }

compiler could eliminate objects, that created but after that never
used:

void test(){ inp(); }

because A(); and B(); are never used unnamed objects.

The compiler might optimize those objects away only if their construction
and destruction are guaranteed to have no side effects, i.e. if you
wouldn't notice it anyway.

What means "to have no side effects"? The fact that A() and B() have
non-trivial ctors is side effect or not? Or it is incorrect to call
obects ctors or I must explicit write A::A() or B::B(). What standard
require?

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

On Jan 24, 3:46 pm, "Grizlyk" <grizl...@yande x.ruwrote:

Rolf Magnus wrote:

The compiler might optimize those objects away only if their construction
and destruction are guaranteed to have no side effects, i.e. if you
wouldn't notice it anyway.

What means "to have no side effects"? The fact that A() and B() have
non-trivial ctors is side effect or not? Or it is incorrect to call
obects ctors or I must explicit write A::A() or B::B(). What standard
require?

A side effect is when something that happens besides the fact that (in
this instance) an object is created. Consider the following:

class Foo {
Foo(int& i) { ++i; }
}

If we create a temporary with this object and pass an integer as a
parameter the ctor will increment the supplied integer, this is a
side-effect. This means that the compiler can not optimize away the
creation of the object since it would also affect the value of the
integer passed (unless the integer can also be optimized away.

If you instead have the following class:

class Bar {
Bar(int i) { ++i; } // Notice no &
}

The compiler can optimize away the construction of the object since
nothing but the objects existence depends on it.

--
Erik Wikström

[Kai-Uwe Bux]

Grizlyk wrote:

Rolf Magnus wrote:

1.
Are expression "auto volatile" can deny removing as "unused
temporary" like this:

auto volatile const class_name tmp;No.
What is your problem?

In the case of temporary object compiler could remove object to the
point, where object will be used, for example:

{
int tmp=0;

if(!is_ready)re turn tmp;
return 1;
}

can be optimized to

{
if(!is_ready){ int tmp=0; return tmp; }
return 1;
}It can even optimize it to:

But why would that be a problem?

Instead of "int tmp" can be "myclass tmp", so non-trivial ctor exist,
and I want to be shure, that myclass::myclas s() ctor will be
unconditional executed. And I do not want rewite class's ctors into
static function calls.

Don't worry: in cases like this, the constructors will be called unless they
do not add to the observable behavior. In other words, constructor calls
can be optimized away only if the static function calls that you would use
in their place could be optimized away, too.

2.
Can C++ garantee, that unnamed temporary object will not be
removed as "unused temporary" here:

In the case of temporary object

class A;
class B;
void test(){ A(); inp(); B(); }

compiler could eliminate objects, that created but after that never
used:

void test(){ inp(); }

because A(); and B(); are never used unnamed objects.

The compiler might optimize those objects away only if their construction
and destruction are guaranteed to have no side effects, i.e. if you
wouldn't notice it anyway.

What means "to have no side effects"? The fact that A() and B() have
non-trivial ctors is side effect or not? Or it is incorrect to call
obects ctors or I must explicit write A::A() or B::B().

No, you don't. You can call the constructor just fine by writing A(). More
precisely, upon evaluation of this expression, a temporary is created and
constructed by calling the default constructor.

Now, as far as optimization is concerned, the following might happen:

struct A {

char arr [200];

A () {
std::cout << "hello world!\n";
}

};

// ...

int main () {
A(); //(*)
}

The standard requires that line (*) prints "hello world!". However, the
compiler is allowed to observe that there is no need to allocate 200 bytes
on the stack. Thus, machine instructions to that extend maybe eliminated.
I.e., in fact the compiler may actually not create an object (region of
memory) but just inline the body of the constructor. The reason is that the
observable behavior does not differ either way.
Best

Kai-Uwe Bux

[Grizlyk]

Kai-Uwe Bux wrote:

Or it is incorrect to call objects ctors
or I must explicit write A::A() or B::B()?

No, you don't. You can call the constructor just fine by writing A(). More
precisely, upon evaluation of this expression, a temporary is created and
constructed by calling the default constructor.

Well, and is it a good (known) C++ idiom to do the temporary object, to
use ctor of object as ordinary function call or not good?

The goal to use unnnamed ctor calling:

1. old code use X() as object, and I do not want to rewrite ctors into
static functions or class into namespace. It seems to me, that easyer
to change ctors implementations .

2. class members of the object, used by ctor can be created
unconcditionall y

class X
{
public:
A a; //a created independed from if( !is_ok() ) or not?
X(){ if( !is_ok() )throw a; }
};

If compare 2 with next example

void test()
{
A a;
if( !is_ok() )throw a;
}

If A has ctor, must "A::A()" be called befor "is_ok()" in both cases or
in the case of class member only? Does concrete sequence exist between
functions calls?

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-01-24 17:23, Grizlyk wrote:

2. class members of the object, used by ctor can be created
unconcditionall y

class X
{
public:
A a; //a created independed from if( !is_ok() ) or not?
X(){ if( !is_ok() )throw a; }
};

Yes, A's ctor will be called before X's ctor. These kinds of things are
easy to examine by creating small classes that prints some text in the
ctor (and perhaps dtor).

If compare 2 with next example

void test()
{
A a;
if( !is_ok() )throw a;
}

If A has ctor, must "A::A()" be called befor "is_ok()" in both cases or
in the case of class member only?

I assume you meant function-call only, since it's obvious that A's ctor
have to be called in test(). But to answer your question, yes A's ctor
will be called in both cases.

Does concrete sequence exist between functions calls?

Do you mean if there is a defined sequence in which the ctors of
member-objects will be called? If you have a class like this:

class X {
A a;
B b;
C c;
// ...
}

Then the ctors of the members will be declared in the order they were
declared, that's why you have to take some care when using initialization.

X::X(int a_, int b_)
: b(b_), a(b + a_) // OOPS!
{ }
In the above constructor to X the initialization of the members (ctor-
calls) will be in the order they were declared, so the initialization of
'a' witch 'b + a_' is no good since 'b' has not been initialized yet.

--
Erik Wikström

[Grizlyk]

Erik Wikström wrote:

Does concrete sequence exist between functions calls?

Do you mean if there is a defined sequence in which the ctors of
member-objects will be called?

No. In the case ctor A() used (logically) as ordinary function call.
Does concrete sequence (fixed order) exist between ordinary functions
calls?

Can the example below

a();
if( !is_ok() )b();

be switched by compiler to

if( !is_ok() ){ a(); b();}

I think that compiler can not switch "a()" and "is_ok()" calls, and
probably if a() is ctor (a()==A::A()) can not also.