Errors

FBIagent

Hab da schon wieder ne´n prob.

bekomme folgende fehlermeldungen:

main.c:5: error: parse error before "selection"
main.c: In function initial': main.c:11: error:false' undeclared (first use in this function)
main.c:11: error: (Each undeclared identifier is reported only once
main.c:11: error: for each function it appears in.)
main.c:21: error: `true' undeclared (first use in this function)

gier der QTXT:

//Include files
#include <stdio.h>
#include <conio.h>

bool selection;
char keypress;
int initialkey;

int initial(){
	selection=false;
	printf("Ein kleiner Taschenrechner.\n\n\n\n");
	printf("Wie willst du rechnen?\n\n");
	printf("[1]Addition,\n");
	printf("[2]Substraktion,\n");
	printf("[3]Multiplikation,\n");
	printf("oder [4]Division");

	initialkey=getch();
	switch(initialkey){
		case 1: selection=true;
				break;
		case 2: selection=true;
				break;
		case 3:	selection=true;
				break;
		case 4:	selection=true;
				break;

	}
}

int keypressed(){

	return 0;
}

//Mainfunction
int main(){
	initial();
	getch();
	return 0;
}

Warum diese fehlermeldungen, kann mir das ma einer erklären? vor allen dingen
den ersten error.

MFG FBI
THX

SideWinder

Scheint fast so als hättest du einen C-Compiler der den Datentyp 'bool' nicht kennt. Wenn dein Compiler C99 beherrst includiere mal stdbool

MfG SideWinder

MasterCounter

Verwende als Datentyp BOOL (nicht bool), musst dann evt. noch windows.h includieren... und schreib es vieleicht mal groß (FALSE TRUE)
vielleicht funktionierts!

oder mach es halt mit 0 und 1.

FBIagent

so funktionierts.

P.S.: Hab den MinGW Developer Studio

MasterCounter

Verwende als Datentyp BOOL (nicht bool), musst dann evt. noch windows.h includieren... und schreib es vieleicht mal groß (FALSE TRUE)
vielleicht funktionierts!

oder mach es halt mit 0 und 1.

rüdiger

@MasterCounter
bitte keine WinAPI-Kacke

supertux

MasterCounter schrieb:

Verwende als Datentyp BOOL (nicht bool), musst dann evt. noch windows.h includieren... und schreib es vieleicht mal groß (FALSE TRUE)
vielleicht funktionierts!

oder mach es halt mit 0 und 1.

Wenn wir hier damit anfangen, muss ich kotzen.

C kennt bool nicht, außer wenn man nach C99 programmier, wo man stdbool includieren muss. Wieso ist das so schwer zu begreifen?

SideWinder

Tu das bitte und nachdem ihr euch beruhigt habt merkt ihr, dass hinter der WinAPI-"Kacke" auch nicht viel mehr steckt als das was stdbool macht.

MfG SideWinder

Shade Of Mine

SideWinder schrieb:

Tu das bitte und nachdem ihr euch beruhigt habt merkt ihr, dass hinter der WinAPI-"Kacke" auch nicht viel mehr steckt als das was stdbool macht.

Exceptional C++ gelsen? bezüglich der Probleme eines #defines für bool?

Naja, aber stdbool.h definiert einen Native Typen _Bool - der ist wohl der WinAPI Kacke (warum Plattformunabhängigkeit aufgeben, weil man bool will? noch dazu wenn dieses bool dann BOOL heisst, was nichtmal in C reinpasst (alle typen sind dort nämlich klein geschrieben) überlegen.

Wenn man bool in C89 braucht, dann bitte selber typedef anlegen - wobei man dann normalerweise gleich int verwenden kann...

SideWinder

Von wegen plattformunabhängigkeit.

Wieso nennen sie den dämlichen Datentyp auch "_Bool" und nicht "bool" - damit C weiter eine Untermenge von C++ bleibt. Dann könnte man sich C sparen und in C++ entweder funktional oder objektorientiert programmieren. Nein da hat man sich gedacht "How to rescue *my* language?". Also mal schnell Dinge einführen die es in C++ nicht gibt und schon braucht man wieder einen eigenen Compiler für C.

Das ist natürlich sehr toll - alleine schon weil man seit neuestem Grunddatentypen includieren muss

Auf was ich raus will: Auf der einen Seite martern sie alle anderen bool-Datentypen per #define an die früher gemacht wurden weil es in C kein bool gab. Man soll jetzt den Standard-Typ nehmen weil der eben Standard ist. Auf der anderen Seite haben sie bei der Einführung ihres Standard-Typs peinlich genau darauf geachtet das der mit nichts mehr kompatibel ist was bisher war.

BTW: In C sind ja offenbar nicht mehr alle Typen kleingeschrieben...

MfG SideWinder

rüdiger

@SideWinder
die Sache ist einfach, dass bool so häufig benötigt wird, dass so gut wie jedes Projekt dafür einen Workarround hat. Hätte man nun mit C99 einfach bool eingeführt, wäre es zu Konflikten gekommen. Also _Bool nehmen (da es im reservierten Namespace liegt, den man ansonsten nicht benutzen darf) und für bool dann eben ein eigener Header

#ifndef cplusplus
#include <stdbool.h>
#endif

Wo ist das Problem? Unportabler und unpraktischer ist es da, die Platformabhängige windows.h einzubinden, weil man einen bool-Typ braucht.

Shade Of Mine

SideWinder schrieb:

Wieso nennen sie den dämlichen Datentyp auch "_Bool" und nicht "bool" - damit C weiter eine Untermenge von C++ bleibt. Dann könnte man sich C sparen und in C++ entweder funktional oder objektorientiert programmieren.

Wegen solchen Leute die gerne
#define bool int
schreiben.

Dadurch würde ein Native Typ bool diese Programme kaputt machen. Was natürlich nicht aktzeptable ist. Deshalb heisst der Typ _Bool und in stdbool.h gibt es ein typedef bool _Bool;

Und die Gründe C zu verwenden sollten offensichtlich sein:
Es ist verdammt einfach einen C Compiler zu schreiben - ein C++ Compiler ist nahezu unendlich kompliziert.

Nein da hat man sich gedacht "How to rescue *my* language?". Also mal schnell Dinge einführen die es in C++ nicht gibt und schon braucht man wieder einen eigenen Compiler für C.

Mit Ausnahme von VLA (was ja auch diskutiert wurde in C++ einzuführen) welche gravierende Änderung wurde denn eingeführt?
Klar, kleiner kompatibilitätsprobleme sind vorhanden - aber es kostet kaum Aufwand ein C Programm C++ kompatibel zu machen...

Das ist natürlich sehr toll - alleine schon weil man seit neuestem Grunddatentypen includieren muss

s. o. für Erklärung.
bool war halt überfällig - und mittlerweile gibt es zuviel Code der ein eigenes bool definiert hat - deshalb hat das Native bool den Namen _Bool

Auf was ich raus will: Auf der einen Seite martern sie alle anderen bool-Datentypen per #define an die früher gemacht wurden weil es in C kein bool gab. Man soll jetzt den Standard-Typ nehmen weil der eben Standard ist. Auf der anderen Seite haben sie bei der Einführung ihres Standard-Typs peinlich genau darauf geachtet das der mit nichts mehr kompatibel ist was bisher war.

Kompatibel mit was denn?
Kann ich kein bool b=a<c; oder ähnliches schreiben, oder was?

BTW: In C sind ja offenbar nicht mehr alle Typen kleingeschrieben...

Doch sind sie. Man soll _Bool ja nicht direkt verwenden, sondern bool verwenden.

SideWinder

Wenn man die WinAPI sowieso benötigt dann würde ich eher auf diese zurückgreifen. Das man den Typ in einen eigenen Header gepackt hat kann ich ja noch verstehen - aber das man ihn _Bool nennt nicht. Wer Probleme mit Namen hat includiert den Header nicht...

Naja meiner Meinung nach wars einfach zu spät. Die Sprache ist tot.

MfG SideWinder

SideWinder

Man kann auch einen rein funktionalen C++-Compiler schreiben. Wär ja alles kein Problem wenn C eine Untermenge sein würde. Naja 2 Sprachen sind viel toller. Man hat ja sonst keine zur Auswahl.

MfG SideWinder

Shade Of Mine

SideWinder schrieb:

aber das man ihn _Bool nennt nicht. Wer Probleme mit Namen hat includiert den Header nicht...

_Bool ist der echte Typ. dh, er ist auch ohne #include<stdbool.h> verfügbar.
in stdbool.h ist lediglich das typedef.

Naja meiner Meinung nach wars einfach zu spät. Die Sprache ist tot.

Ne, nur vom Desktop Bereich verdrängt. Mikrokontroller wird man noch Jahrzehnte lang mit C programmieren.

Man kann auch einen rein funktionalen C++-Compiler schreiben. Wär ja alles kein Problem wenn C eine Untermenge sein würde. Naja 2 Sprachen sind viel toller. Man hat ja sonst keine zur Auswahl.

Wie einfach kann man das?
klar, wenn man sich von EDG die Technik kauft, geht es schnell. Wenn man das Geld aber nicht ausgeben will oder kann - dann ist ein C Compiler wesentlich einfacher. Weil die Syntax wirklich simpel ist. Und Templates sind sowieso ein Horror für die Compilerhersteller.

Und C und C++ waren schon immer 2 Sprachen. Alleine die herangehensweise an Probleme ist ja total unterschiedlich. Und auch früher war keine 100% kompatibilität da.

SideWinder

_Bool also ein Typ, den man ab jetzt benützen kann. Der ist dank geschütztem Namensraum für Variablen auch sicher noch nicht vorhanden. Damit man den faulen Programmierern aber weiterhin den Namen "bool" bieten kann lässt man ihn diesen Namen sozusagen auf Abruf includieren. Das tut man natürlich nur wenn das Projekt nicht dummerweise schon selbst 10 Mal bool definiert hat und der Standardheader somit Probleme machen würde. Da die meisten Projekte aber bool bereits definiert haben und eine Umstellung immer nur Probleme macht wird erst wieder kaum jemand den neuen Typ verwenden.

BTW: C war niemals komplett Untermenge von C++? Das würde mich jetzt genauer interessieren. In welchen Punkten?

Die herangehensweise ist imho auch nicht unterschiedlich - man kann C++ genauso gut als rein-prozedurale (man Gott wieso will ich immer funktional schreiben :() Sprache verwenden und dann ist die Herangehensweise an Probleme imho sehr ähnlich wie in C.

Meiner Meinung nach ist C99 i-Tüpfel-Reiterei.

MfG SideWinder

SideWinder

BTW: Weil du gerade davon sprichst wie teuer es ist Compiler zu schreiben: Neuer Standard heißt meistens neuer Compiler bzw. zumindest Teile neu schreiben. Den Header und den Typ hinzufügen sollte kein Problem sein. Aber, mir kam zu Ohren, ich muss zugeben hier wenig informiert zu sein, dass es einen neuen Zeiger-Abkömmling gibt. Compiler adieu.

MfG SideWinder

Shade Of Mine

SideWinder schrieb:

BTW: C war niemals komplett Untermenge von C++? Das würde mich jetzt genauer interessieren. In welchen Punkten?

http://david.tribble.com/text/cdiffs.htm

Die herangehensweise ist imho auch nicht unterschiedlich - man kann C++ genauso gut als rein-prozedurale (man Gott wieso will ich immer funktional schreiben :() Sprache verwenden und dann ist die Herangehensweise an Probleme imho sehr ähnlich wie in C.

Selbst rein prozedual bietet C++ immer so sachen wie die STL und Templates. Das ermöglich, selbst wenn ich selber keine Klassen schreiben will (warum auch immer??) andere Möglichkeiten.

Natürlich _kann_ man C in C++ schreiben aber wie heisst es so schön "Fortran programmers can program FORTRAN in every langugae"

Dennoch sind es 2 unterschiedliche Sprachen.

Meiner Meinung nach ist C99 i-Tüpfel-Reiterei.

Inwiefern? Es gibt viele sinnvolle Neuerungen.

SideWinder

Du redest von Microkontrollern und wirfst C++ die STL vor? Seit wann funktioniert denn auf Microkontrollern die Standard-C-Library? Wenn ich die dort implementieren kann, kann ich die STL auch implementieren.

BTW: Auf der von dir geposteten Page finde ich den Teil nicht: "Programming elements of C89 which are not supported by ISO-C++"

MfG SideWinder

Shade Of Mine

SideWinder schrieb:

Du redest von Microkontrollern und wirfst C++ die STL vor? Seit wann funktioniert denn auf Microkontrollern die Standard-C-Library? Wenn ich die dort implementieren kann, kann ich die STL auch implementieren.

??
Der Aufwand eines C++ Compilers ist einfach unendlich viel größer als für einen C Compiler. Willst du das nicht verstehen?

Deshalb kann ich C auf jedem noch so kleinen Mikroprzessor zum laufen bekommen, weil man in kurzer zeit einen Compiler from Scratch schreiben kann - was bei C++ einfach nicht möglich ist.

Die STL, Exceptions, Templates,... sind Beispiele warum ein C Programm immer anders aussieht als ein C++ Programm. Wenn man keine STL, Exception und Templates hat und keine OOP verwendet, ja dann hat man C (und nicht C++)

BTW: Auf der von dir geposteten Page finde ich den Teil nicht: "Programming elements of C89 which are not supported by ISO-C++"

War früher, mit C99 wurde es eben upgedatet. Lies es dir mal durch. Es steht immer noch alles dort.