Zweidimensionales Array sortieren

Na, hat sich mein Einsatz ja schon gelohnt, weil wir jetzt endgültig über C++ reden.

Mein Geschreibsel von gestern abend hat übrigens auch noch Fehler. Z.B. Z61 hat sich ret mit in den Funktionsaufruf geschlichen und Z150-153 fehlt jeweils ein dritter Parameter - den habe ich erst im nachhinein an die Signaturen geflanscht - sieht man jetzt ja was man davon hat!

Cysign schrieb:

Noch zum Verständnis:

samples.reserve(s_cnt); ist quasi das malloc des C++.
Zitat:vector::capacity()
But unlike arrays, their size can change dynamically, with their storage being handled automatically by the container. (http://www.cplusplus.com/reference/vector/vector/ )

Ich hatte das so verstanden, dass eine manuelle Reservierung in diesem Fall nicht nötig sei. Und muss der Speicher nicht wieder freigegeben (vgl. C free()) werden?

Weil ich schon weiss, wie viele samples ich in den vector einfügen werde, sage ich dem vector mit reserve() , worauf er sich einrichten soll.
Der vector alloziert dann genügend Speicher und ich kann anschließend bis zu s_cnt Elemente in den vector pappen, ohne dass dieser (eventuell teuer) beim OS um mehr Speicher bitten braucht. Siehe auch capacity(), resize(), size() .
Kann man machen, muss man aber nicht.
Was man (grundsätzlich) nicht braucht: Speicher, den der vector benutzt, irgendwo wieder freizugeben.

Cysign

Kann man machen, muss man aber nicht.

Genau so hatte ich mir das dann auch versucht zu erklären. Bzgl. der anderen drei Schlagworte werd ich gleich mal n bisschen Googeln.

Cysign

Also unter Lubuntu auf nem Laptop lief der Code sauber und schnell. Auf nem Raspberry Pi mit Raspbian siehts da schon anders aus.

Ich hab die etzten Stunden versucht, rauszubekommen, warum der Code den Pi abschmieren lässt , aber meine Vermutung, dass es an -std=gnu++0x liegt, wr falsch. Da ich unter Raspbian nicht mit c++11 kompilieren konnte, hab ichs zunächst mit gnu++0x versucht. Nach etwas Sucherei bin ich dann darauf gestoßen, dass man g++-4.7 nachinstallieren kann. Aber ein Kompilieren mittels g++-4.7 -std=c++11 hat leider auch keine Besserung gebracht. Ich kann zwar nun auf dem Pi mit c++11 kompilieren, aber das Programm stürzt weiterhin nach etwa einer halben Minute ab. Da hilft dann nur ein Neustart des Pi.

Da ich dachte, dass es evtl. zu jitter-Problemen kommen könnte, habe ich den delay-Wert mal hochgesetzt, was vorher bei dem zweifelhaften Samplecode des Herstellers geholfen hatte. Aber in diesem Fall rbachte es keine Verbesserung.

Hast du vieleicht eine Idee, was die problematische Stelle sein könnte?

Das ist natuerlich nicht gut - aber wie ich schon oben sagte: meine Version ist auch noch fehlerbehaftet - schließlich habe ich den Lagesensor nicht und konnte nie testen. (Wobei ich mich schon gerade auf die Suche gemacht habe, aber die Originale wohl nicht mehr produziert werden und Opensource-Clone habe ich nicht gefunden)
Jetzt mit dem Pi ist noch eine Unbekannte dazugekommmen, die ich nicht berücksichtigen kann.

Dass ich einen kleinen Rant gegen Toradex irgendwo in meinen Postings eingebaut habe, muss ich relativieren: die haben schon alles super dokumentiert und einsteigerfreundlich gemacht. Das was ich für das Linux-API gehalten habe ist ja nur ein Wrapper (um den mein Code wieder ein wrapper ist).

Mein Rat wäre also: dass Du Dir ein gesundes Verständnis der API (hiddev u. Co.) anliest, der Toradex-Linux Code ist ein super Start. Und dann nach und nach dem Fehler auf die Spur kommst.

Tut mir leid, dass ich zu diesem Zeitpunkt keinen besseren Rat habe, als von vorne zu beginnen, aber richtig.

FW

PS:
Wenn Du natürlich noch so einen Sensor für mich zusammenlötetest, setzte ich mich nochmal ran

Cysign

Danke für deine Hilfe, aber es geht mir grade eher darum, wie ich den Fehler finden könnte.
Bei meinem eigenen Frickelcode kann ich mir immer irgendwo irgendwas ausgeben, um Fehler zu suchen. Aber bei deinem Code fällt mir das was schwer.
Wie würdest du vorgehen?
Gibts irgend ne Möglichkeit, den Speicherverbrauch mit auszugeben, solange der Code ausgeführt wird? Vielleicht kann ich dann anhand der Größe Rückschlüsse ziehen.

Beim Pi kommt noch hinzu, dass es keine x86, sondern eine ARM-Basis ist. Ich vermute, dass hier irgendwo der Hund begraben liegt.
Wenn der Pi dann aussteigt, bricht seine wLan-Verbindung zusammen und nichts blinkt mehr (weder wLan am Dongle noch die Activity-LED).

Ich überlege schon, ob ich mich von dem Toradex-Sensor trennen und auf I2C setzen soll, zumal ich eh noch einen weiteren Sensor auf I2C-Basis ansteuern möchte. Und zwei I2C-fähige Beschleunigungssensoren hätte ich auch noch in meiner Bastelkiste.
Aber da haperts grade noch daran, dass ich nicht verstehe, wie die Register spezifisch angesprochen werden.
Leider hab ich in Richtung I2C über den Raspberry Pi weder gute Tutorials, noch interessante Bücher gefunden...

Cysign schrieb:

Danke für deine Hilfe, aber es geht mir grade eher darum, wie ich den Fehler finden könnte.

Erstmal: die beiden Fehler, die ich schon angesprochen habe hast Du behoben?
Dann gibt es zwei Zeiten in dem Code delay und sleepval . Vielleicht zu kurz? Zu lang?
Ausgeben kannst Du genauso wie überall sonst auch: pflaster gerne überall Testausgaben rein.
Z.B. in der main-loop

for( int i=0; i<s_cnt; ++i ){
      std::this_thread::sleep_for(sleepval);
      const sample_t s = sample(handle);
      std::cerr << i << ":\t" << s << '\n';
      samples.emplace_back(s);
    }

Cysign

Ah, okay. Das war untergegangen. Ich hatte das ret nicht geändert.
Ich hab in meiner Makefile jetzt das -Wall eingefügt und dann hab ich auch endlich gesehn, dass dem Compiler das ein Dorn im Auge ist.

Als Dritten Parameter des Funktionsaufrufs hab ich mal ne 1 mit übergeben. Ich weiß zwar, dass es ein Bool ist, aber mir ist schleierhaft, was er genau macht.

Jedenfalls läuft es nun schon länger auf dme Pi stabil als bisher. ICh lass das noch ein wenig durchlaufen und freu mich, dass ich nicht wieder aufstehen und den Pi neustarten muss

Sowohl sleepval als auch das delay haben grade den Wert 0.
Sleepval ist die von mir im Samplecode des Herstellers eingebaute Verzögerung, die dafür sorgte, dass der Code sich nicht aufgehangen hatte.
Da dein Code jedoch sauberer läuft, scheine ich den nicht mehr zu benötigen.

Danke nochmal vielmals für diene Hilfe!

Im C++-Buch bin ich übrigens grade aufs Überladen gestoßen. Genau das machst du hier mit 151-153, bzw. 69-114, sehe ich das richtig?

Cysign schrieb:

Als Dritten Parameter des Funktionsaufrufs hab ich mal ne 1 mit übergeben. Ich weiß zwar, dass es ein Bool ist, aber mir ist schleierhaft, was er genau macht.

Das regelt, ob der Parameter im RAM oder im Flash-Speicher des Devices gespeichert wird.

Cysign schrieb:

Im C++-Buch bin ich übrigens grade aufs Überladen gestoßen. Genau das machst du hier mit 151-153, bzw. 69-114, sehe ich das richtig?

Ja. Dummerweise ist das etwas schnoddrig von mir gemacht. Deswegen ist auch der fehlende dritte Parameter nicht aufgefallen. Anstatt die setzende Funktion zu benutzen hat der Compiler die überladene lesende Funktion genommen...
Also mal ein Beispiel, wie Du es nicht nachmachen solltest.

Ansonsten freut es mich natürlich zu hören, dass Du vorankommst.