Michael S <
already5chosen@yahoo.com> schrieb:
On Thu, 5 Sep 2024 11:36:22 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
>
Michael S <already5chosen@yahoo.com> schrieb:
On Wed, 4 Sep 2024 17:08:36 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
Michael S <already5chosen@yahoo.com> schrieb:
On Tue, 3 Sep 2024 20:05:14 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
My impression - based on hearsay for Rust as I have no
experience
- is that the key point of Rust is memory "safety". I use
scare-quotes here, since it is simply about correct use of
dynamic memory and buffers.
>
It is entirely possible to have correct use of memory in C,
>
If you look at the evolution of programming languages,
"higher-level" doesn't mean "you can do more stuff". On the
contrary, making a language "higher-level" means deciding
what it is we want to make harder or even impossible.
Really?
I thought Fortran was higher level than C, and you can do a lot
more things in Fortran than in C.
Or rather, Fortran allows you to do things which are possible,
but very cumbersome, in C. Both are Turing complete, after
all.
>
I'd say that C in the form that stabilized around 1975-1976 is
significantly higher level language than contemporary Fortran
dialects or even the next Fortran dialect (F77).
I did write Fortran, not FORTRAN :-)
I agree that C had many very useful things that pre-FORTRAN 90
did not have. This is not surprising, since the authors of
C knew FORTRAN well.
[...]
Overall, the differences in favor of C looks rather huge.
You are arguing from the point of view of more than 30 years ago.
On the other hand, I recollect only two higher level feature
present in old Fortran that were absent in pre-99 C - VLA and
Complex.
You forget arrays as first-class citizens,
>
In theory, this is an advantage. In practice - not so much.
Old Fortran lacked two key features that make 1st-class arrays
really useful - array length as an attribute and pass-by-value.
You want to pass arrays by value? In practice, that would mean
copy-in and copy-out. Is this something that you do often?
>
>
In languages that I use daily it's not something you can decide freely.
My sympathies.
It is not always possible to avoid packing/unpacking of arrays in
Fortran, for example when passing a non-contiguous array slice
to an old-style or contiguous array, but at least gfortran
has -Warray-temporaries, so the user can be notified.
I one group (C, to slightly less extent C++) passing arrays by value is
cumbersome so I use it less than I would probably do if it was
more convenient.
It is also a potential performance killer - allocating the
temporary array, copying (which will impact the cache), and
then possibly doing the same thing in reverse.
This is one reason why INTENT is quite useful, it can inform
the compiler that copying in or copying out may not be needed.
In other group (Matlab/Octave) pass-by-value is the only available
option, so I use it all the time, but it does not mean much.
I knew there's a reason for me not using matlab or octave :-)
But of course, if it's your day job, you have little choice
in the matter.
I prefer Julia for the more script-oriented stuff, it can be
quite fast.
[...]
Please show an example how you would pass an 2*2 submatrix of a
3*3 matrix in C.
>
>
I said 'arrays'. I never said that it is easy for matrices :(
Two-dimensional arrays or matrices, I don't see a big difference.
But it definitely works for matrices as well. C binding of LAPACK is a
good example of the typical API.
Lapack, whose C interface is as cumbersome as the original FORTRAN one,
is a good example why assumed-shape arrays are so powerful.
The trick is to not forget to keep
lead dimension in separate parameter from number of columns (assuming C
conventions for order of elements in matrix).
I do use this trick in my signal processing practice.
But agree that for case of matrices C is only very slightly more
convenient than old FORTRAN.
The we disagree - old-style FORTRAN was more convenient for arrays
than C.
>
In Fortran, this is, on the caller's side,
real, dimension(3,3) :: a
call foo(a(1:2,1:2))
or also
call foo(a(1:3,1:3))
and on the callee's side
subroutine foo(a)
real, dimension(:,:) :: a
Or, maybe even harder to do in C
call foo(a(1:3:2,1:3:2))
which will pass the elements with indices (1,1),(3,1),(1,3),(3,3)
to foo, whose programmer can be perfectly obvlivious of anything
strange being passed, the arrays just work.
[... going into F95 features...]
- ALLOCATE and ALLOCATABLE variables, where the compiler
cleans up after variables go out of scope
>
How does it differ from automatic variables that C together with
nearly all other Algol derivatives, had from the very beginning?
You can allocate and deallocate whenever, so you have the
flexibility of C's pointers with the deallocation handled
by the compiler.
For example
type foo
real, allocatable, dimension(:) :: x, y, z, f
end type foo
...
type(foo) :: p
...
allocate (p%x(n), p%y(n), p%z(n), p%f(n))
All of this will be deallocated when p gets out of scope.
>
>
I still don't see how it's more capable than C99 except for minor
ability to group automatic VLAs in sort of struct.
You can do the following in Fortran:
subroutine init_foo(p,n)
type(foo), intent(out), dimension(:) :: p
integer, intent(in) :: n
integer :: i
do i=1,size(p)
allocate (p%x(n),p%y(n),p%z(n))
end do
end subroutine foo
init_foo will deallocate every component upon entry to the
subroutine (automatically), and then it allocates the components x,
y and z. The caller then can do things with it.
This would not be possible with pointers to VLA-allocated memory
in C.
It is very much like pointers in C, except the compiler cleans
up after the variables go out of scope.
Fortran also has pointers, which can also point to arrays and
array slices. For a pointer to point to anything, either
you have to allocate it (same syntax as allocatables, but
you have to deallocate explicitly), or you can associate
it with a target, which has to explicity to be marked TARGET.
Plus, you don't need to pass a pointer to a variable if
you want its value set (or do array stuff on it). One of
my pet peeves about C is that in
int a;
/* Set vaulue for a. */
foo(&a);
...
bar();
the value of a could be changed behind the programmer's back
in bar() according to C's language definition.
Computer architects leaving Intel...
Re: Computer architects leaving Intel...
