vergesst C++ ...

Artchi

O'Rakl schrieb:

Nein. C++ und C sind nicht voneinander unabhängig, ebensowenig wie etwa Visual Basic und Tiny Basic voneinander unabhängig sind. C++ hieß ursprünglich "C with classes", das kann dir gefallen oder nicht, es ist nun mal so.

Dann erklär uns doch bitte mal, warum ein C-Programm (ich meine eines, das den aktuellen C-Standard voll ausnutzt) sich auf einem reinen C++-Compiler (auch aktuell) nicht kompilieren lassen würde?

Wie kann da also C++ ein C sein, wenn es nicht alle Eigenschaften von C geerbt hat?

O'Rakl schrieb:

Putzig: Da muß ich euch noch sagen, wie C++ hieß, bevor es "C++" hieß.
Einige wollen hier wohl leider nur streiten um des Streitens willen.
Egal.

Und du meinst, Recht zu haben, obwohl dir das ganze Forum über 30 Seiten etwas anderes sagt. Sehr putzig. Und jetzt geh spielen.

Power Off

volkard schrieb:

nein. Power Off hat wirklich das alles gemacht, von dem er erzählt. hoffentlich hat er das auch fachgerecht entsorgt. ok, ob der nen compiler nu wirklich geschrieben hat, oder damals das drachenbuch gelesen hat, kann man nicht entscheiden.

Du kannst das bestimmt nicht entscheiden!

Ich habe schon viele Compiler geschrieben, keinen vollstaendigen Hochsprachencompiler, falls Du das meinst, aber Compiler fuer anwendungsspezifische Sprachen. Und Compilergeneratoren und Universal-Syntax-Analyzer.

Das meiste, was ich ueber Compilerbau weiss, hab ich, wie ich bereits gesagt habe, aus "BCPL - The Language And Its Compiler". Das "Drachenbuch" habe ich auch.

. . .

So geht man doch nicht miteinander um. Bin ich wieder im Kindergarten gelandet?

Artchi

Lass dich doch von Volkard nicht so provozieren. Er ist hier der Gerhard Schröder...

Power Off

Artchi schrieb:

Lass dich doch von Volkard nicht so provozieren. Er ist hier der Gerhard Schröder...

Der hat unserem Land auch nicht grade gutgetan, oder?

Kevinus

Was wer sagt was gegen Schröder, denkste Trottel wie Stoiber oder Merkel oder sonst jemand würden in diesem verkorksten Land etwas ändern??? Das land kannste eigentlich vergessen... aber zum Thema c++ forever.

Power Off

Kevinus schrieb:

Was wer sagt was gegen Schröder, denkste Trottel wie Stoiber oder Merkel oder sonst jemand würden in diesem verkorksten Land etwas ändern??? Das land kannste eigentlich vergessen... aber zum Thema c++ forever.

Tja ... der Fisch stinkt halt vom Kopf her.

Walli

O'Rakl schrieb:

Putzig: Da muß ich euch noch sagen, wie C++ hieß, bevor es "C++" hieß.

Um es mit den Worten des wohl größten Denkers unserer Zeit zu sagen: Ja nee, is klar!

Also beenden wir diese Diskussion mit dem Resumé:

Soll jeder mit seiner bevorzugten Programmiersprache glücklich werden.

ChockoCookie

Klar, das ist eh die allgemein gültige Maxime. Nur glauben manche Leute ihre Lieblingssprache sei der Weisheit letzter Schluss und versuchen andere davon zu überzeugen alles andere aufzugeben.

Optimizer schrieb:

Oder nen XmlSerializer mit Konstruktor XmlSerializer(System.Type) und Serialize(Stream, Object) anstatt nen XmlSerializer<Type>.

Seh ich nicht so. Das man bie dieser Klasse ein System.Type angeben muss, ist schon gut überlegt. Hier ein Generic zu verwenden, würde die Möglichkeiten der Serialisierung unnötig beschränken. Stell dir vor, du kennst nur den Namen der Klasse als String oder CLSID oder zur Laufzeit ist noch nicht genau bekannt, was für ein Typ überhaupt serialisiert werden soll ...

ewr schrieb:

Optimizer schrieb:

Oder nen XmlSerializer mit Konstruktor XmlSerializer(System.Type) und Serialize(Stream, Object) anstatt nen XmlSerializer<Type>.

Seh ich nicht so. Das man bie dieser Klasse ein System.Type angeben muss, ist schon gut überlegt. Hier ein Generic zu verwenden, würde die Möglichkeiten der Serialisierung unnötig beschränken. Stell dir vor, du kennst nur den Namen der Klasse als String oder CLSID oder zur Laufzeit ist noch nicht genau bekannt, was für ein Typ überhaupt serialisiert werden soll ...

Was soll denn der Mist jetzt ?!?

Wir wollen doch bitte schön unsachlich bleiben. Schreib doch lieber,
was du schon tolles programmiert hast, oder beleidige andere User!
Was anders will ich in einem "vergesst C++" - Thread in einem C++-Forum
nicht sehen!

Jockel

ewr schrieb:

Optimizer schrieb:

Oder nen XmlSerializer mit Konstruktor XmlSerializer(System.Type) und Serialize(Stream, Object) anstatt nen XmlSerializer<Type>.

Seh ich nicht so. Das man bie dieser Klasse ein System.Type angeben muss, ist schon gut überlegt. Hier ein Generic zu verwenden, würde die Möglichkeiten der Serialisierung unnötig beschränken. Stell dir vor, du kennst nur den Namen der Klasse als String oder CLSID oder zur Laufzeit ist noch nicht genau bekannt, was für ein Typ überhaupt serialisiert werden soll ...

Guter Einwand. Muss mal rausfinden, ob man generische Typen mit einem System.Type instanzieren kann. Wenn nicht, wäre es tatsächlich ne Einschränkung. Wenn doch, ist es IMHO besser, einen generischen Serializer zu haben, weil der Cast beim Deserialisieren affig ist.

kartoffelsack

Das könnte man auch automatisieren, in dem man ein kleines Tool baut, das einem den entsprechenden Code baut. Einfach angeben, welche Klassen mit boost::serialize implementiert werden sollen -> fertig.

soweit ich mich entsinne hat gSoap sowas dabei, das man auch unabhängig von den Soap-Sachen zur Serialisierung verwenden kann. Ist aber halt ein eigenes Tool, das man drüberlaufen lassen muss. Das ist während der Entwicklung, wo sich dauernd noch kleinigkeiten ändern nervig. Bei der Wartung, wenn schon lang nix mehr mit der Projekt gemacht wurde und es wieder ausgegraben wird und am besten, der ders gemacht hat, nicht mehr verfügbar ist, eine ziehmliche Hürde.

dann musst du halt deinen modularen aufbau überdenken
wenn du an der implementierung eines moduls was änderst ohne das interface zu ändern musst du ja nur das eine modul neu übersetzen

Ach komm. Wie oft muss man dem Compiler sagen 'Projekt bereinigen und alles neu erzeugen' weil er rumspinnt. Membervariablen und private Funktionen gehören auch zur Implementierung. Sind aber in C++ teil des Interfaces (nur der Zugriff ist verboten). Und wenn ich an einem Projekt entwickle, dann ändert sich hier und da was. Mir wird die Funktion zu lang. Denk ich mir, da könnt ich ne eigene draus machen, schnell ne neue private Funktion -> schwups n haufen Zeug muss neu kompiliert werden. Die einzige Möglichkeit ist pimpl. Aber das kannste auch nur da machen, wo ein wirklich eindeutiger Schnitt zu einem anderen Systemteil ist, weil sonst wirste völlig blöde.

Man muss wirklich aufpassen wie ein wilder. Und der Erfolg ist lediglich, dass ich nicht bedenkenlos einen Cafe trinken gehen kann sondern ichs mir jedesmal überlegen muss, ob sichs rentieren würde.

volkard

kartoffelsack schrieb:

Die einzige Möglichkeit ist pimpl.

naja, und rimpl (reference to impl).

Aber das kannste auch nur da machen, wo ein wirklich eindeutiger Schnitt zu einem anderen Systemteil ist, weil sonst wirste völlig blöde.

ich hab keine probleme mit langen compilezeiten. aber ich hatte mal und hab mit proxies für members gespielt. der compiler braucht nur die größe und das alignment des members, um das klassenlayout zu berechnen. das geb ich ihm.

#ifndef FOOFWD_H
#define FOOFWD_H

#include "BarFwd.h"

#ifdef RELEASE//steht natürlich in BarFwd.h, hier nur mal als demo
#include "Bar.h"
#endif

class Foo{
   Attribute<Bar> bar;
   ...

und Attribute kriegt natürlich nen op-> und op*, fühlt sich fast wie ein zeiger an, nur daß es die daten selber besitzt.

und dann hat man freiheit, im debug-mode pimpl zu machen und im release-mode echtes layering. die details, was ich da gebaut hab, weiß ich gar nicht mehr. aber mein compilezeitproblem wurde voll überkompensiert.

ich will jetzt nicht in abrefe stellen, daß man sich sowas zur recht allgemeinen verwendung auch mal bauen könnte, wenn es das hauptproblem von c++ wäre. dauert aber 5 tage, wenn man es wirklich hübsch machen will.

groovemaster

O'Rakl schrieb:

Hört, hört. -- ja, und ? was willst du uns damit sagen ?

Genau das, was dort steht. Aber nicht uns, sondern nur dir.

O'Rakl schrieb:

Nein. C++ und C sind nicht voneinander unabhängig

Doch, das sind sie. Schmeiss den C Standard weg, jeglichen C Code und alle C Compiler. C++ wird trotzdem weiter existieren, auch wenn die C Kompatibilitätsgeschichten nicht mehr nutzbar wären. Immerhin leben wir im Jahre 2005 und nicht mehr 1979. Seit "C with Classes" hat sich einiges geändert. Das ist aber nicht der springende Punkt, da C++ eben lange nicht standardisiert und mehr oder weniger eine freie Entwicklung war. Der springende Punkt ist einfach, dass C++ seit Beginn Klassen und somit ein OO Konzept hatte. Genau deshalb entwickelte Stroustrup ja C++. Es ging nicht darum, C eine Klassenerweiterung zu spendieren, sondern eine eigene OO Sprache zu entwickeln. Welche Sprache man als Basis nehmen konnte, war erst die nächste Frage.

O'Rakl schrieb:

C++ hieß ursprünglich "C with classes", das kann dir gefallen oder nicht, es ist nun mal so.

Genau das drückt doch mehr als deutlich aus, dass OO die Grundlage von C++ war und kein "Add-on".

Power Off schrieb:

Tja ... der Fisch stinkt halt vom Kopf her.

Wobei es nicht immer der Kopf sein muss, wenn's nach Fisch stinkt.

O'Rakl schrieb:

Also beenden wir diese Diskussion mit dem Resumé:

Soll jeder mit seiner bevorzugten Programmiersprache glücklich werden.

Ist das jetzt ein Fake? Kann man bei Unregs immer so schlecht beurteilen.

edit:
Kein Grund ausfallend zu werden, Bubi. Immerhin war ja nicht alles falsch.

Power Off

(hat sich erledigt)

Ich bin viel besser als C++ und Python zusammen. Bäh! :p

das amüsante ist ja (habe aber nur ab Seite 15 gelesen):
fast alle versuche, gegen den Standpunkt unseres Orakelchens anzup*ssen,
mündeten in unfreiwillige Belege dafür, daß er im grunde recht hat:
STL+boost (vs. Eleganz), Fehlermeldungen mit 10-zeilen-langen Typbezeichnungen
(vs. Einfachheit), Herkunft von C (vs. originäre OOP-Sprache) ...

... schrieb:

STL+boost (vs. Eleganz)

Ich spreche zwar kaum C++, aber mich würde trotzdem interessieren was in diesem Fall gegen Eleganz spricht.