Verleitet die Mächtigkeit der Sprache C++ dazu es kompliziert zu machen?

[volkard]

großbuchstaben schrieb:

Abgesehen davon:
Wie ist die Mächtigkeit einer Sprache definiert ?
Funktionalität pro Codezeile?
Anzahl äquivalenter Assemblerbefehlszeilen pro (hochsprachlichem) Konstrukt ?
Oder Skalierbarkeit - von hardwarenah (Zeiger, direkte I/O) bis abstrakt (Template-Metaprog.), von uController bis HPC?

Vielleicht daß man weniger oft ein Projekt wegen Sprachbeschränkungen aufgeben muss.

Keiner weiß es und früher war "Mächtigkeit" ein gutes Schlüsselwort um zu sagen, daß man im weiteren Verlauf des Threads nicht mehr gelesen werden möchte.

[tiefesCpp]

Seien wir mal ehrlich. Wenn man in der heutigen Zeit bei einem Projekt C++ vermeiden kann, dann tut man dies. Es ist schon schwer eine Sprache zu finden, die so komplex ist und bei der mich sich soo derbe ins Bein schießen kann, wenn man nicht gerade eine Profi ist.

[Marthog]

tiefesCpp schrieb:

Seien wir mal ehrlich. Wenn man in der heutigen Zeit bei einem Projekt C++ vermeiden kann, dann tut man dies. Es ist schon schwer eine Sprache zu finden, die so komplex ist und bei der mich sich soo derbe ins Bein schießen kann, wenn man nicht gerade eine Profi ist.

Wenn es um Geschwindigkeit gehen soll, ist C++ die Sprache der Wahl. GUI-Anwendungen und kleine Apps kann man ja gerne in einer anderen Sprache schreiben, aber wenn man sich mal ueberlegt, was ein Durchschnittsbenutzer alltaeglich verwendet, dann sind das Browser, E-mail-client, ein schlanker und moeglichst schneller Texteditor, PDF-Reader, VLC-Player, Office-Programm, Bildbetrachtung, VLC-Player, Webanwendungen (Facebok, Google, kleine Spiele) und natuerlich die ganzen Betriebssystemskomponenten.

Ausser E-mail muessen alle Programme an bestimmten Stellen schnell sein und seien es nur die Ladezeiten bei PDF-Reader und Bildbetrachtung. Dafuer bleibt eigentlich nur noch C (wofuer man auch gute Programmierer braucht) und C++.

[Ethon]

Halte ich für ein Gerücht dass diese Userprogramme irgendwie besondere Ansprüche an Performance stellen würden.
Notfalls schreibt man halt den kleinen, performancekritischen Teil in einer nativen Sprache (wobei man da lieber C als C++ nimmt) und bindet es im Programm ein.

[Marthog]

Viele Programme sind fuer meinen Geschmack beim Laden von Daten zu langsam und das liegt nicht nur an der Festplatte, sondern daran dass sie ewig zum Verarbeiten brauchen. Es kann natuerlich auch an schlechten Algorithmen liegen, aber nach meiner Erfahrung gibt es noch genug Sachen mit Nachbesserungsbedarf.

[Dobi]

Seh ich ähnlich. Aber nur wegen der 2%* Code in denen 97%* der CPU-Zeit draufgehen muss man sich C oder C++ ja nicht auch unbedingt in den anderen 98% Code antun. Viele "high-level"-Sprachen haben ja ein gutes FFI, und manchmal findet man auch schon eine fertige durchoptimierte lib.

*Für die Zahlen habe ich keine statistische Grundlage, nur etwas subjektive Erfahrung. Sie sind vermutlich trotzdem meistens falsch, was aber für die eigentliche Aussage nicht so wichtig ist.

[Kellerautomat]

Ethon schrieb:

Halte ich für ein Gerücht dass diese Userprogramme irgendwie besondere Ansprüche an Performance stellen würden.
Notfalls schreibt man halt den kleinen, performancekritischen Teil in einer nativen Sprache (wobei man da lieber C als C++ nimmt) und bindet es im Programm ein.

Was machst du eigentlich noch hier? Preist ueberall D an, und wenns mal nicht passt dann C.

[Ethon]

Ich programmiere C++.
Finde D besser, ändert aber nichts an der Tatsache dass ich es sehr selten programmiere.

[5cript]

Ich habe C++ als erstes gelernt, und das Problem was nun entsteht, wenn ich gezwungen bin eine andere Sprache zu verwenden, ist, dass mir einfach so viel fehlt. Ich verwende nur, was ich brauche und wenn die Usability meines codes einfacher wird durch ein bisschen "Eleganz", dann entscheide ich mich gerne mal dafür.

Folgendes Beispiel zeigt, warum es mir Wert ist, manchmal an einer Stelle mehr Arbeit zu machen. Nebenbei ist es ein Anti-Beispiel, dass zeigt, wie Komplexität an den richtigen Stellen dazu führt, dass Code super simpel wird.
(Beispielcode zu meiner eigenen JSON Bibliothek)

struct SerializableClient : public JSON::FusionStruct<SerializableClient>
{
    uint32_t UID;
    uint32_t login_fails;
    std::string name;
    std::string ip;
    uint16_t port;
    Package pack; // has been adapted too
};

BOOST_FUSION_ADAPT_STRUCT
(
    SerializableClient,
    (uint32_t, UID)
    (uint32_t, login_fails)
    (std::string, name)
    (std::string, ip)
    (uint16_t, port)
    (Package, pack)
)

//...

{
// super kurz:
    SerializableClient client;
    js_parse(client, "client", source);
    std::string str = js_stringify("client", client);
}

(funktioniert mit allen standard containern und mehr)
(Andererseits könnte man nun sagen, dass andere Sprachen Introspection haben, aber das ist ja nicht mein Punkt :p )

[Gast]

Das ist superkurz und elegant und hat noch einen Errorhandling!

case class User(name: String, email: String, pwd: String)

object User {
  implicit val userReads: Reads[User] = Json.reads[User]
  implicit val userWrites: Writes[User] = Json.writes[User]
  implicit def userToJson(user: User) = Json.toJson(user)
}

def registerUser = Action(BodyParsers.parse.json) { request =>
  request.body.validate[User] match {
    case jsUser: JsSuccess[User] => // Do something
    case error: JsError => // Error Handling
  }
}

[tntnet]

IBV schrieb:

Das ist superkurz und elegant und hat noch einen Errorhandling!

case class User(name: String, email: String, pwd: String)

object User {
  implicit val userReads: Reads[User] = Json.reads[User]
  implicit val userWrites: Writes[User] = Json.writes[User]
  implicit def userToJson(user: User) = Json.toJson(user)
}

def registerUser = Action(BodyParsers.parse.json) { request =>
  request.body.validate[User] match {
    case jsUser: JsSuccess[User] => // Do something
    case error: JsError => // Error Handling
  }
}

Um welche Programmiersprache handelt es sich hier? Ich kann kein Java erkennen.

[n3wbie]

Performance ist oft mehr eine Frage der Umsetzung als der Sprache.
Ein Bubble-Sort über 35.000 Einträge wird in C++ langsamer sein als in Java.

[Nathan]

n3wbie schrieb:

Ein Bubble-Sort über 35.000 Einträge wird in C++ langsamer sein als in Java.

Und wieso sollte das so sein?

[n3wbie]

Sry. Ich wollte schreiben

Ein Bubble-Sort über 35.000 Einträge wird in C++ langsamer sein als ein Quicksort in Java.

[Bashar]

Trägt das irgendwas zum Thema bei? Mal abgesehen davon, dass es nur ein trivialer Allgemeinplatz ist, mein ich.

[n3wbie]

Bashar schrieb:

Trägt das irgendwas zum Thema bei? Mal abgesehen davon, dass es nur ein trivialer Allgemeinplatz ist, mein ich.

Ja, trägt es durchaus, wenn man das Beispiel überträgt. Wenn etwas zu langsam ist, sollte man sich erstmal Gedanken über das Problem machen statt einfach die Sprache zu wechseln.

Kellerautomat schrieb:

Ethon schrieb:

Halte ich für ein Gerücht dass diese Userprogramme irgendwie besondere Ansprüche an Performance stellen würden.
Notfalls schreibt man halt den kleinen, performancekritischen Teil in einer nativen Sprache (wobei man da lieber C als C++ nimmt) und bindet es im Programm ein.

Was machst du eigentlich noch hier? Preist ueberall D an, und wenns mal nicht passt dann C.

Wenn der Browser zu langsam ist, macht es Sinn herauszufinden warum er zu langsam ist, und die Umsetzung zu verbessern. Dann kann man immer noch über die Sprache nachdenken.

[Mechanics]

Ja und nein... Klar ist die Sprache allein nicht entscheidend. Wir entwickeln zwar in C++, aber viele Teile unserer Software sind aus Performancesicht bei weitem nicht optimal geschrieben. Vieles davon ist auch nicht wirklich relevant, einiges schon. Performance ist aber nicht das einzige Kriterium, Flexibilität, Konfigurierbarkeit und Erweiterbarkeit sind zumindest bei uns oft wichtiger. Und da ist es wiederum nicht schlecht, wenn die Sprache von Grund auf "schneller" ist, da verschenkt man zumindest nicht grundlos Performance. Und in C++ ist es oft einfacher, etwas zu optimieren, da hat man mehr Möglichkeiten.

Aber das Thema war doch eigentlich, ob die Mächtigkeit der Sprache dazu verleitet, etwas komplizierter zu machen?

[In Fuß schießen is doof]

Marthog schrieb:

Wenn es um Geschwindigkeit gehen soll, ist C++ die Sprache der Wahl.

Das gilt aber nur, weil die Compiler hochoptimiert sind.

Gäbe es vergleichbare Compiler für D, dann wäre D besser.

Ausser E-mail muessen alle Programme an bestimmten Stellen schnell sein und seien es nur die Ladezeiten bei PDF-Reader und Bildbetrachtung. Dafuer bleibt eigentlich nur noch C (wofuer man auch gute Programmierer braucht) und C++.

Aus dem Grund nutze ich µTorrent als Torrent Client.
Die anderen waren mir bisher alle zu fett.

µTorrent <= 1 MB
Irgendso ein anderer Torrent Client hat 60 MB benötigt.
So groß waren früher höchstens C++ Compiler.

[SeppJ]

In Fuß schießen is doof schrieb:

Aus dem Grund nutze ich µTorrent als Torrent Client.
Die anderen waren mir bisher alle zu fett.

µTorrent <= 1 MB
Irgendso ein anderer Torrent Client hat 60 MB benötigt.
So groß waren früher höchstens C++ Compiler.

Klar, denn das sind ganz klar 60 MB Bibliotheksfunktionen und Code. Keinesfalls könnten das 60 MB an GUI-Elementen sein. Ausgeschlossen.

[In Fuß schießen ist doof]

SeppJ schrieb:

In Fuß schießen is doof schrieb:

Aus dem Grund nutze ich µTorrent als Torrent Client.
Die anderen waren mir bisher alle zu fett.

µTorrent <= 1 MB
Irgendso ein anderer Torrent Client hat 60 MB benötigt.
So groß waren früher höchstens C++ Compiler.

Klar, denn das sind ganz klar 60 MB Bibliotheksfunktionen und Code. Keinesfalls könnten das 60 MB an GUI-Elementen sein. Ausgeschlossen.

Afaik war das Deluge und das in einer der fetten Versionen wie man sie hier noch finden kann:

http://download.deluge-torrent.org/archive/windows/0.9.02/

Allein die Python Scripte sind entpackt allein schon 20 MB groß.

Das ganze ist schon ein paar Jahre her, ich kann mich nur erinnern dass ich ein richtig fettes Packet downloaden musste.
Die 40 MB könnten es gewesen sein, auch wenn ich eher 60 MB in Erinnerung habe.
Auch weiß ich nicht mehr genau, wie fett das Teil dann im installierten Zustand gewesen ist. So etwa 60-120 MB waren es aber schon, denn ich war so geschockt von dem Platzverbrauch, dass ich mich dann bewusst für µTorrent entschied.

Und Fakt ist, dass es mit dieser Größe nicht gegen µTorrent anstinken kann.
Da sieht es richtig alt aus.
Man stelle sich mal vor, man sucht nur nen Torrent Client.
Will so etwas einfaches wie nur nen Torrent Client und dann kriegt man so ein Fettpaket.

Da das ganze unter Windows laufen sollte, zählen die Supportlibs zur Platzverschwendung mit dazu.
Das gleiche gilt für die Ladezeiten, wenn das ganze Geraffel geladen werden muss.

Es ist schon erstaunlich. µTorrent kann genau das gleiche, aber es braucht nur einen Bruchteil des Platzes und ist Ratzfatz geladen, auch mit HD ohne SSD.

Obwohl ich damals einen Crossplattformfähigen Open Source Torrent Clienten gesucht habe, habe ich mich dann nach dem Schock über den Platzverbrauch dann doch für den nur unfreien Freeware µTorrent Clienten entschieden.
Lediglich für Linux habe ich dann einen anderen genommen.

Aber eines steht fest, wer für so etwas im Prinzip kleines wie einen Torrent Clienten als Entwickler 40 MB verheizt, der gehört im Grunde bestraft.
In 40 MB hat man früher ganze Betriebssysteme untergebracht und die haben mehr geleistet.

Es ist ne Schande, so ein Platzfresser.

Soviel zum Thema