expertenaustausch > comp.lang.* > comp.lang.c

Thomas Koenig (24.01.2019, 23:06)
.... und warum?

Ich kann ja mal anfangen:

Für Skriptiges ist es bei mir typischerwise Perl. Schnell mal
was geschrieben, nützliche Features wie assoziative Arrays und
reguläre Ausdrücke.

Wissenschaftlich / technisch: Fortran. Geniale Unterstützung
von Arrays, vor mehrdimensionalen (in C ist das eine Krankheit),
Plus natürlich eine standardisierte Schnittstelle zu C :-)

Die Vor- und Nachteile von C muss ich hier ja hoffentlich
niemandem erzählen :-)
Bonita Montero (24.01.2019, 23:50)
C++ - Weil man in C so unproduktiv ist!
Thomas Koenig (25.01.2019, 00:09)
Bonita Montero <Bonita.Montero> schrieb:
> C++ - Weil man in C so unproduktiv ist!


Hm, mit welchem Subset denn?
Helmut Schellong (25.01.2019, 01:54)
On 01/24/2019 22:06, Thomas Koenig wrote:
> ... und warum?


Ich begann in den 1970ern mit dem Taschenrechner TI59, den
ich noch habe - mit Drucker und Magnetkarten.

Auf der Hochschule PEARL.
Da hörte ich von C und kaufte deshalb das K&R1.

Weil unter Unix weit überwiegend C/C++ (kostenlos)
vorhanden ist: Eben C und geringfügig C++.

Einmal hatte ich ein Pascal-Programm in C übersetzt.

Als weitere Compiler-Sprache würde mich Ada interessieren.

Insgesamt beherrsche ich etwa 15 Sprachen stark unterschiedlich gut.
Auch mehrere Assembler. Ich probierte z.B. auch awk.
JavaScript gehört auch dazu. Ebenso die C-Shell (csh,tcsh).

Als Skript-Interpreter benutze ich die ab 1995 selbst
entwickelte Shell 'bish', weil mir alle anderen Shells
auf allen Ebenen - auch konzeptionell - _viel_ zu wenig bieten.
Inspirieren dazu ließ ich mich 1994 von der Korn-Shell (ksh).
Оlе Ѕtrеісhеr (25.01.2019, 09:26)
Thomas Koenig <tkoenig> writes:
> Wissenschaftlich / technisch: Fortran. Geniale Unterstützung
> von Arrays, vor mehrdimensionalen (in C ist das eine Krankheit),
> Plus natürlich eine standardisierte Schnittstelle zu C :-)


Python. Hat gegenüber Perl den Vorteil, dass es auch von der Community
genutzt wird und man daher nicht allein dasteht. Dadurch gibt es auch
eine Fülle von recht gut abgestimmten wissenschaftlichen Bibliotheken:
numpy, scipy, pandas, skimage, sklearn, ...

Julia macht auch einen guten Eindruck, allein fehlen da (noch) der
Support durch Bibliotheken.

Schöne Grüße

Ole
Bonita Montero (25.01.2019, 14:47)
>> C++ - Weil man in C so unproduktiv ist!

> Hm, mit welchem Subset denn?


Ist gar nicht mehr nötig, denn die Unterschiede zwischen den Compilern
sind kaum noch maßgeblich.
Claus Reibenstein (25.01.2019, 18:34)
Thomas Koenig schrieb am 24.01.2019 um 22:06:

> .... und warum?


C, weil ich sie beherrsche. C# und Java, weil sie mich interessieren.
PHP und SQL, wenn es um dynamische Webseiten geht.

> Wissenschaftlich / technisch: Fortran. Geniale Unterstützung


Fortran habe ich schon lange nicht mehr angefasst. Fortran V aka Fortran
77 war die letzte Version, mit der ich programmiert habe. Angefangen
hatte ich seinerzeit mit Fortran IV aka Fortran 66.

> von Arrays, vor mehrdimensionalen (in C ist das eine Krankheit),


Wieso "Krankheit"?

> Plus natürlich eine standardisierte Schnittstelle zu C :-)


Jetzt wird's interessant. Welche Version ist das?

> Die Vor- und Nachteile von C muss ich hier ja hoffentlich
> niemandem erzählen :-)


Nicht wirklich :-)

Gruß
Claus
Stefan Reuther (25.01.2019, 19:22)
Am 24.01.2019 um 22:06 schrieb Thomas Koenig:
> Für Skriptiges ist es bei mir typischerwise Perl. Schnell mal
> was geschrieben, nützliche Features wie assoziative Arrays und
> reguläre Ausdrücke.


Ebenso. Insbesondere: relativ problemlos für alles von DOS bis zum
64-bitter zu haben.

> Wissenschaftlich / technisch: Fortran. Geniale Unterstützung
> von Arrays, vor mehrdimensionalen (in C ist das eine Krankheit),
> Plus natürlich eine standardisierte Schnittstelle zu C :-)


C++ von 03 bis 17.

Wenn's low-leveliger wird (also "wissenschaftlich / technisch") dann
gern in einem Subset, der sehr nahe an C dran ist.

In 100% C hab ich einige Programme im Wartungsmodus. Grund für C ist
hier auch: relativ problemlos für alles von DOS bis zum 64-bitter zu haben.

Stefan
Thomas Koenig (25.01.2019, 23:09)
Claus Reibenstein <4spamersonly> schrieb:
> Thomas Koenig schrieb am 24.01.2019 um 22:06:
> C, weil ich sie beherrsche. C# und Java, weil sie mich interessieren.
> PHP und SQL, wenn es um dynamische Webseiten geht.
> Fortran habe ich schon lange nicht mehr angefasst. Fortran V aka Fortran
> 77 war die letzte Version, mit der ich programmiert habe. Angefangen
> hatte ich seinerzeit mit Fortran IV aka Fortran 66.


Wie die meisten Leute. Mit Fortran 90 wurde die Sprache ziemlich
modern, aber Compiler waren erst mal nur kommerziell verfügbar.

>> von Arrays, vor mehrdimensionalen (in C ist das eine Krankheit),

> Wieso "Krankheit"?


Weil sie nicht ordentlich unterstützt werden. Das "Pointer auf
Pointer" - Konstrukt legt einem bei Optimierungen jede Menge Steine
in den Weg. Mehrdimensionale Arrays macht man besser in einer
Sprache, in der sie von Haus aus unterstützt werden.

In modernem Fortran kann man z.B. Arraygrenzen automatisch mit
übergeben und damit auch Bounds Checking automatisch erledigen.

>> Plus natürlich eine standardisierte Schnittstelle zu C :-)

> Jetzt wird's interessant. Welche Version ist das?


Ab Fortran 2003, das wird z.B. von gfortran unterstützt.

Hier ist mal ein mittel-langes Beispiel, das mit Hilfe der
Standard-C-Funktion qsort einen Array von Pseudo-Zufallszahlen
sortiert:

module sort
use iso_c_binding
implicit none

interface
subroutine myqsort(array,elem_count,elem_size,compare) bind(C,name="qsort")
import
type(c_ptr),value :: array
integer(c_size_t),value :: elem_count
integer(c_size_t),value :: elem_size
type(c_funptr),value :: compare
end subroutine myqsort ! Deklaration von qsort
end interface

contains

subroutine qsort_float(a)
real(c_float), dimension(:), intent(inout), target :: a
call myqsort (c_loc(a(1)), size(a,kind=c_size_t), c_sizeof (a(1)), &
c_funloc(compare_float))
end subroutine qsort_float

integer(c_int) function compare_float (a,b) bind(C)
real(c_float), intent(in) :: a, b
integer :: ret

if (a > b) then
compare_float = 1
else if (a == b) then
compare_float = 0
else
compare_float = -1
end if
end function compare_float

end module sort

program main
use sort
implicit none
real, dimension(10) :: a
call random_number(a)
call qsort_float(a)
print *,a
end program main
Claus Reibenstein (25.01.2019, 23:31)
Thomas Koenig schrieb am 25.01.2019 um 22:09:

> Claus Reibenstein <4spamersonly> schrieb:
> Weil sie nicht ordentlich unterstützt werden. Das "Pointer auf
> Pointer" - Konstrukt legt einem bei Optimierungen jede Menge Steine
> in den Weg. Mehrdimensionale Arrays macht man besser in einer
> Sprache, in der sie von Haus aus unterstützt werden.


Also ich hatte nie Probleme mit mehrdimensionalen Arrays in C, und das
Pointer-auf-Pointer-Konstrukt fand ich (und finde ich auch heute noch)
genial, da es Möglichkeiten eröffnet, die in anderen Sprachen nicht
möglich sind.

> In modernem Fortran kann man z.B. Arraygrenzen automatisch mit
> übergeben und damit auch Bounds Checking automatisch erledigen.


C verzichtet - wohl aus Performance-Gründen - komplett auf Bounds
Checking und überlässt dies dem Programmierer. Ein Punkt, den nicht nur
ich mit gemischten Gefühlen betrachte.

>>> Plus natürlich eine standardisierte Schnittstelle zu C :-)

>> Jetzt wird's interessant. Welche Version ist das?

> Ab Fortran 2003, das wird z.B. von gfortran unterstützt.
> Hier ist mal ein mittel-langes Beispiel, das mit Hilfe der
> Standard-C-Funktion qsort einen Array von Pseudo-Zufallszahlen
> sortiert:


Danke dafür :-)

Gruß
Claus
Juergen Ilse (26.01.2019, 00:58)
Hallo,

Thomas Koenig <tkoenig> wrote:
> Claus Reibenstein <4spamersonly> schrieb:
> Weil sie nicht ordentlich unterstützt werden. Das "Pointer auf
> Pointer" - Konstrukt legt einem bei Optimierungen jede Menge Steine
> in den Weg.


Selbstverstaendlich gibt es in C auch mehrdimensionale arrays. Was meinst
du denn, wie ein Feld wie:

int 2dimarray [3][4];

in C organisiert ist?

> Mehrdimensionale Arrays macht man besser in einer
> Sprache, in der sie von Haus aus unterstützt werden.


C kennt selbstverstaendlich auch mehrdimensionale arrays.

> In modernem Fortran kann man z.B. Arraygrenzen automatisch mit
> übergeben und damit auch Bounds Checking automatisch erledigen.


OK, C erzeugt nicht automatisch bounds-checking Code.

>>> Plus natürlich eine standardisierte Schnittstelle zu C :-)

>> Jetzt wird's interessant. Welche Version ist das?

> Ab Fortran 2003, das wird z.B. von gfortran unterstützt.


Durch welchen Standard ist das denn standardisiert (ausser von "compiler-
spezifischen Eigenarten) und mit welchen Kombinationen von Compilern funk-
tioniert das auch *garantiert*?

Tschuess,
Juergen Ilse (juergen)
Bonita Montero (26.01.2019, 09:47)
> Selbstverstaendlich gibt es in C auch mehrdimensionale arrays.
> Was meinst du denn, wie ein Feld wie:
> int 2dimarray [3][4];


Aber keine dynamischen.
Thomas Koenig (26.01.2019, 11:18)
Juergen Ilse <news> schrieb:
> Hallo,
> Thomas Koenig <tkoenig> wrote:
> Selbstverstaendlich gibt es in C auch mehrdimensionale arrays. Was meinst
> du denn, wie ein Feld wie:
> int 2dimarray [3][4];
> in C organisiert ist?


Sind die auch brauchbar, sprich:

Kann man die mit variablen Grenzen, verwenden, als Argumente, um
sie an eine Funktion zu übergeben, und sind sie als nicht-optional
in der letzten Version der C Norm vorgeschrieben?

Nehmen wir mal ein einfaches Beispiel: Ich möchte gerne eine
Funktion schreiben, die eine Matrixmultiplikation eies 3*4 - Array
mit einem 4*5 durchführt (das Ergebnis ist ein 3*5 - Array).
Die Funktion soll mit allgemeinen Feldgrößen klarkommen.

Wie macht man das unter Verwendung der mehrdimensionalen Arrays
in C, auch in der Funktion selber?

>> Mehrdimensionale Arrays macht man besser in einer
>> Sprache, in der sie von Haus aus unterstützt werden.

> C kennt selbstverstaendlich auch mehrdimensionale arrays.


Nur nicht besonders brauchbar; wenn man die an eine Funktion
übergibt, hat man wieder einen eindimensionalen Pointer.

>> In modernem Fortran kann man z.B. Arraygrenzen automatisch mit
>> übergeben und damit auch Bounds Checking automatisch erledigen.

> OK, C erzeugt nicht automatisch bounds-checking Code.


Das macht Fortran auch nicht, aber die Information ist da.
Und dass Array-Grenzen automatisch richtig übergeben werden,
das hilft auch gewaltig, Argumentlisten kurz zu halten und
Fehler zu vermeiden.

>>>> Plus natürlich eine standardisierte Schnittstelle zu C :-)
>>> Jetzt wird's interessant. Welche Version ist das?

>> Ab Fortran 2003, das wird z.B. von gfortran unterstützt.

> Durch welchen Standard ist das denn standardisiert


Fortran 2003 (das ist die Bezeichnung der Norm) und folgende
Normen, Fortran 2008 und Fortran 2018.

Wenn du's genau wissen willst: Die erste Version findet sich in
J3/04-007,
Section 15: Interoperability with C. Das ist ein "working
document", das mit ISO/IEC 1539-1:2004(E) identisch ist.

Und unterstützt wird das von allen heute relevanten Compilern,
d.h. die großen kommerziellen Compilter (Intel, IBM, Cray)
und, wenn's ein bisschen weniger Geld kosten soll (vor allem
für die Cray-Hardware) auch schon lange von gfortran.
Thomas Koenig (26.01.2019, 11:27)
Bonita Montero <Bonita.Montero> schrieb:
>>> C++ - Weil man in C so unproduktiv ist!

>> Hm, mit welchem Subset denn?

> Ist gar nicht mehr nötig, denn die Unterschiede zwischen den Compilern
> sind kaum noch maßgeblich.


Das meinte ich nicht.

Das Problem bei C++ sehe ich eher darin, dass die Sprache so groß
geworden ist, dass man sich naturgemäß in einem Projekt auf eine
sinnvolle Untermenge beschränken muss, weil kein normaler Mensch
mehr die Sprache komplett beherrschen kann. (Da ist C deutlich
angenehmer). Und mit jeder neuen Version von C++ wird wieder eine
neue Abstraktionsschicht drübergekippt, und das macht es nicht
einfacher. Das ist nicht "creeping featuritis", das ist "galloping
featuritis".

Ein schönes Beispiel sind die geplanten Module in C++. Wer sich
jemals fragte, ob ein Compiler ein Web Interface enthalten
sollte, findet auf
einen schönen Talk, bei dem genau das vorgeschlagen wird, und
zwar von einem Mitglied des C++-Normungsgremiums (Achtung, sind
ca. 45 Minuten). Ich saß damals im Publikum und habe nur noch
mit dem Kopf geschüttelt.
Thomas Koenig (26.01.2019, 11:29)
Claus Reibenstein <4spamersonly> schrieb:
> Thomas Koenig schrieb am 25.01.2019 um 22:09:
> Also ich hatte nie Probleme mit mehrdimensionalen Arrays in C, und das
> Pointer-auf-Pointer-Konstrukt fand ich (und finde ich auch heute noch)
> genial, da es Möglichkeiten eröffnet, die in anderen Sprachen nicht
> möglich sind.


Leider ist es ziemlich aufwändig zu programmieren und legt
dem Compiler zur Optimierung auch eine Menge Steine in den Weg.
Konstante Strides beim Zugriff auf Arrays ist dann halt nicht mehr...

Ähnliche Themen