3. Aufgabe so gut gelöst?

Aufgabe so gut gelöst?

  • V

    Aufgabenloeser schrieb:

    Da freu ich mich auch schon drauf, new und delete ja schon etwas!
    meinst du das:

    int size = 1024;
int* array = new int[size]
delete[] array

    ????

    ja, genau.

    also

    class SortedArray{
private:
   int size;
   int *array;
   int anzahl;
public:
   SortedArray(){
      size=10;//oder irgendwas
      array=new int[size];
      anzahl=0;//ups, das hätte auch der alten lösung gefehlt
   }
   void grow(int newSize){
      //neuen speicher in größe newSize anlegen
      //alle alten werte reinkopieren
      //alten speicher löschen
      //ja, ist trickreich und schwierig. naja, vielleicht schaffstes. 
   }
   void push(int x){
      if(anzahl==size)
          grow(2*size);
      array[anzahl]=x;
      int i=anzahl-1;
      while(i>=0 && array[i]>array[i+1]){
         swap(array[i],array[i+1]);
         --i;
      }
      ++anzahl;
   }
   void print(){
      for(int i=0;i<=anzahl;++i)
         cozt<<array[i]<<' ';
   }
};
int main(){
   SortedArray a;
   for(;;){//endlosschleife vermeidet hier möglicherweise doppelten code
      int x;
      cin>>x;
      if(x==0)
         break;
      a.push(x);
   }
   a.print();
}
    0
  • H

    volkard schrieb:

    du kannst ja mal versuchen, den nubes alles auf einmal gleichzeitig beizubringen. viel spaß dabei.

    Das ist imo jetzt etwas unfair. Ich bin ja überhaupt nicht dafür alles aufeinmal zu machen. Ganz im Gegenteil. Ich würde z.B. nicht erwarten, dass der Anfänger sich gleich mit x Problemen gleichzeitig beschäftigen muss (Memory-Management, Sortieren, Eingabe/Ausgabe). Man kann doch z.B. das Schritt für Schritt machen.
    Eine Lektion wo es um Sortieren eines Arrays geht (mit fester Größe). Eine Lektion wie man Benutzereingaben macht. Eine Lektion über dynamische Speicherverwaltung. Und am Ende, wenn die Basics sitzen, macht man eine Aufgabe die alles kombiniert (wie hier).
    Gleichzeitig würde ich behaupten, dass der Einstieg in eine Sprache wie C nunmal nicht so leicht geht wie der Einstieg in eine freundliche Scriptsprache. C erfordert vom Programmierer halt doch etwas mehr Aufmerksamkeit.

    Mir erscheint es nur etwas komisch, dass man erst anfängt jemand etwas falsch beizubringen nur um dann später hinterm Busch hervorzuhüpfen und zu verlangen, dass von nun an alles anders gemacht wird. Das erinnert mich an einen C-Kurs den ich mal gemacht habe. Erst haben wir 100 Stunden lang gets verwendet nur um dann in der letzten Stunde zu lernen, dass man gets in einem echten Programm niemals nie verwenden sollte.

    Wieso ist der code denn nicht verständlich?

    volkard schrieb:

    weil die profis nur code zulassen, der so aussieht:

    #include <iostream>
#include <vector>
#include <algorithm>
#include <iterator>
using namespace std;

int main(){
	vector<int> v;
	copy(istream_iterator<int>(cin),istream_iterator<int>(),back_inserter(v));
	sort(v.begin(),v.end());
	copy(v.begin(),v.end(),ostream_iterator<int>(cout," "));
}

    Das war nicht mein Punkt.
    Ich bezog mich auf:

    for(;;){//endlosschleife vermeidet hier doppelten code
      cin>>array[anzahl];//neuen wert hinten eintragen
      if(array[anzahl]==0)
         break;
      int i=anzahl-1;
      while(i>=0 && array[i]>array[i+1]){
         swap(array[i],array[i+1]);
         --i;
      }
      ++anzahl;
   }

    Und das ist meiner Meinung nicht verständlich, weil es nicht sagt was hier passiert. Vielmehr muss ich mir die Semantik Stück für Stück Zeile für Zeile
    selbst zusammenreimen.
    Zwei drei gut benannte Funktionen draus gemacht und gut ist.

    Aber ich will mich hier auch nicht mit dir streiten. Wollte nur meine 0,02 Euro beitragen und hätte nicht gedacht, dass du da so stark anderer Meinung bist.

    Vielleicht hilft ein adaptiertes Scott Meyers' Zitat:
    "When in doubt, do as Don Volkard does."

    0
  • V

    HumeSikkins schrieb:

    Das ist imo jetzt etwas unfair.

    ich fand es auch ein wenig unfair, wie du mein supa-dupa-programm verreißen wolltest.

    Mir erscheint es nur etwas komisch, dass man erst anfängt jemand etwas falsch beizubringen nur um dann später hinterm Busch hervorzuhüpfen und zu verlangen, dass von nun an alles anders gemacht wird. Das erinnert mich an einen C-Kurs den ich mal gemacht habe. Erst haben wir 100 Stunden lang gets verwendet nur um dann in der letzten Stunde zu lernen, dass man gets in einem echten Programm niemals nie verwenden sollte.

    und genau hier sehe ich deinen einwand nicht. ich schlage doch gar nichts vor, was wan später vergessen soll, sondern ich lasse nur sachen weg (lauter langweilige fehlerprüfungen, und das wachsen-lassen).
    du könntest natürlich der meinung sein, daß man niemals selber algorithmen entwickeln oder eigene datenstrukturen stricken sollte (und ich dachte, das sei die haupt-aufgabe). dann isses natürlich verkehrt, sowas zu machen. dann nimmt man die paar aus std:: als blackbox und fertig.

    ich frage einfach mal Aufgabenloeser: findest du das gut so, daß ich zuerst die falsche lösung zeige mit einer festen größe von 1024 und dann hinterm busch hervorhüpfe und sage, mit new/delete könnte man noch zaubern, daß das array von aleine wächst? hast du das gefühl, schrecklich geschädigt zu sein und in zukunft feste arrays zu nehmen, wo dynamische arrays (mit new) besser wären?
    oder wäre es dir lieber gewesen, ich hätte dir erstmal new/delete einzeln beigebracht und erst nachdem new/delete sitzt, die verraten, wie man die aktuelle aufgabe fein lösen könnte?

    Ich bin ja überhaupt nicht dafür alles aufeinmal zu machen. Ganz im Gegenteil. Ich würde z.B. nicht erwarten, dass der Anfänger sich gleich mit x Problemen gleichzeitig beschäftigen muss (Memory-Management, Sortieren, Eingabe/Ausgabe). Man kann doch z.B. das Schritt für Schritt machen.
    Eine Lektion wo es um Sortieren eines Arrays geht (mit fester Größe). Eine Lektion wie man Benutzereingaben macht. Eine Lektion über dynamische Speicherverwaltung. Und am Ende, wenn die Basics sitzen, macht man eine Aufgabe die alles kombiniert (wie hier).

    das läßt sich keiner gefallen. und ich sehe auch keinen vorteil darin, in einem programm immer alles perfekt zu haben. meine programme zeigen oft undefiniertes verhalten für nicht zugelassene eingaben. ich bin also entweder bei 1394 stehengeblieben oder schon bei 2426 angekommen.
    eingabeprüfung bei so einem prog ist für mich ui und irrelevant.

    Und das ist meiner Meinung nicht verständlich, weil es nicht sagt was hier passiert. Vielmehr muss ich mir die Semantik Stück für Stück Zeile für Zeile
    selbst zusammenreimen.
    Zwei drei gut benannte Funktionen draus gemacht und gut ist.

    natürlich ist
    [cpp]

    void insertSorted(int* begin,int* end){
    while(end!=begin && *end>*begin){
    swap(*begin,*end);
    --end;
    }
    }

    [/cpp]
    oder sowas ein toller bringer in sachen übersichtlichgkeit. normalerweise hat eine schleife auch einen benennbaren zweck, und benennbarer code sollte benannter code sein. und benannter code == funktion. also sollten normalerweise keine verschachtelten schleifen sichbar sein. ich habe aber die erfahrung gemacht, daß nubes gerade da durcheinanderkommen, währen mal eine kleine verschachtelte schleife noch bequem drin ist. das sind mehr programmier-taktiker, weniger design-strategen. also hab ich auf die funktion verzichtet, weil es gerade um andere dinge geht.

    Vielleicht hilft ein adaptiertes Scott Meyers' Zitat:
    "When in doubt, do as Don Volkard does."

    dann hätte ich ja nichts mehr zu meckern.

    0
  • ?

    wow, ihr müsst euch nich wegen mir streiten 😞

    also:

    ich versteh ja schonmal nich alles was ihr erzählt, aufjedenfall bin ich der meinung, das(gerade bei c++), man sich stück für stück vorarbeiten sollte!

    Daher auch der sort selber geschrieben, und keine fehlerüberprüfung (weil ich das hier für meine zwecke nicht braucht, da ich nur eine klasse mit der funktionalität wollte, und keine perfekte klasse)!

    volkard schrieb:

    ich frage einfach mal Aufgabenloeser: findest du das gut so, daß ich zuerst die falsche lösung zeige mit einer festen größe von 1024 und dann hinterm busch hervorhüpfe und sage, mit new/delete könnte man noch zaubern, daß das array von aleine wächst? hast du das gefühl, schrecklich geschädigt zu sein und in zukunft feste arrays zu nehmen, wo dynamische arrays (mit new) besser wären?
    oder wäre es dir lieber gewesen, ich hätte dir erstmal new/delete einzeln beigebracht und erst nachdem new/delete sitzt, die verraten, wie man die aktuelle aufgabe fein lösen könnte?

    so um ehrlich zu sein:

    ich finde das so bedeutend besser, weil erstens new und delete wohl etwas "komplizierter" sind als einfach was aufm stack ablegen(also denk ich mal), und weil diese methode mehr lerneffekt hat.

    und das "ausm busch hervorhüpfen" hat einfach etwas, was man sich eher einprägt (weil man sich daran eher erinnert)!

    Und nein, gerade deswegen werde ich wohl eher new nehmen, weil man durch so einen eingehenden hinweis(mit schlechtem beispiel, wo man gleich gesehen hat wie es falsch ist)sich schneller an die richtige art gewöhnt!

    Und weiterhin glaube ich auch, das man nur die besser möglichkeit benutzen kann, und vorallem versteht, wenn man die schlechte auch kennt!

    NATÜRLICH ist das aber eine subjektive meinung, jeder is da vielleicht anders!

    ich möchte auch nicht das ihr euch jetzt streitet!

    Ich war aufjeden fall forh das meine klasse funktioniert hat 👍 , da ich nebenbeiu noch php und html lerne!

    Aber ich bin immer für verbesserungen zu haben!

    Also gebt mir ein stück eurer weisheit bitte, denn ihr scheint es ja alle (auch wenn ihr verschiedeneer meinung seit) mehr als zu beherrschen, und wenn ich mehrere möglichkeiten später habe, bin ich natürlich froh!

    Nur verlangt bitte nicht das ich templates und vectoren kann, wenn ich noch NIE damit gearbeitet habe!

    0
Anmelden zum Antworten