perlsub (Allgemeines zu Perl) - Perl-Community.de

[thread]12019[/thread]

perlsub

Leser: 3

Gast Gast

2008-06-16 12:43

Hi,

was bedeutet hier "inlining"?

"Constant Functions Functions with a prototype of "()" are potential candidates for inlining."

2008-06-16 12:54

User since
2003-08-04
12208 Artikel
Admin1

inlining bedeutet hier, dass der compiler eine konstante auflöst, also im code nachher
nicht mehr die funktion aufgerufen wird, sondern der wert, also etwa

Code (perl): (dl )

1
2
3

use constant PI => 3.14;
my $x = ...;
print PI * $x;

das wird intern kompiliert zu

Code (perl): (dl )

1
2

my $x = ...;
print 3.14 * $x;

kannst du dir bei jedem programm anschauen, wenn du es mit dem schalter -MO=Deparse aufrufst.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:

Wie frage ich & perlintro Wiki:

brian's Leitfaden für jedes Perl-Problem

roooot

2008-06-16 16:16

User since
2008-03-03
276 Artikel
BenutzerIn
[default_avatar]

benutz statt use constant lieber CPAN:

Readonly

Viele Grüße :)

Strat

2008-06-16 17:04

User since
2003-08-04
5246 Artikel
ModeratorIn

roooot+2008-06-16 14:16:51--
benutz statt use constant lieber Readonly

Warum?

perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/

betterworld

2008-06-16 17:04

User since
2003-08-21
2614 Artikel
ModeratorIn

user image

roooot+2008-06-16 14:16:51--
benutz statt use constant lieber Readonly

Und warum das? Readonly hat zum Beispiel kein Inlining. Manch meinen, dass constant total viele Design-Fehler hat und ziehen daher Readonly vor, aber das ist Geschmacksfrage, und so pauschal wuerde ich niemandem sagen, dass er statt constant Readonly benutzen soll.

Lieblingsmodule: CPAN:

IPC::System::Simple, CPAN:

Path::Class

2008-06-16 17:06

User since
2003-08-04
12208 Artikel
Admin1

nee, nutze lieber constant.

im ernst, das ist geschmackssache, und use constant ist ein deutlicher geschwindigkeitsvorteil.
hier teile ich die meinung von Perl Best Practices nicht.

der einzige vorteil von Readonly, der mir bisher plausibel erschien, ist, dass man die variablen
wie üblich in strings und hashes benutzen kann, während man bei konstanten in dem fall
etwas mehr tippen muss. ansonste finde ich konstanten sehr gut erkennbar (werden laut
konvention komplett grossgeschrieben). dadurch sind sie auch ohne das dollarzeichen
erkennbar.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:

Wie frage ich & perlintro Wiki:

brian's Leitfaden für jedes Perl-Problem

Strat

2008-06-16 17:15

User since
2003-08-04
5246 Artikel
ModeratorIn

Ich bevorzuge meist Readonly aus dem Grund, dass man damit "schöner" (ohne Exporter) packageübergreifend arbeiten kann und sie an Stellen interpolieren, wo Konstanten (=Subs) nicht so einfach interpolieren würden.

Code (perl): (dl )

package ABC;
use constant DEF => 'test';

package XYZ;
print "value: ABC::DEF\n"; # geht nicht
$string .= &ABC::DEF; # sieht komisch aus
$string .= ABC::DEF(); # die () passen nicht zu Konstanten

geht leider nicht, und da noch eine Menge geschwungener Klammern und @ rumzupacken sieht in meinen Augen hässlich aus...

Aber häufig verwende ich auch Readonly nicht...

perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/

betterworld

2008-06-16 17:24

User since
2003-08-21
2614 Artikel
ModeratorIn

user image

Strat+2008-06-16 15:15:19--
Ich bevorzuge meist Readonly aus dem Grund, dass man damit "schöner" (ohne Exporter) packageübergreifend arbeiten kann

Naja, das ist die Frage, ob das so schön ist. Ich finde es eigentlich nicht so schön, Variablen aus anderen Paketen a la $Name::von::dem::Paket::Variable zu benutzen. Zum einen ist das bei vielen Paketnamen einfach zu lang. Und zum anderen beschützt mich da keiner mehr davor, in dem Namen einen Tippfehler einzubauen. Wenn ich hingegen aus einem langen Paketnamen eine Konstante mit Exporter einbinde, muss ich weniger tippen (abgesehen von der Sache mit der Interpolation), und wenn ich mich dann doch mal vertippe, gibt es zur Kompilier- oder zumindest zur Laufzeit einen Fehler.

Lieblingsmodule: CPAN:

IPC::System::Simple, CPAN:

Path::Class

2008-06-16 17:47

User since
2003-08-04
12208 Artikel
Admin1

Strat+2008-06-16 15:15:19--

Code (perl): (dl )

package XYZ;
print "value: ABC::DEF\n"; # geht nicht
$string .= &ABC::DEF; # sieht komisch aus
$string .= ABC::DEF(); # die () passen nicht zu Konstanten

in strings ist es wie gesagt mehr tipperei, aber ich benutze selten konstanten in strings.
&ABC::DEF sollte man nicht benutzen, wenn es sein muss, ABC::DEF(), und das geht wunderbar.
aber am besten einfach ABC::DEF, oder die konstante importieren.

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:

Wie frage ich & perlintro Wiki:

brian's Leitfaden für jedes Perl-Problem

roooot

2008-06-16 18:01

User since
2008-03-03
276 Artikel
BenutzerIn
[default_avatar]

Quote
der einzige vorteil von Readonly, der mir bisher plausibel erschien, ist, dass man die variablen
wie üblich in strings und hashes benutzen kann, während man bei konstanten in dem fall
etwas mehr tippen muss. ansonste finde ich konstanten sehr gut erkennbar (werden laut
konvention komplett grossgeschrieben). dadurch sind sie auch ohne das dollarzeichen
erkennbar.

genau, weil Readonly Variablen in Strings interpoliert werden. Und das finde ich sehr sehr vorteilhaft.
Und ich persönlich habe mir auch angewöhnt alle Radonly Variablen großzuschreiben.

Ich kann die Meinung von Best Practices teilen.
Er hat da auch ein gutes Beispiel:

Code (perl): (dl )

1
2
3

use constant ZEILEN_PRO_SEITE => 42;

$seitenrand{ZEILEN_PRO_SEITE} = MAX_ZEILEN - ZEILEN_PRO_SEITE;

so heißt der Hashwert nun 42 oder ZEILEN_PRO_SEITE. Ich finde das sehr verwirrend, wenn ich nicht selbst _gerade_ das Script geschrieben habe.

Viele Grüße :)

View all threads created 2008-06-16 12:43.