conat.h

Wutz

itedvo schrieb:

#define BLACK 0
#define BLUE 1
#define GREEN 2
#define CYAN 3
#define RED 4
#define VIOLET 5
#define BROWN 6
#define LIGHTGREY 7
#define DARKGREY 8
#define LIGHTBLUE 9
#define LIGHTGREEN 10
#define LIGHTCYAN 11
#define LIGHTRED 12
#define LIGHTMAGENTA 13
#define YELLOW 14
#define WHITE 15
#define DARKBLUE 128
#define GREY 221
#define PINK 222

Besser und robuster aus mehreren Gründen ist:

typedef enum {
BLACK,
BLUE,
GREEN,
CYAN,
RED,
VIOLET,
BROWN,
LIGHTGREY,
DARKGREY,
LIGHTBLUE,
LIGHTGREEN,
LIGHTCYAN,
LIGHTRED,
LIGHTMAGENTA,
YELLOW,
WHITE,
DARKBLUE=128,
GREY=221,
PINK=222} Farbwerte;

/*und dann die Variablendefinitionen*/
Farbwerte farbwerte;
/*und die Funktionsparameter*/
void blafasel(Farbwerte f);
/*statt*/
void blafasel(int f);

Du solltest auch vorsichtig bei der Vergabe von kurzen, prägnanten define-Namen sein, da diese evtl. schon verwendet werden und du vom Compiler bestenfalls eine Warnung erhälst.
Bei der enum-variante bekommst du dagegen einen Fehler, ebenso sind enum für Debuggingzwecke besser geeignet als defines.

itedvo

hmm, danke... die tipps hören sich gut an. werde mich gleich daran setzen und
das ganze verbessern.

wie das ganze mit den libs funktioniert, weiß ich jetzt nicht wirklich, da es
ja eigentlich für die klasse (ich besuch ne htbl) bestimmt ist, war mein 1.
hintergrundgedanke, dass die klasse etwas davon lernt, übernimmt und ev. wieder
verwendet. es geht mir ja nicht direkt etwas zu verstecken xD

dennoch, für spätere zwecke: was für ein project-typ muss ich überhaupt bei
visual studio 2008/10 verwenden für eine .lib? was ist besser und voralem besser
für sowas kleines geeignet?

Wutz schrieb:

314159265358979 schrieb:

Du solltest die Funktionen in den Header geben, damit man keine .c/cpp braucht.

Das ist natürlich Schwachsinn.

da ich bis jetzt geschlafen habe und ich noch alles halbwegs verschwommen sehe,
hät ich dass noch fast geglaubt, was 314159265358979 geschrieben hatte xD
danke wutz, hast mich vor verwirrung gerettet xD

typedef enum {
BLACK,
BLUE,
GREEN,
CYAN,
RED,
VIOLET,
BROWN,
LIGHTGREY,
DARKGREY,
LIGHTBLUE,
LIGHTGREEN,
LIGHTCYAN,
LIGHTRED,
LIGHTMAGENTA,
YELLOW,
WHITE,
DARKBLUE=128,
GREY=221,
PINK=222} Farbwerte;

woher weiß der compiler jetzt was für einen wert jetzt zum beispiel: lightred hat?

und typedef hab ich ja verwendet... zb:

typedef short cord; // platzsparend, brauch nicht mehr!
typedef unsigned int Uint; // hab ich für die farbwerte verwendet, brauch keine werte im bereich Z[h]-

// und dann für die funktion:

void textcolor(Uint color);

aber wenn ich das obere verstehe, verwende ich gerne deinen code...

Belli schrieb:

Hier:

cord wherex(){

    CONSOLE_SCREEN_BUFFER_INFO info;

    return info.dwCursorPosition.X+1;
}

cord wherey(){

    CONSOLE_SCREEN_BUFFER_INFO info;

    return info.dwCursorPosition.Y + 1;
}

fehlt noch ein Funktionsaufruf vor der return - Anweisung.

was für ein funktionsaufruf? info.dwCursorPosition.Y zeigt auf die cursor position... anfangs ist sie bei 0 (auch bei X)... erst im späteren verlauf des
programmes wird sie aktualisiert. sprich: bei printf, bei gotoxy() etc. ich versteh nich welche funktion du meinst...

danke noch mals =b

gruß
ITEDVO

Belli

Na, die where - Funktionen sollen doch die aktuellen Positionen zurückliefern, die stehen aber in info nicht drin, wenn Du nicht vorher

GetConsoleScreenBufferInfo

aufrufst.

314159265358979

Es ist einfacher, die kleinen Funktionen in einem Header zu halten, auch zur Verwendung.

itedvo

Belli schrieb:

Na, die where - Funktionen sollen doch die aktuellen Positionen zurückliefern, die stehen aber in info nicht drin, wenn Du nicht vorher

GetConsoleScreenBufferInfo

aufrufst.

bin gerade beim essen drauf gekommen, aber danke xD

GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &info);

314159265358979 schrieb:

Es ist einfacher, die kleinen Funktionen in einem Header zu halten, auch zur Verwendung.

ein schwachsinn², schreibst du eine funktion in einer headerdatei (also mit dem
befehls block), dann lässt der compiler mit einer schönen fehlermeldung grüßen.
einzig die prototypen sind erlaubt und sinnvoll!

314159265358979

Du hast nen Knall.

itedvo

314159265358979 schrieb:

Du hast nen Knall.

dann gib mir code-beispiele... ev. überseh ich ja was wesentliches, aber
visual studio 2008 meckert ununterbrochen und in jedem tutorial wird entweder
direkt darauf hingewiesen das die funktionen in der .cpp liegen und die prototypen in der .h weils sonst nicht geht oder indirekt in dem darauf hingewiesen wird das eine .cpp benötigt wird, ausser man schreibt eine .dll oder .lib. also, gib mir konkrete beispiele und ich nehme zurück was ich
geschrieben habe.

Mach deine Funktionen static und es geht. Allerdings solltest du dann beachten, dass die Funktion danach in jeder C-Datei vorhanden ist. Das gibt keine Linkerfehler ( nicht Compilerfehler), aber du kannst natürlich nichts mehr machen, wo du drauf angewiesen bist genau die selbe Funktion auszuführen. Wie zum Beispiel statische Variablen in der Funktion.

itedvo

ók, ich nehme das geschriebene zurück... aber dennoch, ist glaube ich eher
unschön? oder?

Wutz

itedvo schrieb:

typedef enum {
BLACK,
BLUE,
GREEN,
CYAN,
RED,
VIOLET,
BROWN,
LIGHTGREY,
DARKGREY,
LIGHTBLUE,
LIGHTGREEN,
LIGHTCYAN,
LIGHTRED,
LIGHTMAGENTA,
YELLOW,
WHITE,
DARKBLUE=128,
GREY=221,
PINK=222} Farbwerte;

woher weiß der compiler jetzt was für einen wert jetzt zum beispiel: lightred hat?

enum verwendet jeweils eine implizite Initialisierung der Elemente, wenn keine explizite angegeben ist, das erste Element beginnt bei 0, jedes folgende Element dann +1.

itedvo

ach so... danke, dann werd ich das mal übernehmen... auf dich kann man
sich halt so gut wie immmer verlassen wutz =b

itedvo

so, hab jetzt einige dinge ergänzt und das ganze jetzt als *.dll project
erstellt. funktioniert alles sehr gut...

etwas, was mich jetzt wunder nimmt ist folgendes: wenn ich jetzt die *.dll
erweitere, kann ich dann nur die *.dll weiter geben, ohne die *.lib + *.h mit
zu geben? falls ja, wieso?

Solange du nur neue Sachen ergänzt und nichts änderst, sollte es kein Problem geben. Die *.h und *.lib benötigst du nur, um dein Programm zu erstellen. Damit weiß der Compiler, wie es in der *.dll drin aussieht.

Wutz

Das zuverlässige und portable Standardverfahren ist, die *.h und *.lib zu liefern, den ganzen DLL-Schrott würde ich nur unsympathischen Leuten zumuten.

itedvo

Wutz schrieb:

Das zuverlässige und portable Standardverfahren ist, die *.h und *.lib zu liefern, den ganzen DLL-Schrott würde ich nur unsympathischen Leuten zumuten.

wer sagt denn, dass mir meine klasse sympathisch ist =b =b =b

hmm, ich mag google nicht wirklich, wisst ihr eh oder? ich meine: ich such nach
tutorials für *.lib und alles was kommt fängt mit dll an... gibts da vieleicht
n´halbwegs gutes tutorial?

Belli

Paul Müller schrieb:

Solange du nur neue Sachen ergänzt und nichts änderst, sollte es kein Problem geben. Die *.h und *.lib benötigst du nur, um dein Programm zu erstellen. Damit weiß der Compiler, wie es in der *.dll drin aussieht.

Es gibt nur Probleme, wenn neue Funktionen geschrieben werden, die von außen aufgerufen werden sollen, und wenn bei vorhandenen Funktionen, die von außen aufgerufen werden, Rückgabewert oder Parametertyp/anzahl geändert werden.