Improved Console v2.0 Beta

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.

Gerard

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

Gerard

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.

Shade Of Mine

@dimah:

sprich mit kingruedi ob er da auch ne Unix Version davon macht - dann wird das ganze nämlich interessant.

Warum unbedingt kingruedi? :p

Shade Of Mine

Original erstellt von <Daniel>:
Warum unbedingt kingruedi? :p

weil er schon ne unix version von der improved console gemacht hat.

Gerard

ich kucke mir grad doxygen an

DrGreenthumb

Original erstellt von Dimah:
colors::fg::dark::red

Macht 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

Gerard

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 vorstellen

auß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 kucken

aber 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.

Gerard

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

Gerard

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)

Gerard

hmm, der linux port wird aber wahrschinelich mehr farben haben, dann wäre ein überladener op() vom vorteil
c++ hat zu viele möglichkeiten

SideWinder

heler? Du meinst wohl heller ;).

---

Was hast du gegen meine Aufteilung der Farben? Ich finde ein FG_RED irgendwie wesentlich ausdrucksvoller als ein kon::colors::dark::red, mal ohne using angenommen.

---

Hab zwar jetzt nicht ausgelesen ob der letzte Thread von dir unten nur Spaß oder Ernst war, aber man sollte Operatoren nur für Dinge überladen, für die sie normalerweise in der Sprache eingesetzt werden. Und somit ist ein + für subtrahieren genau so unsinnig wie ein * für heller - aber ich glaub das hast du sowieso nicht ernst genommen, oder? Sry, bin aber nicht der schnellste in solchen Sachen ;).

---

(bevor der text kritisiert wird den nächsten abschnitt lesen)
Zum Thema Umfang: Weist du was das große Problem an deiner Improved Console ist - die Möglichkeiten die man damit hat. Klingt komisch, dürfte aber eventl. wirklich so sein. Ich habe früher mal selbst an einer Erweiterung mit mehr Möglichkeiten gearbeitet. Zudem wollte ich aus der Funktion getch() noch einen schönen Stream machen, aber nichtsdestotrotz (schreibt man das so?) ist meine Console an einem Punkt gescheitert: Was man mit ihr alles kann. Sie wurde eigentlich immer größer und größer und irgendwann nicht mehr überschaubar.

Für den Anfänger ist die C-Improved-Console fast noch logischer als die in C++. Er ruft was auf und schon passiert etwas. Er kann nicht viel falsch machen, einfach statt cout colcout verwenden und schon ist alles in Farbe. Marcus' geniales Konzept ist einfach: einfach. Man hat mit drei Funktionen eigentlich alles wissenswerte gelernt.

---

So, das Konzept mit den Manipulatoren ist aber sehr gelungen. Und vor allem hat es einen extrem großen Vorteil gegenüber meiner Rein-Ein-Klassen-Implementation, man gibt nur die Grundtools mit, die Helfen dem Anfänger, und nur wer will muss den dann nötigen und nicht mehr unnötigen für den Anfänger unüberschaubaren Zusatz an Möglichkeiten mitnehmen.

Vielleicht wäre dann eine Art Profi-Tool-Sammlung von Zusatzmanipulatoren zu empfehlen. Also schön langsam finde ich gefallen an deiner Version. Mal sehen.

Kritikpunkte:

1. Für den Anfänger darf kein Ballast da sein - weg mit den vielen Namespaces, eine sety-Funktion braucht keinen eigenen Namespace. Da braucht man ja länger für das Eingeben der Position in einem Namespace als für die eigentliche Arbeit.

2. Die Funktion undo() ist irgendwie komisch. Sie wiederspricht dem Prinzip der Namen deiner Funktionen: setcolor sollte nicht am Ende wieder die Farbe zurück setzen?! Oder kann man deine Manipulatoren auch als Funktionen immer und überall aufrufen? Dafür dann aber statisch?

3. Einige dich auf eine Sprache ein getKonsoleInfo() klingt irgendwie komisch ;).

---

Achja und noch eine Frage: Verwendet man gotoxy() wie eine Funktion wird kein undo() aufgerufen, hingegen verwendet man es als Manipulator dann schon. Warum und wie wird das gesteuert? Oder hab ich da was falsch verstanden?

MfG SideWinder

Gerard

sorry, ich habe 30 min geschreiben, eine falsche taste gedrück und weg war es
jetzt finde ich nicht die kraft noch mal 30 zu schreiben

kutzfassung:
colors::red vs colors::FG_ROSE
colors::dark::red vs colors::RG_RED
ich nehme mal an das die leute eine kon-using-direktive machen (außer es gibt names konflikte)

das mit den ops war nur spass

Improved Console 2.0 ist in erster linie ein nutzungs beispiel für kon::manipulator (der namespace kon passt doch nicht)

Kritikpunkte:

1. jup
2. undo wird nur aufgerufen wenn man kon::maipulator in ein stream hatte
3. jup

kon::maipulator wird per value zurück gegeben(hier wird doit(void) aufgerufen), beim ersten kontakt mit ein stream (durch operator<<( ostream & os, maipulator ma) )
übernimt er den stream (hier wird doit(ostream & os) aufgerufen)

da manip ein operator ostream &() und diverse ops<< hat verhält es sich wie ein ostream (gibt die sachen an den richtigen ostream weiter)

soweit wir wissen bleiben temporäre objekte solange am leben wie man mit ihn arbeitet
deswegen lebt der manip bis zum ; und da wird dann auch undo(void) aufgerufen.
damit undo nicht zu oft aufgerufen wird verfolgt manip die COW strategie ( das was std::auto_ptr beim copieren macht, quelle übergibt an ziel ihre inereien und stirbt dann)und erst der letzte ruft undo() auf (refernz zählung wurde vielleicht auch gehen)

[ Dieser Beitrag wurde am 24.02.2003 um 01:41 Uhr von Dimah editiert. ]

Shade Of Mine

äh wieso für anfänger?

muss sich ein fortgeschrittener immer mit allegro rumschlagen?

dark::red sollte zu darkred werden (IMHO)

farben mit den op() überladen finde ich praktisch. aber nur wenn es wirklich viele farben gibt.

1. Für den Anfänger darf kein Ballast da sein - weg mit den vielen Namespaces, eine sety-Funktion braucht keinen eigenen Namespace. Da braucht man ja länger für das Eingeben der Position in einem Namespace als für die eigentliche Arbeit.

Wieso Anfänger? soll man nur weil auch Anfänger diese Lib verwenden können das design mies machen?
warum sollen ANfänger nicht sehen wie man es richtig macht?

vorallem was ist mit den Nicht-Anfängern? Die willst du aussen vor lassen?

2. Die Funktion undo() ist irgendwie komisch. Sie wiederspricht dem Prinzip der Namen deiner Funktionen: setcolor sollte nicht am Ende wieder die Farbe zurück setzen?! Oder kann man deine Manipulatoren auch als Funktionen immer und überall aufrufen? Dafür dann aber statisch?

guter punkt:
aber so verhalten sich die IOStream Manipulatoren ja auch - sehe also sinn darin das prinzip beizubehalten.

3. Einige dich auf eine Sprache ein getKonsoleInfo() klingt irgendwie komisch

jep - englisch sollte überall eingehalten sein.
sonst drehen die armen nicht-deutsch-sprecher ja noch durch

technisch gesehen finde ich diese improved console recht interessant. sollte sie auch für unix erscheinen kommt sie sofort in den standard-include ordner

SideWinder

@Dimah: Dann würde ich aber die Aufteilung so erledigen:

jetziger Name ------ neuer Name ------ Inhalt
----------------------------------------------------
    konmanip.h         manipulator.h     dein Manipulator
    kontools.h         col_iostream.h    deine Improved Console

Die Improved Console hat ja eigentlich mit deinem Manipulator wenig zu tun. Außerdem würde ich nicht nur im Headernamen dringlichst abwärtskomptibel zur alten IC (neue Abkürzung...) bleiben.

Das mit den Farben lassen wir mal außen vor - geht zu sehr ins Detail ;).

Das mit dem Aufrufen hab ich jetzt kapiert - klingt sehr gut :).

@Shade Of Mine:

äh wieso für anfänger?

muss sich ein fortgeschrittener immer mit allegro rumschlagen?

Nein, aber ein Anfänger kann sich eben nur mit der IC rumschlagen, ein Fortgeschrittener kann ja dank des neuen Konzepts leicht von worker_base ableiten und seine eigenen Tools basteln.

Aber auf keinen Fall sollten wir hier nur was für Fortgeschrittene basteln und die eigentliche Zielgruppe aus den Augen lassen...

Ich wäre ja auch für eine Einführung von irendwelchen Toolsammlungen die dann auf worker_base basieren. Da lässt sich dann ja leicht etwas erweitern.

Wieso Anfänger? soll man nur weil auch Anfänger diese Lib verwenden können das design mies machen?
warum sollen ANfänger nicht sehen wie man es richtig macht?

Ist es leicht schön gestaltete Arbeit wenn man sich durch 4 Namespaces Doppelpunkten muss bis man bei seiner Farbe ist?

MfG SideWinder