== True

pumuckl schrieb:

kommt drauf an wie BOOL und TRUE definiert sind - normalerweise als einer der integralen Typen aus C und als 1. (z.B. #define BOOL long)
Beim casten von long nach bool gibts besagte Warnung. Beim Vergleich mit TRUE nicht - weil bLong und TRUE beide vom selben Typ (z.B. long) sind. Und es ist deshalb nicht das gleiche, weil bLong z.B. auch den Wert (TRUE + 1) haben könnte im ersten Fall (cast nach bool) gibt das immernoch true, im zweiten Fall (vergleich mit TRUE) gibts false.

TRUE und blong vom gleichen Typ?
TRUE ist doch kein Typ sondern einfach nur 1 oder?

Und es ist deshalb nicht das gleiche, weil bLong z.B. auch den Wert (TRUE + 1) haben könnte im ersten Fall (cast nach bool) gibt das immernoch true, im zweiten Fall (vergleich mit TRUE) gibts false.

Das verstehe ich nicht ganz.

pumuckl

Betidssa schrieb:

TRUE und blong vom gleichen Typ?
TRUE ist doch kein Typ sondern einfach nur 1 oder?

TRUE ist kein Typ, es hat aber einen Typ. Wenns als #define TRUE 1 definiert ists hats den Typ int. Vermutlich ists passend zu BOOL definiert, also z.B.

#define BOOL int
#define TRUE 1 //TRUE ist ein BOOL, weil 1 ein int ist

//oder
#define BOOL long
#define TRUE 1L //TRUE ist ein BOOL weil 1L ein long ist

Betidssa schrieb:

Das verstehe ich nicht ganz.

Was daran verstehst du nicht?

BOOL bLong;
// mache irgendwas mit bLong

bool b1 = bLong; //b1 ist false, wenn bLong 0 ist, sonst true
bool b2 = (bLong == TRUE); //b2 ist true, wenn bLong TRUE, also 1 ist. sonst false

wenn jetzt ein Spaßvogel z.B. irgendwo sagt bLong = 224; dann hat b1 den Wert true, b2 den Wert false. Deshalb sind die beiden abfragen nicht äquivalent.

wenn jetzt ein Spaßvogel z.B. irgendwo sagt bLong = 224; dann hat b1 den Wert true, b2 den Wert false

Warum das denn?

BOOL bLong = 224; // = TRUE

bool b1 = bLong; // auch TRUE !
bool b2 = (bLong == TRUE); // auch  TRUE weil bLong == TRUE....bLong ist ja auch TRUE

pumuckl

Betidssa schrieb:

Warum das denn?

BOOL bLong = 224; // = TRUE

Eben nicht. TRUE ist meist als 1 definiert, FALSE als 0 andere Zahlen sind nicht vorgesehen. Es ist eben kein Vergleich wie beim eingebauten Datentyp bool, wo jede Zahl außer 0 true ist. bei den #defines ist 1 TRUE, 0 FALSE und alle anderen Zahlen sind weder das eine noch das andere.

_matze

Zut schrieb:

erledigt!

Du solltest deine Frage lieber stehen lassen, damit andere mit dem gleichen Problem später noch was davon haben. Dein "erledigt" kannst du doch im Titel ergänzen...

5cript

Und das hat jetzt welchen Sinn ? Solche #define s braucht erstens kein Mensch 2. Verwirrt das nur

unskilled

Tim06TR schrieb:

Und das hat jetzt welchen Sinn ? Solche #define s braucht erstens kein Mensch 2. Verwirrt das nur

na den jenigen will ich sehen, der so was nicht braucht... ist doch total dämlich, dann ständig fkt zu haben, die nen int (bzw long) zurückgeben und in der doku steht immer: returns 1(success) or 0(failure)...
if(do_x() == 1) wunderhübsch, dann doch lieber
if(do_x() == TRUE) - das es in C++ auch noch anders geht ist (mittlerweile) hoffentlich so klar, dass ich das einfach unter den tisch fallen lassen kann^^

C hat nun mal kein bool... (z.bsp.) die WinAPI ist aber in C geschrieben...
und ob man dort nun typedefs oder aber makros nimmt, macht imho ca. gar keinen unterschied...

bb

5cript

Das C kein bool hat... das ist... unglaublich, muss das eben oben übersehen haben,
Dann macht das ja irgendwo doch sinn.
Kein bool ? Wie schrottig

Nexus

unskilled schrieb:

und ob man dort nun typedefs oder aber makros nimmt, macht imho ca. gar keinen unterschied...

Aber es würde sehr wohl einen Unterschied machen, enum zu nehmen.

unskilled

Nexus schrieb:

unskilled schrieb:

und ob man dort nun typedefs oder aber makros nimmt, macht imho ca. gar keinen unterschied...

Aber es würde sehr wohl einen Unterschied machen, enum zu nehmen.

welche vorteile siehst du denn darin?
ich seh da nicht so wirklich ne besserung...

bb

unskilled schrieb:

Nexus schrieb:

unskilled schrieb:

und ob man dort nun typedefs oder aber makros nimmt, macht imho ca. gar keinen unterschied...

Aber es würde sehr wohl einen Unterschied machen, enum zu nehmen.

welche vorteile siehst du denn darin?
ich seh da nicht so wirklich ne besserung...

bb

enum MyBool...

MyBool a = myBoolTrue;

int b = myBoolTrue; // error

Nexus

unskilled schrieb:

welche vorteile siehst du denn darin?
ich seh da nicht so wirklich ne besserung...

Typsicherheit. asdasasdasd hat es allerdings gerade verkehrt herum gezeigt.

enum BOOL
{
    FALSE,
    TRUE,
};

BOOL a = 3252; // Fehler

Ist dann allerdings wieder blöd wegen solchen Sachen (bräuchte eine Funktion):

BOOL b = (78 && 0);

Ein bool -Ansatz wie in C++ ist schon das beste.

camper

Nexus schrieb:

enum BOOL
{
    FALSE,
    TRUE,
};

BOOL a = 3252; // Fehler

Das wäre in C allerdings kein Fehler.

rüdiger

unskilled schrieb:

C hat nun mal kein bool... (z.bsp.) die WinAPI ist aber in C geschrieben...

Falsch, siehe _Bool und stdbool.h

unskilled schrieb:

und ob man dort nun typedefs oder aber makros nimmt, macht imho ca. gar keinen unterschied...

Falsch

#define Bool int

void foo() {
  int Bool = 1;
}

// vs.

typedef int Bool;

void foo() {
  int Bool = 1;
}

(Wobei ich wie Nexus auch ein enum nehmen würde)

general bacardi

camper schrieb:

Nexus schrieb:
enum BOOL
{
    FALSE,
    TRUE,
};

BOOL a = 3252; // Fehler
Das wäre in C allerdings kein Fehler.

Bei mir (Freescale-Compiler) gibt es eine Warnung, wenn ich einem enum-Typ etwas anderes zuweise.

unskilled

rüdiger schrieb:

unskilled schrieb:

C hat nun mal kein bool... (z.bsp.) die WinAPI ist aber in C geschrieben...

Falsch, siehe _Bool und stdbool.h

ok, wusste ich nicht, dass das mit dem 99er Standard eingeführt wurde^^
ist die winapi die einzige (wichtige) api, die trotzdem auf bool verzichtet oder hat das iwelche gründe?

rüdiger schrieb:

unskilled schrieb:

und ob man dort nun typedefs oder aber makros nimmt, macht imho ca. gar keinen unterschied...

Falsch
#define Bool int

void foo() {
  int Bool = 1;
}

// vs.

typedef int Bool;

void foo() {
  int Bool = 1;
}

naja - 1. ist es BOOL, 2. ist dieser nachteil von makros allg. bekannt 3. ist es dummheit, bezeichner á la BOOL zu nehmen

Ein bool-Ansatz wie in C++ ist schon das beste darauf wollte ich hinaus^^ ohne gibt es iwie immer nur halb-gute wege

bb

drakon

unskilled schrieb:

Falsch, siehe _Bool und stdbool.h

ok, wusste ich nicht, dass das mit dem 99er Standard eingeführt wurde^^
ist die winapi die einzige (wichtige) api, die trotzdem auf bool verzichtet oder hat das iwelche gründe?

Wie ich vermutet habe Abwärtskompatibilität:

http://blogs.msdn.com/oldnewthing/archive/2004/12/22/329884.aspx

Eigentlich liegt das doch auf der Hand, wenn man bedenkt, dass es Windows bereits vor 99 gegeben hat.

unskilled

drakon schrieb:

unskilled schrieb:

Falsch, siehe _Bool und stdbool.h

ok, wusste ich nicht, dass das mit dem 99er Standard eingeführt wurde^^
ist die winapi die einzige (wichtige) api, die trotzdem auf bool verzichtet oder hat das iwelche gründe?

Wie ich vermutet habe Abwärtskompatibilität:

http://blogs.msdn.com/oldnewthing/archive/2004/12/22/329884.aspx

Eigentlich liegt das doch auf der Hand, wenn man bedenkt, dass es Windows bereits vor 99 gegeben hat.

es gibt so viele dinge, die man über schalter lösen könnte(siehe NOMINMAX), das könnte man mit sicherheit auch dort tun... aber ty für link : >

bb

Nexus

camper schrieb:

Das wäre in C allerdings kein Fehler.

Oh, ich wusste gar nicht, dass das erst mit C++ kam. Aber dann scheint mir ein wichtiger Vorteil von enum in C wegzufallen. Gegenüber #define ist man bezüglich Scope, Debugsichtbarkeit und eventuellen Compilerwarnungen im Vorteil, aber wie verhält es sich mit const -Variablen? Besteht hier die einzige Verbesserung von enum darin, Konstanten nicht wegcasten zu können?

drakon

unskilled schrieb:

es gibt so viele dinge, die man über schalter lösen könnte(siehe NOMINMAX), das könnte man mit sicherheit auch dort tun... aber ty für link : >

bb

Wie meinst du das? - Ich fände es völlig sinnfrei die alten Library umschreiben zu gehen, nur damit da ein bool, anstatt ein BOOL steht.. (ich stelle mir gerade so vor, dass das irgendeinen Nebeneffekt geben würde und Code nicht mehr geht.. - Das wäre die wahre Wirtschaftskrise. :p)