Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

21

21.06.2010, 18:50

mh... jeder von euch schlägt was anderes vor.. ursprünglich hatte ich die getter setter bzw. public member variante, dann dacht i mit i machs mitn index op, des ja no pfusch is..

hab nie so wirkli verstanden ,warum i ein struct in c++ nehmen sollt...
kann mir einer ein bsp nennen, bei dem ich mit nem struct wirkli besser bedient bin?

22

21.06.2010, 18:51

Struct == Class (bis eben default acess) in C++, daher kannste immer beides nehmen, wenn du public und private selber schreibst.

23

21.06.2010, 18:53

dacht ichs mir schon.
danke für die bestätigung

24

21.06.2010, 18:54

Steht im übrigen schon vorher im thread (dreimal).

25

21.06.2010, 19:00

sry! hatte mehrere beiträge nicht gesehn... die letzen 3 oder so auf seite eins...

26

24.06.2010, 00:13

Ich denke auch, dass sowohl std::vector, als auch If-Abfragen, als auch Exceptions komplett unangebracht für Komponentenzugriff eines 3D-Vektors sind und nur unnötigen Overhead mit sich bringen.

Der operator[] ist ein Streitfall. Kommt es bei dir jemals vor, dass du kein Literal (also eine Zahl im Code) übergibst, sondern den Wert des Indizes berechnest oder in einer Variable speicherst? Falls nicht, kannst du geradesogut statt vector[0] immer vector.x schreiben. Ich würde sprechende Namen bevorzugen und tendiere daher eher zu drei separaten öffentlichen Membervariablen.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

27

24.06.2010, 00:25

Ich denke auch, dass sowohl std::vector, als auch If-Abfragen, als auch Exceptions komplett unangebracht für Komponentenzugriff eines 3D-Vektors sind und nur unnötigen Overhead mit sich bringen.

Jap

Der operator[] ist ein Streitfall. Kommt es bei dir jemals vor, dass du kein Literal (also eine Zahl im Code) übergibst, sondern den Wert des Indizes berechnest oder in einer Variable speicherst? Falls nicht, kannst du geradesogut statt vector[0] immer vector.x schreiben. Ich würde sprechende Namen bevorzugen und tendiere daher eher zu drei separaten öffentlichen Membervariablen.

Wenn man irgendwelche Algorithmen implementiert die auf Meshes arbeiten hat man sehr sehr schnell den Fall dass man über Indizes auf Komponenten zugreifen will (z.B. wenn man Vertices nach einer Komponente sortieren will, beispielsweise um eine Baumstruktur darüber aufzubauen). Was die sprechenden Namen angeht würde ich mal sagen dass man da je nachdem von welchem Hintergrund man kommt für beide Varianten argumentieren kann, in der Mathematik ist es z.B. üblich (weil eigentlich korrekter) Vektorkomponenten über Indizes zu identifizeren.
Man kann sich (wie schon gesagt) ja aber auch was zusammenhacken was beide Varianten unterstützt:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct vector3d
{
  union
  {
    struct
    {
      float x;
      float y;
      float z;
    };
    float c[3];
  };

  float operator [](int index) const { return c[index]; }
  float& operator [](int index) { return c[index]; }
};

Ist halt nicht 100% sauberes C++ sollte aber mit den gängigen Compilern (MSVC/GCC) funktionieren.

Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von »dot« (24.06.2010, 00:43)


28

25.06.2010, 17:12

Ich würde einen Sicherheitsmechanismus einbauen, damit der Code bei falschen Annahmen bezüglich Alignment gar nicht kompiliert.

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
struct Vector3
{
    float x;
    float y;
    float z;

    float& operator[] (unsigned int index)
    {
        BOOST_STATIC_ASSERT( offsetof(Vector3, z) - offsetof(Vector3, x) == 2*sizeof(float) );
        return *(&x+index);
    }
};

Werbeanzeige