So no duplicate destruction of the same object in there.
So perhaps this is a bug with initializer lists in VC, I dunno. Are you seeing the destructor message with the same value for "this" more than once in your output?
Huh, thats weird. For me it actually completly looks like:
AttributeDeclartion() called.
AttributeDeclartion() called.
AttributeDeclartion(const AttributeDeclaration& decl) called with this: 8595680
and decl: 2686698.
AttributeDeclartion(const AttributeDeclaration& decl) called with this: 8595681
and decl: 2686699.
~AttributeDeclartion() called with this: 2686699.
~AttributeDeclartion() called with this: 2686698.
~AttributeDeclartion() called with this: 2686698. // thats the "faulty" line
Initializing vector done.
~AttributeDeclartion() called with this: 8595680.
~AttributeDeclartion() called with this: 8595681.
Press <RETURN> to close this window...
I actually found a ticket that states something about a memory leak in that initializer list in VC that should have been fixed some time ago. So maybe some over-enthusiastic programmer fixed the leak but also caused this double deletion. Don't know, based on that it doesn't happens in GCC I might as well post it to the VC-people, maybe someone there has greater insight to the actual problem.
Two things I notice about your example code (I don't have MSVC2013 on hand to test initializer lists at the moment):
1. By adding the string to the constructor you disabled the default constructor. Does the bug go away if you have a parameter of a different type? (Try with a POD like int, and a non-POD like, I dunno, std::shared_ptr<int>)
2. You don't have an assignment operator, so the compiler probably generated one for you. Add it in with matching debug output to see if an extra object is being generated and assigned to to match your destructor call. Or add it in as =delete and see if the compiler errors.
1. Yes! As I (at least I though I) mentioned it only happens with the string-type argument. Int, float bool, Class* all work. I didn't test it with other classes references which are implicitely created, might be worth a check though.
2. As I already stated multiple times, none of those operators are called in the code in question here. It would be a legit query, but doesn't mean anything here really due to this fact ;) Also, in my minimal test case, the class doesn't have any state at all, so there would be no point of a copy/move-operator in the first place... neigther is there for a copy-ctor, its just there to assist in debug-ouput. ;)