Hilfe, ich muss C lernen ... und schon fangen die Probleme an

Das habe ich nie behauptet. OOP ist eine Technik ein Werkzeug zu benutzen. Man kann schließlich wenn man mit dem Schraubenzieher auf eine Schraube eindrischt, diese vielleicht ins Holz versenken, aber es geht gewiss auch leichter...

Und OO ist für komplexe Systeme nur ein Hilfsmittel. Sie erlaubt aber, leichter ein sauberes Softwaredesign einzuhalten.

Genau, eigentlich sind wir uns ja einig ;)

Ich glaube, der Grund warum wir das überhaupt diskutieren ist dass du (vermutlich) ehr aus der Anwendungsprogrammierung kommst und ich aus dem Embedded Bereich wo prozeduale Programmierung noch lange nicht tot ist.
 
Oh ich bin mir der Probleme im Embedded-Bereich sehr bewußt. OO erzeugt immer größeren Footprint und verlangsamt die Laufzeit der Programme durch höheren Aufwand im Speichermanagement. Darum bastelt ihr ja auch mehr mit C und Co. Allerdings ist der Embedded-Bereich nun nicht der Standard-Fall der Software-Entwicklung. Die Meisten sind Anwendungsentwickler (wie ich auch). Da ist OO ein Segen, zusammen mit der Verwendung der richtigen Design Pattern.

Der Grund, warum ich Anfängern eher eine Sprache ohne händische Speicherverwaltung empfehle ist aber eher der, dass sie sich so mehr auf die Algorithmen konzentrieren können. Das ist oftmals Herausforderung genug. Es ist schon frustrierend, wenn ein Algorithmus das Programm nicht richtig laufen läßt, eine falsche Speicherverwaltung ist es oft um so mehr (Ich erinner mich da an meine Anfänge vor 10 oder 15 Jahren).
 
ihr seid ganz schön OT....
 
Stimmt, mir war aber so, als seien die Probleme des TO gelöst gewesen. Trotzdem denke ich sind die Positionen geklärt.
 
Ich hänge mich mal hier rein, hab da nämlich auch eine Frage.
Mein Programm sieht wie folgt aus:
Code:
#include <stdio.h>
double division (int,int);

int main ()
{
	int a,b;
	double c;
	a=b=c=0;
	printf ("Bitte Division eingeben (Format: a/b):");
	scanf ("%d/%d", a, b);
	if (b==0)
		printf ("Division durch 0");
	else if ((a%b)!=0)
		printf ("Nicht teilbar");
	else
		c=divison(a,b);
		printf ("%d/%d=%f",a,b,c); 
	return 0;
}

double division (int a,int b)
{
	return a/b;
}

Nach dem kompilieren lässt sich das Programm auch starten, allerdings wird für jede Eingabe „Bus Error“ ausgegeben. Kann mir da jemand helfen, bitte? Möglichst Einsteigerfreudlich wäre nett, mach das ganze auch erst seit einer Woche.
 
Im scanf() musst du die Variablen mit & als Zeiger übergeben.


BTW: Was soll das "a=b=c=0" eigentlich noch in Zeiten hochoptimierender Compiler bringen?
 
ohne a=b=c=0 davor gabs immer probleme beim kompilieren mit xcode.

Den gleichen gibt es allerdings auch wenn ich schreibe: scanf ("%d/%d", &a, &b):

Building target “A3” of project “A3” with configuration “Release” — (1 error)
cd "[...]/AB3/A3"
/Developer/usr/bin/gcc-4.0 -o "[...]/AB3/A3/build/A3.build/Release/A3.build/Objects-normal/ppc/A3" "-L/[...]/AB3/A3/build/Release" "-F[...]/AB3/A3/build/Release" -filelist "[...]/AB3/A3/build/A3.build/Release/A3.build/Objects-normal/ppc/A3.LinkFileList" -arch ppc -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk
Undefined symbols:
"_divison", referenced from:
_main in A3.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
"_divison", referenced from:
_main in A3.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
Build failed (1 error)

Muss ich, um mit a und b weiter arbeiten zu können noch etwas anderes beachten?
 
ohne a=b=c=0 davor gabs immer probleme beim kompilieren mit xcode.
Sicher nicht, wenn du a=0; b=0; c=0; schreibst. Aber es wäre natürlich interessant zu wissen, welche Probleme es mit "Xcode" gab.

ohne Den gleichen gibt es allerdings auch wenn ich schreibe: scanf ("%d/%d", &a, &b):
Nein, hier gibt es andere Probleme, wie du siehst.

Building target “A3” of project “A3” with configuration “Release” — (1 error)
cd "[...]/AB3/A3"
/Developer/usr/bin/gcc-4.0 -o "[...]/AB3/A3/build/A3.build/Release/A3.build/Objects-normal/ppc/A3" "-L/[...]/AB3/A3/build/Release" "-F[...]/AB3/A3/build/Release" -filelist "[...]/AB3/A3/build/A3.build/Release/A3.build/Objects-normal/ppc/A3.LinkFileList" -arch ppc -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk
Undefined symbols:
"_divison", referenced from:
_main in A3.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
"_divison", referenced from:
_main in A3.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
Build failed (1 error)

Muss ich, um mit a und b weiter arbeiten zu können noch etwas anderes beachten?
Er findet das Symbol nicht. Ich habe mutmaßlich auch Tomaten auf den Knöppen, sehe es jedenfalls nicht. Kannst du den Code noch einmal vollständig posten.

BTW: Der Returntype von division() ist blöde: int/int gibt einen int. Aber das ist jetzt nicht das Problem.
 
s/divison/division/

Ich hab mich auch über den Fehler gewundert...

Des weiteren ist die if/elseif/else Kette nicht geklammert, was im else-block unter bestimmten Umständen zu einem Laufzeitfehler führen wird.
 
s/divison/division/

Ich hab mich auch über den Fehler gewundert...

Des weiteren ist die if/elseif/else Kette nicht geklammert, was im else-block unter bestimmten Umständen zu einem Laufzeitfehler führen wird.

Ja, ich habe auch erst nicht gesehen, das da ein übler Rechtschreibfehler ist. Das menschliche Auge korrigiert halt viel zu schnell :)

zum 2ten
Meine Regel daher:
IMMER geschweifte klammer schreiben, auch wenn ich nur eine zeile ausführen will.
 
Code:
#include <stdio.h>
double division (int,int);

int main ()
{
	int a,b;
	double c;
	a=b=c=0;
	printf ("Bitte Division eingeben (Format: a/b):");
	scanf ("%d/%d", [B]&[/B]a, [B]&[/B]b); [B]//variablen bekommen immer werte zugewiesen. damit die auch an die richtige stelle geschrieben werden,  deutet man mit & auf die adresse der variable a und b. ohne klappt eine eingabe nicht[/B]
	if (b==0)
		printf ("Division durch 0\n");
	else if ((a%b)!=0)
		printf ("Nicht teilbar\n");
	else
		c=division(a,b);
		printf ("%d/%d=%.2f\n",a,b,c); 
	return 0;
}

double division (int a,int b)
{
	return a/b;
}

hab mal etwas fehlerkorrektur betrieben. ansonsten fehlen da nur kommentare. die klammerung is in diesem fall nicht notwendig, aber es ist ein besserer programmierstil, wenn man anweisungen in blöcken schreibt.
 
Zuletzt bearbeitet:
Du willst also in *jedem* Fall das letzte printf ausführen lassen? Deine Einrückung sagt mir etwas anderes. Das ist nicht Python!
 
das programm läuft. die bedingungen werden geprüft und dann werden die entsprechenden verzweigungen eingeschlagen. das letzte printf gibt nochmal die rechnung aus. was ich persönlich gar nicht so verkehrt finde.


die einrückung is durch copy&paste etwas verloren gegangen. aber zum glück is das in C/C++ eh wurst...
 
Zuletzt bearbeitet:
Zu indirekten Übergabe:
IndirekterParameter.pdf
 
Naphanel schrieb:
das letzte printf wird nur geschrieben, wenn die bedingungen in den anderen fällen nicht zutrifft.

Nein! Das printf steht in keiner Bedingung und es wird ergo immer ausgeführt!


ist hier unnötig da per modulo geprüft wird ob eine Ganzzahl Division möglich ist. Int wäre die bessere Wahl.


wenn schon double c; dann bitte auch c=0.0; !
 
Das Programm läuft, aber gibt es das richtige aus?

Code:
$ make div
$ ./div
Bitte Division eingeben (Format: a/b):3/4
Nicht teilbar
3/4=0.00
$

Richtig nur dann, wenn das Ergebnis *immer* ausgegeben werden soll. Es werden aber Nachkommastellen angegeben, die ebenfalls 0 sind. Ich würde meinen Schülern/Studenten die Ohren lang ziehen.

Ich würde einem Anfänger empfehlen, die Klammern zu setzen. Das hilft gegen Verwirrungen.
 
Nein! Das printf steht in keiner Bedingung und es wird ergo immer ausgeführt!

yo...hab's selbst gemerkt...is noch früh :shame:

@ebm


ich würd's auch völlig anders angehen, als hier gemacht. aber für einen anfänger is das schonmal nich schlecht. jetzt gilt's verbesserungsvorschläge zu machen. schreibstil is ja schon genannt.
 
_ebm_ schrieb:
Ich würde einem Anfänger empfehlen, die Klammern zu setzen. Das hilft gegen Verwirrungen.

ich empfehle das IMMER zu tun, auch als runaway :)

Es kommt oft genug noch 1 Befehl hinzu und dann noch einer...
Bessere Lesbarkeit reduziert Fehler!

ich klammere nicht nur, ich kommentiere auch a la:

} // end if ...
} // end of method ...


denn kaum etwas ist schlimmer als

}
}
}
 
Ich programmiere immer so überlegt, dass sich da nichts mehr ändert *grins*

Nein, Spaß beiseite, ich gebe dir recht. Gerade bei tief verschachtelten if's sind Kommentare wichtig. Du bist übrigens nicht ANSI-C Konform. C erlaubt nur /* */. // kam in C++ hinzu.
 
wegus hat die softwarekrise erlebt. :)
 
Zurück
Oben Unten