Verrücktes malloc Problem

HE

hm naja der streit um malloc oder nicht, das ist halt ansichstsache! ich bin auch für malloc, aber egal, da könnte man jetzt auch gleich über cout und printf streiten...

aber zum problem, malloc kann den speicher reservieren, trotzdem die fehlermeldung...

HE schrieb:

hm naja der streit um malloc oder nicht, das ist halt ansichstsache!

nee, ist es nicht. malloc in c++ ist einfach falsch. und gefährlich.

HE

ok ok wenn wir schon dabei sind, wie wäre es mal mit argumenten?!?!?!?!?!

The-Kenny

Soweit ich weiß, reserviert dir malloc einfach das, was du angefordert hast und gibt einen Pointer zurück - Ohne jegliche Konstruktoraufrufe, oder wenigstens den Speicherbereich sinnvoll zu füllen.

Ist wahrscheinlich nur halbwissen, aber der fehlende Konstruktoraufruf sollte schon das K.O. für malloc in C++ sein.

OhneName

malloc reserviert zwar Speicher, ruft im Gegensatz zu new aber keine Konstruktoren auf. free gibt den Speicher wieder frei, ruft im Gegensatz zu delete aber keine Destruktoren auf.
Bei den eingebauten Datentypen char, int, double, etc. spielt das vielleicht keine Rolle, aber jedem Anfänger sollte klar sein, dass sich malloc nicht mit Objekten verträgt.

HE

na klar da habt ihr recht, wenn man mit objekten arbeitet ist malloc sicher nicht das nullplusultra, allerdings muss ich nur speicher für ein struct reservieren und dazu reicht malloc allemal.

voidpointer

was sagt die fehlermeldung denn genau? kannst du es hier hin schreiben oder vllt nen screenshot? möglicherweise nen speicherzugriffsfehler, der schon weiter vorne im programm verursacht wurde?

wichtig ist auch, zu wissen, wo genau der fehler auftrat... (debugger?)

neu->next=0;

solltest du vllt besser umschreiben als

neu->next=NULL;

Das macht deinen Code C-Portabel und lesbarer

*D*Evil

Ehm du weißt aber, das eine struct nicht wirklich was anderes ist wie eine class? Hmm ... gut ... und warum sollte man nicht die Funktionen des C++-Standards nutzen, sondern die des C-Standards, um ein Programm in C++ zu schreiben? ?

asc

voidpointer schrieb:

solltest du vllt besser umschreiben als
neu->next=NULL;
Das macht deinen Code C-Portabel und lesbarer

Und verleitet zu fehlerhaften Annahmen in einen Fall wenn man mit überladenen Methoden arbeitet, wo eine ein int, und eine andere einen Zeiger erwartet... NULL ist 0 (in Zukunft, sprich C++0x umgeht man dies hoffentlich mittels null_ptr). Wenn man C-Portabel schreiben will sollte man imho ganz auf C++ verzichten. Ansonsten schaut man vielleicht bei Schnittstellen die C-binärkompatibel sind darauf, aber ansonsten ist das meines erachtens falsch.

Wenn er C programmieren will soll er in das C-Unterforum gehen. C++ zumindest ist nicht C und man braucht auch eine rein C-Portable Syntax nur in seltenen Fällen.

cu André

*D*Evil

Hmm mal kurz nen bissel kürzen hier:

void cound_words(std::string const& word) 
{
	if (list_words == NULL) { list_words = new word_t(word); return; }

	word_t* last(list_words);
	for (word_t* cur(list_words); cur != NULL; cur = cur->next) 
	{
		if ((*cur).word == word) 
		{
			++(*cur).count;
			return;
		}
		last = cur;
	}

	last->next = new word_t(word);
}

... so bekommst du das doch schön kurz & knackig

Voraussetzung dafür ist allerdings ne Struktur ordentlich einzusetzen:

struct word_t
{
	std::string word;
	word_t*		next;
	std::size_t	count;
	word_t(std::string const& word) : word(word), next(NULL), count(1) {}
};

Don06

null_ptr wird echt praktisch. Ich hab mir mal ein Ersatz-Template gebastelt das ungefähr so aussah:

namespace dons
{
	template <class T>
	T* null_ptr(T*)
	{
		return 0;
	}
}

Damit konnte man dann sowas machen:

using dons::null_ptr;

int*  p1 = null_ptr(p1);
char* p2 = null_ptr(p2);

int i1 = null_ptr(i1); // Fehler
int i2 = null_ptr(p1); // Fehler

Der Parameter ist ziemlich unschön, aber war ja eh nur mal so zum Spass.

Gruß
Don06

HE

ja eigentlich besteht das programm hauptsächlich aus code der mit einem c kompiler kompiliert werden könnte, allerdings bietet c++ einige Möglichkeiten, welche in c nur sehr schwer zu verwirklichen sind. deshalb schien mir c++ die bessere wahl, da es ja nicht verboten ist in c++ objektlos zu programmieren. ich könnte mir schon vorstellen in einem späteren moment das ganze auf c umzuschreiben, aber egal...!

Wenn er C programmieren will soll er in das C-Unterforum gehen. C++ zumindest ist nicht C und man braucht auch eine rein C-Portable Syntax nur in seltenen Fällen.

Jepp ich tat mich bei der wahl nicht leicht, ich nahm allerdings dann dieses unterforum, weil ich erstens einen c++ compiler verwende und zweitens im c forum wahrscheinlich nur wegen meiner strings verurteilt würde.

neu->next=NULL

naja wegen NULL oder 0 lässt sich streiten. NULL bedeutet ja nichts anders als die Speicheradresse 0 oder 0x00, aber ihr habt schon recht, besser verständlich wäre NULL. sorry

Problemsignatur:
AppName: program.exe
AppVer: 0.0.0.0
ModName: program.exe
ModVer: 0.0.0.0
Offset: 00009669

Problemberichtinhalt:
Code: 0xc0000005
Flags: 0x00000000
Record 0x0000000000000000
Address:0x0000000000409669

Kein Ahnung was euch da noch helfen könnte!

Danke für die bisherigen Antworten

HE

Oh großen Dank an (D)Evil für deine Hilfe!

Ich glaube ich werde wohl meine C-passion fallen lassen müssen und follends der Objektivität von c++ mich zuwenden. Ich denke das löst mein Problem.

Danke vielmals du hast mir sehr geholfen!
Danke an alle!

pumuckl

HE schrieb:

na klar da habt ihr recht, wenn man mit objekten arbeitet ist malloc sicher nicht das nullplusultra, allerdings muss ich nur speicher für ein struct reservieren und dazu reicht malloc allemal.

Btw enthaelt deine struct einen string, was vermutlich eine Klasse sein wird. Insofern war schon in deiner anfaenglichen Situation dein struct kein POD-struct mehr und musste sich auf den impliziten Ctor verlassen, den malloc aber nicht aufruft.
Deswegen sollte man wirkli nicht C++ mit C-Speicherallokationen (und anderen C-Funktionen) anreichern, weil man oft nicht auf den ersten Blick sieht ob die C-Funktionen intern nicht irgendwas tun (oder eben nicht tun), was den C++-Objekten schaedlich ist.