const
-
Ich habe einen const vector<T> V; und will den in einen Header packen, damit Funktionen, die V verwenden, unter Zuhilfenahme der Elemente von V optimieren können.
Kann das Probleme geben, wenn dadurch V in mehreren .cpp-Files definiert wird? Und wie ggf. kann ich das Problem lösen?
Danke.
-
Warum den Vektor öffentlich machen?
// header T const& v_get_at(size_t index); // cpp namespace { vector<T> V; } T const& v_get_at(size_t index) { return V[index]; }
-
vector<int> V {1,2,3,4,5}; if (find(V.begin(),V.end(), 3)) // do somethingDas kann wegoptimiert werden, wenn V öffentlich ist.
-
c+++++++++ schrieb:
Das kann wegoptimiert werden, wenn V öffentlich ist.
Kennst du LTO? Bitte erst solche Optimierungsaussagen überprüfen und nicht aus dem Bauch das Design verschlechtern.
Wenn du drauf bestehst, die Syntax ist:
extern vector<int> V; // im header vector<int> V; // im cpp
-
static schrieb:
Wenn du drauf bestehst, die Syntax ist:
extern vector<int> V; // im header vector<int> V; // im cppUnd wo definiere ich die Elemente von V?
-
c+++++++++ schrieb:
Und wo definiere ich die Elemente von V?
Merkst du, wieso deine Idee optimierter Unsinn ist?

Entweder sind die Elemente fest, dann ist das kein vector sondern eine konstante Liste von konstanten Ausdrücken. Oder es kann ohnehin nichts optimiert werden, denn es ist schwieriger für den Compiler, mit globalen Variablen irgendetwas zu optimieren. Der hat nämlich genau das gleiche Problem, wie der Programmierer: Bei globalen Variablen kann man gar nicht mehr sagen, wann sie sich wo ändern, weil das kleinste Teil, das man nicht sehen kann, eine Änderung verursachen könnte.
-
SeppJ schrieb:
Entweder sind die Elemente fest,
Ja, das ist der Fall.
-
const int foo[] = {1,2,3,4,5};Damit wird das auch tatsächlich optimiert. Beim vector ist mir das zuvor nicht gelungen.
-
Aber gibt das keine Probleme, wenn das im Header steht und somit in verschiedene .cpp-Files inkludiert wird?
-
c+++++++++ schrieb:
Kann das Probleme geben, wenn dadurch V in mehreren .cpp-Files definiert wird?
Bedingt. Konstante nicht-lokale Objekte haben (sofern sie nicht anders deklariert werden) internal Linkage. Die Definitionen in unterschiedlichen Übersetzungseinheiten stören sich also gegenseitig nicht.
Zu einer ODR-Verletzung kann es kommen, wenn dieses Objekt von inline-Funktionen verwendet wird, weil diese sich dann in unterschiedlichen ÜEs nicht mehr auf das gleiche Objekt beziehen und also nicht identisch sind. Praktisch spielt dieses Problem nur eine geringe Rolle (ggf. im Zusammenhang mit der Reihenfolge dynamischer Initialisierung: wenn die Funktion tatsächlich nicht geinlined wird und die out-of-line-Kopie aus einer anderen Übersetzungseinheit stammt).
Sofern möglich, empfehle hier eher ein Objekt, das statisch initialisiertbar ist (std::array, oder normales Array). Nur dann sind Zugriffe auf den Wert der Elemente konstante Ausdrücke (in diesem Fall liegt dann auch keine ODR-Verletzung i.o.S. vor) und damit leicht optimierbar.
-
camper schrieb:
Sofern möglich, empfehle hier eher ein Objekt, das statisch initialisiertbar ist (std::array, oder normales Array).
Danke, also:
const int V {1,2,3,4,5}; // oder std::array V{1,2,3,4,5};
-
std::tr1::arraynicht zu vergessen. :p
-
c+++++++++ schrieb:
Danke, also:...
fast.
const int V[] {1,2,3,4,5};oder (besser)
const std::array<int, 5> V{1,2,3,4,5};bei zweiterem nicht
#include <array>vergessen

Test bei Ideone.com