Diese Seite ist unverschlüsselt! Um sicherzustellen, das Ihr Passwort nicht ausgelesen werden kann, sollten Sie auf die verschlüsselte Seite wechseln!

    Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » woher kommt das Memoryleak? - (shared_ptr)
Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] > 2 <
010
02.08.2009, 22:12 Uhr
deer
Zitat von 0xdeadbeef:

Allerdings bin ich mir nicht wirklich sicher, ob ich verstehe, was du eigentlich beabsichtigst, denn wenn es um das geht, worum ich es vermute, wären Symbole und Scopes völlig verschiedene Entitäten und die SymbolWithScope-Klasse ergäbe in der vorhandenen Form (von Scope abgeleitet) wenig Sinn.


Ich denke die Klasse SymbolWithScope macht schon Sinn... Ich brauche sie für structs und dergleichen...

Ich habe die Idee von dieser Seite:
www.antlr.org/wiki/display/CS652/Data+aggregates+solution
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
011
02.08.2009, 23:12 Uhr
0xdeadbeef
Gott
(Operator)


Scheinbar meinen die mit Symbolen und Scopes etwas andere Dinge, als ich die Begriffe gelernt habe. Scopes scheinen hier eher die Funktion von Namespaces zu haben. Oder zumindest etwas in der Art - es geht um das Auffinden von Symbolen, nicht um ihren Geltungsbereich.

In dem Fall könnte man es wohl so auffassen, obwohl mir unklar ist, warum LocalScope ein Symbol sein soll. Der State-Machine-Ansatz macht dann allerdings wenig Sinn, weil du ja gar keine state machine implementierst.

Es ist schwierig, so aus dem Stegreif eine sinnvolle Modellierung vorzuschlagen. Ich habe zwar eine grobe Idee, womit du da arbeiten willst, aber was soll das Programm nachher eigentlich genau können?
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
012
03.08.2009, 12:07 Uhr
deer
Zitat von 0xdeadbeef:
Scheinbar meinen die mit Symbolen und Scopes etwas andere Dinge, als ich die Begriffe gelernt habe. Scopes scheinen hier eher die Funktion von Namespaces zu haben. Oder zumindest etwas in der Art - es geht um das Auffinden von Symbolen, nicht um ihren Geltungsbereich.

In dem Fall könnte man es wohl so auffassen, obwohl mir unklar ist, warum LocalScope ein Symbol sein soll. Der State-Machine-Ansatz macht dann allerdings wenig Sinn, weil du ja gar keine state machine implementierst.

Es ist schwierig, so aus dem Stegreif eine sinnvolle Modellierung vorzuschlagen. Ich habe zwar eine grobe Idee, womit du da arbeiten willst, aber was soll das Programm nachher eigentlich genau können?


Das Programm speichert die Definitionen von Variablen (von einem c-File) in einer Map im entsprechenden scope und sucht nach diesen wenn sie benützt werden (lookup).

Du hast recht, dass es wenig Sinn macht, dass LocalScope auch ein Symbol ist. Aber für den Fall eines struct würde es doch gelten? (ist ein symbol sowie definiert einen neuen scope)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
013
03.08.2009, 15:56 Uhr
0xdeadbeef
Gott
(Operator)


Ui, da haste dir ja ganz schön was vorgenommen. Gut, in dem Fall ist das mit der Klassenkapselung wohl nicht zwingend notwendig (es sei denn, du brauchst Funktionalität, die die gesamte Symboltabelle betrifft), aber als globale Variable macht das auch wenig Sinn. Ich nehme an, dass am Ende etwas wie

C++:
int main() {
  boost::shared_ptr<Scope> root_scope = parse_file("code.c");
}

dabei herauskommt (Der Parser-Aufruf mag allerdings etwas komplexer aussehen).
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
014
03.08.2009, 17:49 Uhr
deer
Zitat von 0xdeadbeef:
Ui, da haste dir ja ganz schön was vorgenommen. Gut, in dem Fall ist das mit der Klassenkapselung wohl nicht zwingend notwendig (es sei denn, du brauchst Funktionalität, die die gesamte Symboltabelle betrifft), aber als globale Variable macht das auch wenig Sinn. Ich nehme an, dass am Ende etwas wie

C++:
int main() {
  boost::shared_ptr<Scope> root_scope = parse_file("code.c");
}

dabei herauskommt (Der Parser-Aufruf mag allerdings etwas komplexer aussehen).


eigentlich läufts schon ziemlich gut... ausser dass ich wohl im Modellieren etwas in die Sch** gegriffen habe;-) und dazu ziemlich viele Memory Leaks ausmerzen muss. Dann werde ich mal die Idee (scopes in shared_ptr zu verpacken) ausprobieren. hoffe, dass wirkt sich nicht negativ auf die Performance aus...

danke für die Unterstützung! :-)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
015
03.08.2009, 18:53 Uhr
0xdeadbeef
Gott
(Operator)


Zirkelverweise sollte es ja in diesem Zusammenhang nicht geben, von daher sollte shared_ptr, sofern du ihn konsistent überall verwendest, zum Aufräumen ausreichen.

Übrigens würde ich mir vielleicht ein typedef dafur zurechtlegen, um Tipparbeit zu sparen, etwa

C++:
class scope {
public:
  typedef boost::shared_ptr<scope> ptr;
};

// ...

scope::ptr root_scope = parse_file("code.c");

...ist aber nur so eine Idee. Auf die Art könntest du auch auf std::tr1::shared_ptr bzw., sobald c++0x fertig ist, std::shared_ptr umstellen, ohne den Code an zwanzigtausend Stellen ändern zu müssen.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
016
06.08.2009, 19:13 Uhr
deer
Zitat von 0xdeadbeef:
Zirkelverweise sollte es ja in diesem Zusammenhang nicht geben, von daher sollte shared_ptr, sofern du ihn konsistent überall verwendest, zum Aufräumen ausreichen.

Übrigens würde ich mir vielleicht ein typedef dafur zurechtlegen, um Tipparbeit zu sparen, etwa

C++:
class scope {
public:
  typedef boost::shared_ptr<scope> ptr;
};

// ...

scope::ptr root_scope = parse_file("code.c");

...ist aber nur so eine Idee. Auf die Art könntest du auch auf std::tr1::shared_ptr bzw., sobald c++0x fertig ist, std::shared_ptr umstellen, ohne den Code an zwanzigtausend Stellen ändern zu müssen.


FYI:
Da das Problem nur in diesem Fall auftrat:

typedef struct A
{
struct A * next;
} B;

wobei der aktuelle scope A ist und zugleich der Typ von next. (was beim speichern zum leak geführt hat)
Ich umgehe das nun indem ich in diesem speziellen Fall ein neues Objekt für den Typ erstelle.

danke für Hilfe!
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] > 2 <     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: