Pointer auf Arrays aus Structs

[volkard]

unskilled schrieb:

Ne - weils einfach mal ne PLZahl ist - und nen string einfach mal nix da zu suchen hat...
mal ein paar gründe:
- "01234" != "1234"

hab gerde mit size_t experimentiert.
da war auch 01234 != 1234

[Nexus]

unskilled schrieb:

Nummer oder Straße oder ID sind also die Eigenschaften einer Person?
Naja - man kann es machen - aber es sind halt echt zu viele Eigenschaften...

Ja, wie ich sagte, gewisse Aufteilungen können schon sinnvoll sein, aber ich würde nicht von vorneweg sagen, es wäre schlecht ohne.

unskilled schrieb:

Ne - weils einfach mal ne PLZahl ist - und nen string einfach mal nix da zu suchen hat...

Ach ja? Ich würde eher sagen, ein Integer hat da nichts zu suchen. Man muss schliesslich keine einzige Rechnung damit betreiben. Noch ein paar andere Gegengründe:

unskilled schrieb:

- "01234" != "1234"

Gerade das spricht doch für Strings. Wie willst du einen size_t speichern, der mit einer Null anfängt? Oder den für ein anderes System, bei dem die Grösse von size_t nicht ausreicht oder nicht nur Ziffern vorkommen?

unskilled schrieb:

- unzählige prüfungen für die eingabe (nur zahlen eingegeben, richtige länge angegeben, ...)

Und wieso sollten diese Prüfungen bei einem size_t wegfallen?

unskilled schrieb:

- vergleiche sind langsamer -> nach plz sortieren stinkt
- mind. 6 * mind. 1 Byte vs. 4 (bzw. Byte

Performance- und Speicherplatzwahn auf Kosten der Funktionalität? Das würde ich nicht wollen...

[drakon]

Nexus schrieb:

unskilled schrieb:

- "01234" != "1234"

Gerade das spricht doch für Strings. Wie willst du einen size_t speichern, der mit einer Null anfängt? Oder den für ein anderes System, bei dem die Grösse von size_t nicht ausreicht oder nicht nur Ziffern vorkommen?

Jup. Muss ja nicht unbedingt eine Zahl sein.
z.B: http://de.wikipedia.org/wiki/Postleitzahl_(Vereinigtes_Königreich)

[Nemonisinili]

LOL, ich hatte schon Angst dass ich auf meine Problematik gar keine Antwort kriege weil alle anderen Posts welche nach meinem gepostet wurden viel schneller beantwortet wurden... Und jetzt bin ich völlig überfordert mit all euren Tricks & Tipps Ihr seid schon genial, aber sooo gut muss das auch wieder nicht sein Ich werde nach der morgigen Prüfung mir euren Code noch genauer ansehen und mich etwas über diese Möglichkeiten informieren
Ich hoffe ihr verzeiht mir dass ich trotz mehrmaligen Lesens eurer Hinweise noch nicht weiss, welche dieser Möglichkeiten jetzt die beste von allen ist... vermutlich ab einem gewissen Grad Geschmackssache denke ich. Aber dass meine Version unschön ist, dessen bin ich mir zumindest bewusst

[unskilled]

volkard schrieb:

hab gerde mit size_t experimentiert.
da war auch 01234 != 1234

oO

@nexus: imho ging es nur um deutsche anschriften / plz / ...
ich hab zumindest keine länderkennung oä in der klasse gesehen

und im deutschen ist es nun mal so, dass die PLZ "01234" gleich der "1234" entspricht...
es ist zwar nicht gerade üblich, 1234 zu schreiben aber imho auch nicht verkehrt...

Und wieso sollten diese Prüfungen bei einem size_t wegfallen?

size_t plz;
do    {
   std::cin >> plz;
} while ((plz > 99999) || (!plz));

im Gegensatz zu std::string, bei dem man die länge überprüfen muss und extra noch jede stelle darauf, ob es eine zahl ist...

btw:
die klasse ist auch auf vor- und nachname beschränkt - was ist, wenn jmd nen dritten name hat?

naja - wie auch immer... nimm halt nen string

bb

[Nexus]

unskilled schrieb:

und im deutschen ist es nun mal so, dass die PLZ "01234" gleich der "1234" entspricht...
es ist zwar nicht gerade üblich, 1234 zu schreiben aber imho auch nicht verkehrt...

Hm, naja. Bei einer Zahl muss man jedes Mal bei der Ausgabe wieder an die führenden Nullen denken. Da finde ich eine einheitliche Formatierung mit Zeichenketten gleicher Länge besser.

unskilled schrieb:

size_t plz;
do    {
   std::cin >> plz;
} while ((plz > 99999) || (!plz));

im Gegensatz zu std::string, bei dem man die länge überprüfen muss und extra noch jede stelle darauf, ob es eine zahl ist...

Und was passiert, wenn man in die Konsole "askfdlaö" eingibt?

Abgesehen davon, wieso sollte man die PLZ hier überhaupt prüfen? Wenn, dann müsste man wohl jeden Ort gespeichert haben (die Zahlen sind ja nicht schön aufgezählt). Und andere Attribute prüft man schliesslich auch nicht.

Naja, es ginge vielleicht schon knapp mit size_t . Aber damit ist man unflexibel und eine eigene Klasse dafür zu überladen, obwohl es mit std::string gut geht, finde ich nicht angebracht...

[volkard]

Nexus schrieb:

Naja, es ginge vielleicht schon knapp mit size_t . Aber damit ist man unflexibel und eine eigene Klasse dafür zu überladen, obwohl es mit std::string gut geht, finde ich nicht angebracht...

endlich sagt einer den rechten weg!
und dann lehnt er ihn ab.

klar nen eigenen typ. nix anderes darf gemacht werden.
anfangs reicht durchaus

typedef std::string Postleitzahl.

keine string-spezifischen und unpostleitzahligen sachen sachen wie .begin() benutzen. und sich damit den weg freihalten, die postleitzahl beliebig anders zu implementieren.

sowas geht auch:

struct Postleitzahl
{
   int plz;
   friend ostream& operator<<(ostream& out){
      return out<<setfill('0')<<setw(5)<<plz;
   }
   friend bool operator<(Postleitzahl a,Postleitzahl b){
      return a.plz<b.plz;
   }
}

ist egal. aber es MUSS einen eigenen typen gehen. wer von euch weiß, wann die post wieder die postleitzahlen umstellt? ich jedenfalls nicht und bevorzuge in solchen sachen einen ganz defensiven programmirstil.

[unskilled]

volkard schrieb:

sowas geht auch:

struct Postleitzahl
{
   int plz;
   friend ostream& operator<<(ostream& out){
      return out<<setfill('0')<<setw(5)<<plz;
   }
   friend bool operator<(Postleitzahl a,Postleitzahl b){
      return a.plz<b.plz;
   }
}

Und genau so habe ich es doch auch gesagt - nur, dass ich statt int size_t genommen hatte (weil mir nicht bewusst ist, dass es negative PLZs gibt :-P)...

unskilled schrieb:

class Postleitzahl
{
size_t postleitzahl;
public:
//CTor, ...
//vor allem noch operator >> - damit die vorderen stellen ggf. mit 0en gefüllt werden
};

unskilled schrieb:

meinte btw den operator << ... ist mir nicht aufgefallen, dass es der falsche war ><

Mit Einlesen unter der Annahme, dass alle Zahlen von 1 bis 99999 eine gültige PLZ ergeben:

istream& operator << (istream& in, Postleitzahl &plz)
{
   plz.plz = 0;
   do
   {
      in >> plz.plz;
   } while ((!plz.plz) || (plz.plz > 99999));
   return in;
}

allerdings hätte das ganze nen prob:
wenn man das ganze in ne datei speichert und jmd eine postleitzahl ändert (ungültig macht), dann werden (im besten fall nur) 2 Einträge gemischt.
also würde man die überprüfung wahrscheinlich doch ganz weglassen.
wenn man trotzdem nicht auf die überprüfung verzichten möchte:
(ich weiß nur nicht, ob das hier üblich bzw. elegant ist oder doch eher falsch weil keine sau auf die idee kommt, dass der operator << ne exception werfen darf)

istream& operator << (istream& in, Postleitzahl &plz)
{
   in >> plz.plz;
   if ((!plz.plz) || (plz.plz > 99999))
      throw /*...*/;
   return in;
}

also würde ich dann dazu gehen, die eingabe nur so zu implementieren:

istream& operator << (istream& in, Postleitzahl &plz)
{
   return in >> plz.plz;
}

bool Postleitzahl::good() const
{
  return ((plz) && (plz < 99999));
}

falls es nötig wäre könnte man das ganze auch noch mit plz-tabellen erweitern, die man halt iwo abspeichert evtl cacht oder ne extra klasse zum prüfen macht...

ich weiß nicht, wie man das (in der Praxis) macht, dass personen versch. nationen in das system könnten, aber evtl so:

class BasePLZ
{
public:
  bool bad() const {return !good();}
  virtual bool good() const  {return true;}

  virtual ~BasePLZ() = 0;
};

template <typename T>
class Postleitzahl : public BasePLZ
{
  T plz;
public:
  Postleitzahl(T _plz) : plz(_plz) {}

  virtual T Get() const {return T;}
};

template <typename T>
ostream& operator << (ostream& out, typename const Postleitzahl<T> &plz)
{
  return out << plz.plz;
}

template <typename T>
istream& operator >> (ostream& in, typename Postleitzahl<T> &plz)
{
  return in >> plz.plz;
}

class GerPLZ : public Postleitzahl <size_t>
{
 public:
  GerPLZ(size_t _plz) : Postleitzahl(_plz) {}
};

struct strange_plz
{
  char a[4];
  char b;
  std::string c;
//CTor
}; //was auch immer

//operator << / >>

class StrangeCountryPLZ : public Postleitzahl <strange_plz>
{
 public:
  StrangeCountryPLZ (const strange_plz& _plz) : Postleitzahl(_plz) {}
};

weiß nicht, ob ich hier jz iwo noch fehler drin habe, aber so würde ich es wohl in echt versuchen zu implementieren (nur das Land iwie als enum und dann halt so lang dran rum basteln, bis alles so funktioniert, wie ich es gern verwenden würde)

bb

['OnaseO']

volkard schrieb:

...hab gerde mit size_t experimentiert.
da war auch 01234 != 1234

01234 == Oktalzahl
1234 == Dezimalzahl

[volkard]

unskilled schrieb:

class GerPLZ : public Postleitzahl <size_t>

wichtig ist hier, das ziel nicht aus den augen zu verlieren. ich plädiere dafür, die Postleitzahlenklasse wirklich einfach zu lassen, string oder ganz dummer wrapper um int oder unsigned int (nicht size_t, weil size_t auf 64-bit-compilern auf einmal auf 64 bits aufgezpgen wird.). die verlockung ist groß, jetzt noch lustige sachen einzubauen, weil es auf einmal geht. aber ich würde lieber bescheiden weiterprogrammieren wie zuvor. kann mir nicht wirklich vorstellen, daß die sekretäre mit den features überhaupt umgehen wollen.

[unskilled]

volkard schrieb:

nicht size_t, weil size_t auf 64-bit-compilern auf einmal auf 64 bits aufgezpgen wird.

und wo ist der nachteil?
so lang man nichts binär speichert ist das ja alles np...
aber ja - kannst au unsigned int oder was au immer nehmen

bb