Oh man ja, ich depp hab übersehen das die Byteorder in der Paketspezifikation festgelegt wurde. Und ich war gerade etwas verwirrt...
Danke für die schnelle Antwort. Hat sich damit erledigt.
es gibt keinen grund für einen neuen thread. es gibt nicht mal einen grund, überhaupt threads zu verwenden. dein programm läuft so ab:
verbinden -> was verschicken -> was empfangen -> was tun -> [zurück zu "was empfangen"]
das schreit ja direkt nach einer schleife ab "was empfangen" :-). eine schleife verbraucht keinerlei ressourcen. wenn du threads erzeugst, werden damit immer ressourcen verbraucht - auch wenn du pthread_detach aufrufst.
Moin!
Also ich habe jetzt noch ne feststellung gemacht:
Auf einer 2. AIX Kiste tritt das problem nicht auf... dafür auf einer 2. Solaris Kiste...
Ich wüsste auch nicht welcher Prozess da noch nen Zugriff drauf haben soll, da ja eigentlich das File geschlossen wird bevor ich Gzip aufrufe (Zeile 2)...
Das Problem wurde gelöst:
# define a sample name for the application's name
target := app
# define build options
# compiler name
CXX := g++
# compile options
CXXFLAGS := -ansi -std='c++98' -pedantic -Wall -Weffc++ -Wold-style-cast \
-Wextra -Wunknown-pragmas -Wshadow -Wwrite-strings -Wconversion \
-Wunreachable-code -Winline -Wdisabled-optimization -O3 -march=prescott \
-mfpmath=sse -mmmx -msse -msse2 -msse3
# link options
LDFLAGS := -s
# link libraries
LDLIBS :=
# construct lists of .cpp and their corresponding .o files
sources := $(wildcard *.cpp)
objects := $(sources:.cpp=.o)
dependency := Makefile.dep
# main goal for 'make' is the first target, here 'all'
# 'all' is always assumed to be a target, and not a file
# file disambiguity is achieved via the '.PHONY' directive
# usage: 'make all' or simply 'make', since this is the first target
.PHONY : all clean
all : $(target)
@echo done.
# rule for 'target'
# the automatic variable '$^' expands to all prerequisites (objects)
# the automatic variable '$@' expands to the target's name
# the actual action done is the linking of all .o files into the executable
$(target) : $(objects)
@echo linking...
@$(CXX) $(LDFLAGS) $^ $(LDLIBS) -o $@
# rule for creating an .o file out of a corresponding .cpp file
# the automatic variable '$<' expands to the first prerequisite (%.cpp)
.cpp.o :
@$(CXX) -c $(CXXFLAGS) $< -o $@
# include the dependency file only when 'make clean' is not specified
# this is done to prevent recreating it when the clean target is specified
# if no dependency exist, on the other hand, no warning will be issued:'-' key
ifneq ($(MAKECMDGOALS), clean)
-include $(dependency)
endif
# rule for creating a dependency file
# the preprocessor is used to find out all header-dependencies and store them
# in a dependency file, later to be analyzed by the 'make' utility
$(dependency) :
@echo generating dependencies...
@$(RM) $(dependency)
@$(CXX) -E -MM $(sources) >> $(dependency)
@echo compiling...
# even if there exists a file 'clean', 'make clean' will execute its commands
# and won't ever assume 'clean' is an up-to-date file
# the 'clean' target will remove all intermediate files - .o, .dep respectively
# usage: 'make clean'
clean :
@$(RM) $(target) $(dependency) $(objects)
@echo target, dependencies and objects were removed
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Linux/Unix verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.
mcr schrieb:
Aber vielleicht doch einen anderen Vorschlag:
Teile dem Thread mit, dass er sich selbst beenden soll. Dafür kannst du ja
in regelmäßigen Abständen eine Zustandsvariable im Thread abfragen und anhand
deren Zustand entsprechend reagieren.
Ein Thread bekommt die Info: <Programm beenden>
Dieser Thread setzt die Zustandsvariable jeden Threads auf: <Thread stop>
Jeder Thread schaut zu definierten Zeitpunkten nach, findet dann die Info
<Thread stop> und beendet sich ordnungsgemäß.
Das hört sich ja nach Polling an. Polling sollte jedoch soweit wie möglich vermieden werden; vor allem, wenn man bereits auf IO wartet.
Hi Leute,
ich habe zur Zeit ein Problem mit einer Funktion. Diese erstellt an einer bestimmten Stelle ein einzelnes Eingabefeld. Es soll ganz simpel Eingaben entgegennehmen und bei einem Enter zurückkehren.
Hier der Code:
void NTester::getViaForm(int y, int x)
{
field = new FIELD*[2];
field[0] = new_field(1, 10, y, x, 0, 0);
field[1] = NULL;
set_field_fore(field[0], COLOR_PAIR(2));
set_field_back(field[0], COLOR_PAIR(2));
form = new_form(field);
post_form(form);
refresh();
int ch;
while((ch=getch()) != 0xA)
{
form_driver(form, ch);
}
unpost_form(form);
free_form(form);
free_field(field[0]);
delete [] field;
}
Mein Problem: sobald ich diese Funktion aufrufe, verschwindet alles andere vom Bildschirm. Alle Fenster, Menüs und einfacher Text, alles weg.
Auch wenn ich wrefresh(...) mit allen Fenstern aufrufe, erscheinen sie nicht mehr, erst wenn die Funktion wieder verlassen wird.
Warum das?
Ich bin ein ziemlicher ncurses Anfänger, beschäftige mich erst seit gestern damit. Also bitte nicht schlagen
Hallo liebe C++-Gemeinde,
ich bin auf der Suche nach jemanden, der mir bei der Programmierung einer Client - Server Anwendung unter Verwendung von Internet Stream Sockets ein bischen auf die Sprünge helft.
Falls jemand eine Ahnung davon hat, kann er sich ja per pm mit mir in Verbindung setzen, dann folgen nähere Infos!
PS: Ich werde den Zeitaufwand schon honorieren:)
Jap, würde man. Deshalb werden plattformunabhängige Binärformate auch so spezifiziert, dass die Ablagereihenfolge der Bytes festgelegt ist. Meist ist das die "natürliche" Ablage, sprich Big Endian.
Ich würde solche Formate auch nicht (mehr ) über Strukturen legen, sondern byteweise parsen und die jeweiligen Bits eines Wertes in eine Zielvariable schubsen. Da geht bei Konstrukten wie (byte3 << | byte4 auch die Ausrichtung nicht flöten.
btw... ich weiß nicht, warum des alles Multithreaded sein soll, ich mein, eventuell ist des zu verstehen, wenn man GUI programmiert und so, aber im Allgmeinen kann man auch ein select() oder ein nicht blockierendes select(), das alle halbe sekunde mal aufgerufen wird, reinimplementieren, weiß nicht, wo da das Problem ist, finde in dem Fall so riesig viele Threads zu bauen kostet mehr (an Implementierungsarbeit), als es bringt. Man könnte das ganze allerdings auch über Pools erledigen, die Möglichkeit halte ich für sehr schön. Allerdings muss man halt auch alles wengl mischen, so nen Pool, ne Liste an Aufgaben (Nachrichten, etc),...
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Linux/Unix verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?
Dieses Posting wurde automatisch erzeugt.