Problem mit Klasse



  • ClassTok schrieb:

    Hallo, hier bekomme ich folgende Fehlermeldung was mache ich hier falsch?

    [BCC32 Fehler] File2.cpp(39): E2125 Compiler konnte Standardkonstruktor nicht für die Klasse 'stream' generieren

    Zwei Dinge:

    1. Es existiert kein Standardkonstruktor für die Klasse Token . Entweder du fügst ihn zur Klasse hinzu, oder du fügst der Klasse stream einen Konstruktor hinzu, der in seiner Initialisierungsliste einen geeigneten Parameter für den Token Konstruktor zur Verfügung stellt, z.B.:
    class stream
    {
       Token Token_;
    public:
       stream() : Token_( 0 ) // oder was auch immer sinnvoll ist
       {
       }
    };
    

    2. Du benutzt den Borland/Codegear/Embarcadero C++ Builder. Das wird dir irgendwann mal sehr leid tun...



  • Jockelx schrieb:

    Sobald du einen eigenen Konstruktor anbietest, wird der default-Konstruktor nicht mehr automatisch erzeugt.
    Wäre ja auch irgendwie doof.

    Du musst den selber schreiben.

    Ich glaube, das meint er nicht.

    @ClassTok:
    Da Token keinen Defaultkonstruktor hat, weiß der Compiler bei stream nicht, wie er das Token in einem automatisch generierten Defaultkonstruktor erstellen soll. Deswegen musst du es ihm selbst sagen.



  • Ty @ all für die Hilfe jetzt funktioniertes 🙂

    2. Du benutzt den Borland/Codegear/Embarcadero C++ Builder. Das wird dir irgendwann mal sehr leid tun...

    Was ist so schlimm an dem C++ Builder?



  • Die Versionen, die ich bisher kennengelernt habe, waren nicht besonders stabil. Das kann´s schon mal passieren, dass der Debugger aus irgendeinem Aufruf nicht zurückkommt oder die IDE pausenlos Meldungsfenster mit Fehlermeldungen anzeigt.
    Das ging sogar so weit, dass ich mir auf´m Desktop eine Batchdatei gelegt habe, die den Prozess per taskkill beendet, weil die IDE selbst nicht mehr bedienbar war.
    So ganz standardkonform ist das Ding auch nicht, manche Konstruktionen (besonders was Templates und Vererbung angeht stolpert der Compiler hin und wieder).
    boost unterstützt den BCB offiziell nicht mehr, da ist dann mit boost 1.34_1 Schluss.
    Das RAD Studio unterstützt sowohl C++ als auch Delphi, und die meisten Bibliotheken sind in Delphi programmiert. Das führt oft zu unterschiedlichem Verhalten aufgrund der Unterschiede von Delphi und C++ (z.B. unterstützt Delphi keine Mehrfachvererbung und benutzt bei strings eine 1-basierte Zählweise). Da muss man manchmal schon ziemlich Handstände machen, wenn man Mehrfachvererbung braucht.
    Ausserdem wird das OMF Linkerformat benutzt (Microsoft: COFF), damit sind ein Großteil der 3rd Party Bibliotheken nicht benutzbar. Es existiert zwar ein COFF2OMF Tool, aber das funktioniert auch nicht immer. Und und und...

    Das gilt für Codegear RAD Studio 2007, ein jüngere Version gucke ich mir gerade an. Der jetzige Besitzer der Compilersparte nimmt seine Aufgabe wohl sehr ernst, jedenfalls steckt man einiges an Aufwand in die RAD Studio XE/XE2 Entwicklung/Pflege.

    Edit:
    Guck dir doch mal den Text der Fehlermeldung an. Die Beschreibung passt nicht auf das tatsächliche Problem, sowas ist typisch für Borland/Codegear.



  • Ja das Problem mit dem Debugger hatte ich auch schon.

    Ich programmier nur so aus Hobby, was wird den so in Firmen verwendet ?

    Bei Windows denke ich mal Visual Studios oder ?

    Bei RAD Studios da find ich es immer ganz gut das man da schnell und einfach ein GUI Programm entwickeln kann.

    Gibt es sonst noch andere Programm die einen Builder sowie RAD Studios verwenden ?
    Ich kenne da sonst nur noch den Builder aus dem QT SDK.



  • Kein Mensch baut heute noch manuell statische Formulare auf, dazu bietet jede IDE einen entsprechenden Designer. Hängt natürlich vom Framework ab, ich kenne nur noch das MS Visual Studio, was in dieser Hinsicht aber etwas problematisch ist. Wenn man nur C++ benutzen will bleibt einem nur der Dinosaurier MFC, das moderne .NET Framework setzt aber voraus, dass man C++/CLI (eine MS spezifische Erweiterung) benutzt. Das ist natürlich zu nix anderem kompatibel, weil´s eigene Schlüsselwörter und Operatoren benutzt.

    Wenn´s für ein Projekt keine schwerwiegenden Gründe gegen C# gäbe würde ich die heute in C# umsetzen.



  • Das gute an RAD Studios finde ich immer das die GUI Anwendungen auf jedem PC laufen.

    Bei Microsoft gibt es ja immer das Netframework und wenn ein Benutzer das nicht installiert hat dann funktioniert die Anwendung nicht.

    Bei Assembler (MASM) da gibt es ein Programm da kann man sich einen fertigen GUI Code generieren lassen mit Buttons und Eingabefeldern. Meintest du soetwas mit Designer ?



  • ClassTok schrieb:

    Das gute an RAD Studios finde ich immer das die GUI Anwendungen auf jedem PC laufen.

    Das tun sie aber auch nur, wenn man keine externen Abhängigkeiten hat. Out-of-the-Box laufen Kompilate vom RAD Studio auch nur dort, wo das RAD Studio installiert ist. Entweder liefert man die entsprechenden DLLs mit oder linkt statisch gegen die VCL Bibliotheken.

    ClassTok schrieb:

    Bei Microsoft gibt es ja immer das Netframework und wenn ein Benutzer das nicht installiert hat dann funktioniert die Anwendung nicht.

    Jo, da muss man sich Gedanken machen, wo die Software später laufen soll. Wenn man Legacy Installationen hat, wo die Software auch noch auf einen 386 laufen soll scheidet .NET wohl aus. Bei Neuentwicklungen für Windows darf man aber wohl davon ausgehen, dass ein .NET Framework auf dem Zielsystem vorhanden ist.

    ClassTok schrieb:

    Bei Assembler (MASM) da gibt es ein Programm da kann man sich einen fertigen GUI Code generieren lassen mit Buttons und Eingabefeldern. Meintest du soetwas mit Designer ?

    Ne, das meine ich nicht. Ich meine so´n Ding, wo man ein neues Formular erstellt und dann aus eine Toolpalette GUI Elemente auf das Formular ziehen und deren Eigenschaften bearbeiten kann. Der Designer erzeugt dann automatisch den Quelltext/Resource aus der grafischen Vorlage und bindet ihn in´s Projekt ein.



  • DocShoe schrieb:

    Hängt natürlich vom Framework ab, ich kenne nur noch das MS Visual Studio, was in dieser Hinsicht aber etwas problematisch ist. Wenn man nur C++ benutzen will bleibt einem nur der Dinosaurier MFC, das moderne .NET Framework setzt aber voraus, dass man C++/CLI (eine MS spezifische Erweiterung) benutzt. Das ist natürlich zu nix anderem kompatibel, weil´s eigene Schlüsselwörter und Operatoren benutzt.

    Wenn´s für ein Projekt keine schwerwiegenden Gründe gegen C# gäbe würde ich die heute in C# umsetzen.

    Es gibt noch mehr Frameworks als nur VCL und MFC. Wir sind vollständig auf Qt umgestiegen und auch recht glücklich damit.



  • Ja klar gibt´s da jede Menge, ich meinte allerdings nur die, die das MSVS von Hause aus mitbringt. Mit anderen kenne ich mich auch nicht aus, da wollte ich keine Vermutungen posten.


Anmelden zum Antworten