4. conat.h

conat.h

  • B

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

    GetConsoleScreenBufferInfo

    aufrufst.

    0
  • 3

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

    0
  • I

    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!

    0
  • 3

    Du hast nen Knall.

    0
  • I

    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.

    0
  • ?

    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.

    0
  • I

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

    0

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

    0
  • I

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

    0
  • I

    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?

    0
  • ?

    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.

    0

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

    0
  • I

    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?

    0
  • B

    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.

    0
Anmelden zum Antworten