amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Gleiches Programm wird von GCC kompiliert aber nicht von G++ ? [ - Search - New posts - Register - Login - ]

1 -2- 3 [ - Post reply - ]

2005-08-12, 11:02 h

Solar
Posts: 3680
User
Zitat:
Original von gni:
Warum sollte ich bei 'char *foo = "ein string"' zwingend const brauchen?

Wenn Du ausdrücken möchtest, das der Speicherbereich, auf den foo zeigt, auch beschreibbar ist, natürlich nicht.

Aber wenn der Code später mal in ein ROM gebrannt werden soll (und foo somit in nicht beschreibbaren Speicher liegt), hättest Du dann nicht gerne eine Warnung vor einem Schreibzugriff, bevor Du das erste ROM verbrannt hast?

Von wegfallenden Optimierungsmöglichkeiten für den Compiler (der z.B. einen const-Parameter nicht unbedingt kopieren muß) gar nicht zu reden.

Zitat:
Zitat:
Und der Grund, warum heute kaum noch in C und hauptsächlich in C++ entwickelt wird, ist die bessere Wartbarkeit von C++-Code.
Ach?

Willst Du mich jetzt auf den Arm nehmen oder was?

[ - Answer - Quote - Direct link - ]
2005-08-12, 11:35 h

whose
Posts: 2156
User
Zitat:
Original von Solar:
Kinder, solange ihr von der Semantik von "const" keine Ahnung habt, und ernsthaft glaubt der Hauptzweck von C++ sei, "sicherere" Anwendungen zu schreiben, diskutiert doch besser nicht darüber, OK?

Wer glaubt, daß der Hauptzweck von C++ sei, "sichere" Anwendungen zu schreiben? Wenn Du nur Unterstellungen parat hast, diskutier doch besser nicht mit uns darüber, ok?

Zitat:
Wenn etwas durch eine Konstante initialisiert werden darf (weil es von den entsprechenden Funktionen nicht verändert wird), muß es auch "const" deklariert werden! Das hat nichts mit C++ zu tun und ist schon in C schlichtweg falsch - nur daß sich der Compiler nicht so sehr darüber beschwert.

Wenn Du den ganzen Sermon mal richtig gelesen hättest, wäre Dir aufgefallen, daß ich Holger die Gründe dafür dargelegt habe, warum man es damals nicht als const deklariert hat. Daß DU das heute anders machen würdest, steht auf einem ganz anderen Blatt. Und bei "const" läßt auch ein C-Compiler nur ungern mit sich reden :D

Zitat:
Genau wie solche Sachen wie signed-Werte für Dateigrößen etc. - das hat nichts mit den "guten alten Zeiten" zu tun, sondern damit, das die Jungs damals unter Zeitdruck schlicht Fehler gemacht haben.

Soweit waren wir ja noch gar nicht. Und alles auf den Zeitdruck zu schieben spricht, ehrlich gesagt, von Nichtwissen um die Praktiken der Vergangenheit.

Zitat:
Und der Grund, warum heute kaum noch in C und hauptsächlich in C++ entwickelt wird, ist die bessere Wartbarkeit von C++-Code. (Wir gehen hier mal auf beiden Seiten von Leuten aus, die wissen, was sie tun.)

Ist Dir das Wort "Heute" in Deinem Satz aufgefallen? Aber auch früher wußten die Leute, was sie tun. Vielleicht sogar mehr als heute...

Grüße


--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 12.08.2005 um 12:25 Uhr editiert. ]

[ - Answer - Quote - Direct link - ]
2005-08-12, 11:38 h

whose
Posts: 2156
User
Zitat:
Original von Solar:
Zitat:
Original von gni:
Warum sollte ich bei 'char *foo = "ein string"' zwingend const brauchen?

Wenn Du ausdrücken möchtest, das der Speicherbereich, auf den foo zeigt, auch beschreibbar ist, natürlich nicht.

Laß diesen Satz zusammen mit meinen Ausführung einmal richtig auf Dich wirken. Vielleicht kapierst Du dann endlich, was ich seit nem dutzend Posts erläutere...

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]
2005-08-12, 13:11 h

Solar
Posts: 3680
User
Zitat:
Original von whose:

Wer glaubt, daß der Hauptzweck von C++ sei, "sichere" Anwendungen zu schreiben?

Du offenbar. Ich zitiere:

Zitat:
Original von whose:
Zitat:
Original von Solar:
Heute programmiert außerhalb des Amiga-Sektors kaum noch jemand ganze Anwendungen in C...
Sind diese Anwendungen wirklich sicherer als früher? Oder meinen die Entwickler das nur?

Von Sicherheit habe ich nicht gesprochen.

Zitat:
Wenn Du nur Unterstellungen parat hast...

:angry:

Offensichtlich mehr als das.

:angry:

Zitat:
Wenn Du den ganzen Sermon mal richtig gelesen hättest, wäre Dir aufgefallen, daß ich Holger die Gründe dafür dargelegt habe, warum man es damals nicht als const deklariert hat.

Ja, in völliger Verkennung dessen, was "const" eigentlich an welcher Stelle so genau bewirkt.

Paragraphenweise und über mehrere Posts hinweg läßt Du Dich darüber aus, das die Struktur ja wiederverwendbar sein soll und es deshalb kein "const char *" sein darf... was schlicht Unsinn ist.

Dann fängst Du sogar an, von Assembler und der Unmöglichkeit "narrensicherer" Programmierung zu fabulieren... hallo? Auf welcher Tangente bist Du denn?

Es ging um Amaris' Problem, das sich aus der nachlässig programmierten API ergibt. Nicht um "wasserdichte" Programmiersprachen. (Java gibbet's auf dem Amiga bis auf weiteres nicht, und selbst damit programmiert man sich in < 100 Zeilen ein Speicherleck.)

Zitat:
...alles auf den Zeitdruck zu schieben spricht, ehrlich gesagt, von Nichtwissen um die Praktiken der Vergangenheit.

Welche großartigen Praktiken waren das denn? Bring's mal bitte auf den Punkt, ich bin gespannt.

Zitat:
Zitat:
Und der Grund, warum heute kaum noch in C und hauptsächlich in C++ entwickelt wird, ist die bessere Wartbarkeit von C++-Code. (Wir gehen hier mal auf beiden Seiten von Leuten aus, die wissen, was sie tun.)

Ist Dir das Wort "Heute" in Deinem Satz aufgefallen? Aber auch früher wußten die Leute, was sie tun. Vielleicht sogar mehr als heute...

Offenbar nicht, denn sonst wäre man z.B. an dieser Stelle gründlicher vorgegangen.

[ Dieser Beitrag wurde von Solar am 12.08.2005 um 15:01 Uhr editiert. ]

[ - Answer - Quote - Direct link - ]
2005-08-12, 13:13 h

Solar
Posts: 3680
User
Zitat:
Original von whose:
Zitat:
Original von Solar:
Zitat:
Original von gni:
Warum sollte ich bei 'char *foo = "ein string"' zwingend const brauchen?
Wenn Du ausdrücken möchtest, das der Speicherbereich, auf den foo zeigt, auch beschreibbar ist, natürlich nicht.
Laß diesen Satz zusammen mit meinen Ausführung einmal richtig auf Dich wirken. Vielleicht kapierst Du dann endlich, was ich seit nem dutzend Posts erläutere...

Da gibt's nichts zu kapieren, weil Du seit 'nem dutzend Posts etwas zu erläutern versuchst, von dem außer Dir niemand redet.

[ - Answer - Quote - Direct link - ]
2005-08-12, 22:30 h

Holger
Posts: 8116
User
Zitat:
Original von gni:
Zitat:
Solar:
Kinder, solange ihr von der Semantik von "const" keine Ahnung habt, und ernsthaft glaubt der Hauptzweck von C++ sei, "sicherere" Anwendungen zu schreiben, diskutiert doch besser nicht darüber, OK?
Schön das wenigstens einer Durchblick hat...
Was meinst Du damit? Hast Du mal die Postings richtig gelesen? Um mich selbst zu zitieren:
Zitat:
Original von Holger:
Zitat:
( Original von whose: )
Sind diese Anwendungen wirklich sicherer als früher? Oder meinen die Entwickler das nur?
Du verwechselt Typsicherheit mit Sicherheit. Es geht nicht darum, eine Anwendung sicherer zu machen.

Also Solar's Posting war nicht das erste mit einer solchen Aussage.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2005-08-12, 22:49 h

Holger
Posts: 8116
User
Zitat:
Original von whose:
Zitat:
Original von Holger:
1. Strings, die aus der locale.library kommen, sind Konstanten.
Falsch. Diese Stringzeiger sind zwar als READ ONLY in den Autodocs kommentiert, aber nicht als Zeiger auf einen konstanten String deklariert (STRPTR, ohne CONST davor). Intern sind es sowieso keine Konstanten sondern ein veränderlicher Puffer, aus dem Du Deinen Text bis zur nächsten Verwendung von z.B. GetLocaleStr() herauskopieren kannst.
Du willst es einfach nicht begreifen. Intern kann die locale.library mit dem Puffer machen was es will. Er wird aber als konstanter String herausgegeben. Und verdammt noch mal alle hier wissen, daß die commodore-Entwickler nachlassig programmiert haben, deshalb wissen wir auch, daß die const-Deklaration fehlt.
Was Du immer noch nicht begriffen hast, ist daß wenn die const-Deklaration vorhanden wäre, wie es korrekt wäre, selbstverständlich die locale.library weiterhin mit veränderbaren Puffern hantieren könnte. Sie würden bei herausgeben zu Konstanten werden, ohne daß ein cast benötigt wird. Denn es ist die natürliche Vorgehensweise, wie sie vom Compiler unterstützt wird.

Im Nachhinein innerhalb der Anwendung aus diesem const-String wieder einen veränderlichen zu machen, ist ein Programmierfehler, den der Compiler zu recht moniert. Ohne weitere Diskussion.
Zitat:
Schwupps! Spätestens jetzt hätte Dich Dein Compiler in den Hintern gebissen, wenn Du eine Erweiterung zur locale.library bauen wolltest, die auf eben diesen Puffer schreibend zugreifen muß und der wäre als CONST STRPTR deklariert.
Begreif es doch endlich. Wie die locale.library ihre strings intern speichert, hat nicht damit zu tun, mit welchem typen sie sie herausgibt. Aus internen mutable Objekten beim herausreichen const zu machen, ist ein natürlicher Vorgang.
Und außerhalb der locale.library gibt es keine "Erweiterung zur locale.library". Hat es auch keine zu geben.
Zitat:
Allerdings kannst Du das nicht, wenn Du intern diese Struktur verwendest und dann versuchst, den Speicher dieses (konstanten!) Strings wiederzuverwenden.
Die locale.library benutzt nirgendwo intern eine IText-Struktur, da kannst Du sicher sein.
Zitat:
Meine Ausführungen sind nicht falsch, Du bist nur zu sehr in modernem Denken versunken.
Blödsinn, Du hast einfach immer noch nicht begriffen, was const bedeutet und versuchst die Begründung für die falschen Header-Definitionen im Amiga-API anhand einer völlig falschen Deutung von const herzuleiten.

Natürlich lieferst Du damit einen durchaus möglichen Grund. Sollten alle Commodore-Entwickler genauso falsche Vorstellung von den C-Datentypen gehabt haben, könnte das die Ursache sein.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2005-08-12, 23:12 h

Holger
Posts: 8116
User
Zitat:
Original von whose:
Wir unterhalten uns über eine Sache, die lange, laaaange Zeit vor der allgemeinen Anerkennung heutiger Entwicklungsdogmen ihren Anfang nahm.
Schon mal falsch. Wir reden vom AmigaOS, das Mitte der 80er entwickelt wurde. Und wir reden von const und signed, das damals beides schon ein alter Hut war.
Zitat:
Zu dieser Zeit war es noch üblich, Speichersparend zu entwickeln, das schließt die Wiederverwendung einmal angelegter Buffer mit ein. Diese konnten im Quellcode durchaus auch ursprünglich in Form von Stringkonstanten deklariert worden sein.
Dieser *überhaupt nicht normale Fall* kann durchaus mit einem einzigen cast pro Puffer erledigt werden.
Und vor allem: was hat das mit den Deklarationen des API zu tun?
Zitat:
Wenn die ehemaligen Commodore-Entwickler genau dieses taten (und sie taten es, einen zur Wiederverwendung vorgesehenen Puffer in Form einer Stringkonstanten zu definieren!), hätten sie sich selbst ins Knie geschossen, wenn sie bei einer Funktion, welche mit der IText-Struktur arbeitet, eine Unveränderbarkeit eben dieses Puffers vorausgesetzt hätten.
Erstens besteht das AmigaOS zu 90% aus Code, der von mehreren Tasks gleichzeitig ausgeführt werden kann, womit string-Konstanten, die in einem statischen Block liegen, auf keinen Fall als Puffer benutzt werden können.
Sollte tatsächlich dort eine solcher String als Puffer benutzt worde nein, haben sich die Commodore-Entwickler bereits in's Knie geschossen, und es wäre durchaus von Vorteil gewesen, wenn der Compiler vor einem solchen Gau gewarnt hätte.
Aber irgendwie bezweifle ich, daß so ein übler Bug nach Kickstart 1.1 noch irgendwo wiederholt wurde.
Zitat:
Dann hätte sie der eigene Compiler zeitweise quasi von der Arbeit ausgesperrt (Glaubst Du jetzt endlich, daß ich den Unterschied zwischen einem Zeiger auf eine Stringkonstante und einem konstanten Zeiger auf einen String.
Nein.
Zitat:
Das ist vom heutigen Standpunkt aus gesehen zwar übelster Pfusch am Bau, aber ich rede eben nicht von heutigen Standpunkten.
Die Definition von "Pfusch am Bau" hat sich nie geändert. Und wie oben schon ausgeführt, kann eine solche Vorgehensweise im AmigaOS nie funktioniert haben.
AmigaOS ist ein Multitasking-System, String-Konstanten als Puffer zu mißbrauchen, kann nur in einer einzelnen Anwendung funktioniert haben. Und auch damals gab es schon optimierende Compiler, die gleiche String-Konstanten auf einen Speicherbereich gelegt haben. Wäre dann ziemlich blöd, wenn ein Programmteil ein String-Konstante als schreibbaren Puffer mißbraucht, während ein anderer Teil eine andere Konstante, mit gleichem Inhalt wie der ursprüngliche Inhalt der ersten Konstantefür andere Zwecke nutzen will. Ziemlich blöd.
Zitat:
Dadurch stellt sich auch die Frage nach der "Sicherheit" (Abstürze, Aushebelung von Sicherheitsmechanismen etc. pp.) eines Programms quasi nicht mehr, welche heutzutage ja ein wichtiges, aber durch die strenger Typisierung mancher Compiler lange nicht ausgestandenes Thema ist, wie Du sicher schon selbst erfahren hast.
Ne, habe ich nicht, denn ich habe nie einen Zusammenhang zwischen Typisierung und Sicherheit gesehen. Es geht darum, die Codequalität zu verbessern und Fehlerquellen zu reduzieren, mehr nicht.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2005-08-15, 10:17 h

gni
Posts: 1106
User
Zitat:
Holger:
Zitat:
gni:
Zitat:
Solar:
Kinder, solange ihr von der Semantik von "const" keine Ahnung habt, und ernsthaft glaubt der Hauptzweck von C++ sei, "sicherere" Anwendungen zu schreiben, diskutiert doch besser nicht darüber, OK?
Schön das wenigstens einer Durchblick hat...
Was meinst Du damit?
Mich stört seine undifferenzierte Sichtweise, die in dem Zitat nur allzu deutlich wird.

[ - Answer - Quote - Direct link - ]
2005-08-15, 10:50 h

Solar
Posts: 3680
User
Zitat:
Original von gni:
Mich stört seine undifferenzierte Sichtweise, die in dem Zitat nur allzu deutlich wird.

Mir ist erst im Nachhinein aufgefallen, das es eigentlich nur whose ist, der hier das Kapitel "const" anscheinend übersprungen hat. Das hätte ich deutlicher machen können, ja.

Ansonsten differenziere ich bei semantischen Fehlern nicht nach solchen, die der Compiler anmeckert (wie die Warnung, über die Amaris stolperte), und solchen, die der Compiler nicht mitbekommt (wie der const char * = "xyz" aus Deinem Beispiel).

Welcher Teil davon Dich jetzt dermaßen stört, weiß ich nicht.


[ - Answer - Quote - Direct link - ]
2005-08-15, 13:02 h

whose
Posts: 2156
User 		@Solar:

Ich kanns mir zwar vorstellen, aber das soll gni selbst schreiben.

Wie wär's, wenn wir dieses Kapitel hier schließen? Holger und Du beharrt auf Eurer Meinung, ich hätte nicht verstanden, was da passiert ist und wie sich das heute bemerkbar macht. Gut, akzeptiere ich so. Ich werd auch nie wieder versuchen, die lustigen (und funktionierenden, lieber Holger. Ich sage dazu nur Init...()) Tricks von damals zu erläutern.

Tut mir nur bitte den Gefallen und laßt die Panikmache in Sachen AmigaOS-API weg. Statt dessen könntet ihr Euch an die von mir angeregte Lib setzen, das wäre sinnvoller.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 15.08.2005 um 13:05 Uhr editiert. ]

[ - Answer - Quote - Direct link - ]
2005-08-15, 20:12 h

Holger
Posts: 8116
User
Zitat:
Original von whose:
Ich werd auch nie wieder versuchen, die lustigen (und funktionierenden, lieber Holger. Ich sage dazu nur Init...()) Tricks von damals zu erläutern.
Ich glaube aber, jetzt wird mir klarer, was Du eigentlich meinst. Nicht daß C= Entwickler diese Programmiertechnik benutzt hätten, sondern die zur Verfügung gestellten Routinen, die den Anwendungsprogrammierer zu einer solchen Programmierweise ermutigt haben, ala
char* bla=" ";
InitBitMap(bla);
meintest Du diese Art von tollen Ideen? (Die auf dem A500 wahrscheinlich 0.5 ms auf einer Laufzeit zwei Stunden Gewinn gebracht haben, wenn sie richtig angewendet wurden und zwei Tage zusätzliches Debugging wenn nicht).

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 15.08.2005 um 20:44 Uhr editiert. ]

[ - Answer - Quote - Direct link - ]
2005-08-15, 20:53 h

whose
Posts: 2156
User
Zitat:
Original von Holger:
Zitat:
Original von whose:
Ich werd auch nie wieder versuchen, die lustigen (und funktionierenden, lieber Holger. Ich sage dazu nur Init...()) Tricks von damals zu erläutern.
Ich glaube aber, jetzt wird mir klarer, was Du eigentlich meinst. Nicht daß C= Entwickler diese Programmiertechnik benutzt hätten, sondern die zur Verfügung gestellten Routinen, die den Anwendungsprogrammierer zu einer solchen Programmierweise ermutigt haben, ala
char* bla=" ";
InitBitMap(bla);
meintest Du diese Art von tollen Ideen? (Die auf dem A500 wahrscheinlich 0.5 ms auf einer Laufzeit zwei Stunden Gewinn gebracht haben, wenn sie richtig angewendet wurden und zwei Tage zusätzliches Debugging wenn nicht).

Jep, u.A. das meinte ich. Bis Kickstart 3.0 kamen solche "Tricks" aber durchaus auch im Kickstart vor, Reste davon findest Du heute noch u.A. in der locale.libary (der Stringpuffer. Wird zwar für jede Inkarnation der locale.library neu angelegt, sieht mir aber verdächtig nach einer "ehemaligen" Konstanten aus, wenn ich mir den Code drumherum so anschaue. Auf jeden Fall hats nen triftigen Grund, warum diese Stringzeiger nicht als CONST_STRPTR deklariert sind, sondern statt dessen als READ ONLY kommentiert wurden).

Frag mich aber bitte nicht, warum diese "Tricks" sich so lange gehalten haben. Vermutlich spielt Bequemlichkeit da eine große Rolle. Und die Tatsache, daß da einige Leute wohl lieber Assemblertricks benutzten, statt sich mit "Förmlichkeiten" zu arrangieren I-)

Grüße


--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233



[ Dieser Beitrag wurde von whose am 15.08.2005 um 21:11 Uhr editiert. ]

[ - Answer - Quote - Direct link - ]
2005-08-16, 10:02 h

gni
Posts: 1106
User
Zitat:
Original von Holger:
char* bla=" ";
InitBitMap(bla);
Bahnhof.

[ Dieser Beitrag wurde von gni am 16.08.2005 um 10:03 Uhr editiert. ]

[ - Answer - Quote - Direct link - ]
2005-08-16, 13:49 h

whose
Posts: 2156
User
Zitat:
Original von gni:
Zitat:
Original von Holger:
char* bla=" ";
InitBitMap(bla);
Bahnhof.

[ Dieser Beitrag wurde von gni am 16.08.2005 um 10:03 Uhr editiert. ]

Stell Dir vor, jemand wäre so brilliant, das char *bla=" " exakt so groß zu definieren, daß ne BitMap-Struktur reinpaßt. Also sizeof(bla) == sizeof(struct BitMap). Kein AllocMem(), kein FreeMem()...

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:07 h

Solar
Posts: 3680
User 		Also wird der Speicherbedarf durch den Linker gedeckt, bläst das Executable auf, verlangsamt den Ladevorgang, benötigt den Speicher während der gesamten Programmausführung statt nur bei Bedarf... riesig effizient.

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:16 h

whose
Posts: 2156
User
Zitat:
Original von Solar:
Also wird der Speicherbedarf durch den Linker gedeckt, bläst das Executable auf, verlangsamt den Ladevorgang, benötigt den Speicher während der gesamten Programmausführung statt nur bei Bedarf... riesig effizient.

Das hängt a) vom Compiler/Linker ab, b)von der Faulheit des Programmierers. Ist halt bedeutend weniger Tipparbeit und die Freigabe nimmt einem der Compiler auch noch ab I-)

Ganz nebenbei spart man sich dadurch einiges an Speicher, der sonst erst extern angefordert werden müßte (inkl. Overhead). Das der Speicher während der gesamten Programmausführung "verbraten" wird, war vielen Leuten gar nicht so bewußt und beim (teilweise handoptimierten) ROM-Code war das nicht wirklich ein Problem. Ein großes Thema vor nicht allzu langer Zeit...

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 16.08.2005 um 14:23 Uhr editiert. ]

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:20 h

gni
Posts: 1106
User
Zitat:
whose:
Stell Dir vor, jemand wäre so brilliant, das char *bla=" " exakt so groß zu definieren, daß ne BitMap-Struktur reinpaßt. Also sizeof(bla) == sizeof(struct BitMap). Kein AllocMem(), kein FreeMem()...
Woher hast Du dieses Konstrukt? Warum sollte man es *so* machen? Da kann ich auch gleich ein BitMap Objekt definieren. Ich kann immer noch nicht folgen.

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:32 h

whose
Posts: 2156
User
Zitat:
Original von gni:
Zitat:
whose:
Stell Dir vor, jemand wäre so brilliant, das char *bla=" " exakt so groß zu definieren, daß ne BitMap-Struktur reinpaßt. Also sizeof(bla) == sizeof(struct BitMap). Kein AllocMem(), kein FreeMem()...
Woher hast Du dieses Konstrukt? Warum sollte man es *so* machen? Da kann ich auch gleich ein BitMap Objekt definieren. Ich kann immer noch nicht folgen.

InitBitMap() als Beispiel kam von Holger. Das Spielchen kannst Du bei vielen Funktionen des AmigaOS treiben, nicht nur bei denen, die mit "Init" beginnen.

Das Konstrukt habe ich aus uraltem Code, teilweise ist der auf FishDisks zu finden, teilweise habe ich den vom CATS.

Warum man das *so* machen kann, habe ich oben erläutert. Weniger Tipparbeit, und bei gewissem Code (Module, die aus nem ROM ins RAM kopiert werden) sind die Nachteile kaum spürbar. Es ist halt simpler, Code mitsamt (kleinen) Datenbereichen einfach in den Speicher zu kopieren. Dank Relocation ist es noch nicht einmal ein Problem, an den Datenbereich heranzukommen.

Anders herum hast Du sonst den "Verwaltungskram" (Speicher anfordern/freigeben) und den eigentlich benötigten Speicher, was den Gesamtspeicherplatz doch mehr reduziert als die "Holzhammermethode".

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 16.08.2005 um 14:33 Uhr editiert. ]

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:34 h

Solar
Posts: 3680
User
Zitat:
Original von whose:

Das hängt a) vom Compiler/Linker ab...

Was hängt vom Compiler / Linker ab? Das für ein initialisiertes char-Array Speicher im Datensegment des Executables angelegt werden muß? Mit viel Glück kann ein mit (statt Leerzeichen) initialisiertes char-Array statt in .data in .bss angelegt werden - woraufhin es dann zumindest keinen Platz im Executable wegnimmt, aber immer noch beim Laden angelegt und Null-initialisiert (!) werden muß und über die gesamte Laufzeit der Anwendung Platz frißt.

Mehr holt Dir auch der weltbeste Compiler / Linker da nicht raus.

Zitat:
Ist halt bedeutend weniger Tipparbeit und die Freigabe nimmt einem der Compiler auch noch ab I-)

Ich bin immer wieder froh, wenn ich von Source-Code solcher "Programmierer" verschont bleibe. Eine Freigabe findet überhaupt nicht statt, und wenn Du lieber sizeof( BitMap ) manuell ermittelst und Leerzeichen zählst, bitte. Effizient ist das aber nicht.

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:38 h

Solar
Posts: 3680
User
Zitat:
Original von whose:

...und bei gewissem Code (Module, die aus nem ROM ins RAM kopiert werden) sind die Nachteile kaum spürbar.

Ach, ROM-Speicher darf's auch noch kosten? War ja quasi für lau und in rauhen Mengen zu haben seinerzeit, hat auch kaum was gekostet...

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:40 h

gni
Posts: 1106
User
Zitat:
whose:
Das Konstrukt habe ich aus uraltem Code, teilweise ist der auf FishDisks zu finden, teilweise habe ich den vom CATS.
Dann war das eben fehlerhaften Code. Nur was hat das jetzt alles mit dem Design des AmigaOS zu tun? Ich habe irgendwo den Faden verloren.
Zitat:
Es ist halt simpler, Code mitsamt (kleinen) Datenbereichen einfach in den Speicher zu kopieren.
Diese Methode zum Platz reservieren mag unorthodox sein, aber wo genau ist jetzt das Problem? Das der String read-only ist? Das sich das mit neuen Compilern nicht übersetzen läßt?

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:48 h

whose
Posts: 2156
User
Zitat:
Original von Solar:
Zitat:
Original von whose:

...und bei gewissem Code (Module, die aus nem ROM ins RAM kopiert werden) sind die Nachteile kaum spürbar.

Ach, ROM-Speicher darf's auch noch kosten? War ja quasi für lau und in rauhen Mengen zu haben seinerzeit, hat auch kaum was gekostet...

Was beißt Dich wohl mehr, wenn Du einen Computer baust? Ein ROM, welches keine oder "heruntergedrehte" Ausschmückungen enthält (Bootlogo), oder RAM, das zu schnell voll ist, den Computer unbenutzbar macht und teurer als das ROM ist?

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:50 h

whose
Posts: 2156
User
Zitat:
Original von gni:
Zitat:
whose:
Das Konstrukt habe ich aus uraltem Code, teilweise ist der auf FishDisks zu finden, teilweise habe ich den vom CATS.
Dann war das eben fehlerhaften Code. Nur was hat das jetzt alles mit dem Design des AmigaOS zu tun? Ich habe irgendwo den Faden verloren.
Zitat:
Es ist halt simpler, Code mitsamt (kleinen) Datenbereichen einfach in den Speicher zu kopieren.
Diese Methode zum Platz reservieren mag unorthodox sein, aber wo genau ist jetzt das Problem? Das der String read-only ist? Das sich das mit neuen Compilern nicht übersetzen läßt?

Das der String ReadOnly ist und sich sowas mit bestimmten _alten_ Compilern auch nicht übersetzen ließ.

Üble Tricksereien halt.

Und das Thema lautete: Wie geht man mit Altlasten um?

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:55 h

Solar
Posts: 3680
User
Zitat:
Original von whose:

Was beißt Dich wohl mehr, wenn Du einen Computer baust? Ein ROM, welches keine oder "heruntergedrehte" Ausschmückungen enthält (Bootlogo), oder RAM, das zu schnell voll ist, den Computer unbenutzbar macht und teurer als das ROM ist?

Du tauschst hier ein paar Byte Programmcode (Aufruf der Speicheranforderung + Fehlerverarbeitung, Verwaltungsinformation in der Speicherliste) und einen nur bei Bedarf belegten Speicherbereich gegen einen statisch in ROM und RAM verbrauchten Block, der vom Kopieren des ROM bis zum Ausschalten des Rechners dauerhaft belegt ist.

Wenn Du jetzt über die paar Taktzyklen Zeitersparnis diskutiert hättest... aber Platz sparen sieht anders aus. (mov...)

[ - Answer - Quote - Direct link - ]
2005-08-16, 15:35 h

gni
Posts: 1106
User
Zitat:
whose:
Zitat:
Original von gni:
Diese Methode zum Platz reservieren mag unorthodox sein, aber wo genau ist jetzt das Problem? Das der String read-only ist? Das sich das mit neuen Compilern nicht übersetzen läßt?
Das der String ReadOnly ist und sich sowas mit bestimmten _alten_ Compilern auch nicht übersetzen ließ.
Leider beides falsch ;-) Der Code ließ sich garantiert übersetzen und hat auch funktioniert, sonst hätte man es doch anders geschrieben oder? Und zweitens haben alte (K&R) Compiler Stringliterale in den Datenbereich gelegt. Damit waren sie schreibar und es gab Programme, die auch davon ausgingen, das sie schreibar sind. Deswegen gab es beim GCC bis einschließlich 3.4 die Option "-fwritable-strings".
Zitat:
Üble Tricksereien halt.
Sicher. Über den Grund dieser Tricksereien können wir aber nur Mutmaßungen anstellen.
Zitat:
Und das Thema lautete: Wie geht man mit Altlasten um?
Danke. Allerdings glaube ich nicht, das so alte Programme noch Bedeutung haben.

[ - Answer - Quote - Direct link - ]
2005-08-16, 18:28 h

Holger
Posts: 8116
User
Zitat:
Original von gni:
Zitat:
whose:
Stell Dir vor, jemand wäre so brilliant, das char *bla=" " exakt so groß zu definieren, daß ne BitMap-Struktur reinpaßt. Also sizeof(bla) == sizeof(struct BitMap). Kein AllocMem(), kein FreeMem()...
Woher hast Du dieses Konstrukt? Warum sollte man es *so* machen? Da kann ich auch gleich ein BitMap Objekt definieren. Ich kann immer noch nicht folgen.
Aaaaaalso....

Ich nehme mal an, die ursprüngliche Idee war folgende:

Am Anfang des Programms:

ptr = AllocMem(max(max(sizeof(struct BitMap), sizeof(struct RastPort)), sizeof(struct WhaterEverElse));

Später:

InitBitMap(ptr);

doSomethingThatNeedsABitMap(ptr);

Noch später:

InitRastPort(ptr);

doSomethingThatNeedsARastPort(ptr);

Man hat damit also die gewaltige Ersparnis von einem AllocMem über eine große Laufzeit. Große Laufzeit muß hier angenommen werden, da innerhalb kleiner Zeitintervalle ansonsten die Initialisierung wesentlich teurer wäre und man wohl besser mehrere Speicherbereiche benutzen müßte.
Falls man weiß, was man tut
Andernfalls handelt man sich also eine Performance-Einbuße ein und hat häßlichen, unwartbaren Code.

Dummerweise hat man eine saubere Lösung ala AllocBitMap eben bis OS3.0 nicht zur Verfügung gestellt.

Nun aber zu etwas völlig anderem:
Warum habe ich dieses Beispiel durch einen const-String ergänzt? Weil oberes Beispiel ja keine const-Warnungen produzieren würde. Dafür ist es "noch zu sauber" programmiert :lach:

Da aber aber whose meinte, im C= Code gäbe es entsprechende Beispiele, wo eine Überprüfung der constness durch den Compiler Probleme machen würde (ok, wer da eigentlich Probleme macht...), habe ich also AllocMem durch einen const-String ersetzt.

Damit spart man ja auch immerhin zwei AllocMem-Aufrufe auf die gesamte Programmlaufzeit. :D

Zitat:
Original von Solar:
Also wird der Speicherbedarf durch den Linker gedeckt, bläst das Executable auf, verlangsamt den Ladevorgang, benötigt den Speicher während der gesamten Programmausführung statt nur bei Bedarf... riesig effizient.
Wie schon in einem früheren Posting sagte, ist alles noch viel schlimmer. Denn einige Compiler optimieren konstante Strings, in dem sie identische String in denselben statischen Speicherbereich legen. Programmcode wird ja immer als read-only angenommen.
Sobald also zwei verschiedene Programmteile diesen Trick mit einem Leerstring derselben Länge durchführen, hat man eine Zeitbombe.
Ach ja, prinzipiell könnte auch der Compiler vorhersagen, welcher Wert bei einem Lesezugriff auf diesen konstanten string herauskommen müßte und statt Werten aus der Laufzeit BitMap diese Konstanten in den Code einfügen.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 16.08.2005 um 18:36 Uhr editiert. ]

[ - Answer - Quote - Direct link - ]
2005-08-16, 18:47 h

Holger
Posts: 8116
User
Zitat:
Original von whose:
Warum man das *so* machen kann, habe ich oben erläutert. Weniger Tipparbeit, und bei gewissem Code (Module, die aus nem ROM ins RAM kopiert werden) sind die Nachteile kaum spürbar.
Hmm, über die nicht vorhandene Speicherersparnis und den kaum meßbaren Performancegewinn (wo es nicht gerade eine Einbuße verusacht), wurde ja schon gesprochen. Aber weniger Tipparbeit?
Für mich ist
bm=AllocBitMap();
immer kürzer als
bm=AllocMem(sizeof(struct BitMap), ...);
InitBitMap(bm);
und
ptr="          "
InitBitMap(bm);

ist keine wirkliche Verbesserung, selbst wenn es kürzer als Variante 2 wäre, stellt es doch nur ein Herumdoktorn an den Symptomen dar. Denn die das eigentliche Problem ist, daß man keine AllocBitMap-Funktion hatte. Die bedeutet nämlich auch weniger TippArbeit.
Zitat:
Anders herum hast Du sonst den "Verwaltungskram" (Speicher anfordern/freigeben) und den eigentlich benötigten Speicher, was den Gesamtspeicherplatz doch mehr reduziert als die "Holzhammermethode".

Könntest Du mir bitte erklären, was die "Holzhammermethode" gewesen wäre? Ich bin mit dieser Denkweise der ex-C= Entwickler nicht vertraut. Welche Alternativen spukten diesen Leuten denn noch im Kopf herum?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2005-08-17, 09:16 h

gni
Posts: 1106
User
Zitat:
Holger:
Denn einige Compiler optimieren konstante Strings, in dem sie identische String in denselben statischen Speicherbereich legen.
Ich kennen keinen ANSI/ISO C Compiler, der das nicht macht. Wobei zb. der der SAS/C sogar etwas cleverer vorgeht als GCC. SAS/C kann erkennt auch Substrings am Ende eines Strings.

[ - Answer - Quote - Direct link - ]
2005-08-17, 10:34 h

Holger
Posts: 8116
User
Zitat:
Original von gni:
Ich kennen keinen ANSI/ISO C Compiler, der das nicht macht. Wobei zb. der der SAS/C sogar etwas cleverer vorgeht als GCC. SAS/C kann erkennt auch Substrings am Ende eines Strings.
Dann hätte SAS/C also alle Leerstrings auf denselben Speicherbereich legen müssen? Mit welchem Compiler haben die Commodore-Entwickler dann gearbeitet?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]

1 -2- 3 [ - Post reply - ]


amiga-news.de Forum > Programmierung > Gleiches Programm wird von GCC kompiliert aber nicht von G++ ? [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.