www.mikrocontroller.net

Forum: PC-Programmierung While-Schleife bei C++


Autor: Jürgen Münz (juergen00)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;
}

Autor: Rene H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
n hat einen undefinierten Wert, weil nie initialisiert. Das selbe gilt 
für Eingabe.

Und was soll das?
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kauf dir ein Buch übers Programmieren, vorzugsweise in C oder C++.
Dein "Programm" ist sowas von falsch...

Autor: Rene H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, n ist auch nicht definiert.
Nimm Dir erst mal ein C oder C++ Buch zur Hand. So wird das nichts.

Autor: Jürgen Münz (juergen00)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!!

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Denk einfachmal hierüber nach:
#include <iostream>

using namespace std;

int main(void){
 unsigned int eingabe;
 unsigned int summe = 0;

 cout << "Pogramm,das alle Ganzen Zahlen von 0 bis n addiert und die Summe ausgibt" << endl;
 cout << "Geben sie eine Zahl ein (0 zum Beenden): ";
 cin >> eingabe;
 for (int i=1; i<=eingabe; i++) summe += i;
 cout << "Die Summe der Zahlen von 0 bis " << eingabe << " ist " << summe << endl;
 return 0;
}

dann solltest du es als while-Schleife hinbekommen.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo komme jetzt nicht so aus der C++ Ecke, aber

Was ist "double eingabe = n ;"

Muss es nicht heissen
double eingabe; 
n ist zu diesem Zeitpunkt weder definiert noch deklariert;

Gruß Jörg

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Willst du echt in DEM Quelltext nach so banalen Fehlern wie nicht 
initialisierten Variablen suchen?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich dachte ich fange mal oben an ;-)

Jörg

Autor: Marcus Kunze (marcusk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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;

Autor: NurEinGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und immer wenn ich eine /2 lese bekomm ichs Kotzen.

Denk mal drüber nach du Held...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... und der OP wollte While-Schleifen lernen

Ich glaube, als erstes wollte er Deutsch lernen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Rene H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Marcus Kunze (marcusk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Rene H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schmeiss noch ein "en" nach ...

Autor: Olaf Dreyer (Firma: O.D.I.S.) (dreyero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Marcus Kunze

Spielverderber ;-)

Gruß

Olaf

Autor: Marcus Kunze (marcusk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur zur Info:

> (eingabe + 1) * eingabe

ist immer durch 2 Teilbar

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ;)

Autor: Marcus Kunze (marcusk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gast
> Shifts existieren
Ja, aber das kann doch bitte schön der Compiler entscheiden und nicht 
ich.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: NurEinGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Jürgen Münz (juergen00)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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();


};

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und arbeite an deiner Codeformatierung.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!)

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Trrrrriple Post! ;-)

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.