PHP addieren und subtrahieren ,,textdateibasierend,,

dreivier

Lieutenant
Dabei seit
Apr. 2012
Beiträge
660
warum funktioniert das nicht?
PHP:
$haben;
$haben = $haben[0]-1;
in der zeile wird zb. wenn der wert 0 ist 0 und -1 geschrieben...wie erreiche ich das negativwerte geschrieben werden also wie SQL signed also -1, -234 usw.?

(+1 funktioniert dagegen problemlos!)

Danke.
 

Yuuri

Fleet Admiral
Dabei seit
Okt. 2010
Beiträge
13.059
Und was ist $haben[0]?

edit:
Code:
<?php

$haben;
$haben = $haben[0]-1;

var_dump( $haben );
Code:
int -1
 
Zuletzt bearbeitet:

dreivier

Lieutenant
Ersteller dieses Themas
Dabei seit
Apr. 2012
Beiträge
660
zb. am anfang ist es eine 0....wenn ich also -1 mache sollte aus der 0 ein -1 werden...wird es aber nicht bzw. in der zeile steht dann
0-1
 

Yuuri

Fleet Admiral
Dabei seit
Okt. 2010
Beiträge
13.059
Und was ist jetzt $haben? Was am Anfang? Die Frage hast du damit nicht beantwortet. Was sagt var_dump($haben); vor Zeile 2?
 

Daaron

Fleet Admiral
Dabei seit
Dez. 2011
Beiträge
13.487
warum funktioniert das nicht?
PHP:
$haben;
$haben = $haben[0]-1;
Das kann, in der Form, nicht funktionieren. Warum? Weil die Notation "$haben[0]" impliziert, dass $haben ein Array ist UND mindestens ein Element hat (mit dem Index 0).

Also was passiert tatsächlich?
1.) kriegst du sinnfreie Datengrütze zurück, weil du nach Grütze fragst
2.) Steht in deinem Log definitiv eine Warning, dass du auf ein nicht existierendes Array-Element zugreifen willst.
 
V

VikingGe

Gast
Du solltest dir dringend angewöhnen, Variablen sofort bei der Deklaration zu initialisieren, und zwar mit dem Typen, den sie später haben sollen. Denn:

Code:
zb. am anfang ist es eine 0
Stimmt eben einfach nicht. Nicht initialisierte Variablen mögen bei PHP zwar irgendwelche Standardwerte bekommen, die gerade zufällig zu den benötigten Typen passen, aber in jeder anderen Programmiersprache fliegt man so gewaltig auf die Nase - da kann $haben auch schonmal 42 sein, beim nächsten Programmstart 17 oder die Integer-Repräsentation von "Hans".

Es gab früher mal eine Option namens REGISTER_GLOBALS. Da hätte man bei deinem Script die Variable $haben einfach per URL setzen können - ggf. eine riesige Sicherheitslücke in dem Script. Nutzt inzwischen zwar keiner mehr, aber auf solche Sachen immer achten.


Wenn man jetzt nämlich mal
Code:
$haben = array(10);
$haben = $haben[0] - 1;
schreibt, dann wird das ganze auch zumindest etwas tun. Was? Nun - 10-1 ausrechnen und irgendwie zuweisen, möglicherweise als Integer - nicht mehr als Array. Auch das ist nicht schön.
Aber du kannst nicht einfach auf etwas zugreifen, das keinen Wert hat, und es schon gar nicht so behandeln, als wäre es ein Array.
 
Zuletzt bearbeitet:
M

mambokurt

Gast
Das kam (vielleicht) in den vorherigen Antworten nicht so ganz rüber:
du machst:
$haben = -1;
-> Eine Variable $haben mit Wert -1 wird angelegt
echo $haben;
-> -1 wird ausgegeben, ist ja der Wert der Variablen

ABER:
$haben = $haben[0];
kann schon nur Bullshit liefern. Du sprichst eine stinknormale Integer Variable mit einem Wert als Array an. Ich bin mir jetzt nicht sicher was da genau mit $haben passiert, müsste man mal austesten, kann sein dass es einfach als Array gelesen wird oder per impliziten Typecast nach String formatiert und dann ausgelesen wird. So oder so macht das was du da machst null Sinn :D

EDIT: nur um das nochmal klar zu sagen: $haben ist vorher kein Array, in dem Moment wo du es mit [] ansprichst wird es zu einem, dass da nur Gülle im Wert steht ist nicht verwunderlich...
Ergänzung ()

Du solltest dir dringend angewöhnen, Variablen sofort bei der Deklaration zu initialisieren, und zwar mit dem Typen, den sie später haben sollen.
Viel Spaß dabei :p Wenn ich var X=array(); mache und danach X='hui' dann ist X kein Array mehr, ist halt so. Von da her kannst du da viel initialisieren, bringt in PHP gar nichts.

Ich bin viel ausgelacht worden, aber: wir hängen vor den Variablennamen als Kleinbuchstaben den Datentypen. Also $sBla, $aBlub usw. So sieht man direkt $sXXX ist ein String und $aXXX ist ein Array, Datentyp ändern is nicht im Programm, Problem gelöst.

EDIT2: das soll nicht heißen, dass es sinnlos ist $X= array(); zu initialisieren, aber in seinem Beispiel hätte das halt nix gebracht.
 
Zuletzt von einem Moderator bearbeitet:
V

VikingGe

Gast
mambokurt, du hast natürlich Recht, aber den Typen einer Variablen zu ändern, ist weder sonderlich guter Stil, noch sehe ich irgendeinen Grund, das jemals bewusst tun zu wollen (passiert ja doch eher versehentlich, weil Scriptsprachen soetwas gerne erlauben und/oder man keine Ahnung hat, was man tut) - insofern ist das vielleicht gar nicht mal so blöd mit dem Präfix, da fällt einem sowas beim Lesen des Codes wenigstens eher auf.

Aber das Beispiel hier zeigt eindrücklich, warum es vielleicht doch sinnvoll ist, sich vor PHP mit etwas strengeren Sprachen zu befassen, bei denen einem soetwas direkt um die Ohren fliegt. Anders herum - also von PHP auf etwas anderes - fällt die Umgewöhnung jedenfalls deutlich schwerer, ich spreche da leider aus Erfahrung. :freak:
 

Daaron

Fleet Admiral
Dabei seit
Dez. 2011
Beiträge
13.487
Ich bin viel ausgelacht worden, aber: wir hängen vor den Variablennamen als Kleinbuchstaben den Datentypen. Also $sBla, $aBlub usw. So sieht man direkt $sXXX ist ein String und $aXXX ist ein Array, Datentyp ändern is nicht im Programm, Problem gelöst.
Lach die aus, die bei sowas lachen. Ich verwende grundsätzlich solche Präfixe, wenns sich nicht um absolut triviale Wegwerfvariablen (sowas wie $temp) handelt.
Ich verwende die Präfixe str, arr, obj und, gelegentlich für Booleans, noch bln.

In der Beziehung wird PHP7 lustig, da gibts viele neue skalare Typen.
 

Yuuri

Fleet Admiral
Dabei seit
Okt. 2010
Beiträge
13.059
Mit ner ordentlichen Code Completion ist das auch unnötig, allerdings seh ich es auch zu zu oft, dass auf PhpDoc einfach verzichtet wird und man somit enteder kein Code Completion hat oder es ist unzureichend bzw. einfach nur falsch (bspw. bei vererbten Klassen oder Factories). Für normale Editoren (Notepad++, Sublime Text, GEdit und Co.) mag das vielleicht noch ganz zweckdienlich sein, in ner stattlichen IDE allerdings halte ich es für Humbug.

PHP 7 ändert es ja auch nur dahingehend, dass man Variablendeklarationen hinten kann, nicht Variablen an sich. Imho ist der Draft auch vollkommen fehlerhaft, denn Auto Casting wird damit praktisch ausgehebelt, was aber z.T. selbst stark typisierte Sprachen besitzen. Sieht man sehr schön im letzten Beispiel bzw. auch in "main4.php".
Code:
<?php
declare(strict_types=1);
 
function foobar(): int {
    return 1.0;
}
 
var_dump(foobar());
// Catchable fatal error: Return value of foobar() must be of the type integer, float returned
(C(++) würde hier nur ein Warning werfen, PHP soll hier komplett abbrechen)

Ergo gilt kein "1" als int 1, "0" als 0, "1.2" als 1.2 usw. Da seh ich schon viel zu viele sinnlose, explizite Casts in jedwedem Code, gerade auch solcher, der mit der DB interagiert, wo üblicherweise immer Strings als Daten zurückkommen und auch bereits valide Daten liegen (zumindest theoretisch sollten).

Es ist eher eine Schmach, dass überladene Funktionen/Methoden abgewiesen wurden... :(

BTT: Wie stehts mit dem TE? Gab ja keine Rückmeldung bisher.
 

Daaron

Fleet Admiral
Dabei seit
Dez. 2011
Beiträge
13.487
Du dokumentierst jede Hilfsvariable, die du innerhalb einer Funktion mal für 20-30 Zeilen einführst und danach in der Versenkung verschwinden lässt?

Und seit wann liefern TE's hier Rückmeldung? Wäre ja ganz was neues. Die einzigen, die sich tatsächlich nochmal melden, sie die, denen die Antwort richtig schön gegen den Strich geht.
 

Yuuri

Fleet Admiral
Dabei seit
Okt. 2010
Beiträge
13.059
Du dokumentierst jede Hilfsvariable, die du innerhalb einer Funktion mal für 20-30 Zeilen einführst und danach in der Versenkung verschwinden lässt?
Nein, mit ner ordentlichen Dokumentation gibts Typen für jeden Rückgabewert einer jeden Funktion und wenn ein $a = 5 im Code autritt, schafft ne ordentliche IDE es auch, automatisch den richtigen Typ zuzuweisen. Wozu also selbst nen Typ mitgeben? Wenn man ganz exakt sein will oder der Variablen keinen Initialwert gibt, dann fügt man noch nen PhpDoc-Block wie /* @var $a int */ hinzu, dann ist es im Code Completion fest hinterlegt.
 

Daaron

Fleet Admiral
Dabei seit
Dez. 2011
Beiträge
13.487
Mal sehen, ich kann also viel Zeit in umfangreichen Einsatz von PhpDoc investieren, was sich dann unter Umständen beim Einsatz einer komplexen IDE bemerkbar macht. Oder, ich kann primär auf aussagekräftige Präfixe setzen, die dafür auch dann noch verständlich sind, wenn ich doch mal nur mit Geany, Gedit oder Vim an etwas herum schraube.

PhpDoc scheitert, wenn du mal eine Funktion hast, die entweder mehrere Datentypen akzeptiert oder mehrere zurück gibt. Ich denk da z.B. an Datenbank-Abstraktionen, die eben durchaus entweder ein Result-Object zurück geben können, oder NULL, wenn der Query nichts ergab.
 

Yuuri

Fleet Admiral
Dabei seit
Okt. 2010
Beiträge
13.059
Und dein Variablenpräfix wäre dann korrekt? Der ist doch genauso statisch wie es eine Dokumentation wäre. PhpDoc kann übrigens auch mehrere Datentypen deklarieren mit klasse1|klasse2|int|null. Was dann zurückgegeben wird, kann man dann immer noch mittels $a === null bzw. $a instanceof klasse1 überprüfen bzw. sollte bei sowas dann auch geprüft werden. PhpStorm bspw. ist dann so schlau und castet $a automatisch in die angegebene Klasse, wenn du im entsprechenden if-Block bist. Typischerweise gibt es aber nur eine Klasse bzw. einen Typen oder null o.ä. Fehler sollten dann in Exceptions auftreten, aber das geht dann zu dem Thema hier doch zu weit.

Wie gesagt, für Editor-Arbeit mag das ganz gut sein, aber wenn ne IDE im Spiel ist und entsprechend komplexer Code vorliegt, brauch man sowas ganz und gar nicht mehr.
 
Top