Nochmal zu meinem Problem

ChrisM

So, ist hochgeladen.
Hier könnt ihr euch ein minimales Testprojekt runterladen, in dem der Fehler auftritt:
http://www.chrismandery.de/exptest.rar

Falls ihr rar net öffnen könnt, sagt es grad nochmal und ich mach zip, dann wirds allerdings etwas größer (um 300kb).

ChrisM

Knuddlbaer

Oh man, da sseh ich jetzt erst, das Du CString von std::string erben lässt. Dabei stehts am Anfang

Sorry, blind muss man sein. (CString gibts im VC halt auch, deswegen dacht ich Du verwendest diesen auch, mit dem klappte das ja auch super ;o).

std::string hat keine virtuellen Methoden. Daher ist dieser nicht fürs Vererben geeignet. (z.B. Destruktor, so genau weiß ich die Argumente nicht. Aber in den newsgroups findest Du da was: http://groups.google.de/groups?hl=de&lr=&ie=ISO-8859-1&q=std%3A%3Astring+erben

Das Hauptproplem:

CString gibt es bereits! Der Compiler verwendet mal dies mal das.
Benenne mal CString in eine Klasse um die es noch nicht gibt (C<Klasse> ist bei VC üblich für interna) und Du siehst: Es geht.

Setz nen Breakpoint in den Konstruktor, Du wirst sehen: Da gibts kein Aufruf für. Es wird also ein ganz anderes CString zerstört wie Du in der Routine annimmst.

Gruß
Michael

P.s.: Noch mal sorry das ich es zu spät gesehen hab wegen vererbung vom std::string

ChrisM

Ja, ich weiß, dass es CString schon in den MFC gibt, aber wie kann der Compiler das MFC-CString verwenden, wenn ich ausdrücklich dem Linker sage, dass er die MFC nicht linken soll?

Und das mit den nicht-virtuellen Funktionen dürfte ja nichts machen, weil ich ja explizit CString übergebe, d.h. es wird auch der CString-Destruktor aufgerufen (bzw. sollte er).

ChrisM

Shade Of Mine

fliegt dir die exception auch bei std::string um die ohgren, wenn nein, dann nenne CString mal um (wie du siehst hast du damit bereits die ersten Leute verwirrt).

Knuddlbaer

Es passiert folgendes (theorie

Der Compiler sieht den CString aus der ATL oder MFC (weiß nich so genau).
Er schaut sich den Bauplan an und verwendet diesen auch fleissig.

Der Linker dagegen sucht nur nach irgendetwas das CString heisst. Der Typ ist uninteresannt. Da der Linker die MFC nicht bekommt wird er im String.obj fündig und verwendet dieses.

Du übergibst dort ein völlig anderes Objekt als Du vermuten würdest.

Benenn mal den String um und Du wirst ggf. ncoh Probleme mit den Namesapces finden. (String.cpp - der kram muß noch in den NameSpace rein).

Also: Mal umbenennen ;o) Und schau Dir mal den Link aus den NewsGroups an, von string zu erben war keine so gute Idee, ich kenn die gründe aber nicht mehr. Schaus Dir an damit Du weisst was es an Problemen geben könnte.

mfc ist doch garnicht eingebunden

ChrisM

Benenn mal den String um und Du wirst ggf. ncoh Probleme mit den Namesapces finden. (String.cpp - der kram muß noch in den NameSpace rein).

Ne, da hab ich oben using namespace AGE; hingeschrieben.

Jetzt les ich den Newsgroupartikel und dann probier ich das mal umzubenennen. Wenns dann net geht, schreib ich mir einfach selbst eine Stringklasse, ich brauch ja kein Unicode und nix, einfach einen ASCII-String und sowas ist schnell gecodet.

ChrisM

ChrisM

So, hab alle CString durch CTestString ersetzt, aber das Problem ist immer noch da. Es hat also nix mit den MFC zu tun (die sowieso nicht eingebunden sind und auch nicht im AGE-Namespace ).

Danke für eure Hilfe und hoffentlich kommen wir noch auf den Grund!

ChrisM

Knuddlbaer

using namespace AGE;

Hiermit bekommt der Compiler doch nur gesagt das er im Namensraum AGE schauen soll wenn er etwas sucht.

Damit sagt Du dem Compiler nicht das die Implementierung der Methoden im Namensraum AGE liegen.

Probier mal bitte folgendes:

Breakpoint im Konstruktor setzen und schaun ob er dort anhält.

ChrisM

Breakpoint im Konstruktor setzen und schaun ob er dort anhält.

Ja, sowohl im Konstruktor und im Destruktor wird angehalten.

Allerdings: Seit ich einen Destruktor eingeführt habe, habe ich die Debug Assertion nicht mehr!!
Aber ich glaub jetzt ein Memory Leak zu haben, weil mein Destruktor ja leer ist und im Unterschied zum automatisch generierten Destruktor nicht den Destruktor der Basisklasse (std::string) aufruft!

ChrisM

Knuddlbaer

Hi!

Also, ich bekomm das ganze nicht übersetzt (VC 7).
Ich hab die DLL neu erstellt, aber er findet den Einsprungspunkt des Konstruktors nicht. Hab auch nix mit DLLs bisher am huht.

Hier mal die Header und die Cpp für den String, versuchs mal so:

#ifndef AGE_STRING_INCLUDED
#define AGE_STRING_INCLUDED

#include <string>

#ifdef TESTDLL_EXPORTS
#define AGEAPI __declspec(dllexport)
#else
#define AGEAPI __declspec(dllimport)
#endif

namespace AGE
{

class MyString 
{
public:
     AGEAPI MyString(const std::string &strString);
     AGEAPI MyString(const char *pchString);
     AGEAPI MyString(int nNumber);

private:
    static AGEAPI MyString intToString(int nNumber);
    std::string data;
};

}
#endif

#include <stdio.h>
#include "String.hpp"

namespace AGE
{

MyString::MyString(const std::string &strString) : data(strString)
{
}

MyString::MyString(const char *pchString) : data(pchString)
{
}

MyString::MyString(int nNumber) //: data(intToString(nNumber))
{
}

MyString intToString(int nNumber)
{
    // sprintf() is dark C-Code but it's fast!
    char chBuffer[16];
    sprintf(chBuffer, "%i", nNumber);
    return MyString(chBuffer);
}

}

[ Dieser Beitrag wurde am 22.04.2003 um 19:00 Uhr von Knuddlbaer editiert. ]

Die Probleme mit dem CString aus der MFC hatte ich wegen dem Konvertieren von VC6 auf VC7 da war die MFC dann mit drinne.

Dennoch wäre die Bitte das nicht in Deinem Projekt so zu machen, sonst sucht sich der der mal Dein Projekt warten soll nen Wolf wenn was nicht klappt ;o)

[ Dieser Beitrag wurde am 22.04.2003 um 19:03 Uhr von Knuddlbaer editiert. ]

ChrisM

Wie gesagt, das Problem ist jetzt ja weg, seit ich den Destruktor in CString (mein CString, nicht das von den MFC ) implementiert habe, aber dafür wird jetzt halt nicht mehr der Destruktor der Basisklasse aufgerufen.
Aber warum gehts so?

Ich glaub, ich stells aber trotzdem auf eigene Stringklasse um

ChrisM