Re: [avr-gcc-list] avr-g++ local variable constructor / block body / destructor execution order

[Oleksandr Redchuk]

2007/9/2, David Brown <address@hidden>:

> Similarly, if you have multiple objects being constructed or
> destructed, their ordering is *not* guaranteed by the compiler
AFAIR, this order guaranteed for objects in block of code and for
objects in file - in order of definitions, but not guaranteed for
objects in different files because of dependence form object files
linking order.
In any case this is not a question of constructor/destructor order or
even it's presence:
class iii {
public:
        iii(int _i) : i(_i) {}
        ~iii() {}
        operator int() { return i; }
private:
        int i;
};

int foo(int i) {
        iii a(5);
        return a + i;
}

a even not be created, and this is good optimizer behavior :-)

> are guaranteed is that the code will act as though they followed the
> order given, based on what the compiler knows of the code.

I'm shure that compiler can change execution sequence of independent
lines of code and can't change that sequence for volatile objects
access.
But I'm not shure, that it can change order of non-volatile and
volatile objects access.
avr-gcc optimizer behavior looks reasonable, but is the C++ standard
grant this changing? I not found such grants in standard text...


> inline uint32_t get_counter() {
>         crit_sect cs;
>         uint32_t x = counter;
>         asm volatile("" : : : "memory");
>         return x;
> }
Thanks.
Yes, I think, that qualifying counter as volatile is the best solution
- it is really modifiable in interrupt :-)
But in real world get_counter() is part of "external" code wich I
don't want to change. However, crit_sect definition is a part of
"target-specific" include-file for the "external code" and I add asm
volatile("" : : : "memory"); to constructor and destructor of
crit_sect.

-- 
wbr,
ReAl