7
SetA.erase(i);
SetA.insert(LEAF[*i]);
Garnicht gut. Du iterierst über ein Set, dass Du gleichzeitig veränderst. Durch die automatische Einsortierung kann es passieren, dass Du über Elemente mehrfach iterierst, was von merkwürdigen Effekten bis zu Abstürzen führen kann.
Die bessere Lösung wäre, in ein neues Set einzufügen und dann hinterher das Alte mit dem Neuen zu swappen. Eine Ausnahme wäre höchstens, dass das Set so riesig ist, dass der temporäre, doppelte Speicherbedarf für das Set nicht tragbar ist (ab ein paar MB Speicherverbrauch kann man da vielleicht diskutieren ;))
Zum eigentlichen Problem:
Dass normale Set-Iteratoren const sein können oder nicht, ist als 'defect' im Standard bekannt. Das Problem ist, dass Du all die Kriterien des Schlüssels nicht ändern darfst, die die Sortierung beeinflussen (das Set bekommt das nicht mit und hat so internen Datenmüll) - aber auch dass es viele Parameter am Schlüssel geben kann, die die Sortierung nicht beeinflussen und meist sinnvoll geändert werden können. Es gibt Implementierungen die meinen, dass man die Schlüssel lieber const machen sollte um Fehler von vornherein zu vermeiden, und andere die Schlüssel modifizierbar lassen in der Annahme, dass der Anwender keinen Unfug damit treibt.
Sofern Du dir ganz sicher bist, dass Du die Sortier-Reihenfolge des Sets nicht änderst, und es auch keine andere pratikable Möglichkeit gibt, kannst Du das const vom Element wegcasten.
Lustiger Weise sind die Schlüssel in einer Map immer const