ich will einen baum aufbauen, und die nodes sollen möglichst klein werden,
aber jeder node soll einen name haben, also dachte ich mir :
ich speicher pointer zu den namen (deren anzahl ist nämlich ziemlich begrenzt)
in einer map<name, std::string *>
so kann ich schnell den pointer zum namen finden

die erste funktion soll einen namen hinzufügen
die 2. ist der dtor
(std::map elemente muss man eigenlich nicht löschen, aber ohne gehts auch nicht)

sieht wer den fehler?

const std::string * const HMM_Tree::insertNodeName(const std::string& name)
{
std::map<std::string, std::string * >::const_iterator it = m_node_names.find(name);
if(it != m_node_names.end()) return it->second;
// else
std::string * new_name = new std::string(name);
m_node_names[name] = new_name;
return new_name;
}

HMM_Tree::~HMM_Tree()
{
// delete the names
typedef std::map<std::string, std::string * >::iterator name_map_it;
for(name_map_it it = m_node_names.begin(); it != m_node_names.end(); ++it)
  {
  delete it->second;
  it->second = 0;
  }
}

anbei noch die valgrind ausgabe

==13051== Conditional jump or move depends on uninitialised value(s)
==13051== at 0x805316E: HMM_Tree::~HMM_Tree() (hmm_tree.cpp:46)
==13051== by 0x804F6B7: Hybrid_HMM_Tests() (hybrid_hmm_test.hpp:10)
==13051== by 0x804F706: main (short_test.cpp:8)
==13051==
==13051== Use of uninitialised value of size 4
==13051== at 0x8053106: HMM_Tree::~HMM_Tree() (hmm_tree.cpp:48)
==13051== by 0x804F6B7: Hybrid_HMM_Tests() (hybrid_hmm_test.hpp:10)
==13051== by 0x804F706: main (short_test.cpp:8)
==13051==
==13051== Invalid read of size 4
==13051== at 0x40AFDFB: std::string::~string() (in /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/libstdc++.so.6.0.9)
==13051== by 0x805311C: HMM_Tree::~HMM_Tree() (hmm_tree.cpp:48)
==13051== by 0x804F6B7: Hybrid_HMM_Tests() (hybrid_hmm_test.hpp:10)
==13051== by 0x804F706: main (short_test.cpp:8)
==13051== Address 0xe8240485 is not stack'd, malloc'd or (recently) free'd
==13051==
==13051== Process terminating with default action of signal 11 (SIGSEGV)
==13051== Access not within mapped region at address 0xE8240485
==13051== at 0x40AFDFB: std::string::~string() (in /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/libstdc++.so.6.0.9)
==13051== by 0x805311C: HMM_Tree::~HMM_Tree() (hmm_tree.cpp:48)
==13051== by 0x804F6B7: Hybrid_HMM_Tests() (hybrid_hmm_test.hpp:10)
==13051== by 0x804F706: main (short_test.cpp:8)

das mit der map von strings kommt mir selber ein wenig komisch vor, aber ich
muss die späteren nodes halt so klein wie möglich halten, und sone map
kam mir am besten vor, um schnell von nem string zu nen ptr auf string zu kommen

[edit]
==13051== by 0x805311C: HMM_Tree::~HMM_Tree() (hmm_tree.cpp:48)
is dann diese zeile :

delete it->second;

was ich aber nicht verstehe, denn der ptr müsste doch wegen

std::string * new_name = new std::string(name);
m_node_names[name] = new_name;

valid sein

wenn ich den ganzen dtor auskommentiere kommt so sowas :

==13628== Conditional jump or move depends on uninitialised value(s)
==13628== at 0x8054025: std::_Rb_tree<std::string, std::pair<std::string const, std::string*>, std::_Select1st<std::pair<std::string const, std::string*> >, std::lessstd::string, std::allocator<std::pair<std::string const, std::string*> > >::_M_erase(std::_Rb_tree_node<std::pair<std::string const, std::string*> >) (stl_tree.h:1321)
==13628== by 0x805404F: std::_Rb_tree<std::string, std::pair<std::string const, std::string>, std::_Select1st<std::pair<std::string const, std::string*> >, std::lessstd::string, std::allocator<std::pair<std::string const, std::string*> > >::~_Rb_tree() (stl_tree.h:592)
==13628== by 0x80540A3: std::map<std::string, std::string*, std::lessstd::string, std::allocator<std::pair<std::string const, std::string*> > >::~map() (stl_map.h:94)
==13628== by 0x805318D: HMM_Tree::~HMM_Tree() (hmm_tree.cpp:56)
==13628== by 0x804F5C7: Hybrid_HMM_Tests() (hybrid_hmm_test.hpp:10)
==13628== by 0x804F616: main (short_test.cpp:8)

es scheint, das in der map, elemente sind die ich nicht reingepackt habe

Irgendwie scheint mir die map keinen Sinn zu machen, wenn Key und Value immer gleich sind
Ansonsten konnte ich auf die Schnelle keinen Fehler finden.

Vielleicht modifiziert er sie woanders und es soll so etwas wie ein "Nachschlagewert" im Sinne von Internationalisierung sein.

naja wie gesagt, ich sehe in der map auch keinen sinn, mir gings dabei eigentlich nur ums finden in logarithmischer zeit ...

std::set?

wenn ich einen vector nehme, muss ich ja im schlimmsten fall alle element durch

ich denke dabei geht dann irgendwas schief, ich finde übrigens dieses
autolöschen bei map irgendwie doof, sowas macht vector doch auch nicht ...

der eigentliche sinn war, später nodes zu erzeugen, welche einen ptr auf ihren namen haben, und da wollte ich dann einfach die oben gezeigte funktion nehmen,

im tree ist die map als member drin, und würde dann erst nach allen nodes destruiert,
somit wären alle ptr to string immer valid, und ich hätte pro node nur 4bytes verbraucht um den namem zu speichern

Die Funktion insertNodeName(const std::string& name) gibt dann ja immer nur einen Pointer auf eine Kopie des Parameters name zurück. Warum dann nicht gleich "name" nehmen?

ich denke dabei geht dann irgendwas schief, ich finde übrigens dieses
autolöschen bei map irgendwie doof, sowas macht vector doch auch nicht ...

Jeder Container der Standardbibliothek löscht seine Element im Destruktor.

Treb schrieb:

im tree ist die map als member drin, und würde dann erst nach allen nodes destruiert,

Kopierst du vielleicht den Tree selbst? Dann hast du hoffentlich auch einen passenden Copy-Konstruktor bzw. Zuweisungsoperator.

Treb schrieb:

somit wären alle ptr to string immer valid, und ich hätte pro node nur 4bytes verbraucht um den namem zu speichern

Dir ist aber schon klar, dass deine mit new angeforderten Strings auch Speicher verbrauchen?

Jeder Container der Standardbibliothek löscht seine Element im Destruktor.

In dem Fall aber ja nur den Pointer.

MFK schrieb:

Dir ist aber schon klar, dass deine mit new angeforderten Strings auch Speicher verbrauchen?

Immer nur beim ersten Aufruf. Danach wird nur noch der Pointer auf jenen vorher erstellten String zurückgegeben.

EDIT:

Eine Methode die ich sauberer finde:

Statt einen Pointer auf einen Namen bekommt jeder Node eine TypeID (Enum). Dazu eine Memberfunktion die anhand der TypeID den Namen zurückgibt. Braucht noch weniger Speicher.

jeder node hat einen namen, von den namen gibts ca 50
die bäume werden aber viele 1000 nodes haben, wovon viele natürlich
den selben namen haben werden
(es wird eben ein such-graph, wo die nodes zustände sind, und man kann
verschiedene zustände auch öfter besuchen)

ich wollte mir nun das speichern des names im node selber sparen, und jeder
node sollte nur einen pointer auf den namen haben, weil es eben viel mehr nodes als namen geben wird ...

beim erzeugen der nodes brauchte ich nun einen ptr auf den namen, und so wollte ich die finden ...

hätte ich einen vector genommen

std::vector<std::string> m_node_names;

hätte ich immer über den ganzen vector iterieren müssen, um nachzusehen ob name schon drin, (hätte dann aber adresse sofort über &m_node_names[i] zurückgegen können)

die std::set version sieht nun so aus

const std::string * const HMM_Tree::insertNodeName(const std::string& name)
{
std::set<std::string>::iterator it = m_node_names.find(name);
if(it != m_node_names.end()) return &(*it);
// else
m_node_names.insert(name);
it = m_node_names.find(name);
return &(*it);
}

und irgendwie glaube ich, meine stl-implementierung hat da irgendwo ne macke,
dann nun bekomme ich

==14333== Conditional jump or move depends on uninitialised value(s)
==14333== at 0x8053733: std::_Rb_tree<std::string, std::string, std::_Identitystd::string, std::lessstd::string, std::allocatorstd::string >::_M_erase(std::_Rb_tree_nodestd::string (stl_tree.h:1321)
==14333== by 0x805375D: std::_Rb_tree<std::string, std::string, std::_Identitystd::string, std::lessstd::string, std::allocatorstd::string >::~_Rb_tree() (stl_tree.h:592)
==14333== by 0x80537B1: std::set<std::string, std::lessstd::string, std::allocatorstd::string >::~set() (stl_set.h:94)
==14333== by 0x80529CD: HMM_Tree::~HMM_Tree() (hmm_tree.cpp:55)

aber das nehme ich mal als "warnung" hin ...

und irgendwie glaube ich, meine stl-implementierung hat da irgendwo ne macke

Und ich glaube, du zerlegst dir irgendwo in deinem restlichen Code den Speicher.

Du kannst deine Funktion übrigens etwas vereinfachen:

const std::string * const HMM_Tree::insertNodeName(const std::string& name)
{
    return &(*(m_node_names.insert(name).first));
}

Alles andere ist quark, besonders deine insertNodeName-Methode...

HMM_Tree HMM_ToTree(const Hybrid_LR_HMM& hmm)
{
std::string name = hmm.getName();
std::size_t numStates = hmm.numStates();
Matrix<double> trans_probs(hmm.trans_probs());

HMM_Tree ret_val;

for(std::size_t i=0; i < numStates -1; i++)
  {
  std::stringstream ss;
  ss << name << i;
  std::string subNodeName;
  ss >> subNodeName;
  ret_val.insertNodeName(subNodeName);
  std::cout << "Inserting node " << subNodeName << std::endl;
  }
return ret_val;
}

ohne

return ret_val;

was ich wegen unsinnigkeit zuerst weggelassen habe, kommt der fehler von oben,
nun läufts sauber und ich kann den baum aufbauen,
danke für den tip mit dem set
und entschuldigung für die aufregung

lolz_ausgeloggt schrieb:

Nein!
So macht man das nicht, du fügst beim einfügen einfach mit insert den Namen in das set ein, dann bekommst du ein std::pair zurück wovon der erste ein Iterator auf den String ist und diesen Iterator speicherst du als const_iterator-Attribut in deinem Node-Objekt.

Alles andere ist quark, besonders deine insertNodeName-Methode...

ist schon abgeändert ...

Wie bzw. wo erzeugst du denn deine Knoten?

Diesen Schritt mit den Namen könntest du auch weglassen, wenn du Zugriff auf die Namen beim erzeugen der Knoten hast.