Tut für Socket/Window

[tiris]

Hi,
ich hab vor ein kleines frontend (oder so ähnlich) für meinen Linuxserver zu bauen. Sollte unter Windoof laufen, wäre klasse wenn man es einfach portierten könnte.

Mein Problem:
--> Tut für Socketprogrammierung (Netzwerkverbindung zum Server)
--> Tut für Fenster/Grafikprogrammierung (Textkonsole kann ich auch gleich per ssh haben)

Hat jemand was?
Ich bisher nur entweder sauteure oder absolut sinnlose Bücher gesehen die erklären dass ich mit VC von M$ für 1.000.000 U$ schöne Fenster automatisch erstellen und dann beutzen kann. Will ich aber selbst stricken.

Gruß tiris

[peschmae]

da stellt sich die Frage der Programmiersprache:

C/C++/Java/Perl/Python/...

und die des zu verwendenden Toolkits:

Qt/Gtk/Fox/Fltk/Swing/SWT/WxWindows/...

du musst halt schon ein bisschen konkreter werden. Oder hast du noch keine Ahnung?

MfG Peschmä

[tiris]

C wäre voll cool weil ich da an der Kommandozeile (Also einfach Programme die keine graphische Ausgabe erfordern) schon recht fit bin.
Mit c++ könnte ich mich auch anfreunden, aber dann muss auch noch was dabei sein dass das Klassenkonzept erläutert.

Toolkit ist mir Wurst. Wenn's ohne ginge, so zu Fuß wäre ich auch zufrieden. Unter Win benutze ich den DEV-cpp von www.bloodshed.net . Mit dem bin ich voll zufrieden bis jetzt. Der kann auch Fenster machen, aber das ist dann auch so 'ne automatische Sache und ich würde es ja gerne selbst machen.

Gruß tiris

[tuxipuxi]

hi,

wenn du gerne das gerne mit C machen möchtest empfehle ich dir Gtk+( http://www.gtk.org ).
das ist das unter unix/linux meistbenutzte C toolkit mit bindings für viele andere sprachen.


gruss,
tuxipuxi.

[Lin728]

Grafische Programme (GUI) mit C zu schreiben ist eher unangenehm.

Objectorientierte Programmierung ist gerade beim erstellen von grafischen Oberflächen was feine

[peschmae]

Ich kann Ceisserer eigentlich nur zustimmen. Am besten informierst du dich mal erst möglichst objektiv über Gtk, Qt und Swing. Eventuell noch WxWindows.

Allerdings würde ich den Unterschied zwischen Konsolenprogrammierung und GUI-Programmierung keineswegs unterschätzen. Vor allem OOP muss erst mal verstanden sein - sonst bringts nichts und du nutzt die Vorteile überhaupt nicht aus.

Auf jeden Fall würde ich neben den "ernsthaften" Programmiersprachen (C, C++, Java) auch die Scriptsprachen - hier vor allem Perl und Python nicht aus den Augen verlieren. Mit diesen kann man oft sehr viel schneller zum (genau gleichen) Ziel kommen - unter Verwendung irgend eines "normalen" Toolkits.

MfG Peschmä

[tiris]

GTK+ scheint für meine Anforderungen ganz geeignet zu sein. Ich hab auch nichts gefunden das die Portabilität einschränken könnte, oder lieg' ich da falsch?

gruß tiris

[peschmae]

Natürlich gibts ne Windows-Version von Gtk. Aber die Portierung dahin ist nicht ganz ohne. Schlussendlich gibts von den wenigsten Gtk-Programmen die ich kenne Windows-Portierungen (z.B. Gimp, Gaim)

Mit Gtk hast du dich aber noch nicht für eine Programmiersprache enschieden. Gtk selber ist in C geschrieben, das aber um Objektiorientierung erweitert wurde. Zudem gibts noch Bindings für C++, Python, Perl, C#, Java,...

MfG Peschmä

[anda_skoa]

Ich denk am einfachsten ist es in Java.

Sonst musst du dir entweder ein Toolkit suchen, das auch Sockets Crossplatform hat, oder umständlich den Socketcode auf jeder Plattform anpassen.

Ciao,
_

[Lin728]

anda_skoa hat (wiedermal) recht: Am einfachsten gehts wohl mit java...

Bei den Scripsprachen hast du das Problem dass bindings für die entsprechende Sprache installiert sein müssen....

[tiris]

Also ich kenne ja den Unterschied zwischen normalen und Skriptsprachen. Die einen arbeiten wie Pascal oder eben Java einen Quelltext Schritt für Schritt ab, der muss dann aber nicht kompiliert werden. -->läuft langsamer, aber ist mit Laufzeitumgebung auf jeder unterstützen Plattform lauffähig.
Die anderen können nur im kompilierten Zustand ausgeführt werden. --> läuft schneller, aber nur auf der kompilierten Plattform.

Da aber auch Java einen kleinen Compiler (und Linker und so, ich weiß, aber ich will nicht alles aufzählen) an Board hat kann ich die Sachen doch nach dem Linken und dem Präkompilieren als Maschinencode in den Compiler von einer C-Umgebung laden und habe dann alle Vorteile die es gibt, oder?

gruß tiris

[Lin728]

Grüssi!

Da aber auch Java einen kleinen Compiler (und Linker und so, ich weiß, aber ich will nicht alles aufzählen) an Board hat kann ich die Sachen doch nach dem Linken und dem Präkompilieren als Maschinencode in den Compiler von einer C-Umgebung laden und habe dann alle Vorteile die es gibt, oder?

Wenn du Java von SUN benutzt, wird Java immer interpretiert (also es wird erst zur Laufzeit in Maschienencode übersetzt).

Bei einer Scripsprache ist der Ablauf folgender:
1.) Quellcode einlesen, Sythax checken und in ein universelles bytecode-format übersetzten.
2.) Universellen bytecode für den jeweiligen Prozessor in Maschienensprache übersetzten. Dies erfolgt Schritt für Schritt und ist daher langsam.

(Ich weiß dass klingt sinnlos, aber Perl und Python machen es genau so)

Bei Java findet 1.) im Java-Compilier statt und die Runtime übernimmt den 2. Teil.
Da dies aber zu langsam war, hat man sich eine Menge an Optimierungsmethoden einfallen lassen, somit ist Java zur schnellsten interpretierten Sprache geworden die es gibt (auch wenn .NET schön langsam aufhohlt). Der neue HotSpot-JIT (just in tmie compilier = zur laufzeit compilier) merkt sich jene stellen, die besonders oft durchlaufen werden und führt z.b. nur auf diesen aggressive Optimierungen aus, die sich Stellen die nur ein paar mal aufgerufen werden nicht auszahlen.
Teilweise ist HotSpot sogar schneller als C, aber das sind eher Ausnahmefälle.

Java ist aus zwei Gründen langsamer als C++:
1.) Es übernimmt sehr viele Aufgaben des Programmierers, wie z.B. Arraybereichs-Überprüfungen und Speichermanagement, und das kostet natürlich zeit.
2.) Es ist trotz der vielen Optimierungen noch immer eine mehr oder weniger interpretierte Sprache.

Einen precompiler gibts in java überhaupt gar nicht, sowas machen eigene Tools wenn mans unbedingt braucht.
Auch einen Linker in dem Sinn wie bei nativen Sprachen gibts eigentlich nicht, dass erledigt die Runtime zur Laufzeit.

Aber Java ist bis auf SWING (was angeblich in Java-1.5 viel besser werden soll (OpenGL, neues Metal-Theme)) eine wirklich runde Sache, schade ist nur, dass es nicht OpenSource ist was natürlich immer Risiken in sich birgt.

[tiris]

Keine Möglichkeit den Maschinencode beim Ausführen abzugreifen und dann anständig zu compilieren?

Schade.

Aber ansonsten denke ich ist Java dann doch ganz nett.

gruß tiris

[peschmae]

Nein.

Allerdings gibt es schon native Compiler für Java. Die sind aber nicht sehr weit verbreitet.

Beispiele sind:
gcj (teil von gcc): http://gcc.gnu.org/java als freie Software

GCJ hat allerdings nicht die komplette Klassenbibliothek von Java implementiert. SWT funktioniert. Swing fehlt und AWT ist auch noch nicht fertig.

und dann jede Menge kommerzielle:
http://www.excelsior-usa.com/jet.html - für Win, komplette Klassenbilbiothek

und dann gibts noch jede Menge anderer. Wie gross da dann der Performancegewinn ist und so ist aber auf einem anderen Blatt geschrieben.

MfG Peschmä

[tiris]

Ich denke ich benutze dann mal Java. hat einer einen guten Literaturtipp zu Java, weil da muss ich mich dann doch mehr reinarbeiten als bei C/C++. So ein Buch dass einem da verschiedene Kleinigkeiten erklärt und Nebenbei noch OOP vermittelt wäre ganz nett.

Tipps zur IDE?
Oder lieber ohne?

Gruß tiris