code:

---

#include <proto/exec.h>
    #include <proto/dos.h>
    #include <proto/intuition.h>
    #include <proto/graphics.h>
    #include <proto/gadtools.h>
    #include <string.h>


    int main (void)

    {
    struct Screen *scr;
    struct Window *win;
    struct IntuiMessage *mess;
    struct Gadget *glist = NULL;
    struct Gadget *gad;
    struct NewGadget ng = {0};
    BOOL terminated;
UWORD thetopborder;
UWORD gid;
ULONG myimsgCode;
WORD ret;
UBYTE searchstring[64];
ULONG selgad;

    if (scr = LockPubScreen (NULL))
        {
        gad = CreateContext (&glist);

        ng.ng_VisualInfo  = GetVisualInfo (scr,TAG_END);
        ng.ng_TextAttr    = scr->Font;
thetopborder=scr->WBorTop+scr->Font->ta_YSize+1;

        ng.ng_LeftEdge    = 80;
        ng.ng_TopEdge     = 10+thetopborder;
        ng.ng_Width       =    160;
        ng.ng_Height      = 18;
        ng.ng_GadgetText  = "Searchstring";
ng.ng_GadgetID = 0;
        gad = CreateGadget (STRING_KIND,gad,&ng,TAG_END);

        ng.ng_LeftEdge    = 30;
        ng.ng_TopEdge     = 40+thetopborder;
        ng.ng_Width       =  80;
        ng.ng_Height      = 16;
        ng.ng_GadgetText  = "Okay";
ng.ng_GadgetID = 1;
        gad = CreateGadget (BUTTON_KIND,gad,&ng,TAG_END);


        ng.ng_LeftEdge   = 150;
        ng.ng_TopEdge     = 40+thetopborder;
        ng.ng_Width       =  80;
        ng.ng_Height      = 16;
        ng.ng_GadgetText  = "Abbruch";
ng.ng_GadgetID = 2;
        gad = CreateGadget (BUTTON_KIND,gad,&ng,TAG_END);

        if (gad)
            {

            if (win = OpenWindowTags (NULL,
                    WA_Left,100,
                    WA_Top,100,
                    WA_InnerWidth,250,
                    WA_InnerHeight,60,
                    WA_Title,"Search string",
                    WA_Flags,WFLG_CLOSEGADGET | WFLG_DRAGBAR | WFLG_DEPTHGADGET | WFLG_ACTIVATE,
                    WA_IDCMP,IDCMP_CLOSEWINDOW | IDCMP_REFRESHWINDOW | STRINGIDCMP | BUTTONIDCMP,
                    WA_Gadgets,glist,
                    TAG_END))
                {
                GT_RefreshWindow (win,NULL);

                SetFont (win->RPort,scr->RastPort.Font);

                terminated = TRUE;
                do    {
                    if (Wait ((1L << win->UserPort->mp_SigBit) | SIGBREAKF_CTRL_C) & SIGBREAKF_CTRL_C)
                        terminated = FALSE;
                    while (mess = GT_GetIMsg (win->UserPort))
               selgad = (struct Gadget *) mess->IAddress;
              
               myimsgCode = mess->Code;

                        {
                        switch (mess->Class)
                            {
                case IDCMP_GADGETDOWN | IDCMP_MOUSEMOVE | IDCMP_GADGETUP:
                   switch(selgad)
                   {
                   case 0:
                    searchstring=selgad->GadgetSpecialnfo->StringInfoBuffer;
                   case 1:
                    ret=1;
                   case 2:
                    ret=0;

                   }


                        case IDCMP_CLOSEWINDOW:
                            terminated = FALSE;
                            break;
                        case IDCMP_REFRESHWINDOW:
                            GT_BeginRefresh (win);
                            GT_EndRefresh (win,TRUE);
                            break;
                            }
                        GT_ReplyIMsg (mess);
                        }
                    }
                while (terminated);

                CloseWindow (win);
                }
            else
                Printf ("cannot open windown");
            }
        else
            Printf ("cannot create gadgetsn");

        FreeGadgets (glist);

        if (ng.ng_VisualInfo)
            FreeVisualInfo (ng.ng_VisualInfo);

        UnlockPubScreen (NULL,scr);
        }
    else
        Printf ("cannot lock public screenn");

    return (0);
    }

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Aber C ist so unnötig kompliziert, ich bekomme ständig compilerfehler:

---

Zitat:

---

ULONG selgad;

---

Zitat:

---

selgad = (struct Gadget *) mess->IAddress;

---

Zitat:

---

switch(selgad)
{
case 0:
...
case 1:
...
case 2:

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

C code:

---

#include <proto/exec.h>
	#include <proto/dos.h>
	#include <proto/intuition.h>
	#include <proto/graphics.h>
	#include <proto/gadtools.h>
	#include <string.h>


	int main (void)

	{
	struct Screen *scr;
	struct Window *win;
	struct IntuiMessage *mess;
	struct Gadget *glist = NULL;
	struct Gadget *gad;
	struct NewGadget ng = {0};
	BOOL running;
	UWORD thetopborder;
	ULONG myimsgCode;
	WORD ret;
	UBYTE searchstring[64] = "";
	UBYTE *stringptr;
	ULONG selgad;

	if (scr = LockPubScreen (NULL))
		{
		gad = CreateContext (&glist);

		ng.ng_VisualInfo  = GetVisualInfo (scr,TAG_END);
		ng.ng_TextAttr    = scr->Font;
		thetopborder=scr->WBorTop+scr->Font->ta_YSize+1;

		ng.ng_LeftEdge    = 80;
		ng.ng_TopEdge     = 10+thetopborder;
		ng.ng_Width       =    160;
		ng.ng_Height      = 18;
		ng.ng_GadgetText  = "Searchstring";
		ng.ng_GadgetID = 0;
		gad = CreateGadget (STRING_KIND,gad,&ng,TAG_END);

		ng.ng_LeftEdge    = 30;
		ng.ng_TopEdge     = 40+thetopborder;
		ng.ng_Width       =  80;
		ng.ng_Height      = 16;
		ng.ng_GadgetText  = "Okay";
		ng.ng_GadgetID = 1;
		gad = CreateGadget (BUTTON_KIND,gad,&ng,TAG_END);


		ng.ng_LeftEdge   = 150;
		ng.ng_TopEdge     = 40+thetopborder;
		ng.ng_Width       =  80;
		ng.ng_Height      = 16;
		ng.ng_GadgetText  = "Abbruch";
		ng.ng_GadgetID = 2;
		gad = CreateGadget (BUTTON_KIND,gad,&ng,TAG_END);

		if (gad)
			{

			if (win = OpenWindowTags (NULL,
					WA_Left,100,
					WA_Top,100,
					WA_InnerWidth,250,
					WA_InnerHeight,60,
					WA_Title,"Search string",
					WA_Flags,WFLG_CLOSEGADGET | WFLG_DRAGBAR | WFLG_DEPTHGADGET | WFLG_ACTIVATE,
					WA_IDCMP,IDCMP_CLOSEWINDOW | IDCMP_REFRESHWINDOW | STRINGIDCMP | BUTTONIDCMP,
					WA_Gadgets,glist,
					TAG_END))
				{
				GT_RefreshWindow (win,NULL);

				SetFont (win->RPort,scr->RastPort.Font);

				running = TRUE;
				do	{
					if (Wait ((1L << win->UserPort->mp_SigBit) | SIGBREAKF_CTRL_C) & SIGBREAKF_CTRL_C)
						running = FALSE;
					while (mess = GT_GetIMsg (win->UserPort))
						{

						myimsgCode = mess->Code;

						switch (mess->Class)
							{
						case IDCMP_GADGETDOWN:
					/*	case IDCMP_MOUSEMOVE: */
						case IDCMP_GADGETUP:
							gad = (struct Gadget *) mess->IAddress;
							selgad = gad->GadgetID;
							switch(selgad)
								{
							case 0:
								GT_GetGadgetAttrs (gad,win,NULL,GTST_String,&stringptr,TAG_END);
								strncpy (searchstring,stringptr,63);
								running = FALSE;
								break;
							case 1:
								ret=1;
								running = FALSE;
								break;
							case 2:
								ret=0;
								running = FALSE;
								break;
								}
							break;
						case IDCMP_CLOSEWINDOW:
							running = FALSE;
							break;
						case IDCMP_REFRESHWINDOW:
							GT_BeginRefresh (win);
							GT_EndRefresh (win,TRUE);
							break;
							}
						GT_ReplyIMsg (mess);
						}
					}
				while (running);

				CloseWindow (win);
				}
			else
				Printf ("cannot open windown");
			}
		else
			Printf ("cannot create gadgetsn");

		FreeGadgets (glist);

		if (ng.ng_VisualInfo)
			FreeVisualInfo (ng.ng_VisualInfo);

		UnlockPubScreen (NULL,scr);
		}
	else
		Printf ("cannot lock public screenn");

	Printf ("eingabe = %sn",searchstring);
	Printf ("ret = %ldn",ret);

	return (0);
	}

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Warum kann eine ULONG denn nicht einfach einen wert enthalten,
welcher auf einen beliebigen Speicherbereich zeigt?

---

Zitat:

---

Wenn ich jetzt z.B. 20 Stringgadgets hätte und will jedes
aktivieren können brauch ich doch zu jedem ein Pointer,

---

Zitat:

---

Gab es nicht auch Peek's equivalente in C?

---

Zitat:

---

Ich denke hauptsächlich in Basic...

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>struct Gadget *selgad = imsg->IAddress;
>D.h. selgad darf nicht vom typ ULONG sein, da es ein Pointer auf
>das Gadget ist.

Warum kann eine ULONG denn nicht einfach einen wert enthalten,
welcher auf einen beliebigen Speicherbereich zeigt?

Wenn ich jetzt z.B. 20 Stringgadgets hätte und will jedes
aktivieren können brauch ich doch zu jedem ein Pointer,
also 20 struckturen.

---

Zitat:

---

Gab es nicht auch Peek's equivalente in C?

---

Zitat:

---

>Erst denken, dann programmieren ;-)

Ich denke hauptsächlich in Basic...

---

Und warum programmierst du dann in C?
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von thomas:
Weil ein ULONG eine Zahl ist. Eine Zahl kann nicht auf irgendwas zeigen. Dafür gibt es Zeiger.

---

Ach herrje! Er hatte ja überhaupt keinen Zeiger angelegt!
Das hab' ich völlig übersehen ...

Zitat:

---

Der Unterschied bei C ist, daß der Compiler dir genau auf die Finger schaut und meckert, sobald du etwas ungezogenes tust, während du in Basic alle möglichen Schweinereien programmieren kannst.

---

*grins* eigentlich hätte ich diese Aussage über C erwartet, nicht über Basic ...
Frag' dazu mal z.B. Oberon-Programmierer...
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>Jedes Lesen aus einem Speicherbereich ist ein Peek.
>Dafür braucht C keine extra Funktion. Du mußt halt nur einen Zeiger
>benutzen.

Und wie Zeige ich z.B. auf den 5. Buchstabe in einem BYTE[] ?

---

Zitat:

---

Wo ich übrigens auch diverse Code Beispiele habe an denen ich
alles lernen kann.

---

Als gäb's für C keine Beispiele ... schon mal im Internet geschaut?

Außer, du meinst speziell die Amiga-GUI-Programmierung. Da wird's im Internet an sich dünne sein, aber bis du das Aminet abgegrast hast wird sicher auch Weihnachten ...
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Bei Basic bekomme ich aber eine einfach verständliche Information
darüber was ich falsch gemacht habe.

---

[ - Antworten - Zitieren - Direktlink - ]

Ich kann MaikG schon verstehn. Es ist wirklich nicht so einfach wenn man in Basic "denkt" und dann auf C wechseln möchte. Ich denke auch das der Compiler genau sagt wo es "bedenken" hat. Allerdings ist es für einen Anfänger ganz bestimmt nicht einfach dies auch zu verstehn.

Es gibt einen ganz einfachen Grund von Basic (bzw. MaxonBasic) weg zu kommen und das ist vor allem die unglaublich geringe Geschwindigkeit von MBasic bzw. von Basic. Es ist schon unglaublich wie schnell C im vergleich zu Basic ist. Das sind wirklich leider Welten.

Ich hänge da auch irgendwie zwischendrin. Zum einen würde ich gerne zu C "konvertieren", allerdings verdreh ich mir da leider auch komplett die Finger. Das Programmieren soll schon Spaß machen und da ich das wirklich nur ab und zu mach (z.b. jetzt seit Wochen eigentlich nichts mehr, da ich keine Zeit habe) und es eigentlich "nur" Funprojekte sind, reicht da auch Basic. Aber, naja, ich würde mich schon über mehr Speed freuen, bzw. einer "richtigen" Programmiersprache, das ist schon klar.

Und, ich will jetzt kein Glaubenskrieg a la Programmiersprachen lostreten: Ich steh bei C genauso vor dem Berg(bzw. schon etwas höher... ) wie bei AmiBlitz. Sorry, ist leider so.

PS: C-Bücher unter das Kopfkissen legen bringt leider auch nichts, es drückt sich einfach nicht durch...
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

>Und warum programmierst du dann in C?


Tja, wenn du ein bestehendes C-Programm "reparieren" willst
bleibt einem wohl nicht übrig.
Allerdings könnte es auch bald heissen "AOS4 gibts jetzt auch für
den Classic und entspricht meinen anforderungen an Kompatiblität,
trotzdem will ich ein Programm von mir auf PPC-Speed bringen"


>1.) BUCHSTABEN liegen nicht in einem BYTE[], sondern in einem char[]


Also ist in Byte der ASCII-Code gespeichert?
Gut und beim char könnte ich aber auch den ASCII-Code wollten...


>Wenn du nicht gerade Reaction oder MUI benutzt solltest du in den
>RKMs bzw. auf den AmigaOS DeveloperCDs reichlich Beispiele finden.

Hab nur den NDK3.9


>Es gibt einen ganz einfachen Grund von Basic (bzw. MaxonBasic) weg
>zu kommen und das ist vor allem die unglaublich geringe
>Geschwindigkeit von MBasic bzw. von Basic.

Das sagst du, ich bin an keine MB grenzen gestossen.
Ich erinnere nur mal an die DTMF erkennung C genauso lahm
wie MBasic.


>Du solltest Dich auch mit dem Konzept von Zeigern und Strukturen (Records) beschäftigen. Wenn Du das Konzept verstanden hast, dann wirst Du PEEKs und POKEs nicht mehr mögen. Beides sind nämlich nur Krücken, die Basic benötigt, weil es keine Zeiger und Strukturen kennt.

Ich hab mir das gestern auch nochmal durchgelesen(C-Kurs) aber das
dauert sehr lange bis ich sowas praktisch anwenden kann ohne
ständig irgendwo nachzuschlagen.


BTW: Hat hier schonmal einer mit BGUI gearbeitet?

[ - Antworten - Zitieren - Direktlink - ]

@MaikG:
Okay, wir halten fest: Die Meldungen deines C-Compilers findest du vor allem deshalb unverständlich, weil sie dir - im Gegensatz zu den Basic-Meldungen - unbekannt sind.

Vorschlag zur Lösung:
Wenn du das nächste mal ein Problem hast, dann poste nicht nur den fehlerhaften Quellcode, sondern auch die Meldungen deines Compilers. Dann kann dir die jemand erklären, dann lernst du damit umzugehen.

Andererseits, wenn es nicht gerade ein komplett schräger Compiler ist, dann findet man zu den meisten Meldungen im Internet haufenweise Abhandlungen a la "AAAAAAH!!! Mein Compiler spuckt irgendwelche Meldungen aus mit denen ich nichts anfange! Hilfe!"
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Also ist in Byte der ASCII-Code gespeichert?
Gut und beim char könnte ich aber auch den ASCII-Code wollten...

---

Zitat:

---

Hab nur den NDK3.9

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von akl:
Hin- und Her-Konvertieren zwischen ULONG, APTR und bestimmten Zeigern ist also kein Problem - wenn Du das "casten" jedoch vergisst, beschwert sich der Compiler. Zu Recht.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Aber C ist so unnötig kompliziert, ich bekomme ständig compilerfehler:

---

So, ich will auch mal was dazu sagen.

Zuerst:
Alle die, die hier große Töne spucken, haben wahrscheinlich das Programmieren in C von ihren Müttern gelernt, während sie an der Brust lagen ... oder ????

Also Leute, geht bitte ein wenig freundlicher mit denen um, die sich die Mühe machen und C lernen wollen. Sowas wie "... erst nachdenken und dann hinschreiben ... " (nach dem Motto "Ich weiß wie man's macht, aber Du Trottel scheinbar nicht.") ist nicht gerade hilfreich.

Ich selbst habe C gelernt, als viele Dinge, die heute normal sind, noch garnicht normal waren. Ich denke da z.B. an K&R C, dem Vorläufer des heutigen ANSI-C. Und ich habe mich sehr geplagt in einer Zeit, als es noch kein Internet gab, wo man schnell mal im Forum um Rat fragen konnte ...

z.B.
unsigned long, ULONG, uint32
sind Bezeichner für exact den gleichen Datentyp, nämlich eine 32 Bit lange Zahl.

Wenn ich z.B. schreibe:
ULONG einezahl;

dann kann(!) einezahl wirklich eine Zahl sein.
Es könnte (auf dem AMIGA) aber auch eine Speicher-Adresse sein (auch Pointer genannt). Denn Speicheradressen sind 32 Bit Zahlen.
Es könnte aber auch (um die Verwirrung noch ein wenig größer zu machen) ein Bitfeld mit 32 bits sein. Solche Bitfelder enthalten z.B. die sogenannten Flags, etwa in der struct Gadget das Feld Flags (... ja ich weiß dort ist das ausgerechnet ein UWORD, das Prinzip ist aber das gleiche ...). Jedes Bit dieser Zahl bedeutet eine bestimmte Eigenschaft. Ist ein Bit gesetzt, dann ist damit eine bestimmte Eigenschaft festgelegt.

z.B. beim Gadget:
Ist das erste Bit in Flags gesetzt, so wird beim Draufklicken eine Box um das Gadget gezeichnet.

Woher weiß ich das ?
Das steht in den sogenannten includes am Kopf des Quelltextes, hier in intuition/intuition.h. Ich suche darin "struct Gadget" und etwas darunter steht:

/* --- Gadget.Flags values --- */
/* combinations in these bits describe the highlight technique to be used */
...

#define GFLG_GADGHBOX 0x0001 /* Draw a box around the image */
...

Auch da muß ein Anfänger erst mal durchsteigen. Und es ist wirklich nicht leicht in den includes Informationen zu finden, wenn man garnicht weiß, daß sie dort stehen, bzw. wenn man nicht weiß, wo man danach suchen soll. Mir war und ist da immer das MAXON HotHelp eine echte Hilfe.

Als ich mit meiner Arbeit an dem Quellcode von Bars&Pipes Professional begonnen habe, sind mir oft Teile im Quellcode begegnet, die (ca. 1988) in einem ganz alten Programmierstil geschrieben wurden.

z.B.
long IntuitionBase;
long GfxBase;
...

Ist das falsch ? Ja und Nein. Nach neueren Programmierrichtlinien ist es falsch ... aber es funktioniert bestens, warum sollte es dann falsch sein ? Wichtig ist nur, daß ich weiß, daß hier in dem
long IntuitionBase
die Basis-Adresse der geöffneten intuition.library steht, und diese entsprechend behandle.

Überschaubarer und leichter zu warten (besonders, wenn andere meinen Quellcode lesen wollen) ist der Code natürlich, wenn ich:

struct IntuitionBase * IntuitionBase;

schreibe.
NB: für die Freunde, die von Basic kommen: das Semikolon am Ende eines Ausdrucks ist für den C-Compiler sehr wichtig, damit er weiß, wo ich als Programmierer das Ende eines Ausdrucks haben will. Ich könnte so sogar mehrere Ausdrücke in eine Zeile schreiben, wo ich in Basic zwingend mehrere Zeilen dazu brauche.

z.B.
ULONG a, b, c;

b = 345; c = (28 / 7); a = b + c;

So, nochmal zu den Gadgets:

Ein Gadget wird als die Adresse einer(Zeiger - Pointer - auf eine) Gadget-Struktur definiert. In dieser Struktur ist alles definiert, was für das Gadget wichtig ist.
In einigen Fällen ist es nicht nötig, diesen Zeiger extra zu speichern. Manchmal braucht man ihn aber, dann legt man einfach eine Variable dafür an (Deklaration). In Basic geschieht das "im Vollzug" - erst wenn ich diese Variable im Quellcode brauche. In C stehen die Deklarationen immer am Beginn einer Funktion. Das ist zwar etwas mehr Arbeit als in Basic, am Ende ist es aber übersichtlicher.

Für den Anfänger ist es am einfachsten, jedes Gadget einzel zu deklarieren. C läßt zu, daß Variablen vom gleiche (Daten-)Typ hintereinander mit Komma getrennt deklariert werden können.

z.B:
ULONG a,b,c,d;
oder
struct Gadget *yesgad, *nogad, *prefsgad;

Nun könnte man die Zeiger für die Gadgets entsprechend dem Quelltext speichern:

...
ng.ng_GadgetID = 0;
yesgad = gad = CreateGadget (BUTTON_KIND,gad,&ng,TAG_END);
...
ng.ng_GadgetID = 1;
nogad = gad = CreateGadget (BUTTON_KIND,gad,&ng,TAG_END);
...
ng.ng_GadgetID = 2;
prefsgad = gad = CreateGadget (BUTTON_KIND,gad,&ng,TAG_END);
...

Später kann man nun über den Gadget-Zeiger die einzelnen Felder erreichen.

UWORD id; (am Anfang der Funktion)
...

id = yesgad->GadgetID;

Die GadgetID eines Gadget kann ich aber auch erfahren, wenn der Anwender auf das Gadget klickt. Intuition liest für mich diese nämlich aus der betreffenden Gadget-Struktur aus, und speichert sie für mich in einem bestimmten Feld der IntuiMessage-Struktur ab (((struct Gadget *)(message->IAddress))->GadgetID), die ich dann auswerten kann mit einer

switch()
{
case
...
}

Anweisung.

Nochmal zum obigen Cast (Damit wird die Umwandlung in einen bestimmten Datentyp bezeichnet.).

message->IAdress enthält die Adresse des Gadgets wird also in einen Zeiger vom Typ struct Gadget umgewandelt.
NB.: Das kleine Sternchen nach struct Gadget bezeichnet die Umwandlung als Zeiger (Speicheradresse an der hier die struct Gadget beginnt).
Dann der weitere Zeiger auf die GadgetID (Speicheradresse an der die GadgetID abgelegt ist).

Man könnte das Ganze auch zerlegen:

struct Gadget *gad;
UWORD id;

...

gad = (struct Gadget *)(message->IAdress);
id = gad->GadgetID;

Ich weiß, das war jetzt schon fast ein Mikro-C-Kurs. Aber nur mit ausführlichen sachlichen Erklärungen kann man weiterhelfen. Und ich würde es sehr begrüßen, wenn dies so gehalten würde. Ansonsten werde ich mich hier nicht wieder zu Wort melden.

Und: Es gibt keine blöden Fragen, sondern nur blöde Antworten.

hansfaust
alias Alfred Faust
http://www.alfred-j-faust.de

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von hansfaust:
NB: für die Freunde, die von Basic kommen: das Semikolon am Ende eines Ausdrucks ist für den C-Compiler sehr wichtig, damit er weiß, wo ich als Programmierer das Ende eines Ausdrucks haben will. Ich könnte so sogar mehrere Ausdrücke in eine Zeile schreiben, wo ich in Basic zwingend mehrere Zeilen dazu brauche.

z.B.
ULONG a, b, c;

b = 345; c = (28 / 7); a = b + c;

---

Zitat:

---

In C stehen die Deklarationen immer am Beginn einer Funktion. Das ist zwar etwas mehr Arbeit als in Basic, am Ende ist es aber übersichtlicher.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Du kannst in C eine Variable jederzeit deklarieren.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:

>Es gibt einen ganz einfachen Grund von Basic (bzw. MaxonBasic) weg
>zu kommen und das ist vor allem die unglaublich geringe
>Geschwindigkeit von MBasic bzw. von Basic.

Das sagst du, ich bin an keine MB grenzen gestossen.
Ich erinnere nur mal an die DTMF erkennung C genauso lahm
wie MBasic.

---

Dann frag ich mich, wieso sonst keiner mehr in MBasic programmiert wenn es keine Grenzen hat?

Ich hab mal für ein Projekt eine Routine von MBasic nach ASM konvertiert und dann auch gleich das ganze möglichst an die Möglichkeiten von ASM angepasst. Mit ASM sind halt einfache Bitmanipulationen einfacherer als in Basic(Ja, geht wohl auch mit C, aber damals hab ich es halt in ASM gemacht). Und, was soll ich tippen, ASM war wesentlich schneller. Und das, obwohl ich kaum ASM kann bzw. eigentlich nichts an die "neueren" 68k-Prozessoren angepasst war.

Geschwindigkeitstechnisch stoße ich immer wieder an die Grenzen von MB. Aber es kommt halt auch darauf an was man programmieren möchte.

Selbst ACE ist im Integerbereich schneller(!) als MBasic. Außerdem: MBasic scheint wohl nur reinen 68000er-Code zu generieren.

Und: Es gehen auch keine Befehle die FPU-Register belegt haben möchten. Ich tippe hier z.b. von 3D-Libs. Das ist eine der vielen Grenzen von MB.
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 19.08.2007 um 11:48 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von NoImag:

Zitat:

---

Original von hansfaust:
NB: für die Freunde, die von Basic kommen: das Semikolon am Ende eines Ausdrucks ist für den C-Compiler sehr wichtig, damit er weiß, wo ich als Programmierer das Ende eines Ausdrucks haben will. Ich könnte so sogar mehrere Ausdrücke in eine Zeile schreiben, wo ich in Basic zwingend mehrere Zeilen dazu brauche.

z.B.
ULONG a, b, c;

b = 345; c = (28 / 7); a = b + c;

---

Nur zur Info:
In Basic gibt es den Doppelpunkt:

b& = 345 : c& = (28 / 7) : a& = b& + c&

---

code:

---

DEFLNG a,b,c

b=345 : c=(28/7) : a=b+c

---

So würde das aussehn wenn man es wirklich fast(ULONG gibt es eigentlich nicht bei Basic, leider ist alles Vorzeichenbehaftet) 1 zu 1 nach Basic übersetzen würde.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Aber C ist so unnötig kompliziert, ich bekomme ständig compilerfehler:

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

>Dann frag ich mich, wieso sonst keiner mehr in MBasic programmiert wenn es keine Grenzen hat?

Weil C Portabler ist, oder man da schnellere und bessere hilfe findet.
MUI+Reaction Includes fehlen z.B. auch.

>Ich hab mal für ein Projekt eine Routine von MBasic nach ASM konvertiert und dann auch gleich das ganze möglichst an die Möglichkeiten von ASM angepasst. Mit ASM sind halt einfache Bitmanipulationen einfacherer als in Basic(Ja, geht wohl auch mit C, aber damals hab ich es halt in ASM gemacht). Und, was soll ich tippen, ASM war wesentlich schneller. Und das, obwohl ich kaum ASM kann bzw. eigentlich nichts an die "neueren" 68k-Prozessoren angepasst war.

ASM ist auch schneller als C, das war nicht die frage.
Fast jeder Maxonbasic befehl hat eine unmenge an sicherheitabfragen,
weil der User könnte ja was falsches übergeben oder es könnte
was unerwartet auftreten.
Unter ASM kannst du ganz genau das machen was du willst,
normalerweise weiss man ja welche eingaben kommen können und
daher legt man die überprüfungen selbst fest.


>Außerdem: MBasic scheint wohl nur reinen 68000er-Code zu generieren.

Jain, einige befehle z.b. ungrade adressionen erfordern den 020...
Das DTMF teil hab ich auf C sogar auf 68060 optimiert, war trotzdem
nicht schneller als MB.

>Und: Es gehen auch keine Befehle die FPU-Register belegt haben
>möchten. Ich tippe hier z.b. von 3D-Libs. Das ist eine der vielen
>Grenzen von MB.

Von 3D hab ich keinen schimmer, ich meinte auch die grenzen der
Geschwindigkeit.

[ - Antworten - Zitieren - Direktlink - ]