Programmieren

Merke: manchmal hilft Doku lesen erheblich. Ich habe gerade einen halben Tag danach gesucht, wieso eine pipe() zwischen zwei Threads eines Programms nicht funktioniert. Ich habe eine pipe, an deren lesendem Ende ein Thread mittels select() auf Befehle wartet. Dummerweise wollte bei folgendem Code select nicht zurückkehren:

select(1, &fdset, 0, 0, 0)

Irgendwie wollte das partout nicht zurückkehren, obwohl ich das Schreib-Ende des File-Descriptors beschrieben habe… Hm… Nach einigem Suchen habe ich die Doku nochmal genauer gelesen:

nfds is the highest-numbered file descriptor in any of the three sets, plus 1.

Tja, richtig lesen. nfds (der erste Parameter von select) ist nicht die Anzahl der Descriptoren im fd_set, sondern die Nummer des höchsten Descriptors plus eins. Dummerweise ist das Beispiel in der Doku mit fd=0 gemacht, so dass der höchste plus 1 gleich 1 ist (und damit gleich der Anzahl), was mich natürlich auf die völlig falsche Fährte gelockt hat. Naja, ein halber Tag versemmelt, aber wenigstens was bei gelernt. Fast wie Goethe…

Irgendwann vor langer, langer Zeit (laut Versionshistory mittlerweile 5 Jahre her) hatte ich mal als Fingerübung ein Logging-Template in C++ geschrieben, was sich anfühlen sollte wie std::cout. Ziel war den geneigten Programmierer vom Denken zu entlasten und ihm quasi std::cout-Debugging mit etwas mehr Möglichkeiten zu erlauben. Hat offenbar damals schon gut gepasst, kurz darauf kam nämlich die Fähigkeit zur Anpassung an verschiedene Multithread-Umgebungen via Policy-Klasse dazu. Dann lag das ganze erstmal 5 Jahre im Dornröschenschlaf, in denen ich es zwar hin und wieder genutzt habe, aber eigentlich keine neuen Fähigkeiten brauchte. Bis vor kurzem...

Daher jetzt: tada! ein komplett neues Release, in dem sich so einiges geändert hat. Das Frontend an sich bleibt gleich (sprich: existierender Code sollte problemlos weiter kompilieren, es sei denn er macht was total dämliches und verwendet zweimal einen Log-Level in einer Nachricht). Im Hintergrund hat sich allerdings einiges getan. Erstmal wurde der Code etwas aufgeräumt, da sich dort von verschiedenen Experimenten Reste angesammelt hatten. Dann wurde das Handling der Loglevel komplett umgebaut um eine flexiblere Ausgabe nach unten zu ermöglichen. Hintergrund: ich brauche für ein Projekt gerade die Möglichkeit Daten ins Syslog auszugeben. Dazu muss der zugrundeliegende Ausgabestream aber das Log-Level wissen. Außerdem muss er zuverlässig wissen, wann eine Nachricht beendet ist. Beides stellt das Frontend jetzt sicher. Weil's so schön war habe ich gleich noch den passenden SyslogStream beigelegt, der das Loggingfrontend an syslog() anklemmt. Benutzung ist wie üblich relativ einfach:

#include <syslogstream.hxx>

use namespace Logging;

int main(int argc, char *argv[]) {
    SyslogStream slog("TestLogger");
    Syslogger logger(slog, LEVEL_INFO);

    logger << LEVEL_INFO << "This an INFO message which has a number attached: " << 12345 << std::endl;
    logger << LEVEL_WARNING << "This is a warning message." << std::endl;

    return 0;
}

Dieser Code schreibt zwei Nachrichten unter dem Präfix TestLogger ins Syslog. Die Doku der Klassen gibt noch einige Informationen her, welche Eigenschaften man zusätzlich konfigurieren kann. Das Logging-Frontend kann dank std::ostream-Kompatibilität natürlich jedes Element ausgeben, welches auf einem ostream ausgegeben werden könnte.

Der Code ist weiterhin header-only, braucht also keine Installation irgendwelcher Bibliotheken, sondern kann dan public-domain-Lizenz einfach ins eigene Projekt mit übernommen werden. Wer nett sein will: mich interessiert immer, wo der Code verwendet wird. Kurze Mail an mich wäre nett (hm... sollte ich vielleicht mal in die Lizenz schreiben...)

Der Code ist mittlerweile umgezogen und liegt bei Bitbucket: https://bitbucket.org/namenlos/logging/

Nach über drei Jahren hab ich's dank der Anregung eines Kollegen doch mal geschafft, meinen kleinen Parser-Generator in Python aufzuarbeiten und eine neue Version zu veröffentlichen. Diese bringt endlich rekursive Regeln und die Möglichkeit Regeln zu gruppieren. Außerdem sollte sie jetzt auch Python 3 kompatibel sein. Geblieben ist natürlich die einfache Definition von Parsern in Form einer (leicht abgewandelten) EBNF direkt in Python.

Weil Gelaber über Software ohne Beispiel immer doof ist hier ein Beispiel für das Parsen einer einfachen XML-ähnlichen Sprache:

#! /usr/bin/env python
# -*- coding: utf-8 -*-

from yeanpypa import *

test = '<tag><inner attr="Just a test">plah</inner></tag>'

text = Word(alpha)
name = Combine(alpha + ZeroOrMore(alpha | digit))
value = Literal("\"").hide() + Word(alpha | AnyOf(" \t.,!?+-") | digit) + Literal("\"").hide()
attribute = name + Literal('=').hide() + value
opening_tag = Group(Literal('<').hide() + Word(alpha) + ZeroOrMore(attribute) + Literal('>').hide())
closing_tag = Group(Literal('').hide())
tag = Recursive()
tag.set(text | opening_tag + tag + closing_tag)

result = parse(tag, test)
print result.getTokens()

Die Ausgabe ist hierarchische Liste von Token sein (wobei alle, die mit .hide() markiert werden nicht enthalten sind):

[['tag'], [['inner', [['attr', ['Just a test']]]], 'plah', ['inner']], ['tag']]

Mittels semantischer Aktionen die an Teile der Regeln gehängt werden kann man komplexere Datenstrukturen on the fly aufbauen statt erst auf der endgültigen Tokenliste zu arbeiten. Bspw. könnte die Regel tag mittels einer semantischen Aktion ein Objekt einer Klasse Tag anlegen, welches strukturierten Zugriff auf die Bestandteile des Tags gibt. Semantische Aktionen sind Funktionen, die die Tokenliste, welche durch die Regel gematcht wurde als Parameter erhalten und darauf beliebige Aktionen ausführen können. Yeanpypa ist so konstruiert, dass der Rückgabewert einer semantischen Aktion anstelle der Token in das Ergebnis übernommen wird. So kann man hier also statt einer Liste von Token mittels einer semantischen Aktion gleich eine Liste von Tag-Objekten erhalten.

Die Software findet sich mit dem neuen Release auf bitbucket.org. Doku und Beispiele (auf Englisch) finden sich auf meiner snippets-Webseite. Wenn ich Zeit finde werde ich noch ein paar mehr Beispiele implementieren um die Fähigkeiten von yeanpypa umfassender zu demonstrieren.

Letzte Woche waren meine Holde und ich ja im Urlaub und wie das so ist kommt man da ja meist zu den Sachen, für die man sonst nie Zeit hat. Da ich schon seit längerer Zeit mal TDD ausprobieren wollte, war die Zeit also günstig. Herausgekommen ist ein kleines Spielzeug namens StateMachine (kreativere Namensvorschläge werden in den Kommentaren gern entgegengenommen): eine kleine Bibliothek für State Machines in Java. Brauch ich demnächst wahrscheinlich sowieso für verschiedene Dinge, so dass die Zeit nicht vergeudet war.

Fazit der testgetriebenen Entwicklung? Anfangs etwas gewöhnungsbedürftig, weil man den klassischen Entwicklungsprozess (Entwickeln-Testen) quasi rumdreht. Für so Sachen wie die Entwicklung von Bibliotheken ist das allerdings ganz interessant, weil man relativ früh merkt, wenn die Schnittstellen murksig zu benutzen sind. Durch das "auf den grünen Test" hin programmieren hat man auch klar abgesteckte Aufgaben für jeden Entwicklungsschritt. Ich werd das also bei der Library (und auch sonst wo sich's lohnt) durchaus weiter ausprobieren.

Ach ja: bitbucket.org ist richtig angenehm zu benutzen. So angenehm, dass ich zu faul war, den Kram selbst aufzusetzen. Mercurial ist eh geil. Sag ich ja meiner Frau immer, aber die hört ja nicht...

Eclipse ist ja auch gerade wegen der Code Completion die Java-IDE. Blöd nur, wenn die nicht tut. Wenn weder nach Eingabe eines Punktes noch nach Strg+Space die erwartete Vervollständigung kommt, sondern stattdessen in der Statusleiste nur "No completions available" erscheint, dann hat man unter Umständen in den Projekteinstellungen oder in den generellen Einstellungen für den Java-Editor (unter Window->Preferences: Java->Editor->Content Assist->Advanced) die Vervollständigung verkonfiguriert. Im Zweifelsfall einfach in beiden Listen alle Einträge aktivieren (die obere Liste ist das, was im normalen Assitententenpopup hochploppt, die untere das, wo man mit Strg+Space durchschalten kann). Aus irgendeinem Grund war das bei mir verpfriemelt (ich hab ja das JBoss-Plugin in Verdacht, kann ihm aber nix nachweisen *grml*) und ich hatte daher keine Code-Completion mehr. Naja, wieder mal was gelernt und gestandene Eclipser zum Rätseln gebracht.

Wer mal entspannt Webapplikationen entwickeln will/muss, dem sei Pylons ans Herz gelegt. Nettes Framework, noch einige kleinere Ecken, aber schonmal sehr angenehm zum Entwickeln geeignet. Meist liegt hinter einer Webapplikation ja ein entsprechendes Datenmodell in Form einer Datenbank. Um die bequem ansteuern zu können (SQL von Hand zu coden ist mittlerweile definitiv nicht mehr schön) bringt Pylons eine Integration für SQLAlchemy mit. Nun ist SQLAlchemy flexibel und mächtig, dafür aber manchmal etwas komplexer als nötig. Für viele Anwendungsfälle reichen die Möglichkeiten, die Elixir mitbringt (Elixir ist eine auf SQLAlchemy aufsetzende Bibliothek, die einen deklarativen Stil zur Erstellung des Datenmodells ermöglicht). Mit diesem Trio kann man schonmal recht viel Interessantes tun.

Blöd nur, wenn man ein wenig faul bei der Einbindung der verschiedenen Module ist. Dann kann es nämlich dazu kommen, dass plötzlich folgende Fehlermeldung auftritt, wenn man versucht was in der Nutzersession im Pylons zu speichern:

TypeError: 'ScopedSession' object is unsubscriptable

Der Datentyp deutet es an: das session-Objekt von Pylons ist unter diesem Namen nicht verfügbar. Der Fehler ist simpel: im Datenmodell der Applikation stand mal from elixir import * (um Schreibarbeit bei den Elixir-Datentypen zu sparen). Im Controller wiederum wurde das Datenmodell mit from app.model import * importiert. Tja... Elixir definiert dummerweise ein eigenes session-Objekt, welches durch diese Import-Kette in den Namensraum der Applikation gerät und dort dann das eigentliche Pylons-Objekt überschreibt.

Als Lösung bleiben drei Möglichkeiten: man kann den Import im Datenmodell in import elixir ändern und allen Datentypen ein elixir. voransetzen, die benötigten Elixirtypen mittels from elixir import Field, .... im Datenmodell importieren (und dabei keinesfalls session mit reinnehmen) oder in der Applikation das Datenmodell mittels import app.model as m und dann jedem Zugriff auf Elemente des Modells ein m. voranstellen. Danach hat man wieder wie gewünscht Zugriff auf seine Session und kann Daten darin speichern und daraus lesen.

Manchmal kann man sich auch einen Wolf suchen. Ziel war: ein Widget in dem sich mehrere Children befinden (QLineEdit, Checkboxen, QTableView) immer auf die minimal notwendige Größe zu bringen. Das gilt speziell dann, wenn der QTableView unsichtbar wird. Mit etwas um die Ecke denken geht's: widget->setMaximumHeight(0). (Im dem Fall ging es nur um die Höhe). Muss man erstmal drauf kommen...

Update: Unsinn gelöscht. Man schaue sich mal QWidget::adjustSize() an...

Nach zweitägiger Suche: Python und QT können manchmal sehr hässlich zusammenstoßen, wenn es um die Lebensdauer von Objekten geht. Folgender Code:

class MainWindow(QMainWindow):
    [...]
    def initTreeView(self, top_level_cats):
        model = CategoryModel(top_level_cats)
        self.treeview.setModel(model)
    [...]

Sieht an sich erstmal unverdächtig aus: ein Model wird erzeugt (wie auch immer geartet) und dem QTreeView als Model übergeben. Scheint alles wunderbar, bis man es ausführt. Aus irgendeinem Grund bleibt der QTreeView grundsätzlich leer. Es werden zwar von dem Model unter Umständen noch einige Funktionen aufgerufen (in meinem speziellen Fall waren das headerData() und columnCount(). Keine Ahnung, ob das immer so ist), aber die eigentlich Daten werden nie dargestellt. Soweit, so schlecht.

Ein winzig kleine Änderung des Codes bringt die Lösung. Hier fast die gleiche Funktion:

class MainWindow(QMainWindow):
    [...]
    def initTreeView(self, top_level_cats):
        self.model = CategoryModel(top_level_cats)
        self.treeview.setModel(self.model)
    [...]

Der einzige Unterschied: statt einer lokalen Variable ist model nun ein Feld der umgebenden Klasse. Und siehe da: plötzlich funktioniert es. Wie kommt's? (Fast) ganz einfach: man könnte zwar annehmen, dass self.treeview.setModel(...) sich das Model irgendwie speichert, wenn es noch benötigt wird, aber das scheint nicht der Fall zu sein. Anscheinend werden die entsprechenden Aufrufe nur von der dünnen Schicht von PyQt4 an die zugrundeliegende QT-Bibliothek durchgereicht und die entsprechenden Pythonobjekte dann nicht weiter beachtet. Am Ende der Funktion geht das Element im ersten Fall out-of-scope und wird dann irgendwann mal vernichtet. Blöd nur, wenn QT dann bei der Darstellung des Views plötzlich was von dem Model will, dessen Objekt zu dem Zeitpunkt nicht mehr existiert. Weißt man es hingegen einem Feld in der umgebenden Klasse (zum Beispiel dem Fenster) zu, so existiert es so lang, bis dieses vernichtet wird (und damit auch sein View). Dann kann die QT natürlich nach Herzenslust nach den Daten des Views fragen und wird immer auf unserem Model-Objekt landen, wie das gewünscht ist.

Eigentlich logisch. Wenn man's einmal weiß...

Der Titel sagt es schon: es geht um Eclipse Ganymede und Subversion. Beides meiner Meinung fantastische Tools zur Softwareentwicklung, in Kombination allerdings gerade etwas zickig. Das Problem: bei Eclipse Europa (3.3) wurde meist für die Subversion-Integration das Plugin Subclipse verwendet. Für Ganymede (3.4) gibt's das allerdings noch nicht. Dafür gibt es ein neues Plugin direkt im Ganymede-Repository: Subversive. Dieses Plugin soll wohl bald standardmäßig in Eclipse integriert werden. Es ist quasi deckungsgleich mit dem schon bestehenden CVS-Plugin und integriert sich sehr gut in die Oberfläche.

So schick das Plugin ist: mir scheint, die Eclipse-Jungs und -Mädels haben bei der Zusammenstellung von Ganymede gepennt. Dummerweise ist nämlich der eigentliche Team-Provider integriert, die Library zum Zugriff auf die SVN-Repositories allerdings nicht. Die darf man sich zu Fuß nachinstallieren. Dabei darf man sich dann auch noch entscheiden, welche man nimmt. Ich hab mich letztlich für SVNKit entschieden, weil mir die Idee gefällt, allen Kram gleich in Java abzuwickeln, statt externe Libs einbinden zu müssen. Dummerweise begrüßt mich mein Eclipse bei der Installation von SVNKit mit folgenden Zeilen:

Cannot find a solution where both Match[requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.1.I20080612-1500,0.7.1.I20080612-1500]] and Match[requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0)] can be satisfied. Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0) Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.polarion.eclipse.team.svn.connector.feature.group/0.0.0 Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit15.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0) Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit15.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.polarion.eclipse.team.svn.connector.feature.group/0.0.0 Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0)

Ja, diese Fehlermeldung ist auch im Original so unlesbar. Nach längerem Suchen bin ich in einem Blog auf die Lösung gestoßen: Seit 3. August möchte SVNKit eine neuere Version von Subversive haben (oder andersrum, so 100% schlau bin ich noch nicht draus geworden). Die ist dummerweise nicht in den Ganymede-Repositories, sondern muss unter http://download.eclipse.org/technology/subversive/0.7/update-site/ extra bezogen werden. Diese URL packt man in die Update-Site, muss sie dann noch einmalig via "Manage Sites..." aktivieren und schon kann man sich ein neueres Subversive installieren, was dann auch mit SVNKit spielen mag. Schade, dass die Standardintegration in Ganymede so kaputt ist. Bis zum Nachfolger dauert es ja doch ein wenig und bis dahin sind wahrscheinlich schon einige an Subversion und Eclipse verzweifelt und benutzen glatt wieder CVS *brrrr*...

Update: Wie Deka in den Kommentaren angemerkt hat scheint es mit Subclipse 1.4 wohl doch einen Release für Ganymede zu geben.

Installiert man Pylons nach Anleitung mittels easy_install auf einem Ubuntu Feisty Fawn, dann bricht der Compilerlauf von Cheetah (welches als Abhängigkeit mit installiert wird) unter Umständen irgendwann mit folgender Meldung ab:

src/_namemapper.c:15:58: error: Python.h: No such file or directory

Das liegt daran, daß die passenden Headerfiles nicht in /usr/include/ liegen, sondern in /usr/include/python2.5 (bspw.), wo sie natürlich vom Compiler erstmal nicht gefunden werden. Ein

CFLAGS='-I/usr/include/python2.5' easy_install Pylons

behebt das Problem.

Grad von Achim geschickt bekommen: Random Number. Wer's nicht versteht: macht nix. Ich find's lustig. :)

Ich hatte mal wieder etwas Langeweile und wollte ein wenig mehr Python lernen. Also hab ich mich mal damit beschäftigt, wie das mit Parsing in Python so aussieht. Ich bin ja in C++ von boost::Spirit recht angetan und hab sowas ähnliches für Python gesucht. Das, was dem noch am nächsten kommt, ist pyparsing. Leider hat dieses einen gravierenden (aus meiner Sicht) Nachteil: es scheint nicht möglich zu sein, den Parser dazu zu bringen, Whitespaces NICHT zu ignorieren. Dummerweise brauchte ich das aber für die selbstgestellte Aufgabe an einigen Stellen...

Wie der geneigte Informatiker dann so ist, schreibt er sich den Kram halt selbst und lernt noch was dabei. Rausgekommen ist yeanpypa (bevor einer fragt: YEt ANother PYthon PArser framework. Hat da wer gelacht?!), ein kleines Framework, mit dem sich eine EBNF-Grammatik fast 1:1 in Python-Code übertragen läßt. Die Schnittstelle ist zum Teil bei pyparsing und zum Teil bei boost::Spirit abgeschaut. Das ganze dürfte noch einige Fehler haben, aber erscheint mir bisher schon ganz brauchbar. Der Code steht wieder mal unter einer public domain Lizenz, kann also vollkommen frei verwendet werden. Natürlich freue ich mich über eine kurze Nachricht, wenn jemand damit irgendwas tut.

So, zuguterletzt noch die passenden Links:
Download (yeanpypa.py runterladen)
Einführende Doku (Englisch). Leider alles andere als vollständig. Vielleicht irgendwann mehr...
Vollständige API-Doku. Generiert mit Epydoc.

Nachdem ich heute seit langer Zeit mal wieder im Blog von Andreas Bogk gestöbert hab, bin ich über ein sehr interessantes Paper von ihm und Hannes Mehnert zum Thema "Secure Networking" gestolpert. Grob gesagt isses zwar (natürlich) wieder eins der Dylan-Propagandapaper (er mag die Sprache halt wirklich), aber dieses ist echt sehr nett. Ich hoffe doch, daß das Framework, was sie da vorstellen, sich weiterentwickelt.

Die letzten drei Tage hab ich einen Fehler aus der Kategorie "In den Fuß schießen mit C++" gesucht. Da gibt man sich nun schon alle Mühe, verwendet die gut getesteten Datenstrukturen der STL und trotzdem grinst einen ein ums andere Mal ein Segmentation Fault an. *gnaa*

Folgender Code (vereinfacht, das Original ist in eine Klasse eingebettet):

#include <iostream>
#include <list>

std::list<int> bla;

std::list<int> const getBla() {
        return bla;
}

int main() {
        bla.push_back(10);
        for (std::list<int>::const_iterator i=getBla().begin(); i!=getBla().end(); ++i) {
                std::cerr << *i << std::endl;
        }
}

getBla() ist im Original ein Getter für ein Klassenmember. Eigentlich ein gängiges Konstrukt. Der Crash passiert in der Schleife bei der Dereferenzierung des Iterators i. (Im Original war das etwas komplizierter, aber das ist hier nebensächlich.). Nach einigem Rumprobieren stelle ich fest, daß die Schleife zweimal durchlaufen wird, obwohl bla ja eigentlich nur ein Element enthält. Die Dereferenzierung des Iterators knallt im zweiten Durchlauf der Schleife (logisch, der zeigt dann ja irgendwo ins Nirvana).

Die Ursache des Fehlers liegt in einem fehlenden Zeichen in der Deklaration von getBla(). Eigentlich müßte das wie folgt aussehen (der Unterschied ist der Einfachheit halber rot markiert):

[...]
std::list<int> const &getBla() {
[...]

Standardmäßig übergibt C++ Parameter und Rückgabewerte by value, d.h. es wird eine Kopie des Wertes auf dem Stack gemacht. Das ganze ist von C geerbt. Mit der Einführung von abstrakten Datentypen kann so eine Kopie natürlich richtig teuer werden, weswegen zusätzlich die Möglichkeit der Übergabe by reference eingeführt wurde. Gekennzeichnet wird solch eine Referenz durch ein & hinter dem Datentyp. Dann wird eben statt der Kopie nur ein Verweis übergeben. Kann ungeheuer Zeit und Speicherplatz sparen.

Wie führt das nun in dem Code zum Crash? Nun dafür muss man sich mal den Kopf der for-Schleife näher anschauen:

[...]
        for (std::list<int>::const_iterator i=getBla().begin(); i!=getBla().end(); ++i) {
[...]

Im rot markierten Teil wird der Iterator i initialisiert und zeigt auf das erste Element der von getBla() zurückgelieferten Liste – einer Kopie der Originalliste, die durch die Rückgabe angefertigt wird. Im blau markierten Teil wird der Iterator vor jedem Schleifendurchlauf mit dem Endezeiger der von getBla() zurückgelieferten Liste verglichen – einer anderen Kopie, die ebenfalls wieder durch die Rückgabe by value entsteht. Nun, da der Iterator ursprünglich von der ersten Kopie an hochzählt, kann er nie den Endezeiger der zweiten erreichen, der komplett woanders liegt. Also bricht die Schleife nicht ab, wie es korrekt wäre, sondern läuft ein zweites mal durch. Durch das Hochzählen zeigt der Iterator nun hinter das Ende der ersten Kopie, per Definition also ins Nichts. *BUMM*

Ändert man den Rückgabetype von getBla() auf eine Referenz, so bekommt man bei jedem Aufruf dieselbe Liste (nämlich bla selbst). Und siehe da, dann funktioniert's! Also merke: Der Rückgabewert eines Getters ist grundsätzlich eine konstante Referenz!*grmpf* (Konstant übrigens deswegen, damit einem nicht irgendein Genie plötzlich die eigenen Daten unterm Hintern wegändert.)

Ein besonders schönes Stück Dokumentation aus einem Codestück, an dem ich gerade sitze:

/*---------------------------------------------------------------------------*/
/*     FUNCTION: <function>
 */
/*!    @brief    <short>
 *
 *               <detailed>
 *
 *     @param    <parmetername> [IN:|OUT:|INOUT:] <description> [range: x .. y] 
 *     @param    <parmetername> [IN:|OUT:|INOUT:] <description> [range: x .. y]
 *     @returns  <description>
 * 
 *     @pre      <contractual>
 *     @post     <contractual>
 *
 *     @warning  <warning>
 *     @todo     <features>
 *//*------------------------------------------------------------------------*/

Nein, er ist übrigens nicht von uns.