Bascom to C übersetzen

Peter II schrieb:
> bestimmt, kommt aber auf den Bascom code an.
>
> Wenn dort z.b. eine LCD routine verwendet wird, dann kann man es so
> nicht nach C übernehmen weil es das nicht in C gibt.

hier ist der Code(sieh Anhang)

steffen_B schrieb:
> Ein "C-Programmierer"? Die beiden Begriffe in einem Satz machen ungefähr
> soviel Sinn wie ein "intelligenter Vollidiot" oder "hölzerne Steine"!
>
> Abgesehen davon, das man m. E. in "C" nichts anderes als Fehler
> produzieren kann, war das wohl vom Poster nicht gemeint.

Zwar ist heute Freitag, aber Forentrolle sammeln sich auch freitags 
nicht hier, sondern im Heise-Forum.

Hallo,

das liegt wohl eher an den Leuten die den Code schreiben.
Assembler ist wohl kaum übersichtlicher als C.
Das was ich weiter oben an BASCOM gesehen hab sieht Schxxxe aus.

Und ich hab mal von C-Code gehört der sauber und zuverlässig arbeitet 
und wo einige tausend Leute rumarbeiten. Die POSIX bzw. Linux-Kernel 
Mailingliste hat mehrere tausend Einträge.

Abgesehen davon ist Programmieren unabhängig von einer Sprache oder dem 
Compiler. Das ist dann nur noch Codieren.

Aber sonst ist es wie bei den Autos, egal ob einen Stern oder 4 Ringe, 
wer nicht fahren kann, dem hilft keines von beiden.

mfg aus Berlin

Es ist doch schlicht&einfach EGAL, welche Programmiersprache ich 
verwende, wenn ich verstehe, was ich da mache. Das ist ja sonst wie wenn 
man nur mit Bleistiften von Faber auf Papier schreiben könnte. Denn 
nichts anderes ist eine Programmiersprache: ein Hilfmittel, um einen 
Controller dazu zu bringen, das zu tun, was man will. Genauso ist ein 
Bleistift nur ein Hilfsmittel um etwas auf ein Blatt Papier zu schreiben 
oder malen.
Und natürlich: richtige Künstler schwören auf "ihre" Bleistifte. Damit 
können sie zaubern. Aber wenn grad keiner zur Hand ist, dann bekommen 
sie auch mit einem anderen Bleistift was brauchbares hin.

Sahra Nana schrieb:
> kann mir jemand einen Code von Bascom nach C übersetzen?
Es ist mit Verlaub totaler Blödsinn, dieses Programm Zeile für Zeile von 
Basic nach C zu übersetzen (mag sogar sein, dass es geht, weil da ja nur 
die SPI-Schnitte per SW nachgebildet wird).

Besser wäre es, zu verstehen, was da passiert:
alles läuft zum Schluss auf die Software-SPI in der Funktion 
Adns2610_write_byte() raus. Dort spielen sich die Hardwarezugriffe ab.
Und dann kommt noch ein wenig UART dazu und fertig.

>Aber Spaß bei Seite...such Dir mal nen Job und sag Du kannst nur Bascom
>und kein C.

Genau so! Ich habe einen Kompagnon, der von einer Firma eingestellt
wurde und dort nur in Bascom programmiert. Dem Chef war es völlig Brust,
womit die Programme geschrieben werden, -wichtig war, daß sie das tun,
was sie sollen.

MfG Paul

mein Gott schrieb:
> Gibt es für Bascom eigentlich einen Misra-Standard?
Der MISRA Standard wurde wegen Bascom entwickelt...  ;-)

> Gibt es für Bascom eigentlich einen Misra-Standard?
Da stellt sich die Frage: braucht Bascom auch einen eigenen Standard?
C könnte so einen Standard brauchen, weil ich jederziet eine C-Zeile 
hinschreiben kann, die einigen erhebliches Kopfzerbrechen bereiten 
könnte, und die man ohne genaue Kenntnis der Operandenreihenfolge falsch 
interpretieren könnte.
Sind bei Bascom solche doppeldeutigen Zu- und Anweisungen auch möglich?

Lothar Miller schrieb:

> C könnte so einen Standard brauchen, weil ich jederziet eine C-Zeile
> hinschreiben kann, die einigen erhebliches Kopfzerbrechen bereiten
> könnte, und die man ohne genaue Kenntnis der Operandenreihenfolge falsch
> interpretieren könnte.

So eine Zeile würde einigen Dummköpfen tatsächlich Kopfzerbrechen machen 
- aber nicht dem Compiler. Und nur der muss Dich verstehen.

> Sind bei Bascom solche doppeldeutigen Zu- und Anweisungen auch möglich?

Wo gibt es in C "solche doppeldeutigen Zu- und Anweisungen"? Da ist 
alles eindeutig definiert. Eine Programmiersprache wird nicht 
doppeldeutig, nur weil jemand sie liest, der sie nicht verstanden hat.

Gruß,

Frank

Duck und wech schrieb:
> Es ist schon bezeichnend, wenn eine Programmiersprache von sich aus so
> unsicher ist, dass man zusätzliche Standards braucht, um zu vernünftigen
> Ergebnissen zu kommen ;-)

Du hast falsch verstanden: Der MISRA-C-Standard wurde entworfen, um die 
Risiken durch Unzulänglichkeiten der Programmierer zu minimieren. Lies 
den ersten Absatz des Artikels nochmsal.

Nicht die Programmiersprache ist unsicher, sondern der Programmierer.

Wer meint C programmieren sei Fehleranfälliger als andere Sprachen, der 
kann nicht programmieren, denn er weiß nicht was er tut.

C- Programmieren wissen was sie tun. Den C ermöglicht es die Hardware 
annäherend so nach und so efficient anzusprechen wie Assembler.

Alles andere (höhere9 ist anfälliger gegen fehler, weil man meist die 
Libs nicht einsehen kann und sich so blind verlassen muss......

Bernd Hallinger schrieb:
> C- Programmierer wissen was sie tun.
LOL...
Träum weiter.

> Alles andere (höhere9 ist anfälliger gegen fehler, weil man meist die
> Libs nicht einsehen kann und sich so blind verlassen muss......
Hast du mal den Sourcecode der Microsoft-Libs angeschaut?

> Alles andere (höhere9 ist anfälliger gegen fehler, weil man meist die
> Libs nicht einsehen kann und sich so blind verlassen muss......
Das ist doch überall so:
Ich setz mich ins Auto und verlass mich drauf, dass es fährt und bremst. 
Ich verwende eine Lib und verlass mich drauf, dass sie tut, was in der 
Doc steht.

Lothar Miller schrieb:
> Bernd Hallinger schrieb:
>> C- Programmierer wissen was sie tun.
> LOL...
> Träum weiter.
Wenn man nicht weiß was man tut kann man entweder nicht programmieren 
oder probiert etwas aus.

Abgesehen davon, Bascom versteht nichts was in c nützlich ist:

1

int i;              // In Bascom: "Dim i as Interger". Wie kommt auf so eine scheiß Idee???

2

i++;                // i = i + 1 Viel zu umständlich

3

i = a * b + foo(i); // Nicht in einer Zeile möglich

4

i = &a;             // Meines Wissens überhaupt nicht möglich

5

p = foo;            

6

p();

Peter II schrieb:
> int i = 1;
> printf("%d, %d",i++,i++);

Was ist hier nicht eindeutig?
Das müsste "1, 2" ergeben.

Aber anscheinend werden die Argumente rückwärts abgearbeitet/eingelesen. 
Daher "2, 1"

Das sollte aber immer gleich sein.

Wusste ich vorher nicht, aber sowas würde ich auch nicht schreiben.

Der Kommaoperator ist überhaupt eine Quelle unendlicher Freude...
Was macht die Zeile da:

1

int v, j=3;

2

for (int i=0;i++<6,j++,v=j+i;);

Nein, die Antwort darf nicht länger als 10 Sekunden dauern.
Drei schäbige arithmetische Operationen, und du überlegst immer noch?

Und was würde da herauskommen:

1

volatile int v, j=3;

2

for (int i=0;i++<6,j++,v=j+i;);

Samuel K. schrieb:
> müsste
> anscheinend
> sollte
> würde
No further comment...  ;-)

Lothar Miller schrieb:
>> müsste
>> anscheinend
>> sollte
>> würde
> No further comment...  ;-)

ich bin auch nicht immer sicher. Und in meinen Programme verwende ich 
entweder Ausdrücke, bei denen ich sicher bin, dass sie funktionieren 
oder google.

Deine Schleifen laufen übrigens ins unendliche.

Peter II schrieb:
> nein ist es nicht.

Ist es doch.

> int i = 1;
> printf("%d, %d",i++,i++);

Die Abarbeitungs-Reihenfolge ist definiert, nämlich dass sie inerhalb 
von Argumenten unbestimmt ist. Das ist dokumentiert! Und damit ist die 
Sache eindeutig: nicht machen! :-)

Ich hab jetzt nachgeschaut: 
http://www.mi.uni-koeln.de/c/mirror/f7alpha1.informatik.fh-muenchen.de/~schieder/c-c++-workshop-ws98-99/slide0050.html
 Die Schleifen sind immer wahr da der letzte Ausdruck immer wahr ist.

Lothar Miller schrieb:

> Drei schäbige arithmetische Operationen, und du überlegst immer noch?

Da muss ich nicht überlegen, das Verhalten ist absolut bestimmbar, denn 
jeder C-Compiler der Welt (sofern er korrekt implementiert ist) wird das 
eindeutig übersetzen. Ich sehe da absolut nichts doppeldeutiges.

> Und was würde da herauskommen:
>

1

> volatile int v, j=3;

2

> for (int i=0;i++<6,j++,v=j+i;);

3

>

Auch das ist eindeutig.

Du verwechselst Unzulänglichkeiten des Menschen mit der angeblichen 
Unzulänglichkeit der Sprache C.

Nicht immer ist in C sofort erkennbar, was gemeint ist. Aber das ist 
derjenige schuld, der das so schreibt, nicht die Sprache.

Der Michel schrieb:
> Und warum läßt der Compiler solche Formulierung dann überhaupt durch,
> wenn das Verhalten nicht mal standardisiert ist?

Weil man dann auch keine Funktionen in Funktionen angeben könnte.
Es könnte ja so eine Funktion sein:

int i = 0;
printf("%d, %d", foo(i), foo(i));

int foo(int i)
{ return i++; }

Peter II schrieb:

> So ist es besser:
>
> int i = 0;
> printf("%d, %d", foo(i), foo(i));
>
> int foo(int& i)
> { return i++; }

Das ist nicht besser sondern schlechter, denn das versteht kein 
C-Compiler, was Du da tippselst ;-)

Was soll der Operator "&" da in der Sprache C? Du verwechselst das was 
mit C++ ;-)

Und was soll das Draufrumgetrete? Ich schrieb doch eben schon, dass die 
Abarbeitungsfolge von Funktionsargumenten erklärtermaßen unbestimmt ist. 
Damit ist es eindeutig: es ist unbestimmt. Da ist nichts doppeldeutiges.

Bring mal ein besseres Beispiel für Doppeldeutigkeit in C.

Frank M. schrieb:
>> int i = 1;
>> printf("%d, %d",i++,i++);
>
> Die Abarbeitungs-Reihenfolge ist definiert, nämlich dass sie inerhalb
> von Argumenten unbestimmt ist. Das ist dokumentiert! Und damit ist die
> Sache eindeutig: nicht machen! :-)

Genau, und deswegen spuckt bspw. der GCC auch eine entsprechende Warnung
aus, sofern man diese aktiviert hat:

1

warning: operation on ‘i’ may be undefined [-Wsequence-point]

Lothar Miller schrieb:
> Der Kommaoperator ist überhaupt eine Quelle unendlicher Freude...
> Was macht die Zeile da:int v, j=3;
> for (int i=0;i++<6,j++,v=j+i;);
>
> Nein, die Antwort darf nicht länger als 10 Sekunden dauern.

Ich habe zugegebenermaßen etwas länger als 10 Sekunden gebraucht :)

Das lag aber nicht an dem Kommaoperator, sondern daran, dass man erst
einmal daraufkommen muss, dass v=j+i immer ungerade ist und somit trotz
Überlauf nie 0 werden kann. Dazu hätte ich in Basic genauso lange
gebraucht.

Ganz abgesehen davon ist das absichtlich verunstalteter Code. Verunstal-
ten kann kann man Programme in jeder Sprache (einschließlich Basic).

Peter II schrieb:
> schlechtest Beispiel, weil es hier sogar eindeutig ist.
Warum denn? Darum ging es gar nicht. Es ging drum zu beweisen, dass man 
das nicht verbieten darf.

Denn der Compiler weiß nicht ob dasselbe auch in einer Funktion gemacht 
wird.

Paul Baumann schrieb:
> Ich habe schon oft gelesen, daß es Jemandem nicht gelang, einen
> Quelltext
> in C bei sich auf dem Rechner übersetzen zu lassen. Nein, hieß es dann,
> Du mußt die Version 0815 des Compilers benutzen, nicht die 0816...

Kenn ich, als ich vor ein paar Jahren ein bisschen programmieren konnte 
und von VC# verwöhnt war. Lernt man aber mit der Zeit.

Zur Komplexität.
Hier eine Zeile aus meinem derzeitigen Projekt. Hat beim ersten Test 
funktioniert.

1

((MenuFunc)pgm_read_word(&(currentEntry->value[0].func)))();

So was möchte ich nicht in Bascom schreiben wollen, da ich die meisten 
Befehle gerne in eine Zeile schreibe.

Hallo

ohne Test und ohne Garantie, mal auf die schnelle.

Uart ist von Peter Fleury.
Spi ist von Ulrich Radig.

Gruß Rene

steffen_B schrieb:
> Abgesehen davon, das man m. E. in "C" nichts anderes als Fehler
> produzieren kann, war das wohl vom Poster nicht gemeint.

Du meinst mal abgesehen, dass alle professionellen / komererziellen 
Entwicklungen in C stattfinden und Bascom außer bei Anfängern zu Recht 
ziemlich verhasst ist ...

Mir vergeht gerade die Lust mich mit diesen renitenten Anfänger verbal 
zu batteln ...

Lehrmann Michael schrieb:
>
> Du meinst mal abgesehen, dass alle professionellen / komererziellen
> Entwicklungen in C stattfinden und Bascom außer bei Anfängern zu Recht
> ziemlich verhasst ist ...
>
> Mir vergeht gerade die Lust mich mit diesen renitenten Anfänger verbal
> zu batteln ...

warum haste dann ueberhaupt die 'Klappe aufgerissen' ?
(besser dumm gelallt als garnix gesagt)

toll ist auch das Zitat aus Wiki:
'Zielsetzung sind die Vermeidung von Laufzeitfehlern durch unsichere 
C-Konstrukte, von strukturellen Schwächen durch Missverständnisse 
zwischen Programmierern und die Sicherstellung der Gültigkeit von 
Ausdrücken.'

>Damit hast du den TO seinem Ziel wieder ein Stück näher gebracht -
>nämlich sich ein Diplom erschleichen. :-(

Kann sein, wenn er den Code verwendet ist er selber schuld.

Eigentlich wollte ich nur die Programmiersprachendiskusion unterbrechen.
Ständig ohne Grund, ist echt schlimm.

Gruß Rene

Jürgen Hinze schrieb:
> Lothar Miller schrieb:
>> Ich verwende eine Lib und verlass mich drauf, dass sie tut, was in der
>> Doc steht.
> Wie weit man mit diesem Vertrauen kommt musste ich gerade feststellen:
Natürlich greift man da ab&an in den Topf (auch mir ist das schon ein 
paar mal passiert), aber wenn du dem Compiler nicht traust, dann kannst 
du gleich alles in Assembler schreiben und hinterher den Maschinencode 
kontrollieren...
Man muss ganz einfach darauf vertrauen, dass die Leute, die die Libs 
und den Compiler geschrieben haben, das nach bestem Wissen und gewissen 
und ausreichend gut getan haben.