Alternative zu C,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...

knivil

Wobei dann die Aussage "werden doch die meisten Fehler in C gemacht" eher wertlos ist. Z.B. werden die meisten Zwischenfaelle mit Hunden durch Schaeferhunde verursacht. Macht das den Schaeferhund zu einem sehr aggressiven Hund? Nein, er ist nur der haeufigste Haushund.

PS: jeha mein 11elfter Post!

abc.w

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

Mal abgesehen von der Portabilität, müsste da noch nicht ein volatile rein, damit der nachfolgende Code (der auf die Register zugreifen möchte) bei allen Compiler Optimierungsstufen arbeitet?

abc.w schrieb:

#define BASE 0x1000
uint8_t *reg1 = (uint8_t*)BASE + 0;
uint8_t *reg2 = (uint8_t*)BASE + 1;
uint8_t *reg3 = (uint8_t*)BASE + 2;
Mal abgesehen von der Portabilität, müsste da noch nicht ein volatile rein, damit der nachfolgende Code (der auf die Register zugreifen möchte) bei allen Compiler Optimierungsstufen arbeitet?

Volatile ist dafür nicht geeignet, man benötigt dafür einerseits "compiler barriers" (die verhindert, dass der Compiler umordnet) und andererseits "memory barriers" (welche Schreib-/Lese-Zugriffe, oder beides, sortieren, so dass alle vor der Barrier vor denen hinter der Barrier abgearbeitet werden).