Wenn man einen Range-Check einbaut könnte man den doch vor die For-Schleife packen?!
Dann kann man in der Schleife für n int nehmen.
Wenn man einen Range-Check einbaut könnte man den doch vor die For-Schleife packen?!
Dann kann man in der Schleife für n int nehmen.
In dem Programm kann es potentiell zu zwei Wertebereichüberschreitungen kommen:
1) Der Wertebereich von int umfasst nicht den Wertebereich von size_t (übergabe von Arraysize an manipulate())
2) irgendwas in manipulate()?
(1) lässt sich abfangen, indem man den Wertebereich von size_t und int einmal vor Start der Aufgabe überprüft und ggf. halt direkt abbricht. Dann lässt sich auch gefahrlos size_t zu int casten.
Geändert von fuchs87 (28. Januar 2021 um 22:51 Uhr)
#KriegIstFrieden
#FreiheitIstSklaverei
#UnwissenheitIstStärke
Das kann man auch zur Compile-Zeit prüfen. Dann steht die Überprüfung auch gleich an der Stelle, wo sie benötigt wird. Wenn man das am Anfang des Programms macht, weiß man doch einen Tag später schon nicht mehr, warum diese Abfrage dort steht und optimiert sie weg.
Code:for ( std::size_t n {0}; n < array.size(); ++n){ auto parameterForManipulate = static_cast<int>(n); static_assert(myArray.size() <= numeric_limits<decltype(paramForManipulate)>::max()); array[n] = manipulate(parameterForManipulate ); } }
Civ4 PBEM: 235, 49, 60, 208, 259, 392 - tot, 22, 71, 90, 340 - vernichtet, 53, 132 - überlebt, 166, 294, 378 - gewonnen
Während oder vor dem Kompilieren testen ist am besten, ja.
Funktioniert array.size() in static_assert immer? Ich gehe davon aus, dass die Größe von array variabel ist.
#KriegIstFrieden
#FreiheitIstSklaverei
#UnwissenheitIstStärke
Ich bin bei dem Namen jetzt davon ausgegangen, dass das ein std::array ist. Wenn das zur Laufzeit variabel ist, geht das so natürlich nicht.
Civ4 PBEM: 235, 49, 60, 208, 259, 392 - tot, 22, 71, 90, 340 - vernichtet, 53, 132 - überlebt, 166, 294, 378 - gewonnen
Ich nutze Ubuntu 18.04 und ich möchte zu Testzwecken gerne eine Conda-Umgebung mit Python 2.5.1 aufsetzen. Das Problem ist, dass diese Distribution nicht automatisch mit
conda create -n test_python_env python=2.5.1
gebaut werden kann. Ich habe mir daher die besagte Version von python.org heruntergeladen (Python-2.5.1.tar.bz2).
(Wie) ist es damit möglich eine conda Umgebung fürPython 2.5.1 zu bauen?
Diese Python-Version ist 14 Jahre alt, d.h. du wirst vermutlich auf einige Probleme stoßen, wenn du eine aktuelle Anaconda-Version verwendest Hört sich jedenfalls nach sehr viel Ärger an, dennn man vllt. gar nicht erst suchen sollte.
Hast du für Ubuntu miniconda installiert oder das volle Paket? Ich frage weil ich keins von beiden installiert habe und dann ggf. das gleiche nehme.
Ob der Paketmanager conda überhaupt Python-Pakete für Python 2.5 bereit hält, ist für mich unklar. Kann sein, dass das gar nicht mehr supportet wird.
Nun zu deiner eigentlichen Frage:
Du musst die Python-Version erst noch kompilieren und installieren:
Damit diese alte Python-Version nicht in deinem System landet würde ich bei configure einen Prefix vorgeben.Code:tar -zxvf Python-2.5.1.tgz cd Python-2.5.1 ./configure --prefix=/irgendein/pfad make make install
Wie du conda dann die Info übergibst, wo diese 2.5.1-Python-Version liegt, habe ich noch nicht gefunden.
Geändert von Ramkhamhaeng (09. Februar 2021 um 18:16 Uhr)
Also ich habe jetzt miniconda installiert, aber ich komme auch nicht weiter.
Da https://repo.anaconda.com/miniconda/ Python 2.5 nicht enthält werden vermutlich die Python-Pakete auch nicht in einer kompatiblen Version vorgehalten.
Du könntest versuchen bei dem obigen Configure-Befehl auf das Verzeichnis von
miniconda2 zu verweisen, bei mir ../nyan/miniconda2/,
und es dort zu installieren.
Danach leitest du den symbolischen Link in miniconda2/bin/python (und python2...) auf Version 2.5 um, (cd miniconda2/bin; rm python2 ; ln -s python2.5 python2)
Danach komme ich aber nicht weiter, weil die conda-Version python2.7 erwartet
(source bin/activate scheitert).
Hier breche ich dann mal ab
Edit: Auch bei der Miniconda-Version 1.6.2 von 2013 nutzen sie schon Python 2.7.2.
Geändert von Ramkhamhaeng (09. Februar 2021 um 21:52 Uhr)
Mir ist bewusst, dass das von 2007 ist. Freiwillig würde ich das auch nicht anfassen. Es ist nur folgendes Szenario: ich muss eine Komponente auf einem Remote-Server (Ubuntu mit Anaconda3) nutzen. Diese Software-Komponente nutzt eine eigene Python-Version, nämlich 2.5.1. Sie bekommt von mir ein Python-Skrypt zum Ausführen.
Ich möchte nun innerhalb des Skriptes aus der Tool-Python ausbrechen. Müsste eigentlich mit "conda activate meine Umgebung" funktionieren, aber es klappt einfach nicht. Dazu ist die Komponente wegen Rekord-Zugriff super-lahm. Deshalb hatte ich gehofft, die Komponente bei mir Lokal mit einer Python2.5.1-Umgebung zu emulieren...
Ich weiß zumindest, dass die Komponente die Conda-Umgebung auf dem Remote-Server findet, nur aktivieren tut sie sie nicht.
Habe gelesen, dass man auf Linux-System früher source statt activate genutzt hat, aber das habe ich schon getestet.
Nunja, ich glaube dann werde ich wohl den schmerzhaften Weg gehen und es über den Remote-Zugriff debuggen.
Danke für deinen Versuch Ramkh
Wenn auf dem Server die uralte 2.5.1er Version installiert ist liegt die Vermutung nahe dass neuere Versionen von Python dort nicht vorhanden sind. Hattest du bei deiner Umgebung eine aktuelle Python-Version angegeben?Ich möchte nun innerhalb des Skriptes aus der Tool-Python ausbrechen. Müsste eigentlich mit "conda activate meine Umgebung" funktionieren, aber es klappt einfach nicht.
Kannst du vielleicht lokal eine andere Python-Version, z.B. 2.7, nutzen? Könnte sein, dass immerhin die Komponente aufwärtskompatibel ist.Dazu ist die Komponente wegen Rekord-Zugriff super-lahm. Deshalb hatte ich gehofft, die Komponente bei mir Lokal mit einer Python2.5.1-Umgebung zu emulieren...