Improved Console v2.0 Beta

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

SideWinder

BTW: Warum ist der auto_ptr aus manipulator mutable?

MfG SideWinder

Gerard

Original erstellt von SideWinder:
**BTW: Warum ist der auto_ptr aus manipulator mutable?

MfG SideWinder**

meine stl implementierung ist mist und stlport macht probleme (selbt wenn *ich* stlport haben würde, ich kann ja schlecht den leuten sagen sie sollen sich stlport instalieren)
z.b. std::auto_ptr<T>::release() ist nicht const
ist ein workaround für msvc

Gerard

Original erstellt von Shade Of Mine:
sollte sie auch für unix erscheinen kommt sie sofort in den standard-include ordner

wird kommen, aber eins kann ich sagen mir ist die winapi lieber.
die curses.h lib
100 funktionen, für jede aufgabe gibt es ~zwei funktionen, bei den meisten funktionen kann man nicht mal erahnen was sie machen
irgend welche marko zaubereien, globale variablen
ahja hast du unix? ich brauche jemanden der testet

zu zeit muss ich noch ein problem beseitigen,

int main()
{
    cout << gotoxy( 10, 10 ) << '#' 
         << gotoxy( 10, 20 ) << '#' 
         << gotoxy( 20, 10 ) << '#'
         << gotoxy( 20, 20 ) << '#';
}

macht nicht was es soll

Gerard

ahja mit den farben habt ihr mich klein gekriegt, dark kommt weg weil in namespaces sollen sachen rein die zusammen gehören und die farben gehören zusammen, auch wenn man sie in einer seperaten gruppe einordnen kann

DrGreenthumb

ncurses? ieh... Wieso nicht einfach Escape-Sequenzen?

Escape-Sequenzen? ihh :p

DrGreenthumb

Original erstellt von <mod>:
Escape-Sequenzen? ihh :p

wieso?

Shade Of Mine

Original erstellt von DrGreenthumb:
wieso?

warum escape sequenzen?
müssen laut POSIX die Treiber für die Escape Sequenzen installiert sein?

wenn nein, dann ist das ein KO Kriterium.

Gerard

Original erstellt von Shade Of Mine:
wenn nein, dann ist das ein KO Kriterium.

Escape-Sequenzen können mir aber nicht sagen wo sich grad der curser aufhält

Shade Of Mine

@SideWinder:

Anfängern sollte doch die alte IC reichen, oder?

Warum muss n Profi sich die sachen selber basteln? Dann hab ich ja keine Plattform unabhängigkeit - es sei denn ich portier mir das selbst.

aber dann kann ich ja gleich die ganze lib selber schreiben...

IMHO soll eine library alles können was man braucht und für spezialfälle soll man sie einfach erweitern können. und nicht umgekehrt.

was ist ausserdem an Dimahs Design schlecht? nichts - es ist halt für Anfänger nicht leicht durchschaubar - na und? Anwenden können sies trotzdem. Und welcher Anfänger kapiert schon die WinAPI?

Ich finde es recht gut wenn Anfänger von Anfang an an schönes Design gewöhnt werden - dann fragen sie sich vielleicht was diese manipulatoren sind und aufeinmal stehen sie mit beiden beinen in der IOStream Library. Oder sie kümmern sich nicht drum und verwenden es halt nur - schadet auch nichts.

aber wenn man sie mit C Design konfrontiert werden die ja nie OOP lernen...

und wieso abwärtskompatibel?
einziger Grund den ich dafür kenne ist es, bestehenden Sourceocde nicht zu brechen - das ist hier aber nicht gegeben.

@Dimah:
ne gute Doku würde der Lib auch nicht schade