Hallo,

gibt es bei einer gegebenen Variable $dir, die ein Verzeichnispfad
beinhaltet,
einen Unterschied zwischen diesen beiden Befehlen:

rmdir(${dir});

bzw.

rmdir($dir);

Hab die erste Form vorher noch nie gesehen und jetzt in einem Fremdscript
entdeckt.

Vielen Dank!

> rmdir(${dir});
> bzw.
> rmdir($dir);

Das macht keinen Unterschied, wobei die erste Variante absolut sinnbefreit
ist! (Evtl. braucht diese Notation eine 1/10000000000000000 Millisekunde
länger beim Ausführen!?)

Ãœber die Verwendung von '{' in Variablennamen siehe
http://www.php.net/manual/en/language.variables.variable.php am Ende.


Lorenz

Aha, bei ${$dir} wäre $dir also der Bezeichner einer neuen Variablen...

Vielen Dank für die Info!

Michael Maus schrieb:

> Aha, bei ${$dir} wäre $dir also der Bezeichner einer neuen Variablen...
Was dann aber wieder etwas anderes ist (2x "$") als:

> > > rmdir(${dir});
Diese Schreibweise benutzt man normal, wenn man Variablen und Arrays in
double-quoted Strings einsetzt [1]. (auch wenn ich es persönlich vorziehe,
das "{" vor das "$" zu setzen)

Gruß
Carsten

http://de.php.net/manual/en/language.types.string.php#langua ge.types.string.parsing

Carsten Wiedmann schrieb:
> Diese Schreibweise benutzt man normal, wenn man Variablen und Arrays in
> double-quoted Strings einsetzt [1]. (auch wenn ich es persönlich
> vorziehe, das "{" vor das "$" zu setzen)

ich persönlich ziehe es lieber vor die Variablen außerhalb des Strings
zu benutzen. Allein schon durch den besseren Überblick durch Syntax
Highlight.

Daher nicht
$begruessung = "Hallo $user"
sondern
$begruessung = 'Hallo ' . $user;

Soweit ich mich noch erinnern kann, gab es da auch einen etwas größeren
Unterschied in der Performance (also letzteres ist schneller), oder irre
ich mich da?

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Michael Maus schrieb:

> gibt es bei einer gegebenen Variable $dir, die ein Verzeichnispfad
> beinhaltet,
> einen Unterschied zwischen diesen beiden Befehlen:
>
> rmdir(${dir});
>
> bzw.
>
> rmdir($dir);

define( 'foo', 'bar' );
$foo =3D 'footext';
$bar =3D 'bartext';
echo ${foo};
// Ausgabe: bartext
echo $foo;
// Ausgabe: footext

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Christoph Herrmann schrieb:
> Carsten Wiedmann schrieb:

>> Diese Schreibweise benutzt man normal, wenn man Variablen und Arrays i=
n
>> double-quoted Strings einsetzt [1]. (auch wenn ich es persönlich
>> vorziehe, das "{" vor das "$" zu setzen)

Das ist nicht egal.

> ich persönlich ziehe es lieber vor die Variablen außerhalb des Stri=
ngs
> zu benutzen. Allein schon durch den besseren =DCberblick durch Syntax
> Highlight.

Das ist eher ein Argument gegen deinen Editor, wenn der Variablen in
Strings nicht markiert.

> Daher nicht
> $begruessung =3D "Hallo $user"
> sondern
> $begruessung =3D 'Hallo ' . $user;
>
> Soweit ich mich noch erinnern kann, gab es da auch einen etwas größ=
eren
> Unterschied in der Performance (also letzteres ist schneller), oder irr=
e
> ich mich da?

Nein der Laufzeitunterschied ist vernachlässigbar. Prinzipiell ist
Verkettung "teurer" als Interpolation.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Christoph Herrmann meinte:
> Carsten Wiedmann schrieb:
>> Diese Schreibweise benutzt man normal, wenn man Variablen und Arrays
>> in double-quoted Strings einsetzt [1]. (auch wenn ich es persönlich
>> vorziehe, das "{" vor das "$" zu setzen)
>
> ich persönlich ziehe es lieber vor die Variablen außerhalb des Strings
> zu benutzen. Allein schon durch den besseren Überblick durch Syntax
> Highlight.

PDT (und wahrscheinlich auch andere IDEs) schafft auch ein korrektes
Syntaxhighlighting bei interpolierten Variablen.

> Daher nicht
> $begruessung = "Hallo $user"
> sondern
> $begruessung = 'Hallo ' . $user;
>
> Soweit ich mich noch erinnern kann, gab es da auch einen etwas größeren
> Unterschied in der Performance (also letzteres ist schneller), oder irre
> ich mich da?

Mag sein. Aber bei 20x 'foo'.$bar.'foo'... ist das wahrscheinlich schon
wurscht. Und die Lesbarkeit ist auch dahin.

Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

> Soweit ich mich noch erinnern kann, gab es da auch einen etwas größeren
> Unterschied in der Performance (also letzteres ist schneller), oder irre
> ich mich da?

Naja, bei double-quoted string wird der String natürlich durchgeparst,
weil ja nach Variablen gesucht werden muss. Entsprechend ist das bei
längeren Strings langsamer.

Spannend wäre die dritte Möglichkeit dazu:
$begruessung = sprinf('Hallo %s', $user);
Ich habe mal gelernt, dass Strings aneinanderhängen gar nciht so schnell
geht (weswegen man, wenns drauf ankommt, nen StringBuffer o.ä.
verwendet). sprintf könnte man direkt an C durchreichen...

Gibts da Erfahrungen? Mal ganz davon abgesheen hat die sprintf-Methode
natürlich beträchtliche Vorteile, wenn es z.B. um Lokalisierung geht.

Christoph Herrmann schrieb:

>Allein schon durch den besseren Überblick durch Syntax Highlight

Selbst Notepad++ schafft ein Highlighting von Variablen in Strings.

>Daher nicht
> $begruessung = "Hallo $user"
>sondern
> $begruessung = 'Hallo ' . $user;

Und du hast hier sorgsam den Fall rausgesucht, wo hinter der anzuhängenden
Variable kein Text mehr kommt. ;-)

Bei
$begruessung = "<h1>Hallo $vorname $nachname</h1>";
vs.
$begruessung = '<h1>Hallo ' . $vorname . ' ' . $nachname . '</h1>';

sieht das mit der Übersichtlichkeit schon ganz anders aus.

--
Wolfgang Fellger

Gregor Kofler schrieb:
> PDT (und wahrscheinlich auch andere IDEs) schafft auch ein korrektes
> Syntaxhighlighting bei interpolierten Variablen.

meins nicht, da werden Strings durchgehend mit Variablen immer in der
gleichen Farbe (bei mir grau) dargestellt.

> Mag sein. Aber bei 20x 'foo'.$bar.'foo'... ist das wahrscheinlich schon
> wurscht. Und die Lesbarkeit ist auch dahin.

dann fällt es wohl eher unter die Kategorie "Geschmackssache". ;)

Wahrscheinlich ist es für mich wesentlich einfacher zu lesen, weil ich
es gewohnt bin aus anderen Sprachen.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Wolfgang Fellger schrieb:
> Selbst Notepad++ schafft ein Highlighting von Variablen in Strings.

gerade getestet, ist mir ehrlich gesagt noch nie aufgefallen... Wenn das
im PDT Eclipse auch so funktioniert, nehme ich das Argument gerne wieder
zurück. :)

> Und du hast hier sorgsam den Fall rausgesucht, wo hinter der anzuhängenden
> Variable kein Text mehr kommt. ;-)
>
> Bei
> $begruessung = "<h1>Hallo $vorname $nachname</h1>";
> vs.
> $begruessung = '<h1>Hallo ' . $vorname . ' ' . $nachname . '</h1>';
>
> sieht das mit der Übersichtlichkeit schon ganz anders aus.

Hab mir das Beispiel ausgesucht, weil ich gerade faul war was größeres
zu schreiben. ;) Also ich finde das untere trotzdem schöner, aber wie
gesagt, Gewohnheitssache. :)

[OT]
Mal ganz davon abgesehen, dass ich kein HTML Code im PHP direkt
schreibe, sondern das Beispiel bei mir dann eher so aussehen würde:
$begruessung = new XmlNode('h1');
$begruessung->setValue('Hallo ' . $vorname . ' ' . $nachname);

Also merkt man schon, dass ich kein Platzsparender Mensch bin ;)
[/OT]

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Niels Braczek wrote:
> define( 'foo', 'bar' );
> $foo = 'footext';
> $bar = 'bartext';
> echo ${foo};
> // Ausgabe: bartext
> echo $foo;
> // Ausgabe: footext

Oh Gott, da habe ich ja mal wieder die perversen Programmierer vergessen!
Unter der Bedingung ist das Ergebnis natürlich nicht das Gleiche...

Danke für den Hinweis,
Lorenz

Niels Braczek wrote:
> Michael Maus schrieb:
>
>> gibt es bei einer gegebenen Variable $dir, die ein Verzeichnispfad
>> beinhaltet,
>> einen Unterschied zwischen diesen beiden Befehlen:
>>
>> rmdir(${dir});
>>
>> bzw.
>>
>> rmdir($dir);
>
> define( 'foo', 'bar' );
> $foo = 'footext';
> $bar = 'bartext';
> echo ${foo};
> // Ausgabe: bartext
> echo $foo;
> // Ausgabe: footext

Ach du Kacke, daran denkt man doch nicht... :-)

Mal prinzipiell: Müsste dann ein einfaches ${baz} nicht eine Notice
werfen weil es ja ${'baz'} heißen müsste?

regards,
Jens

On Tue, 18 Sep 2007 14:32:48 +0200 Nicolas Ulmann wrote:
> Spannend wäre die dritte Möglichkeit dazu:
> $begruessung = sprinf('Hallo %s', $user);

Genauso mache ich das in fast allen Faellen.

> sprintf könnte man direkt an C durchreichen...

Das ist vermutlich richtig, aber im Vergleich zu den
Datenbankoperationen in der Regel eh vollkommen vernachlaessigbar.
Der Charme des obigen Statements liegt darin, es durch die Erweiterung
auf

| $begruessung = sprinf(_('Hallo %s'), $user);

fuer gettext verwendbar zu machen. Gut, das geht mit _("Hallo $user")
zwar genauso, aber spaetestens bei Verwendung von Feldvariablen oder
Objekten wird es fuer den (derartige Konstrukte meist nicht gewohnten)
Uebersetzer dann schon sehr unangehem.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Die Lust zu haben! Stefan, stündlich!
(Sloganizer)

..oO(Nicolas Ulmann)

>> Soweit ich mich noch erinnern kann, gab es da auch einen etwas größeren
>> Unterschied in der Performance (also letzteres ist schneller), oder irre
>> ich mich da?
>
>Naja, bei double-quoted string wird der String natürlich durchgeparst,
>weil ja nach Variablen gesucht werden muss. Entsprechend ist das bei
>längeren Strings langsamer.

Nicht zwangsläufig.

>Spannend wäre die dritte Möglichkeit dazu:
> $begruessung = sprinf('Hallo %s', $user);
>Ich habe mal gelernt, dass Strings aneinanderhängen gar nciht so schnell
>geht (weswegen man, wenns drauf ankommt, nen StringBuffer o.ä.
>verwendet). sprintf könnte man direkt an C durchreichen...
>
>Gibts da Erfahrungen? Mal ganz davon abgesheen hat die sprintf-Methode
>natürlich beträchtliche Vorteile, wenn es z.B. um Lokalisierung geht.

Nicht nur da, sondern immer dann, wenn man komplexere Ausdrücke in einem
String unterbringen möchte.

Ich hatte das vor einiger Zeit mal getestet:

http://mfesser.de/test/sprintf.php

Die Laufzeitunterschiede sind zwar klar vorhanden, in der Praxis aber
absolut vernachlässigbar. Darüberhinaus ist nicht immer klar, welche
Methode nun wirklich die schnellste ist, denn auch andere Faktoren wie
Serverlast, Codecache etc. können durchaus eine Rolle spielen.

Nach einigen Durchläufen des Tests zeigt sich durchschnittlich folgendes
Bild (vom schnellsten zum langsamsten):

1) Interpolation
2) sprintf()
3) Verkettung

Gelegentlich sind die Positionen aber auch schon mal vertauscht.

Micha

Jens Himmelrath schrieb:
> Niels Braczek wrote:

>> define( 'foo', 'bar' );
>> $foo =3D 'footext';
>> $bar =3D 'bartext';
>> echo ${foo};
>> // Ausgabe: bartext
>> echo $foo;
>> // Ausgabe: footext
>
> Ach du Kacke, daran denkt man doch nicht... :-)
>
> Mal prinzipiell: Müsste dann ein einfaches ${baz} nicht eine Notice
> werfen weil es ja ${'baz'} heißen müsste?

Jein. Innerhalb der Curly braces gelten nunmal andere Regeln...

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek wrote:
> Jens Himmelrath schrieb:
>> Niels Braczek wrote:
>
>>> define( 'foo', 'bar' );
>>> $foo = 'footext';
>>> $bar = 'bartext';
>>> echo ${foo};
>>> // Ausgabe: bartext
>>> echo $foo;
>>> // Ausgabe: footext
>> Ach du Kacke, daran denkt man doch nicht... :-)
>>
>> Mal prinzipiell: Müsste dann ein einfaches ${baz} nicht eine Notice
>> werfen weil es ja ${'baz'} heißen müsste?
>
> Jein. Innerhalb der Curly braces gelten nunmal andere Regeln...

Da ich ein eifriger Leser des Manuals bin, frag ich mich gerade wo ich
das überlesen habe...

regards,
Jens

Niels Braczek schrieb:

> Christoph Herrmann schrieb:
> > Carsten Wiedmann schrieb:
>
> > > Diese Schreibweise benutzt man normal, wenn man Variablen und
> > > Arrays in double-quoted Strings einsetzt [1]. (auch wenn ich es
> > > persönlich vorziehe, das "{" vor das "$" zu setzen)
>
> Das ist nicht egal.

Tatsache. Auf die Möglichkeit, Konstanten in variablen Variablen zu
benutzen, bin ich nicht gekommen. Wird im Manual auch nur in den UNC's
erwähnt. Dann muss jedenfalls auch das "{" nach dem "$" sein und nicht
davor.

Danke für die Korrektur.

Gruß
Carsten

Jens Himmelrath schrieb:
> Niels Braczek wrote:
>> Jens Himmelrath schrieb:

>>> Mal prinzipiell: Müsste dann ein einfaches ${baz} nicht eine Notice=

>>> werfen weil es ja ${'baz'} heißen müsste?
>>
>> Jein. Innerhalb der Curly braces gelten nunmal andere Regeln...
>
> Da ich ein eifriger Leser des Manuals bin, frag ich mich gerade wo ich =

> das überlesen habe...

Leider steht nicht alles im Manual. Ich habe das hergeleitet aus der
Tatsache, dass man innerhalb von Strings mittels Curly Braces die
Interpretion von Variablen verändern kann. Folglich gelten mit Curly
Braces andere Regeln als ohne... "Jein" sagte ich, weil es durchaus eine
gültige Sichtweise ist, dass es so sein sollte, wie du anmerktest.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Niels Braczek wrote:
> Jens Himmelrath schrieb:
>> Niels Braczek wrote:
>>> Jens Himmelrath schrieb:
>
>>>> Mal prinzipiell: Müsste dann ein einfaches ${baz} nicht eine Notice
>>>> werfen weil es ja ${'baz'} heißen müsste?
>>> Jein. Innerhalb der Curly braces gelten nunmal andere Regeln...
>> Da ich ein eifriger Leser des Manuals bin, frag ich mich gerade wo ich
>> das überlesen habe...
>
> Leider steht nicht alles im Manual. Ich habe das hergeleitet aus der
> Tatsache, dass man innerhalb von Strings mittels Curly Braces die
> Interpretion von Variablen verändern kann. Folglich gelten mit Curly
> Braces andere Regeln als ohne... "Jein" sagte ich, weil es durchaus eine
> gültige Sichtweise ist, dass es so sein sollte, wie du anmerktest.

Na dann waren wir ja auf dem selben Stand.

regards,
Jens