Eine Library stellt eine Datenstruktur zur Verfügung. Für Programme, die diese
Library verwenden, ist es typisch, daß diese in Schleifen mit der Datenstruktur
kommunizieren und dabei Indizes verwenden. Nun scheint es mir aus Gründen der
Lesbarkeit gut, den verschiedenen Typen von Indices über typedef einen Namen
zu geben, also etwa

typedef int elementIdx;
typedef int subElementIdx;

Findet Ihr das sinnvoll oder gibts ein Argument, das zu lassen? Was ist dafür
ein sinnvoller Coding-Standard? elmementIdx, ElementIdx, ElementIdxType...?

Danke

Was ist dadurch gewonnen? Es gibt keine zusätzlichen Typ-Überprüfungen, weil du ja den Quellcode der Bibliothek nicht verändern kannst, nehme ich mal an.
Ich finde, das ist ein klassischer Fall von "Wähle vernünftige Variablennamen".

Nein, das war unklar ausgedrückt. Ich schreibe die Library und möchte in der API diese typedefs unterbringen, damit der User-Code nicht so aussieht:

for(int i=
{
  for(int j=
..

sondern

for(elementIdx i=
{
  for(subElementIdx j=
..

Decimad schrieb:

Was ist dadurch gewonnen? Es gibt keine zusätzlichen Typ-Überprüfungen, weil du ja den Quellcode der Bibliothek nicht verändern kannst, nehme ich mal an.
Ich finde, das ist ein klassischer Fall von "Wähle vernünftige Variablennamen".

Nein, das war unklar ausgedrückt. Ich schreibe die Library und möchte in der API diese typedefs unterbringen, damit der User-Code nicht so aussieht:

for(int i=
{
  for(int j=
..

sondern

for(elementIdx i=
{
  for(subElementIdx j=
..

Und wie wär:

for( int element = 0; ... )
    for( int subelement = 0; ... ) {
        // ...
    }
}

?

Du endest ansonsten in deinen Bibliotheken mit 5000 Namen für ganzzahlige Indizes, die aber alle fröhlich ineinander konvertierbar sind, also nichts im Sinne von Sicherheit bringen. Zudem muss der Benutzer anhand der Signaturen der Funktionen immer nachschlagen, was genau da nun eigentlich gemeint ist.
Aber Volkard hat schon Recht, probier es einfach mal aus

namespace Foo
{
typedef int IndexType;
}

Einen eigenen Typedef für jede "Art" von Index zu machen, wenn im Endeffekt eh alle auf den selben Typ aufgelöst werden halte ich nicht für sinnvoll.

Und wie man den Typedef nennen sollte hängt natürlich davon ab was für naming Conventions man verwendet. In der Standard-Library wird xxx_t verwendet, also dann vielleicht index_t. In Projekten die CamelCase verwenden dann vermutlich IndexT oder IndexType oder für ganz verwegene auch bloss Index.
Manche APIs/Libraries verwenden für Typedefs auch ausschliesslich Grossbuchstaben, also dann INDEX.

Wenn möglich würde ich allerdings einfach size_t verwenden.

Anders siehts meiner Meinung nach bei IDs aus. Ich hab mal ein Framework geschrieben, bei dem verschiedene Entitäten (d.h. Klassen) mit IDs angesprochen wurden. Da gabs dann eine RuleID, CheckpointID usw.
In meinem Fall waren das simple std::string, da das Framework aber noch weiterentwickelt werden sollte, hab ich tatsächlich mehrmals typedef std::string XyzID geschrieben - so dass bei Bedarf später z.B. long oder andere Dinge als ID benutzt werden können.

Die frage "typedeffe ich einen simplen Datentyp?" ist also nicht pauschal zu beantworten sondern situationsabhängig.

Und wie wär:

for( int element = 0; ... )
    for( int subelement = 0; ... ) {
        // ...
    }
}
?

Auch gut, aber sinnvolle Variablennamen sind Sache des Users, während hier das
Design der Library überdacht wird. Ich glaube, der User hat es leichter, wenn
die Methoden der Datenstruktur Argumente haben, deren Typ nicht 'int', sondern
'elementIdx' oder 'subElementIdx' ist.

lg

Bei Indizes stimme ich meinen Vorgängern zu - das sind eigentlich immer Ganzzahlen und das braucht man auch nicht zu maskieren, wenn man davon ausgeht, dass sich nichts grundlegendes am Indextyp ändert.

Anders siehts meiner Meinung nach bei IDs aus. Ich hab mal ein Framework geschrieben, bei dem verschiedene Entitäten (d.h. Klassen) mit IDs angesprochen wurden. Da gabs dann eine RuleID, CheckpointID usw.
In meinem Fall waren das simple std::string, da das Framework aber noch weiterentwickelt werden sollte, hab ich tatsächlich mehrmals typedef std::string XyzID geschrieben - so dass bei Bedarf später z.B. long oder andere Dinge als ID benutzt werden können.

Die frage "typedeffe ich einen simplen Datentyp?" ist also nicht pauschal zu beantworten sondern situationsabhängig.

Also ich würde deine ID's jetzt so ungefähr auch als Handles verstehen - und da macht es ja durchaus Sinn, das zu typedef'en, weil man ja evtl. mal auf Hashes umsteigen möchte oder sowas. Voll einverstanden!

for( int element = 0; ... ;

Wenn ich doch bloß wüßte, was in mit den ... gemeint ist.

Eigentlich müßte man auf ranged for loops warten oder an sowas

for( decltype(...) element = 0; ... ;

denken.

Und den typedef lokal machen.

typedef decltype(...) ElementIndexType;
for( ElementIndexType element = 0; ... ;

aua, ach nee, das ist ja übel.

auto

for( auto element = 0; ... ;

So, Problem ist weg.