Der Übergang zu Boost-1.65.1 und aufgetretene Fehler

Letztes Jahr (fast ein ganzes Jahr ist bereits vergangen) haben wir dennoch auf die neue Version von Boost-1.65.1 umgestellt, und unter der Haube finden Sie die drei Boost-Fehler, auf die wir gestoßen sind. Es ist auch wichtig zu erwähnen, dass zuvor Boost -1.62.1 in unserer Software verwendet wurde, da einige Fehler in Boost früher als Version 1.65.1 aufgetreten sind

Unser Projekt verfügt über ein spezielles Integrationsteam, dessen Hauptaufgabe darin besteht, die gesamte Software auf eine neue Version von Bibliotheken, Visual Studio, neue Versionen von Low-Level-Komponenten (Basiskomponenten, von denen die meisten anderen Komponenten abhängen) usw. zu migrieren. Das Integrationsteam ist auch dafür verantwortlich, alle auftretenden Probleme zu beseitigen, natürlich mit Unterstützung der Komponentenbetreuer, falls erforderlich. Also, Fehler, an die ich mich besonders erinnere.

Fehler im boost :: Dateisystem

Dieser Fehler trat schnell genug auf. Bei der Suche nach dem vollständigen Pfad zum angegebenen Dateinamen stürzten die Tests mit "Zugriffsverletzung" ab. Die Funktion hat einen Aufruf von boost :: filesystem :: exist ausgeführt und das Programm ist abgestürzt. Bei einigen weiteren Tests wurden mehrere ähnliche Fälle festgestellt, während in allen Fällen der Aufruf boost :: filesystem :: exist für globale Variablen ausgeführt wurde. Anscheinend hat sich in der Lebensdauer der Boost-Variablen etwas geändert. Ein Ticket für einen erkannten Fehler ist sehr einfach, ein Fehlerticket in boost :: filesystem :: exist zu googeln

Es stellte sich heraus, dass dieser Fehler ab Version 1.64 verstärkt wurde. Eigentlich war das Problem im Aufruf von make_permissions (verwendet in filesystem :: exist). In 1.64 wurde die Implementierung von make_permissions geändert und verwendet nun globale Variablen. Wenn also beim Initialisieren einer globalen Variablen oder eines globalen Objekts versucht wird, filesystem :: exist aufzurufen, werden die in make_permissions verwendeten globalen Variablen möglicherweise noch nicht initialisiert. Daher löst ein Versuch, auf eine undefinierte Variable zuzugreifen, eine Ausnahme aus.

Fehler in boost :: python

In Tests mit boost :: python wurde etwas Seltsames entdeckt. Wenn Sie eval () für ein Literal (z. B. "40 + 2") trivial aufrufen, werden alle Regeln angezeigt. Wenn Sie die Variablen definieren und sie dann in Ausdrücken verwenden, erhalten wir die Meldung, dass die Berechnungen undefinierte Variablen verwenden (FEHLER: [Name] nicht definiert). Um dieses Problem zu lösen, habe ich mehr Zeit aufgewendet. Ich konnte im Boost-Tracker kein Ticket für dieses Problem finden, daher musste ich das Team dieser Komponente um Hilfe bitten. Informationen über den Fehler wurden schnell auf Github gefunden .

Es kam vor, dass bei der Implementierung von eval die globalen und lokalen Objekte nicht verwendet wurden. Nachdem das Team viel Glück bei der Suche nach einem Fix gewünscht hatte, ohne den Quellcode neu zu kompilieren, verabschiedete es sich :)

boost :: numpy

Dies ist mein am wenigsten bevorzugter Teil. boost :: python :: numeric wurde entfernt und jetzt wurde boost :: python :: numpy als Alternative angezeigt. Der Code, der numerisch verwendete, musste jedoch ziemlich neu gestaltet werden, da es nicht nur darum ging, den Namespace umzubenennen, sondern auch die Objekte zu implementieren.

Außerdem gab es im Header des Boosts Fehlinformationen, die mich irreführten.
Laut dem Kommentar in der Quelle wird der Aufruf von import_array () bereits in numpy :: initialize () ausgeführt:

namespace boost { namespace python { namespace numpy { /** * @brief Initialize the Numpy C-API * * This must be called before using anything in boost.numpy; * It should probably be the first line inside BOOST_PYTHON_MODULE. * * @internal This just calls the Numpy C-API functions "import_array()" * and "import_ufunc()", and then calls * dtype::register_scalar_converters(). */ BOOST_NUMPY_DECL void initialize(bool register_scalar_converters=true); }}} // namespace boost::python::numpy 

Wie sich herausstellte, wird import_array () benötigt.

Darüber hinaus gab es Probleme beim Testen der Änderungen, da Codeteile mit numpy (zuvor mit boost :: python :: numeric) überhaupt nicht durch Tests abgedeckt wurden und der Code selbst auch in einer anderen Komponente verwendet wurde. Daher wurden Probleme nur beim Testen der entsprechenden Komponente festgestellt. Das Integrationsteam muss keine Tests für die Komponenten schreiben, und diese Situation war eine Auslassung des Teams selbst. Wow, ich habe genug von ihnen gehört, dass ich ihren Code gebrochen habe. Aber nachdem das Team gemurrt hatte, deckten sie ihren Code schließlich mit Tests ab. Der Groll blieb jedoch bestehen (während der nächsten Migration wollte das Team meinem Kollegen keinen Zugang zu seiner Komponente gewähren und erwähnte, dass wir das letzte Mal den Code für sie gebrochen hatten. Sasha, Soryan! Aber nach drei Tagen Verhandlungen gaben sie auf).

Fazit

Nach der geleisteten Arbeit kann ich die Pluspunkte für mich selbst feststellen, da Boost zuvor nicht sehr oft verwendet wurde (hauptsächlich Standard), so dass durch die Migration viel hervorgehoben werden kann. Es ist lustig, aber Tatsache ist, dass Sie nach einem solchen Grund aus irgendeinem Grund für viele Kollegen standardmäßig ein „Boost-Experte“ werden, und wenn Sie sich versöhnen, werden Ihnen noch einige Zeit Fragen dazu gestellt.

Übrigens haben in den letzten Jahren viele Unternehmen begonnen, Boost aktiv loszuwerden und die Standardbibliothek nach Möglichkeit zu ersetzen, oder etwas anderes, wenn keine Funktionen in der Standardbibliothek vorhanden sind. Und auch wir standen nicht beiseite. Der Prozess wird gestartet, aber noch nicht abgeschlossen, es gibt noch viel Arbeit.