An interesting question that I AM NOT CONVICED it's so !

[gilesgoat]

So ..

My brother "wants to do a class with a sequential auto incrementing index" ..

IN SHORT ( because it's already well explained in there ) look a this post/answer :

https://stackoverflow.com/questions/741 ... 0_74181334

But just to re-explain let's say he as a class :

Code: Select all

class Id
{
    public:
        Id()
        {
            id = unique_id++;
        }

    int get_id()
    {
        return id;
    }

    private:
        int id;
        static int unique_id;
}

Initialize static member in the source file :

static int Id::unique_id = 0;

Create objects :

Id id1;        // id1.get_id() will return 1
Id id2;        // id2.get_id() will return 2
Id id3;        // id3.get_id() will return 3

Now ESPECIALLY THIS PART :

Code: Select all

Create objects :

Id id1;        // id1.get_id() will return 1
Id id2;        // id2.get_id() will return 2
Id id3;        // id3.get_id() will return 3

Or I'd say "even worse" if you do ( or is it the same ? )

Code: Select all

Create objects :

Id id1,id2,id3;        

I *ALWAYS* "been told" that NOTHING IN THE UNIVERSE will GUARANTEE ANY particular intialisation order and you should NEVER rely on stuff like this !

I mean that thing "only guarantees that all indexes will be different" but you can never tell "which one is the first and which one is the last" as
the compiler could create id3,id2,id1 and/or any order that could be.

Or "have I been told wrong ?" ..

To me, as I know things, I *THINK* ( and even here I am not 100% sure ) that the ONLY way "to force an order" would be to do :

Code: Select all

Create objects :

Id *id1 = new Id;
Id *id2 = new Id;
Id *id3 = new Id;

And that should guarantee they are created in that order .. but what about "Out of order execution" ? .. Still the compiler "seeing that there are no dependecies/side effects" could re-order even those instructions ? Or no becuase "new" is a "function call" ?

I read somewhere about "Windows Smart Pointers" they seems someway "guaranteed" to be created in an order and destoryed in reverse order but I think that's an MS only thing ?

I don't know I am NOT so convinced of that StackOverflow reply.

Anyone knows better ?

[_TinOmen_]

I'd say that the class constructor is like a function call and for that reason the optimizer is not allowed to reorder them. So no matter how you declare them they would be initialized in order.

But I'd not be surprised if there is some C++ language rule that proves me wrong.

[gilesgoat]

I'd say that the class constructor is like a function call and for that reason the optimizer is not allowed to reorder them. So no matter how you declare them they would be initialized in order.

But I'd not be surprised if there is some C++ language rule that proves me wrong.

The problem is "can you be ALWAYS 100% sure of that ?" I'd say "I don't think so".

[gravy]

I'd say that the class constructor is like a function call and for that reason the optimizer is not allowed to reorder them. So no matter how you declare them they would be initialized in order.

But I'd not be surprised if there is some C++ language rule that proves me wrong.

There's no guarantee of initialisation order at global scope in the spec IIRC. If it works it's not a guarantee it'll work at a later date or on a different compiler

In function it'd be okay

[venusian]

Static initialization order is one of the things that is famously undefined in C+; it's been silently breaking people's programs forever. Ultimately it's come down the linker: traditionally calls to static constructors have been included in a special section which is executed before main(). There's no well defined mechanism to force the linker to accumulate all the fragments in any particular order. Or at least that's how it worked about a decade ago when I last had cause to look at this stuff.

From a software engineer perspective, I'd suggest that if he really needs Id1 to have identifier 1, and Id2 to have 2, (etc), then he should give the class a constructor that takes an ID.

[_TinOmen_]

I'd say that the class constructor is like a function call and for that reason the optimizer is not allowed to reorder them. So no matter how you declare them they would be initialized in order.

But I'd not be surprised if there is some C++ language rule that proves me wrong.

There's no guarantee of initialisation order at global scope in the spec IIRC. If it works it's not a guarantee it'll work at a later date or on a different compiler

In function it'd be okay

I forgot to mention I was assuming local variables in my reply. This is why I never reply on Stackoverflow anymore, I leave out important stuff and then I get downvotes