Hallo Leute.
Ich will für meine Gemeinde ein Programm schreiben!
Ich habe folgendes Problemm:
Ich kenne C/C++ (wxWidget) und Java (Eclipse) und bin ein begeisterter
Linux User.
Ich habe schon einige Programme in beiden Sparachen programmiert. Ich
kann mich gar nicht entscheiden bei welcher Sprache ich bei der
Programmierung von Programmen bleiben soll? Ich kenne Ihre Vorteile und
Nachteile! Aber ich kann mich einfach nicht entscheiden.
Hat da jemand, dass auch durchgemacht. Oder habt Ihr euch gleich
entschieden?
Wie habt Ihr euch entschieden und warum???
Gruss stefan
also ich kenne/kann auch beide sprachen, es kommt drauf an was du machen
willst. also wenn du ein open source projekt machen willst, was auch
zukunft haben soll dann verwende c/c++, das kann jeder aus der
opensource gemeinde. wenn du allerdings mit dem ganzen javaoverhead
leben kannst dann benutze java und freu dich auf die ständigen
javaerweiterungen die in der opensource szene nicht ganz so gut ankommen
Für richtige Programme ist c++ die 1. Wahl.
Wenn du das erst mal richtig drauf hast, kannst du auf das Programmieren
mit Hilfskrücken wie Java und VB verzichten.
Programmiersprachen wie Java und VB wurden nur erfunden um die vielen
Kidis
ein Spielzeug für das Freizeitcoden in die Hand zu geben .
So wird verhindert da die jemals richtig programmieren lernen oder
vielleicht noch zu echter Marktkonkurrenz heranwachsen.
So bleiben die Dumm-Flaschen alle bei VB und Java weil es so schön
einfach ist. Und das ist auch gut so.
In diesem Sinne von mir ein großes Dankeschön an die Entwickler von Java
und VB.
Gruß der C++Profi
>Für richtige Programme ist c++ die 1. Wahl.
Und für gute Programme ist Java die 1. Wahl. Professionelle
Java-Programme arbeiten zigmal effizienter als C++. So bleiben die
Dumm-Bratzen alle bei C++, weil sie nicht über ihren Tellerrand blicken
können und meinen, ihre begrenzten Fähigkeiten wären das Maß der Dinge.
Hallo
Würde für eine PC-Anwendung eher zu Java tendieren. Ist einfacher,
sicherer und vorallem plattformunabhängiger als C++. Natürlich durch
VM-Overhead etwas langsamer, aber das letzte bisschen Performance spielt
in der Welt der Desktop-Rechner seit mindestens 5 Jahren keine Rolle
mehr. Ob eine Anwendung nun eine oder zwei Sekunden zum starten braucht,
stört kein Mensch. Und mehr kann man auch kaum herausholen.
> Programmiersprachen wie Java und VB wurden nur erfunden um die vielen> Kidis ein Spielzeug für das Freizeitcoden in die Hand zu geben .
Eine richtig dumme Aussage!
Gruss
Michael
Das ist ja wohl der größte Schwachsinn den ich jemals gehört habe.
Ich denke C++ und Java sind vom Schwierigkeitsgrad her etwa
vergleichbar, ich programmiere sowohl C wie auch Java, allerdings geht
das programmieren mit Java teilweise schneller und efizienter, das fängt
schon bei der API an. Java- Programme sind plattformunabhängig ich kann
sie unter Linux entwickeln und weiß, dass sie unter Windows laufen.
In der Opensource- Gemeinde erscheinen immer mehr Java- Projekte und
warum? Weil Java die Zukunft ist, die Prozessoren werden immer
Leistungsfähiger da kommt es auf den minimalen Unterschied, dass die
Sprache "nur" interpretiert ist nicht an. Das einzige Problem von Java
ist, dass es nicht von Microsoft ist, denn dann wäre der Verbreitunsgrad
deutlich höher, allerdings wäre es dann nicht mehr plattformunabhängig.
So ist es doch gut, dass es von Sun ist, und Java ist gewissermaßen eine
Weiterentwicklung von C++.
"So ist es doch gut, dass es von Sun ist, und Java ist gewissermaßen
eine
Weiterentwicklung von C++."
Auha,das tut auch weh.
Für dich Java auch das Beste. Keine Frage
und sich als "profi" zu bezeichnen definiert genauso ein kiddi @
"c++profi"
vielleicht solltet ihr, die ihr so auf "die eine programmiersprache"
schwört, mal bischen offener für andere sachen sein.
es gibt keine sprache, die in jeder hinsicht perfekt ist. sonst gäbe es
ja nurnoch die eine. jede sprache hat ihre vor und nachteile, ihre
anhänger und ihre abneiger. nur im gegensatz zu euch beiden sind normale
programmierer tolleranter gegenüber sprachen, die eben nicht zu den
persönlichen favorieren zählen
>vielleicht solltet ihr, die ihr so auf "die eine programmiersprache">schwört, mal bischen offener für andere sachen sein.
Und das ist der allergrößte Blödsinn. Wenn ich für andere sachen offen
wäre, könnte ich nicht der Profi sein, der ich bin.
Ist native Java im Original einmal ähnlich lahm wie C oder C++, dann
kostet es mich einen minimalen Mehraufwand, für entsprechenden
Codeblöcke die VM mit Assemblerbefehlen zu überladen unter Ausnutzung
von Multicores und MPI Parallelisierung.
"Ist native Java im Original einmal ähnlich lahm wie C oder C++, dann
kostet es mich einen minimalen Mehraufwand, für entsprechenden
Codeblöcke die VM mit Assemblerbefehlen zu überladen unter Ausnutzung
von Multicores und MPI Parallelisierung."
Ach komm, erzähl doch net so viel Schlaukram.
Das ist eh Blödsinn.
Java mit Assemblercode-Blöcken , ist doch blöder Krampf.
Wer programmiert denn so dämlich.
>Java mit Assemblercode-Blöcken , ist doch blöder Krampf.
Schon mal gemacht? Nein. Assembler ist unter Java nämlich dank OOP und
Plattformunabhängigkeit super einfach, schnell und übersichtlich.
>Wer programmiert denn so dämlich.
Scheint, du wärst glücklicher, wenn du wüßstest, wie du deinem C++ mit
Assembler auf die Sprünge helfen kannst. Aber das ist halt nicht so eine
einfache Spielerei wie das restliche C++.
> vielleicht solltet ihr, die ihr so auf "die eine programmiersprache"> schwört, mal bischen offener für andere sachen sein.
So sehe ich das auch! Ob gut oder schlecht, auf jedenfall ist es
Tatsache: Es gibt praktisch für jeden Zweck eine andere
Programmiersprache. Heutzutage gibt es für fast alles bereits so
leistungsfähige Lösungen, dass sich die Entwicklung eigener Software als
völlig überflüssig erweist. Wichtig ist es heute, solche Lösungen zu
können und effizient zu verknüpfen, das macht einen guten Entwickler
aus. (siehe Content-Management-Konzepte im Internet oder
Datenbankanwendungen) Wer meint, er müsse alles in nativem Code
erledigen, weil es eben schnell ist, der sitzt auf dem falschen Pferd.
Wobei auch hier gilt: Gesunder Menschenverstand anwenden! Games,
Embedded-Systeme, kritische Serveranwendungen, rechenaufwändige
wissenschaftliche Anwendungen oder Kerne von leistungsfähigen/-hungrigen
Anwendungen brauchen natürlich effizienten, nativen Code.
2 Gründe, warum Java schneller sein kann als C++:
-Dynamische Optimierungen in Verbindung mit dem Just-in-time-compiler
-Threadsupport schon in die Sprache integriert
Hi
> Ich denke C++ und Java sind vom Schwierigkeitsgrad her etwa> vergleichbar
???
Java ist deutlich einfacher (im positiven wie im negativen) als C++. C++
ist wohl die Programmiersprachesprache die dem Anwender die meisten
Freiheiten (Mehrfachvererbung, eigenes Speichermanagment,
Operatorüberladung um ein paar Beispiele zu nennen) bietet. Auch der
Templatemechanismus ist wohl in keiner anderen Sprache derart
vielseitig. Das kann aber auch zu beinahe unlesbarem Code führen
(Operatorenüberladung kann zu ulkigen Verwirrungsmanövern führen :-)
Matthias
C# ist fast perfekt ausser dass es von MS kommt.
D könnte sich innerhalb von ein paar Jahren auch durchsetzen
Aktuell würde ich sagen:
Einfache Anwendungsprogramme in Java
aufwendige, leistungshungrige Software (meist trifft das nur auf diverse
Spiele zu) in C++
Wenn die Beschränkung auf Windoof reicht (stimmt nicht ganz, soll wohl
auch unter andere BS compilieren gehen aber KA wie Zukunftssicher oder
nicht): C#
Und wer in die Zukunft sehen will: D
Zitat
"leistungsfähig sind sie Allesamt ... nur eben nicht laut manchen etwas
beschränkten, festgefahrenen C++Programmierern"
So reden nur die Hobbytoolbastler die noch nie richtig programmiert
haben.
Aber gehe mal zu dem Firmen die in der Anwendungsentwicklung tätig sind
.
zu 95% ist dort C++ angesagt.
Der Traum einer einfachen und zugleich professionell einsetzbare
Programmiersprache bleibt eh ein Traum
Wenn man Hardwarenahe programmieren will ,Muss man nun mal vieles von
Hand einstellen.
Z.B. wird die ganze Spiele-Entwicklung innerhalb der nächste 10 Jahre
mit c++ geschehen
C# ist leider kein Ersatz.
Die Anforderungen an leistungsfähige Anwendungen steigen mit den
Konkurrenzdruck immer weiter . Das muss das Maximum aus der Hardware
herausgekitzelt werden.
Das geht nur mit Assembler und C++. C++ ist zwar schon auf einer
höheren abstraktionsebene aber immer noch ausreichend Hardwarenahe.
C# ist zwar in der Entwicklungsperformance besser aber das war es auch
dann schon.
Vom java und co brauchen wir nicht zureden das wird sich niemals in der
professionellen Entwicklung so wie c++ etablieren können.
OK, sagen wir mal die Wahrheit: Die produktivste, professionellste und
beste Sprache ist Smalltalk. Leider hat sie sich nicht durchgesetzt.
Und Java ist längst in der professionellen Entwicklung angekommen, aber
VC-Profi will wahrscheinlich nur Trollen.
> C# ist zwar in der Entwicklungsperformance besser aber das war> es auch dann schon.
Aktueller Fall:
Ein C# Programm. Beobachtet man das Working Set, so sieht man
das der Speicherverbrauch steigt und steigt und steigt.
Bis dann irgendwann die Gigabytes aufgebraucht sind. .NET
legt dann eine Denkpause ein und meldet: Out of memory.
So und jetzt such mal schön.
Da lob ich mir C++. RAII und die Speicherverwaltung ist kein
Thema mehr.
Also ich hab die Erfahrung gemacht, dass alle Programmierer, die C++ so
sehr loben, einfach wenig Ahnung vom Programmieren haben. Jeder sollte
sich die Frage stellen, worauf es eigentlich ankommt. Heutzutage ist es
nach meiner Meinung weniger die Effizienz, weil die Prozessoren so
schnell sind, dass es in den meisten Fällen nicht mehr auf gesparte
Millisekunden ankommt.
Für mich ist folgendes bei einer Programmiersprache wichtig:
1. unterstützt den Programmierer so gut wie möglich beim Schreiben von
fehlerfreien Programmen
2. unterstützt den Programmierer so gut wie möglich beim Schreiben von
lesbaren Programmen
3. unterstützt den Programmierer so gut wie möglich beim Schreiben von
stabilen Programmen
4. unterstützt den Programmierer so gut wie möglich bei der Fehlersuche
Die Punkte erfüllen C# und Java eindeutig besser als C++. In C++ gibt es
einfach zu viele Fallstricke. Man muss immer verdammt genau wissen, was
der Compiler in der jeweiligen Situation macht. (z.B. Kopie oder
Referenz? Da gibts maximal ne Warnung oder einen schönen schwer zu
findenden Absturz; vergessenes public bei der Vererbung -> Exception
wird nicht gefangen, destructor nicht virtuell -> Speicherleck, usw.)
Und die meisten C++ Programmierer wissen es eben nicht!
Es gibt wenig Schlüsselwörter in C++, dadurch wird die Sprache schlank,
aber nicht besser. (sowas wie interface oder abstract und vor allem
override fehlt eindeutig)
Und was bei C++ vor allem fehlt ist der garbage collector. Wenn man
Programme schreiben will, die keine Speicherlecks haben und länger als
1h stabil laufen sollen, dann muss man den shared_ptr aus der boost
Bibliothek verwenden. (Wer das nicht macht zählt bei mir als Metzger,
aber nicht als ordentlicher C++ Programmierer.) Im Vergleich zu C# oder
Java ist das aber viel mehr Aufwand als eigentlich nötig.
Was mich bei C++ auch stört sind solche Sachen:
int a[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
volatile int b = 8[a];
Enthält die 2. Zeile einen Fehler? Nein! Welcher Depp dachte sich da,
dass es ne gute Idee sein würde, sowas in C++ zuzulassen?
weitere Defizite bei C++:
- Die Sache mit den .h und .cpp files ist natürlich auch einfach nur
nervig.
- Die Compilierzeiten bei C++ sind unter aller Sau.
- Refactoring geht nur mit extra Tools, die man natürlich auch bezahlen
muss.
- Keine Unterstützung für Threads in der Sprache.
- Keine Möglichkeit, double als Konstante in der Klassendeklaration im
Header File mit einem Wert zu belegen.
- Exceptions sind nicht von einer gemeinsamen Basisklasse abgeleitet und
jede sch... Bibliothek schreib ihre eigene nicht von std::exception
abgeleitete Exception.
- struct ist als Klasse mit allem als public definiert, was schreibfaule
programmierer gern ausnutzen
...
Heul doch.
Es gibt glücklicherweise Leute, die das anders sehen als Du, nämlich
Leute, die verstanden haben, warum bestimmte Dinge so sind wie sie sind.
Wer Headerdateien nur nervig findet, hat offensichtlich nicht kapiert,
wie ein Compiler und ein Linker arbeitet.
Möchtest Du etwa bei der Verwendung von Libraries immer deren
kompletten Sourcecode mit Dir herumschleppen?
Die Trennung von Deklaration und Definition ist eine sehr wichtige
Errungenschaft von C/C++.
Die Compilierzeiten sind unter aller Sau?
Nur, wenn man nicht in der Lage ist, sein Projekt anständig zu
strukturieren. Dann werden nur noch die Sourcefiles neu übersetzt, in
denen sich was verändert hat. Nein, man packt nicht alle Definitionen in
eine Headerdatei ... (s.o.: nichtverstehen, was eine Headerdatei ist)
Und der Scheiss-Garbage-Collector fehlt nicht. Wem der fehlt, der soll
einfach die Finger von C/C++ lassen und bei seinem poofigen
Java/C#/Kindergartengeraffel bleiben.
Da gibt es dann schicke Schlipsträgermagazine für ...
> Also ich hab die Erfahrung gemacht, dass alle Programmierer, die C++ so> sehr loben, einfach wenig Ahnung vom Programmieren haben. Jeder sollte> sich die Frage stellen, worauf es eigentlich ankommt.
Ich hab die Erfahrung gemacht, daß es nicht immer von Vorteil für die
Stabilität von Programmen ist, wenn das Programmieren zu sehr
erleichtert wird. Früher konnten halt nur Leute, die wirklich Ahnung
hatten, lauffähige Programme schreiben. Heute, mit Java und .Net kann
selbst die Putzfrau nach einem 1-wöchigen Kurs sich ein Programm
zusammenklicken (nichts gegen Reinigungsfachkräfte). Die Codequalität
ist allerdings dann auch dementsprechend.
Um Mißverständnissen vorzubeugen: Ich will damit nicht sagen, daß jeder
C- oder C++-Programmierer wirklich Ahnung hätte oder jeder Java- oder
.NET-Programmierer nicht, sondern nur, daß es für jemanden mit praktisch
keiner Ahnung vom Programmieren, heute viel leichter ist, sich als
"Programmierer" zu betätigen.
Bri wrote:
> Also ich hab die Erfahrung gemacht, dass alle Programmierer, die C++ so> sehr loben, einfach wenig Ahnung vom Programmieren haben.
Komisch.
Ich hab die gegenteilige Erfahrung. Mit die besten Programmierer
dieser Erde benutzen regelmäßig C++. Und haben keinerlei
Probleme damit.
> Jeder sollte> sich die Frage stellen, worauf es eigentlich ankommt. Heutzutage ist es> nach meiner Meinung weniger die Effizienz, weil die Prozessoren so> schnell sind, dass es in den meisten Fällen nicht mehr auf gesparte> Millisekunden ankommt.
Da geb ich dir recht.
>> Für mich ist folgendes bei einer Programmiersprache wichtig:>> 1. unterstützt den Programmierer so gut wie möglich beim Schreiben von> fehlerfreien Programmen
Inwiefern ist C# oder Java da besser?
>> 2. unterstützt den Programmierer so gut wie möglich beim Schreiben von> lesbaren Programmen
Auch da: eigentlich kein Unterschied.
>> 3. unterstützt den Programmierer so gut wie möglich beim Schreiben von> stabilen Programmen
Eben. C++ Programme sind unglaublich stabil.
Als ich Java das erste mal ausprobieren wollte hab ich mir
3 Programme downgeloadet. Alle 3 gestartet und bei allen
3 kam nach ein paar Sekunden: null pointer exception.
Das finde ich besonders pikant, wo es doch angeblich keine
Pointer gibt.
>> 4. unterstützt den Programmierer so gut wie möglich bei der Fehlersuche
Das ist keine Eigenschaft einer Sprache sondern im wesentlichen
eine Frage des Debuggers.
>> Die Punkte erfüllen C# und Java eindeutig besser als C++. In C++ gibt es> einfach zu viele Fallstricke. Man muss immer verdammt genau wissen, was> der Compiler in der jeweiligen Situation macht.
Muss man nicht. Wozu auch. Es sind ja die Objekte die eine
Funktionaltät einbringen. Wie der Compiler das umsetzt
ist sein Bier.
> (z.B. Kopie oder Referenz? Da gibts maximal ne Warnung oder einen> schönen schwer zu findenden Absturz;
Inwiefern soll es da einen Absturz geben?
> vergessenes public bei der Vererbung -> Exception> wird nicht gefangen, destructor nicht virtuell -> Speicherleck, usw.)
OK.
> Und die meisten C++ Programmierer wissen es eben nicht!
Da hast du allerdings recht. Das ist tatsächlich ein
Problem: Fehlende Kenntnisse der Programmierer über ihr
Werkzeug.
>> Es gibt wenig Schlüsselwörter in C++, dadurch wird die Sprache schlank,> aber nicht besser. (sowas wie interface oder abstract und vor allem> override fehlt eindeutig)
interface und abstract vermisse ich überhaupt nicht.
override würde ich mir allerdings wirklich wünschen.
>> Und was bei C++ vor allem fehlt ist der garbage collector.
Den vermissen die meisten C++ Programmierer überhaupt nicht.
Wir haben lieber einen definierten Destruktoraufruf, den man
wunderbar für ein RAII Idiom einsetzen kann, anstatt darauf
zu hoffen, dass der Benutzer einer Klasse schon nicht
darauf vergessen wird ein Dispose() aufzurufen.
> Wenn man> Programme schreiben will, die keine Speicherlecks haben und länger als> 1h stabil laufen sollen, dann muss man den shared_ptr aus der boost> Bibliothek verwenden.
Die kann man benutzen. Ist auch eine gute Idee die zu benutzen
und in der nächsten Version vom C++ Standard werden sie auch
in den Rang einer Standard C++ Komponente aufgenommen.
So what?
> (Wer das nicht macht zählt bei mir als Metzger,> aber nicht als ordentlicher C++ Programmierer.) Im Vergleich zu C# oder> Java ist das aber viel mehr Aufwand als eigentlich nötig.
Dafür habe ich eine definierte Speicherverwaltung in der
ich steuern kann wann was passiert. Ich hatte hier schon den
Fall, dass ein C# Programm immer mehr Speicher zieht.
Und jetzt find mal das schuldige Objekt, dass verhindert
das der GC alles auflöst.
>> Was mich bei C++ auch stört sind solche Sachen:>> int a[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };> volatile int b = 8[a];>> Enthält die 2. Zeile einen Fehler? Nein! Welcher Depp dachte sich da,> dass es ne gute Idee sein würde, sowas in C++ zuzulassen?
Ist gewöhnungsbedürftig, ist aber ein Überbleibsel aus C.
Und dort war es ein Nebeneffekt der Definition wie der
Zusammenhang von Arrays und Pointern ist.
>> weitere Defizite bei C++:>> - Die Sache mit den .h und .cpp files ist natürlich auch einfach nur> nervig.
Keineswegs.
>> - Die Compilierzeiten bei C++ sind unter aller Sau.
Erstens kannst du das nicht C++ anhängen. Zweitens ist
mein C++ Kompiler um einiges schneller als der C#
Compiler.
>> - Refactoring geht nur mit extra Tools, die man natürlich auch bezahlen> muss.
Du verwechselst die Sprache mit der Implementierung bzw.
dem was die die IDE zur Verfügung stellt.
>> - Keine Unterstützung für Threads in der Sprache.
Kommt in der oder einer der nächsten Versionen.
Wenn ich mir allerdings so anschaue wie naiv gerade
Neulinge mit Threads umgehen ist das gar nicht so schlecht
dass es Threads in C++ noch nicht gibt.
>> - Keine Möglichkeit, double als Konstante in der Klassendeklaration im> Header File mit einem Wert zu belegen.
Ist richtig. Allerdings auch nicht das Mega-Problem
>> - Exceptions sind nicht von einer gemeinsamen Basisklasse abgeleitet und> jede sch... Bibliothek schreib ihre eigene nicht von std::exception> abgeleitete Exception.
Das ist ja wohl eher mehr ein Problem der Disziplin der Programmierer
als der Sprache an sich.
>> - struct ist als Klasse mit allem als public definiert, was schreibfaule> programmierer gern ausnutzen
Ebenfalls: Keine Sprache der Welt kann Disziplin bei der
Programmierung ersetzen.
Damit hier kein falscher Eindruck entsteht.
Ich bin keineswegs so vermessen zusagen, dass C++ das
beste seit geschnittenem Brot ist. Wer C# oder Java lieber
mag, der soll das verwenden. Aber zu sagen C++ ist Scheisse
ist weit am Ziel vorbei geschossen. Das ist es nämlich ganz
und gar nicht.
> Wir haben lieber einen definierten Destruktoraufruf, den man> wunderbar für ein RAII Idiom einsetzen kann, anstatt darauf> zu hoffen, dass der Benutzer einer Klasse schon nicht> darauf vergessen wird ein Dispose() aufzurufen.
Das ist ein interessanter Punkt. Während in Java zwar den Speicher
automatisch für mich verwaltet wird, muß ich alle anderen Ressourcen
immer selbst verwalten. In C++ kann ich dank Destruktoren und RAII genau
diese Ressourcen automatisiert verwalten. Ich muß mich bei einer Datei
nicht explizit darum kümmern, daß sie immer (z.B. auch beim Auftreten
einer Exception) geschlossen wird. Das passiert ganz automatisch.
> Wer Headerdateien nur nervig findet, hat offensichtlich nicht kapiert,> wie ein Compiler und ein Linker arbeitet.
Headerdateien enthalten mit Quelldateien redundante Informationen und
man muss zwei Stellen manuell synchron halten. Wenn das nicht bekloppt
ist ;-)
'N Linker kann auch so funktionieren ohne das diese Information von
einem Menschen getrennt werden muss.
> Möchtest Du etwa bei der Verwendung von Libraries immer deren> kompletten Sourcecode mit Dir herumschleppen?
Das es da andere Lösungen gibt, sieht der, der über den Tellerrand
blickt.
> Die Trennung von Deklaration und Definition ist eine sehr wichtige> Errungenschaft von C/C++.
Die Trennung für den Linker ist Blödsinn und das Argument, in
Headerdateien schneller einen Überblick zu erlangen zählt dank
automatischer Quelltextdokumentationswerkzeuge auch nicht.
> Und der Scheiss-Garbage-Collector fehlt nicht. Wem der fehlt, der soll> einfach die Finger von C/C++ lassen und bei seinem poofigen> Java/C#/Kindergartengeraffel bleiben.
Tausendfach auch in "Profi"-Software zu bewundern. Speicherlecks sind
was tolles...
> Früher konnten halt nur Leute, die wirklich Ahnung hatten, lauffähige> Programme schreiben.
Und Speicherlecks waren dennoch drinn. Will nicht heißen das bisherige
GC der Weisheit letzter Schluss sind, aber doch ein Schritt in die
richtige Richtung! Lass den Computer doch selber aufpassen, verdammt,
dazu sind sie da ;-)
> ... sondern nur, daß es für jemanden mit praktisch> keiner Ahnung vom Programmieren, heute viel leichter ist, sich als> "Programmierer" zu betätigen.
"Programmieren" ist ja mehr als Code hacken und Dinge klicken?!
Karl heinz Buchegger wrote:
>> - Exceptions sind nicht von einer gemeinsamen Basisklasse abgeleitet und>> jede sch... Bibliothek schreib ihre eigene nicht von std::exception>> abgeleitete Exception.>> Das ist ja wohl eher mehr ein Problem der Disziplin der Programmierer> als der Sprache an sich.
Köstlich :)
"Disziplin der Programmierer", der ist gut... Wenn mach mal schnell
funktioniert, dann wir mal schnell gemacht. Disziplin muss die
Programmiersprache schon erzwingen.
Man braucht sich ja nur mal "Codingstyles" für C++ ansehen. Das sind
meist hunderte von Punkten und die meisten dienen dazu Fallstricke zu
umgehen.
Was den Rest betrifft, so muss man schon zugestehen, dass du wie meist
Recht hast.
> Aktueller Fall:> Ein C# Programm. Beobachtet man das Working Set, so sieht man> das der Speicherverbrauch steigt und steigt und steigt.> Bis dann irgendwann die Gigabytes aufgebraucht sind. .NET> legt dann eine Denkpause ein und meldet: Out of memory.
Wenn eine GC vorhanden ist, heißt das noch lange nicht, dass jeder damit
umgehen kann, egal ob Java, C#, Smalltalk, Eiffel etc.
> OK, sagen wir mal die Wahrheit: Die produktivste, professionellste und> beste Sprache ist Smalltalk. Leider hat sie sich nicht durchgesetzt.
Noch gibt es einige wirklich professionelle Umgebungen (kleine Auswahl)
Dolphin Smalltalk (Interpreter, freie Community-Edition, nur Windows)
http://object-arts.com/content/navigation/home.html
Smalltalk/X (JIT + Compiler, Inline C, freie Version, unterstützt so gut
wie alle wichtigen Plattformen)
http://www.exept.de/exept/deutsch/Smalltalk/frame_uebersicht.html
Smalltalk MT (Compiler, nur Windows)
http://www.objectconnect.com/products.htm
Cincom Visualworks (Cross-platform) oder ObjectStudio (Windows)
http://www.cincomsmalltalk.com/userblogs/cincom/blogView
Wer sich mal ansehen will was mit WPF bzw. Flash und Smalltalk/Lisp
möglich ist (mehr oder weniger experimentell)
Vista Smalltalk
http://vistasmalltalk.wordpress.com/http://vistascript.net/vistascript/flex/vst.swf
@Rolf Magnus
Bei C# gibt es einen Ersatz für RAII, nämlich einen using Block.
@Karl Heinz
Das Problem ist eben, die meisten C++ Programmierer denken, sie hätten
alles richtig verstanden. Wir können ja mal einen Test machen. Wir
stellen dir ein paar Fragen zu C++ und du musst sie ohne bei google oder
im Standard nachzuschauen beantworten.
Wieso ohne Nachschauen? Ein Professor hat (übrigens ironischerweise in
der Java-Vorlesung) zu uns gesagt, man muß nicht alles wissen. Man muß
nur wissen, wo man's nachlesen kann.
> Headerdateien enthalten mit Quelldateien redundante Informationen und> man muss zwei Stellen manuell synchron halten.
Sie trennen das Interface von der Implementierung. Finde ich sinnvoll.
> "Programmieren" ist ja mehr als Code hacken und Dinge klicken?!
Ja, ist es.
Ohne nachschauen deshalb, weil es mir um Fallstricke in C++ geht. Wie
willst du beim Programmieren etwas nachschauen, wenn du nicht mal weißt,
dass es ein Problem sein könnte?
Irgendwie kommen hier immer wieder Kommentare von den "wer schon mal ein
richtig großes Projekt umgesetzt hat" - Spezialisten.
Hallo? Wer, der das nicht hauptberuflich praktiziert wird jemals eins
dieser richtig großen Projekte umsetzten für die man angeblich zwingend
C++ verwenden sollte ?
So ich ich das kenne sind an solchen großen Projekten mehrere
Programmierer Monate oder gar Jahre beschäftigt.
Und sicher verkürzt Java die Lernzeit. Ist doch im Hobby- oder
Semiprofi-Bereich was tolles.
was nicht heissen soll, dass man Java nicht auch professionell einsetzen
kann. Ein Bekannter, Informatiker, der hin und wieder mal einen
Programmierauftrag bekommt, arbeitet, wenn es sich anbietet, auch mit
Java. Zeit ist Geld ...
Hi allerseits,
ich verfolge die Diskussion mit wachsender Begeisterung, demnächst liege
ich laut brüllend vor Lachen unter dem Tisch...
"was nicht heissen soll, dass man Java nicht auch professionell
einsetzen
kann."
@Chris: Hast Du schon mal was von SAP-R3 gehört? Die Bastelklitsch aus
Walldorf setzt großflächig auf Java. Die Mini-Anwendung SAP-GUI ist
komplett damit geschrieben. Kennst Du IBM? WebSphere, Lotus Notes? Alles
kleine Hobby-Anwendungen, ebenfalls Java. Eclipse, NetBeans? Bessere
Texst-Editoren, ebenfalls pure Java. Oracle? Die Dateiverwaltung von
denen hat eine eigene Java-Engine im Kern (für Stored Procedures, super
schnell übrigens), die Admin-Software ist komplett in Java
geschrieben... Es gäbe sicherlich noch mehr kleine Hobby-Anwendungen,
aber da die alle so unbedeutend sind, fallen sie mir jetzt auf die
Schnelle nicht ein. ;-)
Ich bin zugegebenermaßen ein echter Java-Fan, durfte in den letzten 8
Jahren größere Projekte in C++, Java und aktuell in C# machen. Davor
habe ich mich auch schon das eine oder andere Jährchen mit Assembler,
Basic, Pascal, Ada, Fortran und C vergnügt. Alle 3 (OO-)Sprachen haben,
wie bereits mehrfach erwähnt, ihre Vor- und Nachteile. Für mich
persönlich überwiegen die Nachteile von C++, meine Präferenz geht
eindeutig zu modernen Sprachen wie C# oder Java. Bei denen kann ich mich
in erster Linie auf meine Lösung (z.B. auch ein ordentliches
Objektmodell) konzentrieren. Solch automatisierbaren Dinge wie
Speicherverwaltung, liegt das Objekt denn nun auf dem Stack oder im Heap
interessieren mich schlicht und einfach nicht!
Aus dem Alter, in dem ich meinte, nur das, was ich selbst verbrochen
habe, tauge was (Speicherverwaltung, ...), bin ich mittlerweile raus.
;-) Für mich ist es mittlerweile wesentlich wichtiger, eine (auch für
Kollegen) leicht zu verstehende Software zu schreiben. Das fällt mit C++
etwas schwerer, ist aber natürlich nicht unmöglich.
Grüße an alle Java-Hobby-Programmierer, an die C++-Profis natürlich
auch!
Markus
eehm,
darf ich jetzt anfangen und dir aufzählen welche großen Projekte und
Anwendungen mit C/C++ entwickelt wurden ?
Da schlackerst du mit den Ohren.
"Solch automatisierbaren Dinge wie
Speicherverwaltung, liegt das Objekt denn nun auf dem Stack oder im Heap
interessieren mich schlicht und einfach nicht!"
Gerade das ist so eine typisch Anfängerspruch Ich wette du hast von
allen aufgezählten Prorgrammiersprachen gerade mal ein Buch gelesen,
mehr nicht. Richtig programmiert hast du noch nie.
@VC-Profi
Sorry, daß ich Dich entäuschen muß, aber ich verdiene seit 25 Jahren mit
Software-Entwicklung meine Brötchen, alle aufgezählten Sprachen wurden
mehr oder weniger ausgiebig angewendet.
Die (krasse) Aussage "...interessiert micht schlicht und einfach
nicht..." trifft natürlich lediglich auf Java und C# zu.
"Gerade das ist so eine typisch Anfängerspruch Ich wette du hast von
allen aufgezählten Prorgrammiersprachen gerade mal ein Buch gelesen,
mehr nicht. Richtig programmiert hast du noch nie."
Solche Sprüche nennt man übrigens Totschläger-Argumente, sie sind eine
typische Bankrott-Erklärung...
Gruß
Markus
Beeindruckender Schwanzlängenvergleich, den sich hier einige leisten.
"Meiner ist aber länger als Deiner!"
"Meiner ist aber härter!"
"Meiner schöner!"
"Meiner besser!"
"Meiner wohlschmeckender!"
... etc.
"Sorry, daß ich Dich entäuschen muß, aber ich verdiene seit 25 Jahren
mit
Software-Entwicklung meine Brötchen, alle aufgezählten Sprachen wurden
mehr oder weniger ausgiebig angewendet."
Ich schätze weniger ausgiebig?
bestimmt Homepagen basteln oder so etwas.
Du erzählst doch nur , programmiert hast du noch nie.
Hallo zusammen,
ich lese mir gerade fast die komplette Diskussion durch und muss
aufpassen, dass ich nicht gleich anfange laut zu lachen. C++ ist besser
als Java... nein, Java ist besser als C++ und Du hast keine Ahnung...
neee, Du hast keine Ahnung...
Leute, jede Programmiersprache hat ihre Berechtigung. C++ hat mehr
sprachliche Möglichkeiten (Pointer, Mehrfachvererbung etc.), dafür ist
in ihrer Gesamtheit auch schwerer zu lernen und bietet mehr
Stolperfallen als Java. Bei Java wurden diese Stolperfallen bewußt
weggelassen und einige sehr schöne Dinge (GC, Threads etc.)
hinzugenommen. Von den Bibliotheken, die standardmäßig dabei sind und
fast alles abdecken, was man für eine Anwendung braucht, gar nicht erst
zu sprechen.
In C++ wurden und werden große Anwendungen entwickelt, in Java aber
auch. Und die sind, was ihre Komplexität angeht, auch nicht einfacher.
Vor allem J(2)EE, welches für die Entwicklung von
Client/Server-Anwendungen gedacht ist, vereinfacht die Entwicklung
solcher Anwendungen erheblich. Solche Anwendungen sind, wenn sie nach
der J(2)EE-Spezifikation entwickelt wurden, recht portabel (zwischen
verschiedenen App-Servern) und clusterfähig (wenn Skalierbarkeit bzw.
Hochverfügbarkeit gewünscht ist). Zudem lassen sich Dinge wie
Webanbindung (mittels Servlets, JSP, JSF und div. Open Source
Frameworks) oder Web Services (siehe SOA) wirklich einfach realisieren.
Und was die Geschwindigkeit angeht... die meisten J(2)EE-App-Server sind
selbst in Java implementiert und ziemlich fix.
Nicht ohne Grund entwicklen große Konzerne (T-Systems, Postbank,
Dresdner Bank, SAP usw.) einen großen Teil ihrer Software in Java.
Wahrscheinlich merkt man anhand der letzten Sätze, dass ich beruflich
sehr viel mit Java/J2EE zu tun habe und mir einbilde, etwas davon zu
verstehen. Trotzdem würde ich nicht soweit gehen zu sagen, dass C++
schlecht(er) ist. Es ist halt anders.
Ach so, mir fällt gerade ein Spruch von einem sehr guten Entwickler ein,
den ich kenne. Dieser hat vor über 10-15 Jahren ein komplettes
relationales Datenbanksystem samt ODBC-Treiber, vollständiger
SQL-Unterstützung, später auch JDBC-Treiber usw. in C/C++ implementiert
und es über seine Firma auch vertrieben. Inklusive Support und
Bugfixing. Inzwischen entwickelt er in Java J(2)EE-Anwendungen. Jedes
mal, wenn er noch an seine C/C++ Sourcen muss kommt der Spruch: 'Mein
Gott, alles einstampfen und in Java neu entwickeln...'
Ich für meinen Teil bleibe bei Java und deren Features (z. B. GC...
Speicherverwaltung muss ich mir wirklich nicht mehr antun) und
konzentriere mich lieber auf ein gutes Design. Wer C++ einsetzen will,
der soll sein gutes Design in C++ umsetzen. Und wer wirklich reine OO
will: Smalltalk! Ach ja, und wenn eine moderne Sprache gewünscht ist...
C# soll das Beste aus Java und C++ sein. Selbst noch nicht probiert,
aber schon oft gehört ;)
ciao
Christoph
"Stolperfallen als Java. Bei Java wurden diese Stolperfallen bewusst
weggelassen und einige sehr schöne Dinge (GC, Threads etc.)"
Genau, und in C/C++ hat man die Stolperfallen drinnen gelassen.
Ein glück das wir ja sooo schöne Programmiersprachen haben wie Java
haben.
C/C++ ist ja so unvollkommen , sowas Schlechtes aber auch.
Mein Schwager ist gerade dabei seinen Server auf C++ zupohlen. Warum
wohl?
@ VC-Profi
> Genau, und in C/C++ hat man die Stolperfallen drinnen gelassen.
"dafür ist in ihrer Gesamtheit auch schwerer zu lernen und bietet mehr
Stolperfallen als Java"
Mein Satz sagt folgende Dinge aus:
- C++ ist schwerer zu erlernen, da wird mir kaum jemand widersprechen.
Und ich meine hier die Sprachfeatures. Mir ist klar, dass es sehr lange
dauert, bis man die Java-Bibliotheken gut kennt. Aber das gilt auch für
C++-Bibliotheken.
- C++ bietet aufgrund seiner Features mehr Möglichkeiten schwer zu
findende Fehler und Fehlverhalten in Anwendungen einzubauen. Wer sich
schon mal durch komplizierte Pointerarithmetik, überladene Operatoren,
fehlerhaft implementierte Speicherverwaltung usw. hat durchkämpfen
müssen, der wird das auch bestätigen. Und ja, auch in Java kann man wie
in anderen Sprachen auch viel Mist zusammentippen.
>Ein glück das wir ja sooo schöne Programmiersprachen haben wie Java>haben.
Das ist kein Glück, das ist Fortschritt. Und der geht weiter und läßt
irgendwann auch C++ und Java hinter sich. Und Java ist nicht schön,
sondern praktisch, sogar sehr praktisch mit all den Frameworks, Tools
usw.
>C/C++ ist ja so unvollkommen , sowas Schlechtes aber auch.
Hab ich das gesagt? Ich glaub nicht...
Gruss
Christoph
Karl heinz Buchegger wrote:
> Als ich Java das erste mal ausprobieren wollte hab ich mir> 3 Programme downgeloadet. Alle 3 gestartet und bei allen> 3 kam nach ein paar Sekunden: null pointer exception.>> Das finde ich besonders pikant, wo es doch angeblich keine> Pointer gibt.
Das kann aber Java nix dafür...
Und 3 Programme sind doch wirklich kein Maß oder?
Ich hab als ich mit Java mal angefangen hab auch das ein oder andere
"loch" mal gehabt aber weil Leute schlampigen Code veröffentlichen kann
ja die Sprache nix dafür. Und inzwischen hab ich shcon mehrer größere
Programme entwickelt die völlig in Ordnung laufen ohne nach 3sek ne
Exception (welcher Art auch immer! nach oben werfen)
Für nen Nullpointer muß man auch shcon einiges an "nonos" machen, den
der Java Compiler wirft einen Fehler z.B: wenn die gefahr besteht das
ein Objekt nicht initialisiert worden ist z.B:
1
Strings;
2
System.out.println(s);
Führ zu "s might not have been initiated!" (oder so in der Art)
Das kann man übergehen durch:
1
Strings=null;
2
System.out.println(s);
Wenn man aber nun sein programm vortführt und z.B.
1
Strings;
2
System.out.println(s);
3
s.toLowerCase();
macht kommts natürlich zu ner Exception
Zur Exception selber:
-----------
Thrown when an application attempts to use null in a case where an
object is required. These include:
Calling the instance method of a null object.
Accessing or modifying the field of a null object.
Taking the length of null as if it were an array.
Accessing or modifying the slots of null as if it were an array.
Throwing null as if it were a Throwable value.
Applications should throw instances of this class to indicate other
illegal uses of the null object.
----------
Da das nichts nun mal "null" heißt und das Objekt im Momment eine
Referenz auf "null" hat heißt das ganze NullPointerException, vieleicht
hat jemand bei der Benennung zu sehr an C gedacht man hätte es auch
IllegalNullObjektCallOrAccessOrModifyOrLengthOrOtherNullIllegalAccessExc
eption nenen können ;)
Wie auch immer es sit doch egal wies heißt, jeder javaprogrammierer
(sollte) wissen was ihm das sagen soll.
Zum Thema Programmierer:
Einen guten Programmierer macht aus das er die Probleme unabhängig von
der Programmiersprache lösen kann ;)
Und dieses ganze gestreite ist doch echt Sinnlos, solange er nicht sagt
WAS genau kann man eh keine pro/contra angeben.
Einen guten Programmierer macht aus, wer sich gepflegt in einer
Hochsprache ausdrücken kann (c/c++).
Wer die Hochsprache beherrscht muss nicht mit Ersatzkrücken
programmieren.
Es gitb nix was java besser kann als c/c++.
Also wozu die ganze Show?, lerne vernünftig programmieren und gut is.
Ich kann kein Java und hab auch nicht vor das zu erlernen.
Nicht das ich Java "scheisse" finde. Aber wenn man C++ kann, ist es doch
eigentlich sinnlos auf Java umzusteigen?
Was unabhängig von Geschwidigkeit usw. sicher gilt, ist:
Es gibt nicht gerade viele Entwicklungsumgebungen, mit welchen man uC in
Java programmieren könnte(Meist C, BASIC, Pascal od. Assembler).
Wenn also die beiden Sprachen(Java und C++) ja offenbar eh +/-
gleichwertig sind, ist es in Hinblick darauf, dass einem eines Tages die
Hardware interresiert, vielleicht nicht schlecht C++ zu bevorzugen. Wer
Linux interessiert kommt ausserdem nicht um C herum.
Übrigens: Wenn es nur um die Geschwindigkeit des Programms geht, ist so
oder so Assembler angesagt(Regel-, Steuer-, Messtechnik, usw.).
Das wird aber nicht gerade oft der Fall sein und Assembler ist sonst
sicher nicht zu empfehlen(Knapp lesbar:)).
Fazit: Wer sich für HW interessiert sollte sich sicher mit C/C++
beschäftigen. Wer ein Freund von GUI's und PC ist, kann wahrscheinlich
ebenso gut Java nemen.
Zum Schluss: Die Kerne der gängigen OS sind eigentlich alle in C
implementiert. Ich vermute, dass das seine Gründe hat...(Ein OS sollte
doch vor allem schnell und stabil sein, oder?)
Ach übrigens: http://www.leo.org/information/freizeit/fun/pascal.html
(Idiotisch, aber immerhin offensichtlich nicht ernst.)
Hallo!
Nette Diskusion hier, jetzt noch mein Kommentar zu der Geschichte:
Java wurde bei uns in der UNI zum Lernen von Programmierung und
Datenstrukturen verwendet. Seit dem habe ich es aber nicht mehr
verwendet, da mehr ein standalone-EXE Tool User bin und mich immer
freue, wenn ich nichts installieren muss und eine EXE läuft ohne
Abhängigkeiten, VM's oder ähnliches.
Ich habe in einem Projekt vor einem halben Jahr (GUI-RS232-Hardware)
alles in C++ programmiert. FLTK für GUI, ne Bibliothek noch für RS232
und dann alles schön in Klassen verpackt. Programm lief und alles gut.
Jetzt musste aber noch das Ganze in MATLAB und SCILAB eingebunden
werden. Also Klassen hergenommen, in DLL verpackt, fertig.
Trotz Linux-Anfänger, probierte ich auch das Programm für Linux zu
portieren. Die einzigen Probleme die ich hatte waren, dass ich anfangs
keine Berechtigung für die RS232 hatte und sich der sscanf etwas anders
verhielt als unter WIN32. Jetzt kompiliert das Programm unter WIN32 und
Linux ohne irgendwelchen Änderungen am Code.
Wie hätte für diese Aufgabenstellung die Realisierung in JAVA ausgesehen
(ich hätte keinen Plan, ich weiß dass es was für RS232 gibt, aber nur
für Windows, und da habe ich schon von Problemen mitgekrieg (durfte dann
was in C schreiben, dass dann eingebunden wurde)).
Was ich nun daraus folgern möchte ist, dass Java sicher sehr durch die
mitgelieferten fertigen Klassen (z.B. Datenstrukturen) beeindruckt, dir
mir unter C/C++ etwas fehlen. Wegen diesem Gesichtspunkt verwendet ich
eigentlich Delphi am liebsten, da ich sehr viele fertige Klassen habe,
die einfach zu bedienen sind und trotz fehlen des GC die
Speicherorganisation übersichtlich ist.
Das Argument der Plattformunabhängigkeit von JAVA finde ich nicht sehr
ausschlaggebend, denn es ist nur soweit unabhängig, soweit die Klassen
mitgeliefert werden. Wie siehts mit Serial-Port, USB aus? Steuerung der
Maus und Tastatur? Selbst für GUI gibts schon 2 Varianten (AWT und
Swing; glaub ich).
Ich denke der Eindruck, mit C/C++ macht man Sauerreinen, kommt davon,
das man mit C/C++ halt Funktionen versucht zu Implementieren, wo man mit
JAVA and die Grenzen stößt (z.B. Treiberentwicklung). Sicher ist eine
schöne GUI die sich nicht aus der eigenen Anwendung hinaus traut vom
Code übersichtlicher als ein USB-Treiber mit dem DDK.
Aber ich verwende auch sehr gerne Delphi, aus dem selbem Grund, aus dem
auch viele Java verwenden, man kommt für gewisse Anwendungstypen
schneller zum Ziel, da alle Objekte mitgeliefert werden.
das problem an c++ ist u.a. auch, dass es viele C-altlasten mitschleppt,
aber trotzdem viele inkompatibilitäten zu C hat.
schaut euch mal objective-C oder D an. das sind programmiersprachen, die
meiner meinung nach konsequent zu ende gedacht wurden.
beim design von c++ wurde irgendwann mittendrin aufgehört und das
unvollständige produkt auf die menschheit losgelassen.
wäre c++ halbwegs in ordnung, hätte es Java nie gegeben.
"das problem an c++ ist u.a. auch, dass es viele C-altlasten
mitschleppt,"
Schade nur, dass das so Wenige wie du erkannt haben, denn die meisten
Anwendungen werden immer noch mit den Altlasten behafteten
Programmiersprachen C/C++ geschrieben.
Das alte Geruecht "Java=langsam, C++=schnell" ist Unsinn. Wie
leistungsfaehig Java sein kann sehe ich an meinem Handy: Opera Mini ist
100% Java und um ein Vielfaches schneller als der integrierte Browser
(der mit Sicherheit in C(++) programmiert ist).
Der ist jetzt in Java? Die letzte Version, die ich auf meinem Handy
ausprobiert hatte, war kein Java. Und die integrierten Browser kannst du
eh in die Tonne kippen, wenn's nicht grad auch Opera ist.
Ah, hab grad mal auf der Homepage geschaut und gesehen, daß ich damals
nicht etwas Opera Mini, sondern Opera Mobile auf meinem Handy hatte und
das natürlich was ganz was anderes ist.
> "das problem an c++ ist u.a. auch, dass es viele C-altlasten> mitschleppt,"> Schade nur, dass das so Wenige wie du erkannt haben, denn die meisten> Anwendungen werden immer noch mit den Altlasten behafteten> Programmiersprachen C/C++ geschrieben.
naja, das alte C hat durchaus seine berechtigung, etwa im embedded
bereich. dafür ist es sehr gut geeignet und moderne compiler für µC (ich
rede jetzt nicht vom GCC) erzeugen hochoptimierten code. dem werden
sicher viele hier zustimmen.
natürlich werden auch noch viele programme mit C++ programmiert, das
liegt aber oft an der bequemlichkeit der leute, sich mit einer neueren
sprache zu beschäftigen. C++ hat mal einen richtigen 'hype' erlebt, und
viele sind nun mal darauf sitzen geblieben. es gibt z.b. auch heute noch
alte professoren, die ihren studenten fortran beibringen.
ich bin mir sicher, dass C++ in zukunft mehr und mehr an bedeutung
verlieren wird. C++ hat nichts zu bieten, das mit anderen sprachen nicht
einfacher, sicherer oder wirtschaftlicher zu machen ist.
"verlieren wird. C++ hat nichts zu bieten, das mit anderen sprachen
nicht
einfacher, sicherer oder wirtschaftlicher zu machen ist."
Falsch, das fängt bei Systemresourcen schonen an und hört bei der
Performanz ,und Hardwarenahen Programmierung auf.
C/C++ wurde schon vor 10 Jahren von Freunden der einfachen
Idiotensprachen für Tod erklärt. Es lebe C/C++.
Selbst Microsoft will es in Form von VC++ weiterentwickeln.
Bloß weil wir heute mehr Arbeitspeicher zum verschwenden haben oder
schnellere CPUs unseren Code beschleunigen ,verliert C/C++ keine
Bedeutung . Denn auch die Anforderungen an Software steigen Jahr für
Jahr. Die die auch in der Zukunft auf die Hochsprachen wie C/C++ setzen
werden gegenüber Java-Konkurrenz immer im Vorteil sein .
Traum weiter mit deinem „modernen“ Java. ist eh Unsinn die Behauptung
@ VC-Profi
du scheinst den unterschied zwischen C und C++ nicht zu kennen.
das vermute ich mal, deil du immer C/C++ schreibst.
C ist für hardwarenahe programmierung sehr gut geeignet.
C++ nur bedingt (es sei denn du benutzt die features von C++ nicht,
keine STL, keine templates, etc. aber dann bist du fast wieder bei C
gelandet).
ausserdem favorisiere ich keineswegs Java. es gibt auch
anwendungsgebiete für sie Java nicht so gut ist.
Ich benutze vor allem Java, aber gelegentlich auch C++. Was in Java
fehlt sind Operatorenüberladungen. Wenn man z.B. mit komplexen Zahlen
arbeitet, ist das in Java ein Krampf. Übrigens sollte Java auf Dual-Core
Maschinen gut abgehen...
Java und übrigens auch .NET sind der größte Dreck. Meine Devise lautet:
"keep it simple". Programmierer sind ohnehin heute viel zu verliebt in
überbordende Objetmodelle und ihren abstrakten Universen, die kein
Mensch braucht.
OOP ist selbstverständlich, aber was in Java und .NET mit diesen
gigantischen Class-Libraries und zigfachten Abstraktionsschichten
verbrochen wurde und wird, ist einfach nur lächerlich.
C++ mit einer guten Plattformbibliothek und Datenbankschnittstelle ist
für alles die erste Wahl. Für Webanwendungen reicht PHP für 99% aller
Projekte, bei denen es nicht auf extreme Performance, Lastverteilung
etc. ankommt. Ansonsten kann man dazu in der Tat am besten JAVA
verwenden.
Aber ansonsten C++, schlanke, effiziente Programmierung und nicht diesen
Fickmist, mit den Milliarden Packages und ClassLoaders und Reflection
API, wo der Rechner in die Knie geht, obgleich des Speicherverbrauchs
und die Entwicklung mit den umständlichen Namespaces und aufgeblählten
Source-Bäumen und Referenzierungen zur Qual wird.
Vergesst es, ihr Theoretiker.
Ein seit 10 Jahren selbständiger SW-Entwickler.
----
Ich schließe mich Matze an. Ich bin auch selbständiger
Anwendungswickler.
Ich kann nur jedem empfehlen sich nicht zu sehr in Java oder Net zu
verlieben auch wenn’s so schon einfach ist. Die Richtigen Anwendungen
werden nach wie vor in C/C++ entwickelt , Mit Java und Co ist im
Ernstfall schnell Ende.
Für mich ist Java, Net und VB was zum spielen- Mehr ist damit nicht
drinn.
Ich habe mir gerade ein Buchhaltungssoftware gekauft ,der reinste
Schrott -- basiert auf Java. Kein Mensch kann mit so einem Scheiß
arbeiten. Ein beschissenes Windows-Interface -- Eingaben und
Interaktion -> Schrott, Resourcenfressend ohne ende ,für ein bisschen
Euro umrechnen muss man schon warten. Und bis sich irgendwelche
Bibliotheken geladen haben kann ich mir ein Kaffe kochen gehen.
Ich sage auch, da habe ich diesen Javafritzen nur Geld hinterher
geworfen und die laufen dann im nächsten Forum rum und erzählen uns was
von „professionellen“ Programmieren mit Java.
naja java ist ja schön und gut.. nur schonmal auf einem g4-ibook linux
installiert und dann probiert von sun einen java-interpreter zu
bekommen? ;D
so viel zum thema portabel.. da ist mir c++ lieber der gcc compiliert
überall wo linux drauf rennt (notgedrungen)
man kann mit allen sprachen schlechte programme/code erzeugen.. also ist
die diskussion ziemlich müßig...
im übrigen kann man meiner meinung nach folgendes machen:
ist vor allem gui-zeug dabei => java oder sonst was mit gui-design-tools
ists hauptsächlich dumm daten schaufeln... c++ man kann sagen was man
will aber jit-compiler optimieren zwar sicher so gut wie ein
vernünftiger compiler aber das zeug muss trotzdem erst irgendwann mal
kompilieren und braucht extra speicher... ich arbeite zwischendurch an
einer prüfstandssoftware mit... da kommt man durchaus mit c++ schon
ziemlich in zugzwang mit der performance.. auch ohne dass da jedesmal
string-längen gescheckt werden,...
es ist also absolut nicht notwendig flame wars auszulösen... einigen wir
uns doch darauf, dass niemand mit halbwegs normaler veranlagung eine
office-suite mit brainf*ck schreiben würde ;)
73
Also der Thread ist zwar schon sehr alt aber xD ich kapier das flamen
hier nicht. Klar glaubenskrieg zwischen den Anhängern der jeweiligen
Programmiersprachen gab es immer und wird es auch immer geben. Aber das
ist so als ob sich ein Fahrer eines BMW mit einem Mercedes Fahrer
streitet. Und zu behaupten eine Sprache wäre besser als die andere ist
auch blödsinn, genau so zu behaupten eine wäre eine Kiddy sprache und
die andere eine Profi-Sprache, oder 95% der Firmen gehen nur auf C/C++.
Also wenn man in einer Firma beschäftigt ist, dann ist es dennen *****
egal in welcher Sprache es geschrieben ist. VB z.B. innerhalb von kurzer
Zeit, hat man ein Programmgerüst fertig, wo man in C/C++ oder Java schon
etwas länger braucht. C/C++ ist eine Perfekte Sprache wenn man
Hardwareorientiert proggen will keine frage, 3D anwendungen, games, etc.
Java lernt man im internetbereich gerne schätzen, man kanns ewig so
weiter führen, was ich nur sagen will es gibt viele probleme die man
lösen muss und zu sagen der eine weg ist besser als der andere ist
schwachsinn. Wenn man mehr Sprachen kann als nur C/C++ oder nur Java,
umso besser. Aber zu behaupten seine eigene Sprache wäre DIE SUPER
Proggisprache... das hat überhaupt keine zukünft, überlegt euch selber
mal in welchen bereich ihr Arbeitet oder hobby in dem fall weniger, aber
der bereich wächst ziemlich schnell und ihr müsst auch andere
technologien lernen um wettbewerbsfähig zu bleiben, da reicht meistens
nicht nur eine sprache zu können. ging jetzt nur an die kiddys ^^ ein
richtiger Programmierer denkt logisch =D und würde niemals behaupten DIE
SPRACHE WÄRE PERFEKT blabla blubb und mal ein kleines wort was man am
anfang lernen sollte C/C++ oder Java das ist subjektivbetrachtet was
einem am besten liegt oder für welchen zweck ihr proggen wollt ich hoffe
es kommt nun wieder kein flame auf ^^ aber kritik ist erlaubt bei
fehlern lass ich mich gerne eines besseren belehren und sorry für die
Rechschreibfehler aber muss weiter arbeiten ^^
cu
*Hand hebt und sich fragt ob man mit JAVA auch Mikrocontroller
programmieren kann? Gibts da nen passenden Compiler? Das ist reines
Interesse an der Sache, ist ja nen Mikrocontroller-Forum, ^^! Aber sonst
recht lustig, zulesen die Diskussion.
Gruß Yob
Ja es gibt auch XML Interpreter die dann Machinencode für den uC
erzeugen, das ganze natürlich objektorientiert und plattformunabhängig
gemäss UML und mit Design Pattern.
http://www.mikrocontroller.net/articles/NanoVM
Java ist toll aufm PC - sehr komfortabel und schnell genug
C++ ist auch toll aber z.T. nervig
C ist für µCs perfekt
PHP ist ideal für's Web
Pascal ist alt aber gut
Basic ist der letzte Mist von vorvornachübergestern
> Hi Johnny, hast du damit schon µC prgrammiert? Wenn ja, wie so dein> Fazit dazu?
Hallo Yob
Sorry war nur ein Scherz. uC's programmiert man normalerweise in C oder
allenfalls Assembler wenn es nicht anders geht.
Ganz ganz ehrlich, das ist mit der beste Thread, den ich jemals lesen
durfte.
"Danke", dass mir mein Abend gerettet wurde durch diese amüsante Parodie
und ich selten so viel gesammelten Schwachsinn und verbalen/geistigen
Müll lesen durfte.
=)
MfG
Bekenne mich mal zu Nekromanie :)
Wir bekommen an der Hochschule nach C im letzten Semester nun Java
gelehrt und der Prof sieht es als Wundersprache der Neuzeit.
Nachdem ich mich schon früher mit der Diskussioon beschäftigt habe würde
ich da etwas differenzierter rangehen als der Prof selber - aber als
Schrott würde ich Java nicht bezeichnen. Ist doch Top, wenn man kleine
meist sogar Betriebssystemunabhängige Anwendungen so mit geringerem
Fehlerrisiko in kürzerer Zeit schrieben kann. Es wurden ja genug
Beispiele genannt, dass auch große Anwendungen äußerst leistungsfähig
sein können - fähige Programmierer vorrausgesetzt
Java zu lernen kann, vielleicht gerade , wenn man sich noch nie mit OO
beschäftigt hat auch Grundlage für andere Progrmmiersprachen sein - auch
wenn ich eher in Richtung c++, anschließend Java tendieren würde.
Mein persönliches Fazit:
c als Grundlage ist Pflicht
Java ist vor Allem ein schnellerer Weg zum Ziel, solange die Anwendungen
nicht allzu Komplex werden.
Für C++ gilt ähnliches wie für Java, ein wenig hat es aber immer noch
die Nase vorn. Aber auch in C++ kann man so einen Bullshit proggen, dass
man bei Ausführung der Software denkt man arbeite auf einem 386 ...
C++Profi wrote:
> "So ist es doch gut, dass es von Sun ist, und Java ist gewissermaßen> eine> Weiterentwicklung von C++.">> Auha,das tut auch weh.> Für dich Java auch das Beste. Keine Frage
Ähm - Das stimmt aber. Java ist eine Weiterentwicklung von C++.
Nur weil es nicht zu Assembler, sondern zu Bytecode kompiliert wird,
schließt sich das nicht aus. Mit dem gcj kannst du Java auch direkt zu
Assembler kompilieren, der ohne JVM ausgeführt wird.
Hi
bei einer Weiterentwicklung lässt man aber üblicherweise nicht
Kernbestandteile weg ohne sie durch gleichwertiges zu ersetzen. Java
übernimmt sicher das ein oder andere von C++ lässt aber auch so einiges
weg, so wie es auch C# tut.
- Mehrfachvererbung
- Überladen von Operatoren
- Templates
Über alle drei Punkte kann man sicher streiten ob man das unbedingt
benötigt oder nicht. Aber insbesondere auf die unteren zwei möchte ich
nicht verzichten müssen.
Die ganze Diskussion ist aber eigentlich relativ sinnfrei da beide
Sprachen ihre Nische besetzen und hin und wieder erfolgreich im Land des
"Konkurrenten" wildern.
Matthias
Leute! Hört sofort auf zu streiten! Ich kann das nicht mehr mit ansehen.
Und kann endlich mal jemand an die Kinder denken? DIE KINDER!
Lasst uns doch des friedens wegen auf folgendes einigen:
C++ und Java sind beide Scheisse!
Jeder vernünftige Mensch nimmt für größere Projekte entweder was
funktionales (Haskell, Lisp, Ocaml...) oder Smalltalk & Co
Für Hardwarenahes hat man dann C, Assembler und meinetwegen Forth.
Und für alles dazwischen nimmt man Python.
So. Gut dass wir das jetzt geklört haben...
Also hallo erstmal^^.
Ich besuche derzeit eine HTL und wir haben bisher VB, C, C++, Java
angeschnitten/gelernt. Demnächst kommt noch C# dazu.
Wir gehen in der Schule recht gelassen mit den verschiedenen Sprachen um
da wir von Anfang an die Vor- und Nachteile der oben genannten Sprachen
eingetrichtert bekommen. Es gibt bei uns größere 1-Mann-Projekte bei
denen es dem Lehrer nicht egal ist in welcher Sprache wir sie schreiben,
aber sonst wayne..
Der Grund weshalb ich das hier geschrieben habe ist, dass es für kleine
Programme einfach egal ist in welcher Sprache man es schreibt. Die Vor-
und Nachteile haben bei solch kleinem Code einfach noch zu wenig
Gewicht.
Und ich bin überzeugt davon, dass nur wenige der hier anwesenden bereits
beruflich über Monate hinweg in einem Team Projekte geschrieben haben.
Ich programmiere ca. seid 4 Jahren intensiv und
ich liebe C/C++/C# und Java (von Basic Sprachen halte ich persönlich
nich all zu viel) Ich benutze sie in gleichen Massen. und ich kann bis
heute nicht sagen, die Sprache ist besser als die andere..
Man könnte sich hier genau so gut darüber streiten was besser schmeckt:
Coca Cola Zero oder Coca Cola light ...
ah sry hab noch vergessen was zu sagen^^.
Java ist keine weiterentwicklung von c++!!
selbst sun schreibt dass java nicht als weiterentwicklung gedacht
ist/war/sein wird. und C# ist genau so wenig eine erweiterung von c++
oder Java. (auch hier wieder -> Microsoft lehnt es ab zu sagen es sei
eine weiterentwicklung (wers nich glaubt googlen!)) Es sind laut unseren
Lehrern ergänzungen für Gebiete bei dem eine andere Sprache eben nicht
so der renner ist.
lg chris
Java oder C++ für die Gemeinde.. da kommt es drauf an, was man machen
möchte. :)
--------------------------------------
Da streiten sich wieder Leute, die scheinbar (man solle mir meine eigene
Meinung verzeichen) in einer anderen Welt leben. In einer Welt, ohne
beruflichen Streß, ohne Kundenwünsche, vielleicht sogar ohne Job?
Hey, ich vermute mal, dass die Leute, die sich über eine
Programmiersprache streiten, entweder Studenten sind, oder lediglich
privat programmieren. :) Ergo: Unerfahren, Jungfrauen, usw.
Klar, sie können verdammt gut sein in dem, was sie tun. Das können
wirklich Profis sein (um mal nicht das Wort Kellerkinder zu nennen ^^).
Aber sie vergessen den professionellen Alltag. Wenn man wirklich ein
Profi ist, und damit meine ich Softwareentwickler vom Beruf,
Diplom-Informatiker tätig als Programmierer (und ich meine MINDESTENS
Diplom, denn ich könnte wetten, dass alle, die wirklich das Zeug haben
auf dem Niveau zu fahren, sind studiert!; den Unterschied merke ich
tagtäglich, wenn wir bei uns Studenten (Diplomanden, also "fast" fertig)
betreuen dürfen), dann wird man spätestens nach paar Jahren
berufserfahrung gemerkt haben, dass
a) die Sprache entweder vom Kunden vorgegeben wird
b) es niemals DIE eine Sprache geben kann, denn man wird mit vielen
konfrontiert (Warum eigentlich kein C++ als script-spache im Browser?
Oder Handy? Warum geht die Tendenz richtung VM's? Hmm... was heißt
eigentlich Echtzeit? Ein Wort, das kennen die meisten, aber kaum einer
weiß, was wirklich dahinter steckt :D.. ach ich könnte noch weiter
erzählen)
c) die Sprache eigentlich nur 10% des GANZEN ausmacht. Plannung und
Organisation ist das A & O. Softwaredesign muss stimmen.
Hier noch ein paar weitere Streitpunkte, weil es macht wirklich Spaß
euch zu lesen und man ist sich sicher: Konkurenz für den Job muss ich
von den meisten hier nicht befürchten. (<- Den Satz nennt man auch
Provokation! Also haut in die Tasten ^^).
C++Profi wrote:
> Programmiersprachen wie Java und VB wurden nur erfunden um die vielen> Kidis> ein Spielzeug für das Freizeitcoden in die Hand zu geben .
Das ist wohl der größte Schwachsinn, den ich je gelesen habe. Auch unter
VB können hochkomplexe Anwendungen programmíert werden. Ich kenne
Systeme, die von "VB - Amateueren" im x - fachen der Zeit und weitaus
betriebssicherer als von selbsernannten C++ Profis programmiert wurden.
Und das Verständnis der Objektjorientierung muss wohl kaum nur in C++
vorhanden sein.
Abgesehen davon sollte man die Verwendung der Sprache immer auf die
jeweilige Anwendung beziehen, und nicht stur geradeaus schauen, nur weil
man GLAUBT eine zu beherrschen.
mfg
> Java ist toll aufm PC - sehr komfortabel und schnell genug> C++ ist auch toll aber z.T. nervig> C ist für µCs perfekt
Genau. Ich würde sogar soweit gehen, daß C++ (nicht C!) heute
weitestgehend überflüssig ist.
Peterchen wrote:
>> Java ist toll aufm PC - sehr komfortabel und schnell genug>> C++ ist auch toll aber z.T. nervig>> C ist für µCs perfekt> Genau. Ich würde sogar soweit gehen, daß C++ (nicht C!) heute> weitestgehend überflüssig ist.
Sicher. Deswegen wird es ja auch kaum noch benutzt.
Habe Web Service / Clients in Java mit Netbeans programmiert, um die
Ergebnisse eine Testreports zyklisch in eine Access DB zu schreiben.
(ODBC)
Die Vorgehensweise war sehr strukturiert , alles in mit der Netbeans IDE
übersichtlich.
(Man muss natürlich wissen in welchen XML File was konfiguriert werden
muß).
Bei Applikationen , die übers Netz auf eine relationale Datenbank, oder
auch Olap Datenbank zugreifen wirkt es sich nicht negativ aus, wenn man
sie in Java oder C# schreibt, was die Geschwindigkeit anbetrifft.
Im Gegenteil: ein Java Prog als Bulk-Loader für eine Textdatei in eine
Oracle Datenbank Tabelle konnte das (wahrscheinlich in C oder C++)
geschriebene Oracle-Tool in Punkto Geschwindigkeit eindeutig
übertreffen.
http://www.stefankrause.net/wp/?p=9
Hier steht ein Vergleich u.a. des gcc und des Excelsior jet Compilers.
Letzterer compiliert jars in exe Files und steht dem gcc bei den
Geschwindigkeittests fast immer auf Augenhöhe gegenüber.
Die Investition in Zeit und Mühe die Sprache Java zu erlernen hat sich
gelohnt. Man kann diese Sprache auch partiell lernen , was sehr
vorteilhaft ist und Frust vermeidet.
Mein Aufgabengebiet kann ich vollständig damit abdecken.
Hardwarenahe Anwendungen wie Treiber z.B. werde ich nie programmieren
müssen.
Wenns denn sein muss kann man immer noch das jni benutzen.
Wenn man auf die Graphische Oberfläche verzichtet kann man Java2C
Converter
wie http://www.vishia.de/Java2C/index.html benutzen (wenn dann Optionen
wie Threads und Netzanbindung mal unterstützt werden)
Da ich in beiden Sprachen programmiert habe nun meine Anmerkungen zu der
Sache:
Java besitzt aus meiner Sicht den Vorteil, das es moderne Anforderungen
wie GUI-Klassen schon aus dem Sprachumfang bedient. Dies ist aber mit
den C++-Bibliotheken Qt oder wxWidgets mehr als wettgemacht.
Erleichternd bei der Programmerstellung mit modernen IDE's wie Eclipse
ist weniger die Sprache an sich als der Umstand, das das Programm eben
die ganze Zeit im Hintergrund mitcompiliert wird und man Fehler schon
beim Tippen angezeigt bekommt. Auch dieser Vorteil ist mit der
Verfügbarkeit von C++-Entwicklungsumgebungen und Plugins für Eclipse
teilweise wieder wettgemacht.
Ein echtes Plus für Java ist die Ausführbarkeit von den Programmen auf
verschiedensten Plattformen ohne Neuübersetzung. Gut um kleinere Sachen
von der eigenen Homepage mal schnell vorzuführen.
Zu den Nachteilen von Java, wie ich sie empfunden habe:
Da ist zum einen der nicht zu verleugnende Performanceverlust, den man
gerade bei größeren Datenmengen (große Bilder etc.) deutlich spürt.
In dieser Hinsicht ist die Java-JIT-Compilierung nicht wirklich die
Lösung.
Warum? Zwei meiner Ansicht nach wesentliche Punkte:
1. Java baut auf dem kleinsten gemeinsamen Nenner aller
Rechnerarchitekturen auf, der 0-Adreß-Maschine. Maschinencode für solche
0-Adreß-Maschinen gerade in Hinsicht auf die immer wichtiger werdende
Parallelverarbeitung (SIMD-Befehle) oder der Registervielfalt der
x86-Nachfolger umzuwandeln ist deutlich schwieriger als wenn man den
Hochsprachenalgorithmus vor sich hat.
2. Der JIT-Compiler wird sich nie den Überblick über den Code leisten
können wie ein traditioneller Offline-Compiler. Ansonsten wäre sein
Resourcenbedarf viel zu hoch! Gerade diese weitreichende Codeanalyse
verhilft dem GCC in der letzten Zeit zu Leistungssprüngen.
3. Man vergesse nicht, den Ressourcenbedarf des JIT-Compilers mit zu
erfassen!
Auch der Umgang mit Hauptspeicher kann schnell dazu führen das der PC
zum Auslagern gezwungen wird und so richtig quälend langsam wird.
Auch andere Sachen finde ich bei C++ besser gelöst.
Zum Beispiel den starken Overhead bei Java, bedingt durch die Ableitung
aller Klassen von Object.
Definiere ich mir unter C++ einen Komplex-Wert
complex<double> a;
so belegt dieser nur den Platz für zwei Double-Werte. Bei Java habe ich
den gesamten, durch Object mitgeschleppten Overhead! Das spielt bei
einem komplexen Wert nicht die Rolle, aber wie sieht es bei einer
1024x1024x1024-3D-Matrix aus?
Überhaupt finde ich die Template-Sache bei C++ viel besser gelöst als
die Schein-Templates unter Java, die über zeitraubende dynamic_casts
über die Object-Basisklasse laufen.
Die C++-Templates erlauben mir, Algorithmen generisch aber hocheffizient
umzusetzen - gerade auch durch die Möglichkeit der Spezialisierung.
Desweiteren vermisse ich oft bei Java die unsigned-Datentypen. Viele
Berechnungen in der Bildverarbeitung oder auch anderswo müssen in Java
sehr
kompliziert gestaltet werden weil eben kein unsigned-Wert vorhanden ist.
Das in C++ integrierte C-Erbe finde ich auch nicht unpassend. Man soll
ja nach dem natürlichsten Sprachmittel greifen, und was ist für
mathematische Funktionen natürlicher als Funktionen? sin(x) liest sich
leichter als java.lang.Math.sin(x).
Überhaupt kann die C-Untermenge manchmal recht hilfreich sein. Ein
parameterisierter Dateiname ist mit sprintf() noch immer am schnellsten
zusammengefügt, und zuweilen ist mir der Zugriff auf die "rohen"
Bytedaten auch ganz hilfreich.
Gerade im mathematischen Umfeld finde ich die Operatorenüberladung von
C++ recht gut. Was liest sich besser?
Java: Vector y = M.prod(x).add(o);
-oder-
C++: Vector y=M*x+o;
Gerade bei komplizierteren Formeln erleichtert die C++-Notation deutlich
die Fehlersuche.
Hallo,
tolle Diskussion hier ;) Rüdiger du hast Recht C++ wirkt oft eleganter,
in Java ist manches schreibaufwändiger. (Übrigens reiht aus Math.sin(a))
Nichts desto trotz sind beide Sprachen mehr oder weniger gleichmächtig
und Java Code ist sehr suggestiv ergo einfacher zu warten.
Der Performanceverlust spielt für mich nur eine untergeordnete Rolle,
wichtiger sehe ich es, Programme so zu schreiben, dass sie leicht zu
warten sind.
Ich habe im Studium anfangs C++ gelernt, jetzt möchte ich jedoch Java
lernen. Nicht weil ich glaube, dass Java besser ist, sondern weil ich
glaube Java ist die zukunftsträchtigere Sprache.
Es ist auch gut "Konkurrenzsprachen" zu haben wie C++. Aber im Ernst,
aufgrund von ein paar Arg. abzuwägen, welche Sprache besser ist ,ist
ziemlich kindisch. Ich bevorzuge Java nach wie vor.
Ewald
Legendärer Thread! :D
echt lustig und so schön klischeehaft. :)
Aus dem Thema könnte man doch bestimmt ne South Park Folge machen. xD
Achja: Alle die sich zwischen die Stühle setzen und sagen es gibt nicht
DIE Srache sind Pussys. ;)
du wirst auch in der hölle schmoren! C ist das einzig wahre! ketzer!
... ok, c++ kann ja fast als c durchgehen. wirst wohl nur in einer
kleinen vorhölle schmoren ...
Haha, das ist eine schöne "Abschlussfrage" für diesen Thread! ;)
Man beachte wann der Thread eröffnet wurde: 14.02.2007.
Ob er es am Ende nun Aufgeben oder sich für eine Sprache entschieden
hat, werdem wir wohl nie erfahren!
MfG.
Er ist wahrscheinlich von der Idiotie hier so schockiert worden dass er
das Projekt aufgegeben hat. Aber dennoch nochmal Danke für das
Erstellen, ich hab wirklich selten so gelacht. Sowas albernes... Fast
als würde man pauschal fragen "Lieber Reiter oder Missionar"
hmmm,
ist schon urig
der Threadersteller wird sich wahrscheinlich was anderes dabei gedacht
haben als er diesen Thread eröffnete, er dachte wahrscheinich das er so
etwas wie eine aufgabenspezifische Gegenüberstellung erhalten würde,
bezüglich der beiden Sprachen
also ich für meinen Teil hätte hier auch die Flucht ergriffen, nach dem
Kindergartenspektakel
nicht destotrotz :)
ich hab mir mal einen Link hier drauf gespeichert, ich will diesen
Thread unbedingt bei uns in der Kaffeeküche ans schwarze Brett hängen :D
hmmm
wie auch immer
zum Thema
java oder C++
hängt wohl immer auch davon ab was man für ein Ziel verfolgt
wenn ich zum beispiel eine Applikation programmiere welche verteilt auf
verschiedenen Systemen miteinander kommuniziert, vermute ich ist Java
die bessere Lösung, zumindest für den kommunizierenden Teil
wenn es aber um das Erstellen guter Clientsoftware geht, so machte ich
die Erfahrung das C++ wohl besser ist, weil es ebend doch ein
angenehmeres Speichermanagement bietet und so ein Client an sich schon
immer mal recht gross werden kann
was aber wohl mittlerweile sich lohnt ist es mal zu schauen in wie fern
Java tauglich ist Desktop Anwendungen zu ermöglichen
in Bereich einer grafischen User PC Schnittstelle sprich GUI ist java
mittlerweile nicht mal schlecht und auch angenehm zu verwenden, bis hin
zu einen lauffähigen GUI-App verbraucht es in Java nicht allzuviel Zeit
wenn man so bedenkt wie lange das damals gedauert hat als es so mit GUI
Programmierung los ging
später wurde es ja dann auch in C++ einfacher, wie auch immer wenn man
schnell was hinzaubern will ist java schon nicht schlecht
es gibt aber Anwendungsgebiete wo die Verwendung von C++ eben doch noch
Pflicht ist, Finite Elemente Anwendungen zum Beispiel(wo viele Objecte
während der Runntime miteinander kommunizieren müssen).
Oder wo viele Clienten in Echtzeit miteinander kommunizieren sollen, da
werden auch noch C++ Derivate eingesetzt, weil es ebend doch noch
schneller ist und es auf das bissel mehr Zeit ankommt
ich hab ds Programmieren so gelernt das man vor der Entwicklung genau
abwäägt welche Programmiersprache in Frage kommt,
es ist ähnlich wie mit der programmierung von Programmen die sich der
künstlichen Inteligenz widmen, da hatte sich lange Zeit zumindest LISP
durchgesetzt (weiss nicht ob es heute noch genau so ist) sicher ging das
schon immer mit jeder anderen Sprache auch, aber LISP eignete sich dazu
am ehesten und verdiente damit zu recht seinen Platz, heute wird es nur
noch so weit ich weiss für so Dino Editoren wie emacs eingesetzt oder
man schiele mal rüber nach Autocad
aber Anwendungen programmieren aka MS-Word oder OpenOffice
hmmmmm, eher nicht, noch nie ... und wird auch nie etwas
hmmm ich persönlich mag Java nicht
mag daran liegen das ich zuvor halt viel in C++ machte und Java eher so
nen tristes Nebendasein lebte in meinen Gedanken
in Moment aber ist es so das ich diesen Kraftakt gehe und da arbeite ich
mich immer mehr in Java ein, einfach aus den Grund daher das ich grad
mit an einen Projekt viel arbeite, welches nunmal in Java implementiert
ist
unsympatisch ist mir java nach wie vor, wenn es zum Beispiel um den doch
sehr extrem komplizierten wie komplexen Overhead geht zum Beispiel
oder um das GarbageCollectors, (der GC mag zwar nützlich sein für viele
Dinge, aber manches mal mag ich gerne meinen Speicher so freigeben wie
ich es für richtig halte, ich bin nun mal ein freier Mensch)
hmm einige male wurde hier als Vorteil herausgestellt das java Threads
unterstützt, hmm
das wird später mal etwas tolles sein und auch sind die Möglichkeiten
die sich darin verbergen beachtlich, bis es aber wirklich ein Vorteil
wird, muss es noch um einiges weiter entwickelt werden,,
wie auch immer, ich hab noch zu tun,,
mal wieder wech bin
@ alle die immer an c++ rumnörgeln:
Alles hat seine Vor und Nachteile auch euer Java,
aber heute wird doch fast alles mit c++ programmiert, wenn diese Sprache
so ünnutz is, wieso benutz sie dann jeder?
Wiki schrieb:
> NTERCAL wurde mit dem Ziel entwickelt, das Programmieren schwierig zu> gestalten und die entstehenden Programme effektiv unlesbar zu machen.
Das is ja noch viel besser als Brainf*ck :D
Matthias Weißer schrieb:
> Ich votiere ja für Whitespace.
diese deterministischen sprachen sind für weicheier
java2k ist die sprache der wahl ;-)
(oder falls es schon deterministisch sein muss, dann taxi oder piet :D )
Nochn Gast schrieb:
> Alles hat seine Vor und Nachteile auch euer Java,> aber heute wird doch fast alles mit c++ programmiert, wenn diese Sprache> so ünnutz is, wieso benutz sie dann jeder?
Wenn Rauchen wirklich gefährlich ist, wieso gibt es dann so viele
Raucher?
Markus
Nochn Gast schrieb:
> Alles hat seine Vor und Nachteile auch euer Java,> aber heute wird doch fast alles mit c++ programmiert, wenn diese Sprache> so ünnutz is, wieso benutz sie dann jeder?
Weil es eine Sprache von MS ist und somit für Windows gut geeignet ist.
Nachteil: Funktioniert nur unter Windows
Ich persönlich verwende Java weil es viel weniger bugs gibt und ich
damit Sachen auf meine Website stellen kann.
mfG
bollfa
bollfa schrieb:
> Weil es eine Sprache von MS ist und somit für Windows gut geeignet ist.> Nachteil: Funktioniert nur unter Windows
ha? oder auf deutsch "wie bitte"?
c# ist von MS, c von K&R (damals bei den bell labs), c++ von stroustrup
(damals bei at&t)
c & c++ funktionieren WIRKLICH (fast) überall, einen passenden compiler
vorausgesetzt
"> aber heute wird doch fast alles mit c++ programmiert, wenn diese
Sprache
> so ünnutz is, wieso benutz sie dann jeder?
Weil es eine Sprache von MS ist und somit für Windows gut geeignet ist.
Nachteil: Funktioniert nur unter Windows"
Sorry, aber das ist Unfug. C/C++ sind genormte Sprachen, für die auf
nahezu allen Plattformen Compiler existieren. Nur weil es auch von MS
einen C++-Compiler gibt, hat MS die Sprache noch lange nicht "erfunden".
Kein Wunder, dass Microsoft als EDV-Gott angesehen wird, wenn denen
jegliche Entwicklung im EDV-Bereich zugeschrieben wird. Aber das wäre
nichts Neues. Viele sind auch der Meinung, Microsoft hätte das Internet
erfunden. Wie gesagt, viele Zeitgenossen sind der Meinung, Microsoft
hätte alles im EDV-Bereich erfunden.<kopfschüttel>
Terminator schrieb:
> nichts Neues. Viele sind auch der Meinung, Microsoft hätte das Internet> erfunden. Wie gesagt, viele Zeitgenossen sind der Meinung, Microsoft> hätte alles im EDV-Bereich erfunden.<kopfschüttel>
Das Einzige was Microsoft erfunden hat, sind neue Farbschema und neue
GUI-Features, die keiner wirklich braucht. Bisher war das Gott sei Dank
immer alles abschaltbar :-)
Obwohl. Bei den GUI Features bin ich mir nicht sicher, ob die die Ideen
nicht auch irgendwo geklaut haben. Denn bei dem Zeug mit dem deren
Usability-Lab hochkommt, frag ich mich schon des öfteren: Was rauchen
die und sollten sie nicht besser damit aufhören?
Diese C++ Programmierer,
alles Weicheier. Wer braucht schon einen Compiler, richtige Männer
wissen den Opcode auswendig und hacken ein Programm direkt als Hex!!!!!
(ROFL)
Meine Güte seid Ihr krank (vor allem die VC und C++ Profis)
Bleibt bei eurem C++ (das für bestimmte Dinge absolut seine Berechtigung
hat) während Ihr noch das 1000ste Speicherleck sucht, verkaufe ich schon
die 3.Generation meiner mit java entwickelten SW und zwar mit einer
Version für alle Linux / Unix derivate, für Windows und auch noch für
den Host falls nötig, habe ein plattformunabhängiges DB Interface.
Heutzutage zählt "time to market" und "plattformunabhängigkeit" und
nicht zuletzt Lesbarkeit des Codes und nicht mehr Performance um jeden
Preis zumal java Programme nicht mehr viel langsamer sind.
Aber die meisten "Profies" die sich so nennen haben wahrscheinlich noch
nie über den Windowstellerrand rausgeschaut :-))))
Witzig ist auch, daß die Trennung in C und H Files als absolutes Plus
gefeiert wird aber "Interface" als Schlüsselwort nicht vermisst wird.
Der Streit ist genausolustig wie vor 20 Jahren zwischen Assemblerjunkies
und C
Also immer weiter streiten
Viel Spass noch.
@ Udo R. S. (Gast)
wie bekommst du denn ein aktuelles Javaprogramm ( mit ein paar 1.6
Features ) auf einem Mac OS X v10.3 mit einem PowerPC zum laufen?
Mac ist -zumindest bei mir- aussen vor. Unsere Kunden haben keine MACs
und mir reichts daß meine Kids Apple das Geld wegen IPod hinterherwirft.
Ich kaufe mir garantiert kein so überteuertes Teil. Also weiss ich auch
nicht wie es da mit Java ausssieht.
Aber versuche mal für ein Duzend Betriebssysteme/Derivate C-Programme zu
bauen zu testen und auszuliefern, dann weisst Du welcher Fortschritt
Java ist.
Wenn dann noch ein drei oder vier Datenbankinterfaces dazukommen und je
Betriebssystem dafür entsprechende nicht immer kompatible Libs
eingebunden werden müssen, dann weisst du auch JDBC zu schätzen.
Leider kommen wir hier in der Firma gerade mal langsam in Richtung Java
1.5 an. Unsere Kunden sind meist Banker, die sind fast so rückständig in
Sachen neue Versionen wie die Hardware in Spaceshuttles (Ausser bei
Ideen zum Zocken mit Geld das Ihnen nicht gehört:-))
Wie gesagt, auch C /C++ hat absolut seine Berechtigung, ich habe 10
Jahre C programmiert war von C++ Programmen nur entsetzt und finde
moderne und "leichter erlernbare" objektorientierte Sprachen wie Java
als echten Segen.
Gruß und Spass
Udo
> war von C++ Programmen nur entsetzt
klar hat C++ keine GUI und auch nicht eine so große klassenbibliotek wie
JAVA. Aber von der Sprache finde C++ wesentlich besser als Java.
Was mich in Java (auch .net) stört, es gibt kein "Const" man kann also
aus einem Objekt kein private object rausreichen was nicht verändert
werden kann.
Peter schrieb:
>> war von C++ Programmen nur entsetzt>> klar hat C++ keine GUI und auch nicht eine so große klassenbibliotek wie> JAVA. Aber von der Sprache finde C++ wesentlich besser als Java.>> Was mich in Java (auch .net) stört, es gibt kein "Const" man kann also> aus einem Objekt kein private object rausreichen was nicht verändert> werden kann.
Gibt's in .NET: readonly und const bzw. ReadOnlyCollection<T> und die
div. AsReadOnly-Methoden oder man packt seinen Kram in eine neue Klasse,
implementiert die passenden Interfaces und verhindert damit den Zugriff
oder implementiert nur einen passenden Indexer ohne set.
In Java geht so was afair nur für einige Objekte: java.util.Collections
Collections.unmodifiableList
> Aber versuche mal für ein Duzend Betriebssysteme/Derivate C-Programme zu> bauen zu testen und auszuliefern, dann weisst Du welcher Fortschritt> Java ist.
Also alle Java-Programme, die ich in letzter Zeit so probiert habe,
gingen entweder nur auf einer einzigen Plattform (z.B. ElsterFormular)
oder kamen in separaten Versionen für alle unterstützten Plattformen,
komplett mit eigener Laufzeitumgebung. Da hatte ich letztens erst eine
Config-GUI für einen Drucker, die ein kleines Fensterchen aufmacht. Die
war dann mal kurz fast 100 MB groß, weil sie ein komplettes Java
enthält.
zwieblum schrieb:
> Ja, und das gibt dann sicher sehr gut wartbaren Code.
Das ergibt wartbaren Code, vorausgesetzt die Entwickler wissen was sie
tun.
In C++ lässt sich dagegen so etwas nicht verhindern...
1
classC{
2
protected:
3
int*a;
4
public:
5
constint*getA(){returna;}
6
C(){
7
a=newint[10];
8
for(inti=0;i<10;i++){
9
a[i]=i;
10
}
11
}
12
};
13
14
voidchanger(void*vP);
15
voidchanger(void*vP){
16
int*iP=(int*)vP;
17
iP[4]=123;
18
}
19
20
Cc;
21
std::cout<<c.getA()[4]<<std::endl;
22
// erkennt der Compiler noch als offensichtlich unzulässig
Warum um alles in der Welt hantierst du da mit void* und C-Style-Casts
rum? Natürlich kann man sich mit C++ ins Knie schießen, wenn man es
unbedingt darauf anlegt. C++ ist darauf ausgelegt, daß man sich gegen
versehentliche Fehler schützen kann, nicht aber gegen Sabotage.
Der ganze Code, den du da zeigst, ist sowieso recht häßlich.
> zwieblum schrieb:> > Ja, und das gibt dann sicher sehr gut wartbaren Code.>> Das ergibt wartbaren Code, vorausgesetzt die Entwickler wissen was sie> tun.
Das glaube ich auch nicht, weil wenn du extra noch ein Wrapper und jedes
Object legen musst damit es const wird. Wenn das const objekt selber
noch mal ein Objekt rausgibt wird es noch schwerer.
element o = member.GetElement(1).GetElement(2).GetElement(2);
und jetzt muss o const sein.
das bricht man sich doch die finger in java.
Rolf Magnus schrieb:
> Warum um alles in der Welt hantierst du da mit void* und C-Style-Casts> rum?
Warum? Um kurz zu zeigen, dass es in C++ keine Typsicherheit gibt.
> Natürlich kann man sich mit C++ ins Knie schießen, wenn man es> unbedingt darauf anlegt. C++ ist darauf ausgelegt, daß man sich gegen> versehentliche Fehler schützen kann, nicht aber gegen Sabotage.
Dazu braucht's noch nicht einmal Sabotage. Es reicht z.B. einer der
häufigen Off-By-One-Fehler, um interne Felder einer Instanz zu
überschreiben (was passieren kann, wenn die Instanz auf dem Stack liegt,
braucht wohl keine weitere Erklärung).
> Der ganze Code, den du da zeigst, ist sowieso recht häßlich.
Passend zum Ergebnis ;-)
Arc Net schrieb:
> Rolf Magnus schrieb:>> Warum um alles in der Welt hantierst du da mit void* und C-Style-Casts>> rum?>> Warum? Um kurz zu zeigen, dass es in C++ keine Typsicherheit gibt.
Langsam.
C++ ist schon recht typsicher.
Allerdings lässt es Hintertürchen offen und legt dann die Verantwortung
in die Hände des Programmierers. Dein Code geht durch dieses
Hintertürchen, der Programmierer missbraucht seine Macht und zeigt sich
der Verantwortung nicht gewachsen.
Man hätte diese Hintertürchen auch schliessen können. Dann wäre man
allerdings in das Problem hineingelaufen, sich die Hintertür auch für
Notfälle (zb Interfaceing zu alten C-Libraries) zu schliessen und hätte
sich eines manchmal notwendigen und sinnvoll einsetzbaren Werkzeugs
(konkret: hemmungsloses Herumcasten) beraubt.
C++ ist sicherlich kein Rundum-Airbag. Wer danach sucht, ist bei C++
falsch.
>> Natürlich kann man sich mit C++ ins Knie schießen, wenn man es>> unbedingt darauf anlegt. C++ ist darauf ausgelegt, daß man sich gegen>> versehentliche Fehler schützen kann, nicht aber gegen Sabotage.>> Dazu braucht's noch nicht einmal Sabotage. Es reicht z.B. einer der> häufigen Off-By-One-Fehler,
So häufig kommen die gar nicht mehr vor.
Und die weiter oben angeführten Speicherlecks sind in C++ auch sehr
selten geworden. Zumindest bei C++-Profis sind die ein wesentlich
kleineres Problem als gemeinhin angenommen. RAII Idiom anwenden und das
'Problem' ist meistens vom Tisch. Und für die Garbage-Collection
Fetischisten gibt es dann immer noch die Smart-Pointer aus der
Boost-Kollektion. Sozusagen das Beste aus 2 Welten: Objekte werden
freigegeben, wenn es keinen Verweise mehr darauf gibt und ich habe
trotzdem die volle Kontrolle über die Lebensdauer von Objekten (und
einen sinnvoll einsetzbaren Destruktor)
zwieblum schrieb:
> @Arc Net: Kannst du mir erklären, warum der Compiler nach den (void> *)-casts schreien soll?
Kommt drauf an was du hören willst...
Standpunkt 1: const int* != void* != int* d.h. das sind unterschiedliche
Typen, die Umwandlung somit illegal.
Standpunkt 2: Man braucht solche Umwandlungen, der Rest ist ein Problem
des Programmierers, nicht der Sprache.
Arc Net schrieb:
> zwieblum schrieb:>> @Arc Net: Kannst du mir erklären, warum der Compiler nach den (void>> *)-casts schreien soll?>> Kommt drauf an was du hören willst...> Standpunkt 1: const int* != void* != int* d.h. das sind unterschiedliche> Typen, die Umwandlung somit illegal.
Wenn da nicht die vermaledeite mitgeschleppte Kompatibilität zu C Code
wäre. Und die hat nun mal einen brachial-Brechstangen-Cast. Probier die
C++ casts, die werden verweigern. Aber gegen einen C-Cast ist für einen
C++-Compiler kein Kraut gewachsen. Damit überstimmt der Programmierer
immer den Compiler. Womit dann dein Standpunkt 2 nur noch Makulatur ist:
Der Programmierer sollte besser wissen was er tut, wenn er die
Brechstange benutzt. Und im Regelfall braucht ein C++-Programmierer die
Brechstange nur ganz selten und dann auch nur in einem codemässig eng
begrenzten Bereich. Du tust fast so, als ob das umcasten von Pointern
täglich Brot in der C++ Programmiererei wäre.
überspitzt ausgedrückt:
Die C-Philosophie ist:
Ein beheizter Kessel braucht keine Drucküberwachung. Der Heizer
ist genügend geschult um zu wissen, wann er mit dem Kohlenachlegen
aufhören muss
Die C++-Philosophie ist:
Ein beheizter Kessel kriegt ein Manometer verpasst. Damit kann
der Heizer seine Nachlegen kontrolliert regeln. Der Heizer muss
mitdenken, denn das Manometer ist kein Rundum-Sorglospaket
Die Philosophie der neueren Sprachen ist:
Ein beheizter Kessel kriegt ein Monometer und eine Überdrucksicherung
verpasst. Der Heizer kann Kohle nachlegen wie er will, wenns
gefährlich wird, wird der Kessel geöffnet.
Der Heizer muss nicht mehr mitdenken sondern kann sich aufs
Kohleschaufeln konzentrieren.
Klar kann einem C++-Heizer der Kessel um die Ohren fliegen. Dafür kann
er allerdings auch in Ausnahmesituationen den Kesseldruck auch über den
vorgegebenen Wert einer Überdrucksicherung hochtreiben.
Karl heinz Buchegger schrieb:
> Die Philosophie der neueren Sprachen ist:> Ein beheizter Kessel kriegt ein Monometer und eine Überdrucksicherung> verpasst. Der Heizer kann Kohle nachlegen wie er will, wenns> gefährlich wird, wird der Kessel geöffnet.> Der Heizer muss nicht mehr mitdenken sondern kann sich aufs> Kohleschaufeln konzentrieren.
Das war mal.
Inzwischen heizen die Weichei-Sprachen nur noch mit Warmluft.
Um die zu erzeugen, laufen dann irgendwo im Kraftwerk C und C++.
zwieblum schrieb:
> "Standpunkt 1" ist reine Annahme des Benutzers.
Stichworte: Alonzo Church, Girard, Reynolds, Martin-Löf, Typentheorie,
Typsysteme, Polymorpher Lambda-Kalkül etc.
Karl heinz Buchegger schrieb:
> Arc Net schrieb:>> zwieblum schrieb:>>> @Arc Net: Kannst du mir erklären, warum der Compiler nach den (void>>> *)-casts schreien soll?>>>> Kommt drauf an was du hören willst...>> Standpunkt 1: const int* != void* != int* d.h. das sind unterschiedliche>> Typen, die Umwandlung somit illegal.>> Wenn da nicht die vermaledeite mitgeschleppte Kompatibilität zu C Code> wäre. Und die hat nun mal einen brachial-Brechstangen-Cast. Probier die> C++ casts, die werden verweigern.
Dann eben mit C++ Casts...
1
std::cout<<c.getA()[4]<<std::endl;
2
3
int*iP=const_cast<int*>(c.getA());
4
iP[4]=123;
5
6
std::cout<<c.getA()[4]<<std::endl;
7
8
double*dP=reinterpret_cast<double*>(iP);
9
dP[2]=1234.0;
10
11
std::cout<<c.getA()[4]<<std::endl;
> Die Philosophie der neueren Sprachen ist:> Ein beheizter Kessel kriegt ein Monometer und eine Überdrucksicherung> verpasst. Der Heizer kann Kohle nachlegen wie er will, wenns> gefährlich wird, wird der Kessel geöffnet.> Der Heizer muss nicht mehr mitdenken sondern kann sich aufs> Kohleschaufeln konzentrieren.
Erlang gibt's seit 1987, ML gibt's seit 1973, Simula seit 1967, Lisp
seit 1958...
hm, wenn das mit C++ so gefährlich ist, nehme ich doch besser was
anderes.
Wie war das noch bei Hermann Hesse?
Entgegenkommen
Die ewig Unentwegten und Naiven
ertragen freilich unsre Zweifel nicht.
Flach sei die Welt, erklären sie uns schlicht
und Faselei die Sage von den Tiefen.
Denn sollt es wirklich andre Dimensionen
als die zwei guten, altvertrauten geben,
wie könnte da ein Mensch noch sicher wohnen,
wie könnte da ein Mensch noch sorglos leben?
Um also einen Frieden zu erreichen,
so lasst uns eine Dimension denn streichen!
Denn sind die Unentwegten wirklich ehrlich
und ist das Tiefensehen so gefährlich,
dann ist die dritte Dimension entbehrlich.
Arc Net schrieb:
> int* iP = const_cast<int *>(c.getA());> double* dP = reinterpret_cast<double *>(iP);
LOL.
Ich wusste, dass du dir genau die beiden raussuchen wirst.
const_cast ist explizit dazu gedacht, constness wegzucasten. Von daher
also keine wirkliche Überraschung, dass das der Compiler akzeptieren
wird.
Und reinterpret_cast ist im Grunde nichts anderes als ein Wolf im
Schafspelz: Ein C-Cast in einer C++ Mogelpackung :-) Sein Einsatzgebiet
besteht explizit darin, unrelated Types ineinander umzucasten.
> Erlang gibt's seit 1987, ML gibt's seit 1973, Simula seit 1967,> Lisp seit 1958...
Was willst du uns jetzt damit sagen.
Doch hoffentlich nicht, dass sich Simula um Garbage Collection kümmert
oder das LISP eine streng typisierte Sprache ist.
Karl heinz Buchegger schrieb:
> Doch hoffentlich nicht, dass sich Simula um Garbage Collection kümmert
Ooops. Mein Fehler.
Simula hat eine Garbage Collection.
Klaus Wachtler schrieb:
> Wie war das noch bei Hermann Hesse?>> *Entgegenkommen*>> Die ewig Unentwegten und Naiven> ertragen freilich unsre Zweifel nicht.> Flach sei die Welt, erklären sie uns schlicht> und Faselei die Sage von den Tiefen.
[...]
Schick, das.
Arc Net schrieb:
> int* iP = const_cast<int *>(c.getA());> double* dP = reinterpret_cast<double *>(iP);
Du wunderst dich, dass der Compiler das macht, was er laut Definition
machen soll?
> Stichworte: Alonzo Church, Girard, Reynolds, Martin-Löf,> Typentheorie, Typsysteme, Polymorpher Lambda-Kalkül etc.
Was soll das Dahingestammle?
Zum Thema GUI sollte beachtet werden, daß die Java-Bibliotheken zu
diesem Zweck nicht wirklich zur Sprache zählen.
Ebenso könnte man für C++ Bibliotheken wie der Quasistandard Qt oder
wxWidgets den Java-Bibliotheken Swing/AWT gegenüberstellen, und C++
würde recht gut dabei abschneiden.
Auch anzumerken ist, daß ein amoklaufender GC das Speicherleck würdig
abgelöst hat.
Was mich wundert: es wird ja teilweise richtig die Entmachtung des
Programmierers gefeiert - nach dem zeitgemäßen Motto "Erlöse uns von der
Verantwortung und lasse uns nur noch mit TÜV-geprüften Babyrasseln
spielen!"
Das ist ja fast so als ob im Handwerk der Hammer für phöse und
PC-inkorrekt erklärt wird weil man sich mit diesem auf den Daumen hauen
kann und man ihn deshalb durch Tesafilm abgelöst hat.
Ich war jedenfalls oft froh, immer noch die C-Untermenge zur Verfügung
zu haben, um bestimmte Probleme "mit einer Macht-Typumwandlung" einfach
zu lösen.
Zudem sollten die Sprachmittel möglichst nach der Natur der
umzusetzenden Dinge gewählt werden, und für eine Funktion ist eine
Funktion die natürlichste Umsetzung.
Dieser Grundgedanke sollte eigentlich die Frage beantworten - man wähle
die Sprache nach dem Problem, was man umzusetzen hat.
Dies erklärt, warum Physiker und Mathematiker immer noch gern auf
Fortran zurückgreifen - für ihre Probleme ist dies keine schlechte Art,
diese gut umzusetzen.
zwieblum schrieb:
> Arc Net schrieb:>>> int* iP = const_cast<int *>(c.getA());>> double* dP = reinterpret_cast<double *>(iP);>> Du wunderst dich, dass der Compiler das macht, was er laut Definition> machen soll?
Ich wundere mich nicht, nur war die Aussage von Karl heinz Buchegger
> Probier die C++ casts, die werden verweigern.> Standpunkt 1" ist reine Annahme des Benutzers.>> Was soll das Dahingestammle?
Bei dem Stil wird noch eine ausführliche Antwort erwartet?
Karl heinz Buchegger schrieb:
> LOL.> Ich wusste, dass du dir genau die beiden raussuchen wirst.
und schrieb etwas früher:
> Langsam. C++ ist schon recht typsicher.
U.a. aufgrund genau dieser zulässigen Casts ist C++ nicht typsicher.
> Doch hoffentlich nicht, dass sich Simula um Garbage Collection kümmert> oder das LISP eine streng typisierte Sprache ist.
Lisp ist sowohl typsicher, als auch streng typisiert. Allerdings erst
zur Laufzeit, nicht beim Übersetzen.
Arc Net schrieb:
> Ich wundere mich nicht, nur war die Aussage von Karl heinz Buchegger>> Probier die C++ casts, die werden verweigern.
Mea culpa.
Ich hätte spezifischer sein sollen :-)
> Karl heinz Buchegger schrieb:>> LOL.>> Ich wusste, dass du dir genau die beiden raussuchen wirst.> und schrieb etwas früher:>> Langsam. C++ ist schon recht typsicher.>> U.a. aufgrund genau dieser zulässigen Casts ist C++ nicht typsicher.
Und nochmal.
Du reitest hier auf Casts rum. Neben den beiden von dir verwendeten
Casts gibt es noch den static_cast und den dynamic_cast, die dir diese
Umwandlung nicht durchgehen lassen würden.
Aber im Grunde spielt es keine Rolle.
Den Casts sind genau diejenigen Werkzeuge, die es einem gestatten aus
der Typsicherheit auszubrechen. Man beötigt sie nicht oft aber wenn man
sie benötigt dann sollte man dafür einen guten Grund haben.
Die Alternative: die gefährlichen Casts aus der Sprache zu entfernen,
ist keine Option. Denn manchmal benötigt man genau diese Möglichkeit.
Jeder C und C++ Programmierer, der sein Handwerk versteht, wird dir
zustimmen, dass Casts gefährliche Waffen sind (sein können). Die
Alternative lautet ganz simpel: Benutze keinen Cast, ausser diejenigen,
die einen arithmetischen Datentyp in einen anderen umwandeln und nur
dazu dienen Compilerwarnings abzuschalten.
Aber deswegen C++ zu verteufeln, kann nicht Sinn der Sache sein. Ein
Werkzeugkasten ist auch nicht desegen schlecht, weil man sich mit dem
Hammer auf die Finger klopfen kann.
Genausogut kann ich sagen, Java oder C# wäre mies, weil ich eine
Referenz benutzen kann, die an kein Objekt gebunden wurde.
> Lisp ist sowohl typsicher, als auch streng typisiert. Allerdings erst> zur Laufzeit, nicht beim Übersetzen.
Laufzeit ist uninteressant. Da ist das Kind schon längst in den Brunnen
gefallen.
> U.a. aufgrund genau dieser zulässigen Casts ist C++ nicht typsicher.
Mit der Argumentation könntest du auch behaupten, Stromkabel seien
komplett ungesichert, weil du ja die Möglichkeit hättest, sie
durchzuschneiden und an die offenen Drähte zu fassen.
Klar hättest du die Möglichkeit, aber wozu solltest du das tun, wenn du
es gar nicht willst?
Arc Net schrieb:
>> LOL.>> Ich wusste, dass du dir genau die beiden raussuchen wirst.> und schrieb etwas früher:>> Langsam. C++ ist schon recht typsicher.>> U.a. aufgrund genau dieser zulässigen Casts ist C++ nicht typsicher.
Wenn Du umbedingt willst, dann ja.
Die ganze Diskussion ist doch albern. Ein Zwischenergebnis an dieser
Stelle lautet: "Wenn Du Dir ins Bein schiessen willst, dann kannst Du
das tun." Es handelt sich, wenn man Selbstverstümmelung denn zu den
Kunstformen rechnen mag, also um "künstlerische Freiheit."
Allerdings frage ich mich, ob es tatsächlich Programmierer gibt, die ihr
Geld mit Meckern und Prinzipienreiterei verdienen. Ich tue das nicht.
Ich versuche, die Möglichkeiten der Sprache/Platform elegant und vor
allem sauber zu verwenden.
Karl heinz Buchegger hat meiner Meinung nach sehr elegant geschrieben:
> Aber deswegen C++ zu verteufeln, kann nicht Sinn der Sache sein. Ein> Werkzeugkasten ist auch nicht desegen schlecht, weil man sich mit dem> Hammer auf die Finger klopfen kann.
Udo R. S schrieb:
> Meine Güte seid Ihr krank (vor allem die VC und C++ Profis)> Bleibt bei eurem C++ (das für bestimmte Dinge absolut seine Berechtigung> hat) während Ihr noch das 1000ste Speicherleck sucht, verkaufe ich schon> die 3.Generation meiner mit java entwickelten SW und zwar mit einer> Version für alle Linux / Unix derivate, für Windows und auch noch für> den Host falls nötig, habe ein plattformunabhängiges DB Interface.> Heutzutage zählt "time to market" und "plattformunabhängigkeit" und> nicht zuletzt Lesbarkeit des Codes und nicht mehr Performance um jeden> Preis zumal java Programme nicht mehr viel langsamer sind.
Dem muss selbst ich als C++-Fan uneingeschränkt zustimmen. Speziell die
SW-Entwicklung mit Java ist in weiten Teilen deutlich entspannter als
mit C++. Wenn strukturiert entwickelt wird (und das setze ich von
jedem, der sich Programmierer nennt, voraus!), verzeiht Java einem
deutlich mehr als C++.
Auch im GUI-Sektor hat sich auf der Java-Seite in den letzten Jahren
einiges getan. Ich meine mich an eine Studie zu erinnern, bei der
ermittelt wurde, dass sich native GUI-Programme und
Java-Benutzeroberflächen performancemässig ziemlich nahe stehen. Das
Argument fällt dann wohl also flach (ist übrigens auch meine Erfahrung).
> Witzig ist auch, daß die Trennung in C und H Files als absolutes Plus> gefeiert wird aber "Interface" als Schlüsselwort nicht vermisst wird.
Stimmt leider auch. Mit jedem Tag Java geht mir das bei C++ mehr und
mehr auf den Keks. Ich mag zwar Kekse im Allgemeinen sehr gerne, aber
ein Leben lang nur Kekse? Nein danke. Also mach ich, wenn ich
möchte/muss, halt mit beim großen C++-Zirkus und freue mich am Schluss,
wenn ich eine schöne Applikation entwickelt habe, die ohne pathologische
Casts auskommt und typsicher implementiert ist. Vielleicht möchte sich
der ein oder andere ja anschliessen? :-)
Stephan
@Stephan
Genau, dem schliess ich mich an. Bin zwar nicht mehr auf Java unterwegs,
aber ob nun Java oder C# ist in diesem Fall egal.
Manchmal wär mir doch ganz recht, wenn die Programmieren sich genau so
viel Gedanken machen würden, was sie programmieren, anstelle Argumente
zu suchen warum sie es in welcher Sprache tun.
cheers
Ich programmiere seit 12 Jahren, fing mit C++ an, ging später zu JAVA
über weil die Header-Dateien und Zeiger im C++ mir einfach zu blöd
wurden. Mit den neuen Multi-Core-Prozessoren in der heutigen Hardware
hat übrigens JAVA bald, wenn nicht schon jetzt, die Geschwindigkeit von
C++ erreicht.
Einen schönen Tag noch!
Salaar schrieb:
> Mit den neuen Multi-Core-Prozessoren in der heutigen Hardware> hat übrigens JAVA bald, wenn nicht schon jetzt, die Geschwindigkeit von> C++ erreicht.
Ich programmiere seit 25 Jahren und seit 15 Jahren auch mit Java und
jedes Jahr wieder erklaert die Java-Gemeinde, Java sei jetzt genauso
schnell oder schneller als C++. Wenn es um JIT geht, sehe ich da ja
zumindest theoretisch noch Ansaetze - aber wie soll schnellere Hardware
das Verhaeltnis zwischen den Sprachen verschieben?
Entscheidend ist doch, dass die Geschwindigkeitsunterschiede des
ausführbaren Programms zwischen Java und C++ so gering sind, dass es
irrelevant ist. Mal ist das eine schneller, mal das andere. Aber wen
interessiert das?
Entscheidenter ist doch, dass es eine Programmiersprache dem
Programmierer einfacher macht. Und da hat Java die Nase vorn, weil es
weniger zu Programmierfehlern verleitet und deshalb die
Entwicklungsgeschwindigkeit schneller ist. Man kann zwar auch mit Java
unsauber programmieren, aber das ist doch schwerer als mit C++.
Peter Stegemann schrieb:
> aber wie soll schnellere Hardware> das Verhaeltnis zwischen den Sprachen verschieben?
Rechenstarke Server (also nichts mit integrierten Storage, dass lassen
wir mal schön das sowieso schon vorhandene NAS machen) gibts heute ab
5000€. Das ist nicht mal ein Mannmonat Arbeitskraft, der bei der
Entwicklung mit Sprachen wie z.B. C++ im Vergleich zu Java deutlich
schneller verschlissen wird - und zwar schon lange, bevor überhaupt das
Thema Performance auf den Tisch kommt.
Stephan
Stephan wollte wohl zum Ausdruck bringen, daß es billiger ist, neue
schnellere Hardware zu kaufen statt Zeit in die Entwicklung performanter
Software zu stecken.
Das ist eine Sichtweise, die ziemlich verbreitet ist, gerade, wenn es um
Software im PC-Bereich geht.
Mit dieser Herangehensweise allerdings erlebt man im Embedded-Bereich
ziemlich schnell eine Bruchlandung.
Rufus t. Firefly schrieb:
> Stephan wollte wohl zum Ausdruck bringen, daß es billiger ist, neue> schnellere Hardware zu kaufen statt Zeit in die Entwicklung performanter> Software zu stecken.
Stimmt genau. Wobei man hier genau zwischen Performance und
Skalierbarkeit unterscheiden muss. Skalierbarkeit ist sprachunabhängig
in etwa gleich leicht zu erreichen, es liegt ja ein rein algorithmisches
Problem vor. (Wenn Fertigkomponenten im Spiel sind, ist es lediglich
dass altbekannte
Für-Sprache-X-gibts-ein-gutes-Toolkit-das-für-Sprache-Y-nicht-vorhanden-
ist-Problem).
Performance hingegen ist ein deutlich schwierigeres Optimierungsziel.
Alleine der Aufwand, Performance solide zu messen und zu vergleichen
(Lasttests!) ist bereits bei mittelkleinen Projekten sehr schnell so
groß, dass man dafür locker 10 Rechenknechte der 5000€-Klasse anschaffen
kann. (Selbst erlebt bei einer in Java entwickelten Web-Applikation.)
> Das ist eine Sichtweise, die ziemlich verbreitet ist, gerade, wenn es um> Software im PC-Bereich geht.
Ich würde sogar sagen: Diese Sichtweise ist genauso verbreitet wie
erfolgbringend, so lange bei Konzeption und Programmierung das Thema
Skalierbarkeit ausreichend berücksichtigt wurde.
> Mit dieser Herangehensweise allerdings erlebt man im Embedded-Bereich> ziemlich schnell eine Bruchlandung.
...was für mich persönlich den Embedded-Bereich zu einem attraktiven
Arbeitsumfeld, in dem ich mich gerne mehr beschäftigen würde, macht. Die
Assembler-Zeiten im jugendlichen Alter von 14-18 Jahren waren einfach zu
schön! :-)
Stephan
Rufus t. Firefly schrieb:
> Mit dieser Herangehensweise allerdings erlebt man im Embedded-Bereich> ziemlich schnell eine Bruchlandung.
Nicht nur im Embedded-Bereich, auch im Server-Bereich. Und dann gibt es
da auch noch den Unterschied zwischen Durchsatz und Latenz...
Nicht nur im embedded-Bereich. Auch wenn es richtig mathematisch wird
hat meiner Erfahrung nach C++ die Nase in Sachen Geschwindigkeit UND
Komfortabilität vorne.
Ich schätze dann sehr die Möglichkeit, mittels Operatorenüberladung
hocheffiziente und dennoch äußerst komfortable Datentypen schaffen zu
können, seien es komplexe Zahlen mit mehreren Imaginäranteilen oder
Filtergrundstrukturen.
In meinem Fall machten ca. 12% Geschwindigkeitsunterschied schon was
aus, da ich für haltbare Simulationsergebnisse eine entsprechend hohe
Anzahl an Simulationsläufen brauchte. Und so ein Simulationslauf dauerte
ca. 5 Tage....
Hinzu zum Orginal-Beitrag!!!
Ein so gigantischer Thread über Java und C++, etc.
Hier wurde ja so eine Menge Informationen über C/C++ und Java diskutiert
und damit auch sehr viel "Mist".
Ich finde weder Java noch C oder C++ besser. Beide Programmiersprachen
haben ihre Vor- und Nachteile.
Von der Verwendung und Verbreitung von Programmen dürfte C/C++ gewinnen.
Das resultiert schon aus der Tatsache der damit programmierten
Programmen.
Unix/Linux, Windows, etc. sind doch hauptsächlich in C/C++ programmiert.
(Oder?) Auch der Java-Compiler, die Runtime, etc. sind doch
höchstwahrscheinlich fast vollständig in C oder C++ programmiert.
Was ist eigentlich mit Basic?
Mit Basic kann man alles was man mit C/C++ auch kann.
Das Basic langsam ist ist auch falsch.
- Basic ist in viele "Unter-Basics" gesplittet. (Wähle einfach das beste
für dich aus.)
Ich persönlich nutze PureBasic.
Die damit erstellten Programme laufen hochperformant unter Window,
Linux, MacOs und Amiga.
Ich nutze es unter Linux und Windows.
Unter Linux benötigt PureBasic übrigens auch C (In Form des GCC).
C nutzt doch fast jeder Programmierer. -Warum?
Naja! Das OS nutzt du beim programmieren und die Dll`s,So`s,etc. des
Betriebssystems.
@ PureBasic_Freak,
privat kann jeder seine Programme in seiner Lieblingsprache schreiben,
aber im komerziellen Umfeld sieht die Welt anders aus. Da wird dir BASIC
nicht helfen, sondern da ist z.B. Java, C/C++ oder C# gefragt.
Schreib mal einen Treiber in PureBasic oder lass es auf einem
Mikrocontroller laufen.
BTW, GCC != C
Tobias da hast du wohl leider Recht.
Ich bin auch nur zufällig auf diesen Thread gestoßen.
Mit PureBasic dürfte man doch aber trotzdem Programme für einen x86/x64
tauglichen Microcontroller programmieren.
Der Binärcode ist doch auch nicht anders als bei C/C++ (oder?).
Nur das Linken müsste man Anpassen (oder?).
PureBasic dürfte den PellesC-Linker verwenden -glaube ich!
Bin Hobbyprogrammierer und habe leider von Microcontrollerprogrammierung
ansich kaum Ahnung.
Hahahahahaha!
Mensch, habe ich gelacht.
Der Thread ist lesenswert, von vorne bis hinten. Ich schätze, hier im
Forum wurde noch nie ausführlicher auf eine Frage geantwortet.
Zu Karl heinz Bucheggers Frage vom 18.11.2009:
Ich hab mir nach den ersten 10 Beiträgen eine geholt!
Das hier ist gedruckte Comedy.
Ich persönlich finde ja, dass die Sprache zur Aufgabe passen muss.
Wenn man in einen kleinen, langsamen µC viel Code quetschen muss, nimmt
man ASM. Wenn man auf dem gleichen System kompliziertere Aufgaben lösen
will, dann nimmt man C, weil das einfach verfügbar ist. Java ist ein
bisschen zu viel des Guten für einen µC.
Dafür kann man mit Java Webanwendungen programmieren und eine Anwendung
schreiben, die mit extrem wenig Aufwand auch auf einem Handy läuft.
Wenns schnell gehen soll, klicke ich mir was mit C# oder VB.NET
zusammen.
Ich glaube, die ganze Diskussion hätte es nicht (oder viel kürzer)
gegeben, wenn der Fragesteller seine Frage vor drei Jahren seine Frage
genauer gestellt hätte, wie z.B. "Ich will eine Anwendung schreiben, die
eine aufwendige GUI hat und trotzdem erst von einem Server geholt wird"
oder "Ich will in den AVR-Webserver unserer Gemeinde einen
SD-Kartenleser implementieren". Dann wäre die Sprachenwahl kaum ein
Problem gewesen.
Andererseits hätte ich sonst wohl nie
http://www.leo.org/information/freizeit/fun/pascal.html oder die
übergeordneten Seiten gefunden. Eine weitere Totlachfalle.
Beim Popcornessen zu lachen kann übrigens tödlich sein, wenn man sich
dabei verschluckt. So viel zu totlachen.
ROFL,
Valentin Buck
Hay (hoffe die Diskussion noch ma zum Laufen zu bringen.
Ich bin recht fortgeschritten in Sachen Java und habe jetzt mit C++
angefangen.
Erster Eindruck: GUT
Zweiter Eindruck: SCHEISSE
Ich meine nicht, dass die Sprache S******* ist (Nur für die, die mich
gleich wieder in den Boden stampfen wollen (VC Profi like)).
Die Grundlagen konnte ich schon so, im Prinzip wie Java.
NUR: Als ich mir das Programmieren von GUI's anschauen wollte hab' ich
nur gedacht: WOOOAAAS!?!?!?
Klar, mit Visual Studio hat man die Wahl, aber ich möchte mich weder auf
M$-Produkte einlassen, noch auf die kleinen Syntaxabweichungen, die MS
einbaut um einen an den VS-Compiller zu binden.
Also hab' ich mir QT angeschaut.
Schien erst mal gar nicht so schwer.
Etwas kryptisch, aber das war in Java anfangs auch so.
Und dann: WOOOOAAAAAASS?!?!?
1000 Milliarden Millionen Fehler! (Vielleicht auch 2-3 weniger)
Ich benutz den g++ Compiler auf den so viele andere Linux-Nutzer
schwören und habe QT-Code von einer Webseite der C++-Referenz kopiert.
Und dann kennt er zwar den QT-Pushbutton aber nicht die QT-VBox (oder
wie man dat richtig schreibt).
-Was habe ich da falsch gemacht?
-Kennt er die Bibliothek nicht (oder nur zur Hälfte?)
-Ist der g++ Compiler mit?
-Liegt's an Linux (kommt mir SEHR unwahrscheinlich vor)
-Schreibt man Compil(l)er mit einem oder zwei <l>?
Brauche Antworten.
Mit etwas Übung wirst Du feststellen, daß es sich bei der Qt um die
gegenüber Swing/AWT deutlich ausgereiftere Lösung handelt.
Sicher muß man bei den meisten IDE's die Includes per Hand einfügen,
aber das ist bei Java prinzipiell ähnlich.
Die Überlegenheit der Qt liegt nicht nur in der intuitiven Benutzung von
Komponenten (man ahnt meist, wie sie zu verwenden sind) und des
Signalisierungsmechanismuses, sondern auch in der Verwendung von enums,
so daß die Kontexthilfe nicht in tausenden Integervariablen "ertrinkt"
und man erst lange suchen muß, welches Attribut von den vielen plausibel
erscheinenden Alternativen denn nun richtig ist.
Auch wenn es um die Wiederverwendung von grafischen Elementen geht hat
die Qt mit dem Signal-Slot-Mechanismus gegenüber ActionListenern die
Nase vorn.
Danke für die schnelle antwort, aber das erklärt leider noch nicht,
warum der g++ Compiler manche Komponenten kennt und manche nicht.
Die Fehlermeldung war schon beim include.
Kannst du mir vielleicht eine gute IDE für c++ empfehlen?
Guasto schrieb:> Danke für die schnelle antwort, aber das erklärt leider noch nicht,> warum der g++ Compiler manche Komponenten kennt und manche nicht.
Mit "Komponenten" meinst du hier Klassen?
> Die Fehlermeldung war schon beim include.
Was für ein innclude?
Wie wäre es, wenn du Code und Fehlermeldung mal zeigst? Ich habe keine
Lust auf Ratespielchen.
Guasto schrieb:> -Was habe ich da falsch gemacht?> -Kennt er die Bibliothek nicht (oder nur zur Hälfte?)> -Ist der g++ Compiler mit?> -Liegt's an Linux (kommt mir SEHR unwahrscheinlich vor)> -Schreibt man Compil(l)er mit einem oder zwei <l>?
1. Vermutlich nicht viel, ich hatte auch anfangs extreme Schwierigkeiten
mit Qt, da viele Tutorials, die man im Internet findet einfach
qualitativ nicht gut sind (vorsichtig ausgedrückt). Insgesamt erhält man
leicht den Eindruck, der Tutorialschreiber benutzt bestimmte #includes
intuitiv, ohne sich im klaren zu sein, was er eigentlich included.
Gute Tutorials sind in meinen Augen diese beiden:
http://zetcode.com/tutorials/qt4tutorial/http://doc.qt.nokia.com/4.6/tutorials.html
2 und 3.
Lies die Tutorials ;-) Bei C++ erscheint es bei bestimmten Fehler
normal, dass sie tausende Meldungen auswerfen. Allerdings ergeben sie
alle einen Sinn und man wird dir helfen können, wenn du sie postest.
4.
Zumeist nicht.
5. Compiler
Hoffe, ich konnte helfen!
Erst mal danke für die Antwort.
Die Tutorials sind wirklich ganz gut, aber ein Problem tritt nach wie
vor auf:
main.cpp:1:17: error: QtGui: No such file or directory
main.cpp: In function ‘int main(int, char**)’:
main.cpp:5: error: ‘QApplication’ was not declared in this scope
main.cpp:5: error: expected ‘;’ before ‘app’
main.cpp:6: error: ‘QWidget’ was not declared in this scope
main.cpp:6: error: expected ‘;’ before ‘window’
main.cpp:7: error: ‘QLabel’ was not declared in this scope
main.cpp:7: error: ‘label’ was not declared in this scope
main.cpp:7: error: expected type-specifier before ‘QLabel’
main.cpp:7: error: expected ‘;’ before ‘QLabel’
main.cpp:8: error: ‘QLineEdit’ was not declared in this scope
main.cpp:8: error: ‘lineEdit’ was not declared in this scope
main.cpp:8: error: expected type-specifier before ‘QLineEdit’
main.cpp:8: error: expected ‘;’ before ‘QLineEdit’
main.cpp:10: error: ‘QHBoxLayout’ was not declared in this scope
main.cpp:10: error: ‘layout’ was not declared in this scope
main.cpp:10: error: expected type-specifier before ‘QHBoxLayout’
main.cpp:10: error: expected ‘;’ before ‘QHBoxLayout’
main.cpp:13: error: ‘window’ was not declared in this scope
main.cpp:15: error: ‘QApplication’ is not a class or namespace
main.cpp:17: error: ‘app’ was not declared in this scope
main.cpp: At global scope:
main.cpp:3: warning: unused parameter ‘argc’
main.cpp:3: warning: unused parameter ‘argv’
make: *** [main.o] Fehler 1
Selbst als C++ Anfänger merke ich, dass der Compiler die QT-Elemente
schlicht nicht kennt.
Ich habe aber so ziemlich alle Bibliotheken runtergeladen und der Code
ist 1 zu 1 von der Nokia Seite.
Bin echt ratlos...
Wird wohl auch Zeit, dass ich mir ein anständiges Buch zum Thema kaufe.
Den Code jedoch verstehe ich (größtenteils), ich find's aber echt viel
wirrer als bei java...
Dann fang doch mit dem ersten Fehler an; der Rest sind Folgefehler.
Was will mir "main.cpp:1:17: error: QtGui: No such file or directory"
sagen?
Der Compiler findet eine Datei nicht!
Welche findet er nicht? Die Datei "QtGui".
Hast du eine Vorlage aus einem Tutorial? Wahrscheinlich steht da
nicht "#include <QtGui>", sondern "#include <QtGui.h>", kann das
sein?
Wenn der Compiler die Headerdatei nicht findet, ist es klar, daß
er anschließend die QApplication etc. nicht kennt, die in der
Headerdatei vereinbart sind.
Notfalls kann man ja mal nach der passenden Datei manuell
suchen und sehen, wie sie heisst.
Außerdem wäre es hilfreich, wenn du Fehlermeldungen und
Originalquelltexte zeigen würdest, die auch zusammengehören.
Bei dem obigen Quelltext steht das #include in der ersten Zeile,
laut Fehlermeldung in Zeile 17.
Das macht die Suche nach den Fehlern nicht leichter...
Guasto schrieb:> Ich habe aber so ziemlich alle Bibliotheken runtergeladen und der Code> ist 1 zu 1 von der Nokia Seite.
Die Nokia-Seite ist groß.
Ein etwas genauerer Link wäre sinnvoller.
Guasto schrieb:
> Ich habe aber so ziemlich alle Bibliotheken runtergeladen und der Code> ist 1 zu 1 von der Nokia Seite.
Und was hast du mit diesen Bilbiotheken dann gemacht? Wie sieht dein
.pro-File aus? Oder verwendest du kein qmake? Wie sieht die
Compiler-Kommandozeile aus? Stimmen die include-Pfade?
Klaus Wachtler schrieb:> Hast du eine Vorlage aus einem Tutorial? Wahrscheinlich steht da> nicht "#include <QtGui>", sondern "#include <QtGui.h>", kann das> sein?
Eher nicht. Die Qt-Header haben keine .h-Endung.
> Wenn der Compiler die Headerdatei nicht findet, ist es klar, daß> er anschließend die QApplication etc. nicht kennt, die in der> Headerdatei vereinbart sind.
Richtig. Die Fehler sind allesamt Folgefehler des nicht gefundenen
Headers.
> Bei dem obigen Quelltext steht das #include in der ersten Zeile,> laut Fehlermeldung in Zeile 17.
Die Fehlermeldung bezieht sich nicht auf Zeile 17, sondern auf Spalte 17
in Zeile 1.
Rolf Magnus schrieb:> Die Fehlermeldung bezieht sich nicht auf Zeile 17, sondern auf Spalte 17> in Zeile 1.
Peinlich, aber ich nehme es zur Kenntnis :-(
Klaus Wachtler schrieb:> Rolf Magnus schrieb:>> Eher nicht. Die Qt-Header haben keine .h-Endung.>> Qt3 mit .h, Qt4 ohne
Das stimmt, aber Qt3 hab ich ausgeschlossen.
Guasto schrieb:> Erst mal danke für die Antwort.> Die Tutorials sind wirklich ganz gut, aber ein Problem tritt nach wie> vor auf:>> main.cpp:1:17: error: QtGui: No such file or directory
Okay, ohne jetzt zu fragen, welche Linux Distribution du nutzt, gehe ich
mal davon aus, dass du entweder eine vorkomilierte Version hast, oder
sie kompilliert hast und tippe einfach mal darauf, dass du Qt nicht zum
"PATH" hinzugefügt hast.
Wie man das macht, steht im Zetcode Tutorial:
http://zetcode.com/tutorials/qt4tutorial/introduction/
Da mal einen Blick auf "Install" werfen.
Hab Hoffnung, wir kriegen das schon hin ;-)
Nutzt du übrigens Ubuntu? Falls ja, könnte ich heute Abend mal meinen
Ubuntu-Rechner anschmeißen und dir eine Schritt für Schritt Anleitung
basteln, das würde das ganze sicher verkürzen!
Boah, ich komm' kaum noch mit :-):
-Ja, ich benutze Ubuntu 10.04 (Netbook Edition)
-Nein, ich habe nicht QT zu irgend einem Path hinzugefügt
-@Klaus Wachtlauer:
SO sieht meine .pro File aus (ja, ich benutze qmake):
######################################################################
# Automatically generated by qmake (1.07a) Sat Jul 10 21:15:18 2010
######################################################################
TEMPLATE = app
CONFIG -= moc
INCLUDEPATH += .
# Input
SOURCES += main.cpp
Ich kann damit nicht wirklich was anfangen.
Hab' ich jetzt was vergessen?...
Danke erst mal, für die vielen Antworten!
Guasto schrieb:> Hab' ich jetzt was vergessen?...
Ja.
1. Hättest du von Anfang an einen neuen Thread aufmachen sollen.
2. Es wurde auch nach QTDIR (echo $QTDIR) und qmake (qmake -v) gefragt.
(die qmake-Version müsste bei 2.* sein)
3. Er heißt Klaus Wachtler.
4. Rolf Magnus hat die Frage gestellt und nicht Klaus Wachtler.
5. Der Fehler kommt wohl direkt nachdem make-Aufruf. Es wäre gut, wenn
du alle Meldungen nach make posten würdest. Ich vermute davor
müssten die include-Pfade etc. mit ausgespuckt werden.
6. Ist Qt in der Version 4 überhaupt installiert?
Ansonsten passt alles. ;-)
Das ist mein *pro (von meinem qmake).
Aua...
Okay, immer der Reihe nach:
1.: Hab' wohl keinen Thread aufgemacht, weil ich total hin und weg war
von der Diskussion, welches die beste Sprache ist. Ich weiß, das(?s) ist
keine gute Begründung, aber ich habe keine andere.
2.: DAS muss ich überlesen haben im Wirbel der Antworten.
WAS ist QTDIR und was bedeutet das -v hinter qmake?
3.: Sorry, wegen dem falschen Namen, war keine Absicht. (Siehe Punkt 4)
4.: Man, bin echt zerstreut grade.
Bitte das zu entschuldigen, wir reisen grade quer durch Amerika und ich
finde nur selten eine Möglichkeit ins Internet zu kommen. Bin auch total
fertig.
5.: Ja, wenn ich unter 'Dateisystem' suche, finde ich solche Ordner wie:
-qt4
-libqt4... usw.
6.: Okay, ich installiere die neue Version von qmake... wie geht das?
Hab's mit apt-get install probiert, aber der findet kein qmake.
In der package Verwaltung finde ich auch nichts, außer das, was ich
schon habe.
Danke, dass du alles zusammengefasst hast, hoffe, ich habe nicht SCHON
WIEDER etwas vergessen...
Die Ausgaben sind interessant, wobei in deinem pro-File ja schon die
falsche qmake-Versionsnummer drinsteht.
Aber mach mal, fühlt sich gut an. ;-)
Und wo wir schon dabei sind, was gibt folgendes aus:
1
echo $PATH
Die Option -v bei Shell-Kommandos gibt meist die Version aus.
5. Du bist wohl generell neu unter Linux. Denn keine Ahnung wie, aber
apt hätte dir das auch verraten. ;-)
(ich nutze ein anderes Linux mit einem anderen Paketmanagment.)
Du bist glaube ich gerade dabei zu vergessen die komplette
make-Meldung mit anzugeben, zumindest kommt bei mir der g++-Aufruf
mit raus.
So sollte die Meldung anfangen, da kommt aber noch mehr...
1
make
2
g++ -c -m64 -pipe -march=x86-64 -mtune=generic
6. Vermutlich ist sie installiert, nur vielleicht passen die Pfade (also
die PATH-Variable) nicht. Wie hast du Qt4 installiert? Ich hoffe mit
apt.
Zu den anderen Punkt, passt schon und viel Spaß bei den Amis. ;-)
eklige Tunke schrieb:> 6. Vermutlich ist sie installiert, nur vielleicht passen die Pfade (also> die PATH-Variable) nicht. Wie hast du Qt4 installiert? Ich hoffe mit> apt.
Nachtrag: Bei Ubuntu sind die Pakete aufgeteilt, du brauchst vermutlich
auch qt4-devel (so oder so ähnlich sollte es heißen) und in diesem Paket
müsste das richtige qmake mit bei sein.
Vielleicht kannst du qt3-devel ja deinstallieren, dann dürfte/sollte ja
nur noch ein qmake auf dem System sein.
-Also bei QTDIR kommt bei mir nichts, nur eine neue Zeile.
-qmake -v zeigt:
Qmake version: 1.07a (Qt 3.3.8b)
Qmake is free software from Trolltech ASA.
Okay, der scheint tatsächlich noch Qt3 zu benutzen.
-Bei echo $PATH zeigt er:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
Was bedeuted das? Was ist das für ein Pfad?
-Stimmt, ich habe nur die Fehlermeldung gepostet, dachte, nur die sei
wichtig.
-QT4 ist installiert, keine Ahnung mehr, wann oder wie weiß ich nicht.
-Habe noch mal versucht, das qmake zu installieren (die neue Version).
Ich weiß jetzt, warum das mit apt nicht geklappt hat.
Das Programm heißt qt4-qmake.
Ich habe nur qmake bei apt eingegeben, da hat er nicht gefunden.
Nun, wo das gelöst ist habe ich (TADA!) ein neues Problem.
sudo apt-get install qt4-qmake
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Status-Informationen einlesen... Fertig
qt4-qmake ist schon die neueste Version.
Die folgenden Pakete wurden automatisch installiert und werden nicht
länger benötigt:
libqt4-opengl-dev qt4-designer libqt4-dev
Verwenden Sie »apt-get autoremove«, um sie zu entfernen.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht
aktualisiert.
Ich bin auf der alten Version, aber das wiederrum sagt mir, dass die
neue auch installiert ist.
-Welche Distribution benutzt du?
Also meinen Link (qtforum.de) hast du nicht gelesen oder funktionierte
das nicht?
Kannst du den qt4-qmake oder qmake-qt4 in der Shell aufrufen? Wenn
ja benutze dieses qmake mal.
Das sind jetzt aber Probleme mit apt und da muss ich passen... aber da
wird sich schon wer melden.
ich würde an deiner stelle mal synaptic / aptitude aufmachen und erstmal
jeden qt krempel runterschmeißen, und dann die qt4 sachen mit den
development packages neu installieren
Falls ein Ubuntu-Nutzer anwesend ist, könnte er ja mal schreiben, wie
die qt3-dev-Pakete genau heißen. Guasto scheint nicht nur neu in der
Qt-Welt zu sein, sondern auch neu in der Linux-Welt.
eklige Tunke schrieb:> Kannst du den qt4-qmake oder qmake-qt4 in der Shell aufrufen?
Das Programm heißt qmake-qt4, obwohl das Paket qt4-qmake heißt.
D. I. schrieb:> libqt4-dev
Das ist das wichtigste Paket. Das zieht auch automatisch qmake mit
drauf. Wenn das installiert ist und man qmake-qt4 aufruft, sollten die
Qt-Header automatisch gefunden werden.
@Guasto: Hast du irgendwann mal versucht, von Hand eine Qt zu
installieren, von der vielleicht nocht Reste auf der Festplatte
rumliegen?
Rolf Magnus schrieb:> Hast du irgendwann mal versucht, von Hand eine Qt zu> installieren, von der vielleicht nocht Reste auf der Festplatte> rumliegen?
Weiß er nicht mehr, siehe:
Guasto schrieb:> -QT4 ist installiert, keine Ahnung mehr, wann oder wie weiß ich nicht.Rolf Magnus schrieb:> qmake-qt4
Ich werde jetztmal warten, bis Guastro es mit "qmake-qt4" versucht hat.
Guasto schrieb:> -Bei echo $PATH zeigt er:> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games>> Was bedeuted das? Was ist das für ein Pfad?
Bei dir siehst du mehrere Pfadeinträge in deiner Pfad-Variable, die
Pfad-Variable heißt PATH und mit echo $PATH wird der Inhalt von der
Pfad-Variable ausgegeben. Wenn du in einer Konsole einen Befehl
eingibst, dann schaut Linux in den Pfaden aus PATH nach, ob das
Programm in einem der Ordner ist.
Für alles weitere siehe http://de.linwiki.org/wiki/Linuxfibel saoagr mit
Suchfunktion ;-)
Nun mal eine kleine Anmerkung meinerseits:
Ich programmiere seit ein paar Jahren unter C für Win32/Linux und µC.
C ist eine gute Sprache, wenn es darum geht, ressourcenschonend,
hardwarenah und "fehlerbewusst" zu programmieren, was heißt, dass man
genau wissen muss was man tut. C ist zum Erlernen einer Sprache am
sinnvollsten, da man seine Kenntnisse auch auf C++ (und ggf. Java)
übertragen kann.
So widmete ich mich vor ein paar Monaten der Sprache Java. Ich habe ein
Buch gelesen (Java ist auch eine Insel: nicht empfehlenswert, da zu
theoretisch) und fing an, Konsolenanwendungen mit der IDE Eclipse zu
schreiben.
Vorweg: Eclipse ist für mich eine experimentelle IDE, die auf mich
keineswegs professionell wirkt, wenn man sie etwa mit Visual Studio
vergleicht. Schon alleine das Starten einer EXE ohne Installation löst
bei mir Magenkrämpfe aus.
Nachdem ich dann eine andere IDE (Netbeans) verwendete, um für mein
java-fähiges Handy eine Applikation zu schreiben, ging das
experimentieren weiter. Man findet im Netz so gut wie garnichts über die
Programmierung in Java für EmbeddedGeräte (Handys). Kein Tutorial,
nichts. Klassen, die sich jemand einfallen ließ und sie undokumentiert
an die Menschheit losgelassen hat.
Die Probleme mit den JREs mal ganz außer Acht gelassen.
Als ich dann nach der Enttäuschung Wochen später wieder auf Java
zurückgriff um eine einfache Oberfläche zu programmieren, hatte ich
garkeine Lust mehr. Man findet in Eclipse keine (mitgelieferte und
kostenfreie) Möglichkeit, eine Benutzeroberfläche zu erstellen.
Da lobe ich mir Visual Studio. Egal in welcher Sprache. das
.NET-Framework erlaubt einem ja schließlich den Zugriff auf alle
Bibliotheken, egal, ob man C#, C++ oder VB programmieren will.
Java ist für mich zum tabu-Thema geworden.
Kann mir einer mal bitte sagen, in welcher Sprache denn die Java-Runtime
geschrieben wurde? Sicherlich nicht in Java ;-)
Und zu denken, dass die Hardware schnell/gut genug ist, um auf keine
Ressourcen zu achten, finde ich programmiertechnisch unästhetisch und
dem Endkunden gegenüber egoistisch.
Gruß
Lothar schrieb:> Vorweg: Eclipse ist für mich eine experimentelle IDE, die auf mich> keineswegs professionell wirkt, wenn man sie etwa mit Visual Studio> vergleicht. Schon alleine das Starten einer EXE ohne Installation löst> bei mir Magenkrämpfe aus.
Was besseres gibt's doch nicht. Wozu willst du unbedingt ein
Installationsprogramm das dir quer über die Festplatte ein Dutzend
Verzeichnisse vollmüllt, wenn es auch ohne geht?
Andreas Schwarz schrieb:> Lothar schrieb:>> Vorweg: Eclipse ist für mich eine experimentelle IDE, die auf mich>> keineswegs professionell wirkt, wenn man sie etwa mit Visual Studio>> vergleicht. Schon alleine das Starten einer EXE ohne Installation löst>> bei mir Magenkrämpfe aus.>> Was besseres gibt's doch nicht. Wozu willst du unbedingt ein> Installationsprogramm das dir quer über die Festplatte ein Dutzend> Verzeichnisse vollmüllt, wenn es auch ohne geht?
Finde ich auch. Am besten meiner Meinung nach:
Programmordner mit allem was das Programm benötigt inkl. .exe, einen
eintrag im Nutzerverzeichnis mit den persönlichen Einstellungen und
evtl. einen eintrag im $PATH. Hach die Welt könnte so einfach sein
Lothar schrieb:> Man findet in Eclipse keine (mitgelieferte und> kostenfreie) Möglichkeit, eine Benutzeroberfläche zu erstellen.
Und du bist dir sicher, dass du Eclipse benutzt? Meins kann jedenfalls
Swing, AWT und SWT. Sicher, es gibt kein bequemes Point-and-Click
Fenster, aber wenn man halbwegs mit den Layouts umgehen kann, ist das
absolut kein Hindernis.
Lothar schrieb:> Kann mir einer mal bitte sagen, in welcher Sprache denn die Java-Runtime> geschrieben wurde? Sicherlich nicht in Java ;-)
Sorry, aber das zeigt doch irgendwie, dass du trotz des "theoretischen"
Buches nicht viel von der Funktionsweise einer Programmiersprache
verstanden hast.
Ich persönlich bin auch eher Anhänger der C/C++ Fraktion, da sie einfach
besser zu meinem Stil passen, aber ein ernsthafter Blick zu Java lohnt
sich meiner Meinung nach. Einiges ist sicher besser, anderes schlechter,
aber auf jedenfall ist vieles ANDERS, und das rechtfertigt m.E.
keinesfalls ein sinnloses gebashe mit Halbwissen auf die eine oder
andere Sprache.
"Java ist auch eine Insel" ist ein recht brauchbares Buch, wenn man JAVA
grundsätzlich verstanden hat. Für Anfänger wie Umsteiger lohnt sich da
doch eher ein Grundlagenbuch, um die Besonderheiten der Sprache erstmal
zu verstehen.
Ich empfehle: "Einstieg in Java 6"
Da sind sogar Beispiele drin, wie der geneigte Benutzer eine
Benutzeroberfläche erstellen kann (kostenlos!) ;-)
>Vorweg: Eclipse ist für mich eine experimentelle IDE, die auf mich>keineswegs professionell wirkt,
Wenn ich mir dein Rumgeheule und Deine unqualifizierten Aussagen in
Deinen Postings hier so durchlese, dann wirkst Du auf mich ebenfalls
keineswegs professionell. Du solltest Deine Aussagen mal ein wenig
untermauern.
Dein Rumgeheule zeigt im Übrigen, dass Du anscheinen bei jedem kleinen
Problem an die Hand genommen werden musst.
Also: was genau ist denn an eclipse unprofessionell? Ich kenne Netbeans
und eclipse, und finde beide sehr brauchbar.
Dass Du bemängelst, dass eclipse einfach so, ohne großartige
Installationsorgie läuft, ist übrigens peinlich. Sind das_ _Deine
Kriterien für Professionalität. Vermutlich machst Du Professionalität
auch noch am belegten Plattenplatz fest: unter 2GB ist's Spielkram ;-)
OK, ich pack in mein nächstes Programm ein paar fette High-Res-Bilder
rein, extra für Leute wie Dich...
hallo zusammen,
Ich habe die Seite ganz neutral gelesen und will mich auch nicht äußern
ob das kindisch oder Profis ist.
Meine Meinung ist : Ich bin Hardwareentwickler in einem Maschinenbau
unternemhmen. Wir benutzen Microcontroller und es wird in Assembler
programmiert. Es gibt kein GUI.
Mittlerweile haben wir Siemens Step7 SPS. Die Jungs bei uns
programmieren zwar Step7 aber die denken immer hardwarenah als ob man
mit Assembler programmiert.
C wurde von Anfang an nicht benutzt.
wir haben für unsere KameraSteuerung Visual Basic Express benutzt und
funktioniert.
Jetzt wollen wir alles über Ethernet steuern und kommt anscheinend C und
TCP/IP in Frage.
Was ich sagen will : Der Kunde schreibt uns nie vor wie wir unsere
Aufgaben lösen, sondern sie wollen nur Ergebnisse sehen (
funktionierende Anlage ohne Abstürtze). Wie man ans Ziel ankommt ist
allen EGAL!
Ich habe auch meine Probleme gehabt und dachte: ohh mein Gott wo fange
ich jetzt an? Java, C, C++, Assembler, C# VB, Mysql, PHP, Javascript und
und und und..
Hallooo man kann nicht alles beherschen, aber zumindest man kann sich in
einer Sprache spezialisieren und versuchen viele Aufgaben damit zu lösen
und wenn es nicht geht, dann halt wechseln!! Das Programmieren ist nur
die halbe Miete. Das logische Denken und pfiffige Ideen wie man das
Problem löst, sind eher gefragter in professionellen Umfeld!
Unser manager gibt mir Deadline wann ich fertig sein muss, aber er sagt
nicht du muss die Sprache und diese verwenden!!
Unser Assembler-Hardcore Programmierer sagt : Lösen Sie das Problem
zunächst im Kopf oder auf Papier, denken Sie logisch und strukturiert,
dann erst fangen Sie an mit dem Programmieren!! Syntaxe kann man
lernen!!
FAZIT : sicherlich kann man mit nur einer Sprache viel erreichen aber
warum kam keine auf die Idee mehrere Sprachen zu verwenden? die Stärke
vielleicht von Java und C++ gemeinsam zu benutzen! warum immer diese
unsinnige Diskussion. Es gibt Tools und Sprachen, die haben sich gut
etabliert und man kommt ans Ziel mit solchen Tools einfacher und
schneller.
Meine Meinung nach :
Web Entwicklung : xHTML, CSS, Javascript
Datenbanken : in Offline Modus Access, und übers Web Mysql und PHP
Micro Controller ohne GUI : Assembler und C
Mess- Steuertechnik mit Windows GUI : C++
reine Anwendungssoftware Desktop oder mobile Anwendungen : Java
Warum auch nicht : Microcontroller mit C programmieren und ein GUI in
JAVA??
Ich denke in der Zeit von C und Assembler wo man ein OOP und GUI
vermisst hat, kam der C++ als Retter und dann gabs die Kombination von
C/C++
Ich kann verstehen dass viele sagen : OK wenn C++ nur für GUI
Hardwareanwendungen gedacht ist, dann kann ich auch das mit JAVA und ist
C++ überflüssig!!
Naja : NEVER TOUCH A RUNNING SYSTEM !! warum soll unser Entwickler nach
20 Jahre Assembler Erfahrung zu java wechseln?? das ist auch nicht
wirtschaftlich ;-)))
deshalb sind die meisten hier nur Amateure Programmierer!!
ich habe zwar keinen plan von java und c++.
aber jedes größere java programm das ich bisher getestet habe läuft
irgendwie schwammig :/
eclipse, jdownloader...
ka warum das so ist aber ich mag es nicht.
Thread beobachten
Seitenaufteilung abschalten