nicht angemeldet
Der Martin
Der Martin
Der Martin
Hallo,
ich soll ein Programm in C schreiben, dass eine beliebige Zeichenfolge entgegen nimmt, die Anzahl der Zeichen wiedergibt und die Zeichenfolge auf die ersten 10 Zeichen gekürzt in dem String "ausgabe" speichert und dann angezeigt wird. Das Ganze soll ohne string.h geschrieben werden.
Die Kürzung auf 10 Zeichen funktioniert nicht richtig. Er gibt zwar die 10 Zeichen aus, hängt aber noch undefinierbare Zeichen daran und auch nochmal den kompletten String aus "eingabe".
#include <stdio.h>
#include <conio.h>
int main (void)
{
char eingabe[1024], ausgabe[10];
int i=0, j;
printf("Bitte geben Sie eine Zeichenfolge ein: ");
gets(eingabe);
//Laenge auslesen
while(eingabe[i] != '\0')
i++;
//Kuerzung auf 10 Zeichen
for(j=0; j<10; j++)
ausgabe[j]=eingabe[j];
printf("\nDie eingegebene Folge enthaelt %d Zeichen.", i);
printf("\nDer gespeicherte String ist %s", ausgabe);
getch();
return 0;
}
Hallo!
char eingabe[1024], ausgabe[10];
\0 zählt auch als Zeichen, somit muss ausgabe die Länge 11 haben
printf("\nDer gespeicherte String ist %s", ausgabe);
Die Variable ausgabe ist kein String, Strings enden in C mit \0
for(j=0; j<10; j++)
ausgabe[j]=eingabe[j];
ausgabe muss noch zu einem String "gemacht" werden, d.h. \0 hinzugefügt
Folgender Fehler ist bei dir enthalten: Was ist wenn ich bei der Eingabe weniger als 10 Zeichen eingebe.
mfg
Hello,
Folgender Fehler ist bei dir enthalten: Was ist wenn ich bei der Eingabe weniger als 10 Zeichen eingebe.
Dafür wäre es praktisch, eingabe und ausgabe mit '\0' zu initialisieren.
Liebe Grüße aus Syburg
Tom vom Berg
Hallo,
| while(eingabe[i] != '\0')
Dieses hier verwendete Merkmal von C-Strings solltest du dann nach dem hier
|~~~c
| for(j=0; j<10; j++)
ausgabe[j]=eingabe[j];
auch noch beachten
mfg, Flo
--
sh:) fo:| ch:? rl:( br:^ n4:| ie:{ mo:| va:} de:> zu:} fl:{ ss:) ls:< js:|
Hello,
müsste es nicht besser
char eingabe[1024] = '\0', ausgabe[11] = '\0';
heißen?
Soweit ich mich erinnere, wird dann das gesamte Array initialisiert
Um ausgabe als char-Array ausgeben zu können, muss es doch wohl auch eine NULL am Ende haben, oder?
Liebe Grüße aus Syburg
Tom vom Berg
Hi,
müsste es nicht besser
char eingabe[1024] = '\0', ausgabe[11] = '\0';
heißen?
Fehler: Feld muss mit Initialisierung mit umgebenden geschweiften Klammern initialisiert werden
... sagt mein Compiler dazu.
Das '\0' muss also in geschweifte Klammern: char eingabe[1024] = {'\0'}
Soweit ich mich erinnere, wird dann das gesamte Array initialisiert
Um ausgabe als char-Array ausgeben zu können, muss es doch wohl auch eine NULL am Ende haben, oder?
Man kann in den geschweiften Klammern auch mehrere Werte (durch Komma getrennt) angeben. Dann werden alle Elemente des Feldes, für die kein Wert mehr angegeben ist mit 0 initialisiert. Und 0 ist identisch mit '\0'.
int feld[5] = {1,2,3} erzeugt beispielsweise ein Feld mit 5 Elementen. Die Werte der Elemente sind 1,2,3,0,0.
mfG,
steckl
Vielen Dank, nach der Initalisierung geht es.
Gruß
Mark
Hallo,
gets(eingabe);
ACHTUNG: GEFAHR! Das prüft die Puffergröße nicht. Wenn der Puffer also nicht groß genug ist, wird irgendwohin in den Speicher geschrieben. Du hast Dir hier einen klassischen stack-based buffer overflow gebastelt, Quelle Nr. 1 für Sicherheitslücken in C-Software. Gut, bei Deinem einfachen Programm ist das noch relativ egal, das macht ja sowieso nichts - aber Du solltest Dir das gar nicht erst angewöhnen.
ALSO: NUTZE NIE, NIE, NIE gets(). NIE. UNTER KEINEN UMSTÄNDEN. Das ist eine der wenigen Funktionen, vor der man IMMER abraten muss. IMMER. Mein Linker warnt mich sogar davor:
main.c:(.text+0x6d): warning: the `gets' function is dangerous and should not be used.
Als Alternative bietet sich fgets() an, der kann man die Puffergröße noch übergeben - man muss dafür halt stdin auch noch angeben:
fgets(eingabe, 1024, stdin);
Allerdings: fgets() lässt das \n-Zeichen am Ende einer Zeile (unter Windows vmtl. sogar \r\n) stehen. Daher musst Du Deine Schleife anpassen, wenn das genau so reagieren soll:
while(eingabe[i] != '\0' && eingabe[i] != '\r' && eingabe[i] != '\n')
i++;
Viele Grüße,
Christian
Hello,
ACHTUNG: GEFAHR! [...]
ALSO: NUTZE NIE, NIE, NIE gets(). NIE. UNTER KEINEN UMSTÄNDEN. Das ist eine der wenigen Funktionen, vor der man IMMER abraten muss. IMMER. Mein Linker warnt mich sogar davor:
Meine Meinung:
NUTZE NIE, NIE, NIE C oder C++, wenn sichere Software dabei herauskommen soll.
Pascal und Pascal-Derivate sind schneller und sicherer. :-D
Liebe Grüße aus Syburg
Tom vom Berg
Hallo,
Meine Meinung:
NUTZE NIE, NIE, NIE C oder C++, wenn sichere Software dabei herauskommen soll.
es sei denn, du kennst dich mit C oder C++ aus.
Pascal und Pascal-Derivate sind schneller und sicherer. :-D
Schneller?
Weiß ich nicht, kommt auf den Compiler an.
Sicherer?
Nicht unbedingt. Pascal ist zwar syntaktisch strenger als C - aber man kann auch in Pascal Unsinn treiben, wenn man nicht aufpasst.
Davon abgesehen ... mir persönlich ist Pascal zu, ähm, spießig. ;-)
So long,
Martin
Hello,
Nicht unbedingt. Pascal ist zwar syntaktisch strenger als C - aber man kann auch in Pascal Unsinn treiben, wenn man nicht aufpasst.
Eigentlich nur dann, wenn man es bewusst darauf anlegt.
Davon abgesehen ... mir persönlich ist Pascal zu, ähm, spießig. ;-)
Eben deshalb ist es in Pascal und vielen seiner Derivaten nicht möglich, unbewusst Blödsinn anzustellen.
Schneller sind die Pascal Derivat deshalb, weil ihre IDEs und Compiler gezielt auf die Plattformen abgestimmt sind, auf denen die Programme später laufen sollen. Das bedeutet aber nicht, dass die Programm mit der Reduktion auf ein Standard Instruction Set nicht portabel wären.
Man sieht aber bis heute die Portierung als aufwändigen intelligenten Schritt an und versucht nicht, wie bei C und C++, dies durch dubiose Verbiegungen automatisiert im Hintergrund vornehmen zu lassen.
Alleine die Tatsache, dass weder C noch C++ einen Überlauf auf einem 80x86 nutzbar machen, ist doch schon abschreckend genug.
Liebe Grüße aus Syburg
Tom vom Berg
Hi,
»» Nicht unbedingt. Pascal ist zwar syntaktisch strenger als C - aber man kann auch in Pascal Unsinn treiben, wenn man nicht aufpasst.
Eigentlich nur dann, wenn man es bewusst darauf anlegt.
nein, in dem Moment, wo man Betriebssystemfunktionen aufruft und damit die Kontrolle aus der Hand gibt, ist alles möglich - dann ist die Wahl der Programmiersprache unerheblich.
»» Davon abgesehen ... mir persönlich ist Pascal zu, ähm, spießig. ;-)
Eben deshalb ist es in Pascal und vielen seiner Derivaten nicht möglich, unbewusst Blödsinn anzustellen.
Ja, aber es wird einem auch erschwert, *bewusst* elegant-einfachen Code zu schreiben, selbst *wenn* man weiß, was man tut bzw. tun möchte. Mit Pascal bewegt man sich quasi auf dem Level "Englisch, fünfte Klasse", während man eigentlich fließend sprechen könnte, wenn man nur dürfte.
Schneller sind die Pascal Derivat deshalb, weil ihre IDEs und Compiler gezielt auf die Plattformen abgestimmt sind, auf denen die Programme später laufen sollen.
Das ist bei den C-Compilern teils auch so: Der Borland C-Compiler produziert vorbildlichen Code, an dem ich nur selten "von Hand" noch weitere Optimierungen vornehmen kann. Compiler, die von Haus aus plattformunabhängig sein wollen, schaffen das natürlich nicht in dem Maß.
Alleine die Tatsache, dass weder C noch C++ einen Überlauf auf einem 80x86 nutzbar machen, ist doch schon abschreckend genug.
Meinst du die Verwendung der BOUND-Anweisung[*]? Tja, die ist ja auch in der Realität problematisch, da die Unter- und Obergrenze für den Index erst ermittelt werden muss, und diese Grenzen (vor allem die Obergrenze, da die Untergrenze von pfiffigen Programmierern meist auf 0 normiert wird) als Absolutwerte bekannt sein müssen. Oft ergeben sie sich aber nur aus anderen Strukturen. Der Aufwand, diese Werte zu berechnen und dann eine BOUND-Anweisung zu verwenden, ist mindestens ebenso groß, wie die Indexwerte direkt abzuprüfen, was die BOUND-Anweisung per se zur Totgeburt erklärt. Dass manche Programmierer die Überprüfung aus Bequemlichkeit ganz weglassen, ist eine andere Geschichte.
Ciao,
Martin
[*] Die Schwierigkeit, einen aussagekräftigen Online-Beitrag über die BOUND-Anweisung zu finden, zeigt eindrucksvoll, wie wenig diese Möglichkeit wohl genutzt wird.
Hi Martin
Ja, aber es wird einem auch erschwert, *bewusst* elegant-einfachen Code zu schreiben, selbst *wenn* man weiß, was man tut bzw. tun möchte. Mit Pascal bewegt man sich quasi auf dem Level "Englisch, fünfte Klasse", während man eigentlich fließend sprechen könnte, wenn man nur dürfte.
Wie kommst du darauf, bzw. was meinst du? Es steht dir (z.B.) in Delphi doch völlig frei, ob du VCL Code einsetzt oder direkt auf die WinAPI zugreifst. Und im Zweifelsfall kannst du - sofern du masochistisch veranlagt bist - auch gerne Inline Assembler einsetzen.
Gruß
Uwe
Portland, Oregon
Hallo,
»» Ja, aber es wird einem auch erschwert, *bewusst* elegant-einfachen Code zu schreiben, selbst *wenn* man weiß, was man tut bzw. tun möchte.
Wie kommst du darauf, bzw. was meinst du? Es steht dir (z.B.) in Delphi doch völlig frei, ob du VCL Code einsetzt oder direkt auf die WinAPI zugreifst.
das meinte ich nicht, sondern die relativ strikte Syntax und die strenge Typisierung von Pascal, die es einem schwer macht, mit Datentypen zu jonglieren, die "eigentlich" kompatibel oder sogar gleichbedeutend sind, wie etwa signed und unsigned-Typen oder Zeiger auf verschiedene Typen.
Und im Zweifelsfall kannst du - sofern du masochistisch veranlagt bist - auch gerne Inline Assembler einsetzen.
Das tu ich auch gerne, weil ich *nicht* masochistisch veranlagt bin und ein paar Assembler-Anweisungen oft schneller und klarer zum Ziel führen als eine vergleichbare Pascal- oder C-Anweisung (z.B. ein Byte-Swap beim Konvertieren zwischen Little-Endian und Big-Endian).
Ciao,
Martin
Hallo Martin
...sondern die relativ strikte Syntax und die strenge Typisierung von Pascal, die es einem schwer macht, mit Datentypen zu jonglieren
Ich glaube, das ist einfach Gewohnheitssache. Pascal oder C - beide Sprachen haben ihre Vor- und Nachteile.
...und ein paar Assembler-Anweisungen oft schneller und klarer zum Ziel führen als eine vergleichbare Pascal- oder C-Anweisung
Assembler fasse ich eigentlich nur dann an, wenn es um wirklich rechenintensive und zeitkritische Sachen geht. In letzter Zeit allerdings häufiger, da ich momentan in einem Projekt involviert bin, das sich mit Grafikbearbeitung beschäftigt.
Gruß
Uwe
Portland, Oregon
Hallo,
Schneller sind die Pascal Derivat deshalb, weil ihre IDEs und Compiler gezielt auf die Plattformen abgestimmt sind, auf denen die Programme später laufen sollen.
Nein, Pascal ist garantiert nicht schneller als C/C++. Gleich schnell vielleicht, aber definitiv nicht schneller. Dazu sind C/C++-Compiler heutzutage einfach viel zu gut. Selbst der GCC, dem ja oft nachgesagt wird, er produziere nicht so tollen Code (oft zurecht), ist gerade seit der 4er-Version dramatisch besser geworden, schau Dir doch mal eine aktuelle Preview der 4.4er-Reihe an. Oder schau Dir die Compiler von Intel an, die produzieren momentan den schnellsten Code für die x86-Plattform.
Meine Intuition sagt mir eher, dass Pascal-Compiler im Zweifel eher nicht so gut sind, ganz einfach, weil Pascal im Vergleich zu C/C++ kaum noch mehr verwendet wird und deswegen lange nicht mehr so viel Optimierungsarbeit in Pascal-Compiler gesteckt wird, als in C/C++-Compiler. Mag natürlich sein, dass Pascal-Compiler dennoch so gut sind, dass sie vielleicht etwa gleich schnellen Code produzieren, aber schnelleren mit Sicherheit nicht.
Man sieht aber bis heute die Portierung als aufwändigen intelligenten Schritt an und versucht nicht, wie bei C und C++, dies durch dubiose Verbiegungen automatisiert im Hintergrund vornehmen zu lassen.
Was heißt hier "dubiose Verbiegungen"? Und Deine Aussage in Bezug auf Pascal kann ich absolut nicht nachvollziehen - das ist zumindest rein prinzipiell als Sprache sogar portabler als C/C++, weil's viel abstrakter ist...
Viele Grüße,
Christian
Hello,
Nein, Pascal ist garantiert nicht schneller als C/C++.
und Linux ist eine Scheibe
*rotfl*
Liebe Grüße aus Syburg
Tom vom Berg
Hi Christian
Meine Intuition sagt mir eher, dass Pascal-Compiler im Zweifel eher nicht so gut sind, ganz einfach, weil Pascal im Vergleich zu C/C++ kaum noch mehr verwendet wird und deswegen lange nicht mehr so viel Optimierungsarbeit in Pascal-Compiler gesteckt wird, als in C/C++-Compiler.
Irgend wie muß die Entwicklung an dir vorbeigegangen sein... ;-)
Hast du schon mal einen Blick auf Delphi2009 geworfen? Der Compiler ist Spitzenklasse, wird ständig weiterentwickelt und produziert Code, der von der Geschwindigkeit her mit C/C++ Compilern locker mithalten kann.
Viele Grüße
Uwe
Portland, Oregon
Hallo Uwe,
Meine Intuition sagt mir eher, dass Pascal-Compiler im Zweifel eher nicht so gut sind, ganz einfach, weil Pascal im Vergleich zu C/C++ kaum noch mehr verwendet wird und deswegen lange nicht mehr so viel Optimierungsarbeit in Pascal-Compiler gesteckt wird, als in C/C++-Compiler.
Irgend wie muß die Entwicklung an dir vorbeigegangen sein... ;-)
Hast du schon mal einen Blick auf Delphi2009 geworfen? Der Compiler ist Spitzenklasse, wird ständig weiterentwickelt und produziert Code, der von der Geschwindigkeit her mit C/C++ Compilern locker mithalten kann.
Ich habe ja nicht gesagt, dass Pascal-Compiler überhaupt nicht weiterentwickelt werden. ;-) Ich habe nur gesagt, dass ich mir nicht vorstellen kann, dass Pascal-Compiler besser sind als C/C++-Compiler - gleich gut: ja. Besser: nein.
Und btw: Nein, ich habe die Entwicklung von Delphi nicht mehr verfolgt. Ich hab zwar vor Ewigkeiten mal mit Delphi 1.0 gearbeitet (noch Win 3.1), aber da ich Pascal als Sprache nicht so sehr mag, hab ich dann später unter 32bit-Windows C++ Builder verwendet und als mir dann klar wurde, dass es viel durchachtere Dinge als die VCL gibt bin ich ganz von Produkten von Borland (äh. Inprise oder wie auch immer die inzwischen heißen) abgekommen.
Viele Grüße,
Christian
Hi Christian
...dass es viel durchachtere Dinge als die VCL gibt bin ich ganz von Produkten von Borland (äh. Inprise oder wie auch immer die inzwischen heißen) abgekommen.
Embarcadero heißen sie heute.
Du solltest dir wirklich mal das Trial von D2009 angucken und 'ne Weile mit der IDE und der VCL spielen. Danach schmeißt du z.B. Visual Studio weg...
Ich arbeite seit D1 beruflich mit Delphi, und jedesmal wenn ich mich mit C++ Compilern auseinanderzusetzen habe, kriege ich 'nen Krampf im Darm.
Gruß
Uwe
Portland, Oregon
Hello,
Du solltest dir wirklich mal das Trial von D2009 angucken und 'ne Weile mit der IDE und der VCL spielen. Danach schmeißt du z.B. Visual Studio weg...
Wo steht das denn auf der Website?
ist es das? http://www.embarcadero.com/products/delphi/
Liebe Grüße aus Syburg
Tom vom Berg
Hallo Martin,
Davon abgesehen ... mir persönlich ist Pascal zu, ähm, spießig. ;-)
*hehe* Du triffst meine Meinung zu der Sprache auf den Punkt. :-)
Viele Grüße,
Christian
(Der sich gerade in Fortran einarbeiten darf. *urgs*)
Hello,
(Der sich gerade in Fortran einarbeiten darf. *urgs*)
Welche Version? Welche Plattform? Welches Eingabemedium? *hämisch grins*
Liebe Grüße aus Syburg
Tom vom Berg
Hallo,
(Der sich gerade in Fortran einarbeiten darf. *urgs*)
Welche Version? Welche Plattform?
Fortran 90 unter Linux.
Welches Eingabemedium? *hämisch grins*
Haha. Nein, Lochkarten muss ich nicht mehr stanzen, keine Sorge. ;-)
Viele Grüße,
Christian
NUTZE NIE, NIE, NIE C oder C++, wenn sichere Software dabei herauskommen soll.
Pascal und Pascal-Derivate sind schneller und sicherer. :-D
Hi,
gilt das Deiner Meinung nach auch für den Embedded-Bereich?
Grüße
Stefanie
Sup!
Kann man also in Pascal keine normalen Bibliotheks-Funktionen nutzen?
Gruesse,
Bio
Hello,
Kann man also in Pascal keine normalen Bibliotheks-Funktionen nutzen?
Wenn Du mir sagst, was Du unter "normalen Bibliotheksfunktionen" verstehst und wie die Deiner Meinung nach entstehen, dann kann ich Dir vielleicht sogar noch eine Antwort geben, bevor der Thread im Archiv verschwindet.
Und um das nochmal kalrzustellen: wenn ich hier von Pascal gesprochen habe, dann sind meistens die Derivate Turbo-Pascal, Modula2 oder Delphi ff gemeint. In C und C++ wird man vermutlich auch nicht mehr auf Kernighan & Ritchie oder den ersten Elaboraten von Bjarne Stroustrup herumrutschen.
Allerdings hat Bjarne Stroustrup in mehreren Interviews selber zugegeben, dass er das Design von C++ heute ganz anders anfangen würde und auch mehr auf die Nutzbarmachung der jeweiligen Stärken der Hardwareplattformen eingehen würde, was aber durch den jahrelang verfochtenen übertriebenen Ansatz der absoluten Portabilität heute fast unmöglich ist. Auch bei C++0 (dem Nachfolger von C++) räumt er ein, zuviele Kompromisse eingegangen zu sein.
Für Turbo Pascal und Nachfolger gibt es eine Menge "Units", also Bibliotheken, die man ganz unkompliziert einbinden kann.
Liebe Grüße aus Syburg
Tom vom Berg
Sup!
»» Kann man also in Pascal keine normalen Bibliotheks-Funktionen nutzen?
Wenn Du mir sagst, was Du unter "normalen Bibliotheksfunktionen" verstehst
Die der Standard-C-Library unter Unix. Z.B. "gets".
Gruesse,
Bio
Hallo,
»» »» Kann man also in Pascal keine normalen Bibliotheks-Funktionen nutzen?
kommt auf den Compiler an ...
»» Wenn Du mir sagst, was Du unter "normalen Bibliotheksfunktionen" verstehst
Die der Standard-C-Library unter Unix. Z.B. "gets".
Meine letzten Aktivitäten mit Pascal liegen schon über 15 Jahre zurück, damals mit Borland Pascal 7.0 unter DOS und Windows 3.1 - ach, das waren noch Zeiten ...
Jedenfalls konnte man mit dem Borland-Pascal-Compiler auch beliebige Funktionen aus betriebssystemeigenen oder auch beliebigen anderen DLLs aufrufen, wenn man Code für Windows generiert hat. Und ganz im Vertrauen - ein Compiler, der keinen Code aus Fremdbibliotheken aufrufen kann, ist in meinen Augen höchstens für didaktische Zwecke brauchbar, aber nicht für die reale Praxis.
So long,
Martin
Hello,
Jedenfalls konnte man mit dem Borland-Pascal-Compiler auch beliebige Funktionen aus betriebssystemeigenen oder auch beliebigen anderen DLLs aufrufen, wenn man Code für Windows generiert hat.
Ach das meinte er. Quellen mischen.
Natürlich geht das, auf der Object-Code-Ebene auch Object-Codes aus anderen Quellen einzubinden.
Das Problem dabei ist aber immer, was die dann am Modell vorbei alles selber machen.
Gerade die C-Object-Codes sind ja deshalb nicht beliebt, weil sie, zumindest auf den PC-Plattformen, manchmal recht ungewöhnliche Dinge tun oder aber wichtige Sachen NICHT erledigen, weil die auf anderen Plattformen nicht möglich wären.
Was andere Plattformen betrifft, das weiß ich nicht. Aber die PC-Plattformen sind ja weit genug verbreitet, um dafür auch spezialisierte Programme zu erzeugen und dafür spezialisierte Developer-IDEs und Compiler zu verwenden.
Ich bin da ein entschiedener Gegner der Eierlegenden_Wollmilchsau_Programmier-Hochsprache, die bahuptet, auf allen Plattformen zu laufen. Da sind wir dann ganz schnel, bei Java und da sehen wir ja, dass die Runtime-Engines auch gravierende Unterschiede haben und außerdem die Performance oft absolut in die Knie geht.
Liebe Grüße aus dem Cyberspace
Tom vom Berg
Hallo,
»» Jedenfalls konnte man mit dem Borland-Pascal-Compiler auch beliebige Funktionen aus betriebssystemeigenen oder auch beliebigen anderen DLLs aufrufen, wenn man Code für Windows generiert hat.
Ach das meinte er. Quellen mischen.
nicht nur Quellen, sondern auch Quellen und fertigen Closed-Source-Code.
Gerade die C-Object-Codes sind ja deshalb nicht beliebt, weil sie, zumindest auf den PC-Plattformen, manchmal recht ungewöhnliche Dinge tun oder aber wichtige Sachen NICHT erledigen, weil die auf anderen Plattformen nicht möglich wären.
Nanu? Mir scheint, du redest von Code, der von Unwissenden produziert wurde.
Ich bin da ein entschiedener Gegner der Eierlegenden_Wollmilchsau_Programmier-Hochsprache, die bahuptet, auf allen Plattformen zu laufen. Da sind wir dann ganz schnel, bei Java und da sehen wir ja, dass die Runtime-Engines auch gravierende Unterschiede haben und außerdem die Performance oft absolut in die Knie geht.
Da bin ich hundertprozentig deiner Meinung: Eine Software wird immer für eine bestimmte Zielplattform geschrieben, auch wenn diese Zielplattform dann abstrakt sein kann, etwa eine JVM. Daher finde ich es auch richtig, Eigenschaften dieser Zielplattform auch zu nutzen (und ggf. auf diese Zielplattform hin zu optimieren).
Man kann Software dort plattformunabhängig schreiben, wo es auf den reinen Algorithmus ankommt. Aber sobald es um Schnittstellen zur Außenwelt geht, kommt immer eine gewisse Plattformabhängigkeit ins Spiel.
Liebe Grüße aus dem Cyberspace
Heute nicht aus Syburg?
Ciao,
Martin
Hello,
Heute nicht aus Syburg?
Ach, den Gerüchten nach schließt das Casino hier auch bald, da kann ich auch auf meinen Berg zurück gehen :-)
Liebe Grüße aus dem Cyberspace
Tom vom Berg
ALSO: NUTZE NIE, NIE, NIE gets(). NIE. UNTER KEINEN UMSTÄNDEN. Das ist eine der wenigen Funktionen, vor der man IMMER abraten muss. IMMER. Mein Linker warnt mich sogar davor:
main.c:(.text+0x6d): warning: the `gets' function is dangerous and should not be used.
Ok, gespeichert. Mein Compiler gibt auch eine Warnung raus, habe ich aber wegen Unwissenheit nicht beachtet.
Funktioniert jetzt tadellos.
Gruß
Mark