hey leute,
bei einer eingabe von einer ganzzahl n>0,
in einem programm, das alle zahlen von 0 bis n addiert und die summe
ausgibt,
hier habe ich schon ma versucht was zu machen aber bei eingabe =n zeigt
er immer fehler an kann mir jemand sagen warum und helfen,
vielen dank schon im vorraus
mfg
# include <iostream>
#include <string>
#include <conio.h>
using namespace std;
int main ()
{
double eingabe =n ;
while (ergebnis n <= ++var)
{
cout << "Pogramm,das alle Zahlen von 0 bis n addiert und die Summer
ausgibt" <<endl;
cout << "Geben sie eine Zahl ein (0 zum Beenden): ";
cin >> eingabe;
cout << "Die Summe " <<ergebnis <<" ist " <<eingabe++var <<endl;
}
return 0;
}
n hat einen undefinierten Wert, weil nie initialisiert. Das selbe gilt für Eingabe. Und was soll das?
1 | while (ergebnis n <= ++var) |
Wo ist var definiert? Und was soll ergebnis n sein? Und mach bitte in Deinen Texten ab und an mal ein "." rein. Macht es wesentlich lesbarer.
Kauf dir ein Buch übers Programmieren, vorzugsweise in C oder C++. Dein "Programm" ist sowas von falsch...
Ach ja, n ist auch nicht definiert. Nimm Dir erst mal ein C oder C++ Buch zur Hand. So wird das nichts.
ja vieleicht verständlicher n soll meine eingabe wert sein und und das programm soll hoch zäheln so hoch zählen das 0 + 1+2+3 und so weiter
Kauf dir als erstes nen Buch über Rechtschreibung und Zeichensetzung. Wenn du das durch hast, kannst du dir ein Buch über C++ kaufen und durcharbeiten. Wenn du das auch erledigt hast, kannst du hier bei Problemen nochmal fragen.
So, jetzt aber Jürgen. Wenn das ein Spiel sein soll, ich geb euch Wörter, macht Sätze draus, ok. Na gut, dann sag das. Wenn Du willst Das wir Deine Hausaufgaben lösen, dann wird das nichts. Schon gar nicht wenn Du zu faul bist einen anständigen Text zu schreiben mit Satzzeichen. Gross/Klein wäre toll, muss aber nicht sein. Setz Dich hin, versuche Dein Problem so auszudrücken, das man es auch verstehen kann. Bitte in Deutsch!!!
Denk einfachmal hierüber nach:
1 | #include <iostream> |
2 | |
3 | using namespace std; |
4 | |
5 | int main(void){ |
6 | unsigned int eingabe; |
7 | unsigned int summe = 0; |
8 | |
9 | cout << "Pogramm,das alle Ganzen Zahlen von 0 bis n addiert und die Summe ausgibt" << endl; |
10 | cout << "Geben sie eine Zahl ein (0 zum Beenden): "; |
11 | cin >> eingabe; |
12 | for (int i=1; i<=eingabe; i++) summe += i; |
13 | cout << "Die Summe der Zahlen von 0 bis " << eingabe << " ist " << summe << endl; |
14 | return 0; |
15 | }
|
dann solltest du es als while-Schleife hinbekommen.
Hallo komme jetzt nicht so aus der C++ Ecke, aber Was ist "double eingabe = n ;" Muss es nicht heissen
1 | double eingabe; |
n ist zu diesem Zeitpunkt weder definiert noch deklariert; Gruß Jörg
Willst du echt in DEM Quelltext nach so banalen Fehlern wie nicht initialisierten Variablen suchen?
@Gast
> for (int i=1; i<=eingabe; i++) summe += i;
wir habe zwar heute schnelle cpus, aber man doch ein wenig optimieren
summe = (eingabe + 1) * eingabe / 2;
> wir habe zwar heute schnelle cpus, aber man doch ein wenig optimieren
Es wird immer unverständlicher.
Dieser Satz muss wohl in einer mir unbekannten Sprache geschrieben sein
:-)
... und der OP wollte While-Schleifen lernen, nicht die Laufzeit
optimieren.
und immer wenn ich eine /2 lese bekomm ichs Kotzen. Denk mal drüber nach du Held...
Marcus Kunze schrieb: > @Gast >> for (int i=1; i<=eingabe; i++) summe += i; > > wir habe zwar heute schnelle cpus, aber man doch ein wenig optimieren > > summe = (eingabe + 1) * eingabe / 2; :-) Prinzipiell ja. Aber darum gehts bei diesem Übungsbeispiel im Grunde gar nicht. Hier ist der Weg das Ziel. Und wie man sieht, ist der Weg noch weit.
> ... und der OP wollte While-Schleifen lernen
Ich glaube, als erstes wollte er Deutsch lernen.
Gast schrieb: > und immer wenn ich eine /2 lese bekomm ichs Kotzen. > > Denk mal drüber nach du Held... Und warum bekommst du da das Kotzen? (Ich bekomme immer das Kotzen, wenn Leute ihre Compilerbauer für Vollidioten halten, die ihrem Compiler absichtlich nicht beibringen, dass unter bestimmten Umständen ein /2 identisch ist zu einmal schieben nach rechts).
Gast schrieb: > und immer wenn ich eine /2 lese bekomm ichs Kotzen. > > Denk mal drüber nach du Held... Nicht immer, bei Fliesskomma-Operation macht das durchaus mal Sinn. ;-)
@NurEinGast > ... und der OP wollte While-Schleifen lernen, nicht die Laufzeit > optimieren. Seit wann ist die for Schleife ein while Schleife? (die von Gast) @gast > und immer wenn ich eine /2 lese bekomm ichs Kotzen. > Denk mal drüber nach du Held... Dann Teste erstmal bevor du etwas schreibst.
Shifts existieren, und das gilt nicht nur für das Geschreibsel des OP. Und das Aufsummieren ALLER Fließkommazahlen von 0 bis irgendeinem n > 0 stell ich mir auch spannend vor.
> Und das Aufsummieren ALLER Fließkommazahlen von 0 bis irgendeinem n > 0 > stell ich mir auch spannend vor. ok, wenn man nur die darstellbaren Fließkommazahlen nimmt, ist es zumindest lösbar ;)
@Gast
> Shifts existieren
Ja, aber das kann doch bitte schön der Compiler entscheiden und nicht
ich.
Gast schrieb:
> Shifts existieren, und das gilt nicht nur für das Geschreibsel des OP.
optimierende Compiler existieren ebenfalls.
Das was du da andeutest, ist eine der trivialsten Optimierungen die ein
Compiler überhaupt nur machen kann.
Wenn /2 am klarsten ist, dann schreibe auch /2. Den Rest macht der
Compiler.
Tja, sag das der Optimierungs Voreinstellung. Abgesehen davon sollte man wenn man sich schon damit brüstet optimieren zu wollen sowas auch mal selber bedenken. Ich bin ansonsten auch immernoch der Meinung das für hinreichend kleine n die Summierung schneller läuft als die Berechnung mit Multiplikation und Division, nicht das es dem OP darum gegangen wäre...
@Marcus Kunze >> ... und der OP wollte While-Schleifen lernen, nicht die Laufzeit >> optimieren. > >Seit wann ist die for Schleife ein while Schleife? (die von Gast) Gast Schrieb : > Denk einfachmal hierüber nach: Dann hat er das Problem mit einer FOR Schleife verdeutlicht. Dann schrieb er > dann solltest du es als while-Schleife hinbekommen. Er wollte also dem OP das Prinzip verständlich machen, ihm aber nicht einfach nur die fertige Lösung hinwerfen.
Gast schrieb: > Tja, sag das der Optimierungs Voreinstellung. Würde mich nicht wirklich wundern, wenn die meisten Compiler diese Trivialoptimierung selbst dann machen, wenn der Optimizer ausgeschaltet ist. > Abgesehen davon sollte man > wenn man sich schon damit brüstet optimieren zu wollen sowas auch mal > selber bedenken. Nein. Genau solche Dinge sollte man eben NICHT selber bedenken. Du musst endlich von der Vorstellung weg, dass du irgendjemanden etwas Gutes damit tust, wenn du dich um solche Trivialoperationen selber kümmerst. Das genaue Gegenteil ist der Fall. Kümmere dich um den Algorithmus, kümmere dich um vernünftige Datentypen, kümmere dich darum dass dein Code gut lesbar und wartbar ist. Aber lass um Himmels Willen derartige Trivialtransformationen den Compiler machen! > Ich bin ansonsten auch immernoch der Meinung das für hinreichend kleine > n die Summierung schneller läuft als die Berechnung mit Multiplikation > und Division, nicht das es dem OP darum gegangen wäre... Das wäre ein Argument. Aber das ist nicht gekommen.
Jop, das war in etwa mein Ansinnen, ähnliche for-Schleife, Variablen Deklaration und Initialisierung mit richtgen Typen, aber eben ohne eine gesamte While-Schleife oder die Berücksichtigung eines Abbruchs.
Also wenn mir ein Compiler unter kommt, der bei eingeschalteter Optimierung / 2 nicht durch einen shift erledigt*, dann tret ich den Compiler in die Tonne, und schreib nicht >>1 ins Programm. *Es sei denn die Hardware kann zufällig genau so schnell dividieren, wie shiften ;)
danke an alle die versucht haben mir zu helfen,
ich hab es selber hin bekommen
#include <cstdlib>
#include <iostream>
#include <conio.h>
using namespace std;
int main ()
{
int n, i=0;
cout <<" Gib eine Ganzzahl ein: ";
cin >> n;
long sum=0;
while (i <= n)
{
sum = sum+i;
i=i+1;}
cout << " Die Summeder ersten " << n << " Ganzzahlenbetraegt: " <<
sum << endl;
getch();
};
Wie du willst Karl Heinz, ist müßig sich mit dir darüber zu streiten, insbesondere da du mit sowas bei den meisten Optimierungen und Compilern wohl recht haben wirst. Ich für meinen Teil bleibe dabei das Leute die optimieren wollen wissen sollten was der Compiler draus macht und ein Gefühl für Optimierungen haben. Ab und an mal einen Profiler drüber und auch ein Blick in den ASM Teil schadet da nicht und zeigt, zugegeben auf nicht x86 Plattformen, doch manchmal das die Optimierung nicht so doll ist.
Gast schrieb: > Wie du willst Karl Heinz, ist müßig sich mit dir darüber zu streiten, > insbesondere da du mit sowas bei den meisten Optimierungen und Compilern > wohl recht haben wirst. Nicht nur wohl. Du würdest dich wundern, was Compiler aus solchen trivialen Operationen machen. Oder schreibst du etwa x = ( ( y << 2 ) + y ) << 1; als Ersatz für x = 10 * y; Die meisten Compiler machen diese Ersetzung, wenn sie sich lohnt (CPU-abhängig) und haben bei anderen Zahlen noch ganz andere Tricks drauf. Aber der springende Punkt ist: Der Compiler macht dabei keine Fehler. Änderst du y von int auf long, geht obige Optimierung weiterhin. Änderst du den long in double, geht sie nicht mehr. Der Compiler berücksichtigt das. Aber ob der Programmierer beim Wechsel des Datentyps daran denkt, ist mehr als fraglich. Man kann also mit Fug und Recht behaupten, dass sich hier der Programmierer unnötigerweise ein Eigentor geschossen hat. > Ich für meinen Teil bleibe dabei das Leute die optimieren wollen wissen > sollten was der Compiler draus macht und ein Gefühl für Optimierungen > haben. Eben. Aber du lenkst das Gefühl in die falsche Richtung. Vor 30 Jahren war es noch cool, solche Ersetzungen zu kennen. Heute schmeisst dir jeder Vorgesetzte den Code um die Ohren, wenn du so etwas machst. Optimieren ja. Aber nur dann wenn es sich lohnt. Und wenn ja, fängt man beim Algorithmus an und nicht bei Low-Level Operationen, es sei denn der Profiler hat gezeigt, dass es dort ein Problem gibt und das Assembler Listing hat gezeigt, dass man noch ein paar Nanosekunden schinden kann.
Karl heinz Buchegger schrieb:
> Vor 30 Jahren war es noch cool, solche Ersetzungen zu kennen.
Auch mit dem Hintergedanken, dass derartige Optimierungen auf praktisch
allen CPUs gegriffen haben.
Heute ist das nicht mehr so. Was auf einer CPU schnell ist, kann auf der
nächsten saulangsam sein. Der Compiler kennt seine Zielarchitektur und
sucht sich die Operation raus, die gut geht (Ich würde an dieser Stelle
gerne schreiben 'die optimial ist', aber das ist vermessen und in der
Praxis nicht immer so)
Ich habe Wochen damit verbracht einen Hiddenliner auf einem 486 mittels
Integerarithmetik auf schnell zu trimmen und die Probleme, die durch die
grobe Diskretisierung entstehen in den Griff zu kriegen.
Ein plain vanilla Rewrite auf einem Pentium mit doubles hat diese
int-Optimierung aber sowas von ausgehebelt (Coprozessor!)
> Du würdest dich wundern, was Compiler aus solchen trivialen Operationen > machen. > Oder schreibst du etwa > > x = ( ( y << 2 ) + y ) << 1; > > als Ersatz für > > x = 10 * y; > > Die meisten Compiler machen diese Ersetzung, wenn sie sich lohnt > (CPU-abhängig) Genau. Insbesondere kann es auch langsamer sein, wenn die CPU einen Multiplizierer, aber keinen Barrelshifter hat. > Ich für meinen Teil bleibe dabei das Leute die optimieren wollen wissen > sollten was der Compiler draus macht und ein Gefühl für Optimierungen > haben. Ab und an mal einen Profiler drüber und auch ein Blick in den ASM > Teil schadet da nicht und zeigt, zugegeben auf nicht x86 Plattformen, > doch manchmal das die Optimierung nicht so doll ist. Dieser Blick zeigt auch manchmal, daß gut gemeinte "Optimierungen" von Hand nicht unbedingt immer eine Verbesserung bewirken. Daher sollte man, wenn's einem denn so wichtig ist und Portabilität nicht so die Rolle spielt, gleich Assembler nutzen, und wenn nicht, dem Compiler die Optimierungen überlassen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.