Ich wollte das std::string Array:

string sprache[5] = 
{
"Deu",
"Eng",
"Rus",
"Pol",
"Lit"
};

Als Vector anlegen, ohne weiterhin das string Array zu verwenden.
(Also nicht, das string Array und den vector anlegen und das string Array dann hineinkopieren)

vector <string> sprache(5) = 
{
"Deu",
"Eng",
"Rus",
"Pol",
"Lit"
};

/\
||
Also, so funktioniert es schonmal nicht. LOL (Wäre auch zu einfach gewesen!!)

Gut, nach einigem Durchforsten in der Klassenbeschreibung kam ich dann auf diese Lösung:

vector <string> sprache("Deu","Eng","Rus","Pol","Lit"};

ABER --> Das funktioniert so auch nicht, nur für 2 Elemente, ab 3 Elementen passt wohl der Construktor nicht mehr.

Soweit habe ich es ja nun verstanden, daß es nicht geht, aber gibt es eine Möglichkeit, daß es geht?

Meine bisherige Lösung:

vector<string> sprache;
sprache.push_back("Deu");
sprache.push_back("Eng");
sprache.push_back("Rus");
sprache.push_back("Pol");
sprache.push_back("Lit");

funktioniert bestens, aber ist ein wenig umständlich, da ich sehr große string Arrays habe. mit 27, 41 und 138 string Elementen.

Schön wäre eine Initialisierung im Stil von:

vector<string> sprache ..irgendwie die string Elemente reinpacken..

Also direkt mit den string Elementen initialisieren.

Mir würde auch eine Antwort der Art:

"Geht nicht." helfen, dann muß ich nicht weiter suchen und kann wieder ruhig schlafen.

Gruß,
DC

Danke für die flotte Antwort..

Gruß,
DC

Die Konstruktorvariante template <class InputIterator> vector (InputIterator first, InputIterator last, const Allocator& = Allocator()) sollte funktionieren, folgendermaßen:

std::string strarr[] = {"str1", "str2", "str3", "str4"};
std::vector<std::string> strvec(strarr, strarr + sizeof(strarr) / sizeof(std::string));

Zeiger sind auch Iteratoren, wenn es nach der STL geht.

Ich wollte das std::string Array:

string sprache[5] = 
{
"Deu",
"Eng",
"Rus",
"Pol",
"Lit"
};

Als Vector anlegen, ohne weiterhin das string Array zu verwenden.
(Also nicht, das string Array und den vector anlegen und das string Array dann hineinkopieren)

#include <boost/assign/std/vector.hpp>

// ...

vector<string> v;
v += "Deu", "Pol", "Lit", "...";

Natürlich hast du dann eine zusätzliche Abhängigkeit, die ist in dem Fall aber marginal.

Vielen Dank!!

Gruß,
DC

vector <string> sprache(5) = 
{
"Deu",
"Eng",
"Rus",
"Pol",
"Lit"
};

(Mit runden Klammern, oder mit Eckigen?)

Habe GCC 4.5, aber mit runden Klammern hat es nicht geklappt.

Gruß,
DC

vector<string> sprache=
{
"Deu",
"Eng",
"Ita",
"Fra",
"Gri"
};

gcc 4.5 oder VisualStudio 2010 unterstützen dies bereits.

Also VS2010 unterstützt das leider noch nicht, zumindest bekomme ich den Fehler
error C2552: 'sprache' : non-aggregates cannot be initialized with initializer list

Ich probiere es nun erst einmal mit der boost Lösung.

Gehe ich recht in der Annahme, daß der vector am Ende nicht freigegeben werden kann und deswegen diesen Ausnahmefehler erzeugt?

Gehe ich recht in der Annahme, daß der vector am Ende nicht freigegeben werden kann und deswegen diesen Ausnahmefehler erzeugt?

Dies wäre äußerst ungewöhnlich. Zeig mal mehr Code. Das mit dem fehlenden virtuellen Destruktor klingt schon einmal verdächtig. Erbst du etwa von einem STL-Container?

Also, so funktioniert es schonmal nicht. LOL (Wäre auch zu einfach gewesen!!)

Mit Raten kommst Du in C++ nicht weit. Die Sprache bietet da so einige Irregularitäten. Das kann man sich nicht alles selbst zusammen reimen.

Tja, mit der boost Lösung das gleiche Problem.
Nach Verlassen der Funktion ein Ausnahmefehler.

Wahrscheinlich rufst Du irgendwo undefiniertes Verhalten hervor.

Don Carsto schrieb:

Nur meldet mir der Compiler diesmal, daß er einen nicht-virtuellen Destruktor hat.

Wer hat einen nicht-virtuellen Destruktur und warum sollte das hier eine Rolle spielen?

Don Carsto schrieb:

Gehe ich recht in der Annahme, daß der vector am Ende nicht freigegeben werden kann und deswegen diesen Ausnahmefehler erzeugt?

Falsch geraten.

Versuche das Programm zu verkürzen und vereinfachen und damit den Fehler zu isolieren. Oft findet man so schon den Übeltäter. Wenn Du uns ein kurzes, komplettes Programm zeigen kannst, was sich Deiner Meinung nach ähnlich komisch verhält, dann kann man mehr dazu sagen. Betonung liegt auf "kurz" und "komplett".

Dies wäre äußerst ungewöhnlich. Zeig mal mehr Code. Das mit dem fehlenden virtuellen Destruktor klingt schon einmal verdächtig. Erbst du etwa von einem STL-Container?

Ich habe nun mal das Ganze in eine einfache Consolen Anwendung gepackt. Die Warnungen mit dem non-virtuell-destruktor kommen trotzdem, aber es läuft ohne Ausnahme durch. (Die Warnungen kommen schon,wenn ich nur die boost-include einbinde) Liegt wohl eher an der hohen Warnstufe des Compilers.

Nun habe ich mal den "fehlerhaften" Code komplett gekürzt und schwupps läuft es durch.
Da scheint irgendein anderes böses Objekt die Ausnahme zu erzeugen.

Leider ist der Coee so lang und komplex, daß ein posten nicht viel Sinn macht.

Da ich nun weiß, daß es nicht am vector selbst liegt, sondern eher an dem chaotischen Drumherum, werde ich das mal entwirren (Schritt für Schritt ausblenden) und die fehlerhafte Stelle suchen.

Sinn des Ganzen war sowieso zunächst den Code komplett zu Überarbeiten, um unsichere Stellen auszumerzen.

zu krümelkacker: (Post erst während der Erstellung gelesen)
Ja, leider kann ich keinen vereinfachten Code posten, der sich ähnlich verhält.
Und das mit dem Isolieren habe ich gerade in Angriff genommen. Mal sehen.

Jedenfalls funktioniert die boost-Lösung und auch die GCC 4.5 mit dem noch nicht freigegebenen C++ Standard auch. Der Übeltäter ist irgendwo anders im Code.

Vielen Dank nochmal für die Unterstützung. Und die Lösung des Problems.

So.. nun gehts ans Fehlersuchen...

Gruß,
DC

Es lag an einem zu kleinen char filestring[40];

Dieses wurde wohl etwas zu weit (um 3 Zeichen) überschrieben.
Dadurch wurde die restliche Speicherverwaltung überaus brüchig.
Hatte sich bisher noch nie bemerkbar gemacht, doch seit ich nun auf std::strings und std::vector umgestellt habe, wurden Ausnahmen geschmissen.

Eine tickende Zeitbombe....

Wechsle bei der Gelegenheit am besten alle rohen C-Arrays aus (gegen std::tr1::array , boost::array , oder std::array - alles das Gleiche) und ersetze alle Zeiger auf dynamische Arrays durch std::vector .

Habe nun erstmal eine einigermassen lauffähige Version erschaffen, die sich nun genauso verhält wie die Alte, außer, daß es nun 3x-langsamer geworden ist.

Habe aber auch noch nicht den kompletten Code umgebastelt.
Sind noch einge Krücken drinne.

Habe nun erstmal eine einigermassen lauffähige Version erschaffen, die sich nun genauso verhält wie die Alte, außer, daß es nun 3x-langsamer geworden ist.

Sollte nicht sein, wenn man richtig umbaut.

Natürlich sollte man schon einige Dinge beachten, damit der Vergleich überhaupt gerechtfertigt ist:

• Ganze Container so selten wie möglich kopieren. Lieber mit Const-Referenzen oder Iteratoren arbeiten.
• Generell Objekt-Kopien vermeiden durch Einsatz von swap() und Move-Semantik in C++0x.
• Wenn die Grösse bei std::vector und std::string im Voraus bekannt ist, mit reserve() vorallokieren.
• Im Release-Modus kompilieren und Debug-Laufzeitumgebung abschalten.
• Sicherheitsmassnahmen wie Checked-Iterators deaktivieren.

Hatte zunächst nach dem Umstellen auf string und vector folgendes sehr zeitaufwendige Konstrukt von char-Array auf string umgestellt (Dieses wird etwa 26000 mal aufgerufen)
(Die Schleife selbst ->for(int aa=0;aa<shad_sku.size();aa++)<- ca.65000 mal)

Hier das Original mit char-Array:

if (teilupdate==1)
{
if (strcmp(test[spalmengel],"0")==0) strcpy(app,"x");

strcpy(bigbuffer,"");
sprintf(bigbuffer,"%s\t%s\t%s\t%s\t%s\t%s\t%s\t\t\t%s\t%s\t%s\t%s\t%s\t\t\t\t%s\t%s\t%d\t\n",test[spalsku],test[spalautor]
,fattitle,test[spalverlag],test[spaljahr],test[spalformat],test[spalpreis],test[spalmengel],test[spalamazustand],fatnote,test[spalkatamazon],test[spalsprache],amaurl,app,7);

 for (int aa=0;aa<anzsku;aa++)
  {
   if (strcmp(shad[aa].sku,test[spalsku])==0)
     {
      if((strcmp(shad[aa].anz,test[spalmengel])!=0)||(strcmp(shad[aa].dat,test[spalaenderung])!=0)) {f << bigbuffer;aa=anzsku;flag=1;NR++;}
      else {aa=anzsku;flag=1;}
     }       
  }
if (flag==0) {f << bigbuffer;NR++;}
rectx=SUMAKT*balkx/SUMMAX;SUMAKT++;
}

Laufzeit flotte 16 Sekunden.

Dann die Abänderung ins std::string + vector:
bigbuffer ist nun ein stringstream, aber der bremst nicht.

if (teilupdate==1)
{
if (test[spalmengel]=="0") strcpy(app,"x");

bigbuffer << test[spalsku] << "\t" << test[spalautor] << "\t" << fattitle << "\t" << test[spalverlag]
          << "\t" << test[spaljahr] << "\t" << test[spalformat] << "\t" << test[spalpreis] << "\t\t\t"
          << test[spalmengel] << "\t" << test[spalamazustand] << "\t" << fatnote << "\t" << test[spalkatamazon]
          << "\t" << test[spalsprache] << "\t\t\t\t" << amaurl << "\t" << app << "\t" << "7" << "\t\n";

for (int aa=0;aa<shad_sku.size();aa++)
  {
   if (shad_sku.at(aa)==test[spalsku])
     {
      if((shad_anz.at(aa)!=test[spalmengel])||(shad_dat.at(aa)!=test[spalaenderung]))
         {
          f << bigbuffer.str();
          flag=1;
          NR++;
          break;
         }
      else
         {
          flag=1;
          break;
         }
     }
  }
if (flag==0) {f << bigbuffer.str();NR++;}
rectx=SUMAKT*balkx/SUMMAX;SUMAKT++;
}

Laufzeit grobe 60 Sekunden.

Dann nun wieder abgeändert in:

if (teilupdate==1)
{
if (strcmp(test[spalmengel].c_str(),"0")==0) strcpy(app,"x");

bigbuffer << test[spalsku] << "\t" << test[spalautor] << "\t" << fattitle << "\t" << test[spalverlag]
          << "\t" << test[spaljahr] << "\t" << test[spalformat] << "\t" << test[spalpreis] << "\t\t\t"
          << test[spalmengel] << "\t" << test[spalamazustand] << "\t" << fatnote << "\t" << test[spalkatamazon]
          << "\t" << test[spalsprache] << "\t\t\t\t" << amaurl << "\t" << app << "\t" << "7" << "\t\n";

for (int aa=0;aa<shad_sku.size();aa++)
  {
   if (strcmp(shad_sku.at(aa).c_str(),test[spalsku].c_str())==0)
     {
      if((strcmp(shad_anz.at(aa).c_str(),test[spalmengel].c_str())!=0)||(strcmp(shad_dat.at(aa).c_str(),test[spalaenderung].c_str())!=0))
         {
          f << bigbuffer.str();
          flag=1;
          NR++;
          break;
         }
      else
         {
          flag=1;
          break;
         }
     }
  }
if (flag==0) {f << bigbuffer.str();NR++;}
rectx=SUMAKT*balkx/SUMMAX;SUMAKT++;
}

Also sämtliche string==string und string!=string Vergleiche durch strcmp(x,y)==0/!=0 ersetzt.
Laufzeit grobe 25 Sekunden.

.at() und .size() Verzicht führt zu keinerlei Veränderung.

Warum ist string==string string!=string langsamer als strcmp() ??

Gibt es da eine Abhilfe?

Gruß,
DC

.at() und .size() Verzicht führt zu keinerlei Veränderung

Na das wuerde mich stutzig machen.

Warum ist string==string string!=string langsamer als strcmp()?

Hmm, es ist nicht langsamer. Anstatt zu raten, benutze einen Profiler!

Ansonsten kann ich mich knivil anschliessen. Und benutze bitte [cpp]- statt [code]-Tags, die haben Syntaxhighlighting.

Hast du meine Ratschläge befolgt (besonders die letzten beiden)?

Ja, habe etliche Kombinationen probiert und es führte zun Nichts.
Vorallokierung mit .reserve() gab auch keinelei Vorteile.

Ansonsten kann ich mich knivil anschliessen. Und benutze bitte [cpp]- statt [code]-Tags, die haben Syntaxhighlighting.

[quote]

Okay, habe nun nochmals den Schleifenkörper auf Durchläufe geprüft und muss sagen es sind insgesamt: 2075966830 Durchläufe. !!Jaja, was für ein Wahnsinn!!
(Es werden hier zwei Tabellen miteinander verglichen. Die 1.Tabelle hat knappe 65000 Einträge die 2.Tabelle ca.26000.)

Da beide Tabellen aber nach gleichem Kriterium sortiert sind, muß ich garnicht jedesmal die komplette Tabelle nach einem Match durchsuchen, sondern es reicht, wenn ich nach einem Fund, einfach den Schleifenstartindex hochsetze.
(Dadurch verkleinert sich der Suchbereich)
Nachdem ich diese kleine Korrektur vorgenommen hatte, sind es nur noch 64435 Durchläufe.
Auf dieser Basis habe ich nun die strcmp's wieder durch string==string ersetzt und die Zeit ist nun ohne merkliche Unterschiede jedesmal knappe 8 Sekunden.

(Hatte auch gestern mal eine Lösung mit <vector>.erase() versucht, aber durch diese dynamische Vectorverkleinerung schrumpfte zwar der Suchbereich, aber es dauerte auch sehr lange, weil das Entfernen eines Vector-Elements wohl auch recht zeitaufwendig ist)

Auf jeden Fall spielt wohl die Anzahl der Schleifen eine Rolle.
Wenn ich nun richtig gerechnet habe ist der Unterschied zwischen strcmp und string==string 0,000000025 Sekunden.
Bei 65000 Durchläufen wären es 0,0016 Sekunden länger.
Und bei 2000000000 Durchläufen schon 50 Sekunden.

Gruß,
DC