Opened by styx-cc at 2020-03-13 21:20
User since
2015-01-07
557 Artikel
BenutzerIn
2015-01-07
557 Artikel
BenutzerIn
Bei genauem Hinsehen wird Dir auffallen, dass es nicht jedesmal die gleichen Dinge sind, die gelöscht werden. Und eigentlich sollte der Schlüssel
1284 nach Abarbeitung der 1285 gelöscht sein und nicht ein leeres Array.
Die Ursache: Die Reihenfolge, in der von keys %ranges abgearbeitet wird, ist zufällig. Wenn also zum Beispiel 1283 vor 1282 abgearbeitet wird, dann löscht diese Bearbeitung den Key 1282. Danach kommt irgendwann der Key 1282 dran, dessen Daten schon weg sind. Du greifst dann direkt mit my $related_r = @{ $ranges->{$range} }[3]; in den Hash rein - und dadurch entsteht die leere Liste. Das Phänomen heißt bei Perl "autovivication".
Die Abhilfe: Wenn die Einträge mit "related" immer höhere Schlüsselwerte haben als die, auf die sie sich beziehen, dann sortiere die Liste:
Robuster, weil unabhängig von der Reihenfolge: Prüfe, ob der Schlüssel, den Du suchst, noch existiert:
1284 nach Abarbeitung der 1285 gelöscht sein und nicht ein leeres Array.
Die Ursache: Die Reihenfolge, in der von keys %ranges abgearbeitet wird, ist zufällig. Wenn also zum Beispiel 1283 vor 1282 abgearbeitet wird, dann löscht diese Bearbeitung den Key 1282. Danach kommt irgendwann der Key 1282 dran, dessen Daten schon weg sind. Du greifst dann direkt mit my $related_r = @{ $ranges->{$range} }[3]; in den Hash rein - und dadurch entsteht die leere Liste. Das Phänomen heißt bei Perl "autovivication".
Die Abhilfe: Wenn die Einträge mit "related" immer höhere Schlüsselwerte haben als die, auf die sie sich beziehen, dann sortiere die Liste:
Robuster, weil unabhängig von der Reihenfolge: Prüfe, ob der Schlüssel, den Du suchst, noch existiert:
Code (perl): (dl
)
1 2 3 4
for my $range (keys %$ranges) { next unless exists $ranges->{$range} my $related_r = @{ $ranges->{$range} }[3]; # ...