D Programmierung

[Ben04]

kartoffelsack schrieb:

Was alle am for_each so toll finden, versteh ich net. Habs mal ein mittelgroßes Ein-Mann-Projekt lang versucht überall einzusetzen, wo ichs brauche (zugegeben die C++-Variante) --> an zwei Stellen. Ich hab echt extrem selten die Anforderung irgendwas mit ALLEN Objekten eines Containers zu tun. Sehr oft hingegen muss ich entscheiden ob ein Objekt noch in dem Container zu bleiben hat oder nicht. Und da komm ich um ne klassische Schleife net rum.

Löschen ist natürlich das Beispiel wo ein for_each nicht geht, allerdings ist hierfür auch die normalle Benutzung der for Schleife ungeeignet. Für viele anderen Situation geht es recht gut. Zum Beispiel zum Suchen :

int find_foo(const container&vec)
{
  foreach(i in vec)
    if(is_foo(i))
      return i;
  throw not_found();
}

Zugegeben es wäre nicht schlecht ein etwas flexibleres foreach zu haben das vielleicht auch Löschen möglich machen würde.

[daHa]

std::find/_end/first_of/_if

danke zum suchen braucht man ein for_each auch nicht unbedingt

[Gast]

daHa schrieb:

std::find/_end/first_of/_if

danke zum suchen braucht man ein for_each auch nicht unbedingt

Jo, das wär auch noch zu viel Code. Aber sieh dir das mal an. Irgendwann ist es unlustig, einen Funktor zu schreiben, dem ich dann 5 Parameter (node, candidateList, isObstacle, size, this) übergebe. Es geht sowieso nicht so wahnsinnig elegant, für alle Anwendungsgebiete mit unterschiedlich viel beteiligten Objekten einen Funktor zu definieren. Bei foreach schreib ich den Funktor einfach in den Schleifenrumpf, bei Beibehaltung des gesamten lokalen Kontexts.

private void connectToCandidates(PathfindingNode node, IList<PathfindingNode> candidateList, Predicate<CollisionObject> isObstacle, long size) {
	foreach( PathfindingNode candidate in candidateList ) {
		if( candidate == node   ||   !canConnect(node, candidate, size, ObstacleCategory.FixedPosOnly, isObstacle) )
				continue;

			long distance = node.Pos.DistanceTo(candidate.Pos);
			PathfindingNode.Connect(node, candidate, distance);
		}
}

for-Schleifen habe ich gar nicht so viele. Ich habe eigentlich mehr foreach-Schleifen. Natürlich nicht, um selber FindFirst(Predicate) nach zubauen, aber für Fälle, wo es sich eher anbietet.

[adxin]

volkard schrieb:

ich sehe keinen gwinn duch den gc.
das argument, daß man unbedingt etwas nehmen sollte, das kostenlos und optional ist, kann ich nicht nachvollziehen. warum sollte ich zu meinem auto ne kostenlose optionale (also ich habe die wahl, ob ich sie dann benutze) atombombe einbauen lassen, falls mir das einer anbietet?

Diese Analogie zieht nicht, da unrealistisch. Einen kostenlosen Navi könnte man zu einem Neuwagen doch noch verhandeln.
Außerdem wenn man diese Logik anwendet, dann kann man sich auch folgende Frage stellen: Wozu muss man unbedingt etwas wie Templates nehmen, es ist kostenlos und optional. Ich kann das auch nicht nachvollziehen.
Oder warum soll ich höhere Programmiersprachen wie C o. C++ nehmen, sie sind (manchmal) kostenlos und optional.
Das selbe gilt für for-Schleifen. Warum sollte ich sie anwenden, wenn ich dasselbe mit goto erreichen kann?
(Diese Übertreibungen dienen der Verständlichkeit.)

[volkard]

adxin schrieb:

Diese Analogie zieht nicht, da unrealistisch. Einen kostenlosen Navi könnte man zu einem Neuwagen doch noch verhandeln.

aber es gibt unzweifelhaft kostenlose sachen (wie handys mit vertrag, wie religiöse mitgliedschaften, wie erste extasy-pillen, wie nordic-walking-kurse, wie analsex), die man aufgeschatzt bekommen soll oder enorm tolle sachen zum fairen preis (wie vorwerk-staubsauger), von denen man besser die finger lassen sollte. es ist nicht alles gold, was glänzt. und blei ist sogar giftig.

Außerdem wenn man diese Logik anwendet, dann kann man sich auch folgende Frage stellen: Wozu muss man unbedingt etwas wie Templates nehmen, es ist kostenlos und optional. Ich kann das auch nicht nachvollziehen.
Oder warum soll ich höhere Programmiersprachen wie C o. C++ nehmen, sie sind (manchmal) kostenlos und optional.
Das selbe gilt für for-Schleifen. Warum sollte ich sie anwenden, wenn ich dasselbe mit goto erreichen kann?
(Diese Übertreibungen dienen der Verständlichkeit.)

in den letztgenannten punkten sehe ich noch einen bescheidenen sinn. irgendwie ist keinem ein beispiel eingefallen, wo der gc signifikante vorteile bringt. nur die vermutung, er würde irgendwelches nachdenken vereinfachen, wo ich gegenvermute, daß er um die ecke noch mehr nachdenken erzwingt.

[adxin]

volkard schrieb:

in den letztgenannten punkten sehe ich noch einen bescheidenen sinn. irgendwie ist keinem ein beispiel eingefallen, wo der gc signifikante vorteile bringt. nur die vermutung, er würde irgendwelches nachdenken vereinfachen, wo ich gegenvermute, daß er um die ecke noch mehr nachdenken erzwingt.

Mir fällt auch kein stichhaltes Argument ein, da ich nur Hobby-Programmierer und Schüler bin. Ich habe ich den GC nicht als die Lösung aller Probleme dargestellt.
Ich finde bloß, dass einige Leute hier übertreiben, wenn sie ein foreach als etwas darstellen, was einen Programmierer zum "Bösen" verleitet.

Und um jetzt nochmal auf das ursprüngliche Thema zurück zu kommen:
Mit D kann man alles? machen, was auch mit C++ möglich ist. Darüber hinaus gibt es auch einen optionalen! GC, was soll daran schlecht sein?

PS: Mich würde interessieren, was z.B. die Entwickler von Java sich dabei gedacht haben als sie einen GC den Nutzern aufgezwungen haben. Aus Spaß haben sie das nicht gemacht - behaupte ich jetzt mal. Vielleicht können sie dann diese stichhalten Argumente liefern, wenn es diese überhaupt gibt.

[rzu]

adxin schrieb:

PS: Mich würde interessieren, was z.B. die Entwickler von Java sich dabei gedacht haben als sie einen GC den Nutzern aufgezwungen haben. Aus Spaß haben sie das nicht gemacht - behaupte ich jetzt mal. Vielleicht können sie dann diese stichhalten Argumente liefern, wenn es diese überhaupt gibt.

Hmm, Java war doch ursprünglich hauptsächlich für Internetprogramme(Applets und son Zeug) gedacht, oder? Da macht es schon Sinn, einen GC zu haben, wenn man will, dass die Leute sich auch trauen, den Kram anzumachen. Aber ich denke mal, die haben auch andere Argumente.

[daHa]

adxin schrieb:

Ich finde bloß, dass einige Leute hier übertreiben, wenn sie ein foreach als etwas darstellen, was einen Programmierer zum "Bösen" verleitet.

das stimmt nicht
keiner hat foreach als etwas dargestellt das programmierer zu boesem verleitet.

adxin schrieb:

Und um jetzt nochmal auf das ursprüngliche Thema zurück zu kommen:
Mit D kann man alles? machen, was auch mit C++ möglich ist. Darüber hinaus gibt es auch einen optionalen! GC, was soll daran schlecht sein?

ist aus dem zusammenhang gerissen.

ich glaub niemand hat geschrieben das D mist oder boese ist weil es einen gc anbietet.

ich denke das ist eine leicht trivialisierte zusammenfassung einiger seiten diskussion, vielleicht noch mal lesen?

[daHa]

Optimizer schrieb:

daHa schrieb:

std::find/_end/first_of/_if

danke zum suchen braucht man ein for_each auch nicht unbedingt

Jo, das wär auch noch zu viel Code. Aber sieh dir das mal an. Irgendwann ist es unlustig, einen Funktor zu schreiben, dem ich dann 5 Parameter (node, candidateList, isObstacle, size, this) übergebe. Es geht sowieso nicht so wahnsinnig elegant, für alle Anwendungsgebiete mit unterschiedlich viel beteiligten Objekten einen Funktor zu definieren. Bei foreach schreib ich den Funktor einfach in den Schleifenrumpf, bei Beibehaltung des gesamten lokalen Kontexts.

private void connectToCandidates(PathfindingNode node, IList<PathfindingNode> candidateList, Predicate<CollisionObject> isObstacle, long size) {
	foreach( PathfindingNode candidate in candidateList ) {
		if( candidate == node   ||   !canConnect(node, candidate, size, ObstacleCategory.FixedPosOnly, isObstacle) )
				continue;

			long distance = node.Pos.DistanceTo(candidate.Pos);
			PathfindingNode.Connect(node, candidate, distance);
		}
}

for-Schleifen habe ich gar nicht so viele. Ich habe eigentlich mehr foreach-Schleifen. Natürlich nicht, um selber FindFirst(Predicate) nach zubauen, aber für Fälle, wo es sich eher anbietet.

schoen, hat aber eher weniger mit dem find zu tun auf welches ich micht bezogen hab.
weil das gebrachte find mit foreach bsp laesst sich mit deiner argumentation gemauso nachteilshaft, so es das ueberhpt ist, darstellen

fuer alles laesst sich der ein oder andere fall konstruieren wo sich dieses oder jendes fuer diesen oder jenen besser lesbar/weniger zeilen oder sonst irgendwie vorteilshaft darstellen laesst.

und ob man den functor code im schleifenrumpf moechte oder nicht ist ebenfalls vielfach geschmack oder gewoehnung.

manchmal is mir ein commentar lieber als der code weil mich nicht interessiert was genau gemacht wird, sonder nur das etwas gemacht wird, und ich bin froh soundso viel zeilen code nicht an dieser stelle zu haben.
ein anderes mal is es umgekehrt.

eine verallgemeinerung oder eine % wertung, in soundsoviel% is das besser, laesst sich da meiner bescheidenen meinung nach nicht treffen.

schoen wenn ein foreach da ist, aber auch schoen wenn ein for_each da ist.
was wann wie wo wem unter welchen umstaenden lesbarer erscheint, nunja, mag ich nciht beurteilen, bzw nur fuer mich, und es liegt mir fern meinen persoenlichen geschmack jeden aufdraengen zu wollen.
ausserdem behaupt ich auch gar nicht das ich ein foreach nicht verwenden wuerd wenns da is, mir gehts aber nicht so aber das ich mir 3x taeglich denke mist das das in c++ nicht so gibt.

was diskussionswuerdig waere ist die frage ob ein foreach als sprachfeature einer anderen implementierung ueberlegen ist.
diese frage stellt sich fuer mich aber eher sekundaer, meist ist der code drumherum, oder besser zwischen drinnen, eher diskussionswuerdig.

mit D koennte man uU, so man lust und laune hat, event einen vergleich machen, wobei dann immernoch die frage offen ist ob beide implementierungen des compilers gleichwertig sind, wenns an unterschied ueberhpt gibt.

wuerde ein foreach in den meisten faellen soundsoviel messbar bessere ergebnisse erziehlen wie for_each (oder entsprechende eigenimpl.) dann waere es natuelich ueberlegnswert dies als killerfeature anzupreisen, denk aber das das so nicht sein wird, wodurch foreach fuer mich immer noch ein nice to have aber kein estentieller vorteil / argument fuer oder gegen eine sprache ist.

[volkard]

adxin schrieb:

PS: Mich würde interessieren, was z.B. die Entwickler von Java sich dabei gedacht haben als sie einen GC den Nutzern aufgezwungen haben. Aus Spaß haben sie das nicht gemacht - behaupte ich jetzt mal. Vielleicht können sie dann diese stichhalten Argumente liefern, wenn es diese überhaupt gibt.

das ist einfach. es wurde mal eine sprache OAK entwickelt für embedded systems, waschmaschinen, toaster, kühlschränke und so. mit vm, damit der hersteller leicht den prozessor in der waschmaschine austauschen kann, und mit bewußt kindergartenhaftem verhalten, damit auch der dümmste programmierer damit klarkommt, in der annahme, daß mikrocode für toaster programmieren eine solche strafe ist, daß kein normaler entwickler dort landet. außerdem ist laufzeit gar nicht wichtig, voll interpretierter zwischencode, überall exceptions. der gc war sinnvoll, daß kein mensch mit OAK komplexe programme schreiben sollte, die laufzeit egal war und mit recht ungeschickten programmierern zu rechnen war. tja, und dann hat man OAK umgenannt nach JAVA und fürs internet entdeckt, schnell die ursprünge verwischt (in den ersten java-sdks war aber der name OAK noch zu lesen) und marketinglügen verbreitet, daß sich die balken biegen.
so kommt es, daß keiner versteht, warum java genau so und nicht anders ist, daß java wie von hirnlosen idioten zusammengeklopt erscheint, aber wenn man die geschichte kennt, muß man zugeben, daß java für waschmaschinen einfach excellent ist, elegant, angemessen, toll, einfach super und nicht den hauch einer fehlentscheidung spüren läßt.

[Gast]

Wir reden hier immerhin über eine Waschmaschine mit Multithreading.

[ForEach-Hasser]

Optimizer schrieb:

for-Schleifen habe ich gar nicht so viele. Ich habe eigentlich mehr foreach-Schleifen. Natürlich nicht, um selber FindFirst(Predicate) nach zubauen, aber für Fälle, wo es sich eher anbietet.

vielleicht hat deshalb dein Spiel Performance-Probleme?
http://www.users.muohio.edu/janoside/For vs Foreach.png

[Gast]

Nein, ist nicht deswegen.

[Helium]

ob man schreibt

foreach i in range (x, y)
   print i * i

oder

for i = x to y
   print i * i

oder ob schreibt

foreach e in collection
   print e

oder

for it = collection.begin to collection.end
   print it.value

ist doch im grunde alles nur Synthax. Wäre der Compiler schlau genug, dann könnte er aus beidem das selbe generieren.

[Roar]

volkard schrieb:

adxin schrieb:

PS: Mich würde interessieren, was z.B. die Entwickler von Java sich dabei gedacht haben als sie einen GC den Nutzern aufgezwungen haben. Aus Spaß haben sie das nicht gemacht - behaupte ich jetzt mal. Vielleicht können sie dann diese stichhalten Argumente liefern, wenn es diese überhaupt gibt.

das ist einfach. es wurde mal eine sprache OAK entwickelt für embedded systems, waschmaschinen, toaster, kühlschränke und so. mit vm, damit der hersteller leicht den prozessor in der waschmaschine austauschen kann, und mit bewußt kindergartenhaftem verhalten, damit auch der dümmste programmierer damit klarkommt, in der annahme, daß mikrocode für toaster programmieren eine solche strafe ist, daß kein normaler entwickler dort landet. außerdem ist laufzeit gar nicht wichtig, voll interpretierter zwischencode, überall exceptions. der gc war sinnvoll, daß kein mensch mit OAK komplexe programme schreiben sollte, die laufzeit egal war und mit recht ungeschickten programmierern zu rechnen war. tja, und dann hat man OAK umgenannt nach JAVA und fürs internet entdeckt, schnell die ursprünge verwischt (in den ersten java-sdks war aber der name OAK noch zu lesen) und marketinglügen verbreitet, daß sich die balken biegen.
so kommt es, daß keiner versteht, warum java genau so und nicht anders ist, daß java wie von hirnlosen idioten zusammengeklopt erscheint, aber wenn man die geschichte kennt, muß man zugeben, daß java für waschmaschinen einfach excellent ist, elegant, angemessen, toll, einfach super und nicht den hauch einer fehlentscheidung spüren läßt.

hä, meine geringe menschenkenntnis von pizzaliferanten verrät mir leider nicht ob das pure ironie war, oder ob das tatsächlich ernst gemeint war . klär mnich auf

[Gast]

Er meint das mit Sicherheit vollkommen ernst und formuliert es aber absichtlich noch ein bisschen provokant. Kann man aber leicht kontern. Was kann er schon einer eine Multithreading-fähige Waschmaschine, deren Programmiersprache foreach, sich gegenseitig aufrufende überladene Konstruktoren hat und keine affige Funktionen mit undefinierten return-Werten erlaubt, entgegensetzen?
(Ja, ich weiß, wo es ihm wehtut, ich habe gut aufgepasst )

[volkard]

[quote="Helium"]ob man schreibt...[(quote]
ja, ist an sich egal. ich möchte auch

foreach e in collection
   print e

schreiben dürfen.

Synthax

Syntax

[volkard]

Optimizer schrieb:

Was kann er schon einer eine Multithreading-fähige Waschmaschine, deren Programmiersprache foreach, sich gegenseitig aufrufende überladene Konstruktoren hat und keine affige Funktionen mit undefinierten return-Werten erlaubt, entgegensetzen?
(Ja, ich weiß, wo es ihm wehtut, ich habe gut aufgepasst )

stimmt. hast gut aufgepaßt.

aber entgegensetzen könnte ich, wenn es nicht auf die kosten ankommt, einen bemannten flugzeugträger. das ist mein lieblingswerkzeug, wenn es um universelle einsetzbarkeit ankommt. er kann auch wäsche waschen. als bonusfeatures kann er mir zum beispiel pizza backen, rum besorgen, fliegen erschlagen und musik machen.

[volkard]

Roar schrieb:

hä, meine geringe menschenkenntnis von pizzaliferanten verrät mir leider nicht ob das pure ironie war, oder ob das tatsächlich ernst gemeint war . klär mnich auf

vielleicht hilft das ein wenig
http://de.wikipedia.org/wiki/Star_Seven

[Gast]

btw. muss man allerdings hier schon sagen, dass auch dein bemannter Flugzeugträger nicht gerade eine astreine Entstehungsgeschichte vorweisen kann. C, C with classes, C++ (ohne Mehrfachvererbung, abstrakte Klassen, statische Methoden, templates, namespaces, exceptions), anständiges C++.

Und jeder dieser Zwischenschritte bei fast vollständiger Aufrechterhaltung der Kompatibilität. Java merke ich die Herkunft jedenfalls nicht so krass an, wie C++. Denk' darüber vielleicht auch mal nach.