|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > negativer addresszeiger? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
01.01.2011, 02:01 Uhr AGSzabo Posts: 1663 Nutzer |
wir wollen das jahr mal nicht negativ anfangen aber mich quält folgende frage: es ist an der tagesordnung zu testen ob ein von einer funktion zurückgegebener addresszeiger null ist um zu sehen ob die funktion erfolgreich war, zB AllocMem(). Ist es nun auch erlaubt, davon aus zu gehen dass es niemals eine addresse geben kann, die im 32bit-raum negativ ist? ich will einen 3-state rückgabewert haben, zB positiv = ok, speicher erhalten, null = fail, garkein speicher verfügbar, und das besondere: negativ = kein fast ram (das nur so als beispiel, ich weiss es ist ein schlechtes beispiel, man soll ja vorher mit AvailMem() testen). aber das mit dem negativ, darf man das? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
01.01.2011, 02:30 Uhr thomas Posts: 7718 Nutzer |
Zitat: Nein, das ist nicht erlaubt. Ein 32bit Pointer darf auch 32 Bits benutzen. Aber da du ja Assembler programmierst, spricht doch nichts dagegen, mehrere Werte zurückzugeben, z.B. den Pointer in A0 und einen Fehler-Code in D0. Wenn D0 0 ist, enthält A0 die Adresse, in allen anderen Fällen beschreibt D0 den Fehler. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
01.01.2011, 04:01 Uhr tboeckel Posts: 124 Nutzer |
Zitat: Wer erzählt denn so einen Unfug? Verlaß dich nicht auf AvailMem(). Verlaß dich nur auf AllocMem() und verwandte Funktionen. Entweder du kannst Speicher bekommen oder nicht. Vorheriges Testen bringt überhaupt nichts, weil jederzeit Speicher freigegeben werden kann, so daß die Info von AvailMem() bestenfalls nutzlos sind. AvailMem() kann dir unter OS3 vielleicht sagen, daß noch 1MB Speicher frei ist, aber du kannst mit 100%iger Sicherheit diesen Speicher nicht für dich reservieren, weil er fragmentiert ist und deswegen nicht als ein großer Block zur Verfügung steht. Und damit ist jegliche Info über "freien Speicher" absolut nutzlos. Versuch einfach die gewünschte Menge Speicher zu reservieren. Wenns nicht klappt, dann hilft dir auch die ausgeklügelste Logik nicht weiter. Und mit dem Pager von OS4.1 wird die Situation sogar noch ins Gegenteil umgekrempelt: AllocMem() funktioniert, obwohl AvailMem() garantiert einen Fehlschlag vorhersagt. Lange Rede, kurzer Sinn: stell keine Vermutungen an, sondern wisse! Niemand garantiert dir, daß 32bit das Maximum für alle Zeit darstellt. [ Dieser Beitrag wurde von tboeckel am 01.01.2011 um 04:02 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
01.01.2011, 11:20 Uhr Kronos Posts: 1168 Nutzer |
Zitat: Naja, nur ist das AmigaOS ja schon von haus aus mit diesen 31Bit-Addressen verseucht, da kommt es auf 1 oder 2 mehr Funktionen der Art auch nicht mehr an  MfG Kronos -- Only the good die young all the evil seem to live forever [ - Antworten - Zitieren - Direktlink - ] |
|
01.01.2011, 11:37 Uhr 68kassembler Posts: 62 Nutzer |
@AGSzabo: Das Problem bei deiner Aussage ist doch, das du hier von Negativen Angaben sprichst. Nun das ist ein Problem, weil: 1) Angaben über die Maximalen Freien Speicher immer Positiv oder 0 sind 2) Adressen immer Positiv sind! 3) Computer eigentlich keine Negativen Zahlen kennen. Vor allen der letzte Punkt ist erst mal wichtig. Negative zahlen werden durch (meistens) das hochwertigste Bit dargestellt. Daher, wenn du das erste Bit setzt, wird meistens diese Zahl dann Negativ, weil es so Definiert ist. Und wenn es mal ein Amiga mit mehr als 2 GB RAM geben sollte, kann es in einen 32-Bit Wert dann "negative" angaben geben, weil eben genau diese Bit gesetzt wird. Korrekterweise muss man dann dieses Bit als Bestandteil der Zahl und nicht als Vorzeichen interpretieren. Daher, ist das vorgehen, so wie du es meinst, so nicht umsetzbar. Und außerdem weißt du ja gar nicht, wo der Speicher liegt. Es kann also sein, das der Speicher oberhalb dieser 2GB Grenze liegt. Dann wären auch Adressen Negativ. Daher ist aus meiner Sicht, dein Vorgehen fragwürdig. Es wäre wirklich besser, wie es schon thomas angegeben hat. Gib doch einfach in z.b. A0 die Adresse zurück und in D0, ob es Funktioniert hat. So sparst du dir gleich noch einen Befehl. Kann aber in höheren Sprachen ein Problem werden, wie z.b. C, weil diese Sprachen nur ein Rückgabe wert Akzeptieren. Das kann man aber auch lösen, in dem man einfach sagt, da kommt ein Struct und wenn der Zeiger auf diesen Struct null ist, hat eben nicht Funktioniert oder in dieser Struct kannst du den Fehler wert angeben. Oder du schreibst eine Funktion, wo man dann den Fehler genauer Abrufen kannst, dann brauchst du wirklich nur 0 zurück geben. [ - Antworten - Zitieren - Direktlink - ] |
|
01.01.2011, 11:50 Uhr RhoSigma Posts: 67 Nutzer |
Hallo, gesundes Neues, also meiner Meinung nach ist die Sache für ein in sich gekapseltes (eigenes) Projekt vollkommen egal, ob man die Adresszeiger nun mit 31 od. 32 Bit behandelt, ich habe noch keinen Amiga mit mehr als 2GB (31Bit-Grenze) gesehen. Wichtig ist nur für sich selbst dann eine Konvention aufzustellen, und dann dementsprechend zu pro- grammieren, sprich in Assembler zwischen vorzeichenlosen (32Bit) und vorzeichenbehafteten (1Bit-Vorz. + 31Bit Daten) Tests zu unter- scheiden: Hier meine persönlichen Aufzeichnungen dazu: code: [ - Antworten - Zitieren - Direktlink - ] |
|
01.01.2011, 12:30 Uhr geit Posts: 332 [Ex-Mitglied] |
Negativ ist Böse. Was man machen kann, ist fixe Ergebnisse ausgeben. also -1 oder -2 abfragen, da man diese Werte nie von einem Alloc oder sonstwie bekommt. Das ist nicht schön, aber eine Möglichkeit. Mit Availmem zu prüfen ist natürlich Schwachsinn, da wir ein Multitasking System haben und ein anderer Task den Speicher noch vor dem Alloc klauen kann und die Abfrage dann sinnfrei macht. Geit [ - Antworten - Zitieren - Direktlink - ] |
|
01.01.2011, 14:04 Uhr AGSzabo Posts: 1663 Nutzer |
ich habs jetzt so gemacht dass d0 postitiv, null, -1 oder -2 sein kann. im fall positiv hat a4 als träger eines pointers einen sinn. sonst wird a4 nicht beachtet. -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 01.01.2011 um 14:04 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
01.01.2011, 17:39 Uhr akl Posts: 265 Nutzer |
@AGSzabo: Da beim Zweierkomplement glücklicherweise -1 mit 0xFFFFFFFF belegt ist und man rückwärts zählt (-2 ist 0xFFFFFFFE) kann man diese Werte vom Ende des Adressraums ziemlich entspannt als Fehlerwerte verwenden. Das wird auch an einigen Stellen im AmigaOS so gemacht (siehe z.B. Graphics/Layers/Intuition-Taglisten). Das geht prinzipiell so lange, wie der allozierte Speicher (immer) größer ist, als das, was am Ende des Adressraums theoretisch an effektiv physikalisch verfügbarem RAM noch kommt. Im dem Zusammenhang: Speicher, der von AllocVec zurückgegeben wird, ist grundsätzlich immer (mindestens) langwort-ausgerichtet. Selbst wenn also im Bereich am Ende des Adreßraumes nicht sowieso ROM oder andere Nicht-RAM-Adressen liegen würden, würde bei AllocVec() grundsätzlich keine Adresse größer als 0xFFFFFFFC sein können. Bis -4 hast Du also (mindestens) Luft ;-) [ - Antworten - Zitieren - Direktlink - ] |
|
01.01.2011, 19:04 Uhr AGSzabo Posts: 1663 Nutzer |
@akl: > Bis -4 hast Du also (mindestens) Luft ;-) ja, ich habs jetzt mit d0 gemacht wie oben beschrieben. ich spare mir zwei cmp.l #$ffffffff und $fffffffe und mache statt dem ein tst d0 und dann wenn negativ noch ein cmp.w #$fffe. außerdem spare ich mir das verschieben von d0 nach a4 um in a4 nach moveq #-1 oder #-2 zu d0 disen wert in a4 zu haben (a4 direkt bräuchte ein move.l ...). aber irgendwelche tricks gehen immer. Zb gibt es im layer einen pointer auf einen backfill-hook. setzt man den explizit nicht auf null sondern auf genau 1, bedeutet dies dass der backfill deaktiviert ist (siehe layers.h). ;-) -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
02.01.2011, 12:25 Uhr 68kassembler Posts: 62 Nutzer |
@RhoSigma: Ich halte diese Argumentation für nicht unbedingt gut, weil das Problem schon auftreten kann, bevor man 2 GB RAM im Rechner hat. Z.b. man kann die Anfangsadresse des RAMs so beschreiben: (x steht für irgendeine Zahl) $00xxxxxx In diesen Fall würde es keine Probleme geben, aber, was ist mit: $FFxxxxxx In diesen Fall gebe es durchaus Probleme. Man könnte genau hier z.b. 128 MB RAM legen. Gut, ich weiß gerade nicht, ob es überhaupt irgendeinen Classic Amiga geben wird, wo dieses Problem auftritt, aber wenn man viele Zorro Karten verwendet, die viel "Speicher" brauchen (also viele Adressen) und man auch noch viel RAM eingebaut hat, dann kann es schon passieren, das man dann Plötzlich Adressen in so einen Bereich hat. Ich hoffe mal, das dies so Verständlicher ist. [ - Antworten - Zitieren - Direktlink - ] |
|
02.01.2011, 19:17 Uhr geit Posts: 332 [Ex-Mitglied] |
-3 bis plus 3 sind sicher, aber ganze Bytes im Pointer zu reservieren ist Blödsinn und gefährlich, speziell, wenn man die Software auf aktuellen Maschinen nutzen will. geit [ - Antworten - Zitieren - Direktlink - ] |
|
02.01.2011, 19:37 Uhr RhoSigma Posts: 67 Nutzer |
@68kassembler nun gut, wenn man es so betrachtet, hast du da natürlich absolut recht, darum gehe ich persönlich bei Adresszeigern immer auf Nummer sicher und verwende vorzeichenlose 32Bit-Logik zu testen dergleichen. Ich glaube allerdings nicht, daß die AutoConfig soweit geht, daß Speicher wirklich oberhalb der 2GB-Grenze zu liegen kommt. Ich habe z.B. das Mainboard voll (2MB Chip/16MB Fast) habe 64MB auf der CSPPC und 256MB auf der ZorRAM, letztere wird eingeordnet auf den Adressen $50000000-$60000000. Was den (administrativen) Speicher betrifft, den die Karten selbst zur AutoConfig o.ä. benötigen, der liegt eigentlich immer im Bereich des s.g. Expansions-Slots von $00E00000-$00F80000. Die 4BM FlashRom der Deneb werden bei mir auf $40000000 eingeblendet. Das einzige sind wirklich die 8MB Gfx-Speicher der CybervisionPPC, die auf $E0000000 liegen, aber da sollte man ohnehin nicht direkt drauf zugreifen. Also generell ja, hast du absolut recht mit deiner Aussage, Nummer sicher ist IMMER der beste Weg  [ - Antworten - Zitieren - Direktlink - ] |
|
04.01.2011, 15:57 Uhr Holger Posts: 8116 Nutzer |
Zitat:Jede Zahl, die nicht durch 8 teilbar ist, ist sicher... Das schließt natürlich -3 bis +3 mit ein, da die 0 von vornherein als Fehlerwert belegt ist. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
04.01.2011, 16:07 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das ist eine ziemlich seltsame Anforderung. Der Wert null besagt doch bereits, dass kein Speicher vom angeforderten Typ verfügbar ist, und der Aufrufer weiß doch selbst, welchen Typ er angefordert hat. Hat er explizit CHIP oder FAST angefordert, bedeutet der Wert null, dass eben kein CHIP, bzw. FAST verfügbar ist, während der andere Typ verfügbar sein könnte, aber nicht überprüft wurde (was im Kontext einer Low-Level-Funktion zum Anfordern von Speicher auch ziemlich nutzlos wäre). Hat der Aufrufer beliebigen Speicher angefordert, bedeutet null auch "gar kein Speicher verfügbar". Wobei AmigaOS ohnehin FAST-RAM bevorzugt, wenn man "beliebig" anfordert, und CHIP-RAM nur dann zurückgibt, wenn nichts anderes vorhanden ist. Man braucht also keine speziellen Fehlercodes, um diese anzufangen und dann genau das zu implementieren, was AmigaOS schon von Haus aus tut. Will man den Benutzer darüber informieren, dass man auf "Notfall"-ChipRAM zurückgreifen musste, braucht man einfach nur "beliebigen" Speicher anzufordern und via TypeOfMem zu überprüfen, ob das Ergebnis Chip-RAM ist. Wenn ja, war nicht genug (oder gar kein) FAST-RAM vorhanden. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
04.01.2011, 19:28 Uhr tboeckel Posts: 124 Nutzer |
Es sollte eigentlich mittlerweile ausreichend klar geworden sein, daß jegliche Vermutung über die Menge an freiem und allokierbaren Speicher absolut sinnlos ist. Entweder man kann Speicher bekommen oder man kann es nicht. Der einzige Weg diese Information in Erfahrung zu bringen ist es einfach zu versuchen, ganz ohne besondere Logik und mathematische Höhenflüge. Einfach nur AllocMem() oder ähnliche Funktionen aufrufen und entsprechend des Rückgabewerts handeln. Das ist alles nur eine Ja/Nein-Entscheidung und "vielleicht" oder "ein bißchen" gibt es dabei nicht. AvailMem() hat bei dem ganzen Vorgehen überhaupt nichts zu suchen, sondern macht die Sache garantiert nur schlimmer oder sogar komplett falsch. Wir haben wirklich mehr als genug "Entwickler", die meinen schlauer als das Betriebssystem zu sein und die deswegen irgendwelche tollen Überprüfungen bezüglich freiem Speicher implementieren und deren Programme dann ähnlich tolle Fehlermeldungen ausgeben. Unter AmigaOS4 kann man selbst bei angezeigten Null freien Bytes immer noch erfolgreich Speicher allokieren, weil es da einen Pager gibt, der genau das ermöglicht. Man darf halt nicht vorher denken, sondern nur nachher richtig reagieren. Nähere Erläuterungen findet man hier. Der Artikel bezieht sich zwar auf das Speichersystem von AmigaOS4, erklärt aber sehr schön, warum AvailMem() ganz einfach nicht taugt. [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 01:42 Uhr AGSzabo Posts: 1663 Nutzer |
das mit dem speicher war blos ein (wie ich schon schrieb, schlechtes) beispiel und nicht das was ich eigentlich vor hatte. ist zu kompliziert zu erklären und blos eine von vielen subroutinen in meinem "menu". -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 08:32 Uhr Thore Posts: 2266 Nutzer |
Was Du brauchst ist ein doppelter Rückgabewert. Beispielsweise in d0 der Wert (Adresse, NULL, Daten...) und in d1 der Typ um was es sich handelt. So hast du nicht nur einen tristate sondern einen n-state mit weitaus weniger Aufwand und 32 * 32 möglichen Rückgabewerten. Sobald Du Adressen zurückgeben willst, musst du bei deiner Idee aufpassen, daß sich die Zahlenbereiche nicht überschneiden. Das funktioniert übrigens auch mit den AmigaOS API Funktionen im Einklang. Einfach neben dem Speicherbereich der z.B. AllocMem zurückgibt noch den Typ zurückgeben. [ Dieser Beitrag wurde von Thore am 05.01.2011 um 08:36 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 09:07 Uhr AGSzabo Posts: 1663 Nutzer |
@Thore: Ja, so in etwa habe ich das jetzt gemacht. es spart sogar befehle. blos gehts bei mir nicht wirklich um speicher sondern um einen clickstatus im menu ... aber meine frage ist ja jetzt beantwortet. ;-) -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 11:04 Uhr akl Posts: 265 Nutzer |
@tboeckel: >Unter AmigaOS4 kann man selbst bei angezeigten Null freien Bytes immer >noch erfolgreich Speicher allokieren, weil es da einen Pager gibt, der >genau das ermöglicht Es braucht nichtmal einen Pager, sondern lediglich einen funktionierenden LowMemory-Mechanismus (vgl. "avail flush") [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 11:06 Uhr akl Posts: 265 Nutzer |
@Thore: >Was Du brauchst ist ein doppelter Rückgabewert. Logisch. Allerdings setzt das voraus, dass man seine Anforderungen sorgfältig definiert. Also entweder tristate_pointer = MyAllocVecDirectDropIn(size, flags) oder eben pointer = MyAllocVecSimilarReplacement(size, flags, &status); Aber man kann natürlich auch erstmal lang und breit mit anderen (also uns) darüber diskutieren ;-) nur um dann die Anforderungen zu ändern... [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 12:23 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wenn es so kompliziert zu erklären ist, dass man schlechte Beispiele braucht, um sich Hilfe zu holen, wird am Ende mit ziemlicher Sicherheit nur Murks bei rauskommen. Zitat:Oh je. Der Klickstatus eines Menüs war zu "zu kompliziert zu erklären"? Ich wollte jetzt gerade mit der rhetorischen Frage schließen, ob Du wirklich weißt, was Du da tust, aber dann fiel mir noch rechtzeitig ein, dass Du ja wirklich selbst sagst, dass Du das nicht weißt. Aber im Ernst, Du solltest wirklich versuchen, es herauszufinden, und damit meine ich, bevor Du weiteren Code schreibst. [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 12:25 Uhr Holger Posts: 8116 Nutzer |
Zitat:Na wenn wir schon beim Haarspalten sind, braucht man nicht mal den, weil Kollege Zufall im Multitasking-System genauso zwischen AvailMem und AllocMem für freien Speicher sorgen kann. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 13:59 Uhr akl Posts: 265 Nutzer |
@Holger: Haarespalten würde ich das nicht nennen. Der LowMemory-Mechanismus greift noch innerhalb von AllocMem - und zwar wird von dort aus aufgeräumt, nachdem es eigentlich bereits fehlgeschlagen war. Der Unterschied kann dementsprechend gewaltig sein, und deutlich größer als das, was zufällig wieder freiwerden würde. Leider war das in vielen AOS-Versionen nie richtig implementiert. [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 15:20 Uhr Thore Posts: 2266 Nutzer |
@akl: > Aber man kann natürlich auch erstmal lang und breit mit anderen (also uns) darüber diskutieren Hab nur weiter gedacht und gemeint, später braucht er sicher mehr als nur 3 Ich kenn ihn inzwischen...[ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 18:57 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nun ja, der Knackpunkt ist, dass der LowMemory-Mechanismus die Erfolgschancen erhöht, während die Tatsache, dass andere Programme zwischen AvailMem und AllocMem dazwischenfunken können, auch zu einer Verringerung der Chancen führen kann, was wesentlich gefährlicher wäre, wenn man sich auf AvailMem verlässt. Ansonsten ist der Differenz zwischen AvailMem und nachfolgenden AllocMem durch zufällige Aktionen im Multitasking beliebig und somit auch beliebig groß, während die LowMemory-Handler die benötigte Speichermenge übergeben bekommen und somit nicht mehr als nötig freigeben müssen. Man kann also nicht wirklich behaupten, dass LowMemory-Handler tendenziell mehr freigeben als durch zufällige Aktionen anderer Programme frei werden könnte. Die Implementierung unter AOS3.x steht wiederum auf einem anderen Blatt. Avail Flush ist im Grunde genommen ein Hack. Es wird eine "große" Speichermenge angefordert, wobei es keine exakte Definition gibt, was "groß" in diesem Zusammenhang bedeutet. Es könnte theoretisch a) die Anforderung erfüllt werden, ohne dass der gewünscht "Flush" Effekt eintritt oder b) jeder LowMemory-Handler für sich entscheiden, seine gecachten Ressourcen nicht freizugeben, da bereits klar ist, dass auf keinen Fall genug Speicher für die Anforderung frei wird und das Wegwerfen der Caches keinen Nutzen erfüllt. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 21:54 Uhr AGSzabo Posts: 1663 Nutzer |
@Holger: keine sorge, der code läuft bestens, auch dann wenn ich im moment nicht auswendig weiss, was genau ich da gemacht habe.  ich bezweifle das andere programmierer immer ihr ganzes projekt mit jedem detail im kopf haben ...-- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
05.01.2011, 23:12 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nicht jedes Detail, aber den Teil, für den man gerade eine Anfrage in einem Forum verfasst, sollte man schon im Kopf haben. Und wenn nicht, sollte man lieber sein Gedächtnis auffrischen, statt sich unpassende Beispiele auszudenken. [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > negativer addresszeiger? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|