Stilfrage?

*D*Evil

Man muss nicht immer die ganzen Klassen dafür nehmen ... was soll der Mist? Kann mir keiner erzählen dass das noch performant sein soll. Ein einfaches

int m_datapair[2];
// ---
int m_datapair_x;
int m_datapair_y;

Tut es genau so gut.

__Stefan__

Eine andere Möglichkeit:

struct Blah
{

  struct
  {
    int a, b;
  } pair;

};

BorisDieKlinge

stimmt schon das man nicht immer die bibliotheken nehmen soll,

aber

struct PAIR{

 int a,b;

} pair;

ist gegenüber

std::pair<int,int> pair;

im code unschön, und zerstört evtl. die übersichtlichkeit

__Stefan__

BorisDieKlinge schrieb:

stimmt schon das man nicht immer die bibliotheken nehmen soll,

aber
struct PAIR{

 int a,b;

} pair;
ist gegenüber
std::pair<int,int> pair;
im code unschön, und zerstört evtl. die übersichtlichkeit

Aber du kannst dafür auch andere Bezeichner als first und second nehmen.

Und das struct benötigt übrigens keinen Typen-Namen.

bwbg

Ich verwende std::pair eigentlich nur in den Fällen, wo beide Werte des Paares einen gegenseitigen Bezug haben: Schlüssel-Wert-Beziehungen sind solche Fälle. Als Attribut verwendete ich dieses Konstrukt nie.

Bei Parametern, wie zum Beispiel Koordinaten, Vektoren etc. verwende ich eine eigene Struktur oder Klasse. Die Parameter (z.B. x, y oder r, winkel) übergebe ich dann auch als eigenes Objekt.

Schlussendlich empfinde ich Methoden- oder Funktionsdeklarationen á la

Punkt::Punkt(double x, double y);

um einiges aufschlussreicher (und lesbarer) als

Punkt::Punkt(std::pair<double, double>koordinate);

.

Und Dinge wie

Punkt::Punkt(double[2] koordinate);

lasse ich gleich ganz bleiben. Es gibt wirklich keinen Grund (der mir bekannt ist), der einen Zeiger in der Situation rechtfertigt.

--

Innerhalb der Klasse würde ich das Paar als zwei seperate Attribute ablegen:

double x;
double y;

Alleine aus dem Grund, um vernünftig und lesbar mit den Attributen zu arbeiten.

foo = koordinate[0];
bar = koordinate[1];
// oder gar
foo = koordinate.first;
bar = koordinate.second;

Die ersten beiden wären noch halbwegs nachvollziehbar. Aber beim Zweiten (std::pair) kann man so schnell schon nichts mehr mit anfangen - zumal mir persönlich der Bezug zur Bedeutung der einzelnen Werte des Paares fehlte.

Grüße...

Heiko

Simon2

BorisDieKlinge schrieb:

...

std::array<int>

...

Was'n das ?

Gruß,

Simon2.

Simon2

(D)Evil schrieb:

...Ein einfaches
int m_datapair[2];
// ---
int m_datapair_x;
int m_datapair_y;
Tut es genau so gut.

Kommt drauf an !
Dein Code ist schnell zu

int m_datapair[3];
// ---
int m_datapair_x;
int m_datapair_y;
int m_datapair_z;

erweitert.
Wenn man für möglich hält, sollte man Deinen Ansatz wählen - wenn nicht, kann das std::pair schon passend sein. Letztlich IMHO eine Frage der fachlichen Anforderungen und Modellierung.

Mich wundert ein wenig, dass für Dich wieder einmal die Verwendung der StandardLib mit "Aufwand" verbunden zu sein scheint...
Was soll denn an einem pair komplizierter sein als an einem Array ? (zumal das pair nichteinmal diese "pointer degeneration" aber auch keine Pointer Arithmetik hat).

Gruß,

Simon2.

BorisDieKlinge

ups.. std::array<int> dachte sowas gibts;) :p

thordk

ich nehm für sowas eigentlich grundsätzlich nen eigenen datentypen.

struct Data
{
  int x, y, z, schnickschnack;
};

und baller den in nen vector. warum? weil man so nie durcheinander kommt, mit was für nem typen man grad hantiert. außerdem kanns leicht erweitert werden. ob man nun nen array oder pair oder sonstwas nimmt, mag performancetechnisch ne rolle spielen, sobald man mit ein paar hunderttausend einheiten hantiert. aber mit nen paar tausend daten ist das sowas von wurst und da geht mir lesbarkeit weit über mikrooptimierung.

hustbaer

(D)Evil schrieb:

Man muss nicht immer die ganzen Klassen dafür nehmen ... was soll der Mist? Kann mir keiner erzählen dass das noch performant sein soll. Ein einfaches
int m_datapair[2];
// ---
int m_datapair_x;
int m_datapair_y;
Tut es genau so gut.

Also nu bleib mal am Boden. Performance-mässig reisst sich das genau NIX verglichen mit std::pair oder boost::tuple.