Suche eine Programmiersprache!
-
ness schrieb:
@OT:
LUZA schrieb:
volkard schrieb:
auf keinen fall C, wenn du dir den C++-stil nicht total versauen willst.
weshalb versaut man sich den c++-stil, wenn man erst eine prozeduale sprache lernt und dann eine objektorientierte?
ich habe mit diesem lego-zeugs angefangen, dann nqc ( fürs lego, aber c-syntax)
und dann c++ gelernt und ich muss ehrlich sagen, ich halte meinen c++-stil für sehr gut, und die kentnisse in c helfen eher...Ist "dieses Lego zeugs" mindstorms? Damit hab ich auch angefangen (bin dann aber gleich auf "echtes" C++ umgestiegen). War schon geil, grüne und rote und tolle gelbe und blaue blöcke und der robo Fährt die linie lang
.Das schönste war die Roboter zusammen zu bauen, wie in der guten alten Lego zeit
-
otze schrieb:
was soll man dazu sagen, ausser müde zu lachen? Wenn Java "hart" OO ist, dann will ich garnicht wissen, was Smalltalk für dich ist ;). Und mal davon abgesehen, dass OOP nicht "alles in Klassen stecken" ist, wies java tut.
Ultrahart? Noch härter?
Ja, eigentlich sollte ich von Smalltalk voll das OO-Rohr kriegen!
Hab mich bis jetzt noch nicht damit beschäftigt.
Klar, Java ist "alles in Klassen stecken". Du und ich, wir wissen, daß wahre OO-Programmierung im Kopf stattfindet.
otze schrieb:
ähm...nein? mit C++ kannst du dich zuerst drumrum drücken, und wenn du bereit dafür bist, wirst du auch keine schwierigkeiten mehr haben diese "Tücken" zu verstehen.
Sicher, so geht es auch. Vielleicht denke ich nur, daß man besser zuerst C lernen sollte, weil ich's selber so gemacht hab!
otze schrieb:
C++ ist keine OO sprache, sie ist Objektbasiert! Und templates wurden nicht gegen die makro orgien eingesetzt, sondern sins spätestens seit dem letzten standard ein mächtiges Werkzeug für generische Programmierung!
Na ja, im Prinzip sind templates ja gar nix anderes als Makros (aus der Sicht des Compilers).
Für generische Programmierung wäre Ada 95 aber besser geeignet! Leider ist das viel zu umständlich, da ist C++ definitiv sehr viel lesbarer.
Und klar, mit der STL oder selbergeschriebenen Templates kann man sehr gut generisch programmieren.
otze schrieb:
Lassen wir halt mal einfach ausser acht, dass Java je nach problem gleich schnell oder sogar schneller ist
Hmm ... das liegt aber nur an den bescheidenen Template-Klassen der STL. Z.B. die String-Klasse ist 10 mal so langsam wie meine eigenen, woran das bloß liegt?
-
Hmm ... das liegt aber nur an den bescheidenen Template-Klassen der STL. Z.B. die String-Klasse ist 10 mal so langsam wie meine eigenen, woran das bloß liegt?
mal davon abgesehen, dass "10mal so langsam" ganz schlechter stil ist...die string klassen der stl sind auf keinen spezialfall optimiert, sie versuchen alles gut zu können, und das geht halt nicht ;). Ausserdem ist das sehr implementationsabhängig, gibt ja verschiedene anbieter der stl...
-
Power Off schrieb:
Hmm ... das liegt aber nur an den bescheidenen Template-Klassen der STL. Z.B. die String-Klasse ist 10 mal so langsam wie meine eigenen, woran das bloß liegt?
Wenn du ne os-unabhängig, allgemeingültig verwendbare Stringklasse
hast, die 10 mal schneller als die handelsüblichen STL-Implementierungen sind,
solltest du dich mal als Chef-Entwickler bei Microsoft, Borland oder... bewerben.
Ein sechstelliges Jahresgehalt wär doch sicher nicht schlecht oder.Wer angibt hat mehr vom Leben
-
Redhead schrieb:
Wenn du ne os-unabhängig, allgemeingültig verwendbare Stringklasse
hast, die 10 mal schneller als die handelsüblichen STL-Implementierungen sind,
solltest du dich mal als Chef-Entwickler bei Microsoft, Borland oder... bewerben.
Ein sechstelliges Jahresgehalt wär doch sicher nicht schlecht oder.Mit den Funktionen der C-Standard-Library und einem "greedy allocation scheme" (also "gierigem Speicherzuweisungsschema") kann man das ohne Weiteres machen. Predictive, also voerhersagende, Speicherverwaltung ist ganz leicht zu implementieren und vermeidet unnötige Reallocs.
So eine Klasse muß nicht unbedingt eine Template-Klasse sein. Schließlich braucht ja meistens nur Strings die 8-Bit oder Unicode-Zeichen enthalten (und letztere kann man ja über UTF-8 auch als 8-Bit codieren).
Sechsstellige Gehälter sind in Amerika für erfahrene Programmierer (senior programmers) gang und gäbe.
-
Bisher sind mirdiese "superschnellen" Strings noch nicht in freien oder
kommerziellen (STL-)Implementierungen begegnet. Obs da vielleicht auch
Nachteile gibt.Wir sind hier aber nicht in USA und haben daher auch nicht diese Standards.
-
Redhead schrieb:
Wir sind hier aber nicht in USA und haben daher auch nicht diese Standards.
Ja leider; aber vielleicht kommt das noch irgendwann, wenn die Regierung das Sozialsystem weiter abbaut. Wenn der Kündigungsschutz aufgehoben wird, gilt das ja wahrscheinlich beiderseitig. In den USA kann man von einen Tag auf den anderen kündigen, man wirft bloß ein Kärtchen in einen Briefkasten und fertig. Deswegen sind die Firmen in den USA auch so erpicht darauf, ihre Angestellten zu behalten. Deswegen zahlen sie auch mehr.
Aber in den USA geht zur Zeit das Schreckgespenst des Outsourcings um -- Firmen verlagern z.B. Entwicklungzentren knallhart ins Ausland (nach Indien oder China). Ob sich das wirklich rechnet, ist eine andere Frage.
Bin jedenfalls noch immer froh, in Deutschland zu sein ...
-
<Habe nun hier etwas über Python gelesen!>
C ist für den Anfang ganz gut, man muß es halt können. Wenn man C oder besser noch C++ kann,
ist es leicht, andere Sprachen zu lernen, denn gerade C++ ist derart
kompliziert, daß es einem den Atem verschlägt, wenn man sieht, wie man
Programme, die in C++ Bildschirmseiten füllen (gerade Listenverarbeitung,
Komprehension oder auch Funktionen als Argumente) mit Python in ein paar
Zeilen hinschreiben kann.
-
Redhead schrieb:
Bisher sind mirdiese "superschnellen" Strings noch nicht in freien oder
kommerziellen (STL-)Implementierungen begegnet. Obs da vielleicht auch
Nachteile gibt.Man kann ja den Code für die String-Klasse auch in Assembler implementieren.
Ich denke, der Hauptgrund warum die STL String-Klasse so gelöst ist, damit sich Iteratoren und Funktionsschablonen darauf anwenden lassen.
Warum Dir bisher noch keine selbstgeschriebenen String-Klassen über den Weg gelaufen sind, ist mir allerdings ein Rätsel? Vielleicht, weil Du C++ noch nicht kanntest als es die STL noch gar nicht gab?
-
Power Off schrieb:
C ist eine kleine, einfache und simple Sprache, und schneller erlernbar als C++
hä? u know what ur talking about?
-
Sovok schrieb:
Power Off schrieb:
C ist eine kleine, einfache und simple Sprache, und schneller erlernbar als C++
hä? u know what ur talking about?
Was soll an C kompliziert sein?
Ein Präprozessor, Strukturen und Unions, Funktionen und einfache Ausdrücke, und das war's schon.
Einfach und effektiv.
C++ kann natürlich viel mehr, ist aber auch um Größenordnungen komplexer.
-
es läßt sich übrigends mehr damit anfangen als n hello world zu schreiben
visual basic is "simpel" aber c nich
-
Sovok schrieb:
es läßt sich übrigends mehr damit anfangen als n hello world zu schreiben
visual basic is "simpel" aber c nich
Ich hab in C schon Riesen-Softwarepakete geschrieben, Tonnen von Libraries und Programmen, und finde es trotzdem simpel.
Erst seit's die STL gibt ist C++ wirklich komfortabel geworden, früher hab ich lieber in C programmiert.
-
Power Off schrieb:
Ich benutz Visual C++ (2002) zu Hause seit 2002, und beruflich seit ca. 1996. Bis jetzt gab es keinen Grund für mich, dem Compilerpaket besondere Qualitäten zuzusprechen. Der alte MS C Compiler für DOS hatte auch schon so seine Macken, und den habe ich vorher benutzt (1991-1993).
Ja, ich weiß, daß in der Standardversion kein Optimizer drin ist, jammerschade, was! Wer gibt schon € 1000 für einen Compiler aus? (*Sarkasmus*)
Dir ist klar das der 2002er C++ Compiler von Microsoft nur nen leicht aufgebohrter 6er ist - und beide sind an sich net wirklich gut. Der 2003er dagegen ist wieder richtig gut, und den optimizing Compiler kannst dir sogar kostenlos von Microsoft besorgen
-
nur mal so...
wir haben in der schule in info mit javascript, vb und php gebastelt...ich hab aber ja bekanntlich privat so einiges mehr drauf
, und meine einfach:
c und c++ sind ehrliche sprachen.
nimm mal z.b. vb als vergleich: du fängst mitten in einem riesenhaufen von der ide erzeugtem code an, kommst ( zumindest in der schule) nicht über den horizont deines buttons hinaus...du hast einfach was, ohne zu wissen, wie es kommt. oder willst du mir erklären, dass der normale vb-hobby-programmierer irgendwie weiss, wie das dialogfeld erzeugt wird?
ist einfach nicht die ganze wahrheit, alles vorgefertigt und doch etwas zu schwammig, man versteht nicht wirklich, wie das programm abläuft, der pc arbeitet, wenn man mit java, vb, oder sonstewas anfängt.
c und c++ kommen dem wahren da schon viel näher.
klar, man muss sich an die syntax halten, einige strukturen beachten, und das alles knallhart. aber das ist keineswegs ein nachteil. mit c/c++ kann eben nicht
jeder vollhonk mal eben was schönes zaubern ( ei wie nett, ein mit vb erstelltes dialogfeld... und das in nur 2 min arbeit...
), man muss es verstehen. und eben dieses grundlegende verständnis fürs programmieren bekommt man mit diesen schwamm-sprachen nicht, obwohl es für guten code und entwicklung sehr wichtig ist... 
-
Talla schrieb:
Dir ist klar das der 2002er C++ Compiler von Microsoft nur nen leicht aufgebohrter 6er ist - und beide sind an sich net wirklich gut. Der 2003er dagegen ist wieder richtig gut, und den optimizing Compiler kannst dir sogar kostenlos von Microsoft besorgen
Der 2002er und der 2003er sind fast identisch. Hab schon mit beiden gearbeitet (und auch mit dem 6er).
Der 2002er hat die Version 7.0 und der 2003er die Version 7.1, aber sonst ...
Doch, der 2003er ist mehr standardkonform als der 2002er.
-
Power Off schrieb:
Ich benutz Visual C++ (2002) zu Hause seit 2002, und beruflich seit ca. 1996. Bis jetzt gab es keinen Grund für mich, dem Compilerpaket besondere Qualitäten zuzusprechen. Der alte MS C Compiler für DOS hatte auch schon so seine Macken, und den habe ich vorher benutzt (1991-1993).
Ja, ich weiß, daß in der Standardversion kein Optimizer drin ist, jammerschade, was! Wer gibt schon € 1000 für einen Compiler aus? (*Sarkasmus*)
jit, callstack, 1A-profiling, ram-bearbeitung on the fly, speicherbreakpunkte sind für dich keine besonderen qualitäten?
ich glaub du hast es mal dringen nötig ne runde auf ring 0 zu programmiern oder mit code composer/gdb zu debuggen damit du die vorzüge des vc++ zu schätzen lernst
-
Sovok schrieb:
jit, callstack, 1A-profiling, ram-bearbeitung on the fly, speicherbreakpunkte sind für dich keine besonderen qualitäten?
ich glaub du hast es mal dringen nötig ne runde auf ring 0 zu programmiern oder mit code composer/gdb zu debuggen damit du die vorzüge des vc++ zu schätzen lernst
Ich bezog mich eher auf den C++ Compiler und nicht auf den Debugger, Profiler, die CLR usw.
Der gdb ist übrigens gar nicht so übel: Man kann damit beliebige Ausdrücke berechnen lassen, die sich auf das gestoppte Programm beziehen. Einziger Wermutstropfen: Mangelhafter Multithreading-Support.
Der Microsoft Debugger ist mehr oder weniger Standardware, wenn er die Funktionen nicht hätte, bräuchte man ihn gar nicht erst zu benutzen. Memory Breakpoints, Memory Editor, Call Stack usw. gehören nunmal dazu.
Debuggen in Nachrichten ist nach wie vor unmöglich (dafür müßte es in Windows einen Window Procedure Decoupler geben).
Der JIT ist Teil der .NET CLR, und hat mit VC++ nix zu tun. Außerdem beziehe ich mich auf die native C++ Programmierung (ohne .NET).
Deswegen auch die Frage: Welches Profiling?
-
ich benutz noch im geschäft und privat den vc6 und hab bisher ned das bedürfniss nach nem neuen
jedenfalls gibts da auch ohne .net jit auf sämtlichen c++ code
profiling hat er auch integriert mit sehr guter auflistung des rechenzeitanteils für jede funktion... bei mehreren dlls halt nur per kommandozeile aber kann ich mit lebenich würd nich sagen, dass das ganze zeug "einfach so" dazugehört
benutz mal ne andere entwicklungsumgebung... dann wirste manche features vermissen und wenn auch nur wie beim code composer so is, dass du immer nur ein byte im speicher auf einmal ändern kannst anstatt einfach direkt reinzuschreiben wie beim vc++beim gdb hat mich vorallem das frontend gestört... saulangsam und total unintuitiv
-
Sovok schrieb:
beim gdb hat mich vorallem das frontend gestört... saulangsam und total unintuitiv
Da haste voll recht, die hätten mittlerweile schon längst wenigstens eine ncurses-Version oder eine GUI Version machen können. Aber das kommt ja vielleicht irgendwann noch.
Die Menüsteuerung vom GDB find ich auch zum kotzen.