lerneLebenslang schrieb:
SeppJ schrieb:
Du erreichst damit schon das, was du beschreibst, aber was steht denn in entry->d_name? anscheinend nicht das, was du denkst. In Zeile 30 gibst du es aus. Fällt dir daran nicht auf?
Oje, die Fragezeichen werden bei mir immer größer.
Also laut http://www.delorie.com/gnu/docs/glibc/libc_270.html ist doch in der struct dirent unter d_name der Datei-/Ordnername abgespeichert. Und genau den möchte ich doch haben.
Nope:
This is the null-terminated file name component.
Nur der Dateiname. *wink wink*
Und jetzt zu dem errno. Ich bin mir nicht sicher, ob ich das Vorgehen bis jetzt verstanden habe.
Nein, errno geht ganz anders. errno ist eine globale Variable. Stellst du fest, dass eine Funktion einen Fehler verursacht hat (Rückgabewert), dann kannst du dir den Wert in errno angucken, was genau der Fehler war. Das hat die Funktion im Fehlerfall da rein geschrieben. so kannst du zum Beispiel unterscheiden, ob stat fehlgeschlagen ist, weil die Datei nicht gefunden wurde oder weil die Festplatte explodiert ist.
errno wird nicht automatisch zurück gesetzt (also auf 0 gesetzt). Wenn du mehrere Funktionen aufrufst, die errno verändern können, dann musst du aufpassen, welche davon errno verändert hat.
kompail schrieb:
Mit welchen Flags hast du denn kompiliert? Du brauchst -pthread und eine aktuelle GLIBCXX.
Aha, so einfach kann es also sein. Sagt einem ja auch keiner.
g++ -Wall -pedantic -std=c++0x -O2 -c createThreadWithArguments.cpp
g++ -Wall -pedantic -std=c++0x -O2 -pthread -o "createThreadWithArguments" createThreadWithArguments.o
Dann funzt es auch.
Gruß,
-- Klaus.
normalerweise ruft man configure, make, install auf.
source sieht man sich an indem man im dateiexplorer an die richtige stelle navigiert und das file editiert man in einem schlanken editor, z.B. gedit, scite oder gar nano oder vi.
tntnet schrieb:
Wenn Du dann 10 oder 100 oder 1000 Threads hast, die alle auf select oder poll warten, dann erzeugt das keine Last.
Genau das ist im Prinzip auch die Lösung die ich anstrebe. Die ist rein logisch und technisch auch sauberer als das Mini-Wait, was ich derzeit verwende.
ach blind ist der mensch! ich habs. so ist richtig:
COMMAND="nohup "$@" > nohup.log 2>&1 < /dev/null &"
was so ein hochkommata so aus machen kann. vielen dank für eure hilfe!
ComputerCarl schrieb:
Fragen an SeppJ:
-> "Überflüssige, selbstverschuldete Speicherlöcher im Bereich von Zeile 666."
Das war ja im Ursprungs-Code. Leider weiss ich nicht was du damit meinst. Könntest du das bitte etwas einfacher für micht formulieren?
Benutz kein new. Benutz keine Pointer.
^(Irgendwann, in ferner Zukunft, kommt vielleicht der Moment, an dem du Pointer/new brauchst. Bis dahin weißt du hoffentlich, wie man damit umgeht. Hier jedenfalls ist es einfach nur falsch.)^
-> "Die typischen Logikfehler bei Leseaktionen"
Auch das klingt sehr wichtig und ich weiss nicht was du meinst.
Was ist an folgendem Ablauf falsch?
-Prüfen ob Fehler aufgetreten ist
-Fehleranfällige Aktion durchführen
-Ergebnis verarbeiten
-Zurück zum Anfang
So machst du es aber. In C-artigen Sprachen sieht eine Leseschleife so aus:
Schleife solange (Leseaktion erfolgreich)
{
verarbeite Ergebnis;
}
Deine Schleife ist ein ganz typisches Alarmsignal für einen schlechten Lehrer/Buchautor. Das ist Grundlagenwissen, wird aber trotzdem oft falsch gezeigt. Von diesem Lehrer/Autor solltest du dich sofort(!) trennen.
-> "dilletantische Umwandlung von Text in Zahlen"
eine andere Umwandlung wäre wohl mit Hilfe von maps oder so. Was wäre da erfahrungsgemäß eine der schnelleren und besten Umwandlungen.
Du brauchst keine Geschwindigkeit beim Lesen/Umwandeln. Was du hingegen bräuchtest, wären Fehlerprüfungen.
Allgemein muss ich den Code irgendwie schneller hinbekommen, da die Datenmengen die ich bearbeiten muss ziemlich groß sind. Eine Berechnungszeit von bis 3 Tagen wäre o.k.,
aber ich brauche wohl für meinen Datensatz eine Woche.
Vermutlich kann man den Algorithmus an sich verbessern. Dafür müsste man aber wissen, was du warum machst. Dies wird vermutlich die Möglichkeiten des Forums übersteigen.
Allgemein fällt mir auf, dass du Dinge sehr oft mehrmals machst, die du nur einmal machen bräuchtest und danach das Ergebnis benutzen könntest.
Jeder Tipp wäre hilfreich und bei Fragen zum Code, der Thematik oder der Daten würde ich gerne Auskunft geben.
Guck dir mal an, was ein Profiler ist, damit du nicht länger so komischen Mythen anhängst, was dein Programm schneller macht. Ich fürchte allerdings, du brauchst mehr Erfahrung, um das Ergebnis zu verstehen. Die kann ich dir nicht geben.
recv kehrt zurück wenn ein Paket angekommen ist (oder andere Gründe siehe manpage errorcodes) das Paket wird in den puffer geschrieben ist der zu kurz, dann wird der Rest verworfen.
Du kannst aber mithilfe von MSG_PEEK erstmal den Anfang der Nachricht anschauen um so eine Größenangabe auszulesen, und dann genug Speicher allokieren. Der nächste recv Aufruf verhält sich wie oben.
Bei tcp werden immer soviele Daten aus dem puffer des sockets in deinen puffer geschrieben wie vorhanden sind bzw. in deinen puffer passen.
Im Grunde bringt jede Disribution das Handwerkszeug zum programmieren mit und was nicht dabei ist, kann man sich installieren. Man sollte die Distribution wählen mit welcher man persönlich am besten zurecht kommt.
Da ich zur Zeit nur für die Konsole am schreiben bin, benutze ich nicht mal mehr die GUI sondern nur die Shell und Nano sowie Fedora.
Aus persönlicher Erfahrung würde ich für die C/C++ Programmierung auch von Eclipse abraten. Es bringt einfach zu viel Balast mit, den man nicht wirklich gebrauchen kann. Sollte aber jemand nur mal in C/C++ reinschnuppern und sonst in Java programmieren und dadurch eh schon Eclipse nutzen, da kann man natürlich die Erweiterungen für C/C++ installieren.
Sollte man sich aber rein der C/C++ Programmierung widmen und unbedingt in einer grafischen Umgebung seine Programme entwickeln ist Code:Blocks eine gute Wahl oder die für die jeweilge installierte Grafischen Desktopumgebung vorhanden Entwicklungsumgebung zu nutzen.
Am Ende ist es aber wie am Anfang mit den Distributionen, man muss mit der Entwicklungsumgebung zurecht kommen und damit glücklisch werden
Hallo zusammen,
Ich soll als Hausaufgabe für die Uni eine kleine Shell in C schreiben. Unter anderem soll diese Shell einen Befehl "wait" bereitstellen, welcher auf die Terminierung von Hintergrundprozessen wartet.
Mein Problem ist nun, dass ich die Hintergundprozesse mit setid()(<unistd.h>) in den Hintergrund geschoben habe und sie somit vom Parentprozess entkoppelt habe. Daher erhalte ich die Fehlermeldung
"/usr/bin/wait: line 4: wait: pid 15487 is not a child of this shell"
beim Ausführen von "wait 15487".
Nun frage ich mich ob es eine Möglichkeit gibt dieses Problem zu lösen. Gibt es eine andere Möglichkeit Prozesse in den Hintergrund zu schieben, oder einen anderen waitpid Befehl, oder könnte weitpid() eigentlich auch "nicht-Kind-Prozesse" behandeln?
Du hast korrekterweise versucht, das code-tag zu verwenden. Du hast aber offensichtlich nicht die Vorschau verwendet. Wenn Du was geschrieben hast, schau Dir die Vorschau an, ob das das für den Leser zumutbar ist. So macht es kein Spaß zu lesen.
Was mir spontan so auffällt solltest Du den Rückgabewert von read immer auswerten.
