4. Visual C++ Toolkit 2003 Problem

Visual C++ Toolkit 2003 Problem

  • J

    Artchi schrieb:

    Kein Wunder:

    joomoo schrieb:

    #ifndef WND_BGCOLOR
#define WND_BGCOLOR (HBRUSH) GetStockObject(LTGRAY_BRUSH)
#endif // <<<<<<<<<<<<<<----- WHAT THE FUCK IS THIS??????
#ifndef _EIGENEDB
#define _EIGENEDB

#endif

    Das ist die db.h

    Das ist endif. Wenn es falsch ist, könntest du mir das in einfachen (deutschen) Sätzen erklären? Ich versteh noch nicht ganz was du meinst...

    0
  • A

    Sorry, ich glaub ich hab mir da selber ein Bein gestellt. Das hatte mich alles verwirrt. Aber nichts desto trotz, warum machst du das nicht so:

    #ifndef EIGENEDB_H // Unterstrich an erster Stelle ist den Compilern vorbehalten
#define EIGENEDB_H

// MAKROS sind in C++ BÖSE!!! WEG DAMIT!
#define WND_BGCOLOR (HBRUSH) GetStockObject(LTGRAY_BRUSH)

PAINTSTRUCT ps;
extern HDC hdc;
struct BUFFER                    // This is our back buffering structure
{
// HWND hwnd;                    // This holds the current window's handle
 RECT scrnRect;                // This holds the client rectangle of the window
 HANDLE hCompBitmap;            // This holds the compatible bitmap for the backbuffer
 HANDLE hOldBitmap;            // This is used for storage to free when the program quits
 HANDLE hOldBitmap2;            // This is used as storage to swap between selected bitmaps when using selectObject()
// HDC hdcFront;                // This is the front buffer (The part we see)
 HDC hdcBack;                // This is the back buffer (the part we draw to, then flip)
 HDC hdcBitmap;                // This is a temp buffer to swap the bitmap back and forth from
};
extern BUFFER gBuffer;
extern BUFFER *pBuffer = &gBuffer;
void CreateDoubleBuffering(HWND hwnd);
void zeigeBitmap(HBITMAP hBitmap, int x, int y);
void ClearScreen();
void SwapBackBuffer();

#endif  // EIGENEDB_H

    Der VC++2003 hat eine Neuerung (da Makros böse sind):

    // pragma once ist einfacher.
#pragma once

// MAKROS sind in C++ BÖSE!!! WEG DAMIT!
#define WND_BGCOLOR (HBRUSH) GetStockObject(LTGRAY_BRUSH)

PAINTSTRUCT ps;
extern HDC hdc;
struct BUFFER                    // This is our back buffering structure
{
// HWND hwnd;                    // This holds the current window's handle
 RECT scrnRect;                // This holds the client rectangle of the window
 HANDLE hCompBitmap;            // This holds the compatible bitmap for the backbuffer
 HANDLE hOldBitmap;            // This is used for storage to free when the program quits
 HANDLE hOldBitmap2;            // This is used as storage to swap between selected bitmaps when using selectObject()
// HDC hdcFront;                // This is the front buffer (The part we see)
 HDC hdcBack;                // This is the back buffer (the part we draw to, then flip)
 HDC hdcBitmap;                // This is a temp buffer to swap the bitmap back and forth from
};
extern BUFFER gBuffer;
extern BUFFER *pBuffer = &gBuffer;
void CreateDoubleBuffering(HWND hwnd);
void zeigeBitmap(HBITMAP hBitmap, int x, int y);
void ClearScreen();
void SwapBackBuffer();
    0
  • N

    Artchi schrieb:

    Sorry, ich glaub ich hab mir da selber ein Bein gestellt. Das hatte mich alles verwirrt.

    die syntax-einfärbung hat nicht richtig gefunzt

    0
  • J

    Artchi schrieb:

    Der VC++2003 hat eine Neuerung (da Makros böse sind):

    // pragma once ist einfacher.
#pragma once

    Wie genau funktioniert diese pragma?? Hab ich noch nicht ganz gecheckt. (Und was sind Makros???)

    0
  • G

    Artchi schrieb:

    Der VC++2003 hat eine Neuerung (da Makros böse sind)

    Wer sagt das?
    Makros sind nicht böse. Böse ist nur der, der sie falsch benutzt.
    #pragma once gibt es übrigens nicht erst seit VC++ 2003, und ist zudem nicht portabel.

    0
  • A

    Online-Hilfe zum VisualC++ findest du auf MSDN, unter anderem auch zu den pragmas:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_predir_once.asp

    Makros sind die Dinger, die du mit #define definierst. Als Include-Guard kommt man leider noch nicht ohne Makros bei den meisten Compilern bzw. Präprozessoren aus. Da sind sie also noch legitim. Ansonst sollte man aber Makros vermeiden, da es in der heutigen Zeit mit den C++-Sprachmitteln viel bessere Möglichkeiten gibt. Da Makros keine Sprach- und somit keine Compiler-Elemente sind.

    0
  • A

    groovemaster schrieb:

    Artchi schrieb:

    Der VC++2003 hat eine Neuerung (da Makros böse sind)

    Wer sagt das?
    Makros sind nicht böse. Böse ist nur der, der sie falsch benutzt.
    #pragma once gibt es übrigens nicht erst seit VC++ 2003, und ist zudem nicht portabel.

    Bitte lesen:
    http://www.research.att.com/~bs/bs_faq2.html#macro

    Mag sein das pragma once vor 2003 im VC++ drin war. Ich kenne es erst VC++2003 weil mir VC++2003 mit dem Klassen-Assistenten autom. pragma once in die Header setzt. Bei VC++6.0 hat er das noch nicht gemacht.

    Soweit ich mich laut Foren-Aussagen erinnern kann, kann auch der GCC das mittlerweile.

    0
  • G

    Artchi schrieb:

    Bitte lesen:
    http://www.research.att.com/~bs/bs_faq2.html#macro

    Ja und? Hast du dir das überhaupt mal durchgelesen? Wo steht was davon, dass Makros böse sind. Dort werden lediglich Sachen gezeigt, wo Makros unangebracht sind, und dass es dafür bessere Möglichkeiten gibt. Trotzdem haben Makros ihre Einsatzgebiete. Wie wäre es zB mit bedingter Kompilierung? Oder wie willst du __FILE__ zur Compilezeit widen? Es gibt mehr als nur Konstanten- und Funktions-like Makro Konstrukte. 😉

    0
  • J

    Kommen wir zum Problem zurück: Mit pragma once funktioniert es auch nicht.

    Ich hab mir das so gedacht: Der Compilier braucht eine mehrfache definition pro datei der linker aber nicht, dass heißt, dass es irgentwie an den compilier einstellungen liegt. nochmal wie ich die scheiße compiliere:

    cl Projekte\TuDi\main.cpp include\eigene\db.cpp kernel32.lib user32.lib gdi32.lib
    0
  • G

    joomoo schrieb:

    Ich hab mir das so gedacht: Der Compilier braucht eine mehrfache definition pro datei der linker aber nicht

    Nein, der Compiler braucht lediglich eine mehrfache Deklaration.

    Was mir sonst noch so spontan auffällt

    #ifndef _EIGENEDB
#define _EIGENEDB
PAINTSTRUCT ps; // Problem: Deklaration und Definition
//...
#endif

    Sollte db.h in mehreren ÜE eingebunden werden, wird ps auch mehrfach definiert ➡ ODR Verletzung.

    0
Anmelden zum Antworten