QT signals und slots
Joachim Häfner
Dies ist aus der Doku von QT:
class Foo : public QObject
{
Q_OBJECT
public:
Foo();
int value() const { return val; }
public slots:
void setValue( int );
signals:
void valueChanged( int );
private:
int val;
};
Ich frage mich, wie erreicht wird, dass der Compiler die Ausdrücke
Q_OBJECT, [private, protected, public] slots:, und signals: versteht.
Makros?
Grüße,
Joachim
Ullrich von Bassewitz
> Ich frage mich, wie erreicht wird, dass der Compiler die Ausdrücke
> Q_OBJECT, [private, protected, public] slots:, und signals: versteht.
> Makros?
Q_OBJECT ist vermutlich ein Macro, alles andere loest der Praeprozessor auf
(moc heisst der glaube ich).
Gruss
Uz
--
Ullrich von Bassewitz u...@musoftware.de
Florian Weimer
> Joachim Häfner <joa_h...@web.de> wrote:
> > Ich frage mich, wie erreicht wird, dass der Compiler die Ausdrücke
>> Q_OBJECT, [private, protected, public] slots:, und signals: versteht.
>> Makros?
>
> Q_OBJECT ist vermutlich ein Macro, alles andere loest der Praeprozessor auf
> (moc heisst der glaube ich).
Nein, allesamt sind das mittlerweile Makros. moc generiert seit nur
noch ein paar Methodendefinitionen, die man zu seinem Code hinzulinken
muß. Es handelt sich nicht mehr um einen Präprozessor.
Jan Schaumann
[code snipped]
> Ich frage mich, wie erreicht wird, dass der Compiler die Ausdrücke
> Q_OBJECT, [private, protected, public] slots:, und signals: versteht.
> Makros?
Wenn deine Frage ist: "wie kann ich das compilen", dann schau dir mal
http://www.netmeister.org/misc/HOWTOS/Compiling-Your-First-Qt-App-HOWTO/
an.
Wenn deine Frage jedoch tatsaechlich ist, wie DU deinem Compiler
beibringen kannst selbige Macros (oder auch nicht) zu verstehen, dann
musst du dich mit Compiler-Bau beschaeftigen.
:)
-Jan
--
Jan Schaumann <http://www.netmeister.org>
"Ford," he said, "you're turning into a penguin. Stop it."
Ludwig Pumberger
> > > Ich frage mich, wie erreicht wird, dass der Compiler die Ausdrücke
> >> Q_OBJECT, [private, protected, public] slots:, und signals: versteht.
> >> Makros?
> >
> > Q_OBJECT ist vermutlich ein Macro, alles andere loest der Praeprozessor
auf
> > (moc heisst der glaube ich).
>
> Nein, allesamt sind das mittlerweile Makros. moc generiert seit nur
> noch ein paar Methodendefinitionen, die man zu seinem Code hinzulinken
> muß. Es handelt sich nicht mehr um einen Präprozessor.
Wie soll ein Makro definiert sein das sich zwischen public und :
einschleicht?
Ullrich von Bassewitz
> Nein, allesamt sind das mittlerweile Makros. moc generiert seit nur
> noch ein paar Methodendefinitionen, die man zu seinem Code hinzulinken
> muß. Es handelt sich nicht mehr um einen Präprozessor.
Das kommt mir aeusserst unwahrscheinlich vor.
Wie koennte Deiner Meinung nach ein Macro mit dem Namen "public slots:"
implementiert sein? Ausserdem muss dieser Macro noch erkennen koennen, wo die
mit "public slots:" angefangene Section aufhoert, weil die dazwischen
deklarierten Methoden ja eine spezielle Behandlung brauchen.
Florian Weimer
> Wie soll ein Makro definiert sein das sich zwischen public und :
> einschleicht?
#define slots
| replacement-list:
| pp-tokens_{opt}
(Abschnitt 16, ISO/IEC 14882:1998, 'Programming languages - C++')
| A preprocessing directive of the form
|
| # define identifier replacement-list new-line
|
| defines an object-like macro that causes each subsequent instance
| of the macro name[...] to be replaced by the replacement list of
| preprocessing tokens that constitute the remainder of the
| directive.[...]
(16.3, a.a.O.)
Florian Weimer
> Florian Weimer <f...@deneb.enyo.de> wrote:
> > Nein, allesamt sind das mittlerweile Makros. moc generiert seit nur
>> noch ein paar Methodendefinitionen, die man zu seinem Code hinzulinken
>> muß. Es handelt sich nicht mehr um einen Präprozessor.
>
> Das kommt mir aeusserst unwahrscheinlich vor.
Ist aber inzwischen so. Ich habe mir gerade extra eine Qt-Anwendung
angeschaut. Früher war das vielleicht anders.
> Wie koennte Deiner Meinung nach ein Macro mit dem Namen "public slots:"
> implementiert sein?
Das Makro trägt den Namen 'slots'.
> Ausserdem muss dieser Macro noch erkennen koennen, wo die mit
> "public slots:" angefangene Section aufhoert, weil die dazwischen
> deklarierten Methoden ja eine spezielle Behandlung brauchen.
Diese spezielle Behandlung besteht nur in der Generierung von
Metainformationen durch moc. Die Deklaration selbst wird ohne weitere
Aufbereitung vom C++-Präprozessor und -Compiler verarbeitet; die
Header-Datei mit dem 'public slots:' wird das normal per '#include'
eingebunden.
Ullrich von Bassewitz
>> Wie soll ein Makro definiert sein das sich zwischen public und :
>> einschleicht?
>
> #define slots
Nur dass Dein Macro nichts tut, und deshalb auch kaum fuer die besondere
Kennzeichnungs von "public slots" verantwortlich sein kann. Rein formal ist
die Frage damit zwar beantwortet, aber es belegt Deine Behauptung trotzdem
nicht:-)
Florian Weimer
> Florian Weimer <f...@deneb.enyo.de> wrote:
> >> Wie soll ein Makro definiert sein das sich zwischen public und :
>>> einschleicht?
>>
>> #define slots
>
> Nur dass Dein Macro nichts tut, und deshalb auch kaum fuer die besondere
> Kennzeichnungs von "public slots" verantwortlich sein kann.
Diese besondere Kennzeichnung ist bei der Übersetzung mit dem
C++-Compiler nicht notwendig. Lies die Manpage von moc(1) oder die
Quellen einer beliebigen Qt-Applikation, die auch eigene Widgets
definiert, wenn Du mir nicht glaubst.
Joachim Häfner
gibt er diese an den Compiler weiter, als ASCII-Datei? Könnte man diese
zwischendurch "abfangen", so dass man sehen kann, was der Preprozessor mit
der Eingabe gemacht hat. Mich würde interessieren, wie aus C++ + QT reines
C++ wird.
Grüße,
Joachim
Anselm Lingnau
> Nachdem ein Preprozessor eine Eingabedatei bearbeitet hat: In welcher Form
> gibt er diese an den Compiler weiter, als ASCII-Datei? Könnte man diese
> zwischendurch "abfangen", so dass man sehen kann, was der Preprozessor mit
> der Eingabe gemacht hat.
$ man g++
...
-E Stop after the preprocessing stage; do not run the
compiler proper. The output is preprocessed source
code, which is sent to the standard output.
Das Ergebnis ist aber mit einiger Sicherheit nichts, was man als
»leserlich« bezeichnen sollte.
Anselm
--
Anselm Lingnau .......................................... ans...@strathspey.org
C makes it easy to shoot yourself in the foot, C++ makes it harder, but when
you do, it blows away your whole leg -- Bjarne Stroustrup
Felix von Leitner
> Das Ergebnis ist aber mit einiger Sicherheit nichts, was man als
> »leserlich« bezeichnen sollte.
Kommt auf die libc an.
Felix
Frank Klemm
>Joachim Häfner <joa_h...@web.de> schrieb:
>
>> Nachdem ein Preprozessor eine Eingabedatei bearbeitet hat: In welcher Form
>> gibt er diese an den Compiler weiter, als ASCII-Datei? Könnte man diese
>> zwischendurch "abfangen", so dass man sehen kann, was der Preprozessor mit
>> der Eingabe gemacht hat.
>
> $ man g++
> ...
> -E Stop after the preprocessing stage; do not run the
> compiler proper. The output is preprocessed source
> code, which is sent to the standard output.
>
>Das Ergebnis ist aber mit einiger Sicherheit nichts, was man als
>»leserlich« bezeichnen sollte.
>
Code durcheschlagen hat, sollte der Rest ziemlich lesbar sein.
Das Hauptproblem ist eher dieses Gemüse am Anfang:
# 4 "mppdec.c"
# 1 "/usr/include/time.h" 1 3
# 28 "/usr/include/time.h" 3
# 1 "/usr/include/features.h" 1 3
# 250 "/usr/include/features.h" 3
# 1 "/usr/include/sys/cdefs.h" 1 3
# 251 "/usr/include/features.h" 2 3
# 278 "/usr/include/features.h" 3
# 1 "/usr/include/gnu/stubs.h" 1 3
# 279 "/usr/include/features.h" 2 3
# 29 "/usr/include/time.h" 2 3
# 38 "/usr/include/time.h" 3
# 1 "/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0/include/stddef.h" 1 3
# 199 "/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0/include/stddef.h" 3
typedef unsigned int size_t;
# 39 "/usr/include/time.h" 2 3
# 1 "/usr/include/bits/time.h" 1 3
# 43 "/usr/include/time.h" 2 3
# 57 "/usr/include/time.h" 3
# 1 "/usr/include/bits/types.h" 1 3
# 26 "/usr/include/bits/types.h" 3
# 1 "/usr/include/features.h" 1 3
# 27 "/usr/include/bits/types.h" 2 3
# 1 "/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0/include/stddef.h" 1 3
# 30 "/usr/include/bits/types.h" 2 3
da einen nicht abschrecken darf. Manche Programme werden erst NACH Verwendung des Präprozessors
lesbar.
--
Frank
Jens Schweikhardt
in <slrn9polv...@c.zeiss.de>:
Anselm:
#> $ man g++
#> ...
#> -E Stop after the preprocessing stage; do not run the
#> compiler proper. The output is preprocessed source
#> code, which is sent to the standard output.
#>
#>Das Ergebnis ist aber mit einiger Sicherheit nichts, was man als
#>»leserlich« bezeichnen sollte.
#>
# Wenn nicht mit Macros gewüstet wird und wenn man sich bis zum ersten eigenen
# Code durcheschlagen hat, sollte der Rest ziemlich lesbar sein.
#
# Das Hauptproblem ist eher dieses Gemüse am Anfang:
#
# # 4 "mppdec.c"
# # 1 "/usr/include/time.h" 1 3
$ info --index-search="Preprocessor Options" gcc
...
`-P'
Tell the preprocessor not to generate `#line' directives. Used
with the `-E' option.
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Frank Klemm
>
>$ info --index-search="Preprocessor Options" gcc
>
>...
>
>`-P'
> Tell the preprocessor not to generate `#line' directives. Used
> with the `-E' option.
>
Gibt es noch eine Option zum Entfernen von mehrfachen Leerzeilen?
--
Frank Klemm
Anselm Lingnau
> Gibt es noch eine Option zum Entfernen von mehrfachen Leerzeilen?
Das ist nicht der Unix-Weg®. Wir haben »uniq(1)«.
Anselm
--
Anselm Lingnau .......................................... ans...@strathspey.org
If you're only interested in money, at least be honest about it and become a
stockbroker. -- Daniel Smith
Frank Klemm
>Frank Klemm <p...@uni-jena.de> schrieb:
>
>> Gibt es noch eine Option zum Entfernen von mehrfachen Leerzeilen?
>
>Das ist nicht der Unix-Weg®. Wir haben »uniq(1)«.
>
Es darf auf keinen Fall richtig funcktionieren.
uniq geht nicht. sed geht nicht. Ich habe kein Tool gefunden, daß so etwas
kann. Und in der Zeit habe ich schneller eine bugfreie C Lösung geschrieben.
--
Frank Klemm
Andreas Lobinger
Frank Klemm schrieb:
> >> Gibt es noch eine Option zum Entfernen von mehrfachen Leerzeilen?
> >Das ist nicht der Unix-Weg®. Wir haben »uniq(1)«.
> uniq geht nicht. sed geht nicht. Ich habe kein Tool gefunden, daß so etwas
> kann. Und in der Zeit habe ich schneller eine bugfreie C Lösung geschrieben.
Gebe er ein Beispiel an in dem uniq und sed (ich denke mal das Beispielskript aus
der man-page) zuverlässig nicht funktionieren und die Falschbenutzung durch den
User ausgeschlossen werden kann ,,,
Einen Tag wünschend
LOBI
P.S. sollte jemand tatsächlich das 'fröhliche' vermissen ...
Frank Klemm
>Aloha,
>
>Frank Klemm schrieb:
>> >> Gibt es noch eine Option zum Entfernen von mehrfachen Leerzeilen?
>> >Das ist nicht der Unix-Weg®. Wir haben »uniq(1)«.
>> uniq geht nicht. sed geht nicht. Ich habe kein Tool gefunden, daß so etwas
>> kann. Und in der Zeit habe ich schneller eine bugfreie C Lösung geschrieben.
>
>Gebe er ein Beispiel an in dem uniq und sed (ich denke mal das Beispielskript aus
>der man-page) zuverlässig nicht funktionieren und die Falschbenutzung durch den
>User ausgeschlossen werden kann ,,,
>
char* p;
char* q;
int
main ( void )
{
*p++ = *q++;
*p++ = *q++;
printf ("Hallo.\n");
printf ("Hallo.\n");
printf ("Hallo!!!\n");
return 0;
}
--
Frank Klemm
Anselm Lingnau
> uniq geht nicht. sed geht nicht. Ich habe kein Tool gefunden, daß so
> etwas kann.
Könntest Du das mal präzisieren? Gemäß der landläufigen Definition ist
eine »Leerzeile« eine, die nur ein Newline-Zeichen enthält. Wenn in
einer Datei mehrere solche Zeilen hintereinanderstehen, macht uniq(1)
zumindest auf meinem Rechner (mit GNU textutils 2.0) daraus
zuverlässig eine einzige.
Wenn eine »Leerzeile« für Dich außer dem Newline-Zeichen noch
beliebigen Leerraum (Leerzeichen und Tabs) enthalten darf, dann
entfernt uniq(1) aufeinanderfolgende Leerzeichen mitunter nicht
richtig, da sie zwar gleich aussehen, aber unterschiedliche Zeichen
enthalten können. Das ist dann aber auch nicht weiter überraschend,
denn für sowas ist uniq(1) auch nicht gedacht. Hier könnte man zum
Beispiel auf Perl zurückgreifen, um die Leerzeilen zuerst in eine
kanonische Form zu überführen, damit uniq(1) seine Arbeit tun kann.
... | perl -pe 's/^\s*$/\n/' | uniq
(sed ginge bestimmt auch, aber ich schreibe lieber Perl.)
Alles das ist nicht unbedingt »rocket science« -- im Gegenteil, es ist
nur eine konsequente Anwendung der Unix-Philosophie. »gcc -E« braucht
keine Option zum Unterdrücken aufeinanderfolgender Leerzeilen »modulo
Leerraum«, und ein spezielles Programm dafür ist auch nicht
nötig. QED.
Anselm
--
Anselm Lingnau .......................................... ans...@strathspey.org
Military intelligence is a contradiction in terms. -- Groucho Marx
Frank Klemm
>Frank Klemm <p...@uni-jena.de> schrieb:
>
>> uniq geht nicht. sed geht nicht. Ich habe kein Tool gefunden, daß so
>> etwas kann.
>
> Könntest Du das mal präzisieren? Gemäß der landläufigen Definition ist
> eine »Leerzeile« eine, die nur ein Newline-Zeichen enthält. Wenn in
> einer Datei mehrere solche Zeilen hintereinanderstehen, macht uniq(1)
> zumindest auf meinem Rechner (mit GNU textutils 2.0) daraus
> zuverlässig eine einzige.
>
Leerzeichen zusammenfaßt oder welches Leerzeilen entfernt.
>
> Wenn eine »Leerzeile« für Dich außer dem Newline-Zeichen noch
> beliebigen Leerraum (Leerzeichen und Tabs) enthalten darf, dann
> entfernt uniq(1) aufeinanderfolgende Leerzeichen mitunter nicht
> richtig, da sie zwar gleich aussehen, aber unterschiedliche Zeichen
> enthalten können. Das ist dann aber auch nicht weiter überraschend,
> denn für sowas ist uniq(1) auch nicht gedacht.
>
Das ist ein ganz anderes Problem, daß aber auch schon ein anderes Tool
erledigt. Entfernt '\r', konvertiert Tabulatoren und entfernt überschüssige
Leerzeichen am Ende einer Zeile entfernt.
> Hier könnte man zum Beispiel auf Perl zurückgreifen, um die Leerzeilen
> zuerst in eine kanonische Form zu überführen, damit uniq(1) seine Arbeit
> tun kann.
>
> ... | perl -pe 's/^\s*$/\n/' | uniq
>
> (sed ginge bestimmt auch, aber ich schreibe lieber Perl.)
>
Unixoid. Dinge müssen unbedingt:
- nur so zu 99% funktionieren
- der Fehler darf nicht sofort sichtbar sein
- es dürfen Hausmittelchen wie sed, awk und uniq benutzt werden
> Alles das ist nicht unbedingt »rocket science« -- im Gegenteil, es ist
> nur eine konsequente Anwendung der Unix-Philosophie. »gcc -E« braucht
> keine Option zum Unterdrücken aufeinanderfolgender Leerzeilen »modulo
> Leerraum«, und ein spezielles Programm dafür ist auch nicht
> nötig. QED.
>
QED kannst Du streichen. Gegenbeispiel:
#include <stdio.h>
int main ()
{
FILE* fp = fopen ( "test", "w");
fprintf ( fp, "Test");
fprintf ( fp, "Test");
*p++ = *q++;
*p++ = *q++;
return 0;
}
uniq macht Unsinn, Dein Script macht Unsinn.
Ich will das präprozessierte zwar im allgemeinen nicht kompilieren, aber
solche "Lösungen" sind das, was Unix den so unverwechselbaren Duft gibt.
Gerade ACE+TAO vom Wustl-Schmidt auf Windows 2000 installiert. Einiges
funktioniert nicht. Ich habe es nach C:\Program Files\ACE_TAO installiert.
Es hagelte Beschwerden, daß es nicht auf C:\Program zugreifen konnte.
Das ist wie eine Klärgrube im Hochsommer.
--
Frank Klemm
Florian Weimer
> On 11 Sep 2001 15:15:31 +0000, Anselm Lingnau <anselm...@strathspey.org> wrote:
> >Frank Klemm <p...@uni-jena.de> schrieb:
>>
>>> Gibt es noch eine Option zum Entfernen von mehrfachen Leerzeilen?
>>
>>Das ist nicht der Unix-Weg®. Wir haben »uniq(1)«.
>>
> Ja, der Unix-Weg® ist: Wir machen es buggy.
> Es darf auf keinen Fall richtig funcktionieren.
>
> uniq geht nicht. sed geht nicht.
sed -n -e ':s
/^$/bf
p
n
bs
:f
p
:g
n
/^$/bg
bs'
Nicht richtig getestet.
Frank Klemm
>
>> uniq geht nicht. sed geht nicht.
>
> sed -n -e ':s
> /^$/bf
> p
> n
> bs
> :f
> p
> :g
> n
> /^$/bg
> bs'
>
>
--
Frank Klemm
Andreas Lobinger
Frank Klemm schrieb:
> On Wed, 12 Sep 2001 11:00:00 +0200, Andreas Lobinger <Andreas....@netsurf.de> wrote:
> >Frank Klemm schrieb:
> >> >> Gibt es noch eine Option zum Entfernen von mehrfachen Leerzeilen?
> >> >Das ist nicht der Unix-Weg®. Wir haben »uniq(1)«.
> >> uniq geht nicht. sed geht nicht. Ich habe kein Tool gefunden, daß so etwas
> >> kann. Und in der Zeit habe ich schneller eine bugfreie C Lösung geschrieben.
> >
> >Gebe er ein Beispiel an in dem uniq und sed (ich denke mal das Beispielskript aus
> >der man-page) zuverlässig nicht funktionieren und die Falschbenutzung durch den
> >User ausgeschlossen werden kann ,,,
> >
>
... c-prgramm mit zweimal zwei gleichen Zeilen ...
Was meinst du eigentlich was 'Falschbenutzung durch den User ausgeschlossen'
meint ?
uniq tut das, was in den man-pages erklärt ist, und das hundertprozentig. Punkt.
Das es nicht das tut, was DU willst, sehe ich eher als Defizit auf deiner Seite, wer
lesen kann ist mal wieder klar im Vorteil.
Wer Nebeneffekte, wie das ausblenden von exact gleichen Codezeilen vermeiden will,
schreibt eben ein sed-skript. Oder informiert sich via uniq -d. Oder nimmt awk
zur Hand. (z.B. sollte gawk '/[:graph:]/' funktionieren in deinem Sinne, ungetestet)
Anselm Lingnau
> Unixoid. Dinge müssen unbedingt:
>
> - nur so zu 99% funktionieren
> - der Fehler darf nicht sofort sichtbar sein
> - es dürfen Hausmittelchen wie sed, awk und uniq benutzt werden
Müssen nicht, reichen aber oft (Merkwürdigkeiten mit der
Makroexpansion werden wohl trotzdem gefunden, und übersetzen kann man
seinen Code ja durchaus einfacher). Wenn man es 100% will, muß man
halt ein bißchen mehr Perl schreiben:
#!/usr/bin/perl -n
# Ersetzt aufeinanderfolgende Leerraum-Zeilen durch eine einzige
print unless s/^\s*$/\n/ && $prev_empty;
$prev_empty = /^\s*$/;
Immer noch keine rocket science und auch kein Grund zum Lamentieren
darüber, wie böse doch die Welt ist.
> Gerade ACE+TAO vom Wustl-Schmidt auf Windows 2000 installiert. Einiges
> funktioniert nicht. Ich habe es nach C:\Program Files\ACE_TAO installiert.
> Es hagelte Beschwerden, daß es nicht auf C:\Program zugreifen konnte.
Was hat das mit dem Thema zu tun?
Anselm
--
Anselm Lingnau .......................................... ans...@strathspey.org
If you import antimatter into the United States, does the Customs Service
pay you? -- Jordin Kare
Felix von Leitner
> uniq geht nicht. sed geht nicht.
Was ist dein Problem mit "less -s"?
Felix
Florian Weimer
Dasselbe wie mit 'cat -s', vermute ich.
Frank Klemm
>Aloha,
>
>Frank Klemm schrieb:
>> On Wed, 12 Sep 2001 11:00:00 +0200, Andreas Lobinger <Andreas....@netsurf.de> wrote:
>> >Frank Klemm schrieb:
>> >> >> Gibt es noch eine Option zum Entfernen von mehrfachen Leerzeilen?
>> >> >Das ist nicht der Unix-Weg®. Wir haben »uniq(1)«.
>> >> uniq geht nicht. sed geht nicht. Ich habe kein Tool gefunden, daß so etwas
>> >> kann. Und in der Zeit habe ich schneller eine bugfreie C Lösung geschrieben.
>> >
>> >Gebe er ein Beispiel an in dem uniq und sed (ich denke mal das Beispielskript aus
>> >der man-page) zuverlässig nicht funktionieren und die Falschbenutzung durch den
>> >User ausgeschlossen werden kann ,,,
>> >
>>
>... c-prgramm mit zweimal zwei gleichen Zeilen ...
>
> Was meinst du eigentlich was 'Falschbenutzung durch den User ausgeschlossen'
> meint ?
>
identische Zeilen enthält? Ist das dann kein gültiges C-Programm mehr?
Was ist Falschbenutzung? Wenn er nicht die Buglisten aller Programme kennt?
> uniq tut das, was in den man-pages erklärt ist, und das hundertprozentig.
>
Uniq ist nicht der schuldige. Es ist nur eben mal mißbraucht worden.
> Punkt.
>
Richtig.
> Das es nicht das tut, was DU willst, sehe ich eher als Defizit auf deiner Seite, wer
> lesen kann ist mal wieder klar im Vorteil.
>
Es liegt zumindest an dieser Stelle kein Defizit auf meiner Seite vor.
Der Vorschlag mit uniq kam nicht von meiner Seite. Die fehlerhaften Lösungen
kamen von anderen Seiten. Wobei ich jetzt nicht weiß, ob die Fehler nicht
gesehen worden oder ob sie bewußt übersehen worden, weil es ja meistens gut
geht und das ist ja bekanntlich gut genug.
> Wer Nebeneffekte, wie das ausblenden von exact gleichen Codezeilen vermeiden will,
> schreibt eben ein sed-skript. Oder informiert sich via uniq -d. Oder nimmt awk
> zur Hand. (z.B. sollte gawk '/[:graph:]/' funktionieren in deinem Sinne, ungetestet)
>
Ja, und das ist dann schon wieder ziemlich die gegenteilige Aussage zu, man
brauche keine Option zum Entfernen von Mehrfachleerzeilen, weil das SO
EINFACH ist. Schätze mal den Prozentsatz an gcc-Benutzern, die so einen
Script nicht in 5 Minuten fehlerfrei hinbekommen, nicht in 30 Minuten
fehlerfrei hinbekommen?
--
Frank Klemm
Andreas Lobinger
Frank Klemm schrieb:
> On Wed, 12 Sep 2001 14:25:03 +0200, Andreas Lobinger <Andreas....@netsurf.de> wrote:
> >Frank Klemm schrieb:
> >> On Wed, 12 Sep 2001 11:00:00 +0200, Andreas Lobinger <Andreas....@netsurf.de>
> >> >Gebe er ein Beispiel an in dem uniq und sed (ich denke mal das Beispielskript aus
> >> >der man-page) zuverlässig nicht funktionieren und die Falschbenutzung durch den
> >> >User ausgeschlossen werden kann ,,,
> >> >
> >>
> >... c-prgramm mit zweimal zwei gleichen Zeilen ...
> >
> > Was meinst du eigentlich was 'Falschbenutzung durch den User ausgeschlossen'
> > meint ?
> >
> Was ist an einem C-Programm falsch wenn es zwei aufeinanderfolgende
> identische Zeilen enthält? Ist das dann kein gültiges C-Programm mehr?
>
> Was ist Falschbenutzung? Wenn er nicht die Buglisten aller Programme kennt?
(ich weiss eigentlich nicht warum ich mir das antue, aber mal weiter ...)
Also, auf meinem System hier bringt man uniq spätestens in der
dritten Zeile : uniq - report or filter out repeated lines in a file
Daraus schließe ich (messerscharf):
a) uniq arbeitet zeilenweise
b) irgendetwas passiert mit gleichen Zeilen
Und mir stellen sich (normalerweise in Bruchteilen einer Sekunde) die Fragen:
a) Gibts irgendwelche Einschränkungen in Bezug auf die Zeilen- oder Dateistruktur?
b) Was sind in uniqs Sinne gleiche Zeilen?
c) Gibts eine Möglichkeit die Arbeitweise zu überprüfen oder darzustellen?
Und aus deinem Gelödel hier (tschulljung) liest man deutlich heraus, das du
auf jeden Fall zu Transformationsleitungen aus den Antworten zu 2a und 2b
nicht fähig bist, oder du tust jedenfalls so.
> > uniq tut das, was in den man-pages erklärt ist, und das hundertprozentig.
> Uniq ist nicht der schuldige. Es ist nur eben mal mißbraucht worden.
Die Antwort von Anselm mit uniq wäre die Lösung war natürlich ein Schnellschuß.
Aber tatsächlich funktioniert es ja auch. Es gibt Nebeneffekte, die aber deutlich
der Naivität des Benutzers entspringen ein Werkzeug ohne weitere Kenntnisse darüber
einzusetzen. (Eine weitere Ausgestatung der Szenerie hier, die mir im Kopf herum
geht und in der u.a. die Stichworte Wanddurchbruch, Bohrhammer, Dynamit und Rigips
vorkommen lass ich jetzt mal, weil das eigentlich nur albern werden wird.)
> Es liegt zumindest an dieser Stelle kein Defizit auf meiner Seite vor.
> Der Vorschlag mit uniq kam nicht von meiner Seite. Die fehlerhaften Lösungen
> kamen von anderen Seiten. Wobei ich jetzt nicht weiß, ob die Fehler nicht
> gesehen worden oder ob sie bewußt übersehen worden, weil es ja meistens gut
> geht und das ist ja bekanntlich gut genug.
s.o.
> > Wer Nebeneffekte, wie das ausblenden von exact gleichen Codezeilen vermeiden will,
> > schreibt eben ein sed-skript. Oder informiert sich via uniq -d. Oder nimmt awk
> > zur Hand. (z.B. sollte gawk '/[:graph:]/' funktionieren in deinem Sinne, ungetestet)
> Ja, und das ist dann schon wieder ziemlich die gegenteilige Aussage zu, man
> brauche keine Option zum Entfernen von Mehrfachleerzeilen, weil das SO
> EINFACH ist. Schätze mal den Prozentsatz an gcc-Benutzern, die so ein
> Script nicht in 5 Minuten fehlerfrei hinbekommen, nicht in 30 Minuten
> fehlerfrei hinbekommen?
Aber schätze er mal den Prozentsatz an realen Programmen, die exact gleiche
Programmzeilen aufeinanderfolgen lassen. Und schätze er auch mal die Häufigkeit
der Notwendigkeit den Präprozessoroutput durchzuarbeiten.
Meine Anwort zur Frage, wie man den Präprozessoroutput lesbar hinbekommt, wäre auch
gcc -E -P | cb gewesen, aber dann wäre ja auch wieder ein großes Wehklagen gewesen,
das auf deinem System kein cb existiert und und und ...
Einen fröhlichen Tag wünschend
LOBI
Stefan Reuther
Frank Klemm <p...@c.zeiss.de> wrote:
> Ich habe kein Tool gefunden, welches Rudel von Leerzeichen zu einem
> Leerzeichen zusammenfaßt oder welches Leerzeilen entfernt.
Mehrfache Leerzeilen entfernen: cat -s
-s, --squeeze-blank
never more than one single blank line
cat aus GNU textutils 2.0, falls das was ausmacht.
War doch gar nicht so schwer, oder?
Stefan