D Programmierung

[Dannerbeck_Dieter]

ja es fehlen noch ein paar wichtige dinge in phobos...

[link fehler]

link geht nicht!

[Dannerbeck_Dieter]

Chache löschen! Es gab ein paar grundlegende Veränderungen.

[Reyx]

Naja, ich bin da geteilter Meinung. Etliche Sprachen ahmen die Syntax von C/C++ nach und versuchen, diese "Königssprachen" zu übertrumpfen. Aber ob jetzt PHP, C# oder Java ... Aus irgendwelchen Gründen bin ich immer bei C/C++ geblieben, da braucht es einiges, mich von etwas anderem zu überzeugen! Würde mich wundern, wenn D da anders währe ...

Aber prinzipiell sieht das auf jeden Fall echt interessant aus
Eine echte Compilersprache, foreach-Schleife ... schön schön, aber was an Garbage Collection so toll sein soll kann ich wirklich nicht nachvollziehen!?

[Brutus]

Was hast du gegen std::for_each()?

[BloodLord]

Hm... Ganz nett, bin über die Seite aber auch schon gestolpert und hab D noch nicht ausprobiert. Wird einem Garbage Collection eigentlich aufgezwungen? Das macht nämlich vieles langsamer... Im allgemeinen wäre ein Performancetest der Sprache mal ganz nett.

Scheinbar kann man aber C-like, C++-like oder ein bisschen C#-like ( ) programmieren, je nachdem wie man will, ohne das man an einen bestimmten Stil gebunden ist.

//edit: Frage, weiß einer von euch ob man damit z.B. auch C/C++ APIs benutzen kann? (boost, wxWidgets, DirectX etc. ...)

[Reyx]

Brutus schrieb:

Was hast du gegen std::for_each()?

Dass es kein Sprachkonstrukt ist ...

[daHa]

Reyx schrieb:

Brutus schrieb:

Was hast du gegen std::for_each()?

Dass es kein Sprachkonstrukt ist ...

diese foreach fixiertheit hab ich noch nie verstanden.

produziert der compiler was besseres als output wenn es ein sprachkonstruckt ist?

[Ben04]

Brutus schrieb:

Was hast du gegen std::for_each()?

1. Ich kann nicht schreiben

std::for_each(vec.begin(), vec.end()){

}

Ohne irgendeine Art vernünftiger Lambda Ausdrücken die die Übersetzungszeit nicht verdreifachen ist dies nicht möglich.

2. Ich kann nicht schreiben

std::for_each(vec, &output);

Sondern muss schreiben

std::for_each(vec.begin(), vec.end(), &output);

Dies ist jetzt aber ein Problem der STL und nicht der Sprache. Der Fall wo ich den ganzen Verktor ausgeben will ist nun einmal viel häufiger als der wo ich nur einen Teil ausgeben will. Besser würde ich also finden:

for_each(vec, &output);
for_each(make_range(vec.begin(), vec.end()-3), &output);

[Gast]

daHa schrieb:

Reyx schrieb:

Brutus schrieb:

Was hast du gegen std::for_each()?

Dass es kein Sprachkonstrukt ist ...

diese foreach fixiertheit hab ich noch nie verstanden.

produziert der compiler was besseres als output wenn es ein sprachkonstruckt ist?

Nicht zwangsläufig... ein foreach braucht man halt einfach verdammt oft und selbst mit auto wird das Durchiterieren immer noch nicht genauso schön wie mit foreach. Überleg mal wie lesbar es den Code macht, wenn da steht "für jedes ding in myList { ... }"

[Makros]

Wers unbedingt braucht macht halt nen Makro, aber ne Sprache danach zu bewerten ob es "foreach" gibt...
C und C++ haben nicht umsonst viel weniger Schlüsselwörter als andere Sprachen, sie sind dadurch zwar komplexer, aber die Möglichkeiten schier unbegrenzt.

[Reyx]

C++ und viel weniger Schlüsselwörter als andere Sprachen? Seit wann dass denn?

[C-Juppie]

Makros schrieb:

Wers unbedingt braucht macht halt nen Makro, aber ne Sprache danach zu bewerten ob es "foreach" gibt...
C und C++ haben nicht umsonst viel weniger Schlüsselwörter als andere Sprachen, sie sind dadurch zwar komplexer, aber die Möglichkeiten schier unbegrenzt.

Warum sind Sprachen durch weniger Schlüsselworte komplexer? Ob ich nun

virtual void foobar()=0;

schreibe, oder

abstract void foobar();

macht eine Sprache nicht komplexer, sondern nur unleserlicher.

C++ hat nur aus einem Grund teilweise mit "neuen" Schlüsselwörtern gegeizt: Man wollte soviel C Code wie möglich kompatibel halten.

Aber D sieht wirklich mal sehr interessant aus. Mich wunderts nur, dass man darüber bisher sowenig gehört hat.

[c.rackwitz]

D ist eben zur zeit version 0.144 und damit noch nicht wirklich produktionsqualitaet. funktionieren tuts wunderbar; es kommen eigentlich nur immer features dazu und minimale bugfixes.

[dagegen]

D hat keine Daseinsberechtigung.

[Ben04]

Makros schrieb:

Wers unbedingt braucht macht halt nen Makro, aber ne Sprache danach zu bewerten ob es "foreach" gibt...

Dann mach mal. Wenn du es fertig bringst ein foreach Makro zu bauen dann geb ich einen aus.

[daHa]

Optimizer schrieb:

daHa schrieb:

Reyx schrieb:

Brutus schrieb:

Was hast du gegen std::for_each()?

Dass es kein Sprachkonstrukt ist ...

diese foreach fixiertheit hab ich noch nie verstanden.

produziert der compiler was besseres als output wenn es ein sprachkonstruckt ist?

Nicht zwangsläufig... ein foreach braucht man halt einfach verdammt oft und selbst mit auto wird das Durchiterieren immer noch nicht genauso schön wie mit foreach. Überleg mal wie lesbar es den Code macht, wenn da steht "für jedes ding in myList { ... }"

lesbarkeit ist von for schleifen mindestens genauso gut, wenn nicht besser

ausserdem kann ich in for schleifen recht gemuetlich den iteratortype bestimmen, const , reverse, usw.., was bei den gewuneschten foreach so nicht geht, bzw dann nicht mehr so leicht lesbar ist.

diese foreach fixiertheit ist reines marketinggeplapper fuer/von sprachen die das implementiert haben.
und das halt als grossartiges feature (und ueberlegenheit (der eleganz)) der sprache verkaufen.

ich persoenlich finde es eleganter, und ueberlegen, wenn ich mir ohne probleme eigene foreach (bzw aehnlich benamst um keine verwirrung zu stiften) erstellen kann, die dann in combi von praeprozessor und compiler optimalen code fabrizieren, eine tatsache die die foreachmarketingplapperer gern uebersehen bzw gar nicht wissen.

[Gast]

daHa schrieb:

lesbarkeit ist von for schleifen mindestens genauso gut, wenn nicht besser

typedef std::map<MyKey, MyValue*>::const_iterator Iterator;
for( Iterator i = myMap.begin();  i != myMap.end();  ++i ) {
    cout  <<  (*i)->getMember();
}

foreach( MyValue v in myMap ) {
    Console.Out.WriteLine(v.getMember());
}

q.e.d.

ausserdem kann ich in for schleifen recht gemuetlich den iteratortype bestimmen, const , reverse, usw.., was bei den gewuneschten foreach so nicht geht, bzw dann nicht mehr so leicht lesbar ist.

Super Vorteil, der mir aber nichts bringt, wenn ich einfach die Elemente aufzählen will. Kommt bei mir wesentlich öfters vor, als irgendwas spezielleres. foreach soll ja gar nicht alles abdecken, sondern nur elegant aufzählen. Ich verstehe auch gar nicht, was daran "gemütlich" sein soll, wenn ich immer nen Iterator-typedef machen muss. Ich glaub die C++ - Community freut sich nicht ohne Grund auf das verbesserte auto.

diese foreach fixiertheit ist reines marketinggeplapper fuer/von sprachen die das implementiert haben.
und das halt als grossartiges feature (und ueberlegenheit (der eleganz)) der sprache verkaufen.

Nö, ich mag's. Und ich bin kein Wirtschaftler.

ich persoenlich finde es eleganter, und ueberlegen, wenn ich mir ohne probleme eigene foreach (bzw aehnlich benamst um keine verwirrung zu stiften) erstellen kann, die dann in combi von praeprozessor und compiler optimalen code fabrizieren, eine tatsache die die foreachmarketingplapperer gern uebersehen bzw gar nicht wissen.

Du kannst kein gescheites foreach basteln, ganz einfach, wenn du es irgendwann mal versuchst, wirst du es selber merken. Man kann der Sache zugegebenermaßen einigermaßen nahe kommen, aber supertoll ist es nicht. Und wenn irgendwas nicht klappt steht dann nicht da, "Map<K, V> does not implement IEnuermable<V>, sondern es steht 2 Seiten Fehlermeldung. Aber das bist du ja vielleicht gewohnt.

[Konrad]

typedef std::map<MyKey, MyValue*>::const_iterator Iterator;
for( Iterator i = myMap.begin();  i != myMap.end();  ++i ) {
    cout  <<  (*i)->getMember();
}

Haste jetzt extra nen Pointer in die Map gepackt, damit du quasi 2mal dereferenzieren musst und es so "schlimmer" aussieht?

for(auto iter = map.begin(); iter != map.end(); ++iter) {
        cout << (*i)->get(); 
}

Finde ich nicht unbedingt hässlicher als das foreach in C#. Das begin() und end() sagt meiner Meinung nach genauso viel aus wie ein foreach.
Ok, funktioniert noch nicht aber kommt..

Und wenn irgendwas nicht klappt steht dann nicht da, "Map<K, V> does not implement IEnuermable<V>, sondern es steht 2 Seiten Fehlermeldung. Aber das bist du ja vielleicht gewohnt.

Naja, das liegt halt an den Templates. Hast du nen Vorschlag wie man das besser regeln könnte?

[Any]

struct Int 
{
	Int( int i ) : i( i )
	{
	}

	bool display()
	{
		cout << i << "\t";
		return true;
	}

	int i;
};

int main()
{
	list< Int > li;
	li.push_back( 1 );
	li.push_back( 2 );
	li.push_back( 3 );

	for_each( li.begin(), li.end(), mem_fun_ref( &Int::display ) );
}

Wenn man einfach nur irgendwas machen will auf allen Objekten, ist for_each optimal. Sobald man mehr machen will, ist der Kopf der for-Schleife nicht mehr unnötig viel Standardbalast im Vergleich zum Rumpf.

Aber gut jeder wie er will, ich werde eine Sprache nicht wegen einem fehlenden foreach bemängeln. Ich mag C++ und kann damit leben mal ne Zeile mehr zu tippen.