C-Array? später ändern? - amiga-news.de Forum

amiga-news.de Forum > Programmierung > C-Array? später ändern?

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

12.09.2007, 18:23 Uhr

MaikG
Posts: 5172
Nutzer

Ich wieder :-)

hab da so ein ULong Teil,

Also so etwa:

ULONG Test[]={
GROUP_BackFill, 4,
GROUP_Spacing, GRSPACE_NARROW
};

nun würde ich gerne letzteren eintrag Variabel setzten können.
Ein if da reinsetzen geht nicht, eine Variable wird vom Compiler
auch nicht aktzeptiert.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2007, 18:37 Uhr

ZeroG
Posts: 1487
Nutzer

@MaikG:

code:

ULONG Test[]=
{
    GROUP_BackFill, 4,
    GROUP_Spacing, 0
};

Test[3] = GRSPACE_NARROW;

[ - Antworten - Zitieren - Direktlink - ]

12.09.2007, 20:20 Uhr

Holger
Posts: 8116
Nutzer

Oder Programm im C99 Modus übersetzen. Da sind Variablen in Initializern erlaubt. Sollte von vbcc und gcc unterstützt werden.

Ausdrücke können in C auch von Bedingungen abhängig gemacht werden, die Syntax lautet:
Bedingung? Ausdruck wenn positiv: Ausdruck wenn negativ.

Also zum Beispiel:

code:

Statt

if(x>max) msg="zu gross";
else if(x<min) msg="zu klein";
else msg="in ordnung";

kann man schreiben:

msg = x>max? "zu gross":  x<min? "zu klein": "in ordnung";

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

12.09.2007, 22:18 Uhr

MaikG
Posts: 5172
Nutzer

> ULONG Test[]=
> {
> GROUP_BackFill, 4,
> GROUP_Spacing, 0
> };
>
> Test[3] = GRSPACE_NARROW;
>

Und woher kommt die 3?
Ich meine 0 und 1 oder 1 und 2 würde mir noch einleuchten.

> msg = x>max? "zu gross": x<min? "zu klein": "in ordnung";

und das würde dann in dem Teil gehen?

[ - Antworten - Zitieren - Direktlink - ]

12.09.2007, 22:37 Uhr

Mad_Dog
Posts: 1944
Nutzer

Zitat:
Original von MaikG:
> ULONG Test[]=
> {
> GROUP_BackFill, 4,
> GROUP_Spacing, 0
> };
>
> Test[3] = GRSPACE_NARROW;
>

Und woher kommt die 3?
Ich meine 0 und 1 oder 1 und 2 würde mir noch einleuchten.

Die Elemente eines Arrays werden beginnend mit 0 durchnummeriert.
Test[3] bedeutet "das 4. Element aus diesem Array". Und das ist doch genau, was Du haben willst, oder?

Nochmal zum Mitschreiben:

code:

ULONG Test[]={
GROUP_BackFill, 4,
GROUP_Spacing, GRSPACE_NARROW
};

Damit sagst Du folgendes:

Gebe mir ein Array, das Elemente vom Typ ULONG enthält und Trage folgende Werte ein:

Element 0 = GROUP_Backfill
Element 1 = 4
Element 2 = GROUP_Spacing
Element 3 = GRSPACE_NARROW

Alles klar?

[ Dieser Beitrag wurde von Mad_Dog am 12.09.2007 um 22:42 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.09.2007, 23:01 Uhr

MaikG
Posts: 5172
Nutzer

>Die Elemente eines Arrays werden beginnend mit 0 durchnummeriert.
>Test[3] bedeutet "das 4. Element aus diesem Array".
>Und das ist doch genau, was Du haben willst, oder?

Ja, verstehe. Funktioniert aber nicht, der Compiler beschwert sich
das es bereits früher anders declariert wurde.

@Holger

Geht auch nicht, der Compiler erwartet eine Konstante.
Also die selbe Fehlermeldung als wenn ich einer Variablen die Konstante
zuweisen würde.

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 08:27 Uhr

thomas
Posts: 7718
Nutzer

Zitat:
Funktioniert aber nicht, der Compiler beschwert sich
das es bereits früher anders declariert wurde.

Ich verstehe nicht, warum du dich damit so schwer tust. Du kannst doch schon programmieren, du hast doch bisher Basic programmiert, oder nicht ?

Was du möchtest, ist doch dieses hier:

code:

dim Test(4)

Test(1) = GROUP_BackFill
Test(2) = 4
Test(3) = GROUP_Spacing

if hugo > egon then
   Test(4) = GRSPACE_WIDE
else
   Test(4) = GRSPACE_NARROW
endif

Wortwörtlich übersetzt nach C lautet das so:

code:

ULONG Test[4];

Test[0] = GROUP_BackFill;
Test[1] = 4;
Test[2] = GROUP_Spacing;

if (hugo > egon)
   Test[3] = GRSPACE_WIDE;
else
   Test[3] = GRSPACE_NARROW;

Nun ist es aber nicht optimal, jedes Feld des Arrays einzeln zu initialisieren, wenn es sich überall um Konstanten handelt. Deshalb kann man beim Reservieren des Speichers gleich eine initiale Belegung mit angeben. Das macht man dann so:

code:

ULONG Test[4] = {
   GROUP_BackFill,
   4,
   GROUP_Spacing
   };

if (hugo > egon)
   Test[3] = GRSPACE_WIDE;
else
   Test[3] = GRSPACE_NARROW;

Und wenn man dann noch zu faul ist, die Array-Elemente vorher zu zählen, kann man das auch dem Compiler überlassen. Natürlich muß man dann für das vierte Element einen Platzhalter angeben, den der Compiler mit zählt. Und das If kann man auch wie von Holger angegeben optimieren:

code:

ULONG Test[] = {
   GROUP_BackFill,
   4,
   GROUP_Spacing,
   0
   };

Test[3] = (hugo > egon ? GRSPACE_WIDE : GRSPACE_NARROW);

Jetzt hast du vermutlich die Variablendeklaration global gemacht, d.h. außerhalb jeder Funktion.

Code (wie if usw.) darf aber natürlich nur innerhalb einer Funktion stehen.

Also

code:

/* Globale Variablen */

ULONG Test[] = {
   GROUP_BackFill, 4,
   GROUP_Spacing, 0
   };

/* Hauptprogramm */

int main (void)

{
Test[3] = (hugo > egon ? GRSPACE_WIDE : GRSPACE_NARROW);

...

return (0);
}

Übrigens: vergiß im Original nicht das TAG_END am Ende, sonst gibt's komische Abstürze !

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomasrapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 09:55 Uhr

DrNOP
Posts: 4118
Nutzer

Zitat:
Original von Holger:
Ausdrücke können in C auch von Bedingungen abhängig gemacht werden, die Syntax lautet:
Bedingung? Ausdruck wenn positiv: Ausdruck wenn negativ.

... was auch nichts anderes als ein if - else Konstrukt ist. Ich persönlich finde das if - else auch leichter zu lesen, und wenn ich dann lesen muß daß dies hier die optimierte Variante ist bekomm' ich Gänsehaut!

Als alter Embedded-Programmier geb' ich dann mal den Tip, sich den Assembler-Output dieses Konstrukts anzusehen und mit dem analogen if - else zu vergleichen.

Das if - else erzeugt deutlich weniger Code als diese "optimierte" Variante. Merke: Nicht alles, was die Länge des Quellcodes optimiert, optimiert auch den ausführbaren Code...
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 10:30 Uhr

thomas
Posts: 7718
Nutzer

Zitat:
Original von DrNOP:
Als alter Embedded-Programmier geb' ich dann mal den Tip, sich den Assembler-Output dieses Konstrukts anzusehen und mit dem analogen if - else zu vergleichen.

Das if - else erzeugt deutlich weniger Code als diese "optimierte" Variante. Merke: Nicht alles, was die Länge des Quellcodes optimiert, optimiert auch den ausführbaren Code...

Als alter C64- und Amiga-Programmierer würde ich dir raten, mal das gleiche zu tun und dann aber ganz genau hinzuschauen.

Hier ist der Code, der von VBCC generiert wird:

code:

if (a > b)
	c = 5;
else
	c = 6;

code:

move.l	_a,d0
	cmp.l	_b,d0
	ble	l3
l2
	moveq	#5,d0
	move.l	d0,_c
	bra	l4
l3
	moveq	#6,d0
	move.l	d0,_c
l4

code:

c = (a > b ? 5 : 6);

code:

move.l	_a,d0
	cmp.l	_b,d0
	ble	l10
l9
	moveq	#5,d0
	bra	l11
l10
	moveq	#6,d0
l11
	move.l	d0,_c

Bei dieser einfachen Aufgabe unterscheidet sich das nur um eine Instruktion, aber bei komplexeren Anwendungen generiert die optimierte Variante deutlich kürzeren Code.

Vor allem bei sowas wie

code:

if (a > b)
	printf ("Dies ist ein Test %d %d 5n",funktion1(a),funktion2(b));
else
	printf ("Dies ist ein Test %d %d 6n",funktion1(a),funktion2(b));

Da ist

code:

printf ("Dies ist ein Test %d %d %dn",funktion1(a),funktion2(b),(a > b ? 5 : 6));

erheblich günstiger.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomasrapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 10:34 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von DrNOP:
... was auch nichts anderes als ein if - else Konstrukt ist. Ich persönlich finde das if - else auch leichter zu lesen, und wenn ich dann lesen muß daß dies hier die optimierte Variante ist bekomm' ich Gänsehaut!

Also ich habe nirgends etwas von optimiert geschrieben. Der Punkt sollte eigentlich klar sein. A? B: C ist ein Ausdruck, während if(A) B; else C; ein Statement ist. In C macht das leider viel zu selten einen Unterschied, weswegen man ja auch so viel eigentlich offensichtlichen Unsinn ohne Beanstandung durch einen C-Compiler jagen kann. Trotzdem kann man eben in einem Array-Initializer nur Ausdrücke verwenden.

Ich bevorzuge Code, der ganz klar die Intention des Programmierers dokumentiert. Und wenn ich eine Operation habe, die definitiv ausgeführt werden soll, nur halt mit bedingungsabhängigen Parametern, dann benutze ich eben einen bedingten Ausdruck für eine eben nur einmal hingeschriebene Operation. Umgekehrt würde ich aber auch für zwei unterschiedliche Operationen auch grundsätzlich unterschiedliche Anweisungen, also mittels if hinschreiben.

Zitat:
Als alter Embedded-Programmier geb' ich dann mal den Tip, sich den Assembler-Output dieses Konstrukts anzusehen und mit dem analogen if - else zu vergleichen.

Jetzt bist Du es, der auf Performance herumreitet. Als alter nicht-embedded-Programmierer werde ich nicht in den Assembler-Output (für welchen Prozessor, mit welchem Compiler...) schauen. Der Compiler, den ich meistens verwendet, erzeugt für beide Konstrukte in 99% der Fälle den gleichen Code.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 11:03 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von MaikG:
Geht auch nicht, der Compiler erwartet eine Konstante.
Also die selbe Fehlermeldung als wenn ich einer Variablen die Konstante
zuweisen würde.

Ich verwies ja auf den C99-Standard, der natürlich von den Compilern unterschiedlich weit umgesetzt wird. Erstmal musst Du bei vbcc die Option -c99, bzw. beim gcc -std=c99 angeben, dann kann ich Dir allerdings nicht sagen, ob die aktuellste vbcc-Version es unterstützt, gcc tut es...

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 16:34 Uhr

MaikG
Posts: 5172
Nutzer

>Jetzt hast du vermutlich die Variablendeklaration global gemacht, d.h. außerhalb jeder Funktion.

Ja, das war es.

Bei Basic kann man so tun:

a(1)=5 rem Hier ist das Hauptprogramm

function

a(2)=6 rem Hier ist auch das Hauptprogramm

function

usw.
Eine Haupfunktion an sich gibt es nicht.

An viele eigenschaften von C muss man sich erstmal gewöhnen...

Danke @All

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 16:59 Uhr

thomas
Posts: 7718
Nutzer

@MaikG:

Zitat:
An viele eigenschaften von C muss man sich erstmal gewöhnen...

Das muß richtig heißen "viele schlechte Angewohnheiten, die man sich beim Gebrauch von Basic aneignet, muß man sich schleunigst abgewöhnen..."

Die Schachtelung von Blöcken und lokale Variablen innerhalb von Blöcken haben so ziemlich alle Programmiersprachen gemeinsam, außer Basic. Manche erlauben es, Unterprogramme innerhalb anderer Programme zu deklarieren. Das sind dann aber lokale Unterprogramme, die nur innerhalb des Blocks bekannt sind, in dem sie definiert wurden.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomasrapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 17:03 Uhr

bruZard
Posts: 307
Nutzer

Zitat:
Original von thomas:
@MaikG:

Zitat:
An viele eigenschaften von C muss man sich erstmal gewöhnen...

Das muß richtig heißen "viele schlechte Angewohnheiten, die man sich beim Gebrauch von Basic aneignet, muß man sich schleunigst abgewöhnen..."

Die Schachtelung von Blöcken und lokale Variablen innerhalb von Blöcken haben so ziemlich alle Programmiersprachen gemeinsam, außer Basic. Manche erlauben es, Unterprogramme innerhalb anderer Programme zu deklarieren. Das sind dann aber lokale Unterprogramme, die nur innerhalb des Blocks bekannt sind, in dem sie definiert wurden.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomasrapp.homepage.t-online.de/

Ist zwar Off-Topic, da nicht AMIGA ... aber schaue Dir mal BlitzMax von Mark Sibly an (BlitzMax ist die 3 Generation nach Blitzbasic2 für Amiga). Ist ein Basic-Derivat und haut Dir ganz schön auf die Finger wenn Du die Scopes über den Haufen wirfst oder einfach mal eben eine Variable ohne Scope-Def oder Datentyp benutzen willst

Nicht eben mal alle Basics über einen Kamm scheren

--
Wer glaubt dass Volksvertreter das Volk vertreten, der glaubt auch dass Zitronenfalter Zitronen falten

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 17:21 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von bruZard:
Ist zwar Off-Topic, da nicht AMIGA ... aber schaue Dir mal BlitzMax von Mark Sibly an (BlitzMax ist die 3 Generation nach Blitzbasic2 für Amiga). Ist ein Basic-Derivat und haut Dir ganz schön auf die Finger wenn Du die Scopes über den Haufen wirfst oder einfach mal eben eine Variable ohne Scope-Def oder Datentyp benutzen willst Nicht eben mal alle Basics über einen Kamm scheren

Es soll auch C-Compiler geben, die Dir wenigstens eine Warnung bei bestimmten sinnlosen oder offensichtlich fehlerhaften Konstrukten geben. Das ändert aber nichts an der Sprache C selbst, wie sie halt im Standard definiert ist (irgendwann endlich mal wurde...).

Und so gilt auch für Basic, dass Basic erst einmal die grundlegende Sprache ist, wie sie einst definiert wurde und von fast allen Basic-Dialekten erst mal unterstützt wird. Was darüber hinaus einige Dialekte machen, sagt nichts über Basic aus.

Übrigens sehe ich gar nicht ein, warum ich in einer Programmiersprache grundsätzlich eine Deklaration mit Datentyp brauche. Richtig implementiert kann man auch ohne auskommen. Einige Sprachen verlangen grundsätzlich eine formale Deklaration, Basic nicht. Warum ich noch Basic verwenden sollte, wenn der benutzte Dialekt mir diesen (einzigen?) Vorteil auch noch zunichte macht, ist mir schleierhaft.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 18:25 Uhr

bruZard
Posts: 307
Nutzer

Weil ein

code:

struct MyStruct
{
   int iMyValue
}

unlesbarer ist als ein

code:

Type TMyStruct
  Field iMyValue:Int
End Type

Basic beschreibt seinen Quelltext in einer Sprach-nahen Variante während C/C++ extrem abstrahiert sind ... ein cout << irgendwas ist halt komplizierter als ein Print "irgendwas". Ich sehe nicht ein warum ich meine kostbare Zeit auf einen Syntax verbraten soll anstatt beinahe narrativ zu programmieren.

--
Wer glaubt dass Volksvertreter das Volk vertreten, der glaubt auch dass Zitronenfalter Zitronen falten

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 18:37 Uhr

Mad_Dog
Posts: 1944
Nutzer

Zitat:
Original von thomas:
@MaikG:

Zitat:
An viele eigenschaften von C muss man sich erstmal gewöhnen...

Das muß richtig heißen "viele schlechte Angewohnheiten, die man sich beim Gebrauch von Basic aneignet, muß man sich schleunigst abgewöhnen..."

Der in Amiga-Kreisen bekannte Sachbuchautor Peter Wollschläger hat das mal so formuliert:

Bei BASIC nimmt Dich die Mama an die Hand. Bei C darfst Du bei Rot über die Ampel gehen.

Abgesehen davon kann man auch noch in einer als "idiotensicher" geltenden Programmiersprache (z.B. Ada95) großen Mist bauen
(siehe auch http://ada_programmiersprache.know-library.net/).

--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 18:40 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von bruZard:
Basic beschreibt seinen Quelltext in einer Sprach-nahen Variante während C/C++ extrem abstrahiert sind ... ein cout << irgendwas ist halt komplizierter als ein Print "irgendwas".

Das cout<< irgendwas ist schon nicht mehr Teil der Sprache, auch wenn es den Weg in die Standardbibliothek geschafft hat. printf(...) gibt's immer noch, und letztendlich benutzt ein Programmierer in einer komplexen Anwendung eh keines von beiden -- wie bei Basic-Programmen auch, schließlich schreibt ein in die Sprache eingebautes PRINT ohnehin nicht in die richtige Stelle eines mittels externer Bibliotheken konstruierten GUIs.

Zitat:
Ich sehe nicht ein warum ich meine kostbare Zeit auf einen Syntax verbraten soll anstatt beinahe narrativ zu programmieren.

Solange es Dir nur um die geschweiften Klammern geht, kann ich diese Argumentation kaum nachvollziehen. Da könnte ich locker kontern, dass es äußerst unintuitiv ist, dass ein Array-Zugriff in Basic genauso wie ein Funktionsaufruf aussieht. Da ist eine eckige Klammer für ein Array und eine runde für eine Funktion deutlich leichter nachzuvollziehen.

Ich halte C auch für eine Sprache, die weder leicht zu erlernen ist, noch irgendwie den Lernaufwand durch nützliche Eigenarten rechtfertigen würde. Aber Basic als bessere Alternative hinzustellen, halte ich für sehr gewagt.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 18:46 Uhr

Mad_Dog
Posts: 1944
Nutzer

Zitat:
Original von bruZard:
Weil ein
code:
struct MyStruct { int iMyValue }
unlesbarer ist als ein
code:
Type TMyStruct Field iMyValue:Int End Type

Das finde ich auch nicht "unlesbarer". Der Mensch ist eben ein Gewohnheitstier. Hast Du Dich erstmal an die eine Variante gewöhnt, kommt Dir die andere suspekt vor.

Zitat:
Basic beschreibt seinen Quelltext in einer Sprach-nahen Variante während C/C++ extrem abstrahiert sind ... ein cout << irgendwas ist halt komplizierter als ein Print "irgendwas". Ich sehe nicht ein warum ich meine kostbare Zeit auf einen Syntax verbraten soll anstatt beinahe narrativ zu programmieren.

Hier ging es um C und nicht C++. In C gibt es keine Objekte und Streams. Da gibt's solche Sachen wie printf.

Und Objektorientiertes Programmieren, wie wir es von C++ oder Java her kennen, ist eben nur eine andrere (manche würden auch sagen eine weiterentwickelte) Denkweise. Aber noch probiert sich Mike ja an C und nicht C++...

--
http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 13.09.2007 um 18:47 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 18:47 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Mad_Dog:
Der in Amiga-Kreisen bekannte Sachbuchautor Peter Wollschläger hat das mal so formuliert:

Bei BASIC nimmt Dich die Mama an die Hand. Bei C darfst Du bei Rot über die Ampel gehen.

Trifft aber nicht so den Kern der Sache, weil die Probleme bei Basic eben auch aus dem Fehlen einer solchen Führung herrühren. Basic sagt halt keinen Piep, wenn Du Dich bei einer Variable verschreibst, sie außerhalb ihres Kontext verwendest oder mit falschen Datentypen befüllst, wie es auch erlaubt, sich mittels GOTO "strukturierten" Programmteilen ins Knie zu schießen.

In letzterer Hinsicht hält es mit C mit, in ersterer übertrifft es C sogar. In einigen Dialekten muss man sogar bei Rot über die Ampel gehen.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 18:56 Uhr

Mad_Dog
Posts: 1944
Nutzer

Zitat:
Original von Holger:

...ihres Kontext verwendest oder mit falschen Datentypen befüllst, wie es auch erlaubt, sich mittels GOTO "strukturierten" Programmteilen ins Knie zu schießen.

In letzterer Hinsicht hält es mit C mit, in ersterer übertrifft es C sogar. In einigen Dialekten muss man sogar bei Rot über die Ampel gehen.

An was Wollschläger vielleicht auch nicht gedacht hat: Bei BASIC darfst Du auch wilde Lowlevel-Operationen ausführen z.B. einfach in irgendwelche Speicherstellen oder Register reinschreiben.

Vielleicht sollte ich es - Mike zuliebe - leiber nicht erwähnen, aber GOTO hat auch in C überlebt.

--
http://www.norman-interactive.com

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 19:39 Uhr

whose
Posts: 2156
Nutzer

Zitat:
Original von Holger:

Und so gilt auch für Basic, dass Basic erst einmal die grundlegende Sprache ist, wie sie einst definiert wurde und von fast allen Basic-Dialekten erst mal unterstützt wird. Was darüber hinaus einige Dialekte machen, sagt nichts über Basic aus.

Einspruch, Euer Ehren...

Du referierst doch so gern über Standards, dann schau doch mal in den (soweit ich weiß 1991 endgültig festgelegten) ANSI-Standard für BASIC rein. Da findest Du einiges, was Du der Sprache BASIC immer und immer wieder (durch schlichte Weglassung eben dieser Tatsachen) absprichst.

Da wären u.A. zu nennen: Lokale Variablen, Funktionen, Typprüfung und Vorabdeklaration.

Also all das, was nach Deiner Aussage nur "Dialekt-abhängig" ist. Ist es nicht.

Wenn Du allerdings nur das Minimal-ANSI-BASIC betrachtest, hast Du zweifellos Recht. Nur ist da die standardisierte Entwicklung von BASIC halt nicht stehengeblieben, wie Du es immer wieder so gern kolportierst.

Diese Art der Weiterentwicklung hat es übrigens bei nahezu allen Programmiersprachen gegeben und oftmals haben sich Hersteller von Compilern/Interpretern über die jeweiligen Standards hinweggesetzt, was, wie Du schon so treffend bemerktest, nichts über die Sprachdefinition an sich aussagt.

Zum momentanen Thema noch eine sehr persönliche Sicht der Dinge von mir:

Eine Sprache, in der man sich nicht mißverständlich oder gar unsinnig ausdrücken kann, ist eine tote Sprache, weil sie keine Kreativität erlaubt.

Grüße

--
---

µA1 PPC 750GX-800

A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

13.09.2007, 20:18 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von whose:
Du referierst doch so gern über Standards, dann schau doch mal in den (soweit ich weiß 1991 endgültig festgelegten) ANSI-Standard für BASIC rein. Da findest Du einiges, was Du der Sprache BASIC immer und immer wieder (durch schlichte Weglassung eben dieser Tatsachen) absprichst.

Wo kann man das denn nachlesen? Ich mein, außer durch Kaufen eines in der Praxis irrelevanten Buches?

Zitat:
Da wären u.A. zu nennen: Lokale Variablen, Funktionen, Typprüfung und Vorabdeklaration.

Gewiss doch, es gibt einiges. Solange aber z.B. Vorabdeklaration nicht zwingend ist, stellt sie nur überflüssige Schreibarbeit dar.

Zitat:
Wenn Du allerdings nur das Minimal-ANSI-BASIC betrachtest, hast Du zweifellos Recht. Nur ist da die standardisierte Entwicklung von BASIC halt nicht stehengeblieben, wie Du es immer wieder so gern kolportierst.

In der Praxis schon. Zumindest was standardkonforme Features angeht.

Zitat:
Diese Art der Weiterentwicklung hat es übrigens bei nahezu allen Programmiersprachen gegeben und oftmals haben sich Hersteller von Compilern/Interpretern über die jeweiligen Standards hinweggesetzt, was, wie Du schon so treffend bemerktest, nichts über die Sprachdefinition an sich aussagt.

Der Versuch, grundsätzliche Schwächen einer Programmiersprache im Nachhinein zu beheben, macht aus ihr keineswegs etwas grundsätzlich anderes. Natürlich stellt es aus meiner Sicht ein erstrebenswertes Ziel dar, dass sich sowohl Compiler-Entwickler, als auch Anwendungsprogrammierer an existierende Standards halten. Das ist aber etwas völlig anderes, als aus einem nicht oder kaum in der Praxis umgesetzten Standard (einer Weiterentwicklung) eine prinzipielle Aussage über eine Programmiersprache zu treffen.

Wenn man alle Schwächen von Basic behebt, dann noch Deklarationszwang einführt und das Ganze noch um OO etc. erweitert, kommt am Ende eine Sprache heraus, die zwar nicht zu 100% zu Oberon kompatibel ist, aber trotzdem fast genauso aussieht. Warum das dann noch Basic sein soll, nun ja...

Zitat:
Eine Sprache, in der man sich nicht mißverständlich oder gar unsinnig ausdrücken kann, ist eine tote Sprache, weil sie keine Kreativität erlaubt.

Mag für menschliche Sprachen gelten. Für Programmiersprachen nicht.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

14.09.2007, 00:39 Uhr

whose
Posts: 2156
Nutzer

Zitat:
Original von Holger:

Zitat:
Original von whose:
Du referierst doch so gern über Standards, dann schau doch mal in den (soweit ich weiß 1991 endgültig festgelegten) ANSI-Standard für BASIC rein. Da findest Du einiges, was Du der Sprache BASIC immer und immer wieder (durch schlichte Weglassung eben dieser Tatsachen) absprichst.
Wo kann man das denn nachlesen? Ich mein, außer durch Kaufen eines in der Praxis irrelevanten Buches?

Da es in Deiner Praxis irrelevant ist, hast Du natürlich auch nicht gegoogelt und gelesen. Interessiert Dich ja nicht wirklich. Ich weiß nicht, ob man über Dinge diskutieren sollte, die einen (außer mit Blick auf die Tatsache, daß sie nicht in das persönliche Bild einer perfekten Welt passen) eigentlich nicht interessieren.

Zitat:
Zitat:
Da wären u.A. zu nennen: Lokale Variablen, Funktionen, Typprüfung und Vorabdeklaration.
Gewiss doch, es gibt einiges. Solange aber z.B. Vorabdeklaration nicht zwingend ist, stellt sie nur überflüssige Schreibarbeit dar.

Und schon wieder... wer, außer Dir, behauptet denn, daß es nicht zwingend ist?

Zitat:
Zitat:
Wenn Du allerdings nur das Minimal-ANSI-BASIC betrachtest, hast Du zweifellos Recht. Nur ist da die standardisierte Entwicklung von BASIC halt nicht stehengeblieben, wie Du es immer wieder so gern kolportierst.
In der Praxis schon. Zumindest was standardkonforme Features angeht.

Grummel... eben nicht. Es bedeutet nicht, daß in der Praxis die standardisierte Entwicklung stehengeblieben ist, nur weil Du die Entwicklung nicht mehr mitverfolgt hast.

Zitat:
Zitat:
Diese Art der Weiterentwicklung hat es übrigens bei nahezu allen Programmiersprachen gegeben und oftmals haben sich Hersteller von Compilern/Interpretern über die jeweiligen Standards hinweggesetzt, was, wie Du schon so treffend bemerktest, nichts über die Sprachdefinition an sich aussagt.
Der Versuch, grundsätzliche Schwächen einer Programmiersprache im Nachhinein zu beheben, macht aus ihr keineswegs etwas grundsätzlich anderes. Natürlich stellt es aus meiner Sicht ein erstrebenswertes Ziel dar, dass sich sowohl Compiler-Entwickler, als auch Anwendungsprogrammierer an existierende Standards halten. Das ist aber etwas völlig anderes, als aus einem nicht oder kaum in der Praxis umgesetzten Standard (einer Weiterentwicklung) eine prinzipielle Aussage über eine Programmiersprache zu treffen.

Das ist ja das Problem: Du tust es ununterbrochen (eine prinzipielle Aussage über eine Programmiersprache treffen), weil Du glaubst, daß der Standard in der Praxis nicht umgesetzt wurde.

Du vermischst munter herstellereigene Erweiterungen des z.B. höchsten und weiterentwickelten Standards mit "nicht standardkonform", weil Compilerhersteller diesen Standard nochmal spezifisch erweitern.

Selbst AmiBlitz folgt ANSI-BASIC, erweitert selbiges aber nochmal. Die Anforderungen des Standards werden beibehalten.

Das gilt nicht nur für AmiBlitz sondern für viele andere BASIC-Dialekte ebenfalls. PureBasic, TrueBasic, BlitzMax usw. usw. Das sind BASIC-Dialekte, die immer noch verwendet werden. Nicht nur hobbymäßig. Das sind in der Praxis verwendete Sprachen, unabhängig davon, wie hoch oder niedrig Du den Praxiswert einschätzt.

Zitat:
Wenn man alle Schwächen von Basic behebt, dann noch Deklarationszwang einführt und das Ganze noch um OO etc. erweitert, kommt am Ende eine Sprache heraus, die zwar nicht zu 100% zu Oberon kompatibel ist, aber trotzdem fast genauso aussieht. Warum das dann noch Basic sein soll, nun ja...

B sah ehedem auch noch ganz anders aus, heute heißt es C++. Was solls? Es stört irgendwie niemanden außer Dir, daß manche der heute verwendeten BASICs nicht mehr so aussehen wie zu Zeiten des seligen C64.

So ganz verstehe ich nicht, wo genau eigentlich Dein Problem liegt. Einerseits mokierst Du Dich darüber, daß BASIC irgendwie nicht mehr wirklich relevant ist und bringst andererseits, wenn es um den Amiga geht (auf dem BASIC für einige Leute durchaus noch relevant ist), nichts, was für die Amiga-Programmierung relevant sein könnte, außer "vernichtende" Kritiken der jeweils verwendeten Programmiersprachen, die für Amiga relevant sind.

Das Amiga-Leben für Java-Entwickler mag ja hart sein, das ändert aber nichts daran, daß Java auf dem Amiga derzeit keine praktische Bedeutung hat, egal, wie geil man es persönlich findet. BASIC hingegen hat eine praktische Bedeutung auf dem Amiga, egal, wie schlecht man es persönlich findet. Es ändert nichts an den Tatsachen, wenn man ständig dagegen zu Felde zieht und zu diesem Zweck halbgare Argumente und schlechten Diskussionsstil verwendet.

Zitat:
Zitat:
Eine Sprache, in der man sich nicht mißverständlich oder gar unsinnig ausdrücken kann, ist eine tote Sprache, weil sie keine Kreativität erlaubt.
Mag für menschliche Sprachen gelten. Für Programmiersprachen nicht.

was zeigt, daß Du den Sinn nicht verstanden hast. Ohne "Fehler" keine Weiterentwicklung.

--
---

µA1 PPC 750GX-800

A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

14.09.2007, 01:07 Uhr

Mad_Dog
Posts: 1944
Nutzer

Wie das hier immer zu Grundsatzdisskusionen ausarten muß... der arme Mike

Ich glaube, Holger ging es darum, die Problematik aufzuzeigen, die entstehen kann, wenn man mit einer Programmiersprache seine ersten Schritte wagt, die einen eben nicht zum "sauberen Programmieren" zwingt. Dann kann es durchaus passieren, dass man sich einen schlechten Programmierstil angewöhnt.

Das merkt man übrigens auch, wenn man nachdem man C gelernt hat C++ lernt. Und letztendlich hängt es auchnoch davon ab, was einem der Compiler durchgehen lässt. Ich musste beispielsweise mal ein größeres Projekt von Windows auf Solaris und Linux portieren. Die Vorgänger haben mit einer alten Version des Borland C++ Compiler gearbeitet. Das war eine ziemlich nervige Angelegenheit, all die Sachen (auch offensichtliche logische Fehler) rauszufriemeln, die der Borland-Compiler durchgehen lassen hat, während der g++ klar gesagt hat "moment mal - so geht das aber nicht"...

Aber wir sollten hier Mike nicht allzu verwirren. Schließlich haben wir alle irgendwan mal klein angefangen - die meisten vermutlich auch mit irgend einem BASIC-Dialekt.

Übrigens: In jeder Programmiersprache kann man schlechten und/oder schwer nachvollziehbaren Code schreiben. Ich glaube, in dem Punkt sind wir uns alle einig.

Für Leute wie Mike ist es erstmal wichtig, dass sie überhaupt irgend ein lauffähiges Programm hinbekommen - d.h. auch Erfolgserlebnisse haben - egal wie wüst der Code auch aussehen mag. Alles weitere ergibt sich dann (hoffentlich) von selbst. Spätestens, wenn man seinen eigenen Code nicht mehr versteht, merkt man, dass man irgend was an seinem Programmierstil ändern muss... Und dann beginnt auch ein "BASIC-Erfahrener" die Zahl der globalen Variablen zu reduzieren, Spagetti-Code zu vermeiden, das Black-Box Prinzip anzuwenden usw..

--
http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 14.09.2007 um 01:13 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

14.09.2007, 17:53 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von whose:
Da es in Deiner Praxis irrelevant ist, hast Du natürlich auch nicht gegoogelt und gelesen.

Ich habe selbstverständlich google bemüht, aber offensichtlich genausowenig online-Ressourcen gefunden wie Du, der Du ja ein deutlich höheres Interesse an Links als Belege für Deine Behauptungen bzgl. der Standard haben müsstest, oder? Zumindest wäre es ja natürlich gewesen, meine Frage nach Links sinnvoll zu beantworten, wenn Du denn Links kennen würdest. Dein Verweis auf google ist also in diesem Zusammenhang wohl eher der Versuch, sich wie ein Arschloch zu verhalten, oder gibt es noch eine andere Interpretationsmöglichkeit?

Zitat:
Und schon wieder... wer, außer Dir, behauptet denn, daß es nicht zwingend ist?

Basic

Zitat:
B sah ehedem auch noch ganz anders aus, heute heißt es C++. Was solls? Es stört irgendwie niemanden außer Dir, daß manche der heute verwendeten BASICs nicht mehr so aussehen wie zu Zeiten des seligen C64.

Wenn Du behaupten willst, dass B und C++ ein und dieselbe Programmiersprache sind, dann ist ja alles klar. Dann kann man natürlich allen Programmieren wärmsten empfehlen, einen durch compiler-spezifische Erweiterungen aufgemotzten B-Dialekt zu vewenden, statt konsequent gleich mit C++ anzufangen. Merkst Du vielleicht jetzt, was an dem erweiterten Basic so sinnlos ist?

Zitat:
Einerseits mokierst Du Dich darüber, daß BASIC irgendwie nicht mehr wirklich relevant ist

falsch.

Zitat:
und bringst andererseits, wenn es um den Amiga geht (auf dem BASIC für einige Leute durchaus noch relevant ist), nichts, was für die Amiga-Programmierung relevant sein könnte, außer "vernichtende" Kritiken der jeweils verwendeten Programmiersprachen, die für Amiga relevant sind.

Wieder falsch.
Es ging um einen erweiterten Basic-Dialekt, der auf dem Amiga überhaupt nicht existiert.

Basic hat seine Stärken und Schwächen und erfüllt seinen Zweck, wo es seine (für Basic charakteristischen) Stärken ausspielen kann. Verfolge doch einfach mal die Diskussionen über Basic in den letzten Thread. Es gibt User, die immer noch MaxonBasic verwenden, obwohl es leistungsmäßig wesentlich bessere Alternativen in Form von aufgemotzten Basic-Dialekten gibt. Weil diese User mit diesen Alternativen nicht mehr klar kommen. Obwohl es eigentlich auch Basic sein soll.

Was ist also für Dich das Problem bei meiner Forderung, Basic einfach Basic sein zu lassen, wenn jemand eine Sprache ohne zwingende Deklarationen und der Möglichkeit, ad-hoc ohne hunderte includes mal ein kleines Programm zu schreiben, braucht, und für typsichere, performante Programme einfach eine Sprache zu verwenden, die das von Hause aus kann?

Zitat:
Das Amiga-Leben für Java-Entwickler mag ja hart sein, das ändert aber nichts daran, daß Java auf dem Amiga derzeit keine praktische Bedeutung hat, egal, wie geil man es persönlich findet.

Ich wüsste nicht, was Java in dieser Diskussion zu suchen hat.

Zitat:
was zeigt, daß Du den Sinn nicht verstanden hast. Ohne "Fehler" keine Weiterentwicklung.

Aus hundertfachen Wiederholungen der gleichen Fehler erwächst keine Weiterentwicklung. Selbst in formal korrekten Programmcode bleibt genug Spielraum für Fehler übrig. Da braucht es keine Möglichkeiten seitens der Programmiersprache, auch noch formal falschen Code hinschreiben zu können.

Einfaches Beispiel:

code:

ABC=NULL;
ABC->xyz();

Welcher Nutzen erwächst dem Programmierer daraus, diesen offensichtlich fehlerhaften Code hinschreiben zu können? Welche "Weiterentwicklung" soll aus diesem Fehler entstehen?

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > C-Array? später ändern?

[ - Suche - Neue Beiträge - Registrieren - Login - ]