Improved Console v2.0 Beta
-
Hi,
ich habe mir mal den Spaß gemacht und Marc++us Improved Console eine neue Schnittstelle verpasst.
Also besser gesagt ich habe mir ein wieder verwendbaren Stream-Manipulator geschrieben und den Rest aus Marc++us Code kopiert.
Ich stelle euch erstmal den Manipulator vor.
Wer nicht weiß was Manipulatoren sind kann das hier nachlesen http://cplus.kompf.de/artikel/stream2.html http://cplus.kompf.de/artikel/stream3.htmlalles was ihr machen müsst:
Punkt 1: includet konmanip.h
Punkt 2: leitet von der klasse kon::worker_base eine klasse ab
Punkt 3: überschreibt die virtuellen methoden doit() bzw, doit(std::ostream&) und falls gewünscht undo() (dazu noch später was)
Punkt 4: übergebt einen Instanz von std::auto_ptrkon::worker\_base der auf deine Instanz von den kon::worker_base Derivat zeigt (die Klasse bei Punkt 2) an eine kon::mainpulator Instanz
Punkt 5: schreibt eine Funktion die diesen per value zurück gibtAlso hier ein bsp an einem gotoxy Manipulator
class gotoxy_t : public kon::worker_base // Punkt 2 { public: gotoxy_t(short int x, short int y) : pos_( x, y ) { } virtual void doit() // Punkt 3 { kon::cursor::Pos tmp = kon::cursor::getPosition(); kon::cursor::setPosition( pos_ ); pos_ = tmp; // damit undo den curser an die ursprüngliche Position zurück setzen kann } virtual void undo() // Punkt 3 { kon::cursor::setPosition( pos_ ); } private: kon::cursor::Pos pos_; }; kon::manipulator gotoxy(short int x, short int y) // Punkt 5 { return kon::manipulator( std::auto_ptr<kon::worker_base>( new gotoxy_t( x, y ) ) ); // Punkt 4 }
Wo zu ist der Aufwand gut?
Hier ein paar Bsps.int main() { gotoxy( 10, 10 ); // gotoxy_t::doit() wird aufgerufen cout << gotoxy( 40, 40 ) << "Halöle"; // hier wird zu erst gotoxy_t::doit() aufgerufen // dann gotoxy_t::doit(std::ostream&) // und wenn die Anweisung zu ende ist (ende ist das Semikolon) // dann wird gotoxy_t::undo() aufgerufen // (mit der folge das der Cursor wieder da ist wo er vor der Ausgabe war) }
Wollt ihr ein weiter Bsp?
kon::manipulator xmltagger(const std::string & tag) { // diesmal habe ich das Derivat in der Funktion deklariert // weil außerhalb von der xmltagger Funktion hat sie kein Sinn // das nennt sich lokale klasse class xmltagger_t : public kon::worker_base { public: xmltagger_t(const std::string & tag) : tag_( tag ), os_( NULL ) { } void doit(std::ostream & os) { os_ = &os; *os_ << '<' << tag_ << '>'; } void undo() { if(os_) *os_ << "</" << tag_ << '>'; } private: std::string tag_; std::ostream * os_; }; return kon::manipulator( std::auto_ptr<kon::worker_base>( new xmltagger_t( tag ) ) ); } int main() { std::cout << xmltagger( "foo" ) << "Dieser Text sollte in Tags sein, " << "hoffe ich!"; return 0; }
hier kommt der Quellcode http://home.arcor.de/gerard.choinka/Improve%20Konsole%20v2.0.zip
[ Dieser Beitrag wurde am 26.02.2003 um 19:52 Uhr von Dimah editiert. ]
-
ahja hier ist ein nutzungs bsp
#include <iostream> #include "kontools.h" using namespace kon; using namespace std; int main() { cout << "standard\n"; cout << setcolor( color::red ) << "rot\n"; cout << "standard\n"; setcolor( color::yellow ); cout << gotoxy( 15, cursor::getpos().y ) << "gelb at 15/4"; cout << "gelb at 0/4\n"; setcolor( color::white ); gotoxy( 0, 7 ); cout << "white at 0/7\n"; cout << gotoxy( xdim_size() - 1, 0 ) << setcolor( color::pink ) << '#' << gotoxy( 0, ydim_size() - 1 ) << setcolor( color::green ) << '#'; }
[ Dieser Beitrag wurde am 24.02.2003 um 23:05 Uhr von Dimah editiert. ]
-
Find ich garnicht gut. Ging's nicht noch ein wenig komplizierter.
-
Original erstellt von <Gast>:
Find ich garnicht gut. Ging's nicht noch ein wenig komplizierter.ich hätte vielleicht die drei aufgaben nicht in einen manipulator vereinen sollen, aber das benutzen des manipulator ist doch easy?
[ Dieser Beitrag wurde am 22.02.2003 um 15:02 Uhr von Dimah editiert. ]
-
@Dimah: Ist zwar sehr gut gelungen, aber leider trifft es nicht den Kern der User. Die meisten sind absolute C++-Anfänger die einfach ein bisschen Farbe ins Spiel bringen wollen, die verstehen eben eher weniger von Klassen, Manipulatoren, etc.
Die Idee mit den Manipulatoren ist zwar nicht schlecht, allerdings für die meisten nicht ganz verständlich und etwas zu groß ;).
MfG SideWinder
-
jau genau meine Meinung. Die meisten die mit der Konsole arbeiten und solche Spielchen machen (Farbe, Cursor verschieben und weitere Kindereien) sind Anfänger. Und die werden das kaum mit den Manipulatoren so richtig kapieren. Aber wenn du die wichtigsten Manipulatoren schon vordefinierst ist das ja kein Problem mehr.
-
Original erstellt von <Klaus>:
jau genau meine Meinung. Die meisten die mit der Konsole arbeiten und solche Spielchen machen (Farbe, Cursor verschieben und weitere Kindereien) sind Anfänger. Und die werden das kaum mit den Manipulatoren so richtig kapieren. Aber wenn du die wichtigsten Manipulatoren schon vordefinierst ist das ja kein Problem mehr.in der kontools.h sind die Improved Console dinger drin
z.b.
gotoxy(int x,int y)
setcolor(unsigned short color);
im namespace colors sind farbkonstanten definiert
in namespace cursers gibt es eine paar funktionen
Pos getPosition();
void setPosition(Pos);
void setmode(mode);in namespace xdim bzw. ydim gibt es eine size funktion
dann gibt da noch
void cls(unsigned short int color)für die anfänger beseteht keine notwendigkeit sich mit kon::maipulator auseinader zusetzen und jeder der halb wegs c++ kann wird doch wohl von einer klasse ableiten können und ein paar methoden überschreiben
ich hame mir extra mühe gegeben damit es einfach zu benutzen ist
-
Original erstellt von SideWinder:
**@Dimah: Ist zwar sehr gut gelungen, aber leider trifft es nicht den Kern der User. Die meisten sind absolute C++-Anfänger die einfach ein bisschen Farbe ins Spiel bringen wollen, die verstehen eben eher weniger von Klassen, Manipulatoren, etc.Die Idee mit den Manipulatoren ist zwar nicht schlecht, allerdings für die meisten nicht ganz verständlich und etwas zu groß ;).
MfG SideWinder**
also die handhabung der .h und .cpp dateien ist die gleiche geblieben.
das einzigste was sich verändert hat ist das sie statt#include "col_iostream.h" int main() { colcout.setcolor( FOREGROUND_RED ); colcout << "Hallo\n"; colcout.setcolor( FOREGROUND_INTENSITY ); }
müssen sie bei mir
#include <iostream> #include "kontools.h" using namespace std; using namespace kon; int main() { cout << setcolor( colors::fg::dark::red ) << "Hallo\n"; }
arbeiten
-
Dokumentier das Teil doch ordentlich, zip es und lad es hoch.
-
@dimah:
sprich mit kingruedi ob er da auch ne Unix Version davon macht - dann wird das ganze nämlich interessant.
-
Warum unbedingt kingruedi?
:p
-
Original erstellt von <Daniel>:
Warum unbedingt kingruedi?:p
weil er schon ne unix version von der improved console gemacht hat.
-
ich kucke mir grad doxygen an
-
Original erstellt von Dimah:
colors::fg::dark::redMacht man das so? Namespaces sind ja 'ne tolle Sache, aber ich finde man kann's auch übertreiben...
-
also das dark finde ich auf jeden fall überflüssig
-
Original erstellt von DrGreenthumb:
Macht man das so? Namespaces sind ja 'ne tolle Sache, aber ich finde man kann's auch übertreiben...schau dir die alternative an Farben
also colors muss sein, fg und bg müssen auch sein,
jetzt ist die frage dark und brig
ich kann mir unter TURQUOISE schlecht was vorstellenaußerdem will ich mir nicht all die namen merken müssen, ich tippe colors::
und schon macht die ide eine liste der member auf, dann fg:: und wieder kriege ich eine liste.
in einen jahr wenn (bei mir dauert das 3 tage) wenn ich vergessen habe was ich da gemacht habe, kann ich das genau so machen ohne einmal in die docu zu kuckenaber vielleicht sollte ich mich von fg und bg trennen und stat dessen setcolor ein zweiten defaul paramter geben mit den man die hintergrund farbe angeben kann
aber bei dark und brig weiss ich noch nicht, ob ich darkblue oder dark::blue schreibe ist doch egal
-
dann schreib brig wenigstens aus.
-
Original erstellt von <küsschen>:
dann schreib brig wenigstens aus.ne dann kille ich liber den namespace, dark reicht aus, die hellen sachen können direkt in colors liegen
[ Dieser Beitrag wurde am 23.02.2003 um 02:38 Uhr von Dimah editiert. ]
-
hmmm, das finde ich auch quatsch. wenn sollte man das schon einheitlich designen.
wer sich unter TURQUOISE nichts vorstellen kann, braucht die farbe auch nicht :p
-
cool danke für den anstoss ist jetzt wirklich besser
namespace colors { typedef unsigned short int type; extern const kon::colors::type black; extern const kon::colors::type darkgrey; extern const kon::colors::type grey; extern const kon::colors::type white; namespace dark { extern const kon::colors::type red; extern const kon::colors::type green; extern const kon::colors::type blue; extern const kon::colors::type yellow; extern const kon::colors::type turquoise; extern const kon::colors::type pink; } extern const kon::colors::type red; extern const kon::colors::type green; extern const kon::colors::type blue; extern const kon::colors::type yellow; extern const kon::colors::type turquoise; extern const kon::colors::type pink; } // end of namespace colors kon::manipulator setcolor(kon::colors::type text, kon::colors::type background = 0);
@<küsschen> zu dark müss ich mir noch was überlegen
schade das die konsole nur so wenig farben hat, sonst würde ich das so machen#include <iostream> #include "kontools.h" using namespace std; using namespace kon; int main() { cout << setcolor( colors::red( 0 ) ) << "dunkel\n"; // op() überladen cout << setcolor( colors::red( 1 ) ) << "heler\n"; cout << setcolor( colors::red ) << "heler\n"; }
aber für hell und dunkel lohnt sich das nicht, man könnte natürlich andere ops überladen
z.b. * für hell (* == sonne :D)