vergesst C++ ...

groovemaster schrieb:

aber C++ ist *nicht* C.

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

Das sind zwei unabhängige Sprachen.

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.

Übrigens: Verbalinjurien sind kein Ersatz für fehlende Argumente. Nur mal so
nebenbei

GPC

O'Rakl schrieb:

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

Du trennst sie doch nicht sauber! Du meinst du redest von C++, aber in Wirklichkeit redest du von C!

O'Rakl schrieb:

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

Das war doch nur der Arbeitstitel.

O'Rakl schrieb:

Übrigens: Verbalinjurien sind kein Ersatz für fehlende Argumente. Nur mal so nebenbei

Wer im Glashaus sitzt...

volkard

O'Rakl schrieb:

Das sind zwei unabhängige Sprachen.

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.

sie sind verschiedene sprachen. außer natürlich du zählst die ähnlichkeiten in der syntax. dann muß man aber auch klarerweise sagen, daß java gleich c ist. willste das?
schau dir gute (also af keinen fall von Power Off) c++-programme und gute c-programme an und du wirst sehen, daß sie ganz unterschiedlich sind.

Walli

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.

Man hat C mit Klassen in C++ umgenannt weil der Name der Sprache eben nicht mehr gerecht wurde, da C++ in der Zwischenzeit eben weit über ein C mit Klassen hinaus gewachsen war. Das kann dir gefallen oder nicht, es ist nun mal so.

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.

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.