Kennt jemand von euch D ??? neue Prog. sprache?!?

[quote]Korbinian kennst du NBS????

Hab spontan beim ersten Suchversuch direkt diesen Thread gefunden.

Talla

Also neu ist die auf keinen Fall, hab schon vor Jahren was dazu gelesen, aber irgendwie spricht die mich überhaupt nicht an. Wenn ich mir den Überblick so angucke sieht das echt nur aus wie nen Versuch das schlimmste aus allen Sprachen zusammenzumischen.

Das schlimmste heißt?

Ich seh eigentlich größtenteils nur gutes (von der extrem bescheidenen Bibliothek mal abgesehen).

Ein GC und trotzdem RAII möglich ist schonmal sau geil.

Lambda-Ausdrücke, verschachtelte Funktionen, etc. ist auch cool.

Echte Templates sind auch nicht übel.

Ein foreach ist nie schlecht.

Seid mal realistisch.
Solch eine sprache wird sich nie durchsetzen. Ihr fehlt jede anbindung. Es wird sich nie jemand die mühe machen eine XLib für "D" zu programmieren. Zudem finde ich es unverschämt, eine sprache "D" zu nennen.
Ich denke dass niemand das recht hat, sich als nachfolger von C zu bezeichnen - zumindest nicht mit soetwas.
Auch sind verschachtelte funktionen sinnlos und verleiten zu schlampigem programmieren. Und was will ein programmierer mit foreach und assotiativen arrays? Warum schlüsselwörter für soetwas verwenden?
Das ist doch keine prozessornahe programmierung mehr. Habt ihr euch nie gefragt, warum man Basic nicht für grosse Projekte einsetzt? Ein durchschnittlicher programmierer sollte sich ein assoziatives array selber schreiben können.
Ein schlechter sollte ein fertiges aus einer libary verwenden (siehe C++ libary). Aber doch bitte keine schlüsselwörter.

K.a schrieb:

Solch eine sprache wird sich nie durchsetzen. Ihr fehlt jede anbindung. Es wird sich nie jemand die mühe machen eine XLib für "D" zu programmieren.

Warum sollte jemand eine XLib für D programmieren, wenn er einfach die XLib, GTK oder was weiß ich verwenden kann?
D fehlt keine Anbindung, D kann einfach gegen C-Code gelinkt werden. Du mußt nur die passenden Import-Dateien aus den Headern erstellen. Dies ist einfacher als z.B. für Ada oder andere nicht C-Syntax-Sprachen.

Zudem finde ich es unverschämt, eine sprache "D" zu nennen.
Ich denke dass niemand das recht hat, sich als nachfolger von C zu bezeichnen - zumindest nicht mit soetwas.

Ich finde es unverschämt eine Sprache C++ oder C# zu nennen...

Auch sind verschachtelte funktionen sinnlos und verleiten zu schlampigem programmieren. Und was will ein programmierer mit foreach und assotiativen arrays? Warum schlüsselwörter für soetwas verwenden?
Das ist doch keine prozessornahe programmierung mehr.

Jipp, warum programmieren wir alle nicht einfach in Assembler, oder besser, warum nicht mit einem Hexeditor? Das ist Prozessornah!!!
Verschachtelte Funktionen sind mit ein Ersatz für Makros; hoffe Du erkennst, daß Makros zu fehlerhaftem Programmieren führen, da sie nicht type-safe sind.
Außerdem kannst Du in Ada verschachtelte Funktionen programmieren, und Du willst doch nicht behaupten, daß Ada zu schlampigem Programmieren verleitet, oder?
Assoziative Arrays haben kein Schlüsselwort, wo ist also das Problem? Foreach ist ein Schlüsselwort, ja und? Ist doch schön

Container!(Typ) a;
...
foreach ( Typ i; a )
  doSomething(i);

zu schreiben, anstelle irgendwelcher wilder Iterator-Sachen, man muß für einen Container lediglich einen Operator überladen. Und wenn Du auf den C++-Weg stehst, kannst Du immer noch eine eigene Template Library für D schreiben, bzw. warten bis die DTL fertig ist (die rein zufällig vom STLSoft-Programmierer erstellt wird).

Wenn Du an Deine Lieblingssprache so sehr gewöhnt bist, daß Dich eine Sprache wie D so aufregt, dann brauchst Du erst gar nicht eine andere Sprache anschauen. Ich jedenfalls halte D für eine gute Sprache mit einigen sehr schönen Sprach-Elementen, die einige Schwächen von C und C++ beseitigt, und einige Konzepte aus Sprachen wie Java, C# und Ada mitbringt.

Ein Gast schrieb:

K.a schrieb:

Solch eine sprache wird sich nie durchsetzen. Ihr fehlt jede anbindung. Es wird sich nie jemand die mühe machen eine XLib für "D" zu programmieren.

Warum sollte jemand eine XLib für D programmieren, wenn er einfach die XLib, GTK oder was weiß ich verwenden kann?
D fehlt keine Anbindung, D kann einfach gegen C-Code gelinkt werden. Du mußt nur die passenden Import-Dateien aus den Headern erstellen. Dies ist einfacher als z.B. für Ada oder andere nicht C-Syntax-Sprachen.

Ok das stimmt auch wieder. Aber trotzdem bin ich nicht überzeugt, dass die erweiterungen verbesserungen mit sich bringen. Teilweise vielleicht schon aber grössten teils nicht.

Zudem finde ich es unverschämt, eine sprache "D" zu nennen.
Ich denke dass niemand das recht hat, sich als nachfolger von C zu bezeichnen - zumindest nicht mit soetwas.

Ich finde es unverschämt eine Sprache C++ oder C# zu nennen...
[/quote]

C++ oder C# finde ich nicht unverschämt. Was gibt es daran auszusetzen sich als erweiterung zu betrachten? Ich finde es aber nciht gut sich als NACHFOLGER zu betrachten. Und ich sage das obwohl ich C# auch nicht mag.

Auch sind verschachtelte funktionen sinnlos und verleiten zu schlampigem programmieren. Und was will ein programmierer mit foreach und assotiativen arrays? Warum schlüsselwörter für soetwas verwenden?
Das ist doch keine prozessornahe programmierung mehr.

Jipp, warum programmieren wir alle nicht einfach in Assembler, oder besser, warum nicht mit einem Hexeditor? Das ist Prozessornah!!!
Verschachtelte Funktionen sind mit ein Ersatz für Makros; hoffe Du erkennst, daß Makros zu fehlerhaftem Programmieren führen, da sie nicht type-safe sind.
Außerdem kannst Du in Ada verschachtelte Funktionen programmieren, und Du willst doch nicht behaupten, daß Ada zu schlampigem Programmieren verleitet, oder?
Assoziative Arrays haben kein Schlüsselwort, wo ist also das Problem? Foreach ist ein Schlüsselwort, ja und? Ist doch schön

Container!(Typ) a;
...
foreach ( Typ i; a )
  doSomething(i);

zu schreiben, anstelle irgendwelcher wilder Iterator-Sachen, man muß für einen Container lediglich einen Operator überladen. Und wenn Du auf den C++-Weg stehst, kannst Du immer noch eine eigene Template Library für D schreiben, bzw. warten bis die DTL fertig ist (die rein zufällig vom STLSoft-Programmierer erstellt wird).
[/quote]

ok aber warum macht man dann nicht einfach eine normale for? Warum fügt man ein schlüsselwort hinzu, was nur geringe abkürzungen mit sich bringt!
Ehrlich gesagt mag ich auch an C++ die standard libary nicht. Die fertigen klassen finde ich nicht sehr gut gebrauchbar und schön. Auch ist der name der (template)klasse vektor unpassend.
Ich habe nichts gegen klassen aber gegen von der libary angebotene classen mit überladenen operatoren wie cout.
Ich glaube dass ein anfänger nur richtig begraift wie ein kompiler und C wirklcih funktioniert, wenn er mit printf und ähnlichen anfängt. Wenn es ihm dann gefällt, kann er ja dann immernoch cout verwenden.
Und zum prozessornah programmieren: Ich hoffe du weisst, dass um so weiter sich eine compiler-sprache davon entfernen versucht, umso langsamer das compilat ist? Ich bin kein Assembler-freak der sagt man müsse alles in assembler machen, aber ich denke C++ ist schon weit genug entfernt um gut damit zu programmieren - ja an manchen stellen vielleicht schon ein bisschen zu weit.

Wenn Du an Deine Lieblingssprache so sehr gewöhnt bist, daß Dich eine Sprache wie D so aufregt, dann brauchst Du erst gar nicht eine andere Sprache anschauen. Ich jedenfalls halte D für eine gute Sprache mit einigen sehr schönen Sprach-Elementen, die einige Schwächen von C und C++ beseitigt, und einige Konzepte aus Sprachen wie Java, C# und Ada mitbringt.

Ich rege mich nicht auf weil D eine andere sprache ist. Der einzige grund warum ich mich aufrege ist der name. Sonst finde ich, dass sprachelemente wie foreach überflüssig sind und das fehlen eines preprozessors(oder habe ich das flasch verstanden?) nicht akzeptabel ist für ein grosses projekt. Weitere elemente wie assotative arrays sind überflüssig finde ich.
Ich selber würde an C++ noch einiges verbessern, an ANSI C jedoch nichts.

Shade Of Mine

K.A schrieb:

ok aber warum macht man dann nicht einfach eine normale for?

Weil foreach einfach passt.
foreach geht ueber jedes element, klar ist for dass ueber alle elemente iteriert auch nicht so schwer zu schreiben, aber beachte mal:

for(list<string>::iterator i=l.begin(); i<l.end(); i++)

Wieviele Fehler stecken darin?
ein

foreach(string s in l)

ist kuerzer, schoener und fehlerfreier.

Ich glaube dass ein anfänger nur richtig begraift wie ein kompiler und C wirklcih funktioniert, wenn er mit printf und ähnlichen anfängt. Wenn es ihm dann gefällt, kann er ja dann immernoch cout verwenden.

Dir ist schon klar, dass dank printf() der einstieg in c verdammt schwer ist? weil man dauernd den falschen format specifier erwischt (passiert sogar mir ab und zu) also gerade anfaenger sollten printf meiden, weil es zu komplex ist (und nichts zu dem verstaendnis der sprache beitraegt)

und selbst wenn jemand printf verstanden hat, dann bringt es einem doch in bezug auf sprache/compiler etc. ueberhaupt nicht weiter...

Und zum prozessornah programmieren: Ich hoffe du weisst, dass um so weiter sich eine compiler-sprache davon entfernen versucht, umso langsamer das compilat ist? Ich bin kein Assembler-freak der sagt man müsse alles in assembler machen, aber ich denke C++ ist schon weit genug entfernt um gut damit zu programmieren - ja an manchen stellen vielleicht schon ein bisschen zu weit.

aber der faktor ist laecherlich gering. die einfuehrung einer VM als abstraktionsebene ist ja ein riesen schritt weg von asm, oder? und um welchen faktor ist java langsamer als c++? verschwindend gering. weil durch die abstraktion wieder neue arten der optimierung moeglich sind.

Ich rege mich nicht auf weil D eine andere sprache ist. Der einzige grund warum ich mich aufrege ist der name.

Und C# (Cis, C um 1 erhoeht) stoert dich nicht?
Oder C++, welches ja der Nachfolger von C ist.
Oder C, welches der nachfolger von B ist?

und das fehlen eines preprozessors(oder habe ich das flasch verstanden?) nicht akzeptabel ist für ein grosses projekt.

Verdammt. Und ich war immer der Meinung mit Java, PHP, Python, C# etc. koennte man auch grosse Projekte machen

Ich selber würde an C++ noch einiges verbessern, an ANSI C jedoch nichts.

na das ist interessant. klaer uns mal auf.

Shade Of Mine schrieb:

K.A schrieb:

ok aber warum macht man dann nicht einfach eine normale for?

Weil foreach einfach passt.
foreach geht ueber jedes element, klar ist for dass ueber alle elemente iteriert auch nicht so schwer zu schreiben, aber beachte mal:
for(list<string>::iterator i=l.begin(); i<l.end(); i++)
Wieviele Fehler stecken darin?
ein
foreach(string s in l)
ist kuerzer, schoener und fehlerfreier.

schöner - ja. Aber nur weil list<string>::iterator unschön ist. Das kann man viel schöner programmieren, indem man den iterator oben in der funktion lokal definiert. Dann ist es übersichtlich und man ist sich immer im klaren, welche lokalen variablen erzeugt sind.

Shade Of Mine schrieb:

Ich glaube dass ein anfänger nur richtig begraift wie ein kompiler und C wirklcih funktioniert, wenn er mit printf und ähnlichen anfängt. Wenn es ihm dann gefällt, kann er ja dann immernoch cout verwenden.

Dir ist schon klar, dass dank printf() der einstieg in c verdammt schwer ist? weil man dauernd den falschen format specifier erwischt (passiert sogar mir ab und zu) also gerade anfaenger sollten printf meiden, weil es zu komplex ist (und nichts zu dem verstaendnis der sprache beitraegt)

und selbst wenn jemand printf verstanden hat, dann bringt es einem doch in bezug auf sprache/compiler etc. ueberhaupt nicht weiter...

ich denke dass es einen anfänger sehr verwirrt, wenn er nicht begreift, dass der << operator von cout nur eine funktion ist und nichts "was der prozessor macht". Normalerweise ist << ja ein bitshifting opetator, wie du sicher weisst.
Wenn er printf allerdings wie jede funktion verwendet, die er selber auch schreiben kann, begreift er dass dahinter programmcode steckt, der aufgerufen wird. Und er hat vom programm ein ganz anderes verständnis nicht wie anfänger und sogenannten "profis" sagen :"Das der computer das halt ausführt".
Er versteht das programm aus einer sammlung von aneinandergehängten funktionen - so wie es auch wirklich ist und nicht aus "befehlen die der cumputer kann".

Shade Of Mine schrieb:

Und zum prozessornah programmieren: Ich hoffe du weisst, dass um so weiter sich eine compiler-sprache davon entfernen versucht, umso langsamer das compilat ist? Ich bin kein Assembler-freak der sagt man müsse alles in assembler machen, aber ich denke C++ ist schon weit genug entfernt um gut damit zu programmieren - ja an manchen stellen vielleicht schon ein bisschen zu weit.

aber der faktor ist laecherlich gering. die einfuehrung einer VM als abstraktionsebene ist ja ein riesen schritt weg von asm, oder? und um welchen faktor ist java langsamer als c++? verschwindend gering. weil durch die abstraktion wieder neue arten der optimierung moeglich sind.

Was höre ich da? Java soll verschwindend gering langsamer sein als C++? Und PHP ist so schnell wie assembler oder wie?
Java ist ein 100tstel so schnell wie C++.
Probier's aus!

Shade Of Mine schrieb:

Ich rege mich nicht auf weil D eine andere sprache ist. Der einzige grund warum ich mich aufrege ist der name.

Und C# (Cis, C um 1 erhoeht) stoert dich nicht?
Oder C++, welches ja der Nachfolger von C ist.
Oder C, welches der nachfolger von B ist?

D ist einfach zu allgemein. C++ und C# beinhalten immer noch C und bezeichnen sich somit nicht als nachfolger!

Shade Of Mine schrieb:

und das fehlen eines preprozessors(oder habe ich das flasch verstanden?) nicht akzeptabel ist für ein grosses projekt.

Verdammt. Und ich war immer der Meinung mit Java, PHP, Python, C# etc. koennte man auch grosse Projekte machen

Ich wiederhole mich: ungeeignet.
Wie willst du mit D cross-compilieren ohne pre-prozessor?
Wie willst du mit -D_DEBUG compilieren ohne pre-prozessor?
Pre-prozessor hat sehr viele vorteile.

Shade Of Mine schrieb:

Ich selber würde an C++ noch einiges verbessern, an ANSI C jedoch nichts.

na das ist interessant. klaer uns mal auf.

[!quote]

Das habe ich bereits gesagt.
zitat von mir selbst:

K.A schrieb:

Ehrlich gesagt mag ich auch an C++ die standard libary nicht. Die fertigen klassen finde ich nicht sehr gut gebrauchbar und schön. Auch ist der name der (template)klasse vektor unpassend.
Ich habe nichts gegen klassen aber gegen von der libary angebotene classen mit überladenen operatoren wie cout.
Ich glaube dass ein anfänger nur richtig begraift wie ein kompiler und C wirklcih funktioniert, wenn er mit printf und ähnlichen anfängt. Wenn es ihm dann gefällt, kann er ja dann immernoch cout verwenden.

SideWinder

Lustig zu lesen hier

MfG SideWinder

operator void

__me schrieb:

Ein foreach ist nie schlecht.

Es zeigt aber IMHO das Problem hinter der D-Philosophie. foreach ersetzt jetzt std::for_each durch etwas "Schöneres". Und wo bleibt ein sort, das std::sort ersetzt? usw. - Hätte man die Mittel bereit gestellt, damit man sich ein benutzbares foreach selbst schreiben kann (so wie Enumerable#each in Ruby z.B.), hätte man mit einer allgemeineren Lösung nicht nur die Spitze des Eisbergs kaschiert.
Oder um ein anderes Beispiel zu bringen, D stellt für Strings einen eingebauten Typ bereit (verschiebt die Arbeit also in den Compiler), der dann nicht mehr die Probleme von C++-Strings hat. Wieder wäre es mir lieber, die Sprache wüsste nichts über Strings (oder dynamische Arrays im allgemeinen, denn solche sind Strings ja in D) und würde es ermöglichen, eine schönere Stringklasse in der Sprache selbst zu schreiben.
D = Flickenlösung

Shade Of Mine

K.a schrieb:

schöner - ja. Aber nur weil list<string>::iterator unschön ist. Das kann man viel schöner programmieren, indem man den iterator oben in der funktion lokal definiert. Dann ist es übersichtlich und man ist sich immer im klaren, welche lokalen variablen erzeugt sind.

Von dem iterator rede ich ja garnicht. aber hast du alle fehler gefunden?
kleiner tipp, es sind 3.
und das in dieser unschuldigen zeile...

ich denke dass es einen anfänger sehr verwirrt, wenn er nicht begreift, dass der << operator von cout nur eine funktion ist und nichts "was der prozessor macht". Normalerweise ist << ja ein bitshifting opetator, wie du sicher weisst.

bitshifting ist fuer den anfaenger aber noch uninteressanter.
und wozu wissen dass << eine funktion ist?
cout<<was_auch_immer;
gibt was_auch_immer aus, ohne dass ich den typen kennen muss.

das ist ja ein kleiner teil der oo philosphie. der typ ist egal, nur das objekt zaehlt.

natuerlich versteht das der anfaenger jetzt noch nicht, aber der mechanismus wird ihm praktisch erscheinen und irgendwann wird er es kapiert haben.

Wenn er printf allerdings wie jede funktion verwendet, die er selber auch schreiben kann, begreift er dass dahinter programmcode steckt, der aufgerufen wird.

Klar, printf() ist ja trivial, gell?
variadic functions sind etwas, dass ein anfaenger nicht braucht und selbst profis nur sehr selten. also wozu gleich am anfang lernen?
und wieso sich ab muehen und die format specifier lernen, die man dann sowas irgendwann verwechselt und so viele bugs einbaut?

Er versteht das programm aus einer sammlung von aneinandergehängten funktionen - so wie es auch wirklich ist und nicht aus "befehlen die der cumputer kann".

Aber ein programm ist ja eben _mehr_ als das.
ein programm ist nicht ein "fuehere befehl nach befehl aus".
auf der untersten ebene ist es natuerlich schon, aber wozu fuehren wir dann die abstraktionsschichten ein?

Was höre ich da? Java soll verschwindend gering langsamer sein als C++? Und PHP ist so schnell wie assembler oder wie?
Java ist ein 100tstel so schnell wie C++.
Probier's aus!

Probier du es doch aus. schau dich hier um, hier gab es schon benchmarks.
idr musste man in beiden sprachen etwas tweaken um die maximale leistung herauszuholen und c++ hat zwar immer gewonnen, aber 1) oft mit mehr aufwand und 2) nur mit geringem unterschied. faktor 2-5 etwa.

was na java so lahm ist, ist swing.

D ist einfach zu allgemein. C++ und C# beinhalten immer noch C und bezeichnen sich somit nicht als nachfolger!

doch, tun sie. sie beinhalten zwar C, sehen sich aber dennoch als nachfolger an. zumindest c++ wird auch offiziell als nachfolger angesehen.

Ich wiederhole mich: ungeeignet.
Wie willst du mit D cross-compilieren ohne pre-prozessor?
Wie willst du mit -D_DEBUG compilieren ohne pre-prozessor?
Pre-prozessor hat sehr viele vorteile.

Schau dir D an, dann wirst du sehen, dass du einen PP braucht.

Ehrlich gesagt mag ich auch an C++ die standard libary nicht. Die fertigen klassen finde ich nicht sehr gut gebrauchbar und schön. Auch ist der name der (template)klasse vektor unpassend.

vector ist aber ein aktzeptierter begriff dafuer.

Ich habe nichts gegen klassen aber gegen von der libary angebotene classen mit überladenen operatoren wie cout.

cout ist kein operator
und es haben kaum klassen den op<< ueberladen, nur die, bei denen es sinn macht, wie zB string.

dein problem ist, dass du keine argumente dafuer bringst.

MasterCounter

Ich hab mir jetzt nicht die ganze Übersicht durchgelesen, aber ganz unten ist ein beispiel D Programm (man sieht "D" sch... aus )

Sample D Program (sieve.d)

/* Sieve of Eratosthenes prime numbers */

bit[8191] flags;

int main()
{ int i, count, prime, k, iter;

printf("10 iterations\n");
for (iter = 1; iter <= 10; iter++)
{ count = 0;
flags[] = 1;
for (i = 0; i < flags.length; i++)
{ if (flags[i])
{ prime = i + i + 3;
k = i + prime;
while (k < flags.length)
{
flags[k] = 0;
k += prime;
}
count += 1;
}
}
}
printf ("\n%d primes", count);
return 0;
}

Das sieht doch irgendwie wie c aus ,
oder hab ich da was falch verstanden?

Shade Of Mine

MasterCounter schrieb:

Das sieht doch irgendwie wie c aus ,

Schau dir das Programm in Java an.
statt printf nimmt man println aber sonst ist es doch essentiell das selbe.

oder hab ich da was falch verstanden?

keine ahnung was du erwartet hast, aber D hat sich C++ als grundlage ausgesucht. da sind die aehnlichkeiten durchaus erwuenscht.

operator void schrieb:

__me schrieb:

Ein foreach ist nie schlecht.

Es zeigt aber IMHO das Problem hinter der D-Philosophie. foreach ersetzt jetzt std::for_each durch etwas "Schöneres". Und wo bleibt ein sort, das std::sort ersetzt?

Es gibt zumindest für Arrays ein sort:

int[] mein_array = [ 5, 3, 0, 6, -3, 7 ];
mein_array.sort;

Klar für andere Container-Klassen als Arrays, müßte dann eine eigene generische Sort-Funktion geschrieben werden. Wie gesagt, da muß man warten bis Template Libraries für D verfügbar sind.

usw. - Hätte man die Mittel bereit gestellt, damit man sich ein benutzbares foreach selbst schreiben kann (so wie Enumerable#each in Ruby z.B.), hätte man mit einer allgemeineren Lösung nicht nur die Spitze des Eisbergs kaschiert.

Was ist den an dem foreach nicht benutzbar? Du brauchst bloß für deine Containerklasse opApply überladen.

Oder um ein anderes Beispiel zu bringen, D stellt für Strings einen eingebauten Typ bereit (verschiebt die Arbeit also in den Compiler), der dann nicht mehr die Probleme von C++-Strings hat. Wieder wäre es mir lieber, die Sprache wüsste nichts über Strings (oder dynamische Arrays im allgemeinen, denn solche sind Strings ja in D) und würde es ermöglichen, eine schönere Stringklasse in der Sprache selbst zu schreiben.
D = Flickenlösung

Niemand zwingt Dich die D internen dynamischen Arrays zu verwenden. Du kannst Dir Deine eigene String/dynamische Array-Klasse schreiben. Und wenns hart auf hart kommt, kannst Du char* verwenden!
Seltsame Argumente gegen D habt ihr da.

ich fände es interessant, eine eigene Standard libary für C++ zu schreiben. Ausser der standard libary gefällt mir fast alles.

entschuldigung ich habe die seite 3 übersehen.
So hier meine antwort:

Shade Of Mine schrieb:

K.a schrieb:

schöner - ja. Aber nur weil list<string>::iterator unschön ist. Das kann man viel schöner programmieren, indem man den iterator oben in der funktion lokal definiert. Dann ist es übersichtlich und man ist sich immer im klaren, welche lokalen variablen erzeugt sind.

Von dem iterator rede ich ja garnicht. aber hast du alle fehler gefunden?
kleiner tipp, es sind 3.
und das in dieser unschuldigen zeile...

Es ist vollkommen unerheblich wieviele fehler in dieser zeile sind. Ich kenne mich mit "D" nich aus und kann das nicht ersehen. Ich weis nicht warum du mich fragst ob ich darin fehler finden kann.

Shade Of Mine schrieb:

ich denke dass es einen anfänger sehr verwirrt, wenn er nicht begreift, dass der << operator von cout nur eine funktion ist und nichts "was der prozessor macht". Normalerweise ist << ja ein bitshifting opetator, wie du sicher weisst.

bitshifting ist fuer den anfaenger aber noch uninteressanter.
und wozu wissen dass << eine funktion ist?
cout<<was_auch_immer;
gibt was_auch_immer aus, ohne dass ich den typen kennen muss.

das ist ja ein kleiner teil der oo philosphie. der typ ist egal, nur das objekt zaehlt.
natuerlich versteht das der anfaenger jetzt noch nicht, aber der mechanismus wird ihm praktisch erscheinen und irgendwann wird er es kapiert haben.

Ich denke TROTZDEM dass ein anfänger verstehen sollte was eine funktion ist und was eine rechenoperation ist die vom (Co)Prozessor ausgeführt wird. Ich denke das ist nicht egal - du siehst es an den meisten leuten die sich programmierer schimpfen: sie haben das system überhaupt nicht verstanden!

Shade Of Mine schrieb:

Wenn er printf allerdings wie jede funktion verwendet, die er selber auch schreiben kann, begreift er dass dahinter programmcode steckt, der aufgerufen wird.

Klar, printf() ist ja trivial, gell?
variadic functions sind etwas, dass ein anfaenger nicht braucht und selbst profis nur sehr selten. also wozu gleich am anfang lernen?
und wieso sich ab muehen und die format specifier lernen, die man dann sowas irgendwann verwechselt und so viele bugs einbaut?

Werden selten gebraucht? Das kommt ganz auf den programmierer an. Dieser mechanismus ist äusserst sinnvoll.
Nicht nur das: auch schneller als manche classen aus der standard libary (str), die nur geschrieben wurden um es anfängern leichter zu machen. Sie finden es vielleicht am anfang leicht, es ist dann für sie allerdings viel schwerer das system hinter C zu verstehen.
Schau die doch die ganzen "programmierer" an! Lieber ein paar wenige gute als viele die von sich sagen sie wären solch tolle programmierer aber in wirklichkeit kennen sie den unterschied zwischen einer compilersprache mit echten funktionen wie C nicht von einer interpretersprache wie PHP auseinander.

Shade Of Mine schrieb:

Er versteht das programm aus einer sammlung von aneinandergehängten funktionen - so wie es auch wirklich ist und nicht aus "befehlen die der cumputer kann".

Aber ein programm ist ja eben _mehr_ als das.
ein programm ist nicht ein "fuehere befehl nach befehl aus".
auf der untersten ebene ist es natuerlich schon, aber wozu fuehren wir dann die abstraktionsschichten ein?

Was höre ich da? Java soll verschwindend gering langsamer sein als C++? Und PHP ist so schnell wie assembler oder wie?
Java ist ein 100tstel so schnell wie C++.
Probier's aus!

Probier du es doch aus. schau dich hier um, hier gab es schon benchmarks.
idr musste man in beiden sprachen etwas tweaken um die maximale leistung herauszuholen und c++ hat zwar immer gewonnen, aber 1) oft mit mehr aufwand und 2) nur mit geringem unterschied. faktor 2-5 etwa.

was na java so lahm ist, ist swing.

es ist mir egal was an java langsam ist! Es IST langsam. Und sicher nicht 2 zu 5.
Ich gebe ja zu dass kleine programmiersprachen wie Java, PHP, SHELL, PERL mal ganz nützlich sein können für kleinere sachen und schnell zu schreiben gehen. Aber für grosse projekte sollte man immer C nehmen. Was glaubst du warum alle grossen projekte C-projekte sind?

Shade Of Mine schrieb:

D ist einfach zu allgemein. C++ und C# beinhalten immer noch C und bezeichnen sich somit nicht als nachfolger!

doch, tun sie. sie beinhalten zwar C, sehen sich aber dennoch als nachfolger an. zumindest c++ wird auch offiziell als nachfolger angesehen.

C++ wird als erweiterung angesehen - das ist es doch auch oder etwa nicht? D ist nicht nur eine erweiterung, z.b. existiert kein preprozessor. Du kannst als C code nicht mit dem D compiler compilieren.
Und weil ja in C der operator ++ für eins erhöhen steht, ist wohl C++ vom namen her auch eine erweiterung. Und D vom namen her ein "nachfolger".

Shade Of Mine schrieb:

Ich wiederhole mich: ungeeignet.
Wie willst du mit D cross-compilieren ohne pre-prozessor?
Wie willst du mit -D_DEBUG compilieren ohne pre-prozessor?
Pre-prozessor hat sehr viele vorteile.

Schau dir D an, dann wirst du sehen, dass du einen PP braucht.

ist das ein tippfehler? Meinst du "keinen" oder "einen". Wenn du "einen" meinst, bin ich ganz deiner meinung. Wenn du "keinen" meinst, frage ich dich, wie du in D crosscompilieren willst. Oder eine debug version? Oder von ausserhalb dem compiler flags für den sourcecode mitgeben? Wie soll dass dann in D gehen?

Shade Of Mine schrieb:

Ehrlich gesagt mag ich auch an C++ die standard libary nicht. Die fertigen klassen finde ich nicht sehr gut gebrauchbar und schön. Auch ist der name der (template)klasse vektor unpassend.

vector ist aber ein aktzeptierter begriff dafuer.

Viel zu allgemein. Als verktor verstehe ich eine basis coordinate und eine ziel coordinate im mathematischen sinne.

Shade Of Mine schrieb:

Ich habe nichts gegen klassen aber gegen von der libary angebotene classen mit überladenen operatoren wie cout.

cout ist kein operator
und es haben kaum klassen den op<< ueberladen, nur die, bei denen es sinn macht, wie zB string.

ja ich meine das "<<" ist ein überladener operator von cout. Ich habe doch gesagt "classen mit überladenen operatoren ----- wie cout", oder nicht?

Shade Of Mine schrieb:

dein problem ist, dass du keine argumente dafuer bringst.

cout finde ich unschön! Warum nicht einfach printf nehmen sondern alles abstaktieren und verwirrend machen für anfänger.

Shade Of Mine

K.a schrieb:

Es ist vollkommen unerheblich wieviele fehler in dieser zeile sind. Ich kenne mich mit "D" nich aus und kann das nicht ersehen. Ich weis nicht warum du mich fragst ob ich darin fehler finden kann.

es ist c++

Ich denke TROTZDEM dass ein anfänger verstehen sollte was eine funktion ist und was eine rechenoperation ist die vom (Co)Prozessor ausgeführt wird. Ich denke das ist nicht egal - du siehst es an den meisten leuten die sich programmierer schimpfen: sie haben das system überhaupt nicht verstanden!

Natuerlich soll man die Grundlagen lernen. dagegen habe ich ja nichts gesagt. nur ist printf ein haessliches monster, dass man lieber nicht seinen eltern vorstellt

Werden selten gebraucht? Das kommt ganz auf den programmierer an. Dieser mechanismus ist äusserst sinnvoll.

Aber nicht fuer anfaenger und auch sonst kommt es selten vor, dass man das wirklich braucht. schau dir mal opensource C code an, wie oft siehst du da variadic functions? es ist die ausnahme...

Nicht nur das: auch schneller als manche classen aus der standard libary (str), die nur geschrieben wurden um es anfängern leichter zu machen.

ne, es sind highperformance strukturen die es _jedem_ leichter machen.

oder willst du mal auf die schnelle eine general purpose string klasse schreiben die schneller als std::string ist? geht wohl kaum.

fuer spezielle faelle kann man natuerlich immer speziellen code schreiben der besser als ein allgemeiner code ist.

Sie finden es vielleicht am anfang leicht, es ist dann für sie allerdings viel schwerer das system hinter C zu verstehen.

reden wir von C oder C++?
die stl gibt es ja nur bei C++ und da ist das system hinter C ja total unwichtig.

Schau die doch die ganzen "programmierer" an!

wen meinst du damit?
ich kenne eigentlich keinen c programmierer der c nicht kapiert. sonst wuerde er es ja nicht programmieren.

oder redest du von den anfaengern die wir hier im forum haben und die c gerade lernen?
na oh wunder, die haben es noch nicht kapiert, aber mal ehrlich: wer kapiert denn schon etwas ohne es zu lernen?

Lieber ein paar wenige gute als viele die von sich sagen sie wären solch tolle programmierer aber in wirklichkeit kennen sie den unterschied zwischen einer compilersprache mit echten funktionen wie C nicht von einer interpretersprache wie PHP auseinander.

PHP hat keine echten funkionen?

es ist mir egal was an java langsam ist! Es IST langsam. Und sicher nicht 2 zu 5.

ignorant

Ich gebe ja zu dass kleine programmiersprachen wie Java, PHP, SHELL, PERL mal ganz nützlich sein können für kleinere sachen und schnell zu schreiben gehen. Aber für grosse projekte sollte man immer C nehmen. Was glaubst du warum alle grossen projekte C-projekte sind?

Alle grossen projekte, wie zB Windows 2000?
oder google? oder warum pusht orcale java so? oder ms setzt auf .net. oder die ganzen Java anwendungen und enterprise beans?

sorry, aber du hast dich selbst disqualifiziert.

C++ wird als erweiterung angesehen - das ist es doch auch oder etwa nicht? D ist nicht nur eine erweiterung, z.b. existiert kein preprozessor. Du kannst als C code nicht mit dem D compiler compilieren.

Ich kann auch nicht jeden C code mit einem c++ compiler kompilieren.

Und weil ja in C der operator ++ für eins erhöhen steht, ist wohl C++ vom namen her auch eine erweiterung. Und D vom namen her ein "nachfolger".

dh, B ist der nachfolger von C aber 2 die erweiterung von 1?

cout finde ich unschön! Warum nicht einfach printf nehmen sondern alles abstaktieren und verwirrend machen für anfänger.

weil printf nicht in eine oo sprache passt. du musst immer den typen kennen, und das ist nicht akzeptabel.

sorry, aber ich klinke mich lieber aus. das ist nicht lustig sondern nur laecherlich...

SideWinder

Ich kenne mich mit "D" nich aus und kann das nicht ersehen.

*plonk*, das ist C++

/Edit: Unfair, der Junge ist immer schneller :p

MfG SideWinder

operator void

Ein Gast schrieb:

Es gibt zumindest für Arrays ein sort:
int[] mein_array = [ 5, 3, 0, 6, -3, 7 ];
mein_array.sort;

Da habe ich in der Tat das wichtigste vergessen: Ich meinte ein sort mit Prädikat. Von mir aus auch ein find mit Prädikat, oder alles, was so in <algorithm> rumschwirrt.
Als C++ler sehe ich for_each nur als eine Funktion von vielen, die man mit einem Prädikat ausstatten kann. Leider ist das Konstruieren dieser Prädikate in C++ sehr hässlich. (Und das ist ein Problem, sonst würde man sich nicht die Mühe machen, Boost.Lambda usw. zu schreiben.)
Da hilft D im Fall von for_each nach, indem es foreach in die Sprache einbaut. Lieber wäre es mir, D hätte so minimalistische Blöcke wie Ruby, dass man sich ein foreach, das annähernd schön wie ein eingebautes ist, selbst schreiben kann.