sub isBot($)
{
my ($useragent) = @_;
...
Was meint denn das $ ?
Hab schon ein bissl geBᅵcherT aber nix entdeckt...
Danke ;)
> Gestern gefunden...
> Verstᅵndnisfrage.
>
> sub isBot($)
> {
> my ($useragent) = @_;
>
> ...
>
> Was meint denn das $ ?
Guckst Du hier:
http://perldoc.perl.org/perlsub.html#Prototypes
Gruᅵ, Helmut
--
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn
Das "$" besagt, dass an die Funktion genau ein Wert zu �bergeben ist, der im
skalaren Kontext ausgewertet wird.
Achtung: entgegen langl�ufigen Meinungen hei�t das NICHT, dass nur eine
Skalarvariable oder eine skalarer Wert �bergeben werden kann. Im obigen
Beispiel w�re zB. auch der Aufruf
isBot(@INC);
zul�ssig - die �bergabe an die Funktion w�re dann die Zahl an Arrayelementen
von @INC (d.h., dasselbe wie "scalar @INC").
Wird die Funktion ohne Argument oder mit mehr als einem Argument aufgerufen,
bricht der Parser mit einem Fehler ab.
Mehr unter perldoc perlsub, Abschnitt "Prototypes".
LG, Ferry
--
Ing. Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolh...@wien.gv.at
danke euch beiden fᅵr die Aufklᅵrung ;)
und den Tipp wos weiter geht.
VG!
> > Mehr unter perldoc perlsub, Abschnitt "Prototypes".
> danke euch beiden für die Aufklärung ;)
Zur Vollständigkeit sei hier auch noch kurz auf die Gefahren bei der
Verwendung von Prototypen hingewiesen:
Message-ID: <3796...@cs.colorado.edu>
http://groups.google.com/group/comp.lang.perl.modules/msg/84484de5eb01085b?dmode=source&output=gplain
Diese verhalten sich unter Perl anders als erwartet, wenn man von
typsicheren Sprachen wie C++ kommt.
Kurzum, mit der sub foo ($) Syntax ist eher ein impliziter Cast gemeint,
weshalb auch ein Aufruf foo(@array) möglich ist.
Gruß,
Paolo
C++ kann ich nicht. Es ist aber ziemlich genau das, was man erwartet,
wenn man von C kommt (zumindest, wenn man C verstanden hat).
> Kurzum, mit der sub foo ($) Syntax ist eher ein impliziter Cast gemeint,
> weshalb auch ein Aufruf foo(@array) m�glich ist.
Genau das ist es in C auch.
void foo(int c, double x);
foo(3.5, 'a');
macht im Prinzip nichts anderes als:
{
int c = 3.5;
double x = 'a';
/* body of foo */
}
und da das zuweisungskompatible Typen sind, geht das.
Nat�rlich gibt es in C sehr viele Typen, die nicht zuweisungskompatibel
sind: Wenn ich versuche, einen Pointer einem Integer zuzuweisen,
bekomme ich zumindest eine Warnung, wenn nicht einen Fehler. Wenn ich
eine Struct einem Double zuweisen m�chte, bekomme ich sicher einen
Fehler.
Und hier liegt der gro�e Unterschied zu Perl. Zwar ist auch hier
sub foo($);
foo(%ENV);
�quivalent zu
{
$tmp = %ENV;
local @_ = ($tmp);
# body of foo
}
aber in Perl ist ein Hash zuweisungskompatibel zu einem Skalar. Das
Ergebnis ist ein String, der die Anzahl der Elemente und der Buckets
enth�lt. Wahrscheinlich nicht das, was man sich erwartet ...
Der Unterschied zwischen Perl und C ist also nicht so sehr, dass sich
Prototypes anders verhalten w�rden (sie verhalten sich genau gleich,
wenn man davon absieht, dass Perl einen Prototyp nach der ersten
Verwendung kommentarlos hinnimmt, die meisten C-Compiler aber nicht),
sondern dass die Zuweisung anders funktioniert: Perl hat nur wenige
Typen und die sind alle untereinander zuweisungskompatibel. C hat viel
mehr und nur einige wenige davon sind untereinander
zuweisungskompatibel.
Toms Kritik geht hier also IMHO ins Leere: Wenn in das bei Prototypes
st�rt, m�sste es ihn auch bei der Zuweisung st�ren. Ok, Perl ist nicht
sonderlich konsistent, also warum sollten es Perl-Programmierer sein?
;-)
hp
>
> C++ kann ich nicht. Es ist aber ziemlich genau das, was man erwartet,
> wenn man von C kommt (zumindest, wenn man C verstanden hat).
>
>> Kurzum, mit der sub foo ($) Syntax ist eher ein impliziter Cast gemeint,
>> weshalb auch ein Aufruf foo(@array) m�glich ist.
>
> Genau das ist es in C auch.
>
> void foo(int c, double x);
> foo(3.5, 'a');
>
> macht im Prinzip nichts anderes als:
>
> {
> int c = 3.5;
> double x = 'a';
> /* body of foo */
> }
>
> und da das zuweisungskompatible Typen sind, geht das.
[...]
Ich erwarte vom C-Compiler eine Warnung und genau das passiert auch
in meiner Entwicklungsumgebung. Dieser implizite Cast *kann* gewollt
sein, mu� es aber nicht.
Als C Programmierer sollte man zwar wissen, was dabei passiert; man
mu� es aber nicht benutzen ;-)
Gr��e aus dem sonnigen Bergischen Land
Robert
Sch�n f�r Dich. Compiler k�nnen nat�rlich wegen allem m�glichen warnen.
Aber das �ndert nichts daran, dass das korrektes C ist.
hp