Hallo, On Sat, 08 Feb 2003, Michael Matz wrote:
On Fri, 7 Feb 2003, David Haller wrote:
Naja, ich denke, zusammen haben wir alle Klarheiten beseitigt ;)
Recht so. ;)
*g*
PS: ist hier eigentlich grauslicher Code aus irgendwelcher SW OnTopic?
Klar. Zumindest ich lache gern ;)
ostream& operator<<(ostream& o, someclass& c) { o << c.foo << endl; }
Ui. Da fehlt mindestens das "return o".
Bingo.
string itoa (int val,int length) { char *car = new char[length+1]; for(int i=0; i
Mich schaudert. mem-leak, unnoetige 0-Setzung,
und v.a. so effizient, nicht?
grauenvolle sprintf() Verwendung. Und dieser cast... Ugh.
Was glaube ich weiss sogar, was das '%*2$d' sein soll... Was sagt ein gcc/g++ 3.x dazu?
Eigentlich nichts, nur ne Warnung ueber das "*2$" Konstrukt, die aber falsch ist.
Ist das '*2$' denn "legal"? Ich verstehe das so, dass dort "length" als Laengen-format ins "%0...d" eingebaut werden soll. Und zumindest mein gcc-2.95.2 + pgcc-2.95.3-patch + pgcc-2.95.3-athlon-patch faengt damit nix an ("invalid format specifier" oder so)... Und der Compiler hat sich bei mir IMO bewaehrt. U.a. hab ich meine Kernels seit ca. 2 Jahren damit kompiliert -- und die laufen "rock-stable"[1]... Ich hatte nicht einen kernelbedingten Haenger.
char c[length+1];
Aber Vorsicht. Diese variable-sized-arrays sind nicht ISO-C++.
Oh. Hm. Waere 'char * c = xmalloc(..); string s = string(c); free(c); return s;' besser/ok? Bin mir grad nicht sicher, ob das klappt (und zu muede um das noch testen zu wollen bzw. ich kenne C++ zu wenig um das verhalten des 'string s = string(c)' genau zu wissen)...
snprintf(c, length, "%i", val); return string(c);
Aber abgesehen davon scheint dieser "Quickhack" ja immerhin besser als das Original zu sein ;-) Naja, die Funktion wird nur an einer anderen Stelle deklariert (statt einen Header einzubinden!), aber nicht verwendet... Das hab ich aber erst rausgefunden, nachdem ich obiges schon hatte ;) Gedacht sind meine Aenderungen eh nur "fuer mich", mir reicht's also, wenn mein gcc das schluckt ;) Ich selbst wuerde einen int2string in C++ sowieso anders machen (hab ich auch schonmal[3] ;), wohl via str(ing)stream... Oder direkt in C nach K&R, was ich eh schon als "itoa.c" rumliegen habe. Fuer C++ waere das dann 'return string(itoa(i));' :)
==== inline CInitializedDouble operator=(const CInitializedDouble& in) {mDouble=(in.mDouble);}; };
Sieht aus, wie irgendwie automatisch erzeugter code.
Kann sein.
Wer wuerde denn sonst "{a=b;};" schreiben, anstatt "a=b;".
Ups, das war ein C&P Fehler von mir. Das zweite '};' ist das von 'class { };'. An der Stelle ist das {}; zwingend. Das ist aus nem Headerfile: ==== class CInitializedDouble{ /* ... */ inline CInitializedDouble operator=(const CInitializedDouble& in) {mDouble=(in.mDouble);} }; ==== Worauf ich hinauswollte, bzw. wo ich den Fehler sehe, ist dass es wiederum kein return gibt (was g++ auch bemaengelt). Mein Fix ist ein ==== inline CInitializedDouble& operator=(const CInitializedDouble& in) {mDouble=(in.mDouble); return *this;}; ==== Aber die ganze Klasse ist eh Schwachfug: ==== /** A class of doubles which are initialized with a zero (unnecessary, it seems) */ ==== Tja. Wenn man seine doubles (Variablen allgemein) generell initialisieren wuerde, dann braeuchte man so eine Murks erst gar nicht... Schlamperei/Faulheit durch Murks ausbessern... "Interessant"... Wie erwaehnt, der Code ist, aehm, abenteuerlich (und ein paar Fehler kamen mir recht bekannt vor, von '0.1.6pre3'[2])... Mich wundert, dass das Teil ueberhaupt zu laufen scheint, die muessen da mit sehr toleranten Compilern (und ohne jede Warning-Optionen) arbeiten... Ah, meine Version von vorhin laeuft noch nicht -- muss mal den Perl-Einbau weglassen: ==== libGIFTAcInvertedFile.so contains a sane GIFT Accessor plugin: inverted_file /opt/GIFT-0.1.9/lib/libGIFTAcPerl.so.0: undefined symbol: libGIFTAcPerl_getClassName Could not open library: /opt/GIFT-0.1.9/lib/libGIFTAcDistanceMatrix.so: undefined symbol: __ti10CAcURL2FTS Aborted (core dumped) ==== *hrumpf* Da fehlt wohl ein -llibAcURL2FTS irgendwo... Wer sich's (auch) antun moechte: ftp://ftp.gnu.org/gnu/gift/gift-0.1.9.tar.gz http://www.mrml.net http://viper.unige.ch/demo/php/demo.php Apropos: "MRML", der XML-Dialekt der von GIFT verwendet wird, ist IMO auch "interessant"... ==== <algorithm algorithm-id="sub4" algorithm-type="sub4" algorithm-name="sub4" cui-block-color-histogram="yes" cui-block-color-blocks="yes" cui-block-texture-histogram="yes" cui-base-type="inverted_file" /> ==== Achso, warum die ganze Muehe? Naja, GIFT versucht u.a. Bilder anhand von Aehnlichkeiten zu finden... Klasse Idee eigentlich (und wurde in der c't schon beschrieben) und die Algorithmen sind wohl auch recht gut, theoretisch kann man damit eine geniale Bilddatenbank implementieren -- nur die Umsetzung... *seufz* -dnh [1] hatte Glueck mit den Kernelversionen: zuerst 2.4.0-test1 und -test4, dann gut 1 Jahr spaeter als naechsten 2.4.16... :) [2] die spaetestens vom 6.3.02 ist. Nein, ich hab da keine "Bugreports" gemacht... Zu konfus... [3] will's aber grad nicht raussuchen, ist lange her... -- "Wir werden knapp aber deutlich vor der SPD liegen" -- Ede Stoiber, 21.09.02 Ja watten nu? Knapp _oder_ deutlich? -- ich dazu