Alternative zu C,C++

volkard schrieb:

u-ser_l schrieb:

Basher schrieb:

C ist *der* makroassembler schlechthin, sogar portabel.

na, nun übertreib' mal nicht

C ist doch portabel.
Naja, sagen wir mal ziemlich portabel, solange man damit nicht direkt an die Hardware geht. Aber andererseits: C zu nehmen, wenn damit nicht direkt an die Hardware gehen will, wäre furchtbar ungeschickt. Damit gibt es keine Anwendungsfälle, wo die "Portabilität" von C einen Vorteil bieten würde.

Außer in Fällen wo Portabilität Verfügbarkeit eines Compilers ist

tntnet

gary1195 schrieb:

Eigentlich würde ich gerne Programm einfach mal schreiben anstatt mich dauernd nur mit dem compiler rumschlagen zu müssen.

Die Alternative ist ein Buch. Nämlich ein gutes C++-Buch, womit Du C++ lernen kannst. Ich programmiere täglich mit C++ und schlage mich nicht mit dem Compiler rum.

Basher_ist_nicht_BashAr

volkard schrieb:

C ist doch portabel.
Naja, sagen wir mal ziemlich portabel, solange man damit nicht direkt an die Hardware geht.

nehmen wir an, du hast 'ne hardwarekomponente, die einen treiber braucht, der zuerst mal auf host-controller X laufen soll. machste den treiber in C, dann kannste, wenn du gut programmiert hast, ihn später ohne probleme nach host-controller Y portieren. programmierst du den treiber aber in assembler und X hat 'nen anderen CPU-core als Y, dann hast du die pappnase auf. oder schaut euch mal linux an, das läuft auf den verschiedensten architekturen. warum? das zauberwort lautet: C

ja, wenn man die nicht-portablen Sprachelemente einfach nicht benutzt, kann man wohl in jeder Sprache 'portabel' programmieren.

Daß man in C portabel programmieren kann, bestreitet niemand.

Neulich mußte ich ein C/C++ source-Paket installieren, dessen configure war satte ~15500 Zeilen lang, und selbst da war Nacharbeit am Code angesagt, weil irgendwelche impliziten includes seit Version 4.xx nicht so included werden, wie es die configure für Version 4.yy erwartet

Ein n-teiliges System bietet O(n^2) Möglichkeiten für gegenseitige Abhängigkeiten. Je größer n ...

'Portabel' + 'hardwarenah' sind zwei einander widerstrebende Ziele und schließen sich daher gegenseitig aus. Kompromisse zugunsten der einen oder der anderen Seite sind selbstmurmelnd möglich.

'hardware'-nah an einer virtuellen Maschine geht natürlich immer, so weit war man aber schon vor Jahrzehnten -> Websuche nach Cintpos.

ich will nicht sagen, daß der Ansatz von hardwarenaher + portabler Programmierung mit C/C++ gescheitert ist, aber es scheint zumindest zunehmend mühsam zu werden, wohl auch wegen der zunehmenden Zahl an Abhängigkeiten von Libraries, die ihrerseits von weiteren Libraries abhängen können usw. -

gary1195 schrieb:

Eigentlich würde ich gerne Programm einfach mal schreiben anstatt mich dauernd nur mit dem compiler rumschlagen zu müssen.

Mach keine Fehler, dann hattu keinen Stress mit dem Compiler. Selbst bei Visual Basic wirst du vermutlich das gleiche Problem haben wie jetzt.
Was meinst du mit 'rumschlagen', das der Compiler sich bei jeder zweiten Zeile wegen nem Syntaxfehler anpisst?
Das ist normal.

Tachyon

PCTT ist ne tolle Programmiersprache. Ich meine mich zu erinnern, dass das für "Please close this thread" steht.

Basher_ist_nicht_BashAr

u-ser_l schrieb:

'Portabel' + 'hardwarenah' sind zwei einander widerstrebende Ziele und schließen sich daher gegenseitig aus.

nee, das stimmt nicht. wenn ich z.b. in C auf irgendwelche register eines chips zugreifen will (über memory mapped I/O):

#define BASE 0x1000
uint8_t *reg1 = (uint8_t*)BASE + 0;
uint8_t *reg2 = (uint8_t*)BASE + 1;
uint8_t *reg3 = (uint8_t*)BASE + 2;

^^dann passt es immer, egal wo. ich muss nur BASE einmal pro host-system anpassen und sämtlicher anderer code, der mit dieser hardware arbeitet (z.b. ein sehr komplexer treiber), muss nicht verändert werden.

Basher schrieb:

u-ser_l schrieb:

'Portabel' + 'hardwarenah' sind zwei einander widerstrebende Ziele und schließen sich daher gegenseitig aus.

nee, das stimmt nicht. wenn ich z.b. in C auf irgendwelche register eines chips zugreifen will (über memory mapped I/O):
#define BASE 0x1000
uint8_t *reg1 = (uint8_t*)BASE + 0;
uint8_t *reg2 = (uint8_t*)BASE + 1;
uint8_t *reg3 = (uint8_t*)BASE + 2;
^^dann passt es immer, egal wo. ich muss nur BASE einmal pro host-system anpassen und sämtlicher anderer code, der mit dieser hardware arbeitet (z.b. ein sehr komplexer treiber), muss nicht verändert werden.

Falsch, auf Systemen ohne MMIO fällst du damit dick auf die Fresse. Portabel wäre es den Zugriff zu abstrahieren.

Basher_ist_nicht_BashAr

C-Hacker schrieb:

Falsch, auf Systemen ohne MMIO fällst du damit dick auf die Fresse. Portabel wäre es den Zugriff zu abstrahieren.

natürlich geht's 'noch portabler', ich wollte u_ser-l nur mal mit einem einfachen beispiel zeigen, wie er sich täuscht.

welche sprache ist eigentlich geeignet für system-programmierung ausser c / c++

halt speicher auslesen und ähnliche sachen sollten auch möglich sein, hardware-zugriffe usw...

knivil

Konkretisiere system-programmierung!

ich habe gesagt, man kann in C portabel programmieren. Das heißt weder, daß jedes C-Programm portabel ist, noch daß jedes C-Programm nicht portabel ist.

Jedenfalls: eine Sprache/ein System ist so portabel, daß es 15000 Zeilen Skriptcode bedarf, um Sourcen an die diversen Zielplattformen anzupassen ...

Mit 15000 Zeilen Code könnte man wohl fast dafür sorgen, daß C64-Basic-Programme anstandslos auf einer PS2 compilieren.

froch mich net schrieb:

welche sprache ist eigentlich geeignet für system-programmierung ausser c / c++

das kann man z.B. daran sehen, in welchen Sprachen Systeme implementiert wurden und/oder werden:

ada
algol
bcpl
forth
objective c und andere C-Varianten und -Erweiterungen
lisp
mesa
pascal
pl/|
smalltalk (slang)

...

was APL angeht - die "formal description" von Systems/360 gab es in APL, zählt das auch ?

bitC
bliss
modula-2
oberon
preScheme
...

pl/m
...

KISS
(vor rund 50 Jahren auf IBM 650, heute wohl nicht mehr ganz so populär)

volkard

Ich nehme an, bei diesen 17 Systemimplemetierungssprechen werden doch die meisten Fehler in C gemacht.

knivil

volkard schrieb:

Ich nehme an, bei diesen 17 Systemimplemetierungssprechen werden doch die meisten Fehler in C gemacht.

Absolut oder relativ gesehen?

volkard

knivil schrieb:

volkard schrieb:

Ich nehme an, bei diesen 17 Systemimplemetierungssprechen werden doch die meisten Fehler in C gemacht.

Absolut oder relativ gesehen?

Absolut natürlich.

volkard schrieb:

Absolut natürlich.

Was ist absolut natürlich? Ach du meinst oder so also warte...