Pointer freigeben:

Chew-Z

nee, c++ freaks nehmen new/delete bzw. delete[]. malloc und free ist c-style, funzt aber auch unter c++

Gründe für malloc()/free() mit C++:
KEINE
Gründe gegen malloc()/free() mit C++:
allerdings (teilweise) erhebliche

CarstenJ

Kann es sein, dass diese Thread ziemlich in die Hose ging? Die einzig brauchbare Antwort ist Sovoks, den Rest könnte man getrost im Datennirvana versenken...

net 0

Chew-Z schrieb:

Gründe für malloc()/free() mit C++:
KEINE

doch, man braucht nicht zwischen delete und delete[] zu unterscheiden

CarstenJ schrieb:

Kann es sein, dass diese Thread ziemlich in die Hose ging?

wieso? tggc hat sich noch nicht gemeldet

audacia

CarstenJ schrieb:

Kann es sein, dass diese Thread ziemlich in die Hose ging? Die einzig brauchbare Antwort ist Sovoks, den Rest könnte man getrost im Datennirvana versenken...

Nice. An diesem Forum hat mir gleich der nette Umgangston gefallen. Ich finds auch toll, daß Neulinge oft gleich sarkastisch fertiggemacht werden...

shareholder

Danke Euch hierhin ersteinmal,

Habe ich das jetzt richtig verstanden...
Da ich keinen Speicher reserviert habe, muss ich den Pointer auch nicht zwingend wieder freigeben?

(@audacia, nein: mit MSVC++ .NET)

CarstenJ

Naja, eigentlich ist das hier schon ok, aber ich find es manchmal unangebracht, über ein recht einfaches Thema 2-3 Seiten zu "verschwenden". Der OP wird wahrscheinlich verwirrter sein als vorher, da immer nur ein paar Informationsfetzen hingeworfen werden, die aber auch nicht so richtig erläutert werden.

EDIT:

Habe ich das jetzt richtig verstanden...
Da ich keinen Speicher reserviert habe, muss ich den Pointer auch nicht zwingend wieder freigeben?

Ja, wenn du kein NEW benutzt (zum allokieren) musst du auch kein DELETE (zum freigeben) benutzen.

shareholder

Danke CarstenJ & Andere

Chew-Z

Aufgrund deines Beispiels nehme ich an das IRGENDJEMAND den Speicher
zu dem Pointer allokiert den du geliefert bekommen hast.
In diesem Sinne könnte der Aufruf von Release() vom Ersteller der Funktion
so geplant, dokumentiert(hoffentlich) und daher zwwingend erforderlich sein.

CarstenJ

Hallo,

nebenbei bemerkt ist release schon Standard, hat aber was mit dem std::auto_ptr zu tun:
http://www.gotw.ca/publications/using_auto_ptr_effectively.htm

Ist auch nicht verkehrt, das zu kennen.

shareholder

nö

HRESULT CXmlParserDlg::CheckLoad(IXMLDOMDocument *pDoc)
{
	HRESULT hResult = E_FAIL;
	long lErrorCode = E_FAIL;		
	IXMLDOMParseError *pXMLError = NULL;

	if (SUCCEEDED(pDoc->get_parseError(&pXMLError)) 
		 && SUCCEEDED(pXMLError->get_errorCode(&lErrorCode))
		 && ( lErrorCode != 0 ) )
		hResult = ReportError(pXMLError);

	//
	// Clean-up pointers used.
	//
	if ( pXMLError )
	{
		pXMLError->Release();
		pXMLError = NULL;
	}

	//
	// Pass back the return code.
	//
	return lErrorCode;
}

Chew-Z

Also doch, COM-Programmierung

Release() dekrementiert den Referenzzähler eines COM-Objekts.
Es sollte daher in keinem Fall vergessen werden. Sonst gibts Leichen,
ähnlich wie bei fehlendem delete() oder free().

Ringding

Ui, viel Spaß. COM mit C++ ist nicht gerade "for the faint of heart". Also wenn du keine Ahnung von Speicherverwaltung hast, wirst du damit vermutlich noch kräftig auf die Nase fallen, nur so als Vorwarnung ;).

EDIT: Bei BCB sind übrigens die xxxPtr-Klassen sehr nützlich (also z.B. IXMLDOMParseErrorPtr) - zumindest wären sie es, wenn der Compiler beim Auftreten von Exceptions den Destructor aufrufen würde, was er eigentlich sollte. Ab einer gewissen Funktionskomplexität vergisst er aber leider zunehmend darauf... Macht die Sache auch nicht gerade lustiger :(.

shareholder

Was kann ich mir unter COM-Objekt vorstellen?

Oder wieso muss ich dekrementieren? :o

Sorry, bin planlos.

finix

net schrieb:

Chew-Z schrieb:

Gründe für malloc()/free() mit C++:
KEINE

doch, man braucht nicht zwischen delete und delete[] zu unterscheiden

ja... dafür nimmt man doch gern in Kauf sich selber um Objekt Konstruktion & Destruktion zu kümmern, was?

Chew-Z

COM ist die Infrastruktur hinter objektorientierter, verteilter Programmierung
nach Vorstellung von Microsoft. Das was jetzt durch .NET abgelöst wird, aber
auch zurzeit immer noch millionenfach im Umlauf ist.

Was du konkret verwendest ist der XML-Parser von Microsoft.

Der Umgang mit COM-Objekten ist wirklich nicht ganz trivial. Vor allen Dingen
funktioniert das mit den Objekten doch deutlich anders als in "Raw" C++.

Ein eigenes Forum zu dem Thema findest du unter:
http://www.codeproject.com/script/comments/forums.asp?forumid=1648

CarstenJ

shareholder schrieb:

Was kann ich mir unter COM-Objekt vorstellen?

Oder wieso muss ich dekrementieren? :o

Sorry, bin planlos.

Du programmierst doch gerade irgendwas, oder? Du musst doch wissen, was du da gerade machst, was es werden soll etc. Ich würde dir auch erstmal empfehlen, Standard C++ zu lernen, bevor du dich an solche unübersichtlichen Gebilde wagst.

net 0

shareholder schrieb:

Was kann ich mir unter COM-Objekt vorstellen?

guckst du: http://www.sei.cmu.edu/str/descriptions/com.html

finix schrieb:

net schrieb:

Chew-Z schrieb:

Gründe für malloc()/free() mit C++:
KEINE

doch, man braucht nicht zwischen delete und delete[] zu unterscheiden

ja... dafür nimmt man doch gern in Kauf sich selber um Objekt Konstruktion & Destruktion zu kümmern, was?

ja, das ist natürlich ein klitzekleiner nachteil

audacia

shareholder schrieb:

(@audacia, nein: mit MSVC++ .NET)

???

Falls sich das auf folgendes (aus einem anderen Thread) bezieht:

spjoe schrieb:

argv[1] gibt nur nen pointer auf einen cstring zurück. D.h diesr kann nie 'i' sein. Wenn dann "i".
Daher mein lösungs vorschlag.
C/C++ Code:
if (argv[1][0] == 'i')
//....
C/C++ Code:
if (argv[1][0] == 'i')
//....
C/C++ Code:
if (argv[1][0] == 'i')
//....

mfg

Naja, das Dereferenzieren von argv[1] läuft im Prinzip auf das Gleiche 'raus...

Doch, denn argv ist vom Typ char**, die Indizierung mit [1] gibt char* zurück und das ergibt - dereferenziert - char!

Wenn das mit VC++ nicht klappt, hast du die Parameter beim Start anzugeben vergessen (das Programm prüft, wie man sieht, nicht die Anzahl der Parameter)!
Moritz

Chew-Z

Hi audacia,

auch bei Unklarheiten wäre es sicher wünschenswert die Antworten dem passenden
Thread zuzuordnen.