Seite 1 von 1

Die Suche nach mehr Eleganz ;)

Verfasst: Do Nov 17, 2011 10:02 pm
von Bebu
Huhu, ich suche eine elegante Lösung folgende Zeile zu umgehen und den "bösen" Cast los zu werden:

Code: Alles auswählen

 if( sqlite3_column_text( stmt, i ) ) 
        value = reinterpret_cast<const char*>( sqlite3_column_text( stmt, i ) );
Value ist ein std::string und sqlite3_column_text gibt einen const unsigned char* zurück. Jemand eine Idee?

Re: Die Suche nach mehr Eleganz ;)

Verfasst: Do Nov 17, 2011 10:14 pm
von fat-lobyte
warum musst du da einen reinterpret_cast<> machen? unsigned char in in char sollte doch konvertierbar sein, also sollte ein static_cast<> oder sehe ich da was falsch?
Außerdem hast du meiner Meinung das Wort "bösen" zurecht in Klammern gesetzt. Obwohl einige hier "sehr kritisch" zu casts stehen, finde ich das nicht so schlimm.

Re: Die Suche nach mehr Eleganz ;)

Verfasst: Do Nov 17, 2011 10:23 pm
von Bebu
Den Static Cast verweigert der Compiler als invalid. Ich weiß jetzt nicht, wer von euch beiden einen Knick in der Optik hat ;)

Re: Die Suche nach mehr Eleganz ;)

Verfasst: Fr Nov 18, 2011 1:20 pm
von Xin
Bösen steht zu unrecht in Anführungszeichen, gerade reinterpret_cast ist heftig und sollte nach Möglichkeit nicht verwendet werden.

Weil reinterpret_cast die Zensur irgendwelcher Bedenken von Seiten des Compilers ist, steht da aber auch reinterpret_cast und nicht etwa (char const *)sqlite3_column_text( stmt, i ) und wenn es notwendig ist, gibt es keine Möglichkeit es nicht zu verwenden, ohne es zu verschleiern.
Also richtig gemacht.

Auch darf man mal sagen, dass SQLite hier eigentlich richtig liegt, da negative ASCII-Zeichen keinen Sinn ergeben. Dass Texte in C (char *) sind und nicht (unsigned char *) hat historische Gründe (anderes Wort für Faulheit). Meine String-Klasse funktionierte früher auch mit (unsigned char *). Ich musste aber erkennen, dass etwas richtig zu machen in einem Umfeld, dass das anders sieht, nicht dazu führt, dass der Code richtiger wird.
Hier hätte SQLite also vielleicht auch den Kompromiss eingehen können. Da dem nicht so ist, musst Du casten und machst mit reinterpret_cast ja auch deutlich darauf aufmerksam.

Re: Die Suche nach mehr Eleganz ;)

Verfasst: Fr Nov 18, 2011 10:34 pm
von Bebu
Okay, dann lassen wir es so. Hier die nächste Suche:

Code: Alles auswählen

 inline 
  std::istream& operator>>( std::istream& is, Dedupe::FileInfo::FileType &FT )
  {
    unsigned int Type = 0;
    if( is >> Type ) FT = static_cast<Dedupe::FileInfo::FileType>( Type );
    return is;
  }
Wie gesagt, das Problem bei Sqlite ist, das die nativen Formate sehr eingeschränkt sind und es sich am einfachsten mit Strings arbeiten lässt, um solche Probleme zu vermeiden. Ich benutze einen Stringstream zum übersetzen und brauche daher einen Ausleseoperator für ein Enum. Das da oben habe ich beim Googleln gefunden, aber ich find es nicht schön...

Re: Die Suche nach mehr Eleganz ;)

Verfasst: Sa Nov 19, 2011 12:26 pm
von Xin
Bebu hat geschrieben:Okay, dann lassen wir es so. Hier die nächste Suche:

Code: Alles auswählen

 inline 
  std::istream& operator>>( std::istream& is, Dedupe::FileInfo::FileType &FT )
  {
    unsigned int Type = 0;
    if( is >> Type ) FT = static_cast<Dedupe::FileInfo::FileType>( Type );
    return is;
  }
Wie gesagt, das Problem bei Sqlite ist, das die nativen Formate sehr eingeschränkt sind und es sich am einfachsten mit Strings arbeiten lässt, um solche Probleme zu vermeiden. Ich benutze einen Stringstream zum übersetzen und brauche daher einen Ausleseoperator für ein Enum. Das da oben habe ich beim Googleln gefunden, aber ich find es nicht schön...
Schön ist das wirklich nicht.

Ich hoffe, Du kapselst das alles in einer entsprechenden Kasse. Der operator >> ist global (sollte er jedenfalls sein) und derartige Tricks würde ich eher als Methode einer entsprechenden Wrapper-Klasse sehen, schon alleine um stärker zu verdeutlichen, was da abgeht und um den Unterbau leichter austauschen zu können.

Re: Die Suche nach mehr Eleganz ;)

Verfasst: Sa Nov 19, 2011 10:28 pm
von Bebu
Ok, ich versuche mir mal im Hinterkopf einen Vermerk zu machen. Derzeit wird es so bleiben und durch eine schönere Lösung ersetzt, sobald die erste "heiße" Phase beendet ist. Langsam hätte ich schon Lust auch mal so was wie ein funktionierendes Programm zu sehen. Um damit anfangen zu können, brauche ich nur noch eine funktionierende Datenhaltung und eine Möglichkeit mit dem Nutzer zu interagieren während das Programm schon läuft. Das ist überschaubar und ich will mich nicht mehr mit solchen Details aufhalten. Das Projekt läuft jetzt lange genug, um auch mal so was wie ein Ergebnis zu liefern...
Als Wrapperklasse dafür: Ja, aber nicht jetzt.