C als Lernsprache
Carsten Krueger
> C ist besonders für die Implementation von Verfahren
> durch Elementaroperationen der zugrundeliegenden
> Maschine geeignet.
Meiner Meinung nach nein, weil man z.B. nicht weiß wie groß 'int' ist.
ANSI C ist als Hochsprache nutzlos und genauso als Assemblerersatz.
Erst wenn man sich Portabilität aufgibt kann man sinnvolle Sachen
damit machen.
> Die Sprache enthält keine
> standardisierten Verfahren zum Zugriff auf
> Dateisysteme, Netze oder Datenbanken, keine regulären
> Ausdrücke, keine graphische Benutzeroberfläche und
> keine Speicherverwaltung. Einige dieser Fähigkeiten
> können zwar durch nichtstandardisierte Erweiterungen
> hinzugefügt werden, die aber nicht immer für jede
> C-Implementation verfügbar sind.
ACK
> Das ist für Anfänger
> nicht motivierend.
NACK, einem Anfänger will niemand beibringen wie man Fenster macht.
READ,WRITE,IF,CASE,FOR,REPEAT,WHILE für den Anfang, dann RECORDS,
PROCEDUREN und dann andere Konzepte OO, Funktional, ...
> Wer bereit ist, die Grundlagen des
> Programmierens zu erlernen, ohne damit schnelle Effekte
> und sofortige praktische Ergebnisse zu produzieren,
> könnte mit C beginnen, da die Programmiersprache
> vergleichsweise klein ist, was das Erlernen
> erleichtert. Trotzdem gibt es heute für Anfänger besser
> geeignete Sprachen.
Auf jeden Fall. Allerdings sollte man nicht ein Featuremonster wie
Java nehmen auch wenn das immer mehr Verbreitung findet, es ist
einfach schlecht für Anfänger. Ich bin immernoch froh mit Pascal
angefangen zu haben und Ada würde ich auch für sehr gut geeignet
halten.
> C sollte vorwiegend dann gelernt werden, wenn
> anstehende Entwicklungsaufgaben diese Sprache
> verlangen. Für allgemeine Programmieraufgaben, muß sich
> der C-Programmierer oft auf zu niedriger Ebene mit zu
> vielen Details beschäftigen, was die Entwicklungszeit
> im allgemeinen eher verlängert. Zum Erlernen des
> Programmierens ist C selbst dann nur bedingt geeignet,
> wenn dies im Rahmen einer Ausbildung erfolgen soll, die
> für einen Beruf vorbereitet, in dem später C benötigt
> wird: Denn hier führt der Umweg über eine besser
> erlernbare Sprache oft schneller dazu, daß ein
> Entwickler eine allgemein Programmierkompetenz erlangt,
> die ihn später befähigt und motiviert, die etwas
> sperrige Sprache C zu erlernen.
ACK
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
The Real OS/2 Guy
<usenet23.e...@neverbox.com> wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
> > C ist besonders für die Implementation von Verfahren
> > durch Elementaroperationen der zugrundeliegenden
> > Maschine geeignet.
>
> Meiner Meinung nach nein, weil man z.B. nicht weiß wie groß 'int' ist.
> ANSI C ist als Hochsprache nutzlos und genauso als Assemblerersatz.
> Erst wenn man sich Portabilität aufgibt kann man sinnvolle Sachen
> damit machen.
Schwachsinn. Unsinn kann man immer anrichten. Standardkonform
programmieren kann man nur wenn man
1. den Standard nicht nur flüchtig gelesen sondern auch verstanden hat
2. genau weiß was man tut und nicht halbgaren Unsinn zusammenhackt
> > Die Sprache enthält keine
> > standardisierten Verfahren zum Zugriff auf
> > Dateisysteme, Netze oder Datenbanken, keine regulären
> > Ausdrücke, keine graphische Benutzeroberfläche und
> > keine Speicherverwaltung. Einige dieser Fähigkeiten
> > können zwar durch nichtstandardisierte Erweiterungen
> > hinzugefügt werden, die aber nicht immer für jede
> > C-Implementation verfügbar sind.
>
> ACK
Blödsinn. Ein stream ist in Ein- und Ausgabe nunmal allem überlegen
was irgendwaleche ominösen Devises machen - wenn man nicht
stumpfsinnig und ohne Verstand rumhackt sondern weiß was man tut.
Mit C ist es kinderleicht über stdin Dateien lokal oder
remote/Pipes/Tastatur/com/oder sonstige Datenströme zu lesen und über
stdout zu schreiben. Man braucht nicht mal zu wissen daß Dateien
existieren.
>
> > Das ist für Anfänger
> > nicht motivierend.
>
> NACK, einem Anfänger will niemand beibringen wie man Fenster macht.
> READ,WRITE,IF,CASE,FOR,REPEAT,WHILE für den Anfang, dann RECORDS,
> PROCEDUREN und dann andere Konzepte OO, Funktional, ...
Schreibt einer der C nichtmal ansatzweise kapiert hat. Laß Dir Dein
Lehrgeld wiedergeben!
> > Wer bereit ist, die Grundlagen des
> > Programmierens zu erlernen, ohne damit schnelle Effekte
> > und sofortige praktische Ergebnisse zu produzieren,
> > könnte mit C beginnen, da die Programmiersprache
> > vergleichsweise klein ist, was das Erlernen
> > erleichtert. Trotzdem gibt es heute für Anfänger besser
> > geeignete Sprachen.
>
> Auf jeden Fall. Allerdings sollte man nicht ein Featuremonster wie
> Java nehmen auch wenn das immer mehr Verbreitung findet, es ist
> einfach schlecht für Anfänger. Ich bin immernoch froh mit Pascal
> angefangen zu haben und Ada würde ich auch für sehr gut geeignet
> halten.
Mehr Nonesens. Lerne erstmal C bevor Du anfängst irgendwelche
Kommenare darüber abzulassen.
--
Tschau/Bye
Herbert
To buy eComStation 1.1 in germany visit http://www.pc-rosenau.de
Falk Hueffner
> Mit C ist es kinderleicht über stdin Dateien lokal oder
> remote/Pipes/Tastatur/com/oder sonstige Datenströme zu lesen und
> über stdout zu schreiben.
Wie liest man eine Zeile von stdin? Dafuer braucht man in C schon
ca. 10-20 Zeilen Code, die *kein* Anfaenger beim 1. Mal korrekt wird
schreiben koennen; selbst wenn, ist dies ausgesprochen laestig und
lenkt von wichtigeren Konzepten ab. In allen anderen Sprachen, die ich
kenne, ist dies trivial. C I/O ist wirklich ohne jeden Zweifel nicht
anfaengerfreundlich.
--
Falk
Rainer Weikusat
[...]
> Denn hier führt der Umweg über eine besser
> erlernbare Sprache oft schneller dazu, daß ein
> Entwickler eine allgemein Programmierkompetenz erlangt,
> die ihn später befähigt und motiviert, die etwas
> sperrige Sprache C zu erlernen.
Inhaltlich würde ich dem zustimmen, aber pragamtisch muß ich im
widersprechen: Es gibt eine nicht kleine Gruppe von Leuten, die gar
nichts lernen wollen, außer ein gutes Bild abzugeben. Die haben es bei
'Computerprogrammierung' sehr einfach, weil es für Laien faktisch
unmöglich ist, zu erkennen, wer von den Leuten, die unverständliches
Zeug erzählen, daß deswegen tut, weil er/sie selber keine Ahnung hat,
und wer nicht. Die Blender können ihre 'Außenwirkung' immer auf
Außenwirkung trimmen, denn sie sind nicht an Sachzwänge gebunden.
Mal blöd ausgedrückt: Wer ehrlich arbeitet, bekommt dadurch nie soviel
Geld, daß er/sie eine Meisterprüfung machen könnte. Dazu sind andere
Qualitäten vonnöten, cf EM-TV.
Erich Fruehstueck
fgets(buf, sizeof buf, stdin);
ist das so schwierig?
Erich
--
New Version of EFEU released, More fun with Tk support.
Get the open source from http://efeu.cybertec.at now.
The Real OS/2 Guy
int c;
char buffer[4096]; /* sollte mehr sein als jede Konsole halten kann */
int i;
for (i = 0; (c = getc()) != EOF && c != '\n'; i++) buffer[i] = c;
oder
i = fgets(buffer, sizeof(buffer), stdin);
von wegen 10 - 20 Zeilen code! Kriegt JEDER Anfänger der wirklich an C
interessiert ist als 2. Aufgabe nach dem allseits bekannten hello
world Programm auf die Reihe. Gut, wer noch nie in seinem Leben ein
Programm geschrieben hat, tut sich wirklich schwer, aber der bricht
sich selbst mit basic einen ab.
Ein gut aufbereiteter Anfängerkurs "Programmieren in ANSI C" ist eine
Woche und enthält nur ca. 20 Unterrichts- und 20 Übungsstunden - und
dabei noch eine Einführung in das kleine Computer-1x1 (was sind
Binärzahlen, wie rechne ich binär).
Falk Hueffner
> > Wie liest man eine Zeile von stdin? Dafuer braucht man in C schon
> > ca. 10-20 Zeilen Code, die *kein* Anfaenger beim 1. Mal korrekt wird
> > schreiben koennen; selbst wenn, ist dies ausgesprochen laestig und
> > lenkt von wichtigeren Konzepten ab. In allen anderen Sprachen, die ich
> > kenne, ist dies trivial. C I/O ist wirklich ohne jeden Zweifel nicht
> > anfaengerfreundlich.
>
> fgets(buf, sizeof buf, stdin);
>
> ist das so schwierig?
Wie gross muss ich buf machen, damit es immer funktioniert?
--
Falk
Falk Hueffner
> > Wie liest man eine Zeile von stdin? Dafuer braucht man in C schon
> > ca. 10-20 Zeilen Code, die *kein* Anfaenger beim 1. Mal korrekt wird
> > schreiben koennen; selbst wenn, ist dies ausgesprochen laestig und
> > lenkt von wichtigeren Konzepten ab. In allen anderen Sprachen, die ich
> > kenne, ist dies trivial. C I/O ist wirklich ohne jeden Zweifel nicht
> > anfaengerfreundlich.
>
> int c;
> char buffer[4096]; /* sollte mehr sein als jede Konsole halten kann */
Was fuer ein Quatsch. Spaetestens, wenn stdin eine Datei ist, geht das
gruendlich in die Hose und erzeugt auch noch gleich eine
Sicherheitsluecke. Sowas auch nur vorzuschlagen, finde ich schon fast
boeswillig.
--
Falk
Claus Reibenstein
> Falk Hueffner <falk.h...@student.uni-tuebingen.de> wrote:
>
>>Wie liest man eine Zeile von stdin? Dafuer braucht man in C schon
>>ca. 10-20 Zeilen Code
>
> fgets(buf, sizeof buf, stdin);
>
> ist das so schwierig?
Falk meinte Token, nicht Zeilen ;-)
SCNR. Claus
Carsten Krueger
>Schwachsinn. Unsinn kann man immer anrichten. Standardkonform
>programmieren kann man nur wenn man
>1. den Standard nicht nur flüchtig gelesen sondern auch verstanden hat
>2. genau weiß was man tut und nicht halbgaren Unsinn zusammenhackt
Programmier mal nen ls-Kommando in ANSI C, ach geht nicht? Mift
Mach mal nen ClearScreen in ANSI C, ach geht nicht? Mift
Schreib mal nen Echoserver in ANSI C, ach geht nicht? Mift
Benutz mal ANSI C auf nem 4-Bit-Mikrokontroller, ach geht nicht? Mift
ANSI C ist nutzlos
>Blödsinn. Ein stream ist in Ein- und Ausgabe nunmal allem überlegen
>was irgendwaleche ominösen Devises machen - wenn man nicht
Na klar.
Es gibt graphische Oberflächen, Netzwerke, etc. und ANSI C weiß nichts
davon.
>Mit C ist es kinderleicht über stdin Dateien lokal oder
>remote/Pipes/Tastatur/com/oder sonstige Datenströme zu lesen und über
>stdout zu schreiben.
Com? Zeig mal.
>Schreibt einer der C nichtmal ansatzweise kapiert hat. Laß Dir Dein
>Lehrgeld wiedergeben!
Wie schön, daß du das beurteilen kannst.
Juergen Ilse
Falk Hueffner <falk.h...@student.uni-tuebingen.de> wrote:
> "The Real OS/2 Guy" <os2...@pc-rosenau.de> writes:
>> Mit C ist es kinderleicht über stdin Dateien lokal oder
>> remote/Pipes/Tastatur/com/oder sonstige Datenströme zu lesen und
>> über stdout zu schreiben.
> Wie liest man eine Zeile von stdin?
#include <stdio.h>
int main(void) {
char line[1024];
fgets(line,sizeof(line),stdin);
fputs(line,stdout);
return 0;
}
> Dafuer braucht man in C schon ca. 10-20 Zeilen Code, die *kein* Anfaenger
> beim 1. Mal korrekt wird schreiben koennen;
Das da oben sind 7 Zeilen, keine 10-20, und das Programm liest nicht nur
eine Zeile von stdin (allerdings beschraenkt auf maximal 1023 Zeichen),
sondern gibt die gelesenen Zeichen auch noch wieder auf stdout aus ...
So kompliziert schein es also nicht zu sein (und wenn du dich ueber die
von mir angenommene Maximallaenge der Zeile aufregen willst: Der Umgang
mit "unbegrenzt langen Zeilen" ist in anderen Sprachen so ohne weiteres
auch nicht implementiert, bei vielen Pascalimplementierungen sind Strings
nur maximal 255 Zeichen lang, laengere Strings *gibt* *es* *dort* *nicht*).
> selbst wenn, ist dies ausgesprochen laestig und lenkt von wichtigeren
> Konzepten ab. In allen anderen Sprachen, die ich kenne, ist dies trivial.
Ich halte den oben stehenden 7-Zeiler fuer trivial.
> C I/O ist wirklich ohne jeden Zweifel nicht anfaengerfreundlich.
Das mag sein, das IO bei DIN-Pascal ist es auch nicht, und bei Modula2
decken wir dann ambesten auch mal den Mantel des Schweigens drueber ...
Ich stimme dir zu, dass C nicht unbedingt besonders gut als Anfaenger-
sprache geeignet ist (zumindest bin ich dieser Ansicht) aber nicht aus
den von dir genannten Gruenden, sondern weil es eine ziemliche Hudelei
bzgl. der Datentypen *erlaubt* und dem Programmierer dabei den Source
nicht vor die Fuesse kotzt sondern den Mist sogar noch zu irgendwas
uebersetzt ...
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)
Carsten Krueger
>#include <stdio.h>
>int main(void) {
> char line[1024];
> fgets(line,sizeof(line),stdin);
> fputs(line,stdout);
> return 0;
>}
>
>> Dafuer braucht man in C schon ca. 10-20 Zeilen Code, die *kein* Anfaenger
>> beim 1. Mal korrekt wird schreiben koennen;
>
>Das da oben sind 7 Zeilen, keine 10-20, und das Programm liest nicht nur
>eine Zeile von stdin (allerdings beschraenkt auf maximal 1023 Zeichen),
>sondern gibt die gelesenen Zeichen auch noch wieder auf stdout aus ...
Pascal:
VAR S : STRING;
BEGIN
READLN(S);
WRITELN(S);
END.
Man kann sich nicht in den Fuss schießen was die Länge des Strings
betrifft und mann muss nicht wissen, was stdin und out ist.
>Ich halte den oben stehenden 7-Zeiler fuer trivial.
Intuitiv ist der aber bestimmt nicht.
Ullrich von Bassewitz
> Programmier mal nen ls-Kommando in ANSI C, ach geht nicht? Mift
> Mach mal nen ClearScreen in ANSI C, ach geht nicht? Mift
> Schreib mal nen Echoserver in ANSI C, ach geht nicht? Mift
> Benutz mal ANSI C auf nem 4-Bit-Mikrokontroller, ach geht nicht? Mift
> ANSI C ist nutzlos
Flieg mal nach Frankfurt mit einem Auto. Ach, geht nicht? Mist!
Fahr mal ueber's Meer mit einem Auto. Ach, geht nicht? Mist!
Geh mal auf dem Acker duengen mit einem Auto. Ach, geht nicht? Mist!
Autos sind nutzlos.
Merkst Du was?
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
17:29:03 up 28 days, 52 min, 9 users, load average: 0.00, 0.01, 0.00
Carsten Krueger
>Flieg mal nach Frankfurt mit einem Auto. Ach, geht nicht? Mist!
>Fahr mal ueber's Meer mit einem Auto. Ach, geht nicht? Mist!
>Geh mal auf dem Acker duengen mit einem Auto. Ach, geht nicht? Mist!
>Autos sind nutzlos.
>
>Merkst Du was?
Ich kann damit Prima von Berlin nach Rom fahren.
Nicht alles was hinkt ...
Was für ein nicht-triviales nützliches Programm kannst du dir
vorstellen was in reinem ANSI C geschrieben ist?
Mal abgesehen von sowas ausgefallenem wie FlexeLint.
Irgendwo braucht man Schnittstellen zu den tatsächlichen Gegebenheiten
(und verlässt damit ANSI C) oder man ist sehr in seinen Möglichkeiten
beschränkt.
Übrigens: ich sage nicht, daß das mit ISO-Pascal etc. besser ist.
Juergen Ilse
Carsten Krueger <usenet23.e...@neverbox.com> wrote:
> Was für ein nicht-triviales nützliches Programm kannst du dir
> vorstellen was in reinem ANSI C geschrieben ist?
> Mal abgesehen von sowas ausgefallenem wie FlexeLint.
"grep", "awk", "bc", ...
Dafuer braucht man jeweils nicht unbedingt mehr zu brauchen, als einem
der Standard garantiert ...
Juergen Ilse
Carsten Krueger <usenet23.e...@neverbox.com> wrote:
> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>>#include <stdio.h>
>>int main(void) {
>> char line[1024];
>> fgets(line,sizeof(line),stdin);
>> fputs(line,stdout);
>> return 0;
>>}
>>> Dafuer braucht man in C schon ca. 10-20 Zeilen Code, die *kein* Anfaenger
>>> beim 1. Mal korrekt wird schreiben koennen;
>>Das da oben sind 7 Zeilen, keine 10-20, und das Programm liest nicht nur
>>eine Zeile von stdin (allerdings beschraenkt auf maximal 1023 Zeichen),
>>sondern gibt die gelesenen Zeichen auch noch wieder auf stdout aus ...
> Pascal:
> VAR S : STRING;
> BEGIN
> READLN(S);
> WRITELN(S);
> END.
> Man kann sich nicht in den Fuss schießen was die Länge des Strings
> betrifft und mann muss nicht wissen, was stdin und out ist.
... und der Datentyp STRING kann in Pascal auch keine beliebig lange
Zeichenkette aufnehmen, die Maximallaenge ist Implementationsspezifisch.
Wo ist nun der Vorteil (ausser, dass man noch nicht einmal sieht, wie
die Maximallaenge der einlesbaren Zeichen ist, aber ich frage mich
ernsthaft, ob das wirklich ein Vorteil sein soll ...)?
>>Ich halte den oben stehenden 7-Zeiler fuer trivial.
> Intuitiv ist der aber bestimmt nicht.
Hat nicht mal irgendwer geschrieben (sinngemaess) "das einzig intuitive
ist der Nippel, alles andere wurde erlernt"?
Carsten Krueger
>Dafuer braucht man jeweils nicht unbedingt mehr zu brauchen, als einem
>der Standard garantiert ...
Alles Batchbefehle, alles interaktive geht nicht so recht
Carsten Krueger
>... und der Datentyp STRING kann in Pascal auch keine beliebig lange
>Zeichenkette aufnehmen, die Maximallaenge ist Implementationsspezifisch.
Im Normalfall sollte die länge ausreichend sein, d.h. der Platform
angepasst.
>Wo ist nun der Vorteil (ausser, dass man noch nicht einmal sieht, wie
>die Maximallaenge der einlesbaren Zeichen ist, aber ich frage mich
>ernsthaft, ob das wirklich ein Vorteil sein soll ...)?
Wenn man eine größere Länge braucht kann man den Sprachstandard
verlassen.
>Hat nicht mal irgendwer geschrieben (sinngemaess) "das einzig intuitive
>ist der Nippel, alles andere wurde erlernt"?
:-)
Ich behaupte mal, daß man ein kleines Pascalprogramm was klingende
Variablen, etc. hat mit Englischkentnissen lesen kann.
Ullrich von Bassewitz
> Was für ein nicht-triviales nützliches Programm kannst du dir
> vorstellen was in reinem ANSI C geschrieben ist?
awk, basename, cat, cp, cut, date, echo, ed, expr, grep, head, od, paste,
printf, rm, sed, sort, tail, tee, uniq, und viele andere ...
Mit teilweise kleineren Einschraenkungen zum Unix Standard (z.B. keine Pfade),
aber keine dieser Einschraenkungen betrifft die eigentliche Funktion.
> Mal abgesehen von sowas ausgefallenem wie FlexeLint.
Ja danke, das ist ein weiteres Beispiel.
> Irgendwo braucht man Schnittstellen zu den tatsächlichen Gegebenheiten
> (und verlässt damit ANSI C) oder man ist sehr in seinen Möglichkeiten
> beschränkt.
Selbst wenn es so waere, dass man keine sinnvollen Programme schreiben kann,
die nur Standard C verwenden (und obige Liste widerlegt das eindrucksvoll),
dann hast Du immer noch unrecht: Den Standard musst Du kennen, weil er Dir
sagt, auf was Du Dich verlassen kannst, und auf was nicht.
Manchmal gibt es zum Beispiel einen Weg, etwas standardkonform zu schreiben
und viele nicht standardkonforme. Wer den Standard nicht kennt, fuer den sehen
alle Wege gleich aus. Er wird deshalb mit grosser Wahrscheinlichkeit einen
nicht standardkonformen Weg waehlen und damit oft Programme produzieren, die
fehlerhaft oder fehleranfaellig sind.
Ein unerfahrener Programmierer koennte zum Beispiel aus einem Signalhandler
heraus irgendwelche Funktionen aufrufen. In der Praxis kann das zu
sporadischen, sehr selten auftretenden Fehlern fuehren. Ein solches Programm
kann sehr lange klaglos laufen, es stuerzt vielleicht alle zwei Wochen mal ab.
Der Fehler ist so selten, dass er praktisch nicht reproduziert werden kann und
vielleicht in der Testphase ueberhaupt nicht auftritt. Ein solcher Fehler ist
der Alptraum eines jeden Programmiers, weil man ihn nicht richtig zu fassen
kriegt.
Ein erfahrener Programmierer, der den Standard kennt, haette nach einer
anderen Loesung gesucht, und damit einen solchen Fehler vermieden. Das nette
daran ist, dass dieser Programmierer ueberhaupt nicht wissen muss, welche
Fehler denn konkret auftreten, wenn er sich nicht an den Standard haelt. Er
muss nichts von Reentranz und globalen Variablen wissen. Er weiss, dass solche
Fehler ausgeschlossen sind, wenn er standardkonformen Code schreibt.
Und selbst wenn ein solcher Programmierer mal in die Verlegenheit kommt, Code
schreiben zu muessen, der nicht standardkonform ist, dann werden bei ihm alle
Alarmglocken angehen. Im Gegensatz zum unerfahrenen Programmierer, der sagt
"was soll schon passieren?", der mit derselben Laessigkeit nicht reentrante
Funktionen in Signalhandlern aufruft, wie er "++i" schreibt, weiss er genau,
dass es an dieser Stelle keine Garantien gibt, und dass er deshalb doppelt und
dreifach aufpassen muss. Jemand der den Standard nicht kennt ist wie ein
Kurzsichtiger im Strassenverkehr - er kann die potentiell gefaehrlichen
Situationen nicht erkennen.
Ein anderes Beispiel ist die Unterscheidung zwischen portablem und unportablem
Code: Auch ein Programm, welches Binarfiles liest, Directories kennt, oder
eine graphische Oberflaeche hat, besteht aus Teilen die unabhaengig davon
sind, standardkonform geschrieben werden koennen, und auf jeder Plattform,
fuer die es Standard C gibt lauffaehig sind. Ein unerfahrener Programmierer,
der den Standard nicht kennt, kann portablen Code nicht von unportablem
unterscheiden. Ein erfahrener Programmierer, der den Standard kennt, kann das.
Er wird deshalb die unportablen Teile von den portablen trennen, was zur Folge
hat, dass ein solches Programm sehr viel einfacher portierbar ist. Dieses
Vorgehen erleichtert nicht nur die Portierung, sondern es erlaubt auch eine
Wiederverwendung der portablen Teile in anderen Programmen und auf anderen
Plattformen. Das wiederum erhoeht die Wiederverwendungsrate, senkt die
Fehlerquote, und spart damit richtig Geld. Das mag Dir egal sein, weil es
nicht Dein Geld ist, aber ich kann Dir versichern, dass Schlipstraeger auf
sowas abfahren:-)
Es gibt noch mehr Gruende, warum es fuer jeden C Programmierer sinnvoll ist,
den Standard zu kennen. Um meinen Artikel aber mal zu Ende zu bringen: Du
scheinst zu glauben, dass die Diskussion ueber den C Standard wie sie in
dieser Gruppe gefuehrt wird keinerlei praktische Anwendung hat, und von
Theoretikern gefuehrt wird, die - wenn ueberhaupt - an voellig praxisfernen C
Projekten arbeiten, wohingegen Du mit Deinen Real-World Programmen den echten
Einblick hast. Ich kann Dir versichern, dass das Gegenteil der Fall ist. Ich
weiss nicht von allen hier, was sie machen, aber viele Regulars in dieser
Gruppe sind bereits sehr lange dabei und haben Programmiererfahrung in den
unterschiedlichsten Bereichen.
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
19:52:31 up 28 days, 3:16, 9 users, load average: 0.19, 0.20, 0.12
Carsten Krueger
>Mit teilweise kleineren Einschraenkungen zum Unix Standard (z.B. keine Pfade),
>aber keine dieser Einschraenkungen betrifft die eigentliche Funktion.
In der Form in der sie existieren sind sie halt in ANSI C nicht
möglich.
Was bringt ein Programm was tolle "Berechnungen" anstellen kann, wenn
es nicht mit der Außenwelt kommunizieren kann?
>Selbst wenn es so waere, dass man keine sinnvollen Programme schreiben kann,
>die nur Standard C verwenden (und obige Liste widerlegt das eindrucksvoll),
>dann hast Du immer noch unrecht: Den Standard musst Du kennen, weil er Dir
>sagt, auf was Du Dich verlassen kannst, und auf was nicht.
ACK
>Es gibt noch mehr Gruende, warum es fuer jeden C Programmierer sinnvoll ist,
>den Standard zu kennen. Um meinen Artikel aber mal zu Ende zu bringen: Du
>scheinst zu glauben, dass die Diskussion ueber den C Standard wie sie in
>dieser Gruppe gefuehrt wird keinerlei praktische Anwendung hat, und von
Falsch.
Ich sage, daß man mit purem ANSI C nicht wirklich viel anfangen kann.
>Theoretikern gefuehrt wird, die - wenn ueberhaupt - an voellig praxisfernen C
>Projekten arbeiten, wohingegen Du mit Deinen Real-World Programmen den echten
>Einblick hast.
Nein.
>Ich kann Dir versichern, dass das Gegenteil der Fall ist. Ich
>weiss nicht von allen hier, was sie machen, aber viele Regulars in dieser
>Gruppe sind bereits sehr lange dabei und haben Programmiererfahrung in den
>unterschiedlichsten Bereichen.
Glaube ich dir.
In meinem Ausgangsposting ging es darum, daß ANSI C weder als lowlevel
noch als highlevel Sprache zu gebrauchen ist. Man braucht immer
nichtportable Erweiterungen. (wobei das relativ ist, Posix ist gut
verfügbar)
Erich Fruehstueck
Überlange Zeilen werden einfach aufgespalten. buf ist immer
Nullterminiert. Man kann nur nicht davon ausgehen, dass buf immer
einen Zeilenvorschub enthält. Ich denke, für Anfängerprogramme
kann das Problem vernachlässigt werden. Die Buffergröße ist dann
halt eine Restriktion für die Anwendung. In der Regel wird man als Anfänger
auch keine Programme schreiben, die mit beliebig unsinnigen und fehlerhaften
Eingaben zurechtkommen müssen.
Ansonsten hängt es von der Problemstellung ab,
wie mit überlangen Zeilen umzugehen ist:
* Zeile aufspalten
* Ignorieren der restlichen Zeichen der Zeile
* Warnung ausgeben, Zeile zur Gänze ignorieren
* Fehlermeldung, Verarbeitung abbrechen
* Dynamischen Buffer verwenden, bei Bedarf vergrößern
Professionelle Programme für beliebig lange Zeilen werden wohl mit einem
dynamischen Buffer arbeiten. Da schreibt man sich halt einmal eine
Hilfsfunktion, die das erledigt. Aber da ist man aus dem Anfängerstadium
bereits herausen.
Grüße
Ullrich von Bassewitz
> In der Form in der sie existieren sind sie halt in ANSI C nicht
> möglich.
Du hast nach sinnvollen Programmen gefragt. grep ist auch dann sinnvoll
nutzbar, wenn Dateinamen keine Pfade enthalten koennen, weil es nichts an der
eigentlichen Funktionalitaet aendert. Und das ist die einzige Einschraenkung,
die man machen muss. Aehnliches gilt fuer alle anderen Programme meiner
Liste.[*]
Du kannst nicht "sinnvolle" Programme fordern, und sobald jemand welche nennt,
neue Kriterien aufstellen, bloss damit die Antwort nicht gilt.
> Was bringt ein Programm was tolle "Berechnungen" anstellen kann, wenn
> es nicht mit der Außenwelt kommunizieren kann?
Welches der von mir genannten Programme kann nicht mit der Aussenwelt
kommunizieren?
> In meinem Ausgangsposting ging es darum, daß ANSI C weder als lowlevel
> noch als highlevel Sprache zu gebrauchen ist.
Obwohl ich auch daran zweifle will ich das nicht kommentieren. In der
Begruendung fuer diese Aussage hast Du aber behauptet, dass man keine
sinnvollen Programme in ISO C schreiben kann, und dass ISO C nutzlos sei - und
das ist definitiv falsch. Ich habe eine Liste von sinnvollen Programmen
gepostet (und Juergen hat ein paar mehr genannt), die man alle in ISO C
schreiben kann.
> Man braucht immer nichtportable Erweiterungen.
Welche nichtportablen Erweiterungen braucht grep?
Gruss
Uz
[1] Man koennte sich sogar streiten, ob man diese Einschraenkung (keine Pfade)
ueberhaupt machen muss. Schliesslich muss grep (oder welches Programm auch
immer) nichts ueber Pfade wissen. Es gibt einfach die Argumente an main() an
fopen() weiter. Wenn sie einen Pfad enthalten, und das Betriebssystem das
korrekt behandelt ist ja alles bestens und im Sinne des Standards ok.
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
23:14:50 up 28 days, 6:38, 9 users, load average: 1.20, 0.59, 0.28
The Real OS/2 Guy
Theoretisch unendlich. Praktisch wird Dein Programm wissen mit welchen
Eingabedaten es zu tun bekommen wird und mit einer entsprechenden
Größe arbeiten können. Wenn nicht ist getc() und evtl. dynamische
Puffergröße die bessere Wahl - wenn dann überhaupt noch ein Puffer
gebraucht wird.
The Real OS/2 Guy
<usenet23.e...@neverbox.com> wrote:
> "The Real OS/2 Guy" <os2...@pc-rosenau.de> wrote:
>
> >Schwachsinn. Unsinn kann man immer anrichten. Standardkonform
> >programmieren kann man nur wenn man
> >1. den Standard nicht nur flüchtig gelesen sondern auch verstanden hat
> >2. genau weiß was man tut und nicht halbgaren Unsinn zusammenhackt
>
> Programmier mal nen ls-Kommando in ANSI C, ach geht nicht? Mift
> Mach mal nen ClearScreen in ANSI C, ach geht nicht? Mift
> Schreib mal nen Echoserver in ANSI C, ach geht nicht? Mift
> Benutz mal ANSI C auf nem 4-Bit-Mikrokontroller, ach geht nicht? Mift
> ANSI C ist nutzlos
Daß ANSI C für systemspezifische Sachen nicht ausreichend ist, ist ein
uralter Hut. Alles was Du aufgeführt hast ist implementation defined -
wenn es eine Implementation denn überhaupt unterstützt. Schwachsinn
dur mehr Schwachsinn untermauer zu wollen zeigt nur daß Du keinen
Schimmer vom Standard hast.
> >Blödsinn. Ein stream ist in Ein- und Ausgabe nunmal allem überlegen
> >was irgendwaleche ominösen Devises machen - wenn man nicht
>
> Na klar.
> Es gibt graphische Oberflächen, Netzwerke, etc. und ANSI C weiß nichts
> davon.
Tatsächlich? Nenne doch mal eine graphische Oberfläche die nicht
ausschließlich auf einer Implementation definiert ist. Wincrap läuft
nicht auf linux, unix, AIX, MAC, ........., X läuft auch nicht auf
allen Implementierungen. Der ANSI C standard dient ausschließlich dazu
einen implementierungsunabhängigen Standard zu definieren - und der
ist wirklich nicht nutzlos. Ich habe selbst diverse nicht gerade
kleine Progrogramme so geschrieben daß ein einfacher Compile ohne ein
Bit im Souce zu ändern zu einem funktionalen Programm auf höchst
unterschiedlichen Systemen (16 und 32 Bit) problemlos genau das tut
für das es designt ist. Unter strikter Einhaltung des Standards halt.
Wenn Du mal das Brett das Du vorm Kopf hast beseitigen würdest,
würdest Du auf Anhieb reichlich komplexe Möglichkeiten Sehen auch
dicke Anwendungen 100% portabel zu schreiben - und weitere mit ein
paar zusätzlichen implementation spezifischen Funktionen.
> >Mit C ist es kinderleicht über stdin Dateien lokal oder
> >remote/Pipes/Tastatur/com/oder sonstige Datenströme zu lesen und über
> >stdout zu schreiben.
>
> Com? Zeig mal.
blah >\com1 <\com
blah >\dev\...
Das Programm braucht wirklich keine Ahnung zu haben welches Gerät und
ob überhaupt eines einen Eingabestream liefert oder Daten ausgibt. Es
ist Sache der Implementierung sich um solche Feinheiten Gedanken zu
machen.
> >Schreibt einer der C nichtmal ansatzweise kapiert hat. Laß Dir Dein
> >Lehrgeld wiedergeben!
>
> Wie schön, daß du das beurteilen kannst.
Der Schwachsinn der aus Deiner Feder kommt legt den Schluß nahe,
The Real OS/2 Guy
<usenet23.e...@neverbox.com> wrote:
> u...@spamtrap.musoftware.de (Ullrich von Bassewitz) wrote:
>
> >Flieg mal nach Frankfurt mit einem Auto. Ach, geht nicht? Mist!
> >Fahr mal ueber's Meer mit einem Auto. Ach, geht nicht? Mist!
> >Geh mal auf dem Acker duengen mit einem Auto. Ach, geht nicht? Mist!
> >Autos sind nutzlos.
> >
> >Merkst Du was?
>
> Ich kann damit Prima von Berlin nach Rom fahren.
> Nicht alles was hinkt ...
>
> Was für ein nicht-triviales nützliches Programm kannst du dir
> vorstellen was in reinem ANSI C geschrieben ist?
> Mal abgesehen von sowas ausgefallenem wie FlexeLint.
Hm, Du meinst ein Compiler ist eine Kleinigkeit? Du meinst die 3 Mio
Filter die bereis existieren sind alle Kleinigkeiten? Du meinst ein
Interpreter ist eine Kleinigkeit?
Es gibt programme die ein paar Millonen Zeilen dick sind - und nichts
als ANSI C verwenden. Es gibt viele Programme die nur ein paar Zeilen
klein sind und sich nicht ohne Neuschreiben auf ein anderes System
portieren lassen - nur weil der Programmierer nicht wahr haben wollte
daß ANSI C für die Aufgabe mehr als ausreichend ist.
> Irgendwo braucht man Schnittstellen zu den tatsächlichen Gegebenheiten
> (und verlässt damit ANSI C) oder man ist sehr in seinen Möglichkeiten
> beschränkt.
Quark.
> Übrigens: ich sage nicht, daß das mit ISO-Pascal etc. besser ist.
Nee, Du sagst Nur daß Du keine Ahnung hast.
Carsten Krueger
>Und das ist die einzige Einschraenkung,
>die man machen muss. Aehnliches gilt fuer alle anderen Programme meiner
>Liste.[*]
Dann versuch mal GNU Utitlities ohne POSIX zu kompilieren bzw. zeig
mir gleichmächte Versionen.
Selbst Versionen aus der Busybox benutzen irgendwelche spezifischen
Libs.
Wahrscheinlich währ es einfach zu viel Aufwand auf die Posixlibs zu
verzichten.
>> Was bringt ein Programm was tolle "Berechnungen" anstellen kann, wenn
>> es nicht mit der Außenwelt kommunizieren kann?
>
>Welches der von mir genannten Programme kann nicht mit der Aussenwelt
>kommunizieren?
Außenwelt = Benutzer (Tastatur,Maus,Bildschirm), Netzwerk,
Verzeichnisbaum, ...
stdin, stdout + Dateien ist eine extreme Beschränkung
>Obwohl ich auch daran zweifle will ich das nicht kommentieren. In der
>Begruendung fuer diese Aussage hast Du aber behauptet, dass man keine
>sinnvollen Programme in ISO C schreiben kann, und dass ISO C nutzlos sei - und
>das ist definitiv falsch. Ich habe eine Liste von sinnvollen Programmen
>gepostet (und Juergen hat ein paar mehr genannt), die man alle in ISO C
>schreiben kann.
Alles was bei mir unter Außenwelt fällt kann man mit ANSI C nicht
machen, es eignet sich nur für einige Shellkommandos.
>Welche nichtportablen Erweiterungen braucht grep?
Hab die gängigen Sourcen von grep nicht angesehen aber nimm halt
clear.
The Real OS/2 Guy
von Bassewitz) wrote:
> Carsten Krueger <usenet23.e...@neverbox.com> wrote:
> > Was für ein nicht-triviales nützliches Programm kannst du dir
> > vorstellen was in reinem ANSI C geschrieben ist?
>
> awk, basename, cat, cp, cut, date, echo, ed, expr, grep, head, od, paste,
> printf, rm, sed, sort, tail, tee, uniq, und viele andere ...
>
> Mit teilweise kleineren Einschraenkungen zum Unix Standard (z.B. keine Pfade),
> aber keine dieser Einschraenkungen betrifft die eigentliche Funktion.
Hä?
blah >/usr/var/mine/data </home/meinmuell/speziell/doof
blah >/dev/tty7 </dev/tty4
blah <d:\logfiles\mylog\data.log <"e:\Meine Dateien\Mein Muell\mehr
crap.txt"
Das programm sieht keine Pfad, kein Gerät, nicht mal eine Datei - nur
einen Stream der rein- und einen anderen der raus kommt.
[dicke wahre, zutreffende Anmerkungen]
Versuch mal ein Programm mit der Einstellung von Karsten zu schreiben
das auf n Targets läuft von denen Du nur weißt daß ein ANSI C Compiler
existiert, eine shell rennt die Batches ausführt und sonst nichts.
Mit einem Compiler auf einer Maschine die mit keinem der Zielmaschinen
auch nur die geringste Verwandschaft hat entwickelt und getestet - die
Du dafür aber aus der Westentasche im Schlaf beherrscht als
Entwicklungsumgebung und dazu ein 'make', ein 'make install' und ein
'make clean' - Ich habe einige der Zielsysteme nie gesehen - aber
grünlicher Test und die Sources mit den makefiles von einem
Vertriebler dort auf die Platte werfen lassen, die make laufen lassen
und ein Programm mit ca. 25.000 Zeilen Source hat seine Arbeit
aufgenommen wie vorgesehen. Möglich nur durch ANSI C.
Nur Ignoranten meinen ANSI C wäre nutzlos weil man damit ja nichts
machen könnte. Klar, man muß das einschalten was man gemeinhin Gehirn
nennt um das sauber hin zu kriegen - aber das hat man ja eh wenn man
den Standard mal richtig durcharbeitet.
Carsten Krueger
>Tatsächlich? Nenne doch mal eine graphische Oberfläche die nicht
>ausschließlich auf einer Implementation definiert ist.
Sagt dir Java was?
>allen Implementierungen. Der ANSI C standard dient ausschließlich dazu
>einen implementierungsunabhängigen Standard zu definieren - und der
>ist wirklich nicht nutzlos.
Doch für sich alleine gesehen schon.
siehe auch <57uksv8a92agrekql...@4ax.com>
>und weitere mit ein
>paar zusätzlichen implementation spezifischen Funktionen.
und da haben wir es. Man braucht für die MEISTEN Programme zusätzliche
Funktionen.
>Das Programm braucht wirklich keine Ahnung zu haben welches Gerät und
>ob überhaupt eines einen Eingabestream liefert oder Daten ausgibt.
Ja, aber es kann halt auch nicht einfach auf COM ausgeben, wenn der
Benutzer nicht vorher die Standardeingabe passend gewählt hat.
>Der Schwachsinn der aus Deiner Feder kommt legt den Schluß nahe,
Wie schön du doch flamen kannst.
The Real OS/2 Guy
<usenet23.e...@neverbox.com> wrote:
> u...@spamtrap.musoftware.de (Ullrich von Bassewitz) wrote:
>
> >Mit teilweise kleineren Einschraenkungen zum Unix Standard (z.B. keine Pfade),
> >aber keine dieser Einschraenkungen betrifft die eigentliche Funktion.
>
> In der Form in der sie existieren sind sie halt in ANSI C nicht
> möglich.
> Was bringt ein Programm was tolle "Berechnungen" anstellen kann, wenn
> es nicht mit der Außenwelt kommunizieren kann?
Laß Dir wirklich Dein Lehrgeld wiedergeben! Du blubberst sinnloses
Zeug. Wozu braucht ein Programm eine properitäre GUI wenn es nur von
stdin liest und auf stdout und stderr schreibt?
> >Selbst wenn es so waere, dass man keine sinnvollen Programme schreiben kann,
> >die nur Standard C verwenden (und obige Liste widerlegt das eindrucksvoll),
> >dann hast Du immer noch unrecht: Den Standard musst Du kennen, weil er Dir
> >sagt, auf was Du Dich verlassen kannst, und auf was nicht.
>
> ACK
>
> >Es gibt noch mehr Gruende, warum es fuer jeden C Programmierer sinnvoll ist,
> >den Standard zu kennen. Um meinen Artikel aber mal zu Ende zu bringen: Du
> >scheinst zu glauben, dass die Diskussion ueber den C Standard wie sie in
> >dieser Gruppe gefuehrt wird keinerlei praktische Anwendung hat, und von
>
> Falsch.
> Ich sage, daß man mit purem ANSI C nicht wirklich viel anfangen kann.
Deine Ignoranz stinkt zum Himmel.
> >Theoretikern gefuehrt wird, die - wenn ueberhaupt - an voellig praxisfernen C
> >Projekten arbeiten, wohingegen Du mit Deinen Real-World Programmen den echten
> >Einblick hast.
>
> Nein.
Doch, Daß Du unfähig bist Fakten zur kenntnis zu nehmen bedeutet nicht
daß diese existieren.
> >Ich kann Dir versichern, dass das Gegenteil der Fall ist. Ich
> >weiss nicht von allen hier, was sie machen, aber viele Regulars in dieser
> >Gruppe sind bereits sehr lange dabei und haben Programmiererfahrung in den
> >unterschiedlichsten Bereichen.
>
> Glaube ich dir.
>
> In meinem Ausgangsposting ging es darum, daß ANSI C weder als lowlevel
> noch als highlevel Sprache zu gebrauchen ist. Man braucht immer
> nichtportable Erweiterungen. (wobei das relativ ist, Posix ist gut
> verfügbar)
Stet Wiederholung von Müll macht doch nur mehr Müll und keine
Tatsache.
Carsten Krueger
>Laß Dir wirklich Dein Lehrgeld wiedergeben! Du blubberst sinnloses
>Zeug. Wozu braucht ein Programm eine properitäre GUI wenn es nur von
>stdin liest und auf stdout und stderr schreibt?
Langsam reichts.
Du kannst gerne auf nem Rechner ganz alleine mit deinem ANSI C ohne
Netzwerk verschimmeln
Beschimpf andere Leute.
EOT
Rainer Weikusat
> r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> C ist besonders für die Implementation von Verfahren
>> durch Elementaroperationen der zugrundeliegenden
>> Maschine geeignet.
>
> Meiner Meinung nach nein, weil man z.B. nicht weiß wie groß 'int'
> ist.
Man weiß das aber für jede Implementierung.
> ANSI C ist als Hochsprache nutzlos und genauso als Assemblerersatz.
'ANSI C' (was übrigens mittlerweile ISO-C ist) gibt einen Rahmen für
Eigenschaften von C-Implementierungen vor. Da ich hier an einem
Computer sitze, auf dem im wesentlichen nur C-Programme laufen,
scheint die behauptete Nutzlosigkeit etwas seltsam. Es gibt auch
keinen 'Ersatz' für Assembler und es kann ihn auch konzeptuell gar
nicht geben. Genau wie C ist das eine 'Ding' mit bestimmten
Eigenschaften, die unter Umständen einem Zweck dienen können.
> NACK, einem Anfänger will niemand beibringen wie man Fenster macht.
»Das also ist des Pudels Kern«. Er ist es sogar tatsächlich: Sehr
wenige Leute wollen 'Wissen' teilen, weil sie es idiotischerweise für
eine knappe Ressource halten, die es nicht ist. Aber Arbeitskraft ist
eine und es ist reichlich sinnlos, die mit infighting zu vergeuden,
weil allen Leuten ins Hirn gehämmert wird, daß es exakt zwei Gruppen
von Menschen gäbe: 'Den Gewinner' und 'die Verlierer'. Das ist auf
exakt einem Gebiet der Fall, nämlich bei der alltäglichen Konkurrenz
um das zweifelhafte Privileg, zum Amüsemant irgendwelcher Damen
symbolische Kopfstände machen zu dürfen. Kooperation bringt bessere
Resultate als Konfrontation, denn Leute konzentrieren sich dann auf
Verbesserungen der Arbeitsleistung anstatt darauf, Konkurrenten aus
dem Weg zu räumen, was eine vollkommen unproduktive Tätigkeit ist.
> READ,WRITE,IF,CASE,FOR,REPEAT,WHILE für den Anfang, dann RECORDS,
> PROCEDUREN und dann andere Konzepte OO, Funktional, ...
Wie wärs denn überhaupt mal mit Konzepten anstelle von
Schlüsselwörtern?
Rainer Weikusat
> Falk Hueffner <falk.h...@student.uni-tuebingen.de> wrote:
>> Wie liest man eine Zeile von stdin? Dafuer braucht man in C schon
>> ca. 10-20 Zeilen Code, die *kein* Anfaenger beim 1. Mal korrekt wird
>> schreiben koennen; selbst wenn, ist dies ausgesprochen laestig und
>> lenkt von wichtigeren Konzepten ab. In allen anderen Sprachen, die ich
>> kenne, ist dies trivial. C I/O ist wirklich ohne jeden Zweifel nicht
>> anfaengerfreundlich.
>
> fgets(buf, sizeof buf, stdin);
>
> ist das so schwierig?
Es versagt, falls im Eingabedatenstrom binäre Nullen enthalten sind
und es ist meistens einfacher, beim Einlesen zu parsen und nicht erst
danach.
Rainer Weikusat
> Blödsinn. Ein stream ist in Ein- und Ausgabe nunmal allem überlegen
> was irgendwaleche ominösen Devises machen - wenn man nicht
Falls ich drei Zahlen zwischen zwei Programmen auf demselben Rechner
kommunizieren möchte, ist ein stream nicht nur nicht überlegen,
sondern sogar vollkommen ungeeignet. Oder falls ich mehr
Fehlerbehandlung brauche als 'ging gut' oder 'ging nicht gut' etc.
Rainer Weikusat
> "Erich Fruehstueck" <e...@synthesis.co.at> writes:
>> > Wie liest man eine Zeile von stdin? Dafuer braucht man in C schon
>> > ca. 10-20 Zeilen Code, die *kein* Anfaenger beim 1. Mal korrekt wird
>> > schreiben koennen; selbst wenn, ist dies ausgesprochen laestig und
>> > lenkt von wichtigeren Konzepten ab. In allen anderen Sprachen, die ich
>> > kenne, ist dies trivial. C I/O ist wirklich ohne jeden Zweifel nicht
>> > anfaengerfreundlich.
>>
>> fgets(buf, sizeof buf, stdin);
>>
>> ist das so schwierig?
>
Es kann nicht 'immer' funktionieren, denn ein Computer hat eine
begrenzte Speicherkapazität. Es ist also notwendig, eine Obergrenze
für Speicherverbrauch zu haben, die erzwungen wird.
Rainer Weikusat
> Pascal:
> VAR S : STRING;
> BEGIN
> READLN(S);
> WRITELN(S);
> END.
> Man kann sich nicht in den Fuss schießen was die Länge des Strings
> betrifft
Stimmt. Er ist in jedem Fall zu kurz.
>>Ich halte den oben stehenden 7-Zeiler fuer trivial.
>
> Intuitiv ist der aber bestimmt nicht.
Absolut gar nichts ist 'intuitiv', daß man erlernen muß.
Bodo Thiesen
> C als Lernsprache
>
> C ist besonders für die Implementation von Verfahren
> durch Elementaroperationen der zugrundeliegenden
> Maschine geeignet.
Wobei letztlich die 1:1 Zuordnung C -> Maschienensprache fehlt (dank der
AS-IF-Regel).
> Die Sprache enthält keine
> standardisierten Verfahren zum Zugriff auf
> Dateisysteme,
fopen & CO existiert also bei Dir nicht.
> Netze oder Datenbanken, keine regulären
> Ausdrücke, keine graphische Benutzeroberfläche und
> keine Speicherverwaltung.
malloc & CO existiert also bei Dir auch nicht.
BTW: Dann könnte man allerdings erwähnen, daß es einige Erweiterungen gibt,
die auf vielen[TM] Systemen verfügbar sind, also allen voran POSIX. (Was
dann Zugriffe auf Verzeichnisse, Netzwerk u.ä. standartisiert).
>[Rest gesnippt]
Ansonsten ok.
Gruß, Bodo
--
MS Outlook Express?->[DE: http://piology.org/ILOVEYOU-Signature-FAQ.html]
@@@@@ GEGEN TCG aka. TCPA: @@@@@ [DE: http://www.againsttcpa.com]
Bodo Thiesen
Genau. Und weil das Programm irgendwann auch mal auf einem TI laufen soll,
nimmt man 16 Bytes, weil mehr hat man da ja nicht. Genau so entstehen dann
Programme mit unsinnigen Beschränkungen.
Bodo Thiesen
> Falk Hueffner <falk.h...@student.uni-tuebingen.de> wrote:
>
> char line[1024];
> fgets(line,sizeof(line),stdin);
> fputs(line,stdout);
>
>> Dafuer braucht man in C schon ca. 10-20 Zeilen Code, die *kein* Anfaenger
>> beim 1. Mal korrekt wird schreiben koennen;
>
>Das da oben sind 7 Zeilen, keine 10-20, und das Programm liest nicht nur
>eine Zeile von stdin (allerdings beschraenkt auf maximal 1023 Zeichen),
>sondern gibt die gelesenen Zeichen auch noch wieder auf stdout aus ...
>So kompliziert schein es also nicht zu sein (und wenn du dich ueber die
>von mir angenommene Maximallaenge der Zeile aufregen willst: Der Umgang
>mit "unbegrenzt langen Zeilen" ist in anderen Sprachen so ohne weiteres
>auch nicht implementiert, bei vielen Pascalimplementierungen sind Strings
>nur maximal 255 Zeichen lang, laengere Strings *gibt* *es* *dort* *nicht*).
außerdem würde ein einfaches do { ... } while (strlen(line)==1023); reichen,
um eine gesamte Zeile einzulesen und auszugeben.
Bodo Thiesen
> [Einlesen einer Zeile]
>
> von wegen 10 - 20 Zeilen code! Kriegt JEDER Anfänger der wirklich an C
> interessiert ist als 2. Aufgabe nach dem allseits bekannten hello
> world Programm auf die Reihe.
Klaro. Jeder. Bestimmt.
> Gut, wer noch nie in seinem Leben ein
> Programm geschrieben hat, tut sich wirklich schwer, aber der bricht
> sich selbst mit basic einen ab.
Genau, schließlich ist
input "Bitte Text eingeben: ",A$
auch sooo schwer.
> Ein gut aufbereiteter Anfängerkurs "Programmieren in ANSI C" ist eine
> Woche und enthält nur ca. 20 Unterrichts- und 20 Übungsstunden - und
> dabei noch eine Einführung in das kleine Computer-1x1 (was sind
> Binärzahlen, wie rechne ich binär).
Und danach kann man exakt garnichts.
>Herbert
Wie wäre es, wenn Du langsam mal wieder deine From-Zeile korrigierst? Aus
aktuellem Anlass kann es inzwischen ja nicht mehr nötig sein, und mit diesem
komischen Namen zu nerven.
Jens Schweikhardt
in <yyw3cc5...@winter.inter-i.wohnheim.uni-mainz.de>:
...
#> fgets(buf, sizeof buf, stdin);
#>
#> ist das so schwierig?
#
# Es versagt, falls im Eingabedatenstrom binäre Nullen enthalten sind
stdin ist ein Text-Strom, in dem sind keine erkennbaren binären Nullen.
# und es ist meistens einfacher, beim Einlesen zu parsen und nicht erst
# danach.
Das hängt davon ab, was man 'meistens' vor hat.
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Jens Schweikhardt
in <16pjsvcorhdg1g8rv...@4ax.com>:
# "The Real OS/2 Guy" <os2...@pc-rosenau.de> wrote:
#
#>Schwachsinn. Unsinn kann man immer anrichten. Standardkonform
#>programmieren kann man nur wenn man
#>1. den Standard nicht nur flüchtig gelesen sondern auch verstanden hat
#>2. genau weiß was man tut und nicht halbgaren Unsinn zusammenhackt
#
# Programmier mal nen ls-Kommando in ANSI C, ach geht nicht? Mift
# Mach mal nen ClearScreen in ANSI C, ach geht nicht? Mift
# Schreib mal nen Echoserver in ANSI C, ach geht nicht? Mift
# Benutz mal ANSI C auf nem 4-Bit-Mikrokontroller, ach geht nicht? Mift
# ANSI C ist nutzlos
Ich ignoriere mal Deine kindische Rechtschreibung und versuche sachlich
zu argumentieren.
1. Du hast nicht verstanden, welche Ziele sich ANSI (besser ISO) C
vorgenommen hat. Dateisysteme, Terminals und Sockets sind
systemspezifische Konzepte und ISO C hatte nie den Anspruch, POSIX zu
sein.
2. ISO C hat sich u.a. Portabilität auf die Fahne geschrieben. Das hat
so gut geklappt, daß man folgende Anwendungen in 100% ISO C schreiben kann:
- C Compiler
- Lexer und Parser
- egrep, sed, sort, jede Menge anderer Filter
- Numbercruncher
- Schachproblemlöser
- u.v.m.
#>Blödsinn. Ein stream ist in Ein- und Ausgabe nunmal allem überlegen
#>was irgendwaleche ominösen Devises machen - wenn man nicht
#
# Na klar.
# Es gibt graphische Oberflächen, Netzwerke, etc. und ANSI C weiß nichts
# davon.
Dieser Vorwurf zeigt erneut Dein Unverständnis des Anspruchs von ISO C.
Es geht nicht darum, all things to all people zu sein. If you want POSIX,
you know where to find it. Niemand hat je gesagt, daß man mit ISO C jede
Anwendung schreiben kann. Niemand wirft einem Porsche vor, nicht fliegen
und schwimmen zu können. So ein Fliwatüt ist für viele Anwendungen ein
zu schwerfälliges Gefährt.
Juergen Ilse
Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> "Erich Fruehstueck" <e...@synthesis.co.at> writes:
>> fgets(buf, sizeof buf, stdin);
>> ist das so schwierig?
> Es versagt, falls im Eingabedatenstrom binäre Nullen enthalten sind
In der aufgabenstellung war vom einlesen einer Zeile die Rede, und das
ergibt bei binary streams nur maessig Sinn. Bei text streams stoesst
man aber nicht auf Nullbytes ...
> und es ist meistens einfacher, beim Einlesen zu parsen und nicht erst
> danach.
Das kommt auf den Einzelfall an. In der Aufgabenstellung war nur vom
einlesen einer Zeile die Rede, nicht vom parsen der Daten.
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)
The Real OS/2 Guy
Wie kommst Du auf dieses schmale Brett?
send | receive
verbindet 2 Enden eines strams - gemeinhin pipe genannt. Erzähl mir
nicht daß das ungeeignet wäre oder Du wirst ausgelacht. Richtig - hat
mit C nichts zu tun, zeigt aber trotzdem wie man standardgerecht aber
doch überraschend einfach die I(O Eigenschaften von Standard C
ausnutzen kann.
Juergen Ilse
Ullrich von Bassewitz <u...@spamtrap.musoftware.de> wrote:
> Carsten Krueger <usenet23.e...@neverbox.com> wrote:
>> In der Form in der sie existieren sind sie halt in ANSI C nicht
>> möglich.
> Du hast nach sinnvollen Programmen gefragt. grep ist auch dann sinnvoll
> nutzbar, wenn Dateinamen keine Pfade enthalten koennen, weil es nichts an der
> eigentlichen Funktionalitaet aendert.
Es ist noch nicht einmal eine Einschraenkung. Schliesslich ist es egal,
ob ein Dateiname wie "/home/mydata/privat/mydata.txt" als die Datei
"mydata.txt" im Verzeichnis "/home/mydata/privat" oder als ein "Verzeich-
nisloser Dateiname" "/home/mydata/privat/mydata.txt" aufgefasst wird.
Es macht weder fuer das Programm noch fuer den Programmaufruf oder die
Funktionalitaet von grep (oder welcher der genannten Programme man auch
betrachtet) den geringsten Unterschied.
> [1] Man koennte sich sogar streiten, ob man diese Einschraenkung (keine Pfade)
> ueberhaupt machen muss. Schliesslich muss grep (oder welches Programm auch
> immer) nichts ueber Pfade wissen. Es gibt einfach die Argumente an main() an
> fopen() weiter. Wenn sie einen Pfad enthalten, und das Betriebssystem das
> korrekt behandelt ist ja alles bestens und im Sinne des Standards ok.
Eben. Von "Einschraenkung" ist da IMHO nichts zu entdecken (jedenfalls
nicht bei den genannten Programmen).
The Real OS/2 Guy
<usenet23.e...@neverbox.com> wrote:
> "The Real OS/2 Guy" <os2...@pc-rosenau.de> wrote:
>
> >Tatsächlich? Nenne doch mal eine graphische Oberfläche die nicht
> >ausschließlich auf einer Implementation definiert ist.
>
> Sagt dir Java was?
Welche der nur bedingt kompatiblem versionen meinst Du? 1.=, 1.1, 1.2,
1.3 oder 1.4.0, 1.4.1?
Erzähl nicht daß ein Java 1.1 Programm mit einer wunderschönen GUI
unter Java 1.3 laufen würde. Nichts ist kompatibler zu nichts als Java
zu Java.
C Programme die 1980 ohne Kenntnis von ANSI C 1989 geschrieben wurden
laufen dagegen noch immer und lassen sich sogar noch von einem
Compiler der 2003 geschrieben wurde und ANASI C 1999 entspricht
übersetzen. Sowas nennt man Kompatibilität.
>
> >allen Implementierungen. Der ANSI C standard dient ausschließlich dazu
> >einen implementierungsunabhängigen Standard zu definieren - und der
> >ist wirklich nicht nutzlos.
>
> Doch für sich alleine gesehen schon.
> siehe auch <57uksv8a92agrekql...@4ax.com>
Für sich alleine gesehen braucht man keine einzige Programmiersprache.
Du faselst schon wieder Unsinn.
> >und weitere mit ein
> >paar zusätzlichen implementation spezifischen Funktionen.
>
> und da haben wir es. Man braucht für die MEISTEN Programme zusätzliche
> Funktionen.
Du erzählt blanken Unsinn. Fein daß Du nur das quotest was Deinem
leeren Kopf entspricht.
>
> >Das Programm braucht wirklich keine Ahnung zu haben welches Gerät und
> >ob überhaupt eines einen Eingabestream liefert oder Daten ausgibt.
>
> Ja, aber es kann halt auch nicht einfach auf COM ausgeben, wenn der
> Benutzer nicht vorher die Standardeingabe passend gewählt hat.
Klar und man fähr auch Brühwürfel einzeln mit einem 30-Tommeen LKW
aus. Du hast nicht mal andeutungsweise das Konzept von streams
verstanden.
Ullrich von Bassewitz
> Dann versuch mal GNU Utitlities ohne POSIX zu kompilieren bzw. zeig
> mir gleichmächte Versionen.
Das war nicht die Aufgabenstellung. Deine Frage war, ob es sinnvolle Programme
gibt, die nur in ISO C geschrieben werden koennen, und die Antwort ist ein
eindeutiges: Aber sicher!
>>Welches der von mir genannten Programme kann nicht mit der Aussenwelt
>>kommunizieren?
>
> Außenwelt = Benutzer (Tastatur,Maus,Bildschirm), Netzwerk,
> Verzeichnisbaum, ...
>
> stdin, stdout + Dateien ist eine extreme Beschränkung
Du hast meine Frage nicht beantwortet: Welches der von mir genannten Programme
kann nicht mit der Aussenwelt kommunizieren?
>>Welche nichtportablen Erweiterungen braucht grep?
>
> Hab die gängigen Sourcen von grep nicht angesehen aber nimm halt
> clear.
Wozu sollte grep clear brauchen?
Hier ist nochmal ein Beispiel fuer eine sinnvolle Anwendung: Du kannst in
purem ISO C eine komplette Entwicklungsumgebung mit C Compiler, Assembler und
Linker fuer Deine Lieblings-Embedded-CPU schreiben. Einzige Einschraenkung
ist, dass Du keinen Binaeroutput erzeugen kannst (zumindest ist nicht
sichergestellt, dass der Output auf dem Zielsystem lauffaehig ist). Das ist
aber keine wirkliche Einschraenkung, weil Du genausogut sowas wie Intel-Hex
erzeugen kannst, und tatsaechlich tun das auch etwa 50% der
Entwicklungssysteme die ich kenne. Wenn das keine sinnvolle Anwendung ist,
dann kann ich Dir nicht helfen:-)
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
11:46:21 up 28 days, 19:09, 9 users, load average: 0.00, 0.05, 0.02
Tibor Pausz
> "grep", "awk", "bc", ...
> Dafuer braucht man jeweils nicht unbedingt mehr zu brauchen, als einem
> der Standard garantiert ...
Wenn Du mit dem Standard die Single UNIX Specification meinst hast Du
sicher recht.
Aber wie willst Du rein in C sinnvoll Pattern Matching auf Dateinamen
machen? (grep benutzt das Feature) Jede Datei versuchen zu öffnen?
Verzeichnisse einlesen geht ja nicht, das kennt C nicht.
Tibor Pausz
> awk, basename, cat, cp, cut, date, echo, ed, expr, grep, head, od, paste,
> printf, rm, sed, sort, tail, tee, uniq, und viele andere ...
>
> Mit teilweise kleineren Einschraenkungen zum Unix Standard (z.B. keine Pfade),
> aber keine dieser Einschraenkungen betrifft die eigentliche Funktion.
Es gibt für die meisten der Programme geforderte Mindestfeatures (siehe
Single UNIX Spec V3) und die lassen sich nicht mit ISO C umsetzen. Du
wolltest Programme anführen, die ausschließlich mit ISO C geschrieben
sind. Das trifft auf die Programme oben ohne Einschränkung der
definierten Funktionalität (Single UNIX Spec) nicht zu.
Jirka Klaue
Meinst sowas wie 'grep main *.c'?
Wo wird *.c expandiert? Ich tippe auf die Shell. Und Du?
Jirka
Bodo Thiesen
>Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>
>> Dafuer braucht man jeweils nicht unbedingt mehr zu brauchen, als einem
>> der Standard garantiert ...
>
>Alles Batchbefehle, alles interaktive geht nicht so recht
Bei mir ist bc allerdings ein sehr interaktives Programm, dafür daß
interaktiv nicht gehen soll.
Claus Reibenstein
> Sagt dir Java was?
Ja: dass Du vom Thema ablenken willst.
> und da haben wir es. Man braucht für die MEISTEN Programme zusätzliche
> Funktionen.
Das ist korrekt. Deine Schlussfolgerung daraus, dass ANSI C nutzlos sei,
hingegen nicht.
Gruß. Claus
Claus Reibenstein
> In meinem Ausgangsposting ging es darum, daß ANSI C weder als lowlevel
> noch als highlevel Sprache zu gebrauchen ist.
Mir scheint, Du hast _sehr_ wenig Programmiererfahrung.
Ich habe schon an einigen, großen Projekten mitgearbeitet, bei denen gut
und gerne 99% in ANSI-C geschrieben waren. Für den kleinen Rest, der in
ANSI-C nicht ging, wurden natürlich systemspezifische Routinen
aufgerufen. Sollte das Programm portabel gehalten werden (was die Regel
war), wurden diese Aufrufe in einer eigenen API gekapselt.
Gruß. Claus
Jirka Klaue
> Maschienensprache
Schienen?
> standartisiert
Standarten?
Streng Dich mal ein bißchen an.
Jirka
Juergen Ilse
Jirka Klaue <jkl...@ee.tu-berlin.de> wrote:
> Tibor Pausz wrote:
>> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>>>"grep", "awk", "bc", ...
>>>Dafuer braucht man jeweils nicht unbedingt mehr zu brauchen, als einem
>>>der Standard garantiert ...
>> Wenn Du mit dem Standard die Single UNIX Specification meinst hast Du
>> sicher recht.
>> Aber wie willst Du rein in C sinnvoll Pattern Matching auf Dateinamen
>> machen? (grep benutzt das Feature) Jede Datei versuchen zu öffnen?
grep tut nichts in dieser Richtung. Das expandieren der qildcardnamen
macht die shell *vor* dem Aufruf von grep, grep bekommt nur die bereits
expandierte Liste zu Gesicht.
>> Verzeichnisse einlesen geht ja nicht, das kennt C nicht.
> Meinst sowas wie 'grep main *.c'?
> Wo wird *.c expandiert? Ich tippe auf die Shell. Und Du?
Da brauchst du nicht zu tippen, das macht eindeutig die shell.
Vinzent 'Gadget' Hoefler
>Jirka Klaue <jkl...@ee.tu-berlin.de> wrote:
>
>> Meinst sowas wie 'grep main *.c'?
>> Wo wird *.c expandiert? Ich tippe auf die Shell. Und Du?
>
>Da brauchst du nicht zu tippen, das macht eindeutig die shell.
Bei DOS u.ae. Betruebssystemen tut sie das nicht.
Vinzent.
Juergen Ilse
Laut Spezifikation von grep muss grep das erweitern von Wildcards
*nicht* selbst uebernehmen. Die unix-Versionen tun das auch nicht,
und einige Varianten fuer DOS und andere Systeme tun das auch nicht
(und sind daher in gewohnter Weise nur im Zusammenhang mit einer
shell zu gebruachen, die diese Aufgabe uebernimmt ... Ja, so etwas
gibt es *auch* fuer DOS und Windows).
Helmut Schellong
> Hallo,
>
> Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> wrote:
>
>>Juergen Ilse wrote:
>>
>>>Jirka Klaue <jkl...@ee.tu-berlin.de> wrote:
>>>
>>>>Meinst sowas wie 'grep main *.c'?
>>>>Wo wird *.c expandiert? Ich tippe auf die Shell. Und Du?
>>>
>>>Da brauchst du nicht zu tippen, das macht eindeutig die shell.
>>
>>Bei DOS u.ae. Betruebssystemen tut sie das nicht.
>
>
> Laut Spezifikation von grep muss grep das erweitern von Wildcards
> *nicht* selbst uebernehmen. Die unix-Versionen tun das auch nicht,
> und einige Varianten fuer DOS und andere Systeme tun das auch nicht
> (und sind daher in gewohnter Weise nur im Zusammenhang mit einer
> shell zu gebruachen, die diese Aufgabe uebernimmt ... Ja, so etwas
> gibt es *auch* fuer DOS und Windows).
He he, mit solchen Postings läufst Du Gefahr, daß ich mich
mit ``bsh'' einklinke, die es für DOS/Win gibt.
Und jetzt: Achtung, fertig, los! - mit dem Geflame.
<ebg>
--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Vinzent 'Gadget' Hoefler
>Laut Spezifikation von grep muss grep das erweitern von Wildcards
>*nicht* selbst uebernehmen.
Ja.
Und es ist die einfache[0] Methode, das in
<news:1g5a8bh.1hjwod31m7qapaN%pa...@stud.uni-frankfurt.de> genannte
Problem "Aber wie willst Du rein in C sinnvoll Pattern Matching auf
Dateinamen machen?" zu verlagern.
Aber, ... wie macht es denn dann eine in C geschriebene Shell? ;-)
Vinzent.
[0] Und auch sinnvolle. Dann koennte man sich als Nutzer wenigstens
bei jedem beliebigen Programm auf das gleiche Interface verlassen.
Ullrich von Bassewitz
> Du
> wolltest Programme anführen, die ausschließlich mit ISO C geschrieben
> sind. Das trifft auf die Programme oben ohne Einschränkung der
> definierten Funktionalität (Single UNIX Spec) nicht zu.
Nein. Ich wollte sinnvolle Programme auflisten, die sich in reinem ISO C
schreiben lassen. Und das trifft auf die genannten Programme zu, wenn man die
Features streicht, die sich in reinem ISO C nicht verwirklichen lassen. Wenn
Du willst, dann darfst Du den Programmen gerne andere Namen geben. Ich habe
die bekannten Namen verwendet, weil damit eher klar ist was ich meine. Was
gestrichen werden muss reicht von "ueberhaupt nichts" (bei grep zum Beispiel)
bis hin zu "unwichtige Dinge", wie die Behandlung von Pfaden. In keinem Fall
ist aber die Kernfunktionalitaet eingeschraenkt.
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
15:41:28 up 28 days, 23:05, 9 users, load average: 0.10, 0.10, 0.07
Sven Semmler
> Sagt dir Java was?
Höre auf mit Java. Bisher konnte mir noch keiner glaubhaft erklären
was genau an einem Java Programm Plattform-unabhängig ist. Java Programme
laufen auf der Java Plattform, die auf nativen Plattformen emuliert wird.
Schau Dir doch einfach mal einen beliebigen C64 Emulator auf einer
beliebigen nativen Plattform an und behaupte dann Java sei portabler. Ein
Java Programm läuft immer nur auf der JVM.
Ein ANSI-C Programm läuft auf nahezu jeder Plattform.
/Sven
--
Sven Semmler http://www.semmlerconsulting.com/
key fingerprint: 57C3 94A3 860A C6EC 4012 8826 7D0C 7657 3ABD FD9C
Christoph von Nathusius
begin quoting, Helmut Schellong wrote:
> He he, mit solchen Postings läufst Du Gefahr, daß ich mich
> mit ``bsh'' einklinke, die es für DOS/Win gibt.
Da ziehe ich doch eine Corinna Vinschen allemal
einem Helmut Schellong vor.
CvN
Bodo Thiesen
>Bodo Thiesen wrote:
>
>> Maschienensprache
>
> Schienen?
Liegt bestimmt daran, daß ich jeden Tag zweimal mit der Tram fahre ;-)
>> standartisiert
>
> Standarten?
Und ich schaue extra noch via steak nach, ob auch dort ein D hingehört,
oder ein T, und erhalt als Ausgabe:
$ steak -d standartisiert
--------------------------------------------------
Deutsch -> English
---------- Jetzt die Kontext-Eintraege ----------
Deutsch -> English
1 ) nicht normgerecht, nicht standartisiert :== non-standard
$
Und denke mir - ok, dann gehört *da* also doch das T hin ...
>Streng Dich mal ein bißchen an.
Ok, aber nur für Dich ;-)
Bodo Thiesen
>Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>
>> "grep", "awk", "bc", ...
>> Dafuer braucht man jeweils nicht unbedingt mehr zu brauchen, als einem
>> der Standard garantiert ...
>
> Aber wie willst Du rein in C sinnvoll Pattern Matching auf Dateinamen
> machen? (grep benutzt das Feature) Jede Datei versuchen zu öffnen?
> Verzeichnisse einlesen geht ja nicht, das kennt C nicht.
*Mein* grep kann /keine/ Verzeichnisse einlesen, dieses muß alle Namen
von Datei, auf denen es operieren soll übergeben bekommen. Ich weiß ja
nicht, was Dein grep so alles macht und kann.
Bodo Thiesen
>He he, mit solchen Postings läufst Du Gefahr, daß ich mich
>mit ``bsh'' einklinke, die es für DOS/Win gibt.
>
>Und jetzt: Achtung, fertig, los! - mit dem Geflame.
Schnauze!
(Du hast es ja so gewollt)
Gruß, Bodo
PS: fup2 de.alt.flame
Bodo Thiesen
> [Wildcards & Dateinamen]
>
> Aber, ... wie macht es denn dann eine in C geschriebene Shell? ;-)
Indem sie POSIX benutzt?
Gruß, Bodo
Alexander Bartolich
> *Mein* grep kann /keine/ Verzeichnisse einlesen, dieses muß alle
> Namen von Datei, auf denen es operieren soll übergeben bekommen.
> Ich weiß ja nicht, was Dein grep so alles macht und kann.
Mhh. Und das bei
X-Newsreader:
Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu)
^^^
$ grep --version | head -1
grep (GNU grep) 2.5.1
$ man grep | col -b | sed -ne'/^ *-R/,/^$/p'
-R, -r, --recursive
Read all files under each directory, recursively;
this is equivalent to the -d recurse option.
--
Für Google, Tux und GPL!
Rainer Weikusat
>>Hat nicht mal irgendwer geschrieben (sinngemaess) "das einzig intuitive
>>ist der Nippel, alles andere wurde erlernt"?
>
> :-)
>
> Ich behaupte mal, daß man ein kleines Pascalprogramm was klingende
> Variablen, etc. hat mit Englischkentnissen lesen kann.
Das ist ein Irrtum. Ich sitze auf der Arbeit zT neben einem
Fachinformatiker in Spe, der bessere 'Hello, World!'-Programme in
Pascal schreiben soll (wofür auch immer) und die 'Geschwätzigkeit' der
Sprache nervt ihn (dem Augenschein nach) und hilft ihm kein bißchen
(hinzu kommt natürlich der übliche Irrglaube, jede Programmiersprache
sei so aufwendig zu erlernen und nicht nur die erste und man folglich
falls man 'die falsche' [also Pascal] gelernt habe, primär durch
verschwendete Zeit sich selber einen Nachteil geschaffen habe).
Eine Sprache wird dann als 'einfach zu erlernen' empfunden, wenn sie
jemanden, der sonst keine kennt, nicht direkt mit Konzepten
überlastet, für die er/sie noch nicht mal Wörter weiß, weil sie der
Person auf ihrem bisherigen Lebensweg noch nie begegnet sind. Insofern hat
C hier gewisse Vorteile, denn die Grundlagen [der Sprache] können
schneller verstanden werden. Das ändert allerdings nichts daran, daß
'der theoretische Teil' trotzdem gebraucht wird/ sinnvoll ist und
dieselbe Person dann eben später vor dem Problem steht, verstehen zu
müssen, warum ein Programm, daß strukturell einem Kochrezept gleicht,
dh aus einer Folge von statements besteht, deren einzige
Binnenstruktur implizit in ihrer zeitliche Sequentialität liegt, bei
der Beschreibung komplexerer Systeme wegen der fehlenden Metahpern zum
Artikulieren von Komplexität schnell an seine Grenzen stößt.
Einfach zu erlernen ist zB auch Assembler, lediglich in vielen Fällen
nicht auch einfach zu benutzen.
Vinzent 'Gadget' Hoefler
>$ steak -d standartisiert
>--------------------------------------------------
> Deutsch -> English
>
>---------- Jetzt die Kontext-Eintraege ----------
> Deutsch -> English
> 1 ) nicht normgerecht, nicht standartisiert :== non-standard
*AAAAAAAAAAAAAAARGGG*
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
>>> "The Real OS/2 Guy" <os2...@pc-rosenau.de> writes:
>> > Blödsinn. Ein stream ist in Ein- und Ausgabe nunmal allem überlegen
>> > was irgendwaleche ominösen Devises machen - wenn man nicht
>> > stumpfsinnig und ohne Verstand rumhackt sondern weiß was man tut.
>>
>> Falls ich drei Zahlen zwischen zwei Programmen auf demselben Rechner
>> kommunizieren möchte, ist ein stream nicht nur nicht überlegen,
>> sondern sogar vollkommen ungeeignet. Oder falls ich mehr
>> Fehlerbehandlung brauche als 'ging gut' oder 'ging nicht gut' etc.
>
> Wie kommst Du auf dieses schmale Brett?
>
> send | receive
>
> verbindet 2 Enden eines strams - gemeinhin pipe genannt. Erzähl mir
> nicht daß das ungeeignet wäre oder Du wirst ausgelacht.
Ausgelacht werde ich ohnehin und es ist.
Markus Krebl
> Ist C eigentlich geeignet, um Anfängern das Programmieren
> beizubringen? Ist C leicht als erste Programmiersprache
> erlernbar oder zum Erlernen des Programmierens
> empfehlenswert?
Hallo !
Hab mal diesen Thread verfolgt und manchmal ist das in eine technischhe
Diskussion zwischen Leuten abgeglitten, die bereits programmieren
können. Ich denk Stefan hat da nicht mehr viel damit anfangen können,
weil ein Programmier-Anfänger einfach keine Ahnung von Streams und was
weiß ich noch alles hat. Grundsätzlich ist es ja um die Frage gegangen,
ob C für Anfänger eine gute Wahl ist.
Meiner Meinung nach ist C als Einstieg in die Programmierung nicht
unbedingt die beste Wahl, weil man schon bei verhältnismäßig einfachen
Sachen mit Arrays, Pointern etc. konfrontiert wird.
Als Beispiel wäre hier scanf zu nennen. Will man als Anfänger einen
String von der Tastatur einlesen, dann wird man gleich dazu noch mit
einem zusammengesetzten Datentyp (Array) konfrontiert. Der eine kommt
damit gut zurecht und der andere verzweifelt dabei schon am Anfang und
verliert den Spaß an der Sache. Vor allem wenn man mal wieder vergessen
hat, ein Byte mehr für '\0' zu reservieren.
Aus diesem Grund würde ich Turbo Pascal als sehr gute Einstiegssprache
vorschlagen. Ich persönlich habe mit Basic auf einem Commodore C16
angefangen, aber sobald ich meinen ersten PC hatte, freundete ich mich
schnell mit Turbo Pascal an und hatte sehr viel Spaß dabei.
Andererseits muß man sich natürlich den heutigen Stand in der Praxis
ansehen. Da bietet C natürlich ein Sprungbrett zu vielen anderen Sachen
(C++, Java).
Aber trotz allem, am besten ist es wirklich mit Assembler oder SML
anzufangen *ggg*
liebe Grüße,
Markus
M. Woelfel
> Ist C eigentlich geeignet, um Anfängern das Programmieren
> beizubringen?
Ja, am eigenem Leib gespuert und lieb gewonnen. Aber folgendes Zitat
aus: german.joelonsoftware.com/Articles/BacktoBasics.html hat auch
seine Berechtigung, bei aller Diskussion um sog. Hypes (und C):
"Dies sind lauter Dinge, die es nötig machen, über Bytes nachzudenken.
Sie beeinflussen die großen Entscheidungen die wir über Architektur
und Strategie treffen. Deshalb meine ich, dass Informatikstudenten in
den ersten Semestern bei den Anfängen beginnen sollten, mit C und bei
der CPU. Es widert mich geradezu an, dass in vielen Informatikursen
die Meinung vertreten wird, Java sei eine gute Anfängersprache, weil
sie so "einfach" ist, weil man nicht mit all diesem string und malloc
verwirrt wird und weil man statt dessen cooles objektorientiertes Zeug
lernen kann, das die großen Programe so schön modular macht. Da bahnt
sich ein pädagogisches Desaster an. Generationen von Abgängern werden
über uns kommen, die überall Schlemiel-der-Maler-Algorithmen schreiben
und es nicht mal merken werden, weil sie im Grunde keine Vorstellung
davon haben, dass Strings auf der Detailebene kompliziert sind, auch
wenn man es einem Perl script nicht ansieht. Wenn Sie jemandem etwas
von Grund auf beibringen möchten, dann müssen Sie ganz unten anfangen.
Es ist wie bei Karate Kid: Wachs drauf, Wachs runter, Wachs drauf,
Wachs runter. Mach' das drei Wochen lang. Danach ist es einfach, dem
anderen Kid den Kopf abzuschlagen."
> Ist C leicht als erste Programmiersprache
> erlernbar ...
wenn es die erste Sprache ist, fehlt sowieso der Vergleich (meine
erste Fremdsprache war auch der Horror) ;-)
> ... oder zum Erlernen des Programmierens empfehlenswert?
Zum Erlernen der allgm. Funktionsweisen von Computern und generellen
Sprachkonstrukten JA.
Deine Frage zielte aber nicht auf die Taetigkeit "Programmieren",
sondern die Faehigkeit "Algorithmieren". Dafuer wurden beliebig viele
einfachere Sprachen entworfen und sind hinreichend geeignet.
Gruss Martin
PS: Wer jetzt in C-Lobhudelei verfaellt, hat og. Link nicht gelesen
Rainer Weikusat
> Also muß man es sich eben irgendwie einreden, daß man erst dadurch
> richtig gut Java oder Perl schreiben kann.
'Richtig gut' ist weder bei Perl noch bei Java gefragt, auch wenn es
Leute gibt, die anderen mit Sicherheit das Gegenteil einreden können.
>>Deine Frage zielte aber nicht auf die Taetigkeit "Programmieren",
>>sondern die Faehigkeit "Algorithmieren".
>
> Diese Unterscheidung ist gut. Ich kannte den Begriff
> "Algorithmieren" bisher noch gar nicht.
Der heißt 'Algorithmisieren'.
Bodo Thiesen
>begin Bodo Thiesen:
>> *Mein* grep kann /keine/ Verzeichnisse einlesen, dieses muß alle
>> Namen von Datei, auf denen es operieren soll übergeben bekommen.
>> Ich weiß ja nicht, was Dein grep so alles macht und kann.
>
>Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu)
> ^^^
[ ] Jeder Mensch schreibt Usenet-Posts mit dem Selben System, mit dem er
arbeitet.
>$ man grep | col -b | sed -ne'/^ *-R/,/^$/p'
> -R, -r, --recursive
> Read all files under each directory, recursively;
> this is equivalent to the -d recurse option.
Ja, hier kann grep das auch. Es ist aber nichts, was grep können muß.
Bodo Thiesen
>Carsten Krueger <usenet23.e...@neverbox.com> writes:
>
>> Ich behaupte mal, daß man ein kleines Pascalprogramm was klingende
>> Variablen, etc. hat mit Englischkentnissen lesen kann.
^^^^^
>
>Das ist ein Irrtum. Ich sitze auf der Arbeit zT neben einem
>Fachinformatiker in Spe, der bessere 'Hello, World!'-Programme in
>Pascal schreiben soll (wofür auch immer) und die 'Geschwätzigkeit' der
^^^^^^^^^
>Sprache nervt ihn (dem Augenschein nach) und hilft ihm kein bißchen
>(hinzu kommt natürlich der übliche Irrglaube, jede Programmiersprache
>sei so aufwendig zu erlernen und nicht nur die erste und man folglich
>falls man 'die falsche' [also Pascal] gelernt habe, primär durch
>verschwendete Zeit sich selber einen Nachteil geschaffen habe).
Ja, Rainer, wo sind denn Deine Deutschkenntnisse hin?
PISA?
>Eine Sprache wird dann als 'einfach zu erlernen' empfunden, wenn sie
>jemanden, der sonst keine kennt, nicht direkt mit Konzepten
>überlastet, für die er/sie noch nicht mal Wörter weiß, weil sie der
>Person auf ihrem bisherigen Lebensweg noch nie begegnet sind. Insofern hat
>C hier gewisse Vorteile, denn die Grundlagen [der Sprache] können
>schneller verstanden werden.
als?
Ich glaube nicht, daß das wirklich stimmt, wenn man anfängt, das gegen
Basic zu vergleichen.
>Einfach zu erlernen ist zB auch Assembler, lediglich in vielen Fällen
>nicht auch einfach zu benutzen.
Man hat eine Sprache erst erlernt, wenn man sie anwenden kann. Oder was
meinst Du mit "erlernen"?
Rainer Weikusat
Sehe ich aus wie Du?
M. Woelfel
<weik...@students.uni-mainz.de> wrote:
>> Diese Unterscheidung ist gut. Ich kannte den Begriff
>> "Algorithmieren" bisher noch gar nicht.
>
>Der heißt 'Algorithmisieren'.
Woher weisst Du das? Google liefert mehr Treffer zu meinem
Wortfindungsversuch, was aber auch ein Anzeichen der PISA-Wahrheit
sein kann.
Martin
Claus Reibenstein
> On Thu, 04 Dec 2003 02:46:32 +0100, Rainer Weikusat
> <weik...@students.uni-mainz.de> wrote:
Zu lang.
>>> Ich kannte den Begriff
>>> "Algorithmieren" bisher noch gar nicht.
>>
>>Der heißt 'Algorithmisieren'.
>
> Woher weisst Du das?
Wahrscheinlich formatisiert er auch Disketten und editisiert Texte :-)
Woher er das weiß? Weiß er das überhaupt?
Gruß. Claus
Vinzent 'Gadget' Hoefler
>Wahrscheinlich formatisiert er auch Disketten und editisiert Texte :-)
Du editierst Texte?
Vinzent.
Heinrich Schramm
>Claus Reibenstein wrote:
>
>>Wahrscheinlich formatisiert er auch Disketten und editisiert Texte :-)
Es heißt ja auch alkoholisiert und nicht alkoholiert. ;-)
>Du editierst Texte?
Ja, hat sich nun mal so eingebürgert (auch wenn das furchtbar klingende
"edierst" vermutlich sprachlich korrekter wäre).
Gruß Heiner
Vinzent 'Gadget' Hoefler
>Vinzent 'Gadget' Hoefler <JeLlyFish...@gmx.net> wrote:
>
>>Du editierst Texte?
>
>Ja, hat sich nun mal so eingebürgert
Ich weiss.
>(auch wenn das furchtbar klingende
>"edierst" vermutlich sprachlich korrekter wäre).
Richtig. Darauf wollte ich hinaus.
Aber radieren ist durchaus noch aktuell; oder hat sich dafuer
mittlerweile auch schon raditieren eingebuergert? ;)
Vinzent.
Harald Wenninger
>>>Wahrscheinlich formatisiert er auch Disketten und editisiert Texte :-)
> Es heißt ja auch alkoholisiert und nicht alkoholiert. ;-)
>>Du editierst Texte?
> Ja, hat sich nun mal so eingebürgert (auch wenn das furchtbar klingende
> "edierst" vermutlich sprachlich korrekter wäre).
*argh*
"Edieren" und "editieren" sind zwei grundsätzlich verschiedene
Tätigkeiten.
Fup2 desd, da komplett OT.
Gruß,
Harald
M. Woelfel
>>>Der heißt 'Algorithmisieren'.
>>
>> Woher weisst Du das?
Ich hatte vorher Herrn Wahrig, Herrn Duden und div.
Fremdwoerterbuecher gefragt, bin aber leider ohne Antwort geblieben.
>Wahrscheinlich formatisiert er auch Disketten und editisiert Texte :-)
Er formalisiert Texte und eruiert Disketten ;-)
>Woher er das weiß? Weiß er das überhaupt?
Der Editisierer(TM) weiss nur, dass er logarithmiert, wenn er den
Logarithmus berechnet. Er schloss, geblendet durch die Aehnlichkeit
von Logarithmus und Algorithmus im Wortstamm, auf das Verb.
Nur weiss er es noch immer nicht :-(
Gruss Martin
Rainer Weikusat
>>Woher er das weiß? Weiß er das überhaupt?
>
> Der Editisierer(TM) weiss nur, dass er logarithmiert, wenn er den
> Logarithmus berechnet. Er schloss, geblendet durch die Aehnlichkeit
> von Logarithmus und Algorithmus im Wortstamm, auf das Verb.
>
> Nur weiss er es noch immer nicht :-(
'logarithmisieren' gibt es auch ;-).
Bodo Thiesen
Gib mir ein Bild, dann antworte ich Dir.
Aber zurück zum Thema. Behauptung von Carsten war, man könne Pascal-Programme
mit ausführlichen Namen wenn man über genügende Englischkenntnisse verfügt,
auch ohne Kenntniss der Sprache lesen und verstehen. Deine Gegenbehauptung
dazu war "Das ist ein Irrtum." mit einer Begründung, die sich auf das
*schreiben* von Programmen beruft.