Re: Cracking DES with C++ is faster than Java?

From: Paul Schlyter (pausch_at_saaf.se)
Date: 05/03/04 

Date: Mon, 03 May 2004 19:45:28 GMT

In article <4qSdnUXRwbbqkAvdRVn-ug@comcast.com>,
Douglas A. Gwyn <DAGwyn@null.net> wrote:
 
> Paul Schlyter wrote:
>> :-) .... try the standard problem of writing a subroutine to invert a
>> matrix of arbitrary size. Fortran has had the ability to pass a
>> 2-dimensional array of arbitrary size to subroutines for decades. In
>> C++ you cannot do that -- you'll have to play games with pointers to
>> acheive similar functionality. ...
>
> C doesn't have multidimensional arrays, but it does support
> arrays of arrays
 
C's arrays of arrays are useless here, because you must decide the
number of elements in all dimensions except the last one. In C
you must use pointers to pointers instead, forcing the storage
of a number of pointers, which must be accessed at runtime. THis
slows down the execution of the code.
 
> and other complex structures.
 
True, C is more versatile. Just a pity they left out that case
of multi-dimensional arrays. C borrowed so many other good
properties from Fortran (efficient code, separate compilation,
static variables, a good set of math functions, floating-point
numbers in single AND double precision) so it could have borrowed
that feature as well.
 
In essence C was a very good mixture from the beast features of several
languages existing prior to C. I've already listed what it borrowed
from Fortran; from Pascal it borrowed automatic variables and dynamic
allocation of memory, recursion, and structured programming concepts.
And from assembler it borrowed low-level support such as pointers
and bit manipulation. However C didn't borrow object orientation
from Simula... :-)
 
> Using these tools you get a *choice* of how to represent matrices,
 
In C there's not much of a choice here -- if you want to represent
an arbitrary sized matrix in a way convenient to use, you're
pretty much stuck with the pointer-to-pointer representation.
 
> unlike the native Fortran facility where you're stuck with
> whatever the compiler has wired in.
 
True, C is more versatile, I never argued against that.
 
> In C++ one would normally use a matrix class in order to be
> able to apply the standard operators, e.g. + and *.
 
...and that matrix class would have to be implemented using the same
basic language features which are available in C -- in that respect
C++ does not offer any advantage over C.
  

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://www.stjarnhimlen.se/
         http://home.tiscali.se/pausch/

Relevant Pages

  • Re: Cracking DES with C++ is faster than Java?
    ... > C doesn't have multidimensional arrays, ... you must use pointers to pointers instead, ... properties from Fortran (efficient code, separate compilation, ... However C didn't borrow object orientation ...
    (comp.lang.java)
  • Re: Cracking DES with C++ is faster than Java?
    ... > C doesn't have multidimensional arrays, ... you must use pointers to pointers instead, ... properties from Fortran (efficient code, separate compilation, ... However C didn't borrow object orientation ...
    (sci.crypt)
  • Re: INTERFACE problem
    ... I have an integer at Fortran side, pass it by reference to C function, treat here as pointer, allocate memory and this C-pointer at Fortran side now is an integer which has represents address allocated at C side. ... I did something like this many years ago to allow dynamic allocation ... Then it was converted into a subroutine with the arrays and ... it called the sub by way of Pascal with those "pointers". ...
    (comp.lang.fortran)
  • Re: INTERFACE problem
    ... I have an integer at Fortran side, ... >it by reference to C function, treat here as pointer, allocate memory ... C pointers and arrays ... WHen the Main got the now initialized "pointers" ...
    (comp.lang.fortran)
  • Re: best practices for structuring ASCII input
    ... I'm maintaining a number of smallengineering/scientific Fortran ... data consists of a mixture of variables, arrays, ... the input files are not human readable. ...
    (comp.lang.fortran)