Problem: Runtime Library

Redadmiral

@manni66
Hättest du eventuell eine einfache Lösungsmöglichkeit für mich parat?
Auch hier wieder vielen Dank für die ganze Unterstützung!

@redadmiral
Benutze die Membervariable, nicht die Getterfunktion. Das gilt natürlich auch für die map ein paar Zeilen später.

Wann immer du eine solche Getterfunktion benutzen musst: rufe sie nur einmal auf und weise das Ergebnis einer lokalen Variablen zu. Anschließend benutze diese Variable.

Redadmiral

@manni66
Vielen Dank nochmals für deine Hilfe, jedoch bekomme ich es leider immer noch nicht hin. Ich bin leider absoluter Anfänger im Programmieren und mir geht leider auch etwas die Zeit aus. Könntest du mir eventuell, falls es keine zu großen Umstände macht, beispielhaft zeigen, wie ich das ausgebessert bekomme? Am liebsten wäre mir natürlich wenn du es mir an meinem Bsp. direkt zeigen könntest. Bitte entschuldige die Unannehmlichkeiten, aber ich schiebe mittlerweile etwas Panik, da mir das Ganze auch nicht so gut liegt.

dirkski

@redadmiral Da sich keiner Beschwert: Sieht das nur bei mir so ugly aus? Ich meine der halbe Code als normaler Text, dann ein Teil in der codebox? Ist mir jetzt schon bei mehreren Posts hier aufgefallen. Beitrag unten rechts sind drei Punkte, darüber kann man das Posting bearbeiten... Danke!

@redadmiral
Nein. Wenn du den Rest tatsächlich selbst programmiert hast ist die Umsetzung trivial.

Th69

@redadmiral: Falls du mit dem Begriff "Membervariablen" (noch) nichts anfangen kannst, das sind die Variablen in der Headerdatei unterhalb von "private:" (zumindestens in deiner gezeigten Headerdatei).

dirkski

@dirkski sagte in Problem: Runtime Library:

@redadmiral Da sich keiner Beschwert: Sieht das nur bei mir so ugly aus? Ich meine der halbe Code als normaler Text, dann ein Teil in der codebox? Ist mir jetzt schon bei mehreren Posts hier aufgefallen. Beitrag unten rechts sind drei Punkte, darüber kann man das Posting bearbeiten... Danke!

Ah. Viel Besser. Danke und Guten Morgen.

DocShoe

@redadmiral sagte in Problem: Runtime Library:
Könntest du mir eventuell, falls es keine zu großen Umstände macht, beispielhaft zeigen, wie ich das ausgebessert bekomme? Am liebsten wäre mir natürlich wenn du es mir an meinem Bsp. direkt zeigen könntest. Bitte entschuldige die Unannehmlichkeiten, aber ich schiebe mittlerweile etwas Panik, da mir das Ganze auch nicht so gut liegt.

Das Problem liegt darin, dass Lift::getCabinDisplaySelectedLevels() eine Kopie des set zurückgibt und bei jedem Aufruf eine neue Kopie erzeugt wird.

for (it = Lift::getCabinDisplaySelectedLevels().begin();  // it ist ein Iterator aus Kopie #1
     it != Lift::getCabinDisplaySelectedLevels().end();   // und wird mit end() aus Kopie #2 verglichen
     it++)

Das ist der Grund für deine Fehlermeldung.
Dazu gibt es jetzt mehrere Lösungen:

du änderst den Rückgabetyp der Methode getCabinDisplaySelectedLevels() von set<int> auf const set<int>& und gibst eine Referenz auf die Membervariable zurück. Das löst zum einen das Problem der Iteratoren aus verschiedenen Kopien und ist zum anderen auch deutlich performanter, da überhaupt keine Kopie erzeugt wird.
du benutzt die Membervariable cabinDisplaySelectedLevels statt der Methode Lift::getCabinDisplaySelectedLevels().
du benutzt eine lokale Kopie und benutzt die für die Auswertung

auto local_copy = getCabinDisplaySelectedLevels();
for (it = local_copy.begin(); it != local_copy.end(); it++)

du benutzt range-based for statt Iteratoren.

for( auto position : getCabinDisplaySelectedLevels() )

Das löst zumindest das Problem der Kopien, da das intern benutzte Iteratorenpärchen auf der gleichen Kopie von set<int> erzeugt werden. Spätestens im weiteren Verlauf der Methode wird´s dann aber unheimlich, weil dann eine Kopie benutzt wird um festzustellen, ob Elemente aus den Originaldaten gelöscht werden sollen.

Vorschlag 1 und 2 sind tatsächlich brauchbar, 3 und 4 eher theoretisch und lösen nur das Problem der Iteratoren aus verschiedenen sets. Dafür werfen sie neue, andere Probleme auf.

Zwei andere Punkte:

benutze niemals using namespace in Headerdateien! Das hebelt alle Vorteile und Mechanismen von namespaces wieder aus.
die Notation *Lift::doorIsOpen * innerhalb einer Memberfunktion ist ungewöhnlich und überflüssig. Es gibt Fälle. wo this->doorIsOpen notwendig ist (s.u.), das ist bei dir aber nicht der Fall.

void Lift::set_door_status( bool doorIsOpen )
{
   // Qualifizierung per this ist notwending, um Mehrdeutigkeit aufzulösen
   this->doorIsOpen = doorIsOpen;
}

Redadmiral

@docshoe
Vielen Dank für deine Hilfe! Aber leider bekomme ich das Ganze immer noch nicht zum Laufen. Ich sitze da jetzt schon den ganzen Tag dran, aber der einzige ersichtlich Fortschritt war bisher, dass das Programm nicht sofort die Fehlermeldung ausgewurfen hat, sonder einen Augenblick gewartet hat. Ich probiere da heute schon seit gut 5 h herum und versuche deine Lösungsvorschläge umzusetzen. Ich komme aber leider nicht mehr klar oder ich mache irgendetwas falsch.
Ich würde am liebsten deinen 1. Lösungsweg umsetzen, aber weder den noch einen anderen bekomme ich zum Laufen. Könntest du mir eventuell kritische Codepassagen ausbessern?
Das ist unverschämt soetwas zu fragen, aber ich weiß echt nicht mehr weiter.
Trotzdem nochmal vielen Dank an alle Unterstützer bisher! Ich weiß ich bin ein harter Fall.

Th69

Du mußt das selbstverständlich nicht nur für das std::set<>sondern auch für die std::map<> umsetzen.

Am besten kommentiere ersteinmal den unteren Teil des Codes von setPositionSensoraus und wenn das für 'std::set<>' funktioniert, kommentierst du den 'std::map<>' Teil wieder ein und änderst diesen dann entsprechend ab!