Ist man mit der Programmiersprache D 2.0 anstatt C++ (C++11) schneller am Ziel?

[volkard]

Meine Meinung schrieb:

volkard schrieb:

Ethon schrieb:

Ist auch kein Zufall dass Java 100x relevanter ist als C++, egal ob man Java mag oder nicht.

So wichtig, daß ich kein Java auf dem PC habe. Naja, ich bin aber auch kein Zocker, sonst müßte ich ja wegen der vielen modernen 3d-Spiele Java drauf haben. Mit Minecraft ist Java auf einmal vorn in die Spielewelt eingebrochen, nun gibt es nur noch Browser, Server, Compiler, Office-Suiten, Datenbankmaschinen, Numbercrunching und wissenschaftliche Simulationen, die klar von Java frei oder unbrauchbar sind.

Ähm eigentlich ist Java in der Geschäftswelt heimisch und nicht in der Spielewelt.

Dutzende Auftragsentwicklungen werden in Java realisiert, Spiele werden kaum welche geschrieben und Minecraft ist übrigens ein guter Punkt für die Frage.
Als Indie Entwickler der das am Anfang alles alleine stemmen musste, kam er mit Java sicherlich wesentlich schneller ans Ziel.
Dafür ist Minecraft nun langsamer, aber Kohle hat es ihm trotzdem ohne Ende eingebracht und falls es mal ein Minecraft 2 geben sollte, dann bin ich zuversichtlich, dass er es mit einem > 50 Mann Team dann in C++ oder ähnliches realisieren wird.

Hirn einschalten!

[volkard]

Ethon schrieb:

Sogar im Spielesektor verliert C++ nach und nach an Bedeutung.

*lach*
Hab Dich mit Minecraft in eine Falle gelockt. Du argumentierst wie deine Mutter. Mit erfunden "Fakten" oder gar nicht und die wenigen beobachtbaren Tatsachen ordnet sie merkbefreit ein.

[Tyrdal]

Ethon schrieb:

Soso, und in welchem Bereich der Zukunft glänzt C++ denn? Im Web? Bei Apps? Bei Desktop-Programmen?

Du weißt schon, daß es noch sehr viel mehr Gebiete mit Software gibt?

[Meine Meinung]

volkard schrieb:

Meine Meinung schrieb:

volkard schrieb:

Ethon schrieb:

Ist auch kein Zufall dass Java 100x relevanter ist als C++, egal ob man Java mag oder nicht.

So wichtig, daß ich kein Java auf dem PC habe. Naja, ich bin aber auch kein Zocker, sonst müßte ich ja wegen der vielen modernen 3d-Spiele Java drauf haben. Mit Minecraft ist Java auf einmal vorn in die Spielewelt eingebrochen, nun gibt es nur noch Browser, Server, Compiler, Office-Suiten, Datenbankmaschinen, Numbercrunching und wissenschaftliche Simulationen, die klar von Java frei oder unbrauchbar sind.

Ähm eigentlich ist Java in der Geschäftswelt heimisch und nicht in der Spielewelt.

Dutzende Auftragsentwicklungen werden in Java realisiert, Spiele werden kaum welche geschrieben und Minecraft ist übrigens ein guter Punkt für die Frage.
Als Indie Entwickler der das am Anfang alles alleine stemmen musste, kam er mit Java sicherlich wesentlich schneller ans Ziel.
Dafür ist Minecraft nun langsamer, aber Kohle hat es ihm trotzdem ohne Ende eingebracht und falls es mal ein Minecraft 2 geben sollte, dann bin ich zuversichtlich, dass er es mit einem > 50 Mann Team dann in C++ oder ähnliches realisieren wird.

Hirn einschalten!

Du widersprichst mir bei dieser Aussage:

Ähm eigentlich ist Java in der Geschäftswelt heimisch und nicht in der Spielewelt.

????

Dann weise ich das "Hirn einschalten!" mit Recht an dich zurück.

[volkard]

Meine Meinung schrieb:

volkard schrieb:

Meine Meinung schrieb:

volkard schrieb:

Ethon schrieb:

Ist auch kein Zufall dass Java 100x relevanter ist als C++, egal ob man Java mag oder nicht.

So wichtig, daß ich kein Java auf dem PC habe. Naja, ich bin aber auch kein Zocker, sonst müßte ich ja wegen der vielen modernen 3d-Spiele Java drauf haben. Mit Minecraft ist Java auf einmal vorn in die Spielewelt eingebrochen, nun gibt es nur noch Browser, Server, Compiler, Office-Suiten, Datenbankmaschinen, Numbercrunching und wissenschaftliche Simulationen, die klar von Java frei oder unbrauchbar sind.

Ähm eigentlich ist Java in der Geschäftswelt heimisch und nicht in der Spielewelt.

Dutzende Auftragsentwicklungen werden in Java realisiert, Spiele werden kaum welche geschrieben und Minecraft ist übrigens ein guter Punkt für die Frage.
Als Indie Entwickler der das am Anfang alles alleine stemmen musste, kam er mit Java sicherlich wesentlich schneller ans Ziel.
Dafür ist Minecraft nun langsamer, aber Kohle hat es ihm trotzdem ohne Ende eingebracht und falls es mal ein Minecraft 2 geben sollte, dann bin ich zuversichtlich, dass er es mit einem > 50 Mann Team dann in C++ oder ähnliches realisieren wird.

Hirn einschalten!

Du widersprichst mir bei dieser Aussage:

Ähm eigentlich ist Java in der Geschäftswelt heimisch und nicht in der Spielewelt.

????

Dann weise ich das "Hirn einschalten!" mit Recht an dich zurück.

- Wundere Dich nicht, daß ich auch mal ganze Texte abweise, die nur zu 95% Unfug sind.
- Ich weiß, wo Java wohnt und warum.

Soll ich Dir Satz für Satz beibringen, wo Du unrecht hast oder irrelevant sprichst? Nee, hab's aufgegeben, denn tausend Wissenschaftler können nicht widerlegen, was ein Überzeugungsnarr raushauen kann. Darum reicht es mir vollauf, gelegentlich kenntlich zu machen, welche Richtung Zonentaxonomie ist.

[kkaw]

Ethon schrieb:

D ist definitivIMHO ein verbessertes C++

FTFY.

[Ethon]

kkaw schrieb:

Ethon schrieb:

D ist definitivIMHO ein verbessertes C++

FTFY.

Was ist denn in C++ besser gelöst als in D?
Mal die "Mimimi, die Std-Lib funktioniert größtenteils ohne GC nicht"-Problematik ausgenommen?

[Fytch]

was ist eigentlich der grund wieso mehrfachvererbung in D nicht erlaubt wurde?

[großbuchstaben]

Ethon schrieb:

großbuchstaben schrieb:

ich denke, C++ hat seine beste Zeit erst noch vor sich.

C++11 ist ein ganz großer Wurf. Für mich der größte Fortschritt seit Einführung der STL.

Soso, und in welchem Bereich der Zukunft glänzt C++ denn? Im Web? Bei Apps? Bei Desktop-Programmen?

meiner Erwartung nach dort, wo Eigenschaften wie OOP + generische Programmierung + zero overhead + Libraries wichtig sind. Resourcenkritische Großprojekte. Number crunching. Libraries.

[Ethon]

asfdlol schrieb:

was ist eigentlich der grund wieso mehrfachvererbung in D nicht erlaubt wurde?

Multiple inheritance. It's a complex feature of debatable value. It's very difficult to implement in an efficient manner, and compilers are prone to many bugs in implementing it. Nearly all the value of MI can be handled with single inheritance coupled with interfaces and aggregation. What's left does not justify the weight of MI implementation.

http://dlang.org/overview.html

[Mal ein Beispiel]

volkard schrieb:

Mal ein Beispiel schrieb:

Okay, vergleichen wir mal:

/* fussschuss.cpp */

#include <iostream>

using namespace std;

int main(){
  bool kaputt = false;

  if (!kaputt){
    cout << "okay\n";
  }
  
  // aber C++ erlaubt es auch, mit schlechtem Stil sich in den Fuss zu schiesen:
  if (kaputt == false){
        cout << "okay\n";
  }
  // soweit noch okay, aber:
  if (kaputt = false){
        cout << "okay\n";
  } else {
    cout << "BUMMM!!!\n";
  }
  
  return 0;
}

Dazu zum Vergleich:

/* Ich benutze mal das C Tag, weil es im Forum noch kein Tag für D gibt. */

/* nix_fussschuss.d */
 
import std.stdio;
 
void main()
{
  bool kaputt = false;
  
  if (!kaputt){
     writeln("okay\n");
  }
  
  // so weit okay, aber 
  if (kaputt == false){  // BUMM, Compilererror + Warnung, da nicht erlaubt
         writeln("okay\n");
  }

  // Wegen BUMM von oben kann das erst gar nicht passieren:
  if (kaputt = false){ // gibt alleine ebenfalls nen Compilererror
         writeln("okay\n");
  } else {
     writeln("BUMM!!!\n");
  }
  
  return 0;
}

Fazit:

D vermeidet schlechten Stil, man läuft dadurch weniger Gefahr sich in den Fuss zu schiessen und ist somit schneller mit der Arbeit fertig.

Compiler-Warnungen einschalten.

Was die Sprache nicht kann, dass muss der Compiler fixen.
So nach dem Motto?

Und wer schreibt so miesen Code und macht ne Zuweisung in einer If Bedingung um dann anhand deren Wahrheitswert fortzufahren?
Das ist IMO ganz schlechter Programmierstil.

[Einspruch]

Wenn C++ die Entwicklung nicht verlangsamt, wieso verwenden dann alle kleinen Indie Game Entwickler überwiegend Sprachen wie Java oder C#?

Nur um mal ein paar sehr bekannte Beispiele zu nennen:

Minecraft* -> Java
Terraria -> C#
Kerbal Space Program -> C#
Project Zomboid -> Java

* Okay, wurde schon genannt, aber der Vollständigkeit halber und weil es das bedeutendste Indie Spiel der letzten Jahre ist.)

Bzw. warum wurden gerade die Indie Spiele, die am meisten her machen, also viel Aufwand vermuten lassen, in Java oder C# entwickelt?
Meine Vermutung, die Projekte vergleichbarer Komplexität, die es in C++ versuchten, sind noch nicht fertig oder dauerten zu lange, so dass sie die Lust verloren haben.

[kkaw]

Einspruch schrieb:

Wenn C++ die Entwicklung nicht verlangsamt, wieso verwenden dann alle kleinen Indie Game Entwickler überwiegend Sprachen wie Java oder C#?

Die Prämisse der ursprünglichen Frage hat nicht viel mit der Realität zu tun. Beispielsweise wurden Aspekte wie Vielfältigkeit der Standardbibliothek oder Güte des Tool-Supports ignoriert. Dem Fragesteller ging es anscheinend um das Potential einer Sprache, weniger um die tatsächlich aktuelle Entwicklungsgeschwindigkeit.

Außerdem passen die Sprachen Java und C# hier meiner Meinung nach nicht so ganz in den Thread, weil sie nicht den Anspruch von C++ und D (bzgl "Systemprogrammierung") erheben wollen. Die Indie-Spieleentwickler nehmen wissentlich Performanceeinbußen in Kauf, wenn sie Java und C# verwenden -- wobei ich bei C# gegenüber Java noch den Vorteil sehe, dass man für leichtgewichtige struct s nicht extra den Heap bemühen muss und dadurch ein ggf besseres Speicherlayout erzielen kann. You get what you pay for.

Und D scheint eher ein C# mit const / immutable und Templates zu sein. Ich muss zugeben, dass dieses "transitive const" für mich keinen Sinn ergibt. Kommt mir echt komisch vor. Kam mir auch komisch vor, als Alexandrescu für C++ mal im Usenet (comp.lang.c++ oder so) vorschlug, Konstruktoren mit const überladen zu können. Ich werde das Gefühl nicht los, als hätte er da bzgl const etwas nicht verstanden. Was mich auch davon abhält, mich mehr mit D zu beschäftigen, sind immer diese polemischen Passagen in Texten über D, die sich auf C++ beziehen und dabei aus Mücken Elefanten machen. Man merkt irgendwie, dass die D Entwickler Mühe haben, ihre Sprache zu verkaufen. Beispielsweise wird suggeriert, dass "transitives const" in C++ fehle, wobei es dort aber überhaupt keinen Sinn machen würde, weil Dir in C++ für Klassen auch keiner eine Indirektion aufzwingt ("reference types"). Du hast sozusagen schon "transitives const" bzgl echter Datenelemente, weil Du in C++ größere Objekte direkt aus kleineren zusammensetzen kannst. Aber das wird dann gerne mal unterschlagen.

Ja, natürlich hat D nicht all die syntaktischen Krankheiten aus C++. Wäre ja auch blöd, wenn die D Entwlicker nicht aus C++ gelernt hätten. Aber sie haben versucht, den Spagat zwischen deterministisch aufgerufenen Destruktoren und nicht-deterministicher Garbage-Collection zu machen. Hatte aber nicht den Eindruck, als sei das gut gelungen. Es fühlte sich eher nach Feature-Creep an als ein durchdachtes Design.

[Ethon]

kkaw schrieb:

Aber sie haben versucht, den Spagat zwischen deterministisch aufgerufenen Destruktoren und nicht-deterministicher Garbage-Collection zu machen. Hatte aber nicht den Eindruck, als sei das gut gelungen. Es fühlte sich eher nach Feature-Creep an als ein durchdachtes Design.

Hmm? Eine struct ist ein Objekt das auf dem Stack lebt und bei verlassen des Scopes zerstört wird, genau wie in C++. Eine Klasse ist polymorph, lebt auf dem Heap und wird zerstört wenn der GC sie einsammelt. Oder man ruft delete auf und zerstört sie sofort.

Finde dass man damit eigentlich ziemlich genau die Werkzeuge hat um jeden Anwendungsfall elegant lösen zu können.

[ScottZhang]

Im Grunde ist ja die Annahme dass ein Programm Müll erzeugt schon Müll.

[kkaw]

Ethon schrieb:

Hmm? Eine struct ist ein Objekt das auf dem Stack lebt und bei verlassen des Scopes zerstört wird, genau wie in C++. Eine Klasse ist polymorph, lebt auf dem Heap und wird zerstört wenn der GC sie einsammelt. Oder man ruft delete auf und zerstört sie sofort.

Gibt's dann noch "RAII für Klassen" a la unique_ptr und co für deterministische Zerstörung? Darf man struct-Werte im Heap anlegen? Polymorphie ist ja eine Sache, Lebenszeit eine andere. Ich kann vielleicht doch nicht vorhersehen, ob ein Benutzer meinen struct-Typ direkt irgendwo einbetten will (Stack oder Datenmenber) oder eben doch im Heap halten will, um die Lebenszeit zu verlängern. Oder muss er dafür das Ding in ein 1-elementiges Array kopieren, was dann per Heap/GC gemanaged wird? Wie ernst nimmt D das "Ownership-Konzept"? Die Unterscheidung zwischen struct und class in D sowie C# wird als Vorteil verkauft. Ich sehe darin eine unnötige Inkonsistenz im Typsystem, welche generisches Programmieren erschweren könnte.

[Ethon]

kkaw schrieb:

Gibt's dann noch "RAII für Klassen" a la unique_ptr und co für deterministische Zerstörung?

unique_ptr wäre mit minimalem Aufwand implementierbar wenn man ihn braucht. (Falls es soetwas nicht in der StdLib gibt, kA, nie gebraucht). Alternativ gibt es ScopeGuards mit denen man zb. folgendes machen könnte:

void foo()
{
    auto a1 = new A(), a2 = new A();
    scope(exit) destroy(a1); // a1 wird auf jeden Fall am Ende des Scopes zerstört.
    scope(failure) destroy(a2); // a2 wird nur zerstört wenn der Scope nicht fehlerfrei verlassen wird.
    mightThrow();
}

kkaw schrieb:

Darf man struct-Werte im Heap anlegen? Polymorphie ist ja eine Sache, Lebenszeit eine andere. Ich kann vielleicht doch nicht vorhersehen, ob ein Benutzer meinen struct-Typ direkt irgendwo einbetten will (Stack oder Datenmenber) oder eben doch im Heap halten will, um die Lebenszeit zu verlängern. Oder muss er dafür das Ding in ein 1-elementiges Array kopieren, was dann per Heap/GC gemanaged wird? Wie ernst nimmt D das "Ownership-Konzept"?

http://dlang.org/struct.html

kkaw schrieb:

Die Unterscheidung zwischen struct und class in D sowie C# wird als Vorteil verkauft. Ich sehe darin eine unnötige Inkonsistenz im Typsystem, welche generisches Programmieren erschweren könnte.

Naja, D hat ein sehr ausgefeiltes Template/Trait System, generische Programmierung ist eigentlich kein Problem.

[kkaw]

Ethon schrieb:

Alternativ gibt es ScopeGuards

Ih! Ja, ich erinnere mich... Noch cooler wär's natürlich, diese scope guards gar nicht hinschreiben zu müssen.

Ethon schrieb:

kkaw schrieb:

Darf man struct-Werte im Heap anlegen? Polymorphie ist ja eine Sache, Lebenszeit eine andere. Ich kann vielleicht doch nicht vorhersehen, ob ein Benutzer meinen struct-Typ direkt irgendwo einbetten will (Stack oder Datenmenber) oder eben doch im Heap halten will, um die Lebenszeit zu verlängern. Oder muss er dafür das Ding in ein 1-elementiges Array kopieren, was dann per Heap/GC gemanaged wird? Wie ernst nimmt D das "Ownership-Konzept"?

http://dlang.org/struct.html

Auf der Seite war ich vorhin schon. Keine Ahnung, warum Du sie verlinkt hast. Sie scheint meine Fragen nicht zu beantworten. Oder ich habe es schon wieder übersehen. Ich kann da auch nicht drin erkennen, dass man sich per struct einen move-only Typen bauen kann, der eine Ressource besitzt. Müsstest Du mir als D-Profi mal zeigen, wie sowas geht. "postblit" kann das Original z.B. nicht anfassen. Von Move-Konstruktoren sehe ich da nichts. Und bei der Zuweisung werden auch nur Bits kopiert, was im Fall eines unique_ptr ein Speicherleck bedeuten würde. Zeig mir doch bitte, wie man in D folgendes nachbauen kann, ohne die Zahl von Heap-Allozierungen zu erhöhen:

#include <iostream>
#include <memory>

unique_ptr<int> source() {
   return make_unique<int>(42);
}

void sink(unique_ptr<int> p) {
   std::cout << *p << std::endl;
}

int main() {
   sink(source());
}

Natürlich ist int hier nur ein Platzhalter für irgend eine andere Ressource, wo man keine sinnvolle Kopiersemantik für definieren kann. Ziel: Automatisches, aber deterministisches Freigeben der Resource. Ich will den GC doch nicht unnötig bemühen! ...besonders dann nicht, wenn er regelmäßig die Welt anhält.

[Ethon]

kkaw schrieb:

Ih! Ja, ich erinnere mich... Noch cooler wär's natürlich, diese scope guards gar nicht hinschreiben zu müssen.

Deterministisch etwas zerstören zu müssen und es nicht dem GC zu überlassen sehe ich mal als Spezialfall an. Da kann man sich mal das etwas mehr tippen antun. Muss man in C++ ja immer.

---

import std.typecons;
import std.stdio;

struct A
{
    int v;

    this(int v)
    {
        this.v = v;
        writeln("Create");
    }

    this(this)
    {
        writeln("Postblit");
    }

    ~this()
    {
        writeln("Destroy");
    }
}

Unique!A source()
{
   return Unique!A(new A(42));
}

void sink(Unique!A p)
{
    writeln(p.v);
}

void main()
{
    sink(source());
}

[ethon@desktop-fedora-20 WorkDir]$ ./bla 
Create
42
Destroy

Würde voll passen wenn die StdLib Implementierung von Unique nicht ewig brachliegen würde - vermutlich weil es nie jemand braucht - und der Typ nicht Kopien erlauben würde.
Man kann sich aber einfach die Definition von Unique rauskopieren und das auskommentierte "this(this) = null;" durch "@disable this(this);" ersetzen.
kA was bei denen los ist, wäre ich nicht so faul würde ich mal nachfragen was der Mist in der Stdlib soll.

[großbuchstaben]

Ethon schrieb:

Hmm? Eine struct ist ein Objekt das auf dem Stack lebt und bei verlassen des Scopes zerstört wird, genau wie in C++.

nur, daß eine struct in C++ kein *Objekt*, sondern eine *Klasse* ist, deren members und bases public sind, wenn nichts Anderes angegeben wird (im Unterschied zu class, wo sie privat sind, wenn nicht anders angegeben). Ein Objekt wird daraus durch Instanziierung.