Mein Erstes Programm und meine ersten Fehler



  • WORDs und DWORDs benutze ich, seit ich die MFC verwende. Es hilft meinem Gehirn, für "unsigned short int" die Verknüpfung zu "2-Byte-Wert ohne Vorzeichen" zu erstellen. OK, ich gebe zu, dass es verwirrend sein mag, aber ein jeder hat seinen eigenen Stil:

    [cpp]
    class CSimpleClass //C vor Klassenname
    {
    public:
    char *pszPointer; // Pointer auf ZeichenString
    // Man merke, das Dereferenzierungszeichen liegt neben
    // der Variable ...
    };

    void PointlessFunction(CSimpleClass&,CSimpleClass*); // ... hier beim Typen ...

    (...)

    void PointlessFunction(CSimpleClass &First,CSimpleClass *Second) // und wieder neben der Variable.
    {
    (...)
    }

    [/cpp]

    Schlechte Angewohnheiten, aber was soll ich machen? Ich bin wie ein Autist, der sein eigenes Chaos überblicken kann.

    Wenn du das Programm nicht brauchst, macht es auch nichts. Stattdessen kannst du vielleicht das eine oder andere abkupfern, ich habe nichts dagegen, da es sich schliesslich um "leichtverdaulichen" Code handelt.



  • Für mich handelt es sich bei deinem Code für sehr "schwerverdaulichen" Code.
    Solchen redudanten Code unter Verwendung von Windoof DWORD bzw. LONG würde ich niemanden antun wollen.



  • Möchtest du mal was wissen? Die MFCs basieren auf CHAR, BYTE, SHORT, WORD, LONG, INT, DWORD, UINT, BOOL (abklatsch von bool) und so weiter. Programmierst du schon lang, oder hast du noch nie was von Plattformabhängigkeiten gehört, bei denen ein int manchmal 2 Byte und sehr oft 4 Byte Speicher nimmt? Einige 16-Bit-Prozessoren und Betriebssysteme sind noch so aufgebaut. Ausserdem habe ich mich schon sehr am Riemen gerissen, als ich den Code unten geschrieben habe, um nicht alle Eigenheiten einfliessen zu lassen.



  • Erstmal ein "Ja" auf deine Frage. 😉
    Du hälst also die MFC Plattformabhäng ?
    Kennst du long bzw unsigned long ?



  • Zumal wir hier im C++ Forum sind. Das MFC-Forum ist ein paar Zeilen weiter oben 😉



  • Gerade, DAMIT sie nicht plattformabhängig ist, werden diese Definitionen benutzt. Damit auch Hans Müller aus der Schweiz, der Windows 95 besitzt, diese benutzten kann.



  • Windows 95 - (un)signed long 32bit
    Windows Vista - (un)signed long 32bit

    Aber ist ja auch egal. Hauptsache man denkt nicht das irgendetwas wie MFC was mit Standard zu tun hat.



  • Achso Plattformunabhängig 😃
    16Bit - (un)signed long 32bit
    32Bit - (un)signed long 32bit



  • Vista gibt es (wie XP) im 32-Bit und im 64-Bit-Format.

    Vista 32: int == 4 Byte
    Vista 64: int == 8 Byte

    Das mit Windows 95 war nur ein Beispiel, hier mal die Realität:

    Windows 3.1 (16.Bit): int == 2 Byte

    16 Bit == 2 Byte
    32 Bit == 4 Byte
    64 Bit == 8 Byte

    Ich weiss nicht, ob es zu der Zeit die MFC schon gab, aber die API gab es schon, und darauf beruht die MFC.



  • Drum ja auch kein int sondern long. 🙄



  • 😕 😕 😕

    int ist der Standartwert der Sprache C++. Und da dieser Plattformunabhängig sein soll, muss man Definierungen wie

    typedef __int32 INT; // Ermittelt, dass ein Interger mit 32 Bit INT heissen soll
    


  • int ist der Standartwert der Sprache C++.

    😕 😕 😕 Es gibt keinen "Standardwert" in C++.

    Jetzt stellt sich die Frage, welche Daseinsberechtigung hat der Datentyp long dann eigentlich noch auf 32-Bit-Systemen? long hat ja auf diesen Systemen dieselbe Größe und denselben Wertebereich wie der Datentyp int.

    Die Antwort könnte lauten: aus Kompatibilitätsgründen. Damit alte Programme, die für 16-Bit-Rechner geschrieben wurden, auch noch auf einem 32-Bit-Rechner laufen bzw. übersetzt werden können. Das gilt auch für den umgekehrten Fall. Dies sollten Sie beachten, wenn Sie ein Programm für ein 32-Bit-System geschrieben haben und es dann auf ein 16-Bit-System portierten wollen. In diesem Fall ist es empfehlenswert, den Datentypen long zu verwenden.

    Für 64Bit Systeme ist das allerdings anders.



  • In dem Zitat hast du es doch perfekt auf dem Punkt gebracht: Damit alte Programme auf neueren Betriebssystemen laufen und umgekehrt. Wenn ich schreibe

    typedef unsigned __int8  BYTE;
    typedef unsigned __int16 WORD;
    typedef unsigned __int32 DWORD;
    

    , weiss das Programm genau: BYTE ist ein vorzeichenloser 1-Byte Wert, WORD ein vorzeichenloser 2-Byte Wert und DWORD ein vorzeichenloser 4-Byte Wert, egal auf welchem Betriebssystem. 😮



  • 😮
    *ROFL*



  • Der aus dem Westen ... schrieb:

    😕 😕 😕

    int ist der Standartwert der Sprache C++. Und da dieser Plattformunabhängig sein soll, muss man Definierungen wie

    typedef __int32 INT; // Ermittelt, dass ein Interger mit 32 Bit INT heissen soll
    

    __int32 ist kein Standard-Datentyp und wird nicht von allen Compilern unterstützt. Damit ist die Plattformunabhängigkeit fürn Lokus. Mal abgesehen davon dass solche Wortschöpfungen wie "Definierungen" zwar auch recht kreativ aber trotzdem kein "Standard"-Deutsch sind.



  • Der aus dem Westen ... schrieb:

    In dem Zitat hast du es doch perfekt auf dem Punkt gebracht: Damit alte Programme auf neueren Betriebssystemen laufen und umgekehrt. Wenn ich schreibe

    typedef unsigned __int8  BYTE;
    typedef unsigned __int16 WORD;
    typedef unsigned __int32 DWORD;
    

    , weiss das Programm genau: BYTE ist ein vorzeichenloser 1-Byte Wert, WORD ein vorzeichenloser 2-Byte Wert und DWORD ein vorzeichenloser 4-Byte Wert, egal auf welchem Betriebssystem. 😮

    Ja, das schon, aber ein Wort ist nunmal je nach Prozessor meist 8, 16, 32 oder 64 Bit breit und es auf 32 Bit festzulegen ist pure Verwirrungstaktik.
    Schreib doch lieber

    typedef unsigned __int32 uint32_t;
    

    oder inkludiere die <stdint.h>



  • oder nimm einfach long. 64Bit sind eh gesndert zu behandeln.


Anmelden zum Antworten