Glaubensfrage C / C++
Christoph Freiburger
ich hoffe nicht gleich gesteinigt zu werden, aber nach einer Woche
Internetrecherche bei google, diversen Programmierclubs und selbsternannten
Programmierpropheten bin ich am Rande der Resignatrion:
Macht es Sinn, als 100% Anfänger, ohne jegliche Programmierkenntnisse, c++
zu erlernen und wie gehe ich am besten vor?
Ich möchte mir ein Programm erstellen, um Notizen und Adressen zu verwalten.
Ich weiß, so etwas gibt es en masse, aber ich möchte allen Ballast beiseite
lassen und eine kleine, feine Anwendung nur auf meine Bedüfnisse abgestimmt,
erstellen.
Vielleicht ist c/c++ auch völlig blödsinnig dafür, aber wenn ich 5 Experten
frage, bekomme ich 15 verschiedene Antworten.
Mir raucht schon der Kopf, obwohl ich noch gar nicht angefangen habe zu
programmieren :-)
Viele Grüße
Christoph Freiburger
Vinzent 'Gadget' Hoefler
>Macht es Sinn, als 100% Anfänger, ohne jegliche Programmierkenntnisse, c++
>zu erlernen
Nein.
>und wie gehe ich am besten vor?
Nimm Smalltalk.
Vinzent.
Falk Hueffner
> Macht es Sinn, als 100% Anfänger, ohne jegliche
> Programmierkenntnisse, c++ zu erlernen
Nein, die Sprache ist viel zu kompliziert und fehlertraechtig. Nimm
eine einfache, robuste Sprache wie Scheme oder Python.
--
Falk
Claus Reibenstein
> Macht es Sinn, als 100% Anfänger, ohne jegliche Programmierkenntnisse, c++
> zu erlernen und wie gehe ich am besten vor?
Warum sollte es keinen Sinn machen?
> Ich möchte mir ein Programm erstellen, um Notizen und Adressen zu verwalten.
Dafür sind beide Sprachen geeignet.
> Vielleicht ist c/c++ auch völlig blödsinnig dafür, aber wenn ich 5 Experten
> frage, bekomme ich 15 verschiedene Antworten.
Das ist normal[tm] :-)
> Mir raucht schon der Kopf, obwohl ich noch gar nicht angefangen habe zu
> programmieren :-)
Nimm eine der beiden Sprachen (oder auch eine ganz andere) und leg
einfach mal los. Wenn Du nicht mehr weiter kommst, gibt es irgendwo in
de.comp.lang.* sicher eine geeignete Gruppe, die Dir weiter helfen kann.
Falls Du Dich für C entscheidest, hast Du sie schon gefunden. Für C++
ist news:de.comp.lang.iso-c++ zuständig. Bei anderen Sprachen musst Du
selber mal schauen.
Gruß. Claus
Kurt Watzka
> Hallo,
>
> ich hoffe nicht gleich gesteinigt zu werden, aber nach einer Woche
> Internetrecherche bei google, diversen Programmierclubs und
> selbsternannten Programmierpropheten bin ich am Rande der Resignatrion:
>
> Macht es Sinn, als 100% Anfänger, ohne jegliche Programmierkenntnisse, c++
> zu erlernen und wie gehe ich am besten vor?
Sinn kann man nicht machen. Eine vernünftige Auswahl aus C++ ist meiner
Erfahrung nach als Einsteigersprache recht brauchbar. Das soll bedeuten,
dass man aus C++ eine einfach zu handhabende Lehrsprache herausziehen
kann. Besonders wenn das Ziel des Lernens eines der von C++ unterstuetzten
Denkmuster ist, ist es nicht falsch, mit C++ als Einstiegssprache
anzufangen.
Wenn das langfristige Ziel ohnehin ist, C++ zu lernen, dann ist C++ eine
recht gute erste Programmiersprache. Wenn man einfach nur irgendeine
Programmiersprache lernen will, dann ist eine Sprache, die strenger als C++
ist, meiner Meinung nach besser geeignet.
>
> Ich möchte mir ein Programm erstellen, um Notizen und Adressen zu
> verwalten.
>
> Ich weiß, so etwas gibt es en masse, aber ich möchte allen Ballast
> beiseite lassen und eine kleine, feine Anwendung nur auf meine Bedüfnisse
> abgestimmt, erstellen.
>
Den "Ballast" in einer Anwendung, die alles gewünschte kann, einfach
nicht zu nutzen ist immer noch vernünftiger als gerade C++ zu lernen,
um eine Adress- und Notizverwaltung zu erstellen. Selbst Programmieren
hat einen Sinn, wenn es das gewünschte nicht gibt. Eine Anwendung auf
einem fertigen Datenbanksystem ist vernünftiger als eine "von Grund
auf" in einer Hochsprache wie C++ entwickelte Lösung.
Wenn Du um des Programmieren willens Programmieren lernen willst, dann
ist es sicher eine gute Idee, mit einer Adressverwaltung anzufangen,
wenn Du eine Adressverwaltung brauchst. Wenn Du um der Adressverwaltung
willen Programmieren lernen willst, dann lohnt sich _jeder_ Suchaufwand
tausendfach.
Kurt Watzka
Carsten Krueger
>Vielleicht ist c/c++ auch völlig blödsinnig dafür, aber wenn ich 5 Experten
>frage, bekomme ich 15 verschiedene Antworten.
;-)
Nimm Ada
Gruß Carsten
--
http://learn.to/quote - richtig zitieren
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://oe-faq.de/ - http://www.oe-tools.de.vu/ - OE im Usenet
http://www.spamgourmet.com/ - Emailadresse(n) gegen Spam
Wolfgang Kaufmann
Hallo,
> Macht es Sinn, als 100% Anfänger, ohne jegliche Programmierkenntnisse, c++
> zu erlernen und wie gehe ich am besten vor?
Definiere Sinn. Und darüber wie *Du* am besten vorgehst kann man hier
nur Mutmaßungen äußern. Im Zweifelsfall würde eher eine für Anfänger
erfahrungsgemäß 'angenehmere' Sprache empfehlen. Abgesehen davon,
bist Du mit C++ spezifischen Fragen hier offtopic.
> Vielleicht ist c/c++ auch völlig blödsinnig dafür, aber wenn ich 5 Experten
> frage, bekomme ich 15 verschiedene Antworten.
Und?
Wolfgang.
--
"Es gibt Dinge, die man bereut, ehe man sie tut. Und man tut sie doch."
-- Christian Friedrich Hebbel
Christoph Freiburger
>
> Hallo,
>
> > Macht es Sinn, als 100% Anfänger, ohne jegliche Programmierkenntnisse,
c++
> > zu erlernen und wie gehe ich am besten vor?
>
> Definiere Sinn. Und darüber wie *Du* am besten vorgehst kann man hier
> nur Mutmaßungen äußern. Im Zweifelsfall würde eher eine für Anfänger
> erfahrungsgemäß 'angenehmere' Sprache empfehlen. Abgesehen davon,
> bist Du mit C++ spezifischen Fragen hier offtopic.
>
> > Vielleicht ist c/c++ auch völlig blödsinnig dafür, aber wenn ich 5
Experten
> > frage, bekomme ich 15 verschiedene Antworten.
>
> Und?
>
>
> Wolfgang.
Prima, eine qualifizierte und kompetente Antwort, besten Dank!
beren
na ja, Glaubensfrage, wenn jemand eine Programmiersprache bevorzugt,
seine Sache!
Wenn er Sie Preist und Vergleiche zu anderen Sprachen zieht, ist das
gut, weil man sich dann eventuell besser Entscheiden kann welche man
dan doch lernen will. :-)
Wie bin ich vor einem Jahr auf ANSI- C gekommen? - Ich wollte mit
einer Machinennahe Programmiersprache beginnen, aber Assembler wollte
es nicht sein, desahalb habe ich mich informaiert und mir gleich ein
Buch über ANSI- C gekauft und ein halbes Jahr ungefähr gelesen und
jedes Kapitel bearbeitet.
Jetzt lerne ich am zweiten Buch nähmlich K&R II plus Lösungsbuch. :-)
Vielle Sagen immerm an sollte mit einer Scriptsprache wie
beipsielsweise Perl, PHP oder JavaScript - ist jedem einer
Entscheidung.
Christoph ich würde dir raten einfach ersteinmal mit einer Programmier
- und/oder einer Sciptsprache zu beginnen und dir die ersten
eigentarten einer Programmiersprache an zu eigenen.... ;-)
mfg
andre manikofski
Vinzent 'Gadget' Hoefler
>Wie bin ich vor einem Jahr auf ANSI- C gekommen? - Ich wollte mit
>einer Machinennahe Programmiersprache beginnen, aber Assembler wollte
>es nicht sein,
Unlogisch.
Vinzent.
Alexander Bartolich
> Unlogisch.
> Vinzent.
Warum signierst du deine Postings doppelt?
Vinzent 'Gadget' Hoefler
Tue ich nicht. Wie man von hardwarenah auf C kommt, *ist* unlogisch.
Vinzent.
Vinzent 'Gadget' Hoefler
>Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> wrote:
>>>Vinzent 'Gadget' Hoefler schrieb:
>>>> Unlogisch.
>>>> Vinzent.
>>>Warum signierst du deine Postings doppelt?
>> Tue ich nicht.
>
>Die Sache mit dem verstehen ironischer Bemerkungen ist so eine Sache. ;-)
Ich habe das schon verstanden. Eben drum.
>> Wie man von hardwarenah auf C kommt, *ist* unlogisch.
>
>Was soll daran unlogisch sein? Die meisten hardwarenahen Programme die
>ich kenne sind in C geschrieben.
Beweis durch Behauptung? Ich kenne auch einige nicht wenige
hardwarenahe Programme, die in (Turbo-)Pascal geschrieben wurden. Das
macht den Assoziationsschritt von "hardwarenah" zu Pascal noch lange
nicht logisch.
>Die wenigsten davon allerdings portabel,
>also nicht reines ISO-C. ;-)
Ach, tatsaechlich?
>Wenn man direktes Assemblerprogrammieren mal weglässt, was schwebt dir denn
>für eine hardwarenahe Sprache vor
<URL:http://www.efr.li/~vh/tmp/elan520-programmable_address_region.ads>.
Reine Deklaration, kein Code, laeuft, ist standardkonform (wenn auch
zielarchitekturbedingt natuerlich nicht portabel). *Das* nenne ich
hardwarenah. Aber eine Sprache, die noch nicht mal Binaersystem kennt
als hardwarenah zu bezeichnen, finde ich dann doch eigenwillig.
Ausser, man kennt nichts anderes...
>die auch nur annähernd so verbreitet ist wie C?
Seit wann hat Verbreitung etwas mit Eignung zu tun? Windows ist auch
relativ "verbreitet". Was es fuer den Servereinsatz aber noch lange
nicht geeignet macht.
Vinzent.
Roland Damm
Christoph Freiburger hat geschrieben:
> Macht es Sinn, als 100% Anfänger, ohne jegliche
> Programmierkenntnisse, c++ zu erlernen und wie gehe ich am
> besten vor?
Ja, wenn...
Also ich bin zu C gekommen, nachdem ich schon C64-BASIC und
ein bischen Pascal in der Schule kannte. Später erster
eigender PC, endlich Programme schreiben können, die mehr als
20kb Daten haben können und schon wieder Schrott:
64kb-Segmente, also keine Arrays größer als 64k. Dann habe ich
mich auf die Suche nach einem OS gemacht, wo es das Problem
nicht mehr gibt -> OS/2. Dann habe ich mich auf die Suche nach
einem Compiler gemacht -> GCC. Dann habe ich C gelernt.
Ich will nicht sagen, daß ich sonderlich fit in C bin, fühle
mich in der Sprache jedoch an sich ganz wohl. Nur irgendwann
kam dann C++ auf. Anderew Sprachen vernachlässige ich jetzt
mal. Der Unterschied ist diese Objektorientiertheit. Ich ein
paar mal versucht, etwas in C++ zu machen und bin gescheitert.
Den letzten Schock hat mir M$'s VisualC verpasst, eine
Entwicklungsumgebung, deren Maches es aufgegeben haben, diese
zu dokumentieren.
Mein Problem beim Umstieg auf C++ ist diese im idealfall
volkommen andere Herangehensweise an Probleme. Ich sehe ein
Problem und sehe gleich, wie ich das einteile, welche
Datenstrukturen ich brauche und mit welchen Funktionen ich
zwischen den verschiedenen Datenstrukturen 'übersetze' also
Eingabe in Ausgabe wandeln und so. Objekte sehe ich nicht. Ich
würde mich da als zu sehr C-versäucht bezeichnen.
Deswegen würde ich auch C und C++ nicht so einfach in einem
Atemzug nennen, die beiden Sprachen gehen zwar auseinander
hervor und haben quasi die gleiche Syntax, aber die Art, wie
man ein Problem löst ist im Idealfall bei den beiden Sprachen
sehr unterschiedlich. Ich finde den herkömmlichen Ansatz von C
viel logischer und verständlicher. Andere, die mit einer
OO-Sprache groß geworden sind, sehen das genau umgekehrt.
Will sagen: deine Entscheidung für C oder für C++ könnte eine
Entscheidung fürs Leben sein:-)). Übrigens, wenns um
Zukunftssicherheit geht, die OO-Hype ist wohl auch ein wenig
am Abebben. Auch wenn vor ein paar Jahren alles von OO und C++
geschwärmt hat, ist C doch bestimmt nicht tot.
Allerdings wenn es um Zukunftssicherheit geht und keine
Einwände bezüglich OO bestehen, dann ist derzeit wohl Java
ganz groß angesagt.
> Ich möchte mir ein Programm erstellen, um Notizen und
> Adressen zu verwalten.
Klar, irgendein Problem sollte man sich vornehmen an dem man
exemplarisch die Sprache lernt. Nur sollte man sich nicht zu
viel vornehmen.
> Ich weiß, so etwas gibt es en masse, aber ich möchte allen
> Ballast beiseite lassen und eine kleine, feine Anwendung nur
> auf meine Bedüfnisse abgestimmt, erstellen.
Könnte es sein, daß dir ein richtig fertig semiprofessionell
aussehendes Programm vorschwebt? Hmm, bei solchen Programmen
ist das Userinterface nicht selten der mit Abstand
aufwändigste Teil des Gesamtprojektes, bei einer
Adressverwaltung würde ich sogar sagen, er macht 99% aus. Ich
weis nicht, ob sowas der beste Einstieg ist. Immerhin ist das
auch der Teil des Programms, der am Meisten
Entwicklungsumgebung/Betriebssystem/Library-abhängig ist. Am
Ende glaubt man, C++ zu beherrschen, kann jedoch nicht viel
mehr, als bei VC die richtigen Buttons zu drücken. Gut, ist
natürlich Geschmackssache. Was ich bisher so programmiert
habe, war immer nur des Ergebnisses wegen interessant, nicht
des Aussehens wegen. Aber sicher sind die Zeiten der
Kommandozeile zu Ende. Auch da muß ich wohl ohne eigene
Erfahrungen allerdings wieder Java erwähnen. Da ist die
Programmierung einer Benutzerschnittstelle jedenfalls
systemunabhängig, weil es nämlich die ganze Sprache ist und
weil GUI-Programmierung in der Sprache schon von vornherein
eingebaut ist.
> Mir raucht schon der Kopf, obwohl ich noch gar nicht
> angefangen habe zu programmieren :-)
Das ist ärgerlich. Das Problem hatte ich nicht, als ich
angefangen habe, gabs nur zwei Programmiersprachen: BASIC oder
Assembler:-).
CU Rollo
--
Hier entsteht in Kürze eine neue Sig-Präsenz.
Florian Weingarten
> Aber sicher sind die Zeiten der Kommandozeile zu Ende.
Woas?
Flo
--
Give me about 10 seconds to think for a minute.
Florian Weingarten / Use PGP! (0x65C91285)
Jirka Klaue
...
> als ich
> angefangen habe, gabs nur zwei Programmiersprachen: BASIC oder
> Assembler:-).
Algol? Pascal? LISP?
Jirka
Roland Damm
Jirka Klaue hat geschrieben:
> > als ich
> > angefangen habe, gabs nur zwei Programmiersprachen: BASIC
> > oder Assembler:-).
>
> Algol? Pascal? LISP?
Ich habe mit einem C64 angefangen. Gut, irgendwann kam mal ein
Pascal-Compiler reingeschneit, aber der war so unsäglich
bezüglich seiner Fehlererkennung, daß es unerträglich war. Man
durfte keinen Syntaxfehler im Programm haben, der mehr als 5
Zeilen vom Sourcecodeende entfernt ist, sond bekam man die
eigentliche Fehlermeldung vor lauter nachlaufender Folgefehler
nicht mehr zu Gesicht. Andere Sprachen für C64 sind mir nicht
so bekannt, gut, einen LOGO-Interpreter habe ich wohl mal
gesehen, aber das kann man wohl weniger als Programmiersprache
bezeichnen. Ach ja, und BASIC-Compiler gabs wohl auch, aber
das ändert an der Sprache nichts.
Roland Damm
Florian Weingarten hat geschrieben:
> > Aber sicher sind die Zeiten der Kommandozeile zu Ende.
>
> Woas?
Na gut, nicht vollständig. Bei CGI-Binarys macht man ja
letztlich auch nur Kommandozeilenprogramme. Aber die Zeiten,
als es üblich war, ein Programm durch Eintippen seines Namens
zu starten sind doch offensichtlich nahezu vorbei. Wenn ich
mich im Bekanntenkreis so umschaue, da gibt es durchaus einige
Leute, die ohne Computer nur schwer leben können, wenn man
denen aber sagt 'dann tippst du folgendes ein:...' wissen sie
nicht, wie oder wo. Wieviele % der Windows-User kennen diese
Kommandozeile überhaupt? Ich denke der Anteil derjenigen, die
diese Eingabeaufforderung regelmäßig benutzen liegt heutzutage
bei vieleicht noch 10%. Der Prozentsatz derjenigen, die wissen
wie man pipet oder Ausgaben in Dateien umleitet oder so,
dürfte nochmals eine Größenordnung geringer sein. Unix-User
jetzt mal ausgeschlossen, da sind die Verhältnisse anders.
Aber auch Unix entwickelt sich stark zu einem
Endanwenderorientiertem System mit Bedienbarkeit ohne
Kommandozeile.
Bernd Laengerich
> Das ist ärgerlich. Das Problem hatte ich nicht, als ich
> angefangen habe, gabs nur zwei Programmiersprachen: BASIC oder
> Assembler:-).
_Das_ glaube ich nicht, Basic wurde erst 1962 erfunden, davor gab es
bereits:
Fortran (1954)
Algol (1958)
Cobol (1959)
Lips (1959)
APL (1961)
Quelle:
http://www.igd.fhg.de/~pinsdorf/prog1/03_historie_programmiersprachen.pdf
Bernd
Vinzent 'Gadget' Hoefler
>Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> wrote:
>>>> Wie man von hardwarenah auf C kommt, *ist* unlogisch.
>>>Was soll daran unlogisch sein? Die meisten hardwarenahen Programme die
>>>ich kenne sind in C geschrieben.
>
>> Beweis durch Behauptung? Ich kenne auch einige nicht wenige
>> hardwarenahe Programme, die in (Turbo-)Pascal geschrieben wurden. Das
>> macht den Assoziationsschritt von "hardwarenah" zu Pascal noch lange
>> nicht logisch.
>
>Zu Pascal nicht, bei Turbo-Pascal ist das was anderes.
Richtig. Es ist damit aber genauso etwas anderes wie ein
nicht-Standard-C.
>>>die auch nur annähernd so verbreitet ist wie C?
>
>> Seit wann hat Verbreitung etwas mit Eignung zu tun?
>
>Seit immer.
Es gibt ausreichend Gegenbeispiele, die Dich in der Praxis widerlegen.
Leider gibt es naemlich aus den verschiedensten Gruenden einen ganzen
Haufen ungeeigneter Loesungen.
>Wenn du für ein Zielsystem ausser Assembler und C-Compiler
>nichts bekommst, dann eignet sich der C-Compiler in der Regel wesentlich
>besser als eine Sprache für die du erst selbst den Compiler/Interpreter
>implementieren müsstest.
Ja. Allerdings kenne zumindest ich relativ wenige Systeme, fuer die
das zutrifft und die fuer solche Dinge angebotene Sprache dann auch
wirklich noch ein echtes Standard-C ist.
>Wobei nicht nur die Zahl der Compiler entscheidend ist, sondern auch
>die der Entwickler. :-)
Nein, das ist ein klassisches Nullargument. Jemand, der $PROBLEM
ausschliesslich in einer einzigen Sprache loesen kann/will, ist kein
Entwickler, sondern ausschliesslich ein Idiot. Ja, ich weiss, dass
Deines auch ein typisches Argument von HR-Managern ist.
>> Windows ist auch
>> relativ "verbreitet". Was es fuer den Servereinsatz aber noch lange
>> nicht geeignet macht.
>
>"eignen" ist immer relativ. ;-)
>Da ja in der realen Welt auch im Serverbetrieb durchaus verbreitet muss es
>offensichtlich einige Eignungskriterien erfüllen.
"Nicht geeignet" war hier nicht in der Bedeutung von "komplett
ungeeignet" gemeint. Offensichtlich *kann* man in einer C-aehnlichen
Syntax tatsaechlich auch hardwarenah programmieren (wie man das eben
mittels einer Pascal-aehnlichen Syntax auch in Turbo-Pascal konnte).
Das Ergebnis ist dann aber meist weder auch nur ansatzweise portabel,
noch ist die Loesung besonders bequem. Da es um Groessenordnungen
geeignetere Ansaetze gibt, halte ich C damit eben fuer "nicht
geeignet". Kurz: Ich kann die urspruengliche Schlussfolgerung von "C
und hardwarenah" nicht nachvollziehen, ergo: Sie ist unlogisch.
Vinzent.
Klaus Reinke
> Moin,
>
> Jirka Klaue hat geschrieben:
>
>> > als ich
>> > angefangen habe, gabs nur zwei Programmiersprachen: BASIC
>> > oder Assembler:-).
>>
>> Algol? Pascal? LISP?
>
> Ich habe mit einem C64 angefangen. Gut, irgendwann kam mal ein
> Pascal-Compiler reingeschneit, aber der war so unsäglich
> bezüglich seiner Fehlererkennung, daß es unerträglich war. Man
etwa das Ding von Data-Becker? Es erzeugte echten Maschinencode,
der Compiler selbst war in Basic geschrieben, der Waaahnsinn.
es gab einen Forth-Compiler, der war ganz witzig, aber das einzig
wahre war ein Assembler der über die Computerzeitschrift 'mc'
zu bestellen war, oder der Butterfly-Monitor: rudimentäre Assembler
Programmierung und Disassemblierung auf wenigen KBytes, heute belegt
schon vim eine größere Swap-Datei.
cu Klaus
--
Gib Geenfood keine Chance --> www.bite-back.org
Bremst die WTO
www.zuffnick.de <--- Gib dem Wahnsinn eine Chance
Florian Weingarten
> Lips (1959)
Meinst du Lisp? Oder ist Lips irgendwas was ich verpasst habe? Frage nur,
weil ich Lips noch nie gehoert habe.. :-)
Florian Weingarten
> als es üblich war, ein Programm durch Eintippen seines Namens
> zu starten sind doch offensichtlich nahezu vorbei. Wenn ich
Das seh ich anders.
> mich im Bekanntenkreis so umschaue, da gibt es durchaus einige
> Leute, die ohne Computer nur schwer leben können, wenn man
> denen aber sagt 'dann tippst du folgendes ein:...' wissen sie
> nicht, wie oder wo. Wieviele % der Windows-User kennen diese
> Kommandozeile überhaupt? Ich denke der Anteil derjenigen, die
Reden wir von Windows und meinst du mit Kommandozeile DOS oder reden wir von
der Linux/Unix Konsole? Die ist naemlich meiner Meinung nach alles andere
als ausgestorben.
Fup2p weil offtopic
Juergen Ilse
Florian Weingarten <f...@go.cc> wrote:
> Roland Damm <rolan...@arcor.de> wrote:
>> Aber sicher sind die Zeiten der Kommandozeile zu Ende.
> Woas?
Er meint "die Menschheit verbloedet, und zwar so sehr, dass sie von der
Faehigkeit, sich mittels Worten auszudruecken wieder auf 'Kleinkind-Niveau'
zurueckfaellt und mittels 'zeigen' und 'da' rufen (sprich anklicken) die
eigenen Wuensche zum Ausdruck brigen wird". Ich hoffe allerdings, dass
wir nicht zu "Legasthenikern und Maeusle-Schiebern" mutieren werden.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Das Netz ist Freude. Es ist Ekstase, die jeden einzelnen Nerv erglühen
läßt. Es ist Duft, den man fühlt. Es ist ein Bild, das man riecht.
Es ist Erfüllung - ein Geschmack, neben dem alles andere schal ist.
("Netzreiter-Preisung" aus dem Buch "Der Netzparasit" von Andreas Brandhorst)
Juergen Ilse
Die ersten "hoeheren Programmiersprachen" waren AFAIK Fortran, Lisp und Algol.
C kam erst sehr viel spaeter (Anfang der 70er Jahre, als diese 3 Sprachen
schon fast 10 Jahre auf dem Buckel hatten). Auch Basic kam erheblich spaeter
als diese 3 (und ist aus einem abgespeckten Fortran-Dialekt hervorgegangen).
von den 3 "alten" hoeheren Programmiersprachen duerfte wohl Algol am ehesten
"anfaengertauglich" gewesen sein, aber es ist heutzutage auch am ungebraeuch-
lichsten. Ich halte C nicht unbedingt fuer gut geeignet, um die Grundzuege
des Programmierens zu erlernen (und Assembler, Fortran und Basic auch nicht).
Ada waere von den heute ueblichen Sprachen vielleicht fuer den Einstieg in
die Programmierung ganz gut geeignet.
Markus Raab
> dürfte nochmals eine Größenordnung geringer sein. Unix-User
> jetzt mal ausgeschlossen, da sind die Verhältnisse anders.
> Aber auch Unix entwickelt sich stark zu einem
> Endanwenderorientiertem System mit Bedienbarkeit ohne
> Kommandozeile.
Nicht, wenn man effektiv arbeiten will. Das Konzept von piping,
Programme mit minimalistische Ausgaben, Filter, Jobs (bg, fg, &) ist
einfach genial. Es gibt bei GUIs noch nichts was nur annähernd an diese
Effektivität herankommen kann (ausser grafische Konsolen*G*).
Wenn ich über 2 Bilder oder Lieder konvertieren will, irgendwelche
Loggingdateien auswerten oder Textstreams filtern will springe ich
sofort zu der Kommandozeile.
mfg Markus
--
Linux, the choice | Abhängigkeit ist heiser, wagt nicht, laut
of a GNU generation -o) | zu reden. -- Shakespeare, Rome und Julia
Kernel 2.4.22-mh /\ |
on a i686 _\_v |
Roland Damm
Markus Raab hat geschrieben:
> Wenn ich über 2 Bilder oder Lieder konvertieren will,
> irgendwelche Loggingdateien auswerten oder Textstreams
> filtern will springe ich sofort zu der Kommandozeile.
Hatte ich nicht schon gesagt, daß die Verhältnisse bei Unix
etwas anders sind? Aber selbst da, der Großteil der Programme,
die ich benutze, arbeiten mit und auf einer grafischen
Oberfläche. Und ich bin auch ganz zufrieden damit.
Und ich sprach ja auch nur von der Großzahl der Benutzer. Die
Leser dieser NG dürften wohl kaum repräsentativ für den
Durchschnittsbenutzer sein. Also von dir (der du als
Linux-Nutzer ohnehin schon ein Exot bist) auf den Durchschnitt
zu schließen, ist etwas hergeholt.
Roland Damm
Juergen Ilse hat geschrieben:
> Er meint "die Menschheit verbloedet, und zwar so sehr, dass
> sie von der Faehigkeit, sich mittels Worten auszudruecken
> wieder auf 'Kleinkind-Niveau' zurueckfaellt und mittels
> 'zeigen' und 'da' rufen (sprich anklicken) die eigenen
> Wuensche zum Ausdruck brigen wird". Ich hoffe allerdings,
> dass wir nicht zu "Legasthenikern und Maeusle-Schiebern"
> mutieren werden.
Na ja, so weit würde ich nicht gehen. Man kann kaum läugnen,
daß das herumklicken mit der Maus auf Symbolen oder in
PullDown-Menüs eine einfachere Bedienung ermöglichen kann
(nicht muß). Vor allem dann, wenn man mit Programmen arbeitet,
deren Funktionsumfang so groß ist, daß man die meisten
Funktionen so selten braucht, daß man sie sich kaum merken
kann. Grafische Oberflächen ermöglichen das Wiederfinden von
Funktionen anhand von Aussehen, Farbe, Ort - alles Dinge, die
sich ein Mensch besser merken kann, als zusammenhanglose Namen
von Befehlen (weil Abkürzungen) oder Kommandozeilenparametern.
Mal ganz zu schweigen von den vielen Kommandozeilenprogrammen,
die bei ihrem Aufruf noch nicht einmal sagen, wozu sie da
sind, selbst wenn man sie mit --help aufruft.
Bernd Laengerich
> weil ich Lips noch nie gehoert habe.. :-)
Read my lips?
Bernd, dem die Wechstaben verbuchselt sind.
Bodo Thiesen
>Macht es Sinn, als 100% Anfänger, ohne jegliche Programmierkenntnisse, c++
>zu erlernen und wie gehe ich am besten vor?
>
>Vielleicht ist c/c++ auch völlig blödsinnig dafür, aber wenn ich 5 Experten
>frage, bekomme ich 15 verschiedene Antworten.
Gut, dann analysieren wir mal Dein Problem:
1. Du kannst nicht Programmieren
2. Du kennst keine Programmiersprache
(Ja, das sind zwei verschiedene Dinge)
Wenn Du nun Programmieren lernen willst, wirst Du nicht umhin kommen, auch
mindestens eine Programmiersprache zu lernen. Da am Anfang aber das
Hauptproblem ist, z.B. auf die Idee zu kommen, wie man 10 Zahlen aufsteigend
sortiert, sollte man anfangs eine Sprache benutzen, die nicht zu formal ist
(Lies: Bei der man nicht an zu viele Dinge denken muß, die man am Anfang eh
nicht versteht.)
Bsp.
Ein einfaches C-Programm:
begin 644 hello.c
#include <stdio.h>
int main(void) {
printf("Hello World.\n");
}
end
Jetzt verrate ich auch noch, daß das Programm »Hello World.« ausgeben soll.
Damit dürfte es auch für Dich als Anfänger kein Problem sein, die Zeile
»printf("Hello World.\n");« zu verstehen, ok, vielleicht das »\n«, wenn man
das aber einfach mal verdoppelt, oder ganz weg lässt, wird man recht schnell
merken, daß es einen Zeilenvorschub bewirkt.
Gut, daß war der einfache Teil. Aber was bedeutet dieses Verdammte
»#include <stdio.h>«? Und was ist dieses »int main(void) {« und das »}«? Ist
doch völlig unnötig. Ich will doch nur eine Zeile ausgeben, oder?
Nun, als Vergleich: Die gleiche Funktionalität in BASIC ausgedrückt:
begin hello.bas
PRINT "Hello World."
end
Wow, es geht ja. Keine Zeile, die nicht unmittelbar zur Problemlösung gehört.
Gut, vergleichen wir das jetzt mal mit C++. Zuerst mal, müssen wir hier eine
Klasse finden. Ich kann mir hier beim besten Willen keine Sinnvolle Klasse
ausdenken, das ist wohl der Grund, warum die meisten hello.cpp Programme auch
fast genauso wie die hello.c Programme aussehen. Aber ich mache jetzt mal
künstlich eine Klasse auf, eine Klasse für das gesamte Programm. Daten die es
zu verwalten hat? Keine. Methoden? (Die auf diese Daten operieren - fängt ja
schonmal gut an, keine Daten == keine Methoden? Dann könnten wir hier auch
gleich aufhören. Also definiere ich mal eine Methode "int Run(void)" die dann
quasi wie main das Hauptprogramm enthält. Hier also mein OOP-hello.cpp:
begin 644 hello.cpp
#include <iostream>
class HelloWorld {
// Daten:
// Methoden:
void Run(void);
};
void HelloWorld::Run(void) {
cout << "Hello World." << endl;
}
int main(void) {
HelloWorld app;
app.Run();
}
end
Schön. Eigentlich müssten das jetzt drei Dateien sein:
begin 644 HelloWorld.h
#ifndef HELLOWORLD_H
#define HELLOWORLD_H
class HelloWorld {
// Daten:
// Methoden:
void Run(void);
};
#endif // #ifndef HELLOWORLD_H
end
begin 644 HelloWorld.cpp
#include "HelloWorld.h
#include <iostream>
void HelloWorld::Run(void) {
cout << "Hello World." << endl;
}
end
begin hello.cpp
#include "HelloWorld.h
int main(void) {
HelloWorld app;
app.Run();
}
end
Aber bringen tut's nicht wirklich was. Dafür ist der Umfang noch tu klein.
Doch das eigentliche Problem, was hier auffällt: Von insgesamt 11 Zeilen
(Leerzeilen und Kommentarzeilen nicht mitgezählt) ist gerade mal eine
wirklich für die Ausgabe verantwortlich. Der Rest ist alles Tribut an die
sogenannte Objekt Orientierte Programmierung.
Heißt das nun, daß OOP schlecht ist?
Nein, keineswegs. Allerdings halte ich es nicht für sinnvoll, mit einer
Sprache anzufangen, bei der man im ersten halben Jahr noch nicht weiß, wie
das alles funktioniert. Bei Basic habe ich den Vorteil, mich von Anfang an
darauf konzentrieren zu können, das Programmieren zu lernen, denn die
Sprache ist primitiv genug, um sie locker mal nebenbei mitzunehmen. Ein
Datenfeld sortieren in Basic, C und C++ (Ohne native Sortierfunktionen wie
qsort, die die Sprache ggf. zur Verfügung stellt):
begin 644 sort.bas
REM Konstanten nur über namen ansprechen. Also Konstante für die Anzahl der
REM Einträge im Datenfeld definieren:
const num = 20
REM Für Datenfelder, die mehr als Indizes 0 .. 11 haben sollen, muß man
REM diese sogar in Basic vorher deklarieren. Weiß der Teufel, warum (man
REM könnte diese ja auch später vergrößern ...)
dim Datenfeld(num)
REM Initialisierung des Zufallsgenerators mit der Systemzeit.
randomize timer
REM Initialisierung mit Zufallswerten.
for i=1 to num
Datenfeld(i)=rnd
next
REM Und ausgeben, damit wir nachher vergleichen können.
gosub Ausgeben
REM Jetzt wird sortiert:
for j=1 to num-1
for i=j+1 to num
if Datenfeld(i)>Datenfeld(j) then
swap Datenfeld(i), Datenfeld(j)
endif
next
next
REM Und zur Kontrolle nochmal ausgeben.
gosub Ausgeben
Ende: end
REM PS: Das Lable "Ende: " habe ich nur eingefügt, damit das "end" nicht als
REM Ende der Datei fehlinterpretiert wird.
Ausgeben:
for i=1 to num
print Datenfeld(i);
next
print
return
end
So, einfach mal straight forward. Der Punkt, wo es anfängt, interessanter zu
werden, ist der, wo es via gosub nach Ausgeben geht, und via return zurück.
Erspart er einem hier, die selben Zeilen für die Ausgabe zweimal schreiben
zu müssen. Es sei allerdings angemerkt, daß die Veränderung der Variablen i
durch den Code ab »Ausgeben:« trotzdem im rest des Programmes sichtbar ist.
Also:
i = 42
print i
gosub Ausgeben
print i
würde die Ausgeben
42
20 (oder 21)
erzeugen. Ok, aber jetzt mal das Ganze in C:
begin 644 sort.c
#include <stdio.h>
#include <stdlib.h>
#incldue <time.h>
/* Auch hier: Der Konstanten 20 einen Namen verpassen */
#define NUM 20
/* Hierüber können wir nachher auf unser Datenfeld zugreifen */
int * Datenfeld = NULL;
/* Die Ausgabefunktion: */
void Ausgeben(void) {
int i;
for (i=0;i<NUM;++i) {
printf("%i ",Datenfeld[i]);
}
putchar('\n');
}
/* Hier fängt das Hauptprogramm an: */
int main(void) {
/*
* Entgegen zur Basic-Version dürfen wir hier erstmal anfangen,
* die ganzen Variablen aufzuzählen, die wir so brauchen
* werden ...
*/
int i,j,tmp;
/*
* Ähnlich wie in der Basic Version müssen wir hier das Datenfeld
* erzeugen. Nur wird hier deutlicher, daß dies erst zur Laufzeit
* geschieht.
*/
Datenfeld=malloc(sizeof(int)*NUM);
/* Prüfen, ob wir den Spicherbereich bekommen haben */
if (!Datenfeld) {
perror("malloc");
exit(2);
}
/* Initialisierung des Zufallsgenerators mit der Systemzeit. */
srand(time(NULL));
/* Initialisierung mit Zufallswerten. */
for (i=0;i<NUM;++i) {
Datenfeld[i] = rand();
}
/* Und ausgeben, damit wir nachher vergleichen können. */
Ausgeben();
/* Jetzt wird sortiert: */
for (j=0;j<NUM-1;++j) {
for (i=j+1;i<NUM;++i) {
if (Datenfeld[i]>Datenfeld[j]) {
tmp=Datenfeld[i];
Datenfeld[i]=Datenfeld[j];
Datenfeld[j]=tmp;
}
}
}
/* Und zur Kontrolle nochmal ausgeben. */
Ausgeben();
exit(0);
}
end
In der C Version fängt es gleich am Angang an, unverständlich zu werden,
weil ich eigentlich immer noch nicht darauf eingegangen bin, was die vielen
»#define«s bedeuten. Zur Beruhigung: Für das Verständnis des Quelltextes
unwichtig, einfach ignorieren.
So, der Vorteil des Beispieles Datenfeld sortieren ist es jetzt aber, daß
OOP hier (im Gegensatz zum Hello-World-Programm) endlich anfängt, sinnvoll
zu sein:
begin 644 sort.cpp
#include <stdio.h>
#include <stdlib.h>
#incldue <time.h>
/*
* Die Klasse für ein Datenfeld:
*/
class Feld {
/*
* Die folgenden Elemente dürfen nur von der Klasse aus selber
* benutzt werden
*/
private:
/*
* Wie in der C version: Der Zeiger auf das Datenfeld.
*/
int * Datenfeld;
/*
* Da die Klasse die Größe des Feldes übergeben bekommt, muß sie
* sich diese nun auch merken. Auf diese Weise ist es möglich, mit
* dieser Klasse mehrere Datenfelder unterschiedlicher Größe
* anzulegen.
*/
int size;
/*
* Die folgenden Elemente dürfen von überall aus aufgerufen werden.
*/
public:
Feld(int num);
void Ausgeben();
void RandomInit(void);
void Sortieren();
};
/*
* Der sogenannte Konstuktor. Er wird immer dann aufgerufen, wenn ein
* neues Feld erzeugt wird. In diesem Beispiel also an der Stelle, wo
* in der Funktion main »Feld MeinDatenFeld(NUM);« steht.
*/
Feld::Feld(int size) {
/*
* Genauso wie in der C Version müssen wir hier das Datenfeld
* erzeugen. Statt malloc wird hier das OOP-new benutzt. Macht
* hier aber letztlich das gleiche (Speicher belegen).
*/
Datenfeld = new int[size=num];
/* Prüfen, ob wir den Spicherbereich bekommen haben */
if (!Datenfeld) {
perror("new");
exit(2); /* throw wäre hier eigentlich besser */
}
}
/* Die Ausgabefunktion: */
void Feld::Ausgeben(void) {
int i;
for (i=0;i<size;++i) {
printf("%i ",Datenfeld[i]);
}
putchar('\n');
}
/* Die Funktion, die das Datenfeld mit Zufallsdaten füllt. */
void Feld::RandomInit(void) {
for (i=0;i<size;++i) {
Datenfeld[i] = rand();
}
}
/* Die Sortierfunktion: */
void Feld::Sortieren(void) {
int i,j,tmp;
for (j=0;j<size-1;++j) {
for (i=j+1;i<size;++i) {
if (Datenfeld[i]>Datenfeld[j]) {
tmp=Datenfeld[i];
Datenfeld[i]=Datenfeld[j];
Datenfeld[j]=tmp;
}
}
}
}
/* Auch hier: Der Konstanten 20 einen Namen verpassen */
#define NUM 20
/* Hier fängt das Hauptprogramm an: */
int main(void) {
/*
* Hier wird das Datenfeld erzeugt. Beachte bitte, daß - so
* unscheinbar diese Zeile auch aussehen mag, hier ein ganzer
* Rattenschwanz an Funktionen aufgerufen werden könnten.
*/
Feld MeinDatenFeld(NUM);
/* Initialisierung des Zufallsgenerators mit der Systemzeit. */
srand(time(NULL));
/* Initialisierung mit Zufallswerten. */
MeinDatenFeld.RandomInit();
/* Und ausgeben, damit wir nachher vergleichen können. */
MeinDatenFeld.Ausgeben();
/* Jetzt wird sortiert: */
MeinDatenFeld.Sortieren();
/* Und zur Kontrolle nochmal ausgeben. */
MeinDatenFeld.Ausgeben();
exit(0);
}
end
Was hier auffällt ist vor allem, daß das Hauptprogramm wesentlich
übersichtlicher ist. Ok, das wäre in der C-Variante genauso gegangen. Es
zeigt hier aber auch die Mentalität, die hinter C++ steht: Es gibt Objekte
(Klassen) und diese haben Eigenschaften:
1. Daten die zu speichern sind, und
2. Funktionen (Methoden) die auf diese Daten operieren.
Das sieht man hier doch recht deutlich.
Man könnte jetzt sogar noch beigehen, und aus der C++-Version eine Version
machen, die Templates nutzt, dann könnte man im Hauptprogramm z.B. den hier
machen:
Feld<int> IntFeld(100);
Feld<double> DblFeld(100);
Und schon hätte man sich einen Haufen Arbeit gespart, weil man die
Sortierfunktion nur einmal implementieren muß, aber diese trotzdem auf
beliebige Datentypen (Auch Klassen sind Datentypen) angewendet werden
können. Gegenüber Basic hat C viele Vorteile, und C++ noch viel mehr. Ob
Du als Anfänger Dich aber gleich mit der OOP auseinandersetzen willst, mußt
Du selber entscheiden. Ich habe Dir hier hoffentlich auch für Dich
verständliche Beispielquellen gepostet, entscheiden mußt Du Dich letztlich
selbst, daß kann Dir hier niemand abnehmen.
Gruß, Bodo
--
MS Outlook Express?->[DE: http://piology.org/ILOVEYOU-Signature-FAQ.html]
@@@@@ GEGEN TCG aka. TCPA: @@@@@ [DE: http://www.againsttcpa.com]
Bodo Thiesen
>Ada waere von den heute ueblichen Sprachen vielleicht fuer den Einstieg in
>die Programmierung ganz gut geeignet.
Und Du bist Dir sicher, daß hello world in Ada keinen wesentlich größeren
Umfang hat als z.B. in Basic? (Ich kenne Ada leider nur vom Namen her.)
Bodo Thiesen
>Juergen Ilse hat geschrieben:
>
>> [Menschheit verbloedet, Faehigkeit, sich mittels Worten
>> auszudruecken -> 'Kleinkind-Niveau' mittels 'zeigen' und
>> 'da' rufen (sprich anklicken) Wuensche zum Ausdruck brigen]
>
>Na ja, so weit würde ich nicht gehen. Man kann kaum läugnen,
>daß das herumklicken mit der Maus auf Symbolen oder in
>PullDown-Menüs eine einfachere Bedienung ermöglichen kann
>(nicht muß).
Ja, vor allem wenn die einzelnen Menüpunkte so gut versteckt sind, daß man
sie dort beim besten Willen nicht vermuten täte.
>Vor allem dann, wenn man mit Programmen arbeitet,
>deren Funktionsumfang so groß ist, daß man die meisten
>Funktionen so selten braucht, daß man sie sich kaum merken
>kann.
Dann wird man besser bedient sein, diese Funktionen sinnvoll zu Gruppieren,
dafür brauche ich aber kein Pull-Down Menü. Abgesehen davon habe ich nichts
gegen Klicki-Bunti. Ich merke nur, daß wenn ich eine Datei via
$ cat > ~/langer/pfad/irgendwo/in/meinem/Home/verzeichnis/endlich/geschafft.txt
anlege, ich den Namen viel schneller via
~/l<TAB>p<TAB>i<TAB><TAB><TAB><TAB><TAB>geschafft.txt
eintippen kann, als im Konqueror beim Download in der Dateiliste via Klicken
erreiche. Ach ja: Je nachdem, um was es geht, muß man den endgültigen Namen
dann trotzdem noch eintippen ...
>Grafische Oberflächen ermöglichen das Wiederfinden von
>Funktionen anhand von Aussehen, Farbe, Ort - alles Dinge, die
>sich ein Mensch besser merken kann, als zusammenhanglose Namen
>von Befehlen (weil Abkürzungen) oder Kommandozeilenparametern.
Genau. Deswegen habe ich es auch nach 3 Stunden nicht geschafft, auf meiner
Schwesters Laptop die Autostartfunktion des CD-Rom-Laufwerks auszuschalten
(WinXP) obwohl das Standardprozedur während meiner 3-monatigen Win98
Reinstallationssitzungen war.
Bei Kommandozeilen-Tools ängern sich die Kommandozeilenparameter meistens
nicht mehr, wenn sie sich einmal etabliert haben.
>Mal ganz zu schweigen von den vielen Kommandozeilenprogrammen,
>die bei ihrem Aufruf noch nicht einmal sagen, wozu sie da
>sind, selbst wenn man sie mit --help aufruft.
Das ist ein Fehler in diesen Programmen, aber es gibt genügend Programme
für Wintendo, die auch nicht wissen, wozu sie gut sind (oder dieses Wissen
wie ein Geheimnis hüten).
Vinzent 'Gadget' Hoefler
>Und Du bist Dir sicher, daß hello world in Ada keinen wesentlich größeren
>Umfang hat als z.B. in Basic? (Ich kenne Ada leider nur vom Namen her.)
Geht bei modernen BASIC-Dialekten denn
|10 PRINT "Hello world."
ueberhaupt noch? Aber zum Vergleich:
|with Ada.Text_IO;
|
|procedure Hello_World is
|begin
| Ada.Text_IO.Put_Line ("Hello world.");
|end Hello_World;
Eine C/Java/$whatever-Variante ist auch nicht wirklich kuerzer, wie Du
im anderen Posting gerade bewiesen hast. :)
Ahso, wir sind noch in der flahscen Gruppe. Ich fluppe mal kurz.
Vinzent.
Claus Reibenstein
> 1. Du kannst nicht Programmieren
> 2. Du kennst keine Programmiersprache
>
> (Ja, das sind zwei verschiedene Dinge)
Wem sagst Du das :-)
> Gut, vergleichen wir das jetzt mal mit C++. Zuerst mal, müssen wir hier eine
> Klasse finden.
An dieser Stelle Einspruch, Euer Ehren.
Natürlich kann man ein Programm beliebig verkomplizieren. Aber das muss
ja nicht sein. Dieses kleine C++-Programm täte es auch:
#include <iostream>
int main(void) {
cout << "Hello World." << endl;
}
Et voilà - keine Zeile mehr als die C-Version.
> * Entgegen zur Basic-Version dürfen wir hier erstmal anfangen,
> * die ganzen Variablen aufzuzählen, die wir so brauchen
> * werden ...
Was in jedem Fall zu begrüßen ist!
Ich habe einmal in einem umfangreichen FORTRAN-Projekt (CAD-System
speedikon, falls das jemand kennt) einen Fehler suchen dürfen, der sich
schließlich als Tippfehler in einem Variablennamen herausstellte (ALFA
statt ALPHA). Mit C wäre so etwas kaum möglich, da ein Compiler hier
gleich heftig mosern würde.
C ist eine kleine und leistungsfähige Sprache, verlangt aber eine
gehörige Portion von Disziplin beim Programmieren - und es kann
niemandem schaden, wenn er sich gleich von Anfang an daran gewöhnt, als
sich erst einmal von einfachen, fehlertoleranten Sprachen einlullen zu
lassen. Die versauen langfristig nur den Programmierstil.
Gruß. Claus
Wolfgang Kaufmann
Hallo,
> Ich habe einmal in einem umfangreichen FORTRAN-Projekt (CAD-System
> speedikon, falls das jemand kennt) einen Fehler suchen dürfen, der sich
> schließlich als Tippfehler in einem Variablennamen herausstellte (ALFA
> statt ALPHA). Mit C wäre so etwas kaum möglich, da ein Compiler hier
> gleich heftig mosern würde.
Also, ich habe in solchen Fällen meist das Glück, dass es /beide/
Variablen gibt und der Tipp/-Denkfehler dadurch weder sofort ins Auge
springt, noch der Compiler ans mosern gedacht hätte.
Wolfgang.
--
"Es gibt Dinge, die man bereut, ehe man sie tut. Und man tut sie doch."
-- Christian Friedrich Hebbel
Vinzent 'Gadget' Hoefler
>C ist eine kleine und leistungsfähige Sprache, verlangt aber eine
>gehörige Portion von Disziplin beim Programmieren - und es kann
>niemandem schaden, wenn er sich gleich von Anfang an daran gewöhnt, als
>sich erst einmal von einfachen, fehlertoleranten Sprachen einlullen zu
>lassen. Die versauen langfristig nur den Programmierstil.
ACK. Aber ueber die Definition von "fehlertolerant" muesste man sich,
glaube ich, noch mal unterhalten. ;-)
Vinzent.
Juergen Ilse
Wolfgang Kaufmann <wk-u...@news.theparallax.net> wrote:
> * Thus spoke Claus Reibenstein <c.reib...@pop-hannover.de>:
>> Ich habe einmal in einem umfangreichen FORTRAN-Projekt (CAD-System
>> speedikon, falls das jemand kennt) einen Fehler suchen dürfen, der sich
>> schließlich als Tippfehler in einem Variablennamen herausstellte (ALFA
>> statt ALPHA). Mit C wäre so etwas kaum möglich, da ein Compiler hier
>> gleich heftig mosern würde.
implicit none
waere die Loesung gewesen (haette aber auch in allen anderen Teilen
die "implizite Variablendeklaration" sabotiert und damit bei *allen*
Variablen eine ordentliche Deklaration erzwungen ...).
> Also, ich habe in solchen Fällen meist das Glück, dass es /beide/
> Variablen gibt und der Tipp/-Denkfehler dadurch weder sofort ins Auge
> springt, noch der Compiler ans mosern gedacht hätte.
Dann solltest du ueber eine andere (weniger fehlertraechtige) Namensgebung
bei Variablen nachdenken ... ;-)
Rainer Weikusat
> "Christoph Freiburger" <ti...@epost.de> writes:
>> Macht es Sinn, als 100% Anfänger, ohne jegliche
>> Programmierkenntnisse, c++ zu erlernen
>
Kurz: Falk fühlt sich unmotiviert, C++ zu lernen. Das ist ein
indirekter Ratschlag.
Rainer Weikusat
> Ich will nicht sagen, daß ich sonderlich fit in C bin, fühle
> mich in der Sprache jedoch an sich ganz wohl. Nur irgendwann
> kam dann C++ auf. Anderew Sprachen vernachlässige ich jetzt
> mal. Der Unterschied ist diese Objektorientiertheit.
> Ich ein paar mal versucht, etwas in C++ zu machen und bin
> gescheitert. Den letzten Schock hat mir M$'s VisualC verpasst, eine
> Entwicklungsumgebung, deren Maches es aufgegeben haben, diese
> zu dokumentieren.
Das haben sie in der Erkenntnis getan, daß niemand diese Dokumentation
lesen und ihr Glauben schenken würde, solange er/sie nicht wenigstens
einmal selber auf alle Knöpfe gedrückt hat und danach ist es 'eh
kaputt, egal was es war.
> Mein Problem beim Umstieg auf C++ ist diese im idealfall
> volkommen andere Herangehensweise an Probleme.
Nein. Es sind immer noch Datenstrukturen, auf denen irgendwelche
Funktionen arbeiten, die irgendetwas über ein Interface
kommunizieren.
> Will sagen: deine Entscheidung für C oder für C++ könnte eine
> Entscheidung fürs Leben sein:-)).
Unfug.
> Übrigens, wenns um Zukunftssicherheit geht, die OO-Hype ist wohl
> auch ein wenig am Abebben.
Ach Quatsch, der fängt gerade erst richtig an.
> Allerdings wenn es um Zukunftssicherheit geht und keine
> Einwände bezüglich OO bestehen, dann ist derzeit wohl Java
> ganz groß angesagt.
Sic. Java ist immer 'groß angesagt'.
>> Ich weiß, so etwas gibt es en masse, aber ich möchte allen
>> Ballast beiseite lassen und eine kleine, feine Anwendung nur
>> auf meine Bedüfnisse abgestimmt, erstellen.
>
> Könnte es sein, daß dir ein richtig fertig semiprofessionell
> aussehendes Programm vorschwebt?
Sowas wie Windows zB? Das sieht zweifelsohne richtig fertig aus und
ist sicher semiprofessioniell.
> Hmm, bei solchen Programmen ist das Userinterface nicht selten der
> mit Abstand aufwändigste
Ein Aufwand wird aufgewendet und nicht aufgewandet. Bei vielen
'Projekten' ist die GUI deswegen der aufwendigste Teil, weil sie der
einzige Teil ist, auf den Aufwand verwand wird. Ich kenne da ein
schönes Beispiel mit einem guten Dutzend 'handoptimierter' 'This
button has no function'-Dialoge ...
> Teil des Gesamtprojektes, bei einer
> Adressverwaltung würde ich sogar sagen, er macht 99% aus.
Read: Mit einem Prozent der Arbeit, die man in ein GUI stecken müßte,
bekommt man eine vollkommen benutzbare Adreßbverwaltung.
> Ich weis nicht, ob sowas der beste Einstieg ist.
Man muß das mal gemacht haben um es sich abzugewöhnen.
> Auch da muß ich wohl ohne eigene Erfahrungen allerdings wieder Java
> erwähnen. Da ist die Programmierung einer Benutzerschnittstelle
> jedenfalls systemunabhängig,
»Write once, crash everywhere« [Quelle vergessen].
Falk Hueffner
Kapier ich nicht. Inwiefern ist es fuer die Frage, ob C++ eine
geeignete Anfaengersprache ist, von Relevanz, ob ich motiviert bin
oder nicht, C++ zu lernen?
--
Falk
Vinzent 'Gadget' Hoefler
>»Write once, crash everywhere« [Quelle vergessen].
Muss die RTSJ gewesen sein. Oder zumindest der Schluss, den man aus
ihr zieht, nachdem man sie gelesen hat.
Vinzent.
Roland Damm
Rainer Weikusat hat geschrieben:
> Roland Damm <rolan...@arcor.de> writes:
> > Ich will nicht sagen, daß ich sonderlich fit in C bin,
> > fühle mich in der Sprache jedoch an sich ganz wohl. Nur
> > irgendwann kam dann C++ auf. Anderew Sprachen
> > vernachlässige ich jetzt mal. Der Unterschied ist diese
> > Objektorientiertheit. Ich ein paar mal versucht, etwas in
> > C++ zu machen und bin gescheitert. Den letzten Schock hat
> > mir M$'s VisualC verpasst, eine Entwicklungsumgebung, deren
> > Maches es aufgegeben haben, diese zu dokumentieren.
>
> Das haben sie in der Erkenntnis getan, daß niemand diese
> Dokumentation lesen und ihr Glauben schenken würde, solange
> er/sie nicht wenigstens einmal selber auf alle Knöpfe
> gedrückt hat und danach ist es 'eh kaputt, egal was es war.
Ist trotzdem keine Entschuldigung, wenn ich in der Onlinehilfe
nach Bibliotheksfunktionen suche mit denen ich das machen
kann, was ich machen will, dann auch fündig werde, diese
Funktion aber beim Besten Willen nicht zum laufen bekommen,
weil es sie nicht gibt. Nach langer Suche: es was eine
Java-Funktion. Stand aber auf der manpage garantiert nicht
drauf. Und ganz witzig sind die Hilfeseiten, die sich um
Theman ranken, die weder mit Programmierung, noch mit VC zu
tun haben. Einfach nur WorkArounds für die Bugs des
Mediaplayer z.B..
> > Mein Problem beim Umstieg auf C++ ist diese im idealfall
> > volkommen andere Herangehensweise an Probleme.
>
> Nein. Es sind immer noch Datenstrukturen, auf denen
> irgendwelche Funktionen arbeiten, die irgendetwas über ein
> Interface kommunizieren.
Das wohl ja noch. Aber es wird dann immer auf Vererbung
rumgeritten. Ich verstehe nicht so ganz, wieso ich erst eine
Funktion schreiben sollte, die sowieso nichts kann, nichts tut
und nachher auch gar nicht gebraucht wird:-). Nur damit sich
andere davon etwas erben können. Vieleicht hilft das ja,
Ordnung im Code zu halten. Aber da ist meine Erfahrung eher
die, daß es bei der Ordnung im Code in erster Linie auf die
Disziplin des Programmierers ankommt. Ebenso könnte OO bei
besonders großen Projekten vorteilhaft sein. Gut, da muß ich
ganz klar sagen, daß ich da keine Erfahrung habe. Das gröste
monolithische (damit meine ich nicht eine Fülle von Funktionen
aus diversen Quellen in diversen Programmiersprachen) Programm
dem ich begegnet bin, hatte vieleicht 100000 Zeilen. Und es
war sehr übersichtlich geschrieben. Gut, man mußte sich an die
Marotte des Programmierers gewöhnen, switch-Anweisungen über
tausende von Zeilen gehen zu lassen, in dem er den Code für
jede einzelaktion direkt dort reingeschrieben hatte....:-),
aber egal, wenigstend war er darin konsequent.
> > Übrigens, wenns um Zukunftssicherheit geht, die OO-Hype ist
> > wohl auch ein wenig am Abebben.
>
> Ach Quatsch, der fängt gerade erst richtig an.
Ehrlich? Na gut, Java und so. Aber vor Jahren hatte ich noch
den Eindruck, daß man sich schämen mußte, wenn man einfach nur
C programmiert, ohne das ++ dazu. Heute ist wohl doch ein
bischen die Einsicht durchgesickert, daß C-Code manchmal
einfach nur einfacher kürzer sein kann und daß OO nicht gleich
alle Probleme vom Tisch fegt.
> > Könnte es sein, daß dir ein richtig fertig
> > semiprofessionell aussehendes Programm vorschwebt?
>
> Sowas wie Windows zB? Das sieht zweifelsohne richtig fertig
> aus und ist sicher semiprofessioniell.
*fg*. Ich denke bei sowas eher an die vielen Programme gerade
unter Win, die dann als Shareware auch noch Geld kosten
sollen, zweifelsohne eine schöne Oberfläche haben, aber innen
drin ganz schön grausig sind. Langsam, dumm,...
> > Hmm, bei solchen Programmen ist das Userinterface nicht
> > selten der mit Abstand aufwändigste
>
> Ein Aufwand wird aufgewendet und nicht aufgewandet. Bei
Werd mit versuchen zu merken, auch wenn die Logik fehlt.
> > Teil des Gesamtprojektes, bei einer
> > Adressverwaltung würde ich sogar sagen, er macht 99% aus.
>
> Read: Mit einem Prozent der Arbeit, die man in ein GUI
> stecken müßte, bekommt man eine vollkommen benutzbare
> Adreßbverwaltung.
Ebendt:-) Eine Schleife, die Tastenkommandos liest, sowas wie
'add' oder 'find' und dann zu entsprechenden Unterfunktionen
springt. Der eigendliche Code, der nichts mit dem
Userinterface zu tun hat beschränkt sich wohl auf eine
Suchfunktion und vieleicht noch ein Aufruf von qsort. Und ein
bischen Standartoperation für verkettete Listen vieleicht.
Alles in allem in 200 Zeilen zu erledigen. Selbst dann macht
das Handling der Befehlseingabe und Auswertung schon mehr Code
aus. Mit einer GUI drumherum dagegen......
> > Ich weis nicht, ob sowas der beste Einstieg ist.
>
> Man muß das mal gemacht haben um es sich abzugewöhnen.
Wenn ich mal in der Softwareproduktion arbeiten würde, würde
ich mit wünschen, daß sich um die GUI jemand anderes
kümmert:-) Ich denke mir lieber schnelle Algorithmen aus.
Roland Damm
Juergen Ilse hat geschrieben:
> > Also, ich habe in solchen Fällen meist das Glück, dass es
> > /beide/ Variablen gibt und der Tipp/-Denkfehler dadurch
> > weder sofort ins Auge springt, noch der Compiler ans mosern
> > gedacht hätte.
>
> Dann solltest du ueber eine andere (weniger fehlertraechtige)
> Namensgebung bei Variablen nachdenken ... ;-)
Mit drei Buchstaben bekommt man über 140000 Variablennamen hin
- es will doch wohl keiner sagen, daß ihm das nicht reichen
würde:-) Schließlich ist ein Programm ja immer noch ein
Programm und kein Roman.
SCNR & CU Rollo
Jirka Klaue
>>>selten der mit Abstand aufwändigste
>>
>>Ein Aufwand wird aufgewendet und nicht aufgewandet. Bei
>
> Werd mit versuchen zu merken, auch wenn die Logik fehlt.
Brauchst Du Dir nicht merken, aufwändig ist vollkommen in Ordnung.
Jirka
Vinzent 'Gadget' Hoefler
>Brauchst Du Dir nicht merken, aufwändig ist vollkommen in Ordnung.
Nur, wenn man Verfechter der sogenannten NRS ist.
Vinzent.
Vinzent 'Gadget' Hoefler
>würde:-) Schließlich ist ein Programm ja immer noch ein
>Programm und kein Roman.
Und bei den Lochstreifen stanzt Du auch noch noch jedes Loch einzeln
mit der Hand, richtig?
Vinzent.
Jirka Klaue
Sehr seltsame Auffassung für jemanden, der an Standards glaubt. ;-)
Ich dachte, die NRS ist amtlich? Es wird ja in den Schulen auch
nichts anderes mehr gelehrt.
C99 ist ja auch amtlich und C89/90 ist veraltet. Ob man das eine
oder das andere mag oder "verfechtet" ist irrelevant.
Jirka
Vinzent 'Gadget' Hoefler
>Ich dachte, die NRS ist amtlich?
Das haette man gern, ja.
>Es wird ja in den Schulen auch
>nichts anderes mehr gelehrt.
s/anderes//
Das ist aber schon laenger so. :->
>C99 ist ja auch amtlich und C89/90 ist veraltet. Ob man das eine
>oder das andere mag oder "verfechtet" ist irrelevant.
Mag sein. Aber ich nehme an, dass an diesem Standard Leute gearbeitet
haben, die Ahnung davon hatten, wovon sie reden. Desweiteren hatten
auch die Leute, die es letztendlich betraf, sicher doch auch ein
Mitspracherecht, oder?
BTW, warum gibt es dann auf deutschen Tastaturen immer noch ein
<html>ß</html>, auf der Schweizer meines Laptops, an dem ich
gerade sitze, aber nicht?
Vinzent.
Wolfgang Kaufmann
Hallo,
> Wolfgang Kaufmann <wk-u...@news.theparallax.net> wrote:
>
>> Also, ich habe in solchen Fällen meist das Glück, dass es /beide/
>> Variablen gibt und der Tipp/-Denkfehler dadurch weder sofort ins Auge
>> springt, noch der Compiler ans mosern gedacht hätte.
>
> Dann solltest du ueber eine andere (weniger fehlertraechtige) Namensgebung
> bei Variablen nachdenken ... ;-)
Na, klar -- an sowas denkt man ja als erster, wenn man den Quellcode
liest. ;-) Und das ist mein Problem hierbei: ich lese derzeit
hauptsächlich den Code, ändere eventuell an einigen Stellen etwas und
schreibe selbst prozedual sehr wenig, nur kleinere Dinge für den
Hausgebrauch oder Tests mit einigen hundert Zeilen. Und ich selbst bin
dank der Aufgabe des Lesen von Quellcode den andere geschrieben haben,
auch eher ein großer Freund von längeren, ausdrucksstärkeren Bezeichnern...
Überhaupt nicht mehr lustig sind Fälle die sich rein durch Dinge wie »I«
und »l« unterscheiden.
Jirka Klaue
> Jirka Klaue wrote:
>
>>nichts anderes mehr gelehrt.
>
> s/anderes//
>
> Das ist aber schon laenger so. :->
Das hört sich an wie: "Früher war alles besser." :-)
>>C99 ist ja auch amtlich und C89/90 ist veraltet. Ob man das eine
>>oder das andere mag oder "verfechtet" ist irrelevant.
>
> Mag sein. Aber ich nehme an, dass an diesem Standard Leute gearbeitet
> haben, die Ahnung davon hatten, wovon sie reden. Desweiteren hatten
> auch die Leute, die es letztendlich betraf, sicher doch auch ein
> Mitspracherecht, oder?
Bei C99? Ich glaube, es ist ganz schön teuer bei der Standardisierung
mitzumischen.
> BTW, warum gibt es dann auf deutschen Tastaturen immer noch ein
> <html>ß</html>, auf der Schweizer meines Laptops, an dem ich
> gerade sitze, aber nicht?
Weil man Straße auf Deutsch nachwievor mit <html>ß</html> schreibt.
Wie man das in der Schweiz handhabt, weiß ich nicht. Ich erinnere mich
noch dunkel an seltsame Sachen wie "parkieren" für "parken". ;-)
Jirka
Vinzent 'Gadget' Hoefler
>Vinzent 'Gadget' Hoefler wrote:
>
>> Mag sein. Aber ich nehme an, dass an diesem Standard Leute gearbeitet
>> haben, die Ahnung davon hatten, wovon sie reden. Desweiteren hatten
>> auch die Leute, die es letztendlich betraf, sicher doch auch ein
>> Mitspracherecht, oder?
>
>Bei C99? Ich glaube, es ist ganz schön teuer bei der Standardisierung
>mitzumischen.
Dann unterscheidet sich das offensichtlich signifikant von dem
Prozess, der bei Ada zur Anwendung kommt (oder heisst das jetzt
Anwaendung?). Da darf jeder Vorschlaege bringen und die werden auch
recht offen diskutiert.
>> BTW, warum gibt es dann auf deutschen Tastaturen immer noch ein
>> <html>ß</html>, auf der Schweizer meines Laptops, an dem ich
>> gerade sitze, aber nicht?
>
>Weil man Straße auf Deutsch nachwievor mit <html>ß</html> schreibt.
>Wie man das in der Schweiz handhabt, weiß ich nicht.
Es heisst Strasse. Das ist das Interessante. Nun stell Dir mal vor, es
gaebe einen laenderspezifischen C-Standard. Eine solche Idee ist
wahnwitzig, so was wuerde keiner ernstnehmen. Warum also die NRS?
Microsoft hat mit der Eindeutschung irgendwelcher Word-Makros so was
ja schon mal versucht. ;-)
>Ich erinnere mich
>noch dunkel an seltsame Sachen wie "parkieren" für "parken". ;-)
Ja. Wo Deutsche ihre Fahrraeder parken, parkieren Schweizer ihre
Velos. Eben.
Die NRS verbessert nichts, sie aendert nur, ohne wirklich etwas zu
aendern. Und das ist als Ziel sinnlos.
Vinzent.
--
np: Avril Lavigne - Complicated
Juergen Ilse
> C ist eine kleine und leistungsfähige Sprache, verlangt aber eine
> gehörige Portion von Disziplin beim Programmieren - und es kann
> niemandem schaden, wenn er sich gleich von Anfang an daran gewöhnt, als
> sich erst einmal von einfachen, fehlertoleranten Sprachen einlullen zu
> lassen. Die versauen langfristig nur den Programmierstil.
Auch C als "Anfaengersprache" kann den Programmierstil versauen.
Ich wuerde eher dazu tendieren, als Anfaengersprache eine "restriktivere"
Sprache zu verwenden. Auf anhieb wuerde ich also zuerst z.B. zu Pascal, Ada,
oder Modula2 tendieren (ohne ein Reihenfolge einfuegen zu wollen). Dabei
hat Pascal den Nachteil, dass man bei bestimmten Programmierproblem oder
ab eienr bestimmten Komplexitaet des Programms evt. doch sehr deutlich
die Grenzen der Sprache spuert, und Modula2 hat das Problem, dass zwar
die Sprache standardisiert ist, nicht aber die Library-Module (fuer die
gibt es nur einen eher unverbindlichen Vorschlag von Herrn Wirth, dem
Erfinder der Sprache), und jeder Hersteller hat dann eben die eigenen
Erweiteruingen hinzugefuegt oder auch Teile dieses unverbindlichen Vor-
schlags weggelassen oder gerungfuegig anders implementiert ...
Was die "Erweiterung des standards" betrifft, hat man dieses Problem
uebrigens auch mit Pascal: "Turbo Pascal" oder "Borland Pascal" haben
gegenueber dem standard so viele Erweiterungen und Modifikationen, dass
man sie eigentlich schon wieder als eigene Sprache ansehen muesste ...
Ada ist vielleicht laengst nicht so weit verbreitet, aber der Standard
spezifiziert die Sprache und die mindestens mitzuliefernden packages
sehr genau, und diese sind auch umfangreich genug, um auch komplexe
Aufgaben zu bewaeltigen ... Das Problem des "mangelnden Sprtachumfangs
laut Standard", das bei Pascal zu einem gewissen "Wildwuchs der Dialekte"
gefuehrt hat, existiert also bei Ada nicht.
Meine Erfahrungen mit Ada liegen allerdings auch schon wieder ein paar
Jahre zurueck.
Ekkehard Morgenstern
Hallo Juergen,
"Juergen Ilse" <jue...@usenet-verwaltung.de> schrieb im Newsbeitrag
news:3fbce4c8$0$12053$a5ec...@news.ilse.asys-h.de...
> Auch C als "Anfaengersprache" kann den Programmierstil versauen.
> Ich wuerde eher dazu tendieren, als Anfaengersprache eine "restriktivere"
> Sprache zu verwenden. Auf anhieb wuerde ich also zuerst z.B. zu Pascal,
Ada,
> oder Modula2 tendieren (ohne ein Reihenfolge einfuegen zu wollen). Dabei
Das kann ich voll unterschreiben -- ich würde auch empfehlen, eher mit
Pascal anzufangen als mit C. Ich habe mit BASIC und Pascal gelernt, und erst
Jahre später mit C angefangen, und ich denke, das war auch gut so.
C/C++ sind oft für Anfänger ziemlich frustrierend, z.B. wenn man Fehler im
Zusammenhang mit Pointern macht. Es hat Jahre gebraucht, bis ich
einigermaßen fehlerfreie Programme in C schreiben konnte. Natürlich bin ich
heute viel weiter und lege meinen Code von vornherein idiotensicher aus, um
Fehlern vorzubeugen (und tatsächlich mache ich kaum noch welche).
Übrigens, ich denke, daß beim Lernen von C oder C++ es gelegentlich hilft,
den erzeugten Aassemblercode anzuschauen, gelegentlich sieht man da erst,
was wirklich passiert! ;) -- natürlich, je mehr man programmiert, um so mehr
kann man sich denken, welche Sprachkonstrukte welchen Code erzeugen, aber
manchmal kann es nicht schaden, dem Compiler zu mißtrauen! ;)
Z.B. ist einem am Anfang oft nicht klar, welche Auswirkungen eine Promotion
von Datentypen in Ausdrücken hat, wenn z.B. "char" auf "int" promoted wird,
und ein Prüfen auf "Ä" in einer switch-Anweisung nicht funktioniert, weil
char vorzeichenbehaftet ist, aber man eine "unsigned char" Variable in der
switch-Anweisung verwendet hat! ;)
> Ada ist vielleicht laengst nicht so weit verbreitet, aber der Standard
> spezifiziert die Sprache und die mindestens mitzuliefernden packages
> sehr genau, und diese sind auch umfangreich genug, um auch komplexe
> Aufgaben zu bewaeltigen ... Das Problem des "mangelnden Sprtachumfangs
> laut Standard", das bei Pascal zu einem gewissen "Wildwuchs der Dialekte"
> gefuehrt hat, existiert also bei Ada nicht.
> Meine Erfahrungen mit Ada liegen allerdings auch schon wieder ein paar
> Jahre zurueck.
Gibt es für Windows einen kostenlosen oder erschwinglichen ADA-Compiler?
Grüße,
Ekkehard.
Claus Reibenstein
> Mit drei Buchstaben bekommt man über 140000 Variablennamen hin
Aber keine 140000 sinnvollen.
> - es will doch wohl keiner sagen, daß ihm das nicht reichen
> würde:-) Schließlich ist ein Programm ja immer noch ein
> Programm und kein Roman.
Trotzdem sollte ein Programm nicht nur vom Compiler, sondern auch von
Menschen verstanden werden. Spätestens bei der Fehlersuche sind
sprechende Bezeichner äußerst hilfreich.
Gruß. Claus
Claus Reibenstein
> Wolfgang Kaufmann <wk-u...@news.theparallax.net> wrote:
>
>>* Thus spoke Claus Reibenstein <c.reib...@pop-hannover.de>:
>>
>>>Ich habe einmal in einem umfangreichen FORTRAN-Projekt (CAD-System
>>>speedikon, falls das jemand kennt) einen Fehler suchen dürfen, der sich
>>>schließlich als Tippfehler in einem Variablennamen herausstellte (ALFA
>>>statt ALPHA).
>
> implicit none
>
> waere die Loesung gewesen
Leider kannte der Compiler das damals nicht :-(
Fup2p, da hier ziemlich off topic.
Gruß. Claus
Bodo Thiesen
>Bodo Thiesen schrieb:
>
>> 1. Du kannst nicht Programmieren
>> 2. Du kennst keine Programmiersprache
>>
>> (Ja, das sind zwei verschiedene Dinge)
>
>Wem sagst Du das :-)
Denen, die das immer noch nicht gerafft haben. ;-)
>> Gut, vergleichen wir das jetzt mal mit C++. Zuerst mal, müssen wir hier eine
>> Klasse finden.
>
>An dieser Stelle Einspruch, Euer Ehren.
>
>Natürlich kann man ein Programm beliebig verkomplizieren. Aber das muss
>ja nicht sein. Dieses kleine C++-Programm täte es auch:
>
> #include <iostream>
>
> int main(void) {
> cout << "Hello World." << endl;
> }
>
>Et voilà - keine Zeile mehr als die C-Version.
Toll, und wo wird da die Sprache C++ selbst wirklich genutzt? Natürlich habe
ich das Programm extrem verkompliziert (das habe ich aber auch irgendwie
angemerkt gehabt). Es gibt mir ja gerade darum, dieses Hello-World Programm
mit gewalt OO zu machen (was mir dann wohl trotzdem nur bedingt gelungen
ist - wie will man sowas triviales auch OO lösen?)
>> * Entgegen zur Basic-Version dürfen wir hier erstmal anfangen,
>> * die ganzen Variablen aufzuzählen, die wir so brauchen
>> * werden ...
>
>Was in jedem Fall zu begrüßen ist!
Klar. Aber nicht unbedingt für Anfänger, weil diese dann auch noch über
Datentypen bescheid wissen müssen. Das Ursprungs-Basic kennt nur zwei:
Zahl und Zeichenkette. Beide klar unterschieden durch ein '$'-Zeichen
(oder eben keines). Das wesentliche, um was es mir geht, ist es, möglichst
wenig einführen zu müssen, bevor der blutige Anfänger loshacken kann. Das
heißt natürlich nicht, daß man lange bei Basic bleiben soll. Ein paar
Wochen / Monate (dann aber auch ausschließlich Basic), und dann rüber an
ein anders Werkzeug (ggf. Pascal, Ada, C würde ich an dieser Stelle noch
nicht vorschlagen, wegen den vielen Zeigern und vor allem der blöden
String-Implementation).
>[Falscher Variablenname - mit C wäre das nicht passiert]
>[C, leistungsfähige Sprache, verlangt Disziplin]
Der blutige Anfänger ist froh, wenn er sein Programm syntaxfehlerfrei hat,
das muß man ihm meiner Meinung nach nicht unbedingt erschweren. Tatsächlich
hat mich aber genau dieses Problem (Variablennamen) unter Basic auch schon
immer gestört. Man muß nur den Knick bekommen, möglichst früh der Sprache
Basic den Rücken zuzuwenden.
Bodo Thiesen
> Rainer Weikusat hat geschrieben:
>> Roland Damm <rolan...@arcor.de> writes:
>>
>>> Mein Problem beim Umstieg auf C++ ist diese im idealfall
>>> volkommen andere Herangehensweise an Probleme.
>>
>> Nein. Es sind immer noch Datenstrukturen, auf denen
>> irgendwelche Funktionen arbeiten, die irgendetwas über ein
>> Interface kommunizieren.
>
> Das wohl ja noch. Aber es wird dann immer auf Vererbung
> rumgeritten. Ich verstehe nicht so ganz, wieso ich erst eine
> Funktion schreiben sollte, die sowieso nichts kann, nichts tut
> und nachher auch gar nicht gebraucht wird:-). Nur damit sich
> andere davon etwas erben können.
Stelle Dir vor, Du hast eine Klasse Shape. Von dieser leitest Du jetzt eine
Klasse Ellipse, und eine Klasse Rectangle ab. Von Rectangle wiederum die
Klasse Square, und von Ellipse die Klasse Circle. Wenn Du jetzt in Shape
eine Methode Paint definiert hast, kannst Du folgendes machen:
Share * shape[MAX_SHAPES];
shape[0]=new Circle;
shape[1]=new Rectangle;
shape[2]=new Ellipse;
shape[3]=new Square;
for (i=0;i<4;++i)
shape[i]->Paint();
Und schon hast Du alle Figuren gezeichnet, ohne daß die zeichnende Funktion
1. die Konkreten Datentypen kennen muß
2. Sonstige kenntnisse über die Objekte haben muß
D.h., Du kannst eine Funkion zum zeichnen sämtlicher Objekte schreiben, ohne
zu wissen, welche Objekte Du damit später einmal zeichnen können wirst. So
ein Shape hat weiterhin Eigenschaften wie eine Position, somit ließen sich
z.B. sämgliche Shapes um einen gleichen Vektor verschieben - wieder eine
Funktion, die die Objekte nicht zu kennen braucht. Man könnte der Klasse
Shape auch noch einen Drehwinkel verpassen, damit könnte man dann auch eine
gesamte Ansammlung von Shapes korrekt drehen. Der Phantasie sind da keine
Grenzen gesetzt. Und alle diese Aktionen haben gemeinsam, daß man sie
definieren kann, ohne die konkreten Klassen kennen zu müssen, auf die sie
später angewendet werden können. Also ich empfinde das schon als genial.
Nichts desto trotz sollte man sich bewusst machen, daß das ganze (mit viel
mehr Aufwand) letztlich in C auch gingt.
struct shape {
void * shape_data;
void (*paint)(...);
};
Und die Abgeleiteten "Klassen" müssten dann im Konstruktor nur paint
entsprechen setzen - nichts anderes passiert bei C++ auch, nur daß man da
davon nicht mitbekommt.
Bodo Thiesen
Ich dachte, das Ziel wäre es gewese, die Leute
dazu zu bewegen, sich neue Duden zu kaufen :-.
Bodo Thiesen
> Hatte ich nicht schon gesagt, daß die Verhältnisse bei Unix
> etwas anders sind? Aber selbst da, der Großteil der Programme,
> die ich benutze, arbeiten mit und auf einer grafischen
> Oberfläche. Und ich bin auch ganz zufrieden damit.
>
> Und ich sprach ja auch nur von der Großzahl der Benutzer. Die
> Leser dieser NG dürften wohl kaum repräsentativ für den
> Durchschnittsbenutzer sein. Also von dir (der du als
> Linux-Nutzer ohnehin schon ein Exot bist) auf den Durchschnitt
> zu schließen, ist etwas hergeholt.
Du hast eine Aussage als allgemeingültig hingestellt:
| Aber sicher sind die Zeiten der Kommandozeile zu Ende.
Und Dir wurde hier das Gegenteil behauptet. Ich benutze auch Sylpheed zum
Mail und News lesen und schreiben, das ändert aber nichts daran, daß ich
nach wie vor gerne meine Programme an der Kommandozeile (editor) schreibe,
und von dort ein make, oder ein cvs diff/add/commit starte. Und dabei ist
es mir auch herzlich egal, wie representativ genau ich bin, denn selbst
als einziges Gegenbeispiel hätte ich Deine Aussage wiederlegt. Bei mir ist
jedenfalls die Kommandozeile SEHR lebendig, und seit der neuesten
Wurm-Attacke, für die man dann auf der Eingabeauffortderung »shutdown -c«
eintippen muß, sollten auch Windows-Benutzer wieder wissen, was eine
Kommandozeile ist. Spätestens aber dieses Beispiel zeigt, daß selbst unter
Wintendo die Kommandozeile LEBENSNOTWENDIG sein kann.
Bodo Thiesen
Vergiss ihn, der redet andauernd so'n komisches Zeug - weiß auch net,
warum. Vielleicht liegt es ja an der Uni, oder an der Gegend allgemein,
habe nie danach gefragt ...
Vinzent 'Gadget' Hoefler
>Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> wrote:
>
>>Die NRS verbessert nichts, sie aendert nur, ohne wirklich etwas zu
>>aendern. Und das ist als Ziel sinnlos.
>
>Ich dachte, das Ziel wäre es gewese, die Leute
>dazu zu bewegen, sich neue Duden zu kaufen :-.
*psst* Ja. Inoffiziell.
Vinzent.
Vinzent 'Gadget' Hoefler
>Gibt es für Windows einen kostenlosen oder erschwinglichen ADA-Compiler?
Ja. GNAT. Und es heisst Ada.
<URL:ftp://cs.nyu.edu/pub/gnat>
Vinzent.
Ekkehard Morgenstern
"Vinzent 'Gadget' Hoefler" <JeLlyFish...@gmx.net> schrieb im
Newsbeitrag news:bpkivh$1ona3a$7...@ID-175126.news.uni-berlin.de...
Danke!!! :-)
Rainer Weikusat
> Falk Hueffner <falk.h...@student.uni-tuebingen.de> wrote:
>> Kapier ich nicht. Inwiefern ist es fuer die Frage, ob C++ eine
>> geeignete Anfaengersprache ist, von Relevanz, ob ich motiviert bin
>> oder nicht, C++ zu lernen?
C++ eignet sich als Anfängersprache genausogut wie jede andere. Eine
Sprache kann auch nicht »fehlerträchtig« sein. Das ist absurd. Du
kannst sie nicht beherrschen, dann machst Du bei ihrer Verwendung
Fehler. Insofern wäre die Frage besser als 'Lohnt es sich, C++ zu
lernen' formuliert gewesen, wobei 'lohnt es sich' keinen Geldbetrag
meint. Ich würde diese Frage mittlerweile mit 'nein' beantworten,
obwohl ich die Sprache interessant und nützlich finde, denn ich bin
mit Ergebnissen ihrer Benutzung konfrontiert, und in den meisten
Fällen wäre es wohl ratsam, den Benutzern etwas weniger 'rope to hang
themselves' zu geben.
Das gehört nicht hierher, aber Bodos explizit urheberrechtsgeschützte
'Der Spint Doch!!1' Daueraussage gehört das auch nicht.
> Vergiss ihn, der redet andauernd so'n komisches Zeug - weiß auch net,
> warum. Vielleicht liegt es ja an der Uni, oder an der Gegend allgemein,
> habe nie danach gefragt ...
Wollte das eigentlich schon mal jemand kopieren?
Vinzent 'Gadget' Hoefler
>C++ eignet sich als Anfängersprache genausogut wie jede andere.
Wenn Du den richtigen Lehrer hast, mag das sogar stimmen. Im
Selbststudium ist das ungefaehr so erfolgreich wie der Versuch eines
Anfaengers, ohne jede Vorkenntnisse im Selbststudium Karate zu
erlernen.
>Eine Sprache kann auch nicht »fehlerträchtig« sein.
Falsch, man braucht z.B. lediglich Fehlertraechtigkeit als den Wert
von 1/p auffassen, wobei p die Wahrscheinlichkeit ist, dass ein
zufaelliges, aber den grundsaetzlichen Sprachregeln gehorchendes
Konstrukt zu einem ausfuehrbaren Programm uebersetzt werden kann,
schon kann man das sogar begrenzt mathematisch erfassen.
>Das ist absurd. Du
>kannst sie nicht beherrschen, dann machst Du bei ihrer Verwendung
>Fehler.
Dann gibt es ganz offensichtlich niemanden, der irgendeine Sprache
beherrscht.
Vinzent.
Rainer Weikusat
> Rainer Weikusat hat geschrieben:
>> Nein. Es sind immer noch Datenstrukturen, auf denen
>> irgendwelche Funktionen arbeiten, die irgendetwas über ein
>> Interface kommunizieren.
>
> Das wohl ja noch. Aber es wird dann immer auf Vererbung
> rumgeritten. Ich verstehe nicht so ganz, wieso ich erst eine
> Funktion schreiben sollte, die sowieso nichts kann, nichts tut
> und nachher auch gar nicht gebraucht wird:-).
Der Prototyp wird gebraucht. Die klassischen Beispiele dafür, warum so
etwas nützlich sein kann, sind leider alle etwas unbrauchbar. Ich
könnte aber ein praktisches anbieten (sogar in C).
typedef int sentry_ip_match_function(void const *object, u32 ip);
struct sentry_ip_base {
struct sentry_ip_base *p;
sentry_ip_match_function *does_match;
};
/* functions */
struct sentry_ip_base *sentry_make_single_ip(OpsecSession *session, u32 ip);
struct sentry_ip_base *sentry_make_ip_range(OpsecSession *session, u32 base_ip, unsigned n_ips);
struct sentry_ip_base *sentry_make_ip_net(OpsecSession *session, u32 network, u32 netmask);
static inline int sentry_ip_matches(struct sentry_ip_base const *object, u32 ip)
{
return object->does_match(object, ip);
}
Wobei im zugehörigen .c-File entsprechende Strukturen definiert sind,
die die jeweils unterschiedlichen Daten aufnehmen. Aus der Sicht des
restlichen Programmes ist das aber egal, denn das möchte nur wissen,
ob die Bedingung unter irgendwelchen Umständen wahr gewesen ist und nicht
genau unter welchen Umständen sie das gewesen war. Rein technisch
gesehen ist das overhead, aber es vereinfacht Änderungen, weil im
aufrufenden Code nur noch eine Zeile Code steht, die man außerdem
beliebig repositionieren kann.
> Nur damit sich andere davon etwas erben können. Vieleicht hilft das
> ja, Ordnung im Code zu halten. Aber da ist meine Erfahrung eher
> die, daß es bei der Ordnung im Code in erster Linie auf die
> Disziplin des Programmierers ankommt.
Das kommt leider stark darauf an, was der Code tun soll. Eine simpel
klingende Aufgabenstellung: Nehme einen Block von Text (keinen
beliebig großen, sowas gibt es nicht) und teile den in Zeilen
auf. Erster Versuch: C-library, strtok. Das verschluckt leider
angefangene Zeilen und um das Ende der angefangenen Zeile zu finden,
muß man die Längen aller Zeilen berechnen lassen, obwohl das schon
getan wurde, um einen eventuell vorhandenen Rest lokalisieren zu
können. Zweiter Versuch: 4.4BSD, strsep. Scheidet aus wegen
Nichtvorhandensein auf einer potentiellen Zielplattform. Dritter
Versuch, 'was solls':
static int next_line(char *start, char *bound, char **end)
{
char *run;
run = start;
while (*run != '\n' && ++run < bound);
if (run < bound) {
*run = 0;
*end = run;
return LINE;
}
return PARTIAL_LINE;
}
[...]
bound = rptr + nr;
start = rptr;
do {
rc = next_line(start, bound, &end);
if (rc == LINE) {
if (end > start) debug("stderr: %s", start);
start = end + 1;
}
} while (rc != PARTIAL_LINE && start < bound);
switch (rc) {
case PARTIAL_LINE:
if (start > rptr) {
remain = bound - start;
memcpy(buf, start, remain);
rptr = buf + remain;
avail = sizeof(buf) - remain;
break;
}
warn("line is too long, ignoring");
case LINE:
rptr = buf;
avail = sizeof(buf);
}
Es gibt vermutlich Leute, die sowas immer noch kompliziert nennen
würden (es gibt diverse Sonderfälle), aber die haben die
Implementierung ohne Hilfsfunktion und mit Indizes zum Glück nicht
gesehen.
> Ebenso könnte OO bei besonders großen Projekten vorteilhaft sein.
Die meisten 'besonders großen Projekte' sind vermutlich eher
'besonders aufgeblähte Projekte'.
> Gut, da muß ich ganz klar sagen, daß ich da keine Erfahrung
> habe. Das gröste monolithische (damit meine ich nicht eine Fülle von
> Funktionen aus diversen Quellen in diversen Programmiersprachen)
> Programm dem ich begegnet bin, hatte vieleicht 100000 Zeilen. Und es
> war sehr übersichtlich geschrieben. Gut, man mußte sich an die
> Marotte des Programmierers gewöhnen, switch-Anweisungen über
> tausende von Zeilen gehen zu lassen, in dem er den Code für jede
> einzelaktion direkt dort reingeschrieben hatte....:-),
Und falls er das nicht getan hätte, wären es wohl auch eher 10.000 als
100.000 Zeilen geworden.
F'up2 poster, denn mit C hat das alles nichts zu tun.
René Möhring
> Claus Reibenstein <c.reib...@pop-hannover.de> wrote:
>
>>Bodo Thiesen schrieb:
>>
>>> 1. Du kannst nicht Programmieren
>>> 2. Du kennst keine Programmiersprache
>>>
>>> (Ja, das sind zwei verschiedene Dinge)
>>
>>Wem sagst Du das :-)
>
> Denen, die das immer noch nicht gerafft haben. ;-)
>
>>> Gut, vergleichen wir das jetzt mal mit C++. Zuerst mal, müssen wir hier eine
>>> Klasse finden.
>>
>>An dieser Stelle Einspruch, Euer Ehren.
>>
>>Natürlich kann man ein Programm beliebig verkomplizieren. Aber das muss
>>ja nicht sein. Dieses kleine C++-Programm täte es auch:
>>
>> #include <iostream>
>>
>> int main(void) {
>> cout << "Hello World." << endl;
>> }
>>
>>Et voilà - keine Zeile mehr als die C-Version.
>
> Toll, und wo wird da die Sprache C++ selbst wirklich genutzt? Natürlich habe
Die Streams, wie hier cout, sind doch sehr C++-mäßig. Unter der Haube
geht da schon einiges ab.
--
I'm not a racist, I hate everyone equally!
Rainer Weikusat
> Rainer Weikusat wrote:
>>Eine Sprache kann auch nicht »fehlerträchtig« sein.
>
> Falsch, man braucht z.B. lediglich Fehlertraechtigkeit als den Wert
> von 1/p auffassen, wobei p die Wahrscheinlichkeit ist, dass ein
> zufaelliges, aber den grundsaetzlichen Sprachregeln gehorchendes
> Konstrukt zu einem ausfuehrbaren Programm uebersetzt werden kann,
> schon kann man das sogar begrenzt mathematisch erfassen.
Man kann alles irgendwie auffassen. Von mir persönlich weiß ich
einigermaßen, welche Fehler ich typischerweise mache, und das sind für
8568 Zeilen C genau zwei 'C-typischer Fehler', der sehr leicht zu
finden war, denn der betroffene Programmteil hat schlicht etwas
vollkommen anderes getan, als das, was er sollte (Argumente
vertauscht, was aufgrund von implicit conversions durch den Compiler
ging und eine uninitialisierte Variable). Mir reicht das aus, um
seitdem Leuten von der Verwendung von C abzuraten, außer sie können es
ohnehin oder haben keine andere Wahl. Aber dazu brauche ich keine
wie-auch-immer zusammengerechneten Zahlen von jemandem, der ein
Konkurrenzprodukt verkaufen möchte. Irgendwann kommt man ohnehin an
den Punkt, an dem man notgedrungen anfängt, irgendetwas zu
disassemblieren und womit das kompiliert wurde, ist ziemlich egal. C
kann man so schreiben, daß man sich in der Compilerausgabe auch noch
zurechtfindet, bei allen anderen [gängigen] Sprachen wird das etwas
schwieriger. Das ist nach meinem Dafürhalten ein Vorteil. Praktisch
kommt der allerdings meistens nicht zum Tragen, weil niemand, der
etwas auf sich hält, freiwillig simpel aussehenden Code schreibt oder
komplexen durch weniger komplexen mit identischer Funktion ersetzt,
dann dafür benutzt man ja 'optimierende Compiler' und das
Totschlagargument gegen nachvollziehbar funktionierenden Code lautet
'es ist aber nicht bewiesen, daß der schneller abläuft'. Es zwar mehr
oder minder erwiesen, daß komplexer Code komplexe Fehler hat, aber das
wird niemanden davon abhalten, ihn trotzdem zu schreiben. Dafür bietet
ein C-Compiler sehr wenig Hilfestellung und weil ja niemand jemals an
irgendetwas schuld ist, ist die Sprache also fehlerträchtig und nicht
etwa die Vorgehensweise.
Diesem Problem kann man mit Primitivsprachen wie Ada beikommen, denn,
um ein Perl-Motto zu varrieren, 'es macht die einfachen Dinge schwierig
und schwierigen deswegen außerordentlich schwierig' und niemand fällt
mehr aufgrund von manischer Selbstüberschätzung über seine eigenen
Füße. Eine Lösung für dieses Problem, aber das liegt nicht in der
Sprache als solcher begründet, sondern in der Art, wie sie
üblicherweise benutzt wird.
Vinzent 'Gadget' Hoefler
>Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> writes:
>
>Man kann alles irgendwie auffassen.
Latuernich.
>Von mir persönlich weiß ich
>einigermaßen, welche Fehler ich typischerweise mache,
Du machst primaer genau einen Fehler und das ist der, von Dir auf alle
anderen zu schliessen.
>und das sind für
>8568 Zeilen C genau zwei 'C-typischer Fehler', der sehr leicht zu
>finden war, denn der betroffene Programmteil hat schlicht etwas
>vollkommen anderes getan, als das, was er sollte (Argumente
>vertauscht, was aufgrund von implicit conversions durch den Compiler
>ging
Hmm. Ich erinnere mich an gewisse Diskussionen, wo Du Leute, denen so
was passierte, mehr oder weniger als Idioten abgestempelt hast.
Interessant. :-)
>und eine uninitialisierte Variable).
Das ist nicht einmal C-typisch.
>ohnehin oder haben keine andere Wahl. Aber dazu brauche ich keine
>wie-auch-immer zusammengerechneten Zahlen von jemandem, der ein
>Konkurrenzprodukt verkaufen möchte.
You miss the big picture.
>Irgendwann kommt man ohnehin an
>den Punkt, an dem man notgedrungen anfängt, irgendetwas zu
>disassemblieren und womit das kompiliert wurde, ist ziemlich egal.
Nunja. Die Pragmas Inspection_Point und Reviewable koennen da relativ
hilfreich sein. :)
Uebrigens ist genau das ein Grund, warum ich prinzipiell jedem
empfehle, wenigstens einen blassen Schimmer von Assembler zu haben.
>C
>kann man so schreiben, daß man sich in der Compilerausgabe auch noch
>zurechtfindet, bei allen anderen [gängigen] Sprachen wird das etwas
>schwieriger.
Das sehe ich nicht. Gut, compiliertes Lisp habe ich mir noch nicht
angeschaut.
>Das ist nach meinem Dafürhalten ein Vorteil. Praktisch
>kommt der allerdings meistens nicht zum Tragen, weil niemand, der
>etwas auf sich hält, freiwillig simpel aussehenden Code schreibt oder
>komplexen durch weniger komplexen mit identischer Funktion ersetzt,
>dann dafür benutzt man ja 'optimierende Compiler' und das
>Totschlagargument gegen nachvollziehbar funktionierenden Code lautet
>'es ist aber nicht bewiesen, daß der schneller abläuft'.
Dein "Niemand" ist /etwas/ pauschal. Mein Arbeitsergebnis bestand
heute z.B. bis jetzt aus einer negativen Produktivitaet[0], nachdem
ich etwa 400 Zeilen mehr oder weniger redundanten Code in eine lesbare
Version umgewandelt habe, und diese jetzt dabei inklusive der zwei
eingefuehrten lokalen Funktionen jetzt aus weniger als der Haelfte
besteht und dazu sogar noch generischer[1] ist.
>Es zwar mehr
>oder minder erwiesen, daß komplexer Code komplexe Fehler hat, aber das
>wird niemanden davon abhalten, ihn trotzdem zu schreiben.
Leider.
>Dafür bietet
>ein C-Compiler sehr wenig Hilfestellung und weil ja niemand jemals an
>irgendetwas schuld ist, ist die Sprache also fehlerträchtig und nicht
>etwa die Vorgehensweise.
Genau das ist das Problem an C. Der Nettoeffekt ist aber, dass
ausreichend maechtige restriktive Sprachen Dir am Ende mehr Freiheiten
lassen. Und vor allem, man lernt etwas Sinnvolles dabei. Hint: Wir
sprachen ja von Anfaengern.
>Diesem Problem kann man mit Primitivsprachen wie Ada beikommen,
"Primitiv"sprache ist wohl etwas danebengegriffen. Aber lassen wir
das. Ich kenne Deine Aversion gegen Sprachen, die moderne
Software-Design-Konzepte auch praktisch umsetzen. Mit ausreichend
Disziplin kann man das schliesslich auch in C u.ae. simulieren.
>denn,
>um ein Perl-Motto zu varrieren, 'es macht die einfachen Dinge schwierig
>und schwierigen deswegen außerordentlich schwierig'
Abhaengig davon, was man unter "einfachen Dingen" versteht, mag das
stimmen. Aber das ist mir, ehrlich gesagt, vollkommen egal, weil
bestenfalls 95% der Probleme, die ich zu loesen habe, wirklich
"einfach" sind. Und dummerweise zaehlt am Ende auch nicht der einzelne
Algorithmus als solches, sondern die Loesung als Ganzes.
Aber selbst wenn, das relativiert sich locker nach spaetestens ein
paar Monaten. Und *das* ist es, was zaehlt, wenn man an Systemen
schreibt, die schaetzungsweise wenigstens die naechsten 10 Jahre
ueberleben sollen, ohne dass dabei der Wartungsaufwand exponentiell
anwaechst.
Desweiteren tendiere ich eher dazu, dass jemand, der das behauptet,
die Sprache nicht wirklich verstanden hat. Meine Erfahrung ist
naemlich die, dass in 98% der Faelle der Compiler vollkommen recht
hat, wenn er mich anmeckert.
>und niemand fällt
>mehr aufgrund von manischer Selbstüberschätzung über seine eigenen
>Füße.
Offensichtlich leiden wir einfach alle an Selbstueberschaetzung. Und
die Story, die mich am Dienstag beinahe nach Suedafrika gebracht
haette, erzaehle ich jetzt nicht. Nur so viel: Manchmal ist es schon
praktisch, wenn man wegen der Nutzung restriktiver Primitivsprachen
gewisse Fehler einfach ausschliessen kann.
>Eine Lösung für dieses Problem, aber das liegt nicht in der
>Sprache als solcher begründet, sondern in der Art, wie sie
>üblicherweise benutzt wird.
Es ist ein Problem der Sprache, wenn es weitgehend als guter bis
brauchbarer Stil gilt, sie so zu benutzen und es faktisch unmoeglich
ist, das anders zu tun. IIRC warst Du ein kein Verfechter der Idee,
Konstanten als erste im Vergleich zu nennen, um z.B. Dinge wie
|if (options == (__WCLONE|__WALL) && (current->uid = 0))
zu vermeiden, oder?
Vinzent.
[0] Wenn man "written lines of code" mal als Produktivitaet auffasst,
wovon ich grundsaetzlich abrate.
[1] Generisch i.S.v. "Wenn unserem Produktmanager mal wieder auf dem
Scheisshaus was Neues einfaellt, laesst sich die Idee schneller
fehlerfrei in der Praxis integrieren."
Tibor Pausz
> Heißt das nun, daß OOP schlecht ist?
Man kann Programme unnötig verkomplizieren, das durfte man als bekannt
voraussetzen. In C++ kann man OO Konzepte benutzen muß es aber nicht.
Genauso gut könnte man als Argument ein C OO RunTime System schreiben
und ein C OO Hello World schreiben. Nur sinnvoll wird das für das
Problem Hello World trotzdem nicht.
P.S. Das C++ Beispiel läßt sich auf folgendes eindampfen.
#include <iostream>
int main () {
std::cout << "Hello World!" << std::endl;
return 0;
}
Claus Reibenstein
> P.S. Das C++ Beispiel läßt sich auf folgendes eindampfen.
>
> #include <iostream>
>
> int main () {
> std::cout << "Hello World!" << std::endl;
> return 0;
> }
Da war meine Fassung in <bphrrn$1ofvt5$4...@ID-94739.news.uni-berlin.de>
aber noch etwas kürzer ;-)
Gruß. Claus
Rainer Weikusat
> Rainer Weikusat wrote:
>>Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> writes:
>>Von mir persönlich weiß ich einigermaßen, welche Fehler ich
>>typischerweise mache,
>
> Du machst primaer genau einen Fehler und das ist der, von Dir auf alle
> anderen zu schliessen.
Ich widerspreche einer Allgemeinaussage auf der Basis eines
Gegenbeispiels.
>>und das sind für 8568 Zeilen C genau zwei 'C-typischer Fehler', der
>>sehr leicht zu finden war, denn der betroffene Programmteil hat
>>schlicht etwas vollkommen anderes getan, als das, was er sollte
>>(Argumente vertauscht, was aufgrund von implicit conversions durch
>>den Compiler ging
>
> Hmm. Ich erinnere mich an gewisse Diskussionen, wo Du Leute, denen so
> was passierte, mehr oder weniger als Idioten abgestempelt hast.
Eher Leute, die sowas für ein schwerwiegendes Problem an sich
halten. Das war es nämlich nicht. Es war eher ein schwerwiegendes
Problem, eine Möglichkeit zu bekommen, den fraglichen Code zu testen
und ist es partiell immer noch. Das ist mal wieder so ein bestenfalls
halb sinnvolles Wahnsinnsprojekt und die Arbeit mache ich unbezahlt zu
Hause, denn sobald ich in der Firma auftauche, muß ich primär
irgendwelche Leute, die schlicht Angst vor Computern haben (typische
Seiteneffekt von 'zuviel Windows') dazu überreden, daß ich die Arbeit
tun darf, für deren Erledigung ich eigentlich bezahlt werde (oder
wurde? Kann man bei informellen Jobs auf Stundenbasis nie so genau
sagen ...).
>>und eine uninitialisierte Variable).
>
> Das ist nicht einmal C-typisch.
Es ist trotzdem ärgerlich, wenn ein Compiler, der grundsätzlich immer
warnt, sobald zwischen Deklaration und erster Zuweisung mehr als ein
paar Zeilen liegen, daß auf einmal nicht mehr tut, falls man mehrere
identische Funktionen durch macros erzeugen läßt.
>>Irgendwann kommt man ohnehin an den Punkt, an dem man notgedrungen
>>anfängt, irgendetwas zu disassemblieren und womit das kompiliert
>>wurde, ist ziemlich egal.
>
> Nunja. Die Pragmas Inspection_Point und Reviewable koennen da relativ
> hilfreich sein. :)
In diesem Fall wohl eher nicht.
Das ein Hexdump von einer dieser netten, undokumentierten Strukturen,
mit denen ich hier arbeiten muß.
(gdb) x/40xw session
0x80927e8: 0x00000003 0x53534553 0x204e4f49 0x333a4449
0x80927f8: 0x00000000 0x00000000 0x00000000 0x00000000
0x8092808: 0x0806ba88 0x08091ed8 0x08092858
^^^^^^^^^^ ^^^^^^^^^^
Zeiger auf ein
'OpsecEnvironment'
Zeiger auf einen Zeiger
auf die zur session gehörende 'entity'
Findet man auch ganz leicht, sobald man vor dem Problem steht, daß man
den richtigen Wert da wieder reinschreiben muß und ihn
zweckmäßigerweise irgendwo gesichert hat, wo die Bibliothek nicht ohne
weiteres drankommt. Zum Glück war das hier noch nicht der Fall, aber
ich habe da noch sowas:
/*
This may look redundant, but at least Opsec NG FP3
build number 53026 will forget about the data
argument in case of a failed name resolution after
the error returned for the first module and will
call this with a data argument of NULL.
*/
if (data) {
set_ops_session_property(session, monitor_ack_data, data);
ld = data;
} else ld = get_ops_session_property(session, monitor_ack_data);
Und falls man mich läßt, würde ich auch noch ganz gerne ermitteln, was
da eigentlich schiefläuft. Weil der Effekt sicher vorhersagbar ist,
denke ich ungewollte Interaktionen durch andere threads ausschließen
zu können und der Code von mir, der in dieser Situation ausgeführt
wird, besteht aus einem
return IST_OK_GEH_WIEDER_SPIELEN;
Daran kann es eigentlich auch nicht liegen :->. Cool fand ich auch
noch das hier:
(gdb) disas
Dump of assembler code for function write:
0x407ae9f0 <write>: push %ebx
0x407ae9f1 <write+1>: mov 0x10(%esp,1),%edx
0x407ae9f5 <write+5>: mov 0xc(%esp,1),%ecx
0x407ae9f9 <write+9>: mov 0x8(%esp,1),%ebx
0x407ae9fd <write+13>: mov $0x4,%eax
0x407aea02 <write+18>: int $0x80
'Der syscall ohne Wiederkehr' -- ein in-kernel deadlock, daß durch
irgendeine seltsame Interaktion von asychronous cancel und
AF_UNIX-datagram sockets zustande kam und schon ziemlich
prozeßbeendigungsresistent war.
>>C kann man so schreiben, daß man sich in der Compilerausgabe auch noch
>>zurechtfindet, bei allen anderen [gängigen] Sprachen wird das etwas
>>schwieriger.
>
> Das sehe ich nicht.
Vielleicht etwas präziser formuliert: Ein C-Compiler fügt einem
Programm mangels Laufzeitumgebung sehr wenig Code hinzu, den er selber
erzeugt hat.
>>Dafür bietet ein C-Compiler sehr wenig Hilfestellung und weil ja
>>niemand jemals an irgendetwas schuld ist, ist die Sprache also
>>fehlerträchtig und nicht etwa die Vorgehensweise.
>
> Genau das ist das Problem an C.
Zunächst ist das bloß eine Eigenschaft von C. Das ist auf langsamen
Rechnern mit spartanischer Hauptspeicherausstattung entworfen worden
und da wären die 80k Maschinencode, die ich hier mittlerweile angehäuft
habe, bereits ein monströs großes Programm gewesen. Jedes Werkzeug hat
ein sinnvolles Einsatzgebiet und das von C umfaßt meiner Meinung keine
'großen Systeme', auch wenn es sich dafür benutzen läßt.
> Der Nettoeffekt ist aber, dass ausreichend maechtige restriktive
> Sprachen Dir am Ende mehr Freiheiten lassen. Und vor allem, man
> lernt etwas Sinnvolles dabei.
Sinnvoll nach Maßgabe wessen? Sinnvollerweise macht man ein Diplom in
einem naturwissenschaftlich oder mathematisch ausgerichteten
Studiengang und lernt soviel PHP4 und Java, daß jemand, dem schon eine
Programmiersprache Probleme bereitet, einem glaubt, daß man
300-Zeilen-CGIs schreiben kann. Alles weitere ist eine ziemlich
brotlose Kunst und mE höchstens als Rentnervergnügen zu empfehlen. Es
stört ja schließlich niemanden, falls ein Computer nicht tut, was er
soll, solange die Prospekte schön bunt sind.
>>Diesem Problem kann man mit Primitivsprachen wie Ada beikommen,
>
> "Primitiv"sprache ist wohl etwas danebengegriffen.
* 5.2:: Assignment Statements
* 5.3:: If Statements
* 5.4:: Case Statements
* 5.5:: Loop Statements
* 5.6:: Block Statements
* 5.7:: Exit Statements
* 5.8:: Goto Statements
Das ist der Kern von 'Ada -- The Language' und besonders viel ist das
nicht. Sogar C kennt abweisende und nicht abweisende Schleifen und
zunächst mal dienen solche Konstrukte nicht 'der Optimierung'
(blafasel), sondern dazu, Algorithmen sinnvoll zu beschreiben und
i = 0;
while (i++ < 10) { ....; }
ist auch dann eine sinnlose Formulierung, wenn der Compiler es
automatisch zu
i = 0;
do { ...; } while (++i < 10);
deformiert. Ich kann mich dumpf daran erinnern, daß 'Optimieren' mal
'Spezialbehandlung von Sonderfällen' bedeutet hatte und nicht
'semantisch sinnvoller Sprachgebrauch' und würde es immer noch stark
vorziehen, einen Algorithmus als erstes mal exakt zu beschreiben und
mich ansonsten darauf zu verlassen, daß ein ordentlicher Compiler
(also nicht sowas wie gcc3) daraus vernünftigen Code generieren
wird.
> Aber lassen wir das. Ich kenne Deine Aversion gegen Sprachen, die
> moderne Software-Design-Konzepte auch praktisch umsetzen.
Das ist eher eine Aversion gegen Sprachen, in denen man mit viele
reservierte Worte braucht, um vergleichsweise wenig auszudrücken.
> Desweiteren tendiere ich eher dazu, dass jemand, der das behauptet,
> die Sprache nicht wirklich verstanden hat. Meine Erfahrung ist
> naemlich die, dass in 98% der Faelle der Compiler vollkommen recht
> hat, wenn er mich anmeckert.
[...]
entity = ops_get_own_entity(session); \
debug("session %p terminated: %d", session, reason); \
if (sic_error) debug("sic error '%s' (%d)", sic_error, \
sic_msg); \
ops_session_terminated(entity, session, reason, sic_error, sic_msg); \
\
trace(#name); \
set_sentry_abort_loc(&gen_abort); \
handler = get_handlers(entity)->name; \
if (handler && !setjmp(gen_abort)) { \
ops_set_entity(entity); \
ops_set_session(session); \
handler(session); \
ops_set_entity(NULL); \
ops_set_session(NULL); \
} \
\
destroy_ops_session_data(session); \
}
Das bewirkt folgende Warnung:
./src/ops_generic.c:124: warning: variable `entity' might be clobbered
by `longjmp' or `vfork'
Wie man leicht erkennen kann, ist sie vollkommen unsinning. Das die
erste Zeile ursprünglich hinter dem trace stand, der Wert von entity
aber davor schon benutzt wurde, ergab hingegen keine Warnung.
> Es ist ein Problem der Sprache, wenn es weitgehend als guter bis
> brauchbarer Stil gilt, sie so zu benutzen und es faktisch unmoeglich
> ist, das anders zu tun. IIRC warst Du ein kein Verfechter der Idee,
> Konstanten als erste im Vergleich zu nennen, um z.B. Dinge wie
>
> |if (options == (__WCLONE|__WALL) && (current->uid = 0))
>
> zu vermeiden, oder?
Ich bin kein Anhänger des Gedankens, man solle 'hat Variable x Wert y'
als 'ist y gleich dem Wert von Variablen x' ausdrücken, denn das
erscheint mir unlogisch. Man kann auch von jemand mit einem
mathematischen Hintergrund genügend geistige Flexibilität erwarten,
daß er/sie imstande ist, zu lernen, daß identisch aussehende Symbole
in unterschiedlichen Sprachen unterschiedliche Bedeutungen haben
können. Falls es nicht mal dafür langt, soll der Mensch sich bitte auf
das Gebiet beschränken, auf er lernwillig/ -fähig ist, und von allem
anderen die Finger lassen. Es ist kein Defekt per se, wenn es Dinge
gibt, die sich von 'Mathematik' unterscheiden.
Außerdem ist das aus einer backdoor, die jemand in der CVS-Kopie des
Linux-kernels untergebracht hatte, insofern: 'works as intended'.
Vinzent 'Gadget' Hoefler
>Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> writes:
>> Rainer Weikusat wrote:
>>
>>>Von mir persönlich weiß ich einigermaßen, welche Fehler ich
>>>typischerweise mache,
>>
>> Du machst primaer genau einen Fehler und das ist der, von Dir auf alle
>> anderen zu schliessen.
>
>Ich widerspreche einer Allgemeinaussage auf der Basis eines
>Gegenbeispiels.
Nein. Es geht hier nicht um mathematische Beweise der Art "fuer alle A
gilt ...", sondern um statistische der Art "fuer viele A gilt ...".
Ein Gegenbeispiel beweist da exakt gar nichts.
>>>und das sind für 8568 Zeilen C genau zwei 'C-typischer Fehler', der
>>>sehr leicht zu finden war, denn der betroffene Programmteil hat
>>>schlicht etwas vollkommen anderes getan, als das, was er sollte
>>>(Argumente vertauscht, was aufgrund von implicit conversions durch
>>>den Compiler ging
>>
>> Hmm. Ich erinnere mich an gewisse Diskussionen, wo Du Leute, denen so
>> was passierte, mehr oder weniger als Idioten abgestempelt hast.
>
>Eher Leute, die sowas für ein schwerwiegendes Problem an sich
>halten. Das war es nämlich nicht. Es war eher ein schwerwiegendes
>Problem, eine Möglichkeit zu bekommen, den fraglichen Code zu testen
>und ist es partiell immer noch.
Testen ist teurer als ein zusaetzlicher Compilierversuch, weil der
Compiler Dich auf den Fehler aufmerksam gemacht hat. Das ist der ganze
"Trick" daran: Fehler so frueh wie moeglich zu erkennen. Und manchmal
findet man auch solche Fehler naemlich nicht durch Testen. Zumindest
nicht schnell.
Ich habe hier naemlich auch das Problem, selten gewisse Dinge zu der
Zeit Dinge testen zu koennen, zu der ich testen moechte. Und fuer
einige Dinge wiederum ist der Testaufwand einfach so hoch, dass er im
Tage- bis Wochenbereich liegt. Spaetestens dann kommen simple Fehler
ziemlich teuer. Also versuche ich, sie von vornherein zu vermeiden.
>Vielleicht etwas präziser formuliert: Ein C-Compiler fügt einem
>Programm mangels Laufzeitumgebung sehr wenig Code hinzu, den er selber
>erzeugt hat.
Ist bei Ada nicht so sehr anders. Das, was der Compiler gelegentlich
an Runtimechecks einfuegt ist fuer meine Begriffe recht simpel
erkennbar. Notfalls kompiliert man ohne diese Checks. Gut, beim
Threading wird es ein komplexer, aber so was will man ohnehin nicht
wirklich im Disassemblat debuggen.
>>>Dafür bietet ein C-Compiler sehr wenig Hilfestellung und weil ja
>>>niemand jemals an irgendetwas schuld ist, ist die Sprache also
>>>fehlerträchtig und nicht etwa die Vorgehensweise.
>>
>> Genau das ist das Problem an C.
>
>Zunächst ist das bloß eine Eigenschaft von C.
Ich korrigiere: "Eine problematische Eigenschaft.". Zufrieden?
>Das ist auf langsamen
>Rechnern mit spartanischer Hauptspeicherausstattung entworfen worden
Was nicht zwingend ein Argument gegen Checks ist, die bereits zur
Compilierzeit passieren koennen.
>> Der Nettoeffekt ist aber, dass ausreichend maechtige restriktive
>> Sprachen Dir am Ende mehr Freiheiten lassen. Und vor allem, man
>> lernt etwas Sinnvolles dabei.
>
>Sinnvoll nach Maßgabe wessen?
Sinnvoll in Hinsicht darauf, Software zu schreiben, die man auch drei
oder fuenf Jahre spaeter noch versteht und ausreichend leicht an
veraenderte Anforderungen angepasst werden kann. Z.B. ohne dass ich
mir darueber Gedanken machen muss, dass die Erweiterung des
Wertebereichs irgendeines Parameter zu einem unentdeckten
Werteueberlauf an anderer Stelle fuehrt, die unzulaessigerweise von
einem anderen Wertebereich ausgegangen ist.
>brotlose Kunst und mE höchstens als Rentnervergnügen zu empfehlen. Es
>stört ja schließlich niemanden, falls ein Computer nicht tut, was er
>soll, solange die Prospekte schön bunt sind.
*Mich* stoert das. Das reicht mir als Argument.
>>>Diesem Problem kann man mit Primitivsprachen wie Ada beikommen,
>>
>> "Primitiv"sprache ist wohl etwas danebengegriffen.
>
>* 5.2:: Assignment Statements
>* 5.3:: If Statements
>* 5.4:: Case Statements
>* 5.5:: Loop Statements
>* 5.6:: Block Statements
>* 5.7:: Exit Statements
>* 5.8:: Goto Statements
>
>Das ist der Kern von 'Ada -- The Language' und besonders viel ist das
>nicht.
Das ist sogar eine ganze Menge. Im uebrigen sollte man, wenn man
schon, wie Du, den Sprachkern etwas eigenwillig umdefiniert,
wenigstens Sections 9 und 11 nicht gerade unterschlagen. Den Rest kann
man mit gutem Willen mehr oder weniger unter Software-Design abhaken,
wobei das, wenn man es richtig nutzt, auch verdammt hilfreich sein
kann. Vor allem dann, wenn es um groessere Systeme geht.
>Sogar C kennt abweisende und nicht abweisende Schleifen
Dafuer kennt es wiederum keine for-Schleifen mit schreibgeschuetztem
Index, so what? Ansonsten argumentiere ich dagegen, dass das einfache
Adasche loop-Statement flexibel genug ist, um den ganzen Rest mit
einem (genau genommen gibt es ja zwei) Konstrukt zu erschlagen. Ich
halte C jedenfalls fuer primitiver.
>> Aber lassen wir das. Ich kenne Deine Aversion gegen Sprachen, die
>> moderne Software-Design-Konzepte auch praktisch umsetzen.
>
>Das ist eher eine Aversion gegen Sprachen, in denen man mit viele
>reservierte Worte braucht, um vergleichsweise wenig auszudrücken.
C99 hat ziemlich exakt 37 "reserved identifiers", wenn ich das richtig
sehe. Ada95 hat 69, von denen 6 (IIRC) mit der Einfuehrung von OOP und
einem etwas verbesserten Taskingmodell hinzukamen.
Davon abgesehen, sind einige dieser Keywords teilweise "nur"
Operatoren (abs, and, xor, ...) bzw. Begrenzer a la "{" oder auch
etwas verbosere Varianten von etwas, was sich in C nur via
Sonderzeichen ausdruecken laesst (access, array), sind.
Dazu kommen noch ein paar hinzu fuer Konzepte, die C gar nicht erst
kennt (Exceptions z.B.). Insofern wuerde ich eine Sprache nicht
unbedingt an der Anzahl ihrer "reservierten Worte" messen wollen.
Aber bitte, wenn man das nun alles wegrechnet, bleiben selbst fuer die
dann moeglicherweise reduzierte Ausdrucksstaerke der Sprache
ueberraschen wenige Keywords uebrig. Zumal einige dieser ja zu
Sections gehoeren, die Du zu Deiner Ada-Kern-Version als gar nicht
zugehoerig betrachtest, also solltest Du sie fairerweise dann auch als
nicht existent betrachten.
>> Desweiteren tendiere ich eher dazu, dass jemand, der das behauptet,
>> die Sprache nicht wirklich verstanden hat. Meine Erfahrung ist
>> naemlich die, dass in 98% der Faelle der Compiler vollkommen recht
>> hat, wenn er mich anmeckert.
>
>
>[...]
> entity = ops_get_own_entity(session); \
[...]
>
>Das bewirkt folgende Warnung:
>
>./src/ops_generic.c:124: warning: variable `entity' might be clobbered
>by `longjmp' or `vfork'
Du willst mein Argument jetzt nicht ernsthaft mittels eines
zweifelhaften C-Makros widerlegen, oder?
Eine Meldung wie "will raise Constraint_Error at runtime" duerfte in
den meisten Faellen tatsaechlich darauf hinweisen, dass man gerade
etwas falsch gemacht hat.
>Wie man leicht erkennen kann, ist sie vollkommen unsinning. Das die
>erste Zeile ursprünglich hinter dem trace stand, der Wert von entity
>aber davor schon benutzt wurde, ergab hingegen keine Warnung.
Tja. Kuenstlerpech. Kommt vor. Kaum ein Compiler garantiert Dir eine
vollstaendige oder gar korrekte Datenflussanalyse.
>> Es ist ein Problem der Sprache, wenn es weitgehend als guter bis
>> brauchbarer Stil gilt, sie so zu benutzen und es faktisch unmoeglich
>> ist, das anders zu tun. IIRC warst Du ein kein Verfechter der Idee,
>> Konstanten als erste im Vergleich zu nennen, um z.B. Dinge wie
>>
>> |if (options == (__WCLONE|__WALL) && (current->uid = 0))
>>
>> zu vermeiden, oder?
>
>Ich bin kein Anhänger des Gedankens, man solle 'hat Variable x Wert y'
>als 'ist y gleich dem Wert von Variablen x' ausdrücken, denn das
>erscheint mir unlogisch.
Mathematisch ist es erst einmal dasselbe. Aber es ist ein Workaround,
richtig. Die inhaerente "Unlogik" eines solchen Ausdrucks ist aber
zumindest durch die Verbesserung "man kann '=' nicht mehr aus Versehen
mit '==' verwechseln" durchaus wettgemacht.
Und am Ende gibt es eine ganze Menge Dinge an C, die *ich* aus meiner
Sicht unlogisch finde (die grundsaetzliche short-circuit-Evaluation
z.B.).
>Man kann auch von jemand mit einem
>mathematischen Hintergrund genügend geistige Flexibilität erwarten,
>daß er/sie imstande ist, zu lernen, daß identisch aussehende Symbole
>in unterschiedlichen Sprachen unterschiedliche Bedeutungen haben
>können.
Darum geht es nicht primaer. Es geht darum, dass z.B. schon einfache
Tippfehler, wie sie nun mal immer wieder vorkommen, unter Umstaenden
desastroese Resultate haben *koennen*. Und da ziehe ich mir eine
Sprache vor, bei der die meisten, ueblicherweise auftretenden
Tippfehler nicht in etwas Kompilierfaehigem resultieren.
>Außerdem ist das aus einer backdoor, die jemand in der CVS-Kopie des
>Linux-kernels untergebracht hatte, insofern: 'works as intended'.
Ja. Eben. Und genau deswegen finde ich das auch ein wunderbares
Beispiel fuer die "fehlertraechtige" Semantik von C bzw. auch C++.
Vinzent.
Bodo Thiesen
>P.S. Das C++ Beispiel läßt sich auf folgendes eindampfen.
>
>#include <iostream>
>
>int main () {
> std::cout << "Hello World!" << std::endl;
> return 0;
>}
Wo ist das Objektorientiert? Wo ist die Klasse, wo sind die Daten, wo
sind die Methoden, die darauf operieren. (Ich kann es auch anders
ausdrücken: Man kann kein objektorientiertes Hello World Programm
sinnvoll schreiben, was dann gleich wieder beweist, daß es Probleme
gibt, die sich nicht sinnvoll objektorientiert lösen lassen.) Aber
sollte es Dir entgangen sein: Ich habe ausdrücklich darauf hingewiesen,
daß es auch kürzer geht, und ich habe auch ausdrücklich geschrieben,
warum ich es so kompliziert gemacht habe. Wenn ich eine Sprache mit
einer anderen vergleichen will, und ich sehe in der einen
»printf("Hello World\n");« und in der anderen
»cout << "Hello World!" << endl;"«, dann frage ich mich als allererstes,
warum ich dahin wechseln soll. Meine Version versuchte wenigstens zu
zeigen, worum es geht. (Obwohl das bei einem HelloWorld Programm eh
nicht wirklich einfach ist...)
Bodo Thiesen
>Die Streams, wie hier cout, sind doch sehr C++-mäßig. Unter der Haube
>geht da schon einiges ab.
Genau. Vor allem hat der Anfänger auch so viel davon, weil man das ja
auf dem ersten Blick alles sieht ...
Bodo Thiesen
>Bodo Thiesen <bot...@gmx.de> wrote:
>
>Wieso willst beim C++ Beispiel mit Gewalt ein Objekt erfinden aber bei
>der C Version nicht mit Gewalt eine Funktion?
Ja, das hätte ich eigentlich machen müssen. Für den Rest Deines Artikles
siehe Meine Antwort auf Tibors Artikel.
Rainer Weikusat
[...]
> Darum geht es nicht primaer. Es geht darum, dass z.B. schon einfache
> Tippfehler, wie sie nun mal immer wieder vorkommen, unter Umstaenden
> desastroese Resultate haben *koennen*. Und da ziehe ich mir eine
> Sprache vor, bei der die meisten, ueblicherweise auftretenden
> Tippfehler nicht in etwas Kompilierfaehigem resultieren.
Das ist kein 'üblicherweise auftretender Tippfehler', aber
Diskussionen über Glaubenssätze sind immer etwas zweckfrei.
Claus Reibenstein
> pa...@stud.uni-frankfurt.de (Tibor Pausz) wrote:
>
>>#include <iostream>
>>
>>int main () {
>> std::cout << "Hello World!" << std::endl;
>> return 0;
>>}
>
> Wo ist das Objektorientiert?
War _irgendwo_ in diesem Thread gefordert, "Hello World"
objektorientiert zu lösen? Habe ich etwas übersehen?
> Wo ist die Klasse,
std
> wo sind die Daten,
"Hello World!"
> wo sind die Methoden, die darauf operieren.
cout, endl, operator<<.
> daß es Probleme
> gibt, die sich nicht sinnvoll objektorientiert lösen lassen
Ist eine altbekannte Tatsache.
> Wenn ich eine Sprache mit
> einer anderen vergleichen will, und ich sehe in der einen
> »printf("Hello World\n");« und in der anderen
> »cout << "Hello World!" << endl;"«, dann frage ich mich als allererstes,
> warum ich dahin wechseln soll.
Mir scheint, Du hast die ursprüngliche Frage aus den Augen verloren.
Es ging um die Frage, welche Programmiersprache für einen Anfänger
geeignet ist. Es ging _nicht_ darum zu klären, welche Sprache für einen
professionellen Entwickler am besten geeignet ist. Ein guter Entwickler
sollte sowieso mehrere Sprachen beherrschen. Erst recht ging es nicht
darum, welche Methode der Programmierung (strukturiert, objektorientiert
etc.) die bessere ist. Auch da schadet es nicht, mehrere zu kennen.
> Meine Version versuchte wenigstens zu
> zeigen, worum es geht.
Worum es _Dir_ geht, aber nicht, worum es dem Ursprungsposter geht.
Gruß. Claus
René Möhring
> René Möhring <myspa...@gmx.de> wrote:
>
>>Die Streams, wie hier cout, sind doch sehr C++-mäßig. Unter der Haube
>>geht da schon einiges ab.
>
> Genau. Vor allem hat der Anfänger auch so viel davon, weil man das ja
> auf dem ersten Blick alles sieht ...
Das soll er ja gar nicht sehen am Anfang. Er sieht ja auch bei printf
nicht wie das intern funktioniert. Trotzdem ist das Stream-Konzept für
C++ wichtig und wird jedem der sich ernsthaft damit beschäftigt noch des
öfteren über den Weg laufen.
Vinzent 'Gadget' Hoefler
>Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> writes:
>
>[...]
>
>> Darum geht es nicht primaer. Es geht darum, dass z.B. schon einfache
>> Tippfehler, wie sie nun mal immer wieder vorkommen, unter Umstaenden
>> desastroese Resultate haben *koennen*. Und da ziehe ich mir eine
>> Sprache vor, bei der die meisten, ueblicherweise auftretenden
>> Tippfehler nicht in etwas Kompilierfaehigem resultieren.
>
>Das ist kein 'üblicherweise auftretender Tippfehler',
[ ] Du weisst, was "z.B." in diesem Zusammenhang bedeutete.
>aber Diskussionen über Glaubenssätze sind immer etwas zweckfrei.
ACK. Allerdings laesst sich obiger Glaubensgrundsatz auch beschraenkt
mit Zahlen belegen. Ich weiss, dass Du das nicht magst, aber die
Empfehlungen der MISRA sind beispielsweise auch nicht aus heisser Luft
entstanden.
Und noch was nettes zum Abschluss:
<URL:http://embedded.com/showArticle.jhtml?articleID=15306089>:
|C sucks. Sure it's fun and efficient. Debugging is much more of a kick
|than taming an angry syntax checker that insists on correctness. But
|it's time for the entire firmware community to either embrace a
|restrictive dialect of the language, or to adopt an Ada-like lingo
|that implicitly leads to correct code.
Ja, Jack ist "Consultant". Also duerfte er in Deinen Augen wohl auch
schon verloren haben. Aber es gibt Dinge, die mir wirklich egal sind.
Besonders, wenn ich gerade eine Statemachine in Assembler schreiben
darf, die aus zeitoptimalen Gruenden parallel zu einem Stueck bereits
existierenden Code laufen soll, der vorwiegend aus Verzoegerungen
besteht. Das ganze ist natuerlich an dieser Stelle garantiertes
Single-Tasking (schade, dass die Hardwaredesigner irgendwann mal den
Timer wegoptimiert haben, weil meine Vorgaenger keine Anwendung fuer
ihn hatten, sonst haette ich das Tasking ja wenigstens simulieren
koennen. Tja, man spart, wo man kann und wenn es halt 20 Franken fuer
einen simplen i8254 sind. Andererseits - wer kommt schon auf die Idee,
dass es einen Spinner wie mich geben koennte, der teure Rechenleistung
auf einer 8 MHz-CPU in einem Scheduler verschwenden will, das *kann*
ja weder einfacher noch rechenleistungsmaessig tatsaechlich
effizienter sein), was wohl jetzt mindestens die Zeit bis zum Mittag
verbraten wird und andererseits in popeligen acht Zeilen Ada-Code
schnell und garantiert fehlerfrei erledigt waere. Naja, die acht
Zeilen kann ich mir ja fuer naechstes Jahr aufheben.
Vinzent.
Rainer Weikusat
> |C sucks. Sure it's fun and efficient. Debugging is much more of a kick
> |than taming an angry syntax checker that insists on correctness. But
> |it's time for the entire firmware community to either embrace a
> |restrictive dialect of the language, or to adopt an Ada-like lingo
> |that implicitly leads to correct code.
>
> Ja, Jack ist "Consultant". Also duerfte er in Deinen Augen wohl auch
> schon verloren haben.
s/Consultant/Schwätzer/. Außer das sind Synonyme, was ja möglich wäre.
Meint er jetzt, daß er C benutzt, obwohl er das nicht will, falls ja,
welches schizoides Phänomen ist das genau (Neugier!), und falls nein,
was ist der Inhalt von diesem rant? Ich meine, ich schreibe nicht 'ach
wie schön ist es, in C zu programmieren', ich muß es bloß
zufällig. Wesentlich Unterschiede zu anderen Sprachen kann ich keine
erkennen und die meisten Fehler sind logische Fehler. In der Doku
steht a, real tut es b, außer manchmal, dann tritt Situation c auf
etc. Oder man verbringt mal einen Nachmittag damit, die
geheimnisvollen Interna der RH-eigenen SysV-Init-Bastardisierung zu
erkunden. Eine glorreiche Zeitverschwendung. Was soll ich jetzt mit
Leuten anfangen, die massive Probleme mit Trivialitäten im eigenen Code
haben? Erst mal Ada-Bindings für eine C-Bibliothek voller Fehler
schreiben, weil die Welt davon besser wird und ich teuren
Arbeitskräften dadurch das Leben erleichtern könnte?
What for?
Tibor Pausz
> std
std ist ein namespace, die Klasse ist cout im Namespace std. Alle C++
Bezeichner der C++ Norm sind im Namespace std definiert.
Tibor Pausz
> Da war meine Fassung in <bphrrn$1ofvt5$4...@ID-94739.news.uni-berlin.de>
> aber noch etwas kürzer ;-)
Aber nicht C++ Norm konform.
Vinzent 'Gadget' Hoefler
>Meint er jetzt, daß er C benutzt, obwohl er das nicht will, falls ja,
>welches schizoides Phänomen ist das genau (Neugier!),
Ich schaetze, er hat das gleiche Problem wie Du.
>was ist der Inhalt von diesem rant? Ich meine, ich schreibe nicht 'ach
>wie schön ist es, in C zu programmieren', ich muß es bloß
>zufällig.
Nun gut, vielleicht etwas weniger zufaellig.
Aber wir schweifen ab. Die urspruengliche Aussage war, dass C++ (und
damit wohl auch C) fehlertraechtig sei. Dies wird tagtaeglich neu
bewiesen.
Dass es Alternativen gaebe (seien die jetzt in irgendwelchen Subsets a
la MISRA-C, SafeC++ oder in Ada, Eiffel, ... zu suchen), aendert daran
nichts. Auch Du nicht.
Vinzent.
Rainer Weikusat
> damit wohl auch C) fehlertraechtig sei. Dies wird tagtaeglich neu
> bewiesen.
Bleistifte sind gefährlich, Begründung: Wenn man sich einen ins Auge
stößt, ist man hinterher meistens tot. Ist doch schön, wenn man sich
seine Arbeitsbedingungen aussuchen kann.
Vinzent 'Gadget' Hoefler
>Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> writes:
>> Aber wir schweifen ab. Die urspruengliche Aussage war, dass C++ (und
>> damit wohl auch C) fehlertraechtig sei. Dies wird tagtaeglich neu
>> bewiesen.
>
>Bleistifte sind gefährlich, Begründung: Wenn man sich einen ins Auge
>stößt, ist man hinterher meistens tot.
Richtig. Allerdings sind Bleistifte nicht primaer dazu entwickelt
worden, sie so zu nutzen, dass man sie sich leicht ins Auge stechen
kann. Das ist schlicht Fehlnutzung. Aber darauf wolltest Du doch
hinaus, oder?
>Ist doch schön, wenn man sich
>seine Arbeitsbedingungen aussuchen kann.
So einfach ist das leider auch nicht. Ich befuerchte, dass ich
demnaechst mit ziemlich viel Java gequaelt werden werde. Es gibt ja
eine RTSJ, damit muss es ja logischerweise fuer Embedded und
RT-Systeme geeignet sein, oder? - Eben.
Vinzent.
Tibor Pausz
Crosspost und Folloup nach dcl.iso-c++, da hier OT.
> Wo ist das Objektorientiert? Wo ist die Klasse, wo sind die Daten, wo
> sind die Methoden, die darauf operieren.
Klasse: std::cout
Operator:
std::ostream& operator<< (std::ostream&, const char*)
Daten: "Hello World!"
Das Problem wird nicht mit Polymorphie sondern mit Überladen des
Operators "operator<<" gelöst. Da es sich hier um einen eingebauten
Typen "const char*" handelt, muß man den passenden Operator nicht selbst
definieren.
> Meine Version versuchte wenigstens zu zeigen, worum es geht.
Den Versuch darfst Du als gescheitert ansehen. Du blähst Dein Beispiel
auf, wobei nicht zu erkennen ist, was für einem Zweck es dienen soll.
Polymorphie benutzt du nicht und Überladung auch nicht. Der Sinn dieses
Codebeispiels ist nicht zu erkennen. Wozu dieser Overhead?
Es nährt bloß den Verdacht, daß das C Beispiel schön schlank erscheinen
soll und die C++ Version unnötig aufgebläht ist.
Wenn man eine beliebige Klasse myclass hast, willst man möglichst nur
einmal die Ausgabe für viele Ausgabeströme definieren.
#include <iostream>
#include <fstream>
// Rumpf einer beliebigen Klasse myclass,
// die man beliebig erweitern kann
// damit man sieht wie operator<< funktioniert
// ist ein member a_member vorhanden
class myclass {
friend std::ostream& operator<< (std::ostream& out, const myclass& my);
public:
myclass (int in) : a_member (in) {};
private:
int a_member;
};
// Dieser Operator definiert ein Ausgabeformat für alle ostreams,
// egal ob es sich um std::cout, std::ofstream oder was auch
// immer abgeleitet von der Basisklasse handelt.
std::ostream& operator<< (std::ostream& out, const myclass& my) {
out << my.a_member;
return out;
};
int main () {
myclass a (10);
std::cout << a << std::endl;
std::ofstream file ("myfile");
file << a << std::endl;
return 0;
}
--
de.comp.lang.iso-c++ - Moderation: mailto:voyag...@bud.prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+...@bud.prima.de
Kai Ruhnau
> #include <stdlib.h>
> #incldue <time.h>
>
> /*
> * Die Klasse für ein Datenfeld:
> */
>
> class Feld {
> /*
> * Die folgenden Elemente dürfen nur von der Klasse aus selber
> * benutzt werden
> */
> private:
> /*
> * Wie in der C version: Der Zeiger auf das Datenfeld.
> */
> int * Datenfeld;
>
> /*
> * Da die Klasse die Größe des Feldes übergeben bekommt, muß sie
> * sich diese nun auch merken. Auf diese Weise ist es möglich, mit
> * dieser Klasse mehrere Datenfelder unterschiedlicher Größe
> * anzulegen.
> */
> int size;
>
> /*
> * Die folgenden Elemente dürfen von überall aus aufgerufen werden.
> */
> public:
> Feld(int num);
> void Ausgeben();
> void RandomInit(void);
> void Sortieren();
> };
>
> /*
> * Der sogenannte Konstuktor. Er wird immer dann aufgerufen, wenn ein
> * neues Feld erzeugt wird. In diesem Beispiel also an der Stelle, wo
> * in der Funktion main »Feld MeinDatenFeld(NUM);« steht.
> */
> Feld::Feld(int size) {
> /*
> * Genauso wie in der C Version müssen wir hier das Datenfeld
> * erzeugen. Statt malloc wird hier das OOP-new benutzt. Macht
> * hier aber letztlich das gleiche (Speicher belegen).
> */
>
> Datenfeld = new int[size=num];
>
> /* Prüfen, ob wir den Spicherbereich bekommen haben */
>
> if (!Datenfeld) {
> perror("new");
> exit(2); /* throw wäre hier eigentlich besser */
> }
> }
>
> /* Die Ausgabefunktion: */
>
> void Feld::Ausgeben(void) {
> int i;
>
> for (i=0;i<size;++i) {
> printf("%i ",Datenfeld[i]);
> }
>
> putchar('\n');
> }
>
> /* Die Funktion, die das Datenfeld mit Zufallsdaten füllt. */
>
> void Feld::RandomInit(void) {
> for (i=0;i<size;++i) {
> Datenfeld[i] = rand();
> }
> }
>
> /* Die Sortierfunktion: */
>
> void Feld::Sortieren(void) {
> int i,j,tmp;
>
> for (j=0;j<size-1;++j) {
> for (i=j+1;i<size;++i) {
> if (Datenfeld[i]>Datenfeld[j]) {
> tmp=Datenfeld[i];
> Datenfeld[i]=Datenfeld[j];
> Datenfeld[j]=tmp;
> }
> }
> }
> }
>
> /* Auch hier: Der Konstanten 20 einen Namen verpassen */
>
> #define NUM 20
>
> /* Hier fängt das Hauptprogramm an: */
>
> int main(void) {
> /*
> * Hier wird das Datenfeld erzeugt. Beachte bitte, daß - so
> * unscheinbar diese Zeile auch aussehen mag, hier ein ganzer
> * Rattenschwanz an Funktionen aufgerufen werden könnten.
> */
>
> Feld MeinDatenFeld(NUM);
>
> /* Initialisierung des Zufallsgenerators mit der Systemzeit. */
>
> srand(time(NULL));
>
> /* Initialisierung mit Zufallswerten. */
>
> MeinDatenFeld.RandomInit();
>
> /* Und ausgeben, damit wir nachher vergleichen können. */
>
> MeinDatenFeld.Ausgeben();
>
> /* Jetzt wird sortiert: */
>
> MeinDatenFeld.Sortieren();
>
> /* Und zur Kontrolle nochmal ausgeben. */
>
> MeinDatenFeld.Ausgeben();
>
> exit(0);
> }
Hmm, ich reite der Vollständigkeit mal darauf rum und machs zu C++:
#include <iostream> //cout
#include <iterator> //ostream_iterator
#include <algorithm> //generate
#include <vector> //vector
#include <cstdlib> //rand
using namespace std; //Für so ein kleines Programm ok
int main()
{
//"Feld" mit 10 Elementen
vector<int> MeinDatenFeld(10);
//Mit Zufallswerten füllen
generate(MeinDatenFeld.begin(), MeinDatenFeld.end(),rand);
//Mit Leerzeichen getrennt ausgeben
copy(MeinDatenFeld.begin(), MeinDatenFeld.end(),
ostream_iterator<int>(cout," "));
//Zeilenumbruch
cout<<endl;
//Sortieren
sort(MeinDatenFeld.begin(), MeinDatenFeld.end());
//Wieder ausgeben
copy(MeinDatenFeld.begin(), MeinDatenFeld.end(),
ostream_iterator<int>(cout," "));
cout<<endl;
//Fertig
return 0;
}
Schlägt meiner Meinung nach in der Expressivität und Kürze die anderen
Varianten locker :)
X'Post und F'up nach de.comp.lang.iso-c++ (wegen OT)
Rainer Weikusat
>>Bleistifte sind gefährlich, Begründung: Wenn man sich einen ins Auge
>>stößt, ist man hinterher meistens tot.
>
> Richtig. Allerdings sind Bleistifte nicht primaer dazu entwickelt
> worden, sie so zu nutzen, dass man sie sich leicht ins Auge stechen
> kann. Das ist schlicht Fehlnutzung. Aber darauf wolltest Du doch
> hinaus, oder?
Ich verstehe den Grund für das Gejammer nicht. Wenn C gefordert wird,
programmiert man eben in C und C ist eben C. Laut
Sicherheitsvorschriften zur Arbeit auf Baustellen darf man nicht auf
ungesicherte Leitern steigen. Man findet sich also damit ab, daß man
im Falle eines Unfalls von niemandem Geld bekommt und tut es trotzdem,
weil es verlangt wird. Ich mache mir Gedanken darüber, ob das hier:
if (sam_update && lea_update) {
if (logs_processed) {
no_input_counter = 0;
fw_disconnect = 0;
sentry_status = SENTRY_STATUS_OK;
} else {
if (no_input_counter == INPUT_DEATH || fw_disconnect)
sentry_status = SENTRY_STATUS_INPUT_PROBLEM;
else ++no_input_counter;
}
if (lea_alive && sam_alive) silence_counter = 0;
else {
if (silence_counter == SENTRY_DEATH)
sentry_status = SENTRY_STATUS_SENTRY_PROBLEM;
else ++silence_counter;
}
} else sentry_status = SENTRY_STATUS_UPDATE_ERROR;
immer noch unrichtige Zustandsübergänge enthält und dafür geht
wirklich Zeit drauf. Nicht für die Suche nach versehentlichen
Zuweisungen.
>>Ist doch schön, wenn man sich
>>seine Arbeitsbedingungen aussuchen kann.
>
> So einfach ist das leider auch nicht. Ich befuerchte, dass ich
> demnaechst mit ziemlich viel Java gequaelt werden werde. Es gibt ja
> eine RTSJ, damit muss es ja logischerweise fuer Embedded und
> RT-Systeme geeignet sein, oder? - Eben.
Java ist von C-Programmierern für Leute entworfen worden, die kein C++
mögen, und die meisten 'üblichen' Kritikpunkte wurden beim Design
berücksichtigt. Peyotic justice :->. Es gibt eine ähnliche
Tripelbeziehung zwischen VMess, Unix und NT.
Bodo Thiesen
>Crosspost und Folloup nach dcl.iso-c++, da hier OT.
Nö. Es geht nicht primär um C++ (allerdings auch nicht um C).
>Es nährt bloß den Verdacht, daß das C Beispiel schön schlank erscheinen
>soll und die C++ Version unnötig aufgebläht ist.
Ich habe jetzt keine Lust, die Antwort auf eine ähnliche Behauptung zu
suchen - das überlasse ich Dir. Aber das war nicht meine Absicht, und
wenn Du Dir meinen Artikel genau durchgelesen hättest, hättest Du das
auch erkannt.
Bodo Thiesen
Klar, trotzdem: Thema verfehlt. Spätestens, wenn man ein anderes Problem
stellt, das nicht vollständig von der STL gelöst wird, wird man etwa so
enden, wie hier. Außerdem zeigt das ganze garnicht mehr, worum es bei C++
geht. (Probleme auf Libraries auszulagern kann ich auch in C, dafür
brauche ich C++ wirklich nicht.)
>X'Post und F'up nach de.comp.lang.iso-c++ (wegen OT)
Abgelehnt. Abgesehen davon ist eine Diskussion über mehrere Sprachen in
de.comp.lang.iso-c++ genauso OT wie in de.comp.lang.c
Außerdem ist es ein wenig blöd, jetzt am Ende der Diskussion noch ein
fup2 zu setzen - sonst würde ich nach .misc fuppen - da wäre das
vielleicht tatsächlich besser aufgehoben.
Bodo Thiesen
>Bodo Thiesen <bot...@gmx.de> wrote:
>
>> Wo ist das Objektorientiert?
>
>Gar nicht, wieso sollte es?
>Wo ist das C-Beispiel funktionsorientiert? Eben.
Auch Du darfst das mein anderen Artikel suchen, den ich in der Antwort auf
Tibors Artikel ansprach.
>> Wo ist die Klasse, wo sind die Daten, wo
>> sind die Methoden, die darauf operieren.
>
> Kann es sein das du ein "klein wenig" missverstanden hast was ein
> HelloWorld Programm ist, und was man da sinnvollerweise alles
> reintun sollte?
Ich wollte keine richtige Anwendung programmieren, nur um die
Unterschiede aufzuzeigen. Wenn Du das gerne tun möchtest - bitte. Ich
werde Dich nicht davon abhalten, ganz im Gegenteil. Aber solange Du es
nicht besser machen willst, kritisiere bitte nicht das, was ich
schlecht gemacht habe.
>Insbesondere dann nicht wenn man bei einen Beispiel versucht möglichst
>viel Ballast mit reinzunehmen nur um viele Sprachfeatures zu zeigen
>(C++) während man im anderen Beispiel nur ein normales HelloWorld
>damit vergleicht, das logischerweise fast keine Sprachfeatures von C
>enthält.
>
>Oder willst hier nur zeigen: Seht in C++ kann man alles so herrlich
>unnötig aufblähen während C eine schöne schlanke Lösung ermöglicht,
>wechselt doch alle zu C?
Wie gesagt: Such den Artikel, und dann wirst Du die Antwort auf diese
Frage kennen.
Bodo Thiesen
Genau. Hau' drauf. Erschlag' den Anfänger mit allen kleinigkeiten. Nur zu.
Weiter! Jetzt nur nicht nachgeben. Er blutet noch nicht schön genug. Drauf.
Jetzt mal im Ernst: Zuerst behauptest Du, man könne cout ruhig nehmen, weil
da "unter der Haupe [...] schon einiges ab" geht, und nun argumentierst Du
ganau entgegengesetzt. Entscheide Dich doch erstmal, was Du willst.
Bodo Thiesen
> Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> writes:
>> Rainer Weikusat wrote:
>>> Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> writes:
>
>Daran kann es eigentlich auch nicht liegen :->. Cool fand ich auch
>noch das hier:
>
> (gdb) disas
>Dump of assembler code for function write:
>0x407ae9f0 <write>: push %ebx
>0x407ae9f1 <write+1>: mov 0x10(%esp,1),%edx
>0x407ae9f5 <write+5>: mov 0xc(%esp,1),%ecx
>0x407ae9f9 <write+9>: mov 0x8(%esp,1),%ebx
>0x407ae9fd <write+13>: mov $0x4,%eax
>0x407aea02 <write+18>: int $0x80
>
>'Der syscall ohne Wiederkehr' -- ein in-kernel deadlock, daß durch
>irgendeine seltsame Interaktion von asychronous cancel und
>AF_UNIX-datagram sockets zustande kam und schon ziemlich
>prozeßbeendigungsresistent war.
[...]
>nicht. Sogar C kennt abweisende und nicht abweisende Schleifen und
>zunächst mal dienen solche Konstrukte nicht 'der Optimierung'
>(blafasel), sondern dazu, Algorithmen sinnvoll zu beschreiben und
>
> i = 0;
> while (i++ < 10) { ....; }
>
>ist auch dann eine sinnlose Formulierung, wenn der Compiler es
>automatisch zu
>
> i = 0;
> do { ...; } while (++i < 10);
>
>deformiert. Ich kann mich dumpf daran erinnern, daß 'Optimieren' mal
>'Spezialbehandlung von Sonderfällen' bedeutet hatte und nicht
>'semantisch sinnvoller Sprachgebrauch' und würde es immer noch stark
>vorziehen, einen Algorithmus als erstes mal exakt zu beschreiben und
>mich ansonsten darauf zu verlassen, daß ein ordentlicher Compiler
>(also nicht sowas wie gcc3) daraus vernünftigen Code generieren
>wird.
Du bist ein elendiglicher Stänkerer. Ich nehme mal an, mit Kernel war
der Linux Kernel gemeint. Dieser, als auch gcc sind Open Source. Wenn
Du so gut bist, wie Du behauptest, warum beteiligst Du Dich nicht an
diesen Projekten, um die Fehler oder Missfeatures endlich zu
beseitigne? Nein, statt dessen belästigst Du diese Gruppe einmal im
Monat mit Deinem Ärger über diese Produkte. Oder - wenn diese wirklich
so schlecht sind - wieso benutzt Du dann nicht was besseres? Benutze
doch einfach Windows und VC, dann hast Du keine Probleme mehr mit
in-Kernel Locks im Linux Kernel, und Du hast dann auch keine Probleme
mehr mit von gcc3 schlecht übersetzten Code.
Du hast jetzt ein beispiel benutzt, um eine allgemeingültige Aussage, die
für 98% der Fälle zutreffen soll zu wiederlegen. Irgendwie ist das für Dich
typisch.
BTW: Ist das erste Argument zu ops_session_terminated() const?
Kai Ruhnau
> Kai Ruhnau <kai.ne...@tragetaschen.dyndns.org> wrote:
>
>>Hmm, ich reite der Vollständigkeit mal darauf rum und machs zu C++:
>>
[Codesnip]
>>
>>Schlägt meiner Meinung nach in der Expressivität und Kürze die anderen
>>Varianten locker :)
>
> Klar, trotzdem: Thema verfehlt.
Naja, dein Thema war einen Vergleich zu ziehen zwischen zwei (drei)
Sprachen - jedenfalls hab ichs so verstanden :). Ich habe für eine der
Sprachen gezeigt, dass es einfacher geht. Dabei meine ich "einfacher" nicht
in dem Sinne, dass man mit wenig Sprachmitteln das Ziel erreicht [1],
sondern dass man mit wenig eigenem Code, der leicht verständlich ist (bis
zu einem gewissen Grad mit nur grober Kenntnis der STL), ein nicht gerade
ungewöhnliches Problem lösen kann.
Dass C++ - und da gehört die STL zu - nicht einfach zu lernen ist, steht
dabei zumindest für mich außer Frage.
> Spätestens, wenn man ein anderes Problem
> stellt, das nicht vollständig von der STL gelöst wird, wird man etwa so
> enden, wie hier.
Du wirst überrascht sein, wie viele Problemstellungen von der STL abgedeckt
werden (können). Und wenn nicht abgedeckt, dann immernoch in hohem Maße
unterstützt.
> Außerdem zeigt das ganze garnicht mehr, worum es bei C++
> geht. (Probleme auf Libraries auszulagern kann ich auch in C, dafür
> brauche ich C++ wirklich nicht.)
Doch, genau darum (u.a.) geht es bei C++. Eine Library, die mittels
Standard festgezurrt ist und bei jedem halbwegs aktuellen Compiler dabei
ist, gehört benutzt. Genauso, wie man prinft, fopen oder malloc in C
benutzen sollte - ja sogar muss -, gehört es in C++ zum Guten Stil [TM]
cout, fstream und vector zu benutzen [2].
Gerade die STL bietet auf einem hohen Abstraktionsgrad _die_ klassischen
Problemlösungen, mit denen man sich als Programmierer sonst bestimmt 50%
der Zeit beschäftigt: Arrays von Elementen, Verkettete Listen,
Speicherverwaltung (insbesondere RAII in dem Zusammenhang), Sortieren,
Kopieren (abstrakt, Quelle und Ziel können vieles sein), I/O Ein- und
Ausgabe, Zeichenkettenverarbeitung etc.
Gleichzeitig sorgen Templates dafür, dass diese Elemente der STL trotz
ihrer Allgemeinheit "schnell" und zu vielen Objekten/Typen kompatibel sind.
Iteratoren halten Algorithmen und die Container zusammen und entkoppeln
diese Konzepte.
Beispielsweise der Code, um die Elemente eines (beliebigen) STL-Containers
"woandershin" zu kopieren, ist modulo Kopier-Varianten nur genau einmal da
und höchst wahrscheinlich effizienter implementiert, als es ein normaler
Durchschnittsprogrammierer in üblicherweise viel zu kurzer Zeit kann (Zum
Beispiel memcopy für "einfache" [3] Datenstrukturen).
Mir persönlich fällt jetzt spontan kein (sinnvolles) C++ Programm ein, das
nicht mit Hilfe der STL gelöst, bzw. sogar wesentlich eleganter gelöst
werden kann.
Eine Standard(!)-Library für egal welche Programmiersprache ist dafür da,
benutzt zu werden.
>>X'Post und F'up nach de.comp.lang.iso-c++ (wegen OT)
>
> Abgelehnt.
Ok.
> Abgesehen davon ist eine Diskussion über mehrere Sprachen in
> de.comp.lang.iso-c++ genauso OT wie in de.comp.lang.c
>
> Außerdem ist es ein wenig blöd, jetzt am Ende der Diskussion noch ein
> fup2 zu setzen - sonst würde ich nach .misc fuppen - da wäre das
> vielleicht tatsächlich besser aufgehoben.
Du hast recht. Sie wurde hier angefangen und solange keiner meckert kann
sie hier auch bleiben.
Grüße
Kai
[1] zugegeben, die STL zu kennen ist schon eine nicht gerade kleine Aufgabe
[2] new ist ein Operator, deshalb erwähne ich ihn nicht
[3] POD - Plain old Data. Speicherbereich, der keinen Konstruktor und
Destruktor braucht und deshalb einfach so kopiert werden kann.
--
This signature is left as an exercise for the reader.
Jirka Klaue
> Mir persönlich fällt jetzt spontan kein (sinnvolles) C++ Programm ein, das
> nicht mit Hilfe der STL gelöst, bzw. sogar wesentlich eleganter gelöst
> werden kann.
Hmm? Auf einen Bildschirm malen, USB ansteuern, HD formatieren, Netzwerk, ...
Schreib doch mal schnell einen Browser. ;-)
Jirka
Kai Ruhnau
Mach das mal schnell in C ;)
Nein, im Ernst:
Das ist ein weiterer Punkt, worum es in C++ geht.
Wenn die STL Funktionalität nicht bietet (und das aus gutem Grund), geht es
meistens darum, die betriebssystemspeziefischen (meist C-) Funktionen zu
abstrahieren.
USB und Netzwerk sind abstrakt Streams. Das heißt, man muss "nur" das
Stream-Interface drumbasteln [1] und kann anschließend die ganze STL damit
benutzen.
Das "auf den Bildschirm malen" ist meist nur das zur Schau Stellen einer
eigenen Datenstruktur. Spätestens die wird am einfachsten und fast immer am
besten in STL-Containern gehalten.
Einen Browser zu machen, ist dann nur noch den Netzwerk(-html-)stream in
eine Datenstruktur umzuwandeln, die man dann auf dem Bildschirm ausgibt.
Dabei sind alle Punkte zwischen Stream und Bildschirm mit Unterstützung der
STL sinnvoll lösbar.
Dass die STL um längen nicht alle Probleme lösen kann ist doch klar.
Grüße
Kai
[1] Im groben sind es nur zwei Funktionen, die man schreiben muss: Was
passiert, wenn Zeichen im Sende- oder keine im Empfangspuffer sind.
Jirka Klaue
> Dass die STL um längen nicht alle Probleme lösen kann ist doch klar.
Sonst hätte man Java. :-)
Jirka
Tibor Pausz
> Nö. Es geht nicht primär um C++ (allerdings auch nicht um C).
Es geht um unpassend formulierte Beispiele. Das erste C++ Beispiel taugt
nichts, da es ein einfaches Problem unnötigt verkompliziert und das
zweite C++ Beispiel ist weit davon entfernt optimal zu sein. Das C
Beispiel ist näher am Optimum, warum nutzt Du nicht qsort? Ok, du willst
den Algorithmus näher bringen.
Trivialbeispiele sind meist nicht dafür geeignet OO Programmierung
sinnvoll zu erläutern, da dann der Overhead immer viel größer ist als
der Nutzen. Übrigens ist das C++ Beispiel keineswegs OO, member
functions machen noch keine OO Problemlösung.
Dein C/C++ Code hat ein und denselben Bug. Für Schleiferzähler über
Felder sollte man immer size_t nehmen und nicht int. Auf 64Bit Systemen
ist size_t üblicherweise 64Bit unsigned int und int oftmals nur 32Bit.
Damit sind Deine Programme nicht mehr portabel.
Noch einige Anmerkungen zu Deinem "C++" Code, das ist pre ISO-C++ und
zum Teil falsch. Mittlerweile wird vieles anders gemacht. Etwa wirft der
new operator std::bad_alloc, eine Überprüfung ob new erfolgreich war ist
damit überflüssig. exit() sollte man _nie_ benutzen, da es dazu führt,
daß Destruktoren nicht aufgerufen werden; entweder main mit return
verlassen oder exception nicht fangen. Defines sollte man außer als
Include Guards _nie_ verwenden, da sie nicht typesafe sind.
> Ich habe jetzt keine Lust, die Antwort auf eine ähnliche Behauptung zu
> suchen - das überlasse ich Dir. Aber das war nicht meine Absicht, und
> wenn Du Dir meinen Artikel genau durchgelesen hättest, hättest Du das
> auch erkannt.
Dein Anliegen war es wohl zu zeigen, daß C und C++ als Anfängersprache
nicht sonderlich geeignet sind. Wenn Du die Möglichkeit hast wirf mal
einen Blick in Accelerated C++, Koenig & Moo das ist das zur Zeit wohl
beste C++ Tutorial für Anfänger. Was Deinem C++ Code mittlerweile wieder
auch auf Dich zutreffen dürfte. Oder schreibst Du immer noch K&R C?
P.S. Das zweite C++ Beispiel etwas umgeschrieben (ausschließlich ISO-C++
benutzt!). Überlege Dir eine passende Newsgroup, da Du mit
de.comp.lang.iso-c++ nicht zufrieden warst, wohin man den Thread
umziehen kann. "Langsam" wird es wirklich off topic.
#include <iostream>
#include <vector>
#include <algorithm>
#include <ctime>
const size_t fieldsize = 100;
void init_elem (int& elem) {
elem = rand ();
}
void print_elem (int& elem) {
std::cout << elem << "\n";
}
int main () {
srand (time (0));
std::vector<int> myfield (fieldsize);
for_each (myfield.begin (), myfield.end (), init_elem);
sort (myfield.begin (), myfield.end ());
for_each (myfield.begin (), myfield.end (), print_elem);
return 0;
}
Rainer Weikusat
> Du bist ein elendiglicher Stänkerer.
[...]
> Nein, statt dessen belästigst Du diese Gruppe einmal im
> Monat mit Deinem Ärger über diese Produkte.
[...]
> Irgendwie ist das für Dich typisch.
Bodo inhaltlich zusammengefaßt.