state.h
- Bebu
- Beiträge: 562
- Registriert: Mi Okt 21, 2009 6:19 pm
- Wohnort: In der Nähe von Salzburg - Bin aber kein Österreicher!
state.h
Wer sich das Filesearch-Modul schon ein bisschen genauer angesehen hat, ist dort auf einen Header namens state.h gestoßen. Er steht absichtlich nur in Namespace Dedupe und war dafür gedacht, alle Rückgabekonstanten für Funktionen usw. zentral zu sammeln und zu dokumentieren. Spricht aus euerer Sicht etwas dagegen? Wenn nicht, sollten wir diesen Header aus dem Filesearch Modul herauslösen und z. B. einen weiteren Ordner für Dateien erstellen, der von allen Modulen benutzt werden kann und auch soll. Mir fällt nur kein passender Name dafür ein. Was haltet ihr davon?
Wer immer nach dem Unerreichbaren jagt, der wird irgendwann auf die Schnauze fallen!
- Xin
- nur zu Besuch hier
- Beiträge: 8861
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: state.h
Hi, den Thread habe ich gerade erst gesehen.
Der Nachteil ist, dass man mehr Dateien offen halten muss, der Vorteil, dass man sich sicher sein kann, dass es definitiv eine Datei gibt und man seine Datenstruktur nicht in einer Auswahl von Dateien suchen muss.
Was mir mehr zu denken gibt, ist dass State eine ganze Reihe von unterschiedlichen Typen in einem enum zu versammeln scheint. Was machst Du, wenn Dein interner Statuscode für den Thread statt 'is_running' mal 'file_ok' meldet? Eine Enum, die nur IsRunning, IsSleeping und IsReseted annehmen kann, kann nur diese Werte liefern. Es macht hier also auch keinen Sinn, sich darüber Gedanken zu machen, was passiert, falls file_ok kommen könnte. File_Ok wird einfach nicht kommen. Um das sicher zu stellen, braucht man Datentypen, die das unterscheiden.
State ist aber in der aktuellen Fassung kein Datentyp, sondern eine Sammlung von Magic-Numbers.
Grundsätzlich ist die Idee in Ordnung, dennoch tendiere ich eher dazu, einer solchen enum einen eigenen Header zu geben.Bebu hat geschrieben:Wer sich das Filesearch-Modul schon ein bisschen genauer angesehen hat, ist dort auf einen Header namens state.h gestoßen. Er steht absichtlich nur in Namespace Dedupe und war dafür gedacht, alle Rückgabekonstanten für Funktionen usw. zentral zu sammeln und zu dokumentieren. Spricht aus euerer Sicht etwas dagegen? Wenn nicht, sollten wir diesen Header aus dem Filesearch Modul herauslösen und z. B. einen weiteren Ordner für Dateien erstellen, der von allen Modulen benutzt werden kann und auch soll. Mir fällt nur kein passender Name dafür ein. Was haltet ihr davon?
Der Nachteil ist, dass man mehr Dateien offen halten muss, der Vorteil, dass man sich sicher sein kann, dass es definitiv eine Datei gibt und man seine Datenstruktur nicht in einer Auswahl von Dateien suchen muss.
Was mir mehr zu denken gibt, ist dass State eine ganze Reihe von unterschiedlichen Typen in einem enum zu versammeln scheint. Was machst Du, wenn Dein interner Statuscode für den Thread statt 'is_running' mal 'file_ok' meldet? Eine Enum, die nur IsRunning, IsSleeping und IsReseted annehmen kann, kann nur diese Werte liefern. Es macht hier also auch keinen Sinn, sich darüber Gedanken zu machen, was passiert, falls file_ok kommen könnte. File_Ok wird einfach nicht kommen. Um das sicher zu stellen, braucht man Datentypen, die das unterscheiden.
State ist aber in der aktuellen Fassung kein Datentyp, sondern eine Sammlung von Magic-Numbers.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
- Bebu
- Beiträge: 562
- Registriert: Mi Okt 21, 2009 6:19 pm
- Wohnort: In der Nähe von Salzburg - Bin aber kein Österreicher!
Re: state.h
Darüber habe ich mir bisher nicht so viele Gedanken gemacht. Ich würde es halt einfach als Benutzer der Klasse ziemlich lästig finden, wenn Konstanten die in einem Klasseninterface liegen, aus drei verschiedenen Namensräumen kommen.Xin hat geschrieben: Was mir mehr zu denken gibt, ist dass State eine ganze Reihe von unterschiedlichen Typen in einem enum zu versammeln scheint. Was machst Du, wenn Dein interner Statuscode für den Thread statt 'is_running' mal 'file_ok' meldet? Eine Enum, die nur IsRunning, IsSleeping und IsReseted annehmen kann, kann nur diese Werte liefern. Es macht hier also auch keinen Sinn, sich darüber Gedanken zu machen, was passiert, falls file_ok kommen könnte. File_Ok wird einfach nicht kommen. Um das sicher zu stellen, braucht man Datentypen, die das unterscheiden.
State ist aber in der aktuellen Fassung kein Datentyp, sondern eine Sammlung von Magic-Numbers.
Wer immer nach dem Unerreichbaren jagt, der wird irgendwann auf die Schnauze fallen!
- fat-lobyte
- Beiträge: 1398
- Registriert: Sa Jul 05, 2008 12:23 pm
- Wohnort: ::1
- Kontaktdaten:
Re: state.h
Ich muss sagen, ich sehe das wie Xin. Was hat sleep mit could_not_use_file zu tun??Bebu hat geschrieben:Darüber habe ich mir bisher nicht so viele Gedanken gemacht. Ich würde es halt einfach als Benutzer der Klasse ziemlich lästig finden, wenn Konstanten die in einem Klasseninterface liegen, aus drei verschiedenen Namensräumen kommen.
Vielleicht ist das auch ein bisschen einstellungssache. Siehst du das Arbeiten mit namespaces als Bürde an? Ist es dir nur lästig immer den Namespaceamen davorzuschreiben? Ich sehe das beispielsweise nicht so. Ich will wissen wo die komischen Variablen und Konstanten herkommen die ich da verwende. Wenn da nichts davorsteht hab ich keine Ahnung wo das deklariert ist und wo ich die Doku dazu suchen soll.
Eine kleinigkeit:
Die Member deines Enums sind klein geschrieben: z.B.: could_not_use_file
Eigentlich sind das stinknormale integer konstanten, ich persönlich verwende dafür Großbuchstaben, unser Codestil schreibt was anderes vor: http://www.proggen.org/doku.php?id=proj ... mbolenamen
Haters gonna hate, potatoes gonna potate.
- cloidnerux
- Moderator
- Beiträge: 3123
- Registriert: Fr Sep 26, 2008 4:37 pm
- Wohnort: Ram (Gibts wirklich)
Re: state.h
Wieso nicht etwas OOP und die Rückgabewerte in eine Klasse Wrappen, die dann einmal einen Text und einmal vlt nur ein Integer als Staus hat, und dann überall abgelesen wird.
Könnte man dann eine Basisklasse "Result" anlegen, die vorschreibt das es die Memeber "Message" und "Value" hat und man dann nur noch ableitet, sodass z.B innerhalb des Filesearch-Moduls ein Spezialisiertes FileSearchResult gibt, das bei Fehlern einfach als Basisklasse weitergeleitet wird?
Könnte man dann eine Basisklasse "Result" anlegen, die vorschreibt das es die Memeber "Message" und "Value" hat und man dann nur noch ableitet, sodass z.B innerhalb des Filesearch-Moduls ein Spezialisiertes FileSearchResult gibt, das bei Fehlern einfach als Basisklasse weitergeleitet wird?
Redundanz macht wiederholen unnötig.
quod erat expectandum
quod erat expectandum
- Xin
- nur zu Besuch hier
- Beiträge: 8861
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: state.h
Der String wird vermutlich eher selten verwendet.cloidnerux hat geschrieben:Wieso nicht etwas OOP und die Rückgabewerte in eine Klasse Wrappen, die dann einmal einen Text und einmal vlt nur ein Integer als Staus hat, und dann überall abgelesen wird.
Könnte man dann eine Basisklasse "Result" anlegen, die vorschreibt das es die Memeber "Message" und "Value" hat und man dann nur noch ableitet, sodass z.B innerhalb des Filesearch-Moduls ein Spezialisiertes FileSearchResult gibt, das bei Fehlern einfach als Basisklasse weitergeleitet wird?
Ansonsten wäre das ein Objekt... Enums mit Objekte mache ich recht häufig wie folgt:
Code: Alles auswählen
.h
class Primitiv
{
private:
unsigned int Exponent;
unsigned int Mantisse;
Primitiv( unsigned int exponent, unsigned int mantisse ) : ... {}
public:
static Primitiv const Char, Short, Int, Long, Float, Double;
};
.cpp:
Primitiv const Char( 0, 8 );
Primitiv const Short( 0, 16 );
Primitiv const Int( 0, 32 );
Primitiv const Long( 0, 64 );
Primitiv const Int( 8, 23 );
Primitiv const Long( 10, 53 );
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
- Bebu
- Beiträge: 562
- Registriert: Mi Okt 21, 2009 6:19 pm
- Wohnort: In der Nähe von Salzburg - Bin aber kein Österreicher!
Re: state.h
So ich habe gerade eine neue Version von state.h hochgeladen. Sagt mir mal, was ihr davon haltet. Wenn es so gefällt, ändere ich es in meinen Klassen ab, damit das ganze wieder kompiliert.
PS: Offtopic--> Soll ich jetzt die Klasse File auf Filesearch umbenennen oder nicht?
PS: Offtopic--> Soll ich jetzt die Klasse File auf Filesearch umbenennen oder nicht?
Wer immer nach dem Unerreichbaren jagt, der wird irgendwann auf die Schnauze fallen!
- fat-lobyte
- Beiträge: 1398
- Registriert: Sa Jul 05, 2008 12:23 pm
- Wohnort: ::1
- Kontaktdaten:
Re: state.h
Ähm, ich glaube solche änderungen hätten dazugehört. Man hat immer die möglichkeit einen ganzen commit rückgängig zu machen wenns sein muss.Bebu hat geschrieben:So ich habe gerade eine neue Version von state.h hochgeladen. Sagt mir mal, was ihr davon haltet. Wenn es so gefällt, ändere ich es in meinen Klassen ab, damit das ganze wieder kompiliert.
Das musst du entscheiden. Repräsentiert die Klasse "eine Datei" oder "eine Dateisuche"? Hast du die antwort auf diese Frage, hast du auch die Antwort auf deineBebu hat geschrieben:PS: Offtopic--> Soll ich jetzt die Klasse File auf Filesearch umbenennen oder nicht?
Haters gonna hate, potatoes gonna potate.