3. Schöner Code?

Schöner Code?

  • D

    k1ro schrieb:

    (und das mit den _ hat seinen Sinn)

    wäre ja noch schöner, wenn nicht... und welchen Sinn hat es?

    0
  • K

    http://www.c-plusplus.net/forum/viewtopic.php?t=39461&highlight=underscore
    ganz runter scrollen

    0
  • D

    nur weil's für den Compilerbauer reserviert ist, muss der ja nicht gleich überall sowas machen.

    0
  • K

    @Greenthumb

    ja, ne, is klar,
    nur... ach, lies mal seinen letzten post 😉

    ohha schrieb:

    dass ist aber nicht mein Code sondern STL-Code.

    0
  • N

    ohha schrieb:

    template<class _FI1, class _Pd2, class _Ty, class _Pd1> inline
	_FI1 _Search_n(_FI1 _F1, _FI1 _L1,
...

    Hätte man das nicht evt. anders lösen können (andere Bezeichner?)

    ja, sieht aus wie stl-code. der wird bestimmt maschinell generiert (aus uml-diagrammen oder sowas).

    0
  • D

    k1ro schrieb:

    @Greenthumb

    ja, ne, is klar,
    nur... ach, lies mal seinen letzten post 😉

    ohha schrieb:

    dass ist aber nicht mein Code sondern STL-Code.

    war mir schon klar. mit "muss der ja nicht gleich überall sowas machen", meine ich auch, den Compilerbauer.
    An maschinen-generierten Code glaube ich nicht.

    0
  • K

    aaachso,
    dann hab ich dich falsch verstanden, sry

    0
  • ?

    Theoretisch müssten die STL-Implementierer doch alles, was intern oder lokal ist, nennen dürfen, wie sie wollen? 😕

    Aber ist halt so mehr 1337 h4x0r. 🙄

    0
  • I

    Wie kann man ernsthaft fragen, ob das schöner Code ist? 😕

    0
  • ?

    GAH! Das liest sich wie die Microsoft-STL-Implementierung des VC++ 6.0 - die auch dementsprechend gut (bzw. schlecht) funktionierte.

    Um die Frage zu beantworten: JA! Der Code ist sogar verdammt hässlich. Wenn du ne STL lesen willst, um die Interna zu verstehen, nimm die GNU libstdc++. Oder meinetwegen auch STLPort, obwohl die aus Kompatibilitätsgründen (STLPort will mit allen Compilern laufen) teilweise recht seltsame Präprozessor-Konstruktionen drin haben.

    Wenn ich diesen speziellen Code richtig verstehe, dann sollte das eigentlich so heißen:

    template<typename iterator_t, 
	 typename count_t, 
	 typename content_t, 
	 typename distance_t> 
inline iterator_t _Search_n(iterator_t first, 
			    iterator_t nil, //not in list - direkt hinter dem Ende des Bereichs
			    count_t num,
			    const content_t& val,
			    distance_t *unused) {
  distance_t len = 0;
  _Distance(first, nil, len); //Irgendein Makro. Peusocode: len = last-first;

  for (; len >= num; ++first, --len) {
    iter_t pos = first;
    for (count_t num_found = 0; ; ++pos, ++num_found)
      if (num_found == num)
        return first;
      else if (!(*pos == val))
        break; 
  }

  return nil; 
}

    Das ist ein ziemlich ineffizienter Algorithmus, um einen gegebenen Wert in einer gegebenen Folge n-mal hintereinander zu finden. Ich persönlich hätte es eher so geschrieben:

    template<typename iterator_t,
	 typename count_t,
	 typename content_t>
inline iterator_t search_n(iterator_t first,
			   iterator_t nil,
			   count_t num,
			   content const &val) {
  count_t num_found = 0;

  for(iterator_t pos = first;
      (nil - pos) - num_found >= num; //nil - pos ist Pseudocode, aber da es
      ++pos) {                        //ja scheinbar ne Funktion gibt, die den
    if(*pos == val)                   //Abstand zweier Iteratoren zurück gibt,
      ++num_found;                    //die halt einfach hier einsetzen.
    else
      num_found = 0;

    if(num_found == num)
      return pos;
  }
  return nil;
}

    Das ist zwar nur so hingekladdet, aber ich glaube, dass es laufen sollte.

    0
Anmelden zum Antworten