Array in Ausdruch erzeugen
-
... sofern er sich ganz kurz mit der syntax der Container und ihrer Funktionen auseinandersetzt. ja ?
Kann ich als Anfänger bestägigen
-
muh schrieb:
Weil ja jeder anfänger mit ...
direkt was anfangen kann...Und deshalb soll man einen Anfänger also fehlerträchtigen Code vermitteln und C-Arrays verwenden, die ebenso komplex sind (Wenn man die vielen Fragen zur Zuweisung, Kopie, Übergabe etc. bedenkt kann niemand behaupten, das Arrays einfacher zu verstehen sind).
Ja, ich hätte den Code "vereinfachen" können (using namespace; Indexzugriff; Call-By-Value). Aber ich halte auch Anfänger in der Lage, Fragen zu stellen, und zeige ihnen lieber wie der Code in einer Anwendung in etwa aussehen sollte. Ich habe etwas dagegen Code zu vermitteln der
a) Unnötig fehlerträchtig ist...
b) ... in sauberen Anwendungen daher eh nicht eingebaut werden sollte...
c) ... und damit unnötiges Wissen darstellt.
Lieber liefer ich eine weitere Erläuterung nach.Zum einen sehe ich dann, das der Anfänger auch wirklich Interesse hat (Nachfragen kostet nichts, außer vielleicht Zeit), und das er sich zumindestens mal mit den Code auseinander gesetzt hat (ohne fehlerträchtigen Code 1:1 in seinen Code per Copy/Paste zu übernehmen).
cu André
P.S: Ich will garnicht behaupten das ich von Anfang an sauberen Code gelernt habe, aber dennoch kenne ich es von mir das man alte Gewohnheiten schwerer ablegt. Wieso sollte ich also gleich Gewohnheiten schaffen von denen ich weiß, das er sie später ablegen muss?
-
Wie heißts so schön? "Mit gutem Beispiel vorangehen" - ein schlechtes Beispiel zu liefern nur weils leichter verständlich ist ist absolut der falsche Weg.
Mal abgesehen davon dass die Einstellung "das ist fortgeschrittenes C++, das versteht der eh nicht" ganz schön arrogant ist und oft nicht der Wahrheit entspricht. Einige hier sonnen sich gerne in der Illusion, dass Neulinge in C++ auf jeden Fall unintelligenter und lernresistenter sind als sie selbst und überschätzen dabei zusätzlich ihren eigenen Wissensstand.
-
Wenn man Arrays immer per Reference übergeben würde, hätte mein viele Probleme weniger.
-
KasF schrieb:
Wenn man Arrays immer per Reference übergeben würde, hätte mein viele Probleme weniger.
Vor allem, weil man dann die Größe immer zur Compilezeit festlegen müsste

Felix
-
Phoemuex schrieb:
Vor allem, weil man dann die Größe immer zur Compilezeit festlegen müsste
Compiletime ist doch immer schön.
Wenn alle Lib-Entwickler ihre "Array-Funktionen" so definieren würden, hätte wir ne Menge weniger Ärger:
template<int S> void printArray( int (&array)[S] ) { for(int i = 0; i < S; ++i) cout << array[i] << endl; }Ohne die Referenz würde das gar nicht funktionieren.
Oder das ganze für alle Typen:
template<typename T ,int S> void printArray( T (&array)[S] ) { for(int i = 0; i < S; ++i) cout << array[i] << endl; }Edit: Gibt es dieses Idiom schon, wenn nicht ist es nun das KasF-Idiom

-
muh schrieb:
...
Weil ja jeder anfänger mit
...
direkt was anfangen kann...Habe ich das behauptet ?
Lies nochmal mein Post, dann wird Dir vielleicht klar, woran er meiner Ansicht nach gespart hat: An einer vernünftigen Erläuterung.Ich habe gar nicht seinen Code oder seine Lösung kritisiert, sondern die Art, wie er ihn präsentiert hat: Da hat er erstmal einen auf "coole Sau, die's nicht nötig hat, irgendetwas zu erklären" gemacht ... und sich hinter beschwert, dass ihn alle so furchtbar falsch einschätzen.
2 kurze Sätze, WARUM er diese Lösung vorschlägt, hätten
- dem OP geholfen, diesen Code in seinen Möglichkeiten und Grenzen zu beurteilen (und ggf. zu verstehen) und
- dem Rest des Forums klarer gemacht, ob dieser Code aus gründlicher Erwägung entstanden ist oder nur Ergebnis eines längeren Rumgefummels bis zum Punkt "irgendwie tut's das jetzt" (denn solcher Code wird hier gar nicht so selten präsentiert und bei Unregs kann man das einfach nicht wissen).Das musste user13 dann alles mühsam (und in eine aufgeheizte Situation hinein) nachschieben ... was definitv mehr Aufwand war, als wenn er es gleich dazugeschrieben hätte.
ERGO: Am falschen Ende gespart.Gruß,
Simon2.