View Single Post
Old 09-06-2013, 05:03 PM   #5
jtt
Connoisseur
jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.jtt composes epic poetry in binary.
 
Posts: 97
Karma: 90350
Join Date: Aug 2013
Location: Berlin, Germany
Device: PB 622, PB 623
Hallo Martin,

Quote:
Ja, das stimmt. Habe ich auch festgestellt. Bei nicht existierendem Fontnamen sucht Openfont wohl selbst einen Default-Font. Ob es aber wirklich niemals NULL zurückgibt, ist nicht erwiesen...
Ja, endgültige Aussagen kann man durch Raten leider nie hinkriegen;-)

Quote:
Irgendwie erinnere ich mich, dass wegen falschem Umgang mit Fonts ich erst viele Abstürze hatte. Hier ein entsprechender Kommentar aus meinem PBChord-Programm:

Code:
//ifont *vorher = GetFont();   //I wanted to save actual font during examining width
			//But storing the result of GetFont() crashes on real device (not in Emulator)
Versuche also niemals, den Rückgabewert von GetFont abzuspeichern! Das Gibt sofortigen Absturz auf PB903/603 aber nicht auf dem Emulator...
Das wundert mich eigentlich nicht so sehr, ein so zurückgegebener Pointer ist in aller Regel nur solange gültig, bis die Funktion das nächste Mal aufgerufen wird. Wenn man die Informationen, auf die ein solcher Pointer zeigt, später noch braucht, muss man immer eine "deep copy" machen. Dass sich das Verhalten auf dem Gerät und dem Emulator unterscheidet könnte an unterschiedlichen memory allocation Strategien liegen sofern der Pointer nicht z.B. auf eine als in der GetFont() Funktion als static definierte structure zeigt (in dem Fall würde ich dann aber eher erwarten, dass die Verwendung eines "alten" Pointers nicht zu Abstürzen führt, sondern nur zu scheinbar unsinnigen Inhalten).

Quote:
Den gibt es schon. Ich habe ihn bei PBChord benutzt. Er stammt aus der PBTK-Bibliothek, die der Autor von "Pi", dem Texteditor zur Verfügung gestellt hat. Es hat mich zwar einige graue Haare gekostet, die "from source" zu builden, da er Smart-Pointer aus der Boost-Bibliothek verwendet - aber sie lief dann doch irgendwann.
Vielen Dank für den Hinweis, ich werde mal versuchen das zu finden.

Quote:
Es ist aber wohl als char * deklariert:

Code:
typedef struct imenu_s {

	short type;
	short index;
	char *text;
	struct imenu_s *submenu;
} imenu;
Das war ja gerade meine Kritik daran, ich würde da gerne einen 'char const *' für das 'text' Feld haben;-)

Quote:
Im PBTK nutzt der Autor es folgendermaßen:

Code:
std::vector<std::string>::iterator it=items.begin();
    for(int i=0;i<(int)items.size();++i,++it){
      menu[ms-i-1].type=ITEM_ACTIVE;
      menu[ms-i-1].index=i;
      menu[ms-i-1].text=(char*)it->c_str();
    }
Klar, die const-ness weg-casten kann man immer (und ich habe das auch erst mal so gemacht in der Hoffnung, dass das 'const' da nur vergessen wurde). Aber ein const Pointer beinhaltet ja das Versprechen, dass das, was auch immmer den string kriegt, dessen Inhalt nicht zu ändern versuchen wird. Aber wenn ich mich nicht darauf verlassen kann ist das Weg-casten der const-ness ein Vabanque-Spiel - wenn die Funktion den nicht als const gekennzeichneten String tatsächlich verändern sollte hat man ein ernsthaftes Problem. In dem obigen Beispiel würde die C++-String ohne deren Wissen geändert, und das führt zu sehr unschönen Effekten (Absturz im besten Falle und unbemerkte Datenkorruption im unangenehmeren - und manchmal wird's auch so aussehen als wäre alles wunderbar). Und wenn man da ein string literal übergibt, dann knallt's entweder oder man hat zumindest undefined behaviour, je nach Plattform...
Etwas mehr Sauberkeit bei der Arbeit wäre schon erfreulich, da es allen Beteiligtem, inklusive den Autoren, auf die Dauer einen Haufen Arbeit und Kopfzerbrechen ersparen kann.

Quote:
Ich meine, das wäre von Sergej's PBSDK
Danke, die kannte ich auch noch nicht!

Quote:
Natürlich. Aber ich glaube kaum, dass wir die jemals bekommen werden
Wirklich schade. Mir ist nicht so ganz einsehbar, warum man sich die Arbeit macht eine Library zu schreiben, die man dann nicht dokumentiert und sie damit zumindest halbwegs unbenutzbar macht. Ich habe selbst schon einige Libraries geschrieben und weiss deshalb natürlich, dass dann auch noch Dokumentation zu schreiben nicht gerade der leckerste Teil der Arbeit ist. Andererseits hat es sich eigentlich immer dadurch bezahlt gemacht, dass ich durch das nochmal gründlich darüber Nachdenken und auch immer mal wieder Nachkontrollieren, was man da eigentlich wirklich zusammengebastelt hat, einiges an Fehlern und sogar Design-Probeme gefunden habe. Na ja...
Vielleicht kann man sie ja dazu bewegen die Sourcen für die Library rauszurücken, dann könnte man sich, ganz unabhängig von der Dokumentation, ein Bild machen (und vielleicht auch sogar zur deren Verbesserung beitragen).

Freundliche Grüße, Jens

Last edited by jtt; 09-06-2013 at 05:08 PM.
jtt is offline   Reply With Quote