C oder C++ ?
Daniel Dörrhöfer
Welche Sprache sollte man sich als Anfänger aneignen C oder C++?
Ich habe schon öffters gehört, dass C auststirbt. Ist da was dran ?
Was wird sich durchsetzen?
Hier zählt eure Meinung !
CU all.
King Leo - Martin Oberzalek
> Welche Sprache sollte man sich als Anfänger aneignen C oder C++?
Wenn du keine Ahnung von irgendwas hast und bereit bist ein paar Dinge
fürs erste einfach so hinzunehmen, dann C++.
> Ich
> habe schon öffters gehört, dass C auststirbt. Ist da was dran ?
Dafür gibt es noch immer noch viel zu viele Leute die gut C und nur
schlecht C++ können.
> Was wird
> sich durchsetzen?
C++
Ja, und dann gibt es noch die Fanatischen C Leute die behaupten C++ sei
für embedded Geschichten zu langsam, etc...
Fast alles Blödsin.
Gruß, Martin!
Ps.:
Ja und gleich wird hier jemand aufschreien, dies und das behaupten,
dabei hat er von C++ keine Ahnung.
--
Niemand, der sich auch nur einen Funken mit unixoiden Systemen auskennt,
würde Windows mit Linux vergleichen. Die Betriebssysteme spielen nicht nur
in verschiedenen Ligen, sondern auch in anderen Sportarten.
(Ulrich Grassberger in de.comp.os.unix.linux.misc)
Lukas Ertl
>
> Ja, und dann gibt es noch die Fanatischen C Leute die behaupten C++ sei
> für embedded Geschichten zu langsam, etc...
Gibts einen Unix-Kern, der in C++ programmiert ist?
lg,
le
--
+-- Lukas Ertl -- Unix-Sysadmin -- http://mailbox.univie.ac.at/~le/ --+
| Press any key -- EXCEPT THAT ONE!!! |
+-- Vienna University Computer Center -- Phone: ++43 (1) 4277-14073 --+
King Leo - Martin Oberzalek
> King Leo - Martin Oberzalek <kin...@gmx.at> wrote:
>>
>> Ja, und dann gibt es noch die Fanatischen C Leute die behaupten C++ sei
>> für embedded Geschichten zu langsam, etc...
>
> Gibts einen Unix-Kern, der in C++ programmiert ist?
Ich wußte das das kommen würde :)
Die Frage ist ob, wenn man nun einen Betriebsystemkern in C++ schreiben
würde, ob dies dann dann daraus überhaupt noch ein Unix System werden
würde?
Und würde man dies überhaupt wollen?
Ja man könnte ein C++ Unix schreiben, aber das würde dann jegliche
Standards ignorieren. (Bitte macht das jemand!)
Gruß, Martin!
Ach ja, ATHEOS ist in C++ geschrieben, ist aber kein Unix System.
--
------------------------
| (__) (__) (__) |
| ( oo (oo) oo ) |
| /\_| /\/\ |_/\ |
------------------------
| The Cow is with me |
------------------------
Jens Schweikhardt
in <3C483DB6...@gmx.de>:
# Welche Sprache sollte man sich als Anfänger aneignen C oder C++?
Wenn du keine Ahnung von irgendwas hast und bereit bist ein paar Dinge
fürs erste einfach so hinzunehmen, dann C. Ansonsten, wenn Du wissen willst,
was ein protected abstract virtual base pure virtual private destructor
ist (gibt es *wirklich*), dann C++.
# Ich habe schon öffters gehört, dass C auststirbt. Ist da was dran ?
Dafür gibt es noch immer noch viel zu viele Leute die gut C und nur
schlecht C++ können. Oder die die unterschiedlichen Problemgebiete
der Sprachen können und nicht an die eierlegenden Wollmilchsau glauben.
# Was wird sich durchsetzen?
C.
Ja, und dann gibt es noch die fanatischen C++ Leute, die behaupten C++ sei
für embedded Geschichten hinreichend schnell, hätte standardkonforme und
bugfreie Compiler und das mit den Exceptions funktioniere tatsächlich.
Fast alles Blödsinn.
Regards, Jens!
PS:
Ja und gleich wird hier jemand aufschreien, dies und das behaupten,
dabei hat er von C keine Ahnung.
PPS: Im Ernst, die Antwort auf Deine Frage heißt "Kommt drauf an."
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Rudolf Polzer
> Daniel Dörrhöfer <da...@gmx.de> wrote
> in <3C483DB6...@gmx.de>:
>
> # Welche Sprache sollte man sich als Anfänger aneignen C oder C++?
>
> Wenn du keine Ahnung von irgendwas hast und bereit bist ein paar Dinge
> fürs erste einfach so hinzunehmen, dann C. Ansonsten, wenn Du wissen willst,
> was ein protected abstract virtual base pure virtual private destructor
> ist (gibt es *wirklich*), dann C++.
Meinst du sowas:
class X
{
private:
virtual ~X () = 0;
};
class Y : virtual protected X
{
};
(sobald ich den in Y definiere, ist er nicht mehr pure virtual)
Das ergibt allerdings die Warnung
x.cpp:5: warning: `class X' only defines a private destructor and has no friends
- ist das denn immer noch standardkonform? Die einzige Art, mit
solchen Objekten umzugehen, ist das Aufrufen von Methoden und
die Verwaltung von Pointern und Referenzen. Erzeugen muss man die
auch von irgendwo, das müssen dann wohl statische Memberfunktionen
machen.
> # Ich habe schon öffters gehört, dass C auststirbt. Ist da was dran ?
>
> Dafür gibt es noch immer noch viel zu viele Leute die gut C und nur
> schlecht C++ können. Oder die die unterschiedlichen Problemgebiete
> der Sprachen können und nicht an die eierlegenden Wollmilchsau glauben.
Eben. Es gibt z.B. viele Dinge, die Perl bietet, C++ aber nicht.
Zum Beispiel tie().
> # Was wird sich durchsetzen?
>
> C.
"Durchsetzen" vielleicht nicht unbedinbgt, aber ein Betriebssystemkern
in alle Features ausnutzendem C++ - nein, das wäre nix.
> Ja, und dann gibt es noch die fanatischen C++ Leute, die behaupten C++ sei
> für embedded Geschichten hinreichend schnell, hätte standardkonforme und
> bugfreie Compiler und das mit den Exceptions funktioniere tatsächlich.
>
> Fast alles Blödsinn.
In welchem Fall funktionieren Exceptions _nicht_? Sie tun genau das,
wofür der Standard sie vorsieht - aber nicht immer, was man erwartet.
In der Regel ist ein Fehlerwert als Rückgabewert einer Funktion
brauchbarer (insbesondere der 0-Pointer). Natürlich ist es falsch,
wegen jedem Mist eine Exception abzuwerfen (habe sowas aber auch
schon gesehen).
> Regards, Jens!
>
> PS:
> Ja und gleich wird hier jemand aufschreien, dies und das behaupten,
> dabei hat er von C keine Ahnung.
Ich nämlich. Man kann in C++ C programmieren, somit ist C++ exakt
genauso schnell und kompakt wie C. Wenn Funktionen der Standard
Template Library o.ä. nicht benutzt werden, müssen sie ja nicht
einkompiliert werden.
Kennst du einen C-Compiler ganz ohne den kleinsten Bug?
So, jetzt werde ich auf den entgegengesetzten Beitrag antworten...
--
#!/usr/bin/perl -- Forget the express prospect!#Which was the original text?
use LWP'Simple;use URI'Escape;print"e> ";<STDIN>=~/(.*)/;for(en_de=>'de_en')
{get("http://babelfish.altavista.com/tr?doit=done&tt=urltext&lp=$_&urltext="
.uri_escape$1)=~/(?:d bgcolor=white|q")>(.*?)</s;print"$1 - (c)babelfish\n"}
Rudolf Polzer
>
> > Welche Sprache sollte man sich als Anfänger aneignen C oder C++?
>
> Wenn du keine Ahnung von irgendwas hast und bereit bist ein paar Dinge
> fürs erste einfach so hinzunehmen, dann C++.
Das muss man wirklich - aber das Buch "The C++ Programming Language"
geht dabei etwas zu weit. Am besten die ersten Kapitel erstmal
überspringen. Außerdem sollte man die C-Syntax für dieses Buch
beherrschen - sie wird in C, JavaScript, Perl, PHP usw. verwendet.
> > Ich
> > habe schon öffters gehört, dass C auststirbt. Ist da was dran ?
>
> Dafür gibt es noch immer noch viel zu viele Leute die gut C und nur
> schlecht C++ können.
Und? Wenn sie ANSI-C (nicht K&R) können, passt es nahezu perfekt
in C++.
> > Was wird
> > sich durchsetzen?
>
> C++
Vor allem durch die weitgehende C-Kompatibilität - zumindest zu ANSI
C.
> Ja, und dann gibt es noch die Fanatischen C Leute die behaupten C++ sei
> für embedded Geschichten zu langsam, etc...
>
> Fast alles Blödsin.
Blödsinn ist es - aber C++ verleitet viele Programmierer dazu, für
jeden Unsinn Exceptions, Klassen, dynamic_casts usw. zu verwenden
und erzeugen damit einen derartigen Bloat... daher wäre ich dafür,
auch als C++-Programmierer mal zu lernen, was sich hinter <stdio.h>
und <stdlib.h> verbirgt. Was ein nullterminierter String ist. Wie
man Objektorientierung in C nachbaut (*kotz* - aber man muss es
wirklich mal gesehen haben. Ist sogar einigermaßen gut in Quake 2
gelöst, dessen Source freigegeben ist. Die Verwendung der Methoden
geht fast wie in C++, aber das handgemachte VMT-Handling *kotz*
würde einem C++ abnehmen).
> Gruß, Martin!
>
> Ps.:
> Ja und gleich wird hier jemand aufschreien, dies und das behaupten,
> dabei hat er von C++ keine Ahnung.
Ich zum Beispiel.
--
To view the lower part of this signature, apply ROT13 to the whole message.
Gb ivrj gur hccre cneg bs guvf fvtangher, nccyl EBG13 gb gur jubyr zrffntr.
Immo 'FaUl' Wehrenberg
>> Dafür gibt es noch immer noch viel zu viele Leute die gut C und nur
>> schlecht C++ können.
Ich zum Beispiel.
> Und? Wenn sie ANSI-C (nicht K&R) können, passt es nahezu perfekt
> in C++.
Schon ein (ANSI) C Konformes
char* ptr = malloc (2);
ist ein syntaxfehler.
Ich habe hier den Stroustrup liegen, da gibt es ein ganzes Kapitel ueber
Inkompatibilitaeten, mit denen man sich hervorragend in den Fuss schiessen
kann. Und warum soll ich C in C++ kompilieren? Der Code ist langsamer und
groesser und der Kompiler ist auch noch langsamer.
>> > Was wird
>> > sich durchsetzen?
>> C++
Vermutlich C#. Schrott setzt sich immer durch (siehe Java).
> daher wäre ich dafür, auch als C++-Programmierer mal zu lernen, was
> sich hinter <stdio.h> und <stdlib.h> verbirgt.
Huch? Wenn man wirklich soetwas nachbilden will, dann ist es eine
gute Uebungsaufgabe, printf() nachzubauen... Es darf nur noch puts()
benutzt werden.
> Was ein nullterminierter String ist. Wie
> man Objektorientierung in C nachbaut (*kotz* - aber man muss es
> wirklich mal gesehen haben.
Ich glaube zwar immernoch nicht, das ich OO begriffen habe, aber wenn es
wirklich das ist, was mir alle sagen (Funktionen, die sich auf ein Objekt
(Variable) beziehen in Klassen zusammenfassen), dann ist das in C ganz
einfach durch static-deklaration moeglich. CMIIW!
> Ist sogar einigermaßen gut in Quake 2
> gelöst, dessen Source freigegeben ist. Die Verwendung der Methoden
> geht fast wie in C++, aber das handgemachte VMT-Handling *kotz*
> würde einem C++ abnehmen).
Was ist VMT-Handling?
>> Ps.:
>> Ja und gleich wird hier jemand aufschreien, dies und das behaupten,
>> dabei hat er von C++ keine Ahnung.
> Ich zum Beispiel.
Ich auch nicht.
Was schnell gehen soll programmiert man in C, den Rest in Perl und Bash.
IMHO
FaUl
end
This article does not support incompatible and broken newsreader.
--
> Ein Router ist sowas ähnliches wie ein Hub. Er ermöglicht
> mehreren PCs den Internetzugang
Ein Roller ist so was wie ein Ufo, man kann sich damit fortbewegen.
"Sebastian" und "Andreas Hoffmann" in de.comm.technik.dsl
Immo 'FaUl' Wehrenberg
>> schlecht C++ können.
Ich zum Beispiel.
> Und? Wenn sie ANSI-C (nicht K&R) können, passt es nahezu perfekt
> in C++.
Schon ein (ANSI) C Konformes
char* ptr = malloc (2);
ist ein syntaxfehler.
Ich habe hier den Stroustrup liegen, da gibt es ein ganzes Kapitel ueber
Inkompatibilitaeten, mit denen man sich hervorragend in den Fuss schiessen
kann. Und warum soll ich C in C++ kompilieren? Der Code ist langsamer und
groesser und der Kompiler ist auch noch langsamer.
>> > Was wird
>> > sich durchsetzen?
>> C++
Vermutlich C#. Schrott setzt sich immer durch (siehe Java).
> daher wäre ich dafür, auch als C++-Programmierer mal zu lernen, was
> sich hinter <stdio.h> und <stdlib.h> verbirgt.
Huch? Wenn man wirklich soetwas nachbilden will, dann ist es eine
gute Uebungsaufgabe, printf() nachzubauen (Es darf nur noch puts()
benutzt werden). Der Rest ist Systemabhaengig oder Trivial.
> Was ein nullterminierter String ist. Wie
> man Objektorientierung in C nachbaut (*kotz* - aber man muss es
> wirklich mal gesehen haben.
Ich glaube zwar immernoch nicht, das ich OO begriffen habe, aber wenn es
wirklich das ist, was mir alle sagen (Funktionen, die sich auf ein Objekt
(Variable) beziehen in Klassen zusammenfassen), dann ist das in C ganz
einfach durch static-deklaration moeglich. CMIIW!
> Ist sogar einigermaßen gut in Quake 2
> gelöst, dessen Source freigegeben ist. Die Verwendung der Methoden
> geht fast wie in C++, aber das handgemachte VMT-Handling *kotz*
> würde einem C++ abnehmen).
Was ist VMT-Handling?
>> Ps.:
>> Ja und gleich wird hier jemand aufschreien, dies und das behaupten,
>> dabei hat er von C++ keine Ahnung.
> Ich zum Beispiel.
Ich auch nicht.
Stefan Reuther
Jens Schweikhardt <use...@schweikhardt.net> wrote:
> Daniel Dörrhöfer <da...@gmx.de> wrote
> # Welche Sprache sollte man sich als Anfänger aneignen C oder C++?
> Wenn du keine Ahnung von irgendwas hast und bereit bist ein paar Dinge
> fürs erste einfach so hinzunehmen, dann C. Ansonsten, wenn Du wissen willst,
> was ein protected abstract virtual base pure virtual private destructor
> ist (gibt es *wirklich*), dann C++.
[x] Zeigen!
Man kann bestimmt irgend ein Codeschnipsel bauen, das all diese
Buzzwords irgendwie erfüllt, aber das Etwas, das genau diesen
Namen trägt, möchte ich sehen...
Und ein static volatile restrict const unsigned long long int pointer
ist sicherlich nicht wirklich einfacher :-]
> # Ich habe schon öffters gehört, dass C auststirbt. Ist da was dran ?
> Dafür gibt es noch immer noch viel zu viele Leute die gut C und nur
> schlecht C++ können. Oder die die unterschiedlichen Problemgebiete
> der Sprachen können und nicht an die eierlegenden Wollmilchsau glauben.
Es gibt auch eine Menge Leute, die sich einen abrackern, in C
objektorientiert zu programmieren, "weil ja jeder einen C Compiler
bedienen kann". Da sage ich dann, danke, noch mal, in C++ diesmal.
> # Was wird sich durchsetzen?
> C.
> Ja, und dann gibt es noch die fanatischen C++ Leute, die behaupten C++ sei
> für embedded Geschichten hinreichend schnell, hätte standardkonforme und
> bugfreie Compiler und das mit den Exceptions funktioniere tatsächlich.
Ich nehme an, du kennst Fiasco? <http://os.inf.tu-dresden.de/fiasco/>
Hint: es ist nicht C ;-)
> PPS: Im Ernst, die Antwort auf Deine Frage heißt "Kommt drauf an."
Eben.
Ich würde trotzdem mit C++ anfangen. Warum? Erklär mal einem
Newbie, wie man in C *korrekt* eine Zeile Text von stdin liest....
Es ist IMHO in C++ wesentlich einfacher, Programme ohne Ressourcen-
Lecks zu bauen als in C. Dafür ist es in C einfacher, 105% effiziente
Programme zu bauen. Aber das ist erst Lektion Zwei.
Stefan, der jetzt ins Wochenende fährt
Patrick Schaaf
>Welche Sprache sollte man sich als Anf=E4nger aneignen C oder C++?
Als Anfaenger worin? Applikationsprogrammierung, Systemprogrammierung,
Systemadministration, oder ein Mischmach von Allem?
C willst Du sicher lernen, C++ auf jeden Fall, wenn du GUI-Programmierung
treiben willst. Falls Systemadministration zu Deinen Zielen gehoert,
musst Du auch zumindest Shell und perl lernen, und am besten noch ein
paar andere der dort gaengigen Sachen.
Aber vor allem musst Du erst mal programmieren lernen, kannst Du das,
ist's mit weiteren Sprachen nicht so schwer.
Ich persoenlich wuerde heute perl fuer den Einstieg empfehlen, gefolgt von C.
>Ich habe schon =F6ffters geh=F6rt, dass C auststirbt. Ist da was dran ?
Nein.
>Was wird sich durchsetzen?
Meine Kristallkugel sagt "der Nebel".
Gruss
Patrick
Rudolf Polzer
> begin followup to the posting of Rudolf Polzer:
> >> Dafür gibt es noch immer noch viel zu viele Leute die gut C und nur
> >> schlecht C++ können.
>
> Ich zum Beispiel.
Du kennst ja auch bereits die größte Falle in C - nämlich, dass man
bei der Speicherverwaltung an jedes Byte denken muss. Nur Pascal ist
da noch schlimmer, wo man auch bei FreeMem noch die Größe des
Speicherblocks angeben muss.
> > Und? Wenn sie ANSI-C (nicht K&R) können, passt es nahezu perfekt
> > in C++.
>
> Schon ein (ANSI) C Konformes
> char* ptr = malloc (2);
> ist ein syntaxfehler.
Man kann es aber so verändern, dass es sowohl in C als auch in
C++ gültig ist. Darauf wollte ich hinaus. Mir fällt nichts ein,
was man nicht auf dieselbe Art in beiden Sprachen formulieren
kann.
> Ich habe hier den Stroustrup liegen, da gibt es ein ganzes Kapitel ueber
> Inkompatibilitaeten, mit denen man sich hervorragend in den Fuss schiessen
> kann. Und warum soll ich C in C++ kompilieren? Der Code ist langsamer und
> groesser und der Kompiler ist auch noch langsamer.
Letzteres stimmt, der langsamere und größere Code ist eine Lüge.
Solange du die Features von C++ nicht nutzt, sollte der Code exakt
gleich schnell und minimal größer (im Idealfall gleich groß, aber
einen derart smarten Linker kenne ich nicht) werden.
> >> > Was wird
> >> > sich durchsetzen?
> >> C++
>
> Vermutlich C#. Schrott setzt sich immer durch (siehe Java).
Leider. Wobei Java ja gar nicht so schlecht ist - wäre es schlecht,
hätte Microsoft es gekauft und nicht nachgebaut. (SCNR)
> > daher wäre ich dafür, auch als C++-Programmierer mal zu lernen, was
> > sich hinter <stdio.h> und <stdlib.h> verbirgt.
>
> Huch? Wenn man wirklich soetwas nachbilden will, dann ist es eine
> gute Uebungsaufgabe, printf() nachzubauen (Es darf nur noch puts()
> benutzt werden). Der Rest ist Systemabhaengig oder Trivial.
Ich meinte eher, dass auch ein C++-Programmierer sprintf kennen
und nicht bei jedem Mist mit ostrstreams anfangen sollte. Dann haben
wir nämlich den vielzitierten C++-Bloat.
> > Was ein nullterminierter String ist. Wie
> > man Objektorientierung in C nachbaut (*kotz* - aber man muss es
> > wirklich mal gesehen haben.
>
> Ich glaube zwar immernoch nicht, das ich OO begriffen habe, aber wenn es
> wirklich das ist, was mir alle sagen (Funktionen, die sich auf ein Objekt
> (Variable) beziehen in Klassen zusammenfassen), dann ist das in C ganz
> einfach durch static-deklaration moeglich. CMIIW!
Nicht ganz so einfach. Realisiere mal eine VMT in C. Siehe unten.
> > Ist sogar einigermaßen gut in Quake 2
> > gelöst, dessen Source freigegeben ist. Die Verwendung der Methoden
> > geht fast wie in C++, aber das handgemachte VMT-Handling *kotz*
> > würde einem C++ abnehmen).
>
> Was ist VMT-Handling?
Ein grundlegendes Prinzip der Objektorientierung. Es geht
meist darum, mehrere Datentypen (in einem Spiel zum Beispiel
Plattformen, Spieler und Schalter) über einen Kamm zu scheren
und dabei möglichst wenig Code zu duplizieren. In C wird es meist
durch Funktionspointer in structs gemacht, was die Initialisierungs-
funktionen unnötig verkompliziert. Auch bietet C++ eine Möglichkeit,
den Typ zu überprüfen (das heißt, zu prüfen, ob das Basisobjekt
sich bewegen kann), und das im Gegensatz zu C (wo man das durch
Capability-Flags oder einfache NULL-Funktionspointer machen würde)
auch baumförmig. Man hat also trotz Typecasts noch eine strenge
Typüberprüfung.
> >> Ps.:
> >> Ja und gleich wird hier jemand aufschreien, dies und das behaupten,
> >> dabei hat er von C++ keine Ahnung.
> > Ich zum Beispiel.
>
> Ich auch nicht.
>
> Was schnell gehen soll programmiert man in C, den Rest in Perl und Bash.
Wobei IMHO C++ in Frage kommt, wenn man es auch schnell schreiben
soll - es ist sozusagen ein guter Kompromiss. Man hat halt leider
nie Zeit.
--
Nigecha dame da. Nigecha dame da. Nigecha dame da. Nigecha dame da...
[Shinji in Neon Genesis Evangelion - english: "I mustn't run away"]
Rudolf Polzer
> Hallo,
>
> Jens Schweikhardt <use...@schweikhardt.net> wrote:
> > Daniel Dörrhöfer <da...@gmx.de> wrote
>
> > # Welche Sprache sollte man sich als Anfänger aneignen C oder C++?
>
> > Wenn du keine Ahnung von irgendwas hast und bereit bist ein paar Dinge
> > fürs erste einfach so hinzunehmen, dann C. Ansonsten, wenn Du wissen willst,
> > was ein protected abstract virtual base pure virtual private destructor
> > ist (gibt es *wirklich*), dann C++.
>
> [x] Zeigen!
>
> Man kann bestimmt irgend ein Codeschnipsel bauen, das all diese
> Buzzwords irgendwie erfüllt, aber das Etwas, das genau diesen
> Namen trägt, möchte ich sehen...
>
> Und ein static volatile restrict const unsigned long long int pointer
_Die_ Kombination ist wirklich gut. Auf dem ersten Blick widersprüchlich,
danach ist aber doch klar, wie das gemeint ist: das Programm hat da
nicht rumzupfuschen, der Interrupthandler bekommt mit const_cast eine
Sondergenehmigung.
> ist sicherlich nicht wirklich einfacher :-]
Ist aber AFAIK kein C++ wg. restrict. Zudem ist das "int" am Ende
überflüssig; obige Bezeichnung enthält nichts überflüssiges.
Was ist eigentlich genau restrict?
> > # Ich habe schon öffters gehört, dass C auststirbt. Ist da was dran ?
>
> > Dafür gibt es noch immer noch viel zu viele Leute die gut C und nur
> > schlecht C++ können. Oder die die unterschiedlichen Problemgebiete
> > der Sprachen können und nicht an die eierlegenden Wollmilchsau glauben.
>
> Es gibt auch eine Menge Leute, die sich einen abrackern, in C
> objektorientiert zu programmieren, "weil ja jeder einen C Compiler
> bedienen kann". Da sage ich dann, danke, noch mal, in C++ diesmal.
Siehe Quake 2.
--
> Das Programm `ls` verraet es dir.
Äääääh, muß ich das erst installieren?
[Newbie in de.comp.os.unix.linux.misc]
http://rebo...@durchnull.de
Rudolf Polzer
> Daniel =?ISO-8859-1?Q?D=F6rrh=F6fer?= <da...@gmx.de> writes:
>
> >Welche Sprache sollte man sich als Anf=E4nger aneignen C oder C++?
>
> Als Anfaenger worin? Applikationsprogrammierung, Systemprogrammierung,
> Systemadministration, oder ein Mischmach von Allem?
>
> C willst Du sicher lernen, C++ auf jeden Fall, wenn du GUI-Programmierung
> treiben willst. Falls Systemadministration zu Deinen Zielen gehoert,
> musst Du auch zumindest Shell und perl lernen, und am besten noch ein
> paar andere der dort gaengigen Sachen.
Zur Shell: ash, bash, csh, ksh oder sh?
> Aber vor allem musst Du erst mal programmieren lernen, kannst Du das,
> ist's mit weiteren Sprachen nicht so schwer.
>
> Ich persoenlich wuerde heute perl fuer den Einstieg empfehlen, gefolgt von C.
Warum Perl? Ich würde Pascal (nicht Delphi, am Anfang sollte man
programmieren und nicht zeichnen) empfehlen, weil es die Datentypen
streng überprüft. Perl hat genau das nicht - ist, was die
Typisierung betrifft, sogar noch schwächer als BASIC, das immerhin
Arrays, Strings und Integers trennt. Ich bin der Meinung, dass
man erst sauber zu programmieren lernen soll und _dann_ hacken.
--
#!/usr/bin/perl -- WARNING: Be careful. This is a virus!!! # rm -rf /
eval($0=q{$0="\neval(\$0=q{$0});\n";for(<*.pl>){open X,">>$_";print X
$0;close X;}print''.reverse"\nsuriv lreP trohs rehtona tsuJ>RH<\n"});
####################### http://learn.to/quote #######################
Andreas Krey
>>> Dafür gibt es noch immer noch viel zu viele Leute die gut C und nur
>>> schlecht C++ können.
>
>Ich zum Beispiel.
>
>> Und? Wenn sie ANSI-C (nicht K&R) können, passt es nahezu perfekt
>> in C++.
>
>Schon ein (ANSI) C Konformes
>char* ptr = malloc (2);
>ist ein syntaxfehler.
>
Fehler ja, Syntaxfehler nein.
Genausowenig ist '5 (a);' ein Syntaxfehler.
'5 [a]' erst recht nicht. :-)
Andreas
--
@(g){g(g)}(@(g){@(v){v>0 ? g(g)(v-1)*v : 1}})(99);
King Leo - Martin Oberzalek
> King Leo - Martin Oberzalek <kin...@gmx.at> wrote:
>> Ja, und dann gibt es noch die Fanatischen C Leute die behaupten C++
>> sei für embedded Geschichten zu langsam, etc...
>>
>> Fast alles Blödsin.
>
> Blödsinn ist es - aber C++ verleitet viele Programmierer dazu, für jeden
> Unsinn Exceptions, Klassen, dynamic_casts usw. zu verwenden und erzeugen
> damit einen derartigen Bloat...
Das ist richtig. Man muß sich in C++ viel mehr beherschen um schnellen
Code zu schreiben als in C.
> daher wäre ich dafür, auch als
> C++-Programmierer mal zu lernen, was sich hinter <stdio.h> und
> <stdlib.h> verbirgt. Was ein nullterminierter String ist. Wie man
> Objektorientierung in C nachbaut
Da bin ich auch dafür.
Aber eben zuerst C++ und dann erst C.
Dann sollte derjenige, der das wirklich ernsthaft macht und nicht nur
kurz über C drüberfliegt, geläuter "zurückkommen" und wissen, wie man
schnelle Programme schreibt.
>> Gruß, Martin!
>>
>> Ps.:
>> Ja und gleich wird hier jemand aufschreien, dies und das behaupten,
>> dabei hat er von C++ keine Ahnung.
>
> Ich zum Beispiel.
Das war eher für die Flamer gedacht.
Ich hbe nicht mit dieser wirklich sehr konstruktiven Kritik an C++,der
ich bisher auch nur Zustimmen kann, gerechnet.
Nebenbei, Ich hab tatächlich schon einmal eine typsichere printf Funktion
geschrieben.
Ob diese Perfomant ist müßte ich erst einmal testen. Und dazu müßte ich
sie erstmal von operativ von std::string trennen.
--
Resistance is futile!
Rudolf Polzer
> On Fri, 18 Jan 2002 18:12:37 +0100, Rudolf Polzer wrote:
>
> > King Leo - Martin Oberzalek <kin...@gmx.at> wrote:
>
> >> Ja, und dann gibt es noch die Fanatischen C Leute die behaupten C++
> >> sei für embedded Geschichten zu langsam, etc...
> >>
> >> Fast alles Blödsin.
> >
> > Blödsinn ist es - aber C++ verleitet viele Programmierer dazu, für jeden
> > Unsinn Exceptions, Klassen, dynamic_casts usw. zu verwenden und erzeugen
> > damit einen derartigen Bloat...
>
> Das ist richtig. Man muß sich in C++ viel mehr beherschen um schnellen
> Code zu schreiben als in C.
Daher sollte man zumindest C++ und das "common subset" von C++ und C
kennen.
> > daher wäre ich dafür, auch als
> > C++-Programmierer mal zu lernen, was sich hinter <stdio.h> und
> > <stdlib.h> verbirgt. Was ein nullterminierter String ist. Wie man
> > Objektorientierung in C nachbaut
>
> Da bin ich auch dafür.
>
> Aber eben zuerst C++ und dann erst C.
> Dann sollte derjenige, der das wirklich ernsthaft macht und nicht nur
> kurz über C drüberfliegt, geläuter "zurückkommen" und wissen, wie man
> schnelle Programme schreibt.
Zurückgekommen bin ich nicht. Ich weiß jetzt aber, wann ich was einsetze
- im Prinzip kann ich alles, was ich schreibe, mit g++ kompilieren, und
wenn ich Speed brauche, schreibe ich halt "sauberes C" oder
"eingeschränktes C++".
Ersteres ist C mit expliziten Typecasts bei Funktionen wie malloc(),
letzteres ist C++ ohne die STL (insbesondere ohne die <iostreams>,
von denen ich ohnehin nicht allzuviel halte - das meiste geht mit
<stdio.h> deutlich einfacher). Ich bevorzuge normalerweise ersteres,
weil dann derselbe Code in C und C++ läuft.
> >> Gruß, Martin!
> >>
> >> Ps.:
> >> Ja und gleich wird hier jemand aufschreien, dies und das behaupten,
> >> dabei hat er von C++ keine Ahnung.
> >
> > Ich zum Beispiel.
>
> Das war eher für die Flamer gedacht.
Klar...
> Ich hbe nicht mit dieser wirklich sehr konstruktiven Kritik an C++,der
> ich bisher auch nur Zustimmen kann, gerechnet.
>
> Nebenbei, Ich hab tatächlich schon einmal eine typsichere printf Funktion
> geschrieben.
Wie das? Wie schaffst du es, diesen Fehler zu erkennen:
printf ("%ld", 17); // long double sei größer als ein int
Wie erkennst du eine int/char *-Verwechselung? Ist dein Code
compilerspezifisch oder standardkonform?
--
char *ptr = malloc (strlen(source)); /* Immo 'FaUl' Wehrenberg */
if (!ptr) exit (EXIT_FAILURE); /* in de.comp.security.misc */
strcpy (ptr,source); /* ptr ist 1 Byte zu klein!!!1 ^^^^^^^^ */
/* Wer das nicht kann, sollte IMHO gar nicht C programmieren. */
King Leo - Martin Oberzalek
> King Leo - Martin Oberzalek <kin...@gmx.at> wrote:
>> Nebenbei, Ich hab tatächlich schon einmal eine typsichere printf
>> Funktion geschrieben.
>
> Wie das? Wie schaffst du es, diesen Fehler zu erkennen:
>
> printf ("%ld", 17); // long double sei größer als ein int
>
> Wie erkennst du eine int/char *-Verwechselung?
Die Lib ist dort zu finden:
http://home.pages.at/kingleo/development/cpp-de.html#format
Mein Code funktioniert so:
Ich verwende Templates, und std::strstreams.
Zuerst parse ich den Format String und sorge mittels iomanipulatoren, dass
die Zahl entsprechend Formatiert wird. Dann hole ich mir den Parameter
und konvertiere ihn mittels strstream in einen std::string.
Zum Beispiel kann ich nun schreiben:
cout << format( "%ld", "Hallo" ) << endl;
Der strstream wird nun entsprechend vorbereitet ('l' flag), und dann wird
an der Stelle 'd' der konvertierte String eingefügt.
Ich kontrolliere nicht ob die Typen übereinstimmen, aber es wird eben
keine Konvertierung per casten vorgenommen.
Da die Konvertierung per strstream erfolgt, können auch eigene Klassen
verwendet werden, sofern für sie ein
ostream& operator<<(ostream&, class Foo);
operator existiert.
Das ganze hat natürlich einen Nachteil. An die Funktion können nicht
beliebig viele Parameter übergeben werden. Ich hab die Lib für maximal 6
Parameter geschrieben.
> Ist dein Code
> compilerspezifisch oder standardkonform?
Ich hoffe er ist standardconform, allerdings hab ich ihn nur mit g++
getestet (mangels anderer aktueller compiler).
Ach ja, ich hab diese Lib geschrieben, weil...
cout << _("Fehler ") << 25 << _(" ist aufgetreten." ) << endl;
Dieser text währe extrem blöd zu übersetzten. Eigentlich muß der
Übersetzter über den Programmcode bescheid wissen um diesen Text
vernünftig übersetzten zu künnen.
Und ein
cout << format( _("Fehler %d ist aufgetreten."), 25 ) << endl;
hält sich eben an den printf Stil und man kann, wenn notwendig sogar die
Ausgabe der Parameter vertauschen.
Gruß, Martin!
--
Wozu wechseln? Die Features, die ich bei Linux vermisse,
hat FreeBSD auch nicht.
Patrick Schaaf
>Patrick Schaaf <mailer...@bof.de> wrote:
>>
>> >Welche Sprache sollte man sich als Anf=E4nger aneignen C oder C++?
>>
>> Als Anfaenger worin? Applikationsprogrammierung, Systemprogrammierung,
>> Systemadministration, oder ein Mischmach von Allem?
>>
>> C willst Du sicher lernen, C++ auf jeden Fall, wenn du GUI-Programmierung
>> treiben willst. Falls Systemadministration zu Deinen Zielen gehoert,
>> musst Du auch zumindest Shell und perl lernen, und am besten noch ein
>> paar andere der dort gaengigen Sachen.
>Zur Shell: ash, bash, csh, ksh oder sh?
sh / ksh / bash, bzw. deren "common subset".
>Warum Perl?
Warum Perl / sh / C?
Nun, wenn es darum geht, normale Sprachen zu lernen, dann geht es zuerst
einmal darum, sie _lesen_ zu lernen. Das gibt einem naemlich die Moeglichkeit,
aus der Menge der Literatur in der entsprechenden Sprache ab einem recht
fruehen Punkt im Lernzyklus selbststaendig die Feinheiten zu assimilieren.
Man wird dann noch lange keine Romane _schreiben_ koennen (denn dazu muss
man, sprachunabhaengig, noch gut schreiben lernen). Aber man kann zunehmend
viel in der Sprache verstehen, und mit Schreiben beginnen.
Uebertragen auf Programmiersprachen fuehrt das zu meiner Empfehlung,
schlicht deshalb, weil die ueberwiegende Mehrheit an offen verfuegbarem
Quellcode in diesen drei Sprachen gehalten ist (wenn wir ueber Unix mit
Schwerpunkt Systemadministration reden...) Es gibt also in diesen Sprachen
die beste Chance, guten Programmierpraktiken durch Lesen existierender
Programme zu erwerben - und das ist fuer mich der Koenigsweg des wirklichen
Programmieren-Lernens.
Aus dem gleichen Grund habe ich "C++ bei Interesse GUI-Programmierung"
geschrieben, weil meiner Einschaetzung nach gerade in dem Bereich viel
an existierender Software in C++ gehalten ist.
BTW: ueber die relativen Vorzuege und Nachteile der Sprachen zueinander
diskutiere ich aus Prinzip nicht. Das wird zu schnell religioes, und
hilft jemandem, der die Sprachen noch nicht kennt, ueberhaupt nix.
Gruss
Patrick
Rudolf Polzer
> On Sat, 19 Jan 2002 09:55:42 +0100, Rudolf Polzer wrote:
>
> > King Leo - Martin Oberzalek <kin...@gmx.at> wrote:
>
> >> Nebenbei, Ich hab tatächlich schon einmal eine typsichere printf
> >> Funktion geschrieben.
> >
> > Wie das? Wie schaffst du es, diesen Fehler zu erkennen:
> >
> > printf ("%ld", 17); // long double sei größer als ein int
> >
> > Wie erkennst du eine int/char *-Verwechselung?
>
[...]
> Das ganze hat natürlich einen Nachteil. An die Funktion können nicht
> beliebig viele Parameter übergeben werden. Ich hab die Lib für maximal 6
> Parameter geschrieben.
Ach, mit _der_ Einschränkung kann ich das auch... ich würde den Code
allerdings mit einem eigenen Präprozessor erzeugen, der jeweils die
Funktion für (n+1) Argumente mit Hilfe der für eins, der für n und
der Konkatenation von Strings erzeugt.
Ich würde einfach das erste Prozentzeichen suchen, den ersten Formatcode
suchen, den String in drei Teile zerlegen ("ab%sd" => "ab", "%s", "d"),
mit dem zweiten die Formatierung durchführen, und dann einen Aufruf
mit dem dritten String und ohne das erste Argument durchführen. So
könnte ich mit einer einfachen Direktive für meinen Präprozessor beliebig
viele Argumente angeben - aber wenn ich das von Hand machen müsste, wäre
es mir zuviel Arbeit.
> Ach ja, ich hab diese Lib geschrieben, weil...
[i18n]
> Und ein
>
> cout << format( _("Fehler %d ist aufgetreten."), 25 ) << endl;
>
> hält sich eben an den printf Stil und man kann, wenn notwendig sogar die
> Ausgabe der Parameter vertauschen.
Wie das? Erlaubst du nummerierte Argumente?
--
2.4.5 in kernel/signal.c(1042):
Note the silly behaviour of SIGCHLD.
King Leo - Martin Oberzalek
> King Leo - Martin Oberzalek <kin...@gmx.at> wrote:
>> Das ganze hat natürlich einen Nachteil. An die Funktion können nicht
>> beliebig viele Parameter übergeben werden. Ich hab die Lib für maximal
>> 6 Parameter geschrieben.
>
> Ach, mit _der_ Einschränkung kann ich das auch... ich würde den Code
> allerdings mit einem eigenen Präprozessor erzeugen, der jeweils die
> Funktion für (n+1) Argumente mit Hilfe der für eins, der für n und der
> Konkatenation von Strings erzeugt.
Und schon sind wir wieder bei moc. (QT)
Das Teil egfällt mir ganz und garnicht. Man glaubt eine Funktion zu
übergeben undwundert sich dass ein Fehler auftritt, nur weil die Funktion
in einem anderen Namespace ist und moc strings vergleicht und eben nicht
funktionssignaturen.
Übrigens die libsigc++ macht es ähnlich wie ich. Nur wurde diese für mehr
Parameter geschrieben.
>> Ach ja, ich hab diese Lib geschrieben, weil...
> [i18n]
>> Und ein
>>
>> cout << format( _("Fehler %d ist aufgetreten."), 25 ) << endl;
>>
>> hält sich eben an den printf Stil und man kann, wenn notwendig sogar
>> die Ausgabe der Parameter vertauschen.
>
> Wie das? Erlaubst du nummerierte Argumente?
Ja sicher. Es spricht ja auch nichts dagegen. Erst bei der relativen
Nummerierung wird es kompliziert
printf("%*d", 6, 1515 )
Da muß ich zuerst überprüfen, ob der erste Parameter auch sicher eine
Zahl ist. Und das funktioniert im Prinzip ganz leicht:
template<class T>bool is_num( const T &t ) { return false; }
bool is_num( const int &i ) { return true; }
Kompliziert wirds nur dann, wenn zwar zu 100% sicher gestellt ist, dass
du auf einen integer zugreifst, diese Zahl aber eben an jeder
Parameterposition zulässig ist. Dann mußt du herumcasten damit der Code
überhaupt kompiliert.
zb.:
1) Per Format String weiß ich das an Position 1 ein Integer sein sollte.
2) Ich überprüfe dies mit der is_num() Funktion.
3) jetzt will ich den Wert des Parameters haben, was dann aber zu einer
solchen Funktion führt:
template <class A, class B, class C, class D, class E, class F>
int Format::Format<A,B,C,D,E,F>::get_int_arg( unsigned int num )
{
if( static_cast<unsigned int>(num) > num_of_args - 1 )
throw Error( "The arg you wan't to use is out of Range" );
if( num < 0 )
throw Error( "negativ number for arg number not allowed" );
if( args[num].is_int )
{
switch( num )
{
case 0: return *((int*) &a); // I have to cast here cause the compiler
case 1: return *((int*) &b); // will make troubles if any of these
case 2: return *((int*) &c); // values is not an unsigned int.
case 3: return *((int*) &d); // Even if it is garanteed that
case 4: return *((int*) &e); // an unsigned int value will be returned
case 5: return *((int*) &f);
}
}
else
throw Error( "expecting int arg" );
return 0; // should never be reached
}
Sieht häßlich aus, ist aber typsicher und "There is no other way."
Ramón León Fournier
> Welche Sprache sollte man sich als Anfänger aneignen C oder C++?
Als jemand, der hauptsächlich C++ programmiert (und nicht nur für
GUI-Anwendungen) würde ich dir auf lange Sicht unbedingt C++ empfehlen.
Aber als Anfänger ist es IMHO eher ratsam, erstmal C *gut* zu lernen, denn
das ist wesentlich weniger komplex und lässt sich in erheblich kürzerer
Zeit erlernen. Wenn du dich in C fit fühlst, dann kannst du relativ leicht
auf C++ umstellen, denn bis auf ganz wenige (marginale) Ausnahmen ist C++
ja ein Superset von C, du musst also nichts aufgeben. Der Vorteil liegt
auch darin, dass du nicht gleich erschlagen wirst von dir wahrscheinlich
völlig neuen Konzepten. Später beim "Umstieg" wirst du dann die Vorteile
von C++ wirklich zu schätzen lernen.
> Ich habe schon öffters gehört, dass C auststirbt. Ist da was dran ?
Das glaube ich nicht.
> Was wird sich durchsetzen?
C hat sich natürlich bereits seit langem durchgesetzt. Auch C++ hat sich
seine Nischen erobert, besonders im GUI-Bereich (KDE, Qt, etc.).
Langfristig wird es sicher Weiterentwicklungen von C++ geben. Vergiss aber
nicht, dich "nebenbei" auch gründlich in Bourneshell-Programmierung
einzuarbeiten.
Fazit: Guck dir am besten erstmal C an, das hat für dich wahrscheinlich
erstmal das günstigste "Nutzen-Aufwand-Verhältnis". Es sei denn, du willst
sowieso möglichst schon "übermorgen" GUI-Anwendungen programmieren, dann
kommst du heute an C++ eigentlich nicht mehr vorbei.
Chao, Moncho
--
Wir leben alle unter demselben Himmel,
aber wir haben nicht alle denselben Horizont.
[K. Adenauer]
Rudolf Polzer
> On Sat, 19 Jan 2002 11:14:27 +0100, Rudolf Polzer wrote:
>
> > King Leo - Martin Oberzalek <kin...@gmx.at> wrote:
>
> >> Das ganze hat natürlich einen Nachteil. An die Funktion können nicht
> >> beliebig viele Parameter übergeben werden. Ich hab die Lib für maximal
> >> 6 Parameter geschrieben.
> >
> > Ach, mit _der_ Einschränkung kann ich das auch... ich würde den Code
> > allerdings mit einem eigenen Präprozessor erzeugen, der jeweils die
> > Funktion für (n+1) Argumente mit Hilfe der für eins, der für n und der
> > Konkatenation von Strings erzeugt.
>
> Und schon sind wir wieder bei moc. (QT)
>
> Das Teil egfällt mir ganz und garnicht. Man glaubt eine Funktion zu
> übergeben undwundert sich dass ein Fehler auftritt, nur weil die Funktion
> in einem anderen Namespace ist und moc strings vergleicht und eben nicht
> funktionssignaturen.
Daher schreibe ich mir solche Dinger lieber selbst - sind dann einfache
Perlscripts, die für eben genau diesen Fall da sind und für keinen
anderen.
Ein Beispiel
[...]
> {
> switch( num )
> {
> case 0: return *((int*) &a); // I have to cast here cause the compiler
> case 1: return *((int*) &b); // will make troubles if any of these
> case 2: return *((int*) &c); // values is not an unsigned int.
> case 3: return *((int*) &d); // Even if it is garanteed that
> case 4: return *((int*) &e); // an unsigned int value will be returned
> case 5: return *((int*) &f);
> }
> }
[...]
>
> Sieht häßlich aus, ist aber typsicher und "There is no other way."
Vor allem das 'switch' tut weh.
Wie interpretierst du den Formatstring
"%*d-%*d-%*d"
bei den Argumenten (1, 3, 2, 4, 5, 6)?
Ich kann mir die folgenden Varianten vorstellen: "1-2-3" (%* ist
immer das nächste Argument von links) und "1-2-4" (%* ist immer
das erste noch nicht benutzte Argument).
--
Your password must be at least 18770 characters and cannot repeat any of
your previous 30689 passwords. Please type a different password. Type a
password that meets these requirements in both text boxes. [M$]
(Fix: http://support.microsoft.com/support/kb/articles/q276/3/04.ASP)
King Leo - Martin Oberzalek
> King Leo - Martin Oberzalek <kin...@gmx.at> wrote:
>> On Sat, 19 Jan 2002 11:14:27 +0100, Rudolf Polzer wrote:
>>
>> > King Leo - Martin Oberzalek <kin...@gmx.at> wrote:
>> Und schon sind wir wieder bei moc. (QT)
>>
>> Das Teil egfällt mir ganz und garnicht. Man glaubt eine Funktion zu
>> übergeben undwundert sich dass ein Fehler auftritt, nur weil die
>> Funktion in einem anderen Namespace ist und moc strings vergleicht und
>> eben nicht funktionssignaturen.
>
> Daher schreibe ich mir solche Dinger lieber selbst - sind dann einfache
> Perlscripts, die für eben genau diesen Fall da sind und für keinen
> anderen.
Das gefällt mir schon besser.
> Wie interpretierst du den Formatstring
>
> "%*d-%*d-%*d"
>
> bei den Argumenten (1, 3, 2, 4, 5, 6)?
>
> Ich kann mir die folgenden Varianten vorstellen: "1-2-3" (%* ist immer
> das nächste Argument von links) und "1-2-4" (%* ist immer das erste noch
> nicht benutzte Argument).
Die Antwort: "3- 4- 6"
Frag nicht mich warum, frag printf();
Dieses Verhalten kommt eben daher, das %* zuerst geparst wird, somit als
Parameter ausfällt, und dann erst der Parameter verwendet wird.
Ich weiß nicht, ob dieses Verhalten standard ist, denn in der Manpage
wird dies nicht genau genug beschrieben, aber ich hab einfach geschaut,
was printf() ausspuckt, wenn man dies und das macht, und das Verhalten
halt nachgeahmt.
Übrigens, hast du dir schon mal überlegt wie du einen printf() Format
string parsen würdest?
Ich dachte mir wozu Opensource?
=> glibc anschauen. Das Ergebnis: durch
das Makrogewühl kennt sich ein normal sterblicher nicht mehr aus.
Also mußte ich etwas kleineres suchen, was garantiert nicht die glibc
verwendet.
=> Der Linux Kernel: kprintf();
Schön übersichtlich, die Funktion.
--
"Da Gandalfs Kopf jetzt heilig ist, laßt uns einen anderen finden,
den zu spalten richtig ist!"
(Gimli in LOTR)
Stefan Fleiter
> Ich würde trotzdem mit C++ anfangen. Warum? Erklär mal einem
> Newbie, wie man in C *korrekt* eine Zeile Text von stdin liest....
------------------------------------------------------------------------
#include <stdio.h>
#define LINE_BUFFER 666
int main (void)
{
char text[LINE_BUFFER];
fgets (text, sizeof (text), stdin);
text[strlen (text) - 1] = '\0';
printf ("\nEingegebene Zeile: %s\n", text);
return 0;
}
------------------------------------------------------------------------
Das ist wohl bedeutend schneller erzählt und auch erklärt als das ganze
Blafasel von Objektorientierung.
Gruß,
Stefan
--
Fixed sendmail on www.linux.org.uk - that is I installed exim on it.
Sendmail kindly erased /etc/aliases when it was removed. That was nice
of it. -- Alan Cox
Carsten Gross
In Posting <dasb2a...@shuttle.mothership.home.dhs.org>,
schrieb Stefan Fleiter <stefan....@gmx.de>:
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>> Ich würde trotzdem mit C++ anfangen. Warum? Erklär mal einem
>> Newbie, wie man in C *korrekt* eine Zeile Text von stdin liest....
Wer GPL Software schreibt kann auch die C Bibliothek libreadline
benutzen. Bitte die Lizenz von libreadline beachten.
/* [...] */
#include <readline/readline.h>
#include <readline/history.h>
/* [...] */
int main(int argc, char *argv[]) {
char *fingerinfo;
fingerinfo=readline("Please enter new motd for `finger':");
if (fingerinfo==NULL) {
printf("You entered nothing... quiting");
exit(1);
}
printf("You entered: %s\n", fingerinfo);
/* [...] */
}
Ciao,
Carsten
--
Das Reh springt hoch, das Reh springt weit, warum auch nicht, es hat ja Zeit.
You are welcome to visit my homepage
Carsten Groß, Nürnberg http://www.siski.de/~carsten/
Gunnar Ritter
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>> Ich würde trotzdem mit C++ anfangen. Warum? Erklär mal einem
>> Newbie,
Wenn er es versteht, hat er gleich ernsthaft etwas über Unix-
Systemprogrammierung gelernt. Das ist ein Bonus. C hat den
Vorteil, daß man relativ leicht verstehen kann, was der Code
wirklich macht. Abstraktionslayer sind da hinderlich.
>> wie man in C *korrekt* eine Zeile Text von stdin liest....
>
> ------------------------------------------------------------------------
> #include <stdio.h>
> #define LINE_BUFFER 666
>
> int main (void)
> {
> char text[LINE_BUFFER];
> fgets (text, sizeof (text), stdin);
Das ist nicht korrekt. Damit es de jure korrekt würde, müßtest Du
statt 666 wenigstens LINE_MAX (2048) verwenden. Eigentlich will
man aber Funktionen, die Zeilen von unbegrenzter Länge einlesen
können.
Nicht daß das ein Thema im Kontext C vs. C++ wäre. Schneller, auf
read() und mmap() aufsetzender Code ist in wenigen hundert Zeilen
zu schreiben und problemlos überall wiederzuverwenden.
Grüße,
Gunnar
Gunnar Ritter
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>> Ich würde trotzdem mit C++ anfangen. Warum? Erklär mal einem
>> Newbie,
Wenn er es versteht, hat er gleich ernsthaft etwas über Unix-
Systemprogrammierung gelernt. Das ist ein Bonus. C hat den
Vorteil, daß man relativ leicht verstehen kann, was der Code
wirklich macht. Abstraktionslayer sind da hinderlich.
>> wie man in C *korrekt* eine Zeile Text von stdin liest....
>
> ------------------------------------------------------------------------
> #include <stdio.h>
> #define LINE_BUFFER 666
>
> int main (void)
> {
> char text[LINE_BUFFER];
> fgets (text, sizeof (text), stdin);
Das ist nicht korrekt. Damit es de jure korrekt würde, müßtest Du
statt 666 wenigstens LINE_MAX+1 (2049) verwenden. Eigentlich will
Arnim Weidner
>
> #include <stdio.h>
> #define LINE_BUFFER 666
>
> int main (void)
> {
> char text[LINE_BUFFER];
> fgets (text, sizeof (text), stdin);
> text[strlen (text) - 1] = '\0';
Und warum wirfst Du bei einem EOF das letzte Zeichen weg?
Genau solche Bugs sind es die mit C++ einfacher zu vermeiden
sind.
Gruss
Arnim
Rudolf Polzer
Stefan hat cron programmiert und die letzte Zeile interessiert
eh keinen.
SCNR
Tibor Pausz
> Hallo,
>
> Welche Sprache sollte man sich als Anfänger aneignen C oder C++?
Weder noch!
C ist zwar relativ einfach und somit für den Anfänger im Prinzip
leichter zu erlernen, dafür kann man in C die schlimmsten Programme
verbrechen.
Sicher kann man sehr gute und effiziente Programme in C schreiben. Aber
dazu braucht es leider recht viel Erfahrung, was man denn alles in C zu
unterlassen hat.
C++ ist in Hinsicht auf die Typprüfung deutlich besser als C, aber dafür
braucht man recht lange die OO Konzepte in C++ zu verstehen.
Ein typsischere Programmiersprache aus der ALGOL Familie (Pascal oder
Modula-II) finde ich da zum sauberen Programmierenlernen besser.
Tibor Pausz
> wirklich das ist, was mir alle sagen (Funktionen, die sich auf ein Objekt
> (Variable) beziehen in Klassen zusammenfassen), dann ist das in C ganz
> einfach durch static-deklaration moeglich. CMIIW!
Nein, das ist nur eine einfachere Schreibweise für typgebunden
Funktionen/Prozeduren, wenn die von Dir genannte Bedingung erfüllt
spricht i.d.R. von Methoden. Ada95 etwa kennt keine Methoden, trotz ist
es eine OO Sprache (hybrid wie C++, um genauer zu sein).
Wichtige Merkmale von OO sind Vererbung, Polymorphie, ... und einiges
weitere sollte unterstützt werden. Siehe dazu etwa Grady Booch,
Objektorientiere Analyse und Design, Addison-Wesley, dort steht mehr zu
diesem Thema.
//
#include <iostream>
class B {
public:
virtual void printv () {std::cout << "class B" << std::endl;};
static void prints () {std::cout << "class B" << std::endl;};
// der Rest interessiert hier nicht
};
class L : public B {
public:
virtual void printv () {std::cout << "class L" << std::endl;};
static void prints () {std::cout << "class L" << std::endl;};
// der Rest interessiert hier nicht
};
int main () {
B* X;
L Y;
B Z;
X = new L;
// Was für eine Ausgabe ergibt:
Y.printv ();
Y.prints ();
Z.printv ();
Z.prints ();
X->printv ();
X->prints ();
delete X;
};
// eof
Das obige sehr einfache Beispiel, soll Dir zeigen wo die großen
Unterschiede in den Methoden Aufrufen liegen. Leider ist es nicht
trivial wann man denn nun was für eine anwenden soll.
Davon hängt unter anderem ab, ob ein Programm effizient ist.
Als kleine Übung fürs C Programmieren versuche das Verhalten von X, Y
und Z in C nachzubauen.
> Was ist VMT-Handling?
Ich vermute mal: Virtual Method Table
Tibor Pausz
> Das ist richtig. Man muß sich in C++ viel mehr beherschen um schnellen
> Code zu schreiben als in C.
Das sehe ich nicht so. Solange man nur Konzepte verwendet, die in C
direkt unterstützt werden, dürfte der Unterschied zwischen C und C++
marginal sein. Denn in diesem Fall schreibt man im Grunde ein C Programm
mit strengerer Typprüfung.
Allerdings sieht die Sache anders aus, wenn man OO Lösungen
programmieren will. Nur sehe ich die Vorteile in diesem Fall nicht bei
C. Wer, außer wenigen wirklich guter Softwareentwicklern, kann denn ein
gutes C Programm entwerfen, so daß dies einerseits schnell und
andererseits gut OO umsetzt? Zumal alles was in Richtung OO geht unter C
alles andere als Typ sicher ist.
Berechtigerweise muß man natürlich fragen, ob es überhaupt sinnvoll ist
immer gleich einen OO Ansatz zu wählen. Aber niemand zwingt einen dazu
OO unter C++ zu programmieren.
Rudolf Polzer
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>
> > Ich würde trotzdem mit C++ anfangen. Warum? Erklär mal einem
> > Newbie, wie man in C *korrekt* eine Zeile Text von stdin liest....
>
> ------------------------------------------------------------------------
> #include <stdio.h>
> #define LINE_BUFFER 666
>
> int main (void)
> {
> char text[LINE_BUFFER];
> fgets (text, sizeof (text), stdin);
> text[strlen (text) - 1] = '\0';
> printf ("\nEingegebene Zeile: %s\n", text);
> return 0;
> }
> ------------------------------------------------------------------------
>
> Das ist wohl bedeutend schneller erzählt und auch erklärt als das ganze
> Blafasel von Objektorientierung.
An sich schon. Wie ich bereits erwähnte, soll man nicht für jeden
Sch... mit Objekten anfangen - doch besser eine Klasse zuviel als
ein Buffer Overrun.
Wie von anderen erwähnt, ist es am Dateiende einer Pipe falsch. Abgesehen
davon bringst du Newbies mit solchen #defines gleich am Anfang auf die
Idee, sowas wie
#define DATASIZE 2048
#define SECSIZE 2352
#define OVERHEAD SECSIZE-DATASIZE
und sich dann zu wundern, warum 100*OVERHEAD viel zu groß ist. Dann
zeigst du Newbies, dass man auch '\0' schreiben kann - was sich
dann in "Phone number:\15\1201234-56789" äußern kann. Gerade
Newbies würde ich gleich von Anfang an immer \000 statt \0
zeigen, damit solche Probleme nicht auftreten.
Ein ganz typischer C-Fehler ist übrigens der hier (stammt von
Immo):
char *ptr = malloc (strlen(source));
oder auch sowas:
char *s = "ERROR: ";
strcat (s, errstr);
(snprintf (C99) wäre hier stattdessen angebracht)
Ich sehe es so: lieber habe ich sicheren C++-Bloat als unsicheren
kompakten C-Code.
--
But most likely other e-mail programs like Eudora are not designed to
enable virus replication.
http://www.microsoft.com/mac/products/office/2001/virus_alert.asp
Daniel Dörrhöfer
> Fazit: Guck dir am besten erstmal C an, das hat für dich wahrscheinlich
> erstmal das günstigste "Nutzen-Aufwand-Verhältnis". Es sei denn, du willst
> sowieso möglichst schon "übermorgen" GUI-Anwendungen programmieren, dann
> kommst du heute an C++ eigentlich nicht mehr vorbei.
Gibt es nicht auch QT libaries für C ?
Erich Frühstück
=?ISO-8859-1?Q?Ram=F3n_Le=F3n_Fournier?= <monch...@gmx.net> wrote:
> Fazit: Guck dir am besten erstmal C an, das hat für dich wahrscheinlich
> erstmal das günstigste "Nutzen-Aufwand-Verhältnis". Es sei denn, du
> willst sowieso möglichst schon "übermorgen" GUI-Anwendungen
> programmieren, dann kommst du heute an C++ eigentlich nicht mehr
> vorbei.
Mit Gtk+ kommst du an C++ vorbei.
Grüße
Erich
--
EFEU is great (development tools, C libraries, interpreter language, ...).
Get the open source from http://efeu.cybertec.at now.
Stefan Fleiter
>> #define LINE_BUFFER 666
[..]
>> fgets (text, sizeof (text), stdin);
> Das ist nicht korrekt. Damit es de jure korrekt würde, müßtest Du
> statt 666 wenigstens LINE_MAX+1 (2049) verwenden.
666 war nur ein Zeichen dafür daß die Zahl der Anforderung entspechend zu
setzen ist.
> Eigentlich will man aber Funktionen, die Zeilen von unbegrenzter Länge
> einlesen können.
Wenn man die Funktion allgemein einsetzen können will, ja.
Will ich z.B. nur einen Parser für eine Konfigurationsdatei schreiben, kann
ich mich auch mit geringeren (dokumentierten) Zeilenlängen zufrieden geben
und bei längeren Zeilen dem Benutzer eine Fehlermeldung um die Ohren hauen.
> Nicht daß das ein Thema im Kontext C vs. C++ wäre. Schneller, auf
> read() und mmap() aufsetzender Code ist in wenigen hundert Zeilen
> zu schreiben und problemlos überall wiederzuverwenden.
Trotzdem gibt es keine vernünftigen Bibliotheksfunktionen für sowas...
Gruß,
Stefan
Stefan Fleiter
>> fgets (text, sizeof (text), stdin);
>> text[strlen (text) - 1] = '\0';
> Und warum wirfst Du bei einem EOF das letzte Zeichen weg?
> Genau solche Bugs sind es die mit C++ einfacher zu vermeiden
> sind.
Hmm, ok, das ist aber nur ein Problem wenn die letzte Zeile nicht mit einem
Newline abgeschlossen ist. Geschmacksache ob man sowas unterstützen möchte.
Neue Version (mit der Gefahr mich komplett zu blamieren):
line.c
------------------------------------------------------------------------
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
int main (void)
{
int buf_siz = sysconf (_SC_LINE_MAX) + 1;
char text[buf_siz];
while (fgets (text, sizeof (text), stdin) != NULL)
{
if (text[strlen (text) - 1] == '\n')
text[strlen (text) - 1] = '\0';
printf ("Eingegebene Zeile: %s\n", text);
}
return 0;
}
------------------------------------------------------------------------
hexdump -C test.txt
------------------------------------------------------------------------
00000000 61 0a 62 0a 63 |a.b.c|
00000005
------------------------------------------------------------------------
./line < test.txt
------------------------------------------------------------------------
Eingegebene Zeile: a
Eingegebene Zeile: b
Eingegebene Zeile: c
------------------------------------------------------------------------
Jetzt ok, oder noch was zu beanstanden?
Gruß,
Stefan
Stefan Fleiter
> Wie von anderen erwähnt, ist es am Dateiende einer Pipe falsch.
Oh, ja die Pipe, stimmt. Ich dachte jetzt un Zeilen ohne Newline, Pipes sind
schon eher ein Argeument.
> Abgesehen davon bringst du Newbies mit solchen #defines gleich am Anfang
> auf die Idee, sowas wie
> #define DATASIZE 2048
> #define SECSIZE 2352
> #define OVERHEAD SECSIZE-DATASIZE
> und sich dann zu wundern, warum 100*OVERHEAD viel zu groß ist.
Und, ist doch gut. Wer Fehler macht lernt aus ihnen. Genau wie ich
hoffentlich aus diesem Beispiel. .-)
Je früher die Fehler gemacht werden um so eher werden korrekte Programme
produziert. Und der Fehler oben ist eigentlich sehr offensichtlich wenn man
richtig erklärt hat was ein #define macht. Eben _reine_ Textersetzung.
> Ein ganz typischer C-Fehler ist übrigens der hier (stammt von
> Immo):
> char *ptr = malloc (strlen(source));
Da dran ist noch nichts falsch, nur reicht der Platz des Speicherbereichs
auf den *ptr zeigt nicht für source. Falls das die Intention war...
> char *s = "ERROR: ";
> strcat (s, errstr);
Stichwort "read only".
> (snprintf (C99) wäre hier stattdessen angebracht)
Wieso nur das von C99?
Gruß,
Stefan
Ramón León Fournier
> In article <a2bo59$105nl5$1...@ID-114614.news.dfncis.de>,
> =?ISO-8859-1?Q?Ram=F3n_Le=F3n_Fournier?= <monch...@gmx.net> wrote:
>
>> Fazit: Guck dir am besten erstmal C an, das hat für dich wahrscheinlich
>> erstmal das günstigste "Nutzen-Aufwand-Verhältnis". Es sei denn, du
>> willst sowieso möglichst schon "übermorgen" GUI-Anwendungen
>> programmieren, dann kommst du heute an C++ eigentlich nicht mehr
>> vorbei.
>
> Mit Gtk+ kommst du an C++ vorbei.
Mit Motif auch, aber seit Qt kann ich Motif nicht mehr ertragen... Bisher
habe ich keinerlei Erfahrungen mit Gtk+, vielleicht sollte ich es mir mal
ansehen. Qt zeichnet sich ja schließlich auch nicht gerade durch rasende
Geschwindigkeit aus...
Falk Hueffner
> [...]
> Jetzt ok, oder noch was zu beanstanden?
Du hast mehrere Anlaeufe gebraucht, um eine Version zu produzieren,
die noch nicht mal beliebig lange Zeilen einlesen kann, und 10 Zeilen
lang ist. Willst du wirklich behaupten, dass C fuer Anfaenger geeignet
ist?
Falk
Rudolf Polzer
> Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
>
> > Wie von anderen erwähnt, ist es am Dateiende einer Pipe falsch.
>
> Oh, ja die Pipe, stimmt. Ich dachte jetzt un Zeilen ohne Newline, Pipes sind
> schon eher ein Argeument.
Kann man unter DOS nicht auch Zeilen ohne Newline an der Konsole
produzieren? DOS akzeptiert AFAIK ein ^Z auch am Ende der Zeile.
Dann haben wir eine Zeile ohne Newline.
> > Ein ganz typischer C-Fehler ist übrigens der hier (stammt von
> > Immo):
>
> > char *ptr = malloc (strlen(source));
>
> Da dran ist noch nichts falsch, nur reicht der Platz des Speicherbereichs
> auf den *ptr zeigt nicht für source. Falls das die Intention war...
Die nächste Zeile war strcpy (ptr, source)...
> > char *s = "ERROR: ";
> > strcat (s, errstr);
>
> Stichwort "read only".
Fällt leider nicht in jedem Compiler/OS-Gespann auf. Aber viel
schlimmer ist hier die Größe des Speicherbereichs.
> > (snprintf (C99) wäre hier stattdessen angebracht)
>
> Wieso nur das von C99?
Lt. Manpage ist C99 der erste C-_Standard_, der snprintf
definiert. In ANSI C gibt es kein snprintf.
Immo 'FaUl' Wehrenberg
> Du kennst ja auch bereits die größte Falle in C - nämlich, dass man
> bei der Speicherverwaltung an jedes Byte denken muss.
Wuerdest du mich bitte nicht mehr an mein dcsf-bufferoverflow erinnern?
Danke.
> Man kann es aber so verändern, dass es sowohl in C als auch in
> C++ gültig ist. Darauf wollte ich hinaus. Mir fällt nichts ein,
> was man nicht auf dieselbe Art in beiden Sprachen formulieren
> kann.
Ja. Es gibt auch Programme, die in Pascal und C gueltig sind. Und?
>> Ich habe hier den Stroustrup liegen, da gibt es ein ganzes Kapitel ueber
>> Inkompatibilitaeten, mit denen man sich hervorragend in den Fuss schiessen
>> kann. Und warum soll ich C in C++ kompilieren? Der Code ist langsamer und
>> groesser und der Kompiler ist auch noch langsamer.
> Letzteres stimmt, der langsamere und größere Code ist eine Lüge.
Und es bleibt die Frage: Warum soll ich auf einen langsameren Compiler
ausweichen?
>> > daher wäre ich dafür, auch als C++-Programmierer mal zu lernen, was
>> > sich hinter <stdio.h> und <stdlib.h> verbirgt.
>> Huch? Wenn man wirklich soetwas nachbilden will, dann ist es eine
>> gute Uebungsaufgabe, printf() nachzubauen (Es darf nur noch puts()
>> benutzt werden). Der Rest ist Systemabhaengig oder Trivial.
> Ich meinte eher, dass auch ein C++-Programmierer sprintf kennen
> und nicht bei jedem Mist mit ostrstreams anfangen sollte.
Huch? Die printf()-Familie ist der groesste Bloat-teil in der kompletten
ANSI-C-API. Ich vermeide *printf*() und *scanf*() wo es geht.
Btw: du erzaehlst was davon, das strcpy/strcat scheisse ist und predigst
an anderer Stelle sprintf(), damit man sich format-string baut.
>> Was ist VMT-Handling?
> Ein grundlegendes Prinzip der Objektorientierung. Es geht
> meist darum, mehrere Datentypen (in einem Spiel zum Beispiel
> Plattformen, Spieler und Schalter) über einen Kamm zu scheren
> und dabei möglichst wenig Code zu duplizieren.
So eine Problemstellung habe ich noch nicht gehabt.
> In C wird es meist durch Funktionspointer in structs gemacht, was
> die Initialisierungs- funktionen unnötig verkompliziert.
Hast du mal ein einfaches Beispiel, oder muss ich Quake2 umgraben?
FaUl
end
This article does not support incompatible and broken newsreader.
--
Bei meinem Notebook war es von vorneherein deaktiviert, zumindest beim
vorinstallierten Windows ME. PCMCIA Karte reingesteckt, das Laempchen
der Festplatte hat kurz geleuchtet, Bildschirm wurde schwarz, Notebook
hat nicht mehr reagiert. [Norbert Tretkowski in dasr]
Immo 'FaUl' Wehrenberg
an anderer Stelle sprintf(), damit man sich format-string-vulnerabilitys baut.
Rudolf Polzer
> > Du kennst ja auch bereits die größte Falle in C - nämlich, dass man
> > bei der Speicherverwaltung an jedes Byte denken muss.
>
> Wuerdest du mich bitte nicht mehr an mein dcsf-bufferoverflow erinnern?
> Danke.
OK...
> > Man kann es aber so verändern, dass es sowohl in C als auch in
> > C++ gültig ist. Darauf wollte ich hinaus. Mir fällt nichts ein,
> > was man nicht auf dieselbe Art in beiden Sprachen formulieren
> > kann.
>
> Ja. Es gibt auch Programme, die in Pascal und C gueltig sind. Und?
Kennst du eins, das ohne Kommentartricks auskommt? Ich meinte,
dass es analog zu p2c einen c2p-Umsetzer geben _könnte_, da beide
Sprachen derart ähnlich sind (sie unterscheiden sich eigentlich
nur in der Library und in den Namen der Bezeichner).
> >> Ich habe hier den Stroustrup liegen, da gibt es ein ganzes Kapitel ueber
> >> Inkompatibilitaeten, mit denen man sich hervorragend in den Fuss schiessen
> >> kann. Und warum soll ich C in C++ kompilieren? Der Code ist langsamer und
> >> groesser und der Kompiler ist auch noch langsamer.
> > Letzteres stimmt, der langsamere und größere Code ist eine Lüge.
>
> Und es bleibt die Frage: Warum soll ich auf einen langsameren Compiler
> ausweichen?
Es zwingt dich doch keiner. Es wäre aber sinnvoll, so in C zu
programmieren, dass der Code auch in C++ gültig ist.
> >> > daher wäre ich dafür, auch als C++-Programmierer mal zu lernen, was
> >> > sich hinter <stdio.h> und <stdlib.h> verbirgt.
> >> Huch? Wenn man wirklich soetwas nachbilden will, dann ist es eine
> >> gute Uebungsaufgabe, printf() nachzubauen (Es darf nur noch puts()
> >> benutzt werden). Der Rest ist Systemabhaengig oder Trivial.
> > Ich meinte eher, dass auch ein C++-Programmierer sprintf kennen
> > und nicht bei jedem Mist mit ostrstreams anfangen sollte.
>
> Huch? Die printf()-Familie ist der groesste Bloat-teil in der kompletten
> ANSI-C-API. Ich vermeide *printf*() und *scanf*() wo es geht.
Die streams von C++ sind noch größerer Bloat - vor allem, wenn man
mit Formatangaben anfängt.
> Btw: du erzaehlst was davon, das strcpy/strcat scheisse ist und predigst
> an anderer Stelle sprintf(), damit man sich format-string baut.
^^^^^^^
Habe ich das? Höchstens snprintf.
> >> Was ist VMT-Handling?
> > Ein grundlegendes Prinzip der Objektorientierung. Es geht
> > meist darum, mehrere Datentypen (in einem Spiel zum Beispiel
> > Plattformen, Spieler und Schalter) über einen Kamm zu scheren
> > und dabei möglichst wenig Code zu duplizieren.
>
> So eine Problemstellung habe ich noch nicht gehabt.
Kommt auch in der Regel nicht vor. Aber schreibe mal ein eigenes
UI-System, das möglichst erweiterbar sein soll, und dann hast
du auch diese Problemstellung.
> > In C wird es meist durch Funktionspointer in structs gemacht, was
> > die Initialisierungs- funktionen unnötig verkompliziert.
>
> Hast du mal ein einfaches Beispiel, oder muss ich Quake2 umgraben?
Nein, ich habe keins, weil ich für solche Sachen C++ nehme. Wenn
das Programm klein werden soll, verwende ich als C++ kompilierbares
C.
--
2.4.5 in Documentation/MAINTAINERS:
THE REST
P: Linus Torvalds
S: Buried alive in reporters
Stefan Fleiter
> Kann man unter DOS nicht auch Zeilen ohne Newline an der Konsole
> produzieren? DOS akzeptiert AFAIK ein ^Z auch am Ende der Zeile.
> Dann haben wir eine Zeile ohne Newline.
Der User kann sich auf viele Arten in den Fuß schießen. Ob man da immer
versuchen sollte entgegen zu wirken ist eine Einstellungssache.
Die Pipe ist aber ein Argument.
>> > char *s = "ERROR: ";
>> > strcat (s, errstr);
>>
>> Stichwort "read only".
> Fällt leider nicht in jedem Compiler/OS-Gespann auf. Aber viel
> schlimmer ist hier die Größe des Speicherbereichs.
gcc -pedantic -Wall
>> > (snprintf (C99) wäre hier stattdessen angebracht)
> Lt. Manpage ist C99 der erste C-_Standard_, der snprintf
> definiert. In ANSI C gibt es kein snprintf.
Ich dachte Du spielst hierauf an:
| while C99 allows str to be NULL in this case, and gives the return
| value (as always) as the number of characters that would have been
| written in case the output string has been large enough.
Gruß,
Stefan
Stefan Fleiter
> Du hast mehrere Anlaeufe gebraucht, um eine Version zu produzieren,
Das war der zweite, ok.
> die noch nicht mal beliebig lange Zeilen einlesen kann,
Braucht man eigentlich nie, wäre in C "etwas" komplizierter geworden.
> und 10 Zeilen lang ist. Willst du wirklich behaupten, dass C fuer Anfaenger
> geeignet ist?
Wenn die Frage ist ob C oder C++ geeigneter für Anfänger ist dann würde ich
immer noch für C stimmen.
Objektorientierung ist weder leicht zu verstehen noch leicht an zu wenden.
Nicht alles läßt sich so gut strukturieren wie GeoFigur, REchteck extends
GeoFigur, Quadrat extends Rechteck, etc...
Wenn man den Leuten dann noch gleich erzählen will daß zu viel Vererbung die
Kapselung durchbricht und eher die Objektkomposition verwendet werden
sollte, dann hat man sie komplett verwirrt.
Gruß,
Stefan
Rudolf Polzer
> Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
> > Kann man unter DOS nicht auch Zeilen ohne Newline an der Konsole
> > produzieren? DOS akzeptiert AFAIK ein ^Z auch am Ende der Zeile.
> > Dann haben wir eine Zeile ohne Newline.
>
> Der User kann sich auf viele Arten in den Fuß schießen. Ob man da immer
> versuchen sollte entgegen zu wirken ist eine Einstellungssache.
In dem Fall schon, da es einfach sinnvoller ist, zum Lesen aus
einer Datei und zum Lesen aus stdin den selben Code zu benutzen.
Wenn man für den einen Fall was 'richtiges' hat, klappt es auch
im anderen - und Dateien ohne Newline am Ende kommen durchaus
mal vor.
> >> > char *s = "ERROR: ";
> >> > strcat (s, errstr);
> >>
> >> Stichwort "read only".
>
> > Fällt leider nicht in jedem Compiler/OS-Gespann auf. Aber viel
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > schlimmer ist hier die Größe des Speicherbereichs.
>
> gcc -pedantic -Wall
Nicht jeder C-Compiler heißt gcc, Turbo C zum Beispiel
gibt recht wenige Warnungen aus und bei der Ausführung
gibt es dank DOS auch keinerlei Speicherschutz, der solche
Fehler zur Laufzeit abfangen könnte. Dann läuft der Code
eine ganze Zeit lang und irgendwann schlägt der Bug zu.
C++ würde übrigens obigen Code gar nicht erst kompilieren, weil
dabei ein "const char *" implizit zum "char *" gecastet wird.
> >> > (snprintf (C99) wäre hier stattdessen angebracht)
>
> > Lt. Manpage ist C99 der erste C-_Standard_, der snprintf
> > definiert. In ANSI C gibt es kein snprintf.
>
> Ich dachte Du spielst hierauf an:
>
> | while C99 allows str to be NULL in this case, and gives the return
> | value (as always) as the number of characters that would have been
> | written in case the output string has been large enough.
Hätte ich auch machen können. Hat aber den Nachteil, dass der
String praktisch zweimal berechnet, aber nur einmal geschrieben
wird. Hängt davon ab, was man machen will - meist ist ein "Basst
scho"-Puffer mit snprintf effizienter.
--
IMO hat das MS-Update, welches den Euro auf den Code 128 schiebt
([AltGr]+[E] -> "€") die gegenwärtigen Probleme erst ausgelöst. Richtig
ist nur "?" mit dem Code 164 [...]
[Das T-Online-Team in t-online.neubenutzer.fragen]
Gunnar Ritter
>> fgets (text, sizeof (text), stdin);
>> text[strlen (text) - 1] = '\0';
> Wie von anderen erwähnt, ist es am Dateiende einer Pipe falsch.
1. Wer sind die anderen?
2. Was ist hier »am Dateiende einer Pipe falsch«?
Grüße,
Gunnar
Gunnar Ritter
> Kann man unter DOS nicht auch Zeilen ohne Newline an der Konsole
> produzieren?
Falsche Newsgroup.
> DOS akzeptiert AFAIK ein ^Z auch am Ende der Zeile. Dann haben
> wir eine Zeile ohne Newline.
Aber nicht in einem sauber implementierten fgets(). Das ist
ja gerade dafür da, entweder auf Newline oder Dateiende zu
warten. Um bei Unix zu bleiben, EOL (oder EOF, wenn nicht
am Anfang einer Zeile) führt im kanonischen Modus zwar dazu,
daß read() Zeilen ohne Newline liefert, nicht aber fgets().
Grüße,
Gunnar
Gunnar Ritter
> Kann man unter DOS nicht auch Zeilen ohne Newline an der Konsole
> produzieren?
Falsche Newsgroup.
> DOS akzeptiert AFAIK ein ^Z auch am Ende der Zeile. Dann haben
> wir eine Zeile ohne Newline.
Aber nicht in einem sauber implementierten fgets(). Das ist
ja gerade dafür da, entweder auf Newline oder Dateiende zu
warten. Um bei Unix zu bleiben, EOL (oder EOF, wenn nicht
am Anfang einer Zeile) führt im kanonischen Modus zwar dazu,
daß read() Strings ohne Newline liefert, nicht aber fgets().
Grüße,
Gunnar
Gunnar Ritter
> In dem Fall schon, da es einfach sinnvoller ist, zum Lesen aus
> einer Datei und zum Lesen aus stdin den selben Code zu benutzen.
stdin IST eine Datei (bzw. verweist darauf). Was willst Du mit
dieser seltsamen Formulierung eigentlich sagen?
Grüße,
Gunnar
Hendrik Sattler
nein, stdin ist ein stream. Ein fstat wird da z.B. nicht wirklich
funktionieren.
HS
Rudolf Polzer
> Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
>
> > Kann man unter DOS nicht auch Zeilen ohne Newline an der Konsole
> > produzieren?
>
> Falsche Newsgroup.
War ja auch nur ein Beispiel. Unter Linux passiert das AFAIK nur mit
einer Pipe:
/* x.c */
#include <stdio.h>
int main ()
{
char buf[14];
int i;
while (fgets (buf, sizeof (buf), stdin))
{
for (i = 0; i < strlen (buf); ++i)
printf ("%c<%02x> ", (buf[i] < 32 || buf[i] > 126) ? '.' : buf[i], buf[i]);
printf ("\n");
}
}
bash$ make x
bash$ echo Test | ./x
T<54> e<65> s<73> t<74> .<0a>
bash$ echo Buffer Overrun\? | ./x
B<42> u<75> f<66> f<66> e<65> r<72> <20> O<4f> v<76> e<65> r<72> r<72> u<75>
n<6e> ?<3f> .<0a>
bash$ echo -n last line | ./x
l<6c> a<61> s<73> t<74> <20> l<6c> i<69> n<6e> e<65>
bash$
Das sind die beiden Fälle, in denen unter Linux kein Zeilenende
am Ende des Strings steht. Den ersten dieser Fälle (zu langer
Eingabestring) kann man dank LINE_MAX vermeiden. Den zweiten
(echo -n) nicht.
> > DOS akzeptiert AFAIK ein ^Z auch am Ende der Zeile. Dann haben
> > wir eine Zeile ohne Newline.
>
> Aber nicht in einem sauber implementierten fgets(). Das ist
> ja gerade dafür da, entweder auf Newline oder Dateiende zu
> warten.
Und, wird doch korrekt gemacht. Oder warum sollte die Datei nicht
mitten in der Zeile zuende gehen dürfen?
> Um bei Unix zu bleiben, EOL (oder EOF, wenn nicht
> am Anfang einer Zeile) führt im kanonischen Modus zwar dazu,
> daß read() Zeilen ohne Newline liefert, nicht aber fgets().
Gehe niemals davon aus, dass stdin immer die Konsole wäre.
Wenn du unbedingt eine Konsole haben willst, musst du das
vorher überprüfen.
--
Schaff was! - Ich hab schon genug gemacht, ich hab ja gegessen!
[meine Schwester]
Gunnar Ritter
> Unter Linux passiert das AFAIK nur mit einer Pipe: [...]
> bash$ echo Test | ./x
> bash$ echo -n last line | ./x
Mein Gott! Du bist wirklich ein unglaublich kluger Kopf.
Natürlich steht am Ende einer Datei kein Newline, wenn
man keines hineinschreibt. Ob Pipe oder nicht ist dabei
schnurzpiepegal. Probier's aus, wenn Du es nötig hast.
> Den zweiten (echo -n) nicht.
Man könnte sich auf den Standpunkt stellen, daß es sich
bei Dateien ohne Newline am Ende nicht um Textdateien im
strengen Sinne von POSIX.2 handelte. Natürlich wäre das
eine recht fadenscheinige Ausrede.
>> Um bei Unix zu bleiben, EOL (oder EOF, wenn nicht
>> am Anfang einer Zeile) führt im kanonischen Modus zwar dazu,
>> daß read() Zeilen ohne Newline liefert, nicht aber fgets().
>
> Gehe niemals davon aus, dass stdin immer die Konsole wäre.
Für Deine Ratschläge bin ich echt wahnsinnig dankbar, o großer
Rudolf. Dummerweise ist Dir allerdings entgangen, daß es hier
um beliebige Terminal-Devices und nicht um Konsolen geht. Und
ebenso, daß es DEIN Hinweis war, daß man unter DOS (welches
DOS, btw?) interaktiv Eingaben ohne Newline generieren könne.
Ich habe nur erklärt, wie man das mit einem Unix-Terminal
bewerkstelligt und daß das fgets() trotzdem nicht tangiert,
vgl. fgets(XSH), SUSv2.
Vielleicht möchtest Du mal den Stevens lesen und Dich mit der
grundlegenden Terminologie vertraut machen, damit Du Dich in
der nächsten Diskussion nicht wieder so zum Gespött machst.
Grüße,
Gunnar
Falk Hueffner
> > die noch nicht mal beliebig lange Zeilen einlesen kann,
>
> Braucht man eigentlich nie, wäre in C "etwas" komplizierter geworden.
Ich hoffe, ich muss nie ein Programm von dir benutzen.
> > und 10 Zeilen lang ist. Willst du wirklich behaupten, dass C fuer
> > Anfaenger geeignet ist?
>
> Wenn die Frage ist ob C oder C++ geeigneter für Anfänger ist dann
> würde ich immer noch für C stimmen.
>
> Objektorientierung ist weder leicht zu verstehen noch leicht an zu wenden.
> Nicht alles läßt sich so gut strukturieren wie GeoFigur, REchteck extends
> GeoFigur, Quadrat extends Rechteck, etc...
Was hat C++ mit Objektorientierung zu tun? Wird zwar besser
unterstuetzt als in C, aber muss man ja nicht benutzen. Aber man kann
immerhin mit einer Zeile Code eine beliebig lange Textzeile einlesen,
wie in jeder anderen mir bekannten Sprache auch...
Wenn die Frage ist, ob C oder C++ geeigneter für Anfänger ist, würde
ich uebrigens eindeutig für "keins von beiden" stimmen. Sprachen, bei
denen hinter jeder Ecke undefiniertes Verhalten lauert, sind da
einfach ungeeignet.
Falk
Rudolf Polzer
Dass man nicht davon ausgehen darf, dass stdin ein Newline vor
dem EOF hat, bloß weil man ohne Redirection diesen Ausnahmefall
nicht provozieren kann.
--
#!/usr/bin/perl -- prints all files of current dir.
open H,"|a2ps -1R";for(sort<*>){print H"$_:\n";open
X,"<$_";print H map{chomp;"> $_\n"}<X>;print H"\n"}
# http://rebo...@durchnull.de
Rudolf Polzer
> Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
>
> > Unter Linux passiert das AFAIK nur mit einer Pipe: [...]
> > bash$ echo Test | ./x
> > bash$ echo -n last line | ./x
>
> Mein Gott! Du bist wirklich ein unglaublich kluger Kopf.
> Natürlich steht am Ende einer Datei kein Newline, wenn
> man keines hineinschreibt. Ob Pipe oder nicht ist dabei
> schnurzpiepegal. Probier's aus, wenn Du es nötig hast.
An einem /dev/tty kriegst du sowas nicht hin, man muss aber
dank Redirection doch damit rechnen.
> > Den zweiten (echo -n) nicht.
>
> Man könnte sich auf den Standpunkt stellen, daß es sich
> bei Dateien ohne Newline am Ende nicht um Textdateien im
> strengen Sinne von POSIX.2 handelte. Natürlich wäre das
> eine recht fadenscheinige Ausrede.
cron ist da recht hartnäckig, aber das ist jetzt bisher
das erste Argument, das für den eigentlich fehlerhaften
Code spricht.
> >> Um bei Unix zu bleiben, EOL (oder EOF, wenn nicht
> >> am Anfang einer Zeile) führt im kanonischen Modus zwar dazu,
> >> daß read() Zeilen ohne Newline liefert, nicht aber fgets().
> >
> > Gehe niemals davon aus, dass stdin immer die Konsole wäre.
>
> Für Deine Ratschläge bin ich echt wahnsinnig dankbar, o großer
> Rudolf. Dummerweise ist Dir allerdings entgangen, daß es hier
> um beliebige Terminal-Devices und nicht um Konsolen geht. Und
> ebenso, daß es DEIN Hinweis war, daß man unter DOS (welches
> DOS, btw?) interaktiv Eingaben ohne Newline generieren könne.
> Ich habe nur erklärt, wie man das mit einem Unix-Terminal
> bewerkstelligt und daß das fgets() trotzdem nicht tangiert,
> vgl. fgets(XSH), SUSv2.
Wie gesagt, mit Redirection kann man einen solchen Fall provozieren.
Sobald man das kann, muss man damit auch rechnen.
Gunnar Ritter
> An einem /dev/tty kriegst du sowas nicht hin,
Doch. Ich habe bereits indirekt erklärt, wie.
$ od -bc
foo<EOF><EOF>0000000 146 157 157
f o o
0000003
$
Es ist allerdings auch hier nur am Dateiende relevant und
deshalb kein Sonderfall. Wie ich ebenfalls bereits schrieb.
Du bist auf dem besten Weg zur Merkbefreiung.
Grüße,
Gunnar
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote:
>> Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
>> > In dem Fall schon, da es einfach sinnvoller ist, zum Lesen aus
>> > einer Datei und zum Lesen aus stdin den selben Code zu benutzen.
>>
>> stdin IST eine Datei (bzw. verweist darauf). Was willst Du mit
>> dieser seltsamen Formulierung eigentlich sagen?
>
> Dass man nicht davon ausgehen darf, dass stdin ein Newline vor
> dem EOF hat,
Es gibt in dieser Hinsicht genau gar keinen Unterschied zwischen
stdin und beliebigen anderen Deskriptoren.
Grüße,
Gunnar
Jens Schweikhardt
in <1011375829.irz787%sr...@inf.tu-dresden.de>:
#
# Hallo,
#
# Jens Schweikhardt <use...@schweikhardt.net> wrote:
#> Daniel Dörrhöfer <da...@gmx.de> wrote
#
#> # Welche Sprache sollte man sich als Anfänger aneignen C oder C++?
#
#> Wenn du keine Ahnung von irgendwas hast und bereit bist ein paar Dinge
#> fürs erste einfach so hinzunehmen, dann C. Ansonsten, wenn Du wissen willst,
#> was ein protected abstract virtual base pure virtual private destructor
#> ist (gibt es *wirklich*), dann C++.
#
# [x] Zeigen!
Peter van der Linden, "Expert C Programming" (sic), Seite 328.
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Andreas Krey
>Gunnar Ritter <g...@bigfoot.de> wrote:
>> Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
>>
>> > Unter Linux passiert das AFAIK nur mit einer Pipe: [...]
>> > bash$ echo Test | ./x
>> > bash$ echo -n last line | ./x
>>
>> Mein Gott! Du bist wirklich ein unglaublich kluger Kopf.
>> Natürlich steht am Ende einer Datei kein Newline, wenn
>> man keines hineinschreibt. Ob Pipe oder nicht ist dabei
>> schnurzpiepegal. Probier's aus, wenn Du es nötig hast.
>
>An einem /dev/tty kriegst du sowas nicht hin, man muss aber
>dank Redirection doch damit rechnen.
>
und dann zweimal ^D. stdin bekommt dann den Text ohne
ein Newline hintendran.
Andreas
--
@(g){g(g)}(@(g){@(v){v>0 ? g(g)(v-1)*v : 1}})(99);
Klaus von der Heyde
> > Eigentlich will man aber Funktionen, die Zeilen von unbegrenzter Länge
> > einlesen können.
>
> Wenn man die Funktion allgemein einsetzen können will, ja.
> Will ich z.B. nur einen Parser für eine Konfigurationsdatei schreiben, kann
> ich mich auch mit geringeren (dokumentierten) Zeilenlängen zufrieden geben
> und bei längeren Zeilen dem Benutzer eine Fehlermeldung um die Ohren hauen.
Das sollte man aber nicht machen. Guter programmierstil (den ich auch
nicht befolge, keine sorge :) ist es, keine willkuerlichen
beschraenkungen zu machen. Irgendwer hat mal gesagt, die einzigen
konstanten im programm sollten 0 und 1 sein. Das finde ich etwas
uebertrieben; aber bei einer auf irgendeinen wert festgelegten
stringlaenge kann man immer fragen: warum nur soviel, und nicht noch
mehr.
Klaus
Felix von Leitner
> Welche Sprache sollte man sich als Anfänger aneignen C oder C++?
Als Anfänger solltest du erst mal programmieren lernen, nicht eine
bestimmte Programmiersprache.
> Ich habe schon öffters gehört, dass C auststirbt. Ist da was dran ?
Nein.
> Was wird sich durchsetzen?
Quantencomputer mit direktem Gehirn-Interface.
> Hier zählt eure Meinung !
Nein, hier zählt, daß du mal ne Runde ausnüchterst.
Troll, Troll, Troll your boat, gently down the stream...
Stefan Fleiter
>>> die noch nicht mal beliebig lange Zeilen einlesen kann,
>> Braucht man eigentlich nie, wäre in C "etwas" komplizierter geworden.
> Ich hoffe, ich muss nie ein Programm von dir benutzen.
Der Einbau von unnützer Komlexität in Programme steigert deren
Fehleranfälligkeit ungemein. Meine Programme arbeiten nach KISS, was aber
nicht heißt daß ich nicht versuchen würde sämtliche Fehler ab zu fangen.
Aber Du in Deiner Erhabenheit kannst ja gerne mal einen Link zu Deinen
"Werken" geben, damit wir uns auch davon überzeugen können.
>> > und 10 Zeilen lang ist. Willst du wirklich behaupten, dass C fuer
>> > Anfaenger geeignet ist?
>>
>> Wenn die Frage ist ob C oder C++ geeigneter für Anfänger ist dann
>> würde ich immer noch für C stimmen.
> Was hat C++ mit Objektorientierung zu tun?
Ne ganze Menge.
Wer programmiert schon objektorientiert in C?
> Wird zwar besser unterstuetzt als in C, aber muss man ja nicht benutzen.
> Aber man kann immerhin mit einer Zeile Code eine beliebig lange Textzeile
> einlesen, wie in jeder anderen mir bekannten Sprache auch...
Theoretisch schön, praktisch nicht von Bedeutung.
Ich warte immer noch auf ein _sinnvolles_ Beispiel wo man sowas braucht.
> Wenn die Frage ist, ob C oder C++ geeigneter für Anfänger ist, würde
> ich uebrigens eindeutig für "keins von beiden" stimmen.
Siehe oben:
_Wenn_ die Frage ist...
> Sprachen, bei denen hinter jeder Ecke undefiniertes Verhalten lauert, sind
> da einfach ungeeignet.
C ist halt eindeutig näher am am System und zum verstehen bedeutend besser
geeignet.
Gruß,
Stefan
Stefan Fleiter
> C++ würde übrigens obigen Code gar nicht erst kompilieren, weil
> dabei ein "const char *" implizit zum "char *" gecastet wird.
Dafür muß man beim malloc explizit casten, ziemlich fehlerträchtig.
> Hätte ich auch machen können. Hat aber den Nachteil, dass der
> String praktisch zweimal berechnet, aber nur einmal geschrieben
> wird. Hängt davon ab, was man machen will - meist ist ein "Basst
> scho"-Puffer mit snprintf effizienter.
Stimmt, nur ist der Teil des Programms bei dem effizientes Programmieren von
Bedeutung ist meist verschwindend gering.
Programme erst funktional schreiben und dann nur an den _wirklich nötigen_
Stellen optimieren spart unheimlich viel Zeit und vermeidet komlizierten
Code.
Stefan
--
Fixed sendmail on www.linux.org.uk - that is I installed exim on it.
Sendmail kindly erased /etc/aliases when it was removed. That was nice
of it. -- Alan Cox
Stefan Fleiter
> ist es, keine willkuerlichen beschraenkungen zu machen. Irgendwer hat mal
> gesagt, die einzigen konstanten im programm sollten 0 und 1 sein. Das finde
> ich etwas uebertrieben; aber bei einer auf irgendeinen wert festgelegten
> stringlaenge kann man immer fragen: warum nur soviel, und nicht noch mehr.
Gut, dann ist also POSIX auch schon schlecht.
Lies mal in "man 3 (sys|(f)path)conf", was da alles reguliert ist. :-)
Gruß,
Stefan
Klaus von der Heyde
> Als Anfänger solltest du erst mal programmieren lernen, nicht eine
> bestimmte Programmiersprache.
Wie soll man das auslegen: gleich mit mehreren zu beginnen? Mit
irgendwas muss man schliesslich den anfang machen. Lehrbuch-pseudocode
ist i.a. nicht besonders erfuellend.
> > Ich habe schon öffters gehört, dass C auststirbt. Ist da was dran ?
>
> Nein.
Zumindest auf absehbare zeit ist kein ende in sicht. Solange noch
irgendwer darin programmiert, lebt es. Im moment sind sehr viele
programme in C geschrieben, die aktiv entwickelt werden.
> Nein, hier zählt, daß du mal ne Runde ausnüchterst.
> Troll, Troll, Troll your boat, gently down the stream...
Hoppla, ich finde die frage wirklich nicht verkehrt. Zu meiner zeit
war sie leicht zu beantworten......
Klaus
--
Klaus von der Heyde -- he...@informatik.uni-bonn.de
Klaus von der Heyde
>
> Klaus von der Heyde <kl...@nero.uni-bonn.de> wrote:
>
> > ist es, keine willkuerlichen beschraenkungen zu machen
>
> Gut, dann ist also POSIX auch schon schlecht.
Ja :) Die werte koennte man auch auf "unendlich" setzen, wenn die
implementierung der funktionen entsprechend waere (und POSIX das
zulaesst).
> Lies mal in "man 3 (sys|(f)path)conf", was da alles reguliert ist. :-)
Pure ruecksichtnahme auf bestehendes ......
:)
Rudolf Polzer
> Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
>
> > C++ würde übrigens obigen Code gar nicht erst kompilieren, weil
> > dabei ein "const char *" implizit zum "char *" gecastet wird.
>
> Dafür muß man beim malloc explizit casten, ziemlich fehlerträchtig.
>
> > Hätte ich auch machen können. Hat aber den Nachteil, dass der
> > String praktisch zweimal berechnet, aber nur einmal geschrieben
> > wird. Hängt davon ab, was man machen will - meist ist ein "Basst
> > scho"-Puffer mit snprintf effizienter.
>
> Stimmt, nur ist der Teil des Programms bei dem effizientes Programmieren von
> Bedeutung ist meist verschwindend gering.
ACK - zumal dieser Teil üblicherweise kein *printf aufruft.
> Programme erst funktional schreiben und dann nur an den _wirklich nötigen_
> Stellen optimieren spart unheimlich viel Zeit und vermeidet komlizierten
> Code.
Stimmt - aber ein "Basst scho"-Puffer mit snprintf ist außerdem
noch leichter zu realisieren als snprintf zweimal aufzurufen, und
Programmierer sind bekanntlich faul.
Wenn ich also weiß, dass ich mit einer >512-Zeichen-Zeile nichts
anfangen kann, kann ich einen Puffer fester Größe nehmen und
im Falle der Überschreitung eine Warnung ausgeben (das merke
ich z.B. am fehlenden Newline, wenn der eof-Test false ergibt),
aber trotzdem weitermachen.
Wenn ich dagegen weiß, dass mir asprintf zur Verfügung steht, ist
es ganz einfach - leider ist asprintf kein C99.
Arnim Weidner
> Falk Hueffner <falk.h...@student.uni-tuebingen.de> wrote:
>
>> Aber man kann immerhin mit einer Zeile Code eine beliebig lange Textzeile
>> einlesen, wie in jeder anderen mir bekannten Sprache auch...
>
> Theoretisch schön, praktisch nicht von Bedeutung.
> Ich warte immer noch auf ein _sinnvolles_ Beispiel wo man sowas braucht.
Bei Deinem Quellcode hast Du ein Problem wenn Du damit z.B. die
/etc/passwd parst. Stell Dir vor jemand aendert seinen Kommentar
(gecos) z.B. mit "passwd -f" so, dass die Zeile laenger wird
als Deine maximale Laenge. Die ueberstehenden Bytes werden bei
Dir als neue Zeile interpretiert, fatal.
Arnim
Felix von Leitner
> > Als Anfänger solltest du erst mal programmieren lernen, nicht eine
> > bestimmte Programmiersprache.
> Wie soll man das auslegen: gleich mit mehreren zu beginnen? Mit
> irgendwas muss man schliesslich den anfang machen. Lehrbuch-pseudocode
> ist i.a. nicht besonders erfuellend.
Nein. Nicht die Sprache ist wichtig, sondern daß du Programmieren
lernst. Das macht man u.a., indem man sich verschiedene Sprachen
anschaut, und zwar nicht "C und C++" sondern auch funktionale
Programmiersprachen, ein bißchen Prolog, Eiffel und so.
> Hoppla, ich finde die frage wirklich nicht verkehrt. Zu meiner zeit
> war sie leicht zu beantworten......
Nein.
Klaus von der Heyde
> Nein. Nicht die Sprache ist wichtig, sondern daß du Programmieren
> lernst. Das macht man u.a., indem man sich verschiedene Sprachen
> anschaut, und zwar nicht "C und C++" sondern auch funktionale
> Programmiersprachen, ein bißchen Prolog, Eiffel und so.
Ja, ok. Aber bei irgend etwas muss man ja anfangen. Das erste programm
schreiben. Ich haette dafuer spontan ein shellscript empfohlen (ja, ja,
ich weiss...). Irgend etwas, das grundlegende konzepte vermittelt.
> > Hoppla, ich finde die frage wirklich nicht verkehrt. Zu meiner zeit
> > war sie leicht zu beantworten......
>
> Nein.
Doch. In einer zeit mit nicht-freier software und rechnern mit nur ein
paar kB speicher, dafuer mit einem interpreter fuer eine gewisse sprache
im ROM blieb kaum was anderes uebrig, mit dem man _anfangen_ konnte. Da
hat mensch es heutzutage doch besser....
Klaus
Rainer Weikusat
> Wie von anderen erwähnt, ist es am Dateiende einer Pipe falsch.
'Rudi im All', wie gewöhnlich ...
> Abgesehen
> davon bringst du Newbies mit solchen #defines gleich am Anfang auf die
> Idee, sowas wie
>
> #define DATASIZE 2048
> #define SECSIZE 2352
> #define OVERHEAD SECSIZE-DATASIZE
Offensichtlich.
> zeigst du Newbies, dass man auch '\0' schreiben kann - was sich
> dann in "Phone number:\15\1201234-56789" äußern kann. Gerade
> Newbies würde ich gleich von Anfang an immer \000 statt \0
> zeigen, damit solche Probleme nicht auftreten.
Evtl wäre es sinnvoller, ein oder zwei Kleinigkeiten, über die
zugrundeliegende Repräsentation zu lernen und 'Nullen', dh eine
beliebig lange Folge von Null-Bits, generell als solche zu behandeln.
Typkonvertierungen in C sind definiert und nachlesbar.
> Ein ganz typischer C-Fehler ist übrigens der hier
Das ist ein ganz typischer 'mal grade eben'-Fehler und der wurde auch
bloß von einem Menschen gemacht.
> char *s = "ERROR: ";
> strcat (s, errstr);
>
> Ich sehe es so: lieber habe ich sicheren C++-Bloat als unsicheren
> kompakten C-Code.
Was ist an Deinen zwei strawmen bitteschön 'unsicher'. Es ist ganz
sicher in beiden Fällen Müll.
--
hoffentlich ist es beton
Felix von Leitner
> Doch. In einer zeit mit nicht-freier software und rechnern mit nur ein
> paar kB speicher, dafuer mit einem interpreter fuer eine gewisse sprache
> im ROM blieb kaum was anderes uebrig, mit dem man _anfangen_ konnte. Da
> hat mensch es heutzutage doch besser....
Bitte?! Man braucht keinen Computer zum Programmieren!
Klaus von der Heyde
> Bitte?! Man braucht keinen Computer zum Programmieren!
Aber zur ausfuehrung der erstellten programme :)
Programmierbare taschenrechner gibts natuerlich auch (ich rechne die mit
zu computern), da kann man auch mit anfangen.
Klaus
Friedrich Dominicus
>
>
> //
> #include <iostream>
> class B {
> public:
> virtual void printv () {std::cout << "class B" << std::endl;};
> static void prints () {std::cout << "class B" << std::endl;};
> // der Rest interessiert hier nicht
> };
>
> class L : public B {
> public:
> virtual void printv () {std::cout << "class L" << std::endl;};
> static void prints () {std::cout << "class L" << std::endl;};
> // der Rest interessiert hier nicht
> };
>
> int main () {
> B* X;
> L Y;
> B Z;
>
> X = new L;
>
> // Was für eine Ausgabe ergibt:
> Y.printv ();
> Y.prints ();
> Z.printv ();
> Z.prints ();
> X->printv ();
> X->prints ();
>
> delete X;
> };
He,he eine Objektorientierte Sprache vor virtual in Objekten nicht
default ist. Und dann im gleichen Atemzug Polymorphy nennen. Leute ihr
könnt einem das Leben ganz schön versauern..
> // eof
>
> Das obige sehr einfache Beispiel, soll Dir zeigen wo die großen
> Unterschiede in den Methoden Aufrufen liegen. Leider ist es nicht
> trivial wann man denn nun was für eine anwenden soll.
Ein einfaches OO-Beispiel welches nicht trivial ist. Wofür dann OO?
>
> Davon hängt unter anderem ab, ob ein Programm effizient ist.
>
> Als kleine Übung fürs C Programmieren versuche das Verhalten von X, Y
> und Z in C nachzubauen.
Nö danke, das muß ich mir weder in C noch in C++ antun.
Bis dann
Friedrich
Stefan Fleiter
> Bei Deinem Quellcode hast Du ein Problem wenn Du damit z.B. die
> /etc/passwd parst. Stell Dir vor jemand aendert seinen Kommentar
> (gecos) z.B. mit "passwd -f" so, dass die Zeile laenger wird
> als Deine maximale Laenge. Die ueberstehenden Bytes werden bei
> Dir als neue Zeile interpretiert, fatal.
Die Frage ist ob eine Zeile von /etc/passwd länger als LINE_MAX Zeichen
seind darf. In der man-page steht nichts dazu da.
Wenn ja, was ich nicht glaube, wäre das aber ein sinnvolles Beispiel.
Gruß,
Stefan
Stefan Fleiter
> Wenn ich dagegen weiß, dass mir asprintf zur Verfügung steht, ist
> es ganz einfach - leider ist asprintf kein C99.
Genau, und leider deshalb in paortabel gehaltenen Programmen nicht zu
verwenden. :-/
Gruß,
Stefan
Stefan Reuther
Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
> King Leo - Martin Oberzalek <kin...@gmx.at> wrote:
>> > Wie das? Wie schaffst du es, diesen Fehler zu erkennen:
>> >
>> > printf ("%ld", 17); // long double sei größer als ein int
>> >
>> > Wie erkennst du eine int/char *-Verwechselung?
>>
>> Mein Code funktioniert so:
> [...]
>> Das ganze hat natürlich einen Nachteil. An die Funktion können nicht
>> beliebig viele Parameter übergeben werden. Ich hab die Lib für maximal 6
>> Parameter geschrieben.
> Ach, mit _der_ Einschränkung kann ich das auch... ich würde den Code
> allerdings mit einem eigenen Präprozessor erzeugen, der jeweils die
> Funktion für (n+1) Argumente mit Hilfe der für eins, der für n und
> der Konkatenation von Strings erzeugt.
Ich hab neulich auch mal so ein Teil gebaut. Momentan auf 10
Parameter begrenzt, weil ich aus Performancegründen ein
fest dimensioniertes Array verwende, aber das auf eine
verkettete Liste (-> beliebig viele Parameter) umzubauen ist
kein Problem. Benutzung ist bei meiner Version
format("Hallo, %s") << "Welt";
Genau wie Martin's Version kann bei mir prinzipiell jeder
Typ ausgegeben werden, der einen operator<<(ostream) hat.
>> Ach ja, ich hab diese Lib geschrieben, weil...
> [i18n]
>> Und ein
>>
>> cout << format( _("Fehler %d ist aufgetreten."), 25 ) << endl;
>>
>> hält sich eben an den printf Stil und man kann, wenn notwendig sogar die
>> Ausgabe der Parameter vertauschen.
> Wie das? Erlaubst du nummerierte Argumente?
Wenn schon typsicher, dann auch numerierte Argumente ;-)
Stefan
Stefan Reuther
Gunnar Ritter <g...@bigfoot.de> wrote:
> Stefan Fleiter <stefan....@gmx.de> wrote:
>> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>>> Ich würde trotzdem mit C++ anfangen. Warum? Erklär mal einem
>>> Newbie,
> Wenn er es versteht, hat er gleich ernsthaft etwas über Unix-
> Systemprogrammierung gelernt. Das ist ein Bonus. C hat den
> Vorteil, daß man relativ leicht verstehen kann, was der Code
> wirklich macht. Abstraktionslayer sind da hinderlich.
Für Programmieranfänger ist es aber sicher besser, wenn
sie erstmal funktionierende Programme hinbekommen, die
auch tatsächlich etwas tun, als wenn sie stundenlang
Speicher- und Puffermanagement machen um schließlich den
Benutzer nach seinem Namen und Alter fragen zu können.
Da ist `getline(cin, name)' und `cin >> alter' nun mal
besser als irgendwelches Gefrickel mit `fgets' und
Puffergrößen. Schon weil man sich eben nicht selber um
Speichermanagement kümmern muß.
Ich will unserem Anfänger ja nicht gleich Templates
und Mehrfachvererbung beibringen. Auch wenn ich persönlich
der Meinung bin, das Templates die beste Erfindung seit
geschnittenem Brot sind ;-)
Stefan
Stefan Reuther
Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
> Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
>> > Wenn du keine Ahnung von irgendwas hast und bereit bist ein paar Dinge
>> > fürs erste einfach so hinzunehmen, dann C. Ansonsten, wenn Du wissen willst,
>> > was ein protected abstract virtual base pure virtual private destructor
>> > ist (gibt es *wirklich*), dann C++.
>>
>> [x] Zeigen!
>>
>> Man kann bestimmt irgend ein Codeschnipsel bauen, das all diese
>> Buzzwords irgendwie erfüllt, aber das Etwas, das genau diesen
>> Namen trägt, möchte ich sehen...
>>
>> Und ein static volatile restrict const unsigned long long int pointer
> ^^^^^^^^ ^^^^^
> _Die_ Kombination ist wirklich gut. Auf dem ersten Blick widersprüchlich,
> danach ist aber doch klar, wie das gemeint ist: das Programm hat da
> nicht rumzupfuschen, der Interrupthandler bekommt mit const_cast eine
> Sondergenehmigung.
Warum? Vielleicht ist ja nur der Zeiger `const' und nicht
der long long int, auf den er zeigt.
>> ist sicherlich nicht wirklich einfacher :-]
> Ist aber AFAIK kein C++ wg. restrict. Zudem ist das "int" am Ende
> überflüssig; obige Bezeichnung enthält nichts überflüssiges.
Das ist auch kein C++, das ist C99. C++ hat auch kein long long.
> Was ist eigentlich genau restrict?
Im Prinzip heißt das, daß der Zeiger keine Aliase besitzt.
Der C90 Prototyp von memcpy ist
void *memcpy(void *dest, const void *src, size_t n);
mit der Anmerkung
The memory areas may not overlap.
In C99 drückt man diese Anmerkung mit `restrict' Zeigern aus
void *memcpy(void * restrict s1, const void * restrict s2,
size_t n);
Stefan
King Leo - Martin Oberzalek
Hallo,
> Ich hab neulich auch mal so ein Teil gebaut. Momentan auf 10 Parameter
> begrenzt, weil ich aus Performancegründen ein fest dimensioniertes Array
> verwende, aber das auf eine verkettete Liste (-> beliebig viele
> Parameter) umzubauen ist kein Problem. Benutzung ist bei meiner Version
> format("Hallo, %s") << "Welt";
gut, aber funktioniert dann auch?
cout << format( "Hallo, %s" ) << "Welt;
Gruß, Martin!
--
Selbst am einsamsten Ort des Universums wirst du immer noch zu einem
Himmel voller Sterne aufblicken können.
Rudolf Polzer
> Hallo,
>
> Rudolf Polzer <AntiATFiel...@durchnull.de> wrote:
> > Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
> >> > Wenn du keine Ahnung von irgendwas hast und bereit bist ein paar Dinge
> >> > fürs erste einfach so hinzunehmen, dann C. Ansonsten, wenn Du wissen willst,
> >> > was ein protected abstract virtual base pure virtual private destructor
> >> > ist (gibt es *wirklich*), dann C++.
> >>
> >> [x] Zeigen!
> >>
> >> Man kann bestimmt irgend ein Codeschnipsel bauen, das all diese
> >> Buzzwords irgendwie erfüllt, aber das Etwas, das genau diesen
> >> Namen trägt, möchte ich sehen...
> >>
> >> Und ein static volatile restrict const unsigned long long int pointer
> > ^^^^^^^^ ^^^^^
> > _Die_ Kombination ist wirklich gut. Auf dem ersten Blick widersprüchlich,
> > danach ist aber doch klar, wie das gemeint ist: das Programm hat da
> > nicht rumzupfuschen, der Interrupthandler bekommt mit const_cast eine
> > Sondergenehmigung.
>
> Warum? Vielleicht ist ja nur der Zeiger `const' und nicht
> der long long int, auf den er zeigt.
Wäre es dann nicht ein
"static volatile restrict unsigned long long int pointer const"?
> > Was ist eigentlich genau restrict?
>
> Im Prinzip heißt das, daß der Zeiger keine Aliase besitzt.
> Der C90 Prototyp von memcpy ist
> void *memcpy(void *dest, const void *src, size_t n);
> mit der Anmerkung
> The memory areas may not overlap.
> In C99 drückt man diese Anmerkung mit `restrict' Zeigern aus
> void *memcpy(void * restrict s1, const void * restrict s2,
> size_t n);
So wie ich das lese, gibt es auch keine restrict char *, sondern nur
char * restrict.
Was ist ein Alias eines Zeigers? Sind p und p+1 noch Aliase? Sind
p und p+0 überhaupt welche? Wenn ja, sind sie es auch noch nach
einer Parameterübergabe durch eine Funktion?
--
www42:~ # mv /mnt/c/windows/win.com /dev/null
mv: /dev/null: data refused
Gunnar Ritter
>> Wenn er es versteht, hat er gleich ernsthaft etwas über Unix-
>> Systemprogrammierung gelernt. Das ist ein Bonus. C hat den
>> Vorteil, daß man relativ leicht verstehen kann, was der Code
>> wirklich macht. Abstraktionslayer sind da hinderlich.
>
> Für Programmieranfänger ist es aber sicher besser, wenn
> sie erstmal funktionierende Programme hinbekommen, die
> auch tatsächlich etwas tun,
Für Programmieranfänger mit Sicherheit, aber für die ist C++
ebenfalls eine schlechte Wahl.
Ansonsten geht es in dieser Newsgroup nicht um Programmieren
allgemein, sondern um Unix-Programmieren, und darauf bezieht
sich meine Aussage.
Grüße,
Gunnar
Tibor Pausz
> He,he eine Objektorientierte Sprache vor virtual in Objekten nicht
> default ist. Und dann im gleichen Atemzug Polymorphy nennen. Leute ihr
> könnt einem das Leben ganz schön versauern..
C++ ist ein Hybrid Sprache, das sorgt immer für Verwirrungen. Das ist
eine der Gründe warum ich der Meinung bin, daß C++ nicht gerade eine
Anfängersprache ist, das ist zurückhaltende Formulierung. Programmieren
sollte man schon können und OO zu kennen ist auch nicht schlecht.
C wie auch C++ sind mächtig und man kann mit ihnen bei entsprechendem
Wissen gute und effiziente Programme schreiben. Aber ...
Eine der Gründe warum "virtual" nicht default ist, ist nunmal die
Tatsache, daß virtuelle Methoden langsamer aufgerufen werden. Es gibt
Hochsprachen die sind sehr typsicher, das heißt es wird eine sehr starke
statische Typprüfung vorgenommen. Möglichst werden Typen während des
Compilerlaufs geprüft und nicht erst während der Laufzeit des Programms.
Das andere Extrem sind Sprachen, die (fast) keinerlei Typprüfung während
des Compilerlaufs haben. Diese Sprachen sind sehr flexibel, aber dafür
sind die Programme auch relativ langsam in der Ausführung.
Aber nicht immer ist diese relativ langsame Ausführung von Nachteil,
ganz im Gegenteil. Insofern sehe ich den Königsweg bei
Programmiersprachen nicht, ist gibt nicht die Eine goldene
Programmiersprache, die alles gut unterstützt.
C++ steht nunmal für die eher statischen Programmiersprachen und daher
ist hier Laufzeiteffizienz stärker beim Entwurf gewichtet worden als
Flexibilität. -> virtual ist nicht die Vorgabe.
> Ein einfaches OO-Beispiel welches nicht trivial ist. Wofür dann OO?
Nicht immer ist es sinnvoll OO Elemente zu benutzen und es ist durchaus
sinnvoll statische Elemente in Klassen zu haben -> GoF Book, Singleton
Pattern bzw. Alexandrescu, Modern C++ Design für eine Umsetzung
desselben.
Der Vorteil einer Hybrid Sprache ist es nun Elemente aus den klassischen
Sprachen anzubieten und dazu OO Elemente, leider folgt daraus aber
gleichsam eine Erhöhung der Komplexität.
Stefan Reuther
King Leo - Martin Oberzalek <kin...@gmx.at> wrote:
> On Mon, 21 Jan 2002 14:55:37 +0100, Stefan Reuther wrote:
>> Ich hab neulich auch mal so ein Teil gebaut. Momentan auf 10 Parameter
>> begrenzt, weil ich aus Performancegründen ein fest dimensioniertes Array
>> verwende, aber das auf eine verkettete Liste (-> beliebig viele
>> Parameter) umzubauen ist kein Problem. Benutzung ist bei meiner Version
>> format("Hallo, %s") << "Welt";
> gut, aber funktioniert dann auch?
> cout << format( "Hallo, %s" ) << "Welt;
Nein, aber
cout << (format("Hallo, %s") << "Welt");
Die Formatierung der Ausgabe passiert bei mir im "operator string()".
Stefan
King Leo - Martin Oberzalek
Ein interessanter Ansatz muß ich sagen.
Da ich meine format Klasse sowieso bald komplett neu schreiben muß, werd
ich mir überlegen, ob nicht das ein, oder andere Konzept besser währe.
Also immer her mit den Ideen!
--
Selbst Systeme, die ein oder zwei Jahre alt sind, können die Mainstream-
Applikationen mit Leichtigkeit ausführen. Kein Wunder, Standard-Programme
von Microsoft erhielten nur kosmetische Updates verpasst, die nur in den
seltensten Fällen mehr Leistung benötigen. (www.tomshardware.de)
Felix von Leitner
> Ich hab neulich auch mal so ein Teil gebaut. Momentan auf 10
> Parameter begrenzt, weil ich aus Performancegründen ein
> fest dimensioniertes Array verwende, aber das auf eine
> verkettete Liste (-> beliebig viele Parameter) umzubauen ist
> kein Problem. Benutzung ist bei meiner Version
> format("Hallo, %s") << "Welt";
> Genau wie Martin's Version kann bei mir prinzipiell jeder
> Typ ausgegeben werden, der einen operator<<(ostream) hat.
Ganz toll. Nur: wozu?
Man vereint die eklige Syntax mit der Schlechten Performance.
Felix
Rudolf Polzer
Und? Dafür kann man diesen Code recht gut internationalisieren.
Das ist aber das einzige für mich ersichtliche Pro-Argument für
diesen Code.
Das geht aber auch einfacher:
#include <stdio.h>
#include <stdlib.h>
#include <stding>
#include <stdarg.h>
// ...
using namespace std;
// ...
string format (char *format, ...)
{
string str;
char *p = 0;
va_list ap = va_start (format);
vasprintf (&p, format, ap);
if (!p)
throw FatalError ("out of memory", errno);
va_end (ap);
str = p;
free (p);
return str;
}
Ist auch i18n-geeignet, aber dank vasprintf nicht standardkonform.
Das Kopieren am Ende kann man durch eine GNU-Erweiterung (Return-
Variablen) vermeiden.
--
Koroshiteyaru. Koroshiteyaru. Koroshiteyaru. Koroshiteyaru...
[Asuka in Neon Genesis Evangelion - english: "I'll kill you"]
King Leo - Martin Oberzalek
> Felix von Leitner <usenet-...@fefe.de> wrote:
>> Thus spake Stefan Reuther (sr...@inf.tu-dresden.de):
>> > Ich hab neulich auch mal so ein Teil gebaut. Momentan auf 10
>> > Parameter begrenzt, weil ich aus Performancegründen ein fest
>> > dimensioniertes Array verwende, aber das auf eine verkettete Liste
>> > (-> beliebig viele Parameter) umzubauen ist kein Problem. Benutzung
>> > ist bei meiner Version
>> > format("Hallo, %s") << "Welt";
>> > Genau wie Martin's Version kann bei mir prinzipiell jeder Typ
>> > ausgegeben werden, der einen operator<<(ostream) hat.
>>
>> Ganz toll. Nur: wozu?
>> Man vereint die eklige Syntax mit der Schlechten Performance.
>
> Und? Dafür kann man diesen Code recht gut internationalisieren. Das ist
> aber das einzige für mich ersichtliche Pro-Argument für diesen Code.
Das war auch der einzige Grund, warum ich diesen Code geschrieben
hatte. [1]
> Das geht aber auch einfacher:
> // ...
> using namespace std;
> // ...
> string format (char *format, ...)
Und schon ist die typsicherheit im Ar***
Und das war auch der einzige Grund warum ich "..." nicht verwendet hab!
> Ist auch i18n-geeignet, aber dank vasprintf nicht standardkonform.
Mein Code ist dagegen schon Standardkonform.
All diese Gründe hab ich aber in den vorherigen Postings schon dargelegt.
Also sei bitte so nett und lies den Thread noch einmal!
Gruß, Martin!
[1] Und wenn es nur um die Internationalisierung geht, dann sind das
wieviele Texte die am Bildschirm ausgegeben werden??
Rechne es dir selber aus. Das Performance Argument zieht hierbei nicht.
Diejenigen, die es aber trotzdem versuchen, sind genau die, die entweder
solche Biblotheken zweckentfremden, oder noch nicht wissen wozu es
Profiler gibt.
--
Die Überlegenheit von Windows auf dem Solitär-Sektor ist aber auch
schon lange Vergangenheit.
(Andreas Stiasny in at.linux)
King Leo - Martin Oberzalek
> On Fri, 25 Jan 2002 00:38:04 +0100, Rudolf Polzer wrote:
>
>> Felix von Leitner <usenet-...@fefe.de> wrote:
Mein Posting war eigentlich an Felix gerichtet. Nicht an dich Rudolf.
Gruß, Martin!
--
Niemand, der sich auch nur einen Funken mit unixoiden Systemen auskennt,
würde Windows mit Linux vergleichen. Die Betriebssysteme spielen nicht nur
in verschiedenen Ligen, sondern auch in anderen Sportarten.
(Heiko Schlenker in de.comp.os.unix.linux.misc)
Stefan Reuther
Felix von Leitner <usenet-...@fefe.de> wrote:
> Thus spake Stefan Reuther (sr...@inf.tu-dresden.de):
>> Ich hab neulich auch mal so ein Teil gebaut. Momentan auf 10
>> Parameter begrenzt, weil ich aus Performancegründen ein
>> fest dimensioniertes Array verwende, aber das auf eine
>> verkettete Liste (-> beliebig viele Parameter) umzubauen ist
>> kein Problem. Benutzung ist bei meiner Version
>> format("Hallo, %s") << "Welt";
>> Genau wie Martin's Version kann bei mir prinzipiell jeder
>> Typ ausgegeben werden, der einen operator<<(ostream) hat.
> Ganz toll. Nur: wozu?
Internationalisierung.
> Man vereint die eklige Syntax mit der Schlechten Performance.
Über Geschmack brauchen wir hier ja nicht zu streiten.
C-Version, sprintf:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char** argv)
{
int i = atoi(argv[1]);
while (i-- > 0) {
char buffer[1000];
sprintf(buffer, "Der Zähler hat den Wert %d, fallend.\n", i);
}
}
$ time ./test1 1000000
real 0m3.303s
user 0m3.300s
sys 0m0.000s
Das gleiche mit meiner Format-Klasse (`string str = format("...") << i'):
$ time ./test2 1000000
real 0m3.731s
user 0m3.730s
sys 0m0.000s
Und mit stringstream (`strstream s; s << "..." << i << "...")'):
$ time ./test3 1000000
real 0m4.149s
user 0m4.150s
sys 0m0.000s
Für bessere Internationalisierung als iostream, bessere
Erweiterbarkeit und Wartbarkeit (Speicherallokation) als
sprintf, und Typsicherheit (schon mal in reinem C einen
`off_t' ausgeben müssen?) nehme ich die 12% Verlust gerne
hin. Wobei ich mir relativ sicher bin, die auch noch
eliminieren zu können (Formatparameter werden momentan
by-reference übergeben).
Stefan
Stefan Stapelberg
> Daniel Dörrhöfer <da...@gmx.de> wrote
> > # Ich habe schon öffters gehört, dass C auststirbt. Ist da was dran ?
Das Gerücht kommt immer mal wieder hoch. Auch daß Unix ausstirbt
und auch, daß alle Hersteller den Unix-Kern in C++ schreiben.
Kompletter Nonsens.
> Es gibt auch eine Menge Leute, die sich einen abrackern, in C
> objektorientiert zu programmieren, "weil ja jeder einen C Compiler
> bedienen kann". Da sage ich dann, danke, noch mal, in C++ diesmal.
Ne, falsche Begründung. Richtig ist: "weil ordentliche Programme
die Prinzipien der Objektorientierung und des Information Hiding
beachten, ohne dabei eine bestimmten Sprache vorauszusetzen",
jaja, das geht sogar in Assembler, ei sowas.
Was, wenn nicht objektorientiert, sind die in C geschriebenen
STDIO-Funktionen? Was, wenn nicht objektorientiert ist das in
C geschriebene X Window System? Was, wenn nicht objektorientiert
sind Teile des Unix-Kerns?
Was wäre, wenn die Objektorientierung schon seit den frühen
60ern nix neues mehr ist? Und nur grad wieder werbewirksam
"neu" aufgelegt wurde? Na gut, so neu nicht mehr, ab immer
noch fest verankert in den Hirnen der Entscheider: "Ist ihr
Programm auch objektorientiert?" Logo isses das, war's schon
immer, sind ja schließlich ein Haufen Objekte drin. LOL
Solange ich Codeschnipsel wie die folgenden sehe:
char *defname;
defname = (char)malloc(6);
strcpy(defname, "guest");
glaub ich nicht, daß C++ Programmierern besseres/saubereres
Programmieren gegenüber C aufzwingt, eher im Gegentum. Oder
weiß einer der C++-Spezialisten, wo der genaue Unterschied
zwischen
char *defname = "guest";
und
char defname[] = "guest";
liegt? Doch, doch, da gibt's einen.
Stefan, der weiter bei C-only bleibt :-)
PS: Nur falls einer fragt, was ich denn wieder geraucht hätte:
Es war schwarzer Krauser grade :-) :-) :-) Grüssle an Felix ;-)
--
Stefan Stapelberg Fon: +49.6221.803.802 RENT-A-GURU (TM)
<ste...@rent-a-guru.de> Fax: +49.6221.803.899 Neuer Weg 16
http://www.netstore.de/ RAG3-RIPE D-69118 Heidelberg
** Microsoft spel chekar vor sail, worgs grate!! **
Stefan Stapelberg
Stefan, ich helf Dir mal:
int frc(void) {
int cc;
if ((cc = getchar()) != EOF)
frc();
return cc;
}
Liest (fast) beliebig lange Zeilen.
Bruhahaha
Stefan Stapelberg
>
> Kann man unter DOS nicht auch Zeilen ohne Newline an der Konsole
> produzieren? DOS akzeptiert AFAIK ein ^Z auch am Ende der Zeile.
> Dann haben wir eine Zeile ohne Newline.
Nein, tut's nicht. Es erkennt ein ^Z nur nach Newline und auch
nur, wenn dem ^Z nochmal ein Newline folgt. Es sollte es tun,
wenn's die STDIO-Funktionen richtig nachbilden tät, aber is
halt DOS (Die ohne System).
Stefan Stapelberg
> Aber nicht in einem sauber implementierten fgets(). Das ist
> ja gerade dafür da, entweder auf Newline oder Dateiende zu
> warten. Um bei Unix zu bleiben, EOL (oder EOF, wenn nicht
> am Anfang einer Zeile) führt im kanonischen Modus zwar dazu,
> daß read() Strings ohne Newline liefert, nicht aber fgets().
Und das ist falsch. EOF hat bei interaktiven Dateien zunächst
die selbe Bedeutung wie EOL, nämlich: Nimm alles, was im Puffer
(des Gerätetreibers) steht und schick es an das lesende Programm.
Steht nix drin, kommt nix = Dateiende. Steht was drin, kommt "was"
und zwar ohne Newline.
Daß Du noch ein zweites EOF geben mußt, damit fgets() dann
Dateiende liefert, hängt mit der Bedeutung zusammen - obigen
Absatz nochma genau durchlesen.
Also doch erstma richtig C lernen und dann C++, odda? :-) :-)
Grüße Stefan
Stefan Stapelberg
> Bitte?! Man braucht keinen Computer zum Programmieren!
Stimmt! Das Programmieren einer Waschmaschine reicht manchen Leuten.
Rudolf Polzer
> Rudolf Polzer wrote:
> >
>
> > Kann man unter DOS nicht auch Zeilen ohne Newline an der Konsole
> > produzieren? DOS akzeptiert AFAIK ein ^Z auch am Ende der Zeile.
> > Dann haben wir eine Zeile ohne Newline.
>
> Nein, tut's nicht. Es erkennt ein ^Z nur nach Newline und auch
> nur, wenn dem ^Z nochmal ein Newline folgt. Es sollte es tun,
> wenn's die STDIO-Funktionen richtig nachbilden tät, aber is
> halt DOS (Die ohne System).
Wirklich?
,---
| D:\TEST>copy con x
| Test
| ^Z
| 1 file(s) copied
|
| D:\TEST>copy con y
| Test^Z
| 1 file(s) copied
|
| D:\TEST>copy con z
| Test^Zfahrer
| 1 file(s) copied
|
| D:\TEST>dir
|
| Volume in drive D is mu/drives/d
| Directory of D:\TEST
|
| . <DIR> 01-28-02 6:05p
| .. <DIR> 01-28-02 6:05p
| X 6 01-28-02 6:05p
| Y 4 01-28-02 6:05p
| Z 4 01-28-02 6:05p
| 5 file(s) 14 bytes
| 1,019,674,624 bytes free
|
| D:\TEST>ver /r
|
| MS-DOS Version 6.22
| Revision A
| DOS is in HMA
|
| D:\TEST>
`---
Auch nach dem ^Z muss kein Newline kommen - die Datei wird aber danach
abgeschnitten. Wenn ich Test^Zfahrer eingebe, wird die Datei auch nur
4 Byte groß. copy liest scheinbar zeilenweise ein, behandelt das ^Z aber
völlig korrekt als EOF-Zeichen.
Das bei Win98 SE mitgelieferte DOS verhält sich übrigens exakt genauso.
--
"Windows löschen" fällt m.E. unter die bestimmungsgemässe Nutzung der
Software. Also zulässig.
[Holger Lembke in de.soc.recht.marken+urheber]
Rainer Weikusat
> Ne, falsche Begründung. Richtig ist: "weil ordentliche Programme
> die Prinzipien der Objektorientierung und des Information Hiding
> beachten, ohne dabei eine bestimmten Sprache vorauszusetzen",
Das ist aber nicht der eigentliche Witz.
> Was, wenn nicht objektorientiert, sind die in C geschriebenen
> STDIO-Funktionen? Was, wenn nicht objektorientiert ist das in
> C geschriebene X Window System? Was, wenn nicht objektorientiert
> sind Teile des Unix-Kerns?
Nicht 'objektorientiert', man kann sie aber so beschreiben. Es sind
keine closures im technischen Sinne, => 'First order citizen'.
> Was wäre, wenn die Objektorientierung schon seit den frühen
> 60ern nix neues mehr ist?
So wirds wohl sein.
> Solange ich Codeschnipsel wie die folgenden sehe:
>
> char *defname;
>
> defname = (char)malloc(6);
> strcpy(defname, "guest");
>
> glaub ich nicht, daß C++ Programmierern besseres/saubereres
> Programmieren gegenüber C aufzwingt,
Der Ansatz ist ohnehin vollkommen irrig (... und man _muß_
nachweislich 'manuelles Speichermanagment' in Perl machen (oder
überall), denn ein durchgehend laufendes Programm muß sich bezüglich
Speicheranforderung à la O(1) verhalten und das *ist* eine Eigenschaft
des Algorithmus' ... ich weiß nicht, ob das Märchen schon kam oder
noch kommt, ich ich denke, man kann es als solches abhaken. Für immer
:-)
--
hoffentlich ist es beton