Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > pointer plus an integer

Reply
Thread Tools

pointer plus an integer

 
 
Wade Ward
Guest
Posts: n/a
 
      10-15-2007


"Ernie Wright" <(E-Mail Removed)> wrote in message
news(E-Mail Removed). ..
> Wade Ward wrote:
>
>> "James Kuyper Jr." <(E-Mail Removed)> wrote in message
>> news:7z5Qi.793$hI1.195@trndny06...
>>
>>>Jack Klein wrote:
>>>
>>>>This is hideous code, it looks like somebody tried translating FORTRAN
>>>>to C, with the indices beginning at 1 instead of 0.
>>>
>>>Correct.

>>
>> No, incorrect. This pointer-infested slop was never fortran.
>>
>> The fortran would look more like:
>> real, allocatable :: A(:,
>> ...
>> allocate (A(rows,columns))

>
> That's Fortran 90. The original Numerical Recipes was written using
> Fortran 77.

The biggest attraction to f77 was the dynamically allocatable array, at
least so says Richard Maine. If that was originally f77, the author clearly
was not using the strength of the syntax. Hideous code is somehow a
metasyntactic constant.
--
wade ward
"Nicht verzagen, Bruder Grinde fragen."


 
Reply With Quote
 
 
 
 
Wade Ward
Guest
Posts: n/a
 
      10-15-2007



"Ben Pfaff" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Ernie Wright <(E-Mail Removed)> writes:
>
>>> It looks like sample code from Numerical Recipes in C.
>>> [...]
>>> double *m = malloc(10* sizeof *m);
>>> m -= 1;
>>>
>>> Of course, that's undefined behaviour.

>>
>> The book was written before C89.

>
> The latest edition has a discussion of the issue and a fix for
> the code, although the authors do not exactly take a
> comp.lang.c-approved attitude toward it.

If the authors *ever* approved of that code, it would be proof of their own
incompetence.

char a[]="\n .CJacehknorstu";int putchar(int);int main(void)
{unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;
for(;p+=!*p;*p/=4)
switch(0[p]&3)case 0:

{
system("pause");
return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);
break;}}}
--
wade ward
"Nicht verzagen, Bruder Grinde fragen."


 
Reply With Quote
 
 
 
 
James Kuyper Jr.
Guest
Posts: n/a
 
      10-15-2007
Wade Ward wrote:
> "James Kuyper Jr." <(E-Mail Removed)> wrote in message
> news:7z5Qi.793$hI1.195@trndny06...

....
>> Correct. That's exactly the historical development of the NRC (Numerical
>> Recipes in C) library. I've translated a fair number of their
>> "Fortran-inspired C" routines into "native C" style; the effort was
>> significant; avoiding off-by-one errors in loops required constant
>> vigilance - I can understand why someone not very familiar with C might
>> have chosen this awful work-around to avoid having to do that same work.

> No, incorrect. This pointer-infested slop was never fortran.


I didn't say that it was. That pointer-infested slop was created during
the translation process from Fortran to C, apparently by someone far
more familiar with Fortran than with C. It's a clever, but fundamentally
misguided, attempt to create something in C that can be used in a manner
similar to Fortran arrays, thereby simplifying the translation of
Fortran code which indexed those "arrays".

The cost of this design decision was that it made the code hard to
understand for more experienced C programmers, and added in unnecessary
complexity related to allocation and deallocation of those arrays.

> The fortran would look more like:
> real, allocatable :: A(:,


I have a fair amount of experience with Fortran, but it ended a long
time ago, before I ever used a compiler supporting the features you're
using in that statement. I strongly suspect that the original Fortran
version of the Numerical Recipes library also pre-dates those features;
or at least, was written to be backwardly compatible with compilers that
did not yet support them.
 
Reply With Quote
 
Ernie Wright
Guest
Posts: n/a
 
      10-15-2007
Wade Ward wrote:

> "Ernie Wright" <(E-Mail Removed)> wrote in message
> news(E-Mail Removed). ..
>
>>Wade Ward wrote:
>>
>>>The fortran would look more like:
>>>real, allocatable :: A(:,
>>>...
>>>allocate (A(rows,columns))

>>
>>That's Fortran 90. The original Numerical Recipes was written using
>>Fortran 77.

>
> The biggest attraction to f77 was the dynamically allocatable array, at
> least so says Richard Maine.


You're misremembering what he said, or he misspoke. f77 doesn't have
allocatable arrays. It doesn't even have lowercase source.

- Ernie http://home.comcast.net/~erniew
 
Reply With Quote
 
Wade Ward
Guest
Posts: n/a
 
      10-15-2007



"James Kuyper Jr." <(E-Mail Removed)> wrote in message
news:gNHQi.699$H92.359@trnddc07...
> Wade Ward wrote:
>> "James Kuyper Jr." <(E-Mail Removed)> wrote in message
>> news:7z5Qi.793$hI1.195@trndny06...

> ...
>>> Correct. That's exactly the historical development of the NRC (Numerical
>>> Recipes in C) library. I've translated a fair number of their
>>> "Fortran-inspired C" routines into "native C" style; the effort was
>>> significant; avoiding off-by-one errors in loops required constant
>>> vigilance - I can understand why someone not very familiar with C might
>>> have chosen this awful work-around to avoid having to do that same work.

>> No, incorrect. This pointer-infested slop was never fortran.

>
> I didn't say that it was. That pointer-infested slop was created during
> the translation process from Fortran to C, apparently by someone far more
> familiar with Fortran than with C. It's a clever, but fundamentally
> misguided, attempt to create something in C that can be used in a manner
> similar to Fortran arrays, thereby simplifying the translation of Fortran
> code which indexed those "arrays".
>
> The cost of this design decision was that it made the code hard to
> understand for more experienced C programmers, and added in unnecessary
> complexity related to allocation and deallocation of those arrays.
>
>> The fortran would look more like:
>> real, allocatable :: A(:,

>
> I have a fair amount of experience with Fortran, but it ended a long time
> ago, before I ever used a compiler supporting the features you're using in
> that statement. I strongly suspect that the original Fortran version of
> the Numerical Recipes library also pre-dates those features; or at least,
> was written to be backwardly compatible with compilers that did not yet
> support them.

That's probably a fair run-down on what happened.
--
wade ward
"Nicht verzagen, Bruder Grinde fragen."


 
Reply With Quote
 
Wade Ward
Guest
Posts: n/a
 
      10-15-2007




"Ernie Wright" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed). ..
> Wade Ward wrote:
>
>> "Ernie Wright" <(E-Mail Removed)> wrote in message
>> news(E-Mail Removed). ..
>>
>>>Wade Ward wrote:
>>>
>>>>The fortran would look more like:
>>>>real, allocatable :: A(:,
>>>>...
>>>>allocate (A(rows,columns))
>>>
>>>That's Fortran 90. The original Numerical Recipes was written using
>>>Fortran 77.

>>
>> The biggest attraction to f77 was the dynamically allocatable array, at
>> least so says Richard Maine.

>
> You're misremembering what he said, or he misspoke. f77 doesn't have
> allocatable arrays. It doesn't even have lowercase source.

f77 is fixed-form, where source needs to be in a certain column or face
terrible consequences. I've only seen it as upper-case, and it looks like
shouting. f90 allowed free-form, with much more-relaxed rules for
appearance. I don't think I remember wrongly about Richard's reasons for
using f77, and he seems to be a walking fortran encyclopedia.

f2003 allows interoperabiltiy with C, but there is no full-fledged compiler
yet available. I don't know where the rub is, as far as getting a compliant
implementation (I use f95). If I had to guess, I would say it's with the
object-oriented stuff. There's also head-scratchers with C interop. People
are constructively discussing issues having to do with f2008.
--
wade ward
"Nicht verzagen, Bruder Grinde fragen."


 
Reply With Quote
 
Wade Ward
Guest
Posts: n/a
 
      10-15-2007


[snipped from elsewhere]

>>I can't see how to cast an integer to a pointer.


> You can't. Fortran doesn't do that - not even with the C interop stuff.
> Of course,you can always play around with TRANSFER, but recall that the
> standard says that the resulting values are undefined when you type
> cheat with TRANSFER. And you can do it in C.


You can't do it portably in C, either. I believe you can memcpy() in
to an (unsigned char *) and back again. If sizeof(int) >= sizeof(void*)
you might be able to do the cast, but the use of the value of the
int is non-portable. Those writing large model x86 code, and
who try to do such casts, know all about this one.

>> cptr = C_PTR(p+1)


> I suppose you are trying to use a structure constructor here. You can't
> do that with C_PTR as it has (intentionally) private components. The
> whole point of private components is to keep you from fiddling with the
> innards. You can't write a structure constructor for a private component
> - you don't even know what the components are. Now maybe you know what a
> C pointer better look like inside, but accordingh to the Fortran
> compiler, you don't know.


From K&R2 (close, but not exactly, the C89 standard) A6.6:

"Certain other conversions involving pointers and integers are
permitted, but have implementation defined aspects. They must
be specified by an explicit type-conversion operator, or cast."

"A pointer may be converted to an integral type large enough to
hold it; the required size is implementation-dependent. The
mapping function is also implementation dependent."

"An object of integral type may be explicitly converted to a
pointer. The mapping always carries a sufficiently wide integer
converted from a pointer back to the same pointer, but is
otherwise implementation-dependent."

Can someone in the know comment on the above?
--
wade ward
"Nicht verzagen, Bruder Grinde fragen."


 
Reply With Quote
 
Ernie Wright
Guest
Posts: n/a
 
      10-16-2007
Wade Ward wrote:

> Ernie Wright wrote:
>> Wade Ward wrote:
>>> Ernie Wright wrote:
>>>
>>>>That's Fortran 90. The original Numerical Recipes was written using
>>>>Fortran 77.
>>>
>>>The biggest attraction to f77 was the dynamically allocatable array, at
>>>least so says Richard Maine.

>>
>>You're misremembering what he said, or he misspoke. f77 doesn't have
>>allocatable arrays. It doesn't even have lowercase source.

>
> f77 is fixed-form, where source needs to be in a certain column or face
> terrible consequences. I've only seen it as upper-case, and it looks like
> shouting. f90 allowed free-form, with much more-relaxed rules for
> appearance.


Yeah, I know all that. Fortran was my second language, and f77 was the
language used in my first computer science course in college.

It didn't have allocatable arrays.

> I don't think I remember wrongly about Richard's reasons for
> using f77, and he seems to be a walking fortran encyclopedia.


There's no reason to guess. Plenty of websites list the major features
added to f90.

- Ernie http://home.comcast.net/~erniew
 
Reply With Quote
 
Wade Ward
Guest
Posts: n/a
 
      10-16-2007


"Ernie Wright" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed). ..
> Wade Ward wrote:


> Yeah, I know all that. Fortran was my second language, and f77 was the
> language used in my first computer science course in college.

Me too. We didn't get very far with the material.

> It didn't have allocatable arrays.
>
>> I don't think I remember wrongly about Richard's reasons for using f77,
>> and he seems to be a walking fortran encyclopedia.

>
> There's no reason to guess. Plenty of websites list the major features
> added to f90.

Yeah, you're right. I wonder if I remember wrong or Richard mistyped....
http://en.wikipedia.org/wiki/Fortran#FORTRAN_77

--
wade ward
"Nicht verzagen, Bruder Grinde fragen."


 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      10-29-2007
On Fri, 12 Oct 2007 02:58:08 -0400, Ernie Wright <(E-Mail Removed)>
wrote:

> Jack Klein wrote:
>
> > On Thu, 11 Oct 2007 11:42:00 -0700, "Ivan K." <(E-Mail Removed)>
> > wrote in comp.lang.c:

<snip: code from Numerical Recipes in C>
> The first part creates matrices of maximum size.
>
> The second part fiddles with pointers to make the matrices appear to be
> some other (smaller) size, presumably the actual size needed at that
> point in the code.
>
> This is a common Fortran idiom. It's unnecessary in C, since you can
> allocate exactly the amount of memory you need at run time. In Fortran,
> an array of fixed maximum size has to be created at compile time.
>

<OT> It was necessary in early versions of the language then known as
FORTRAN (all caps). Since the 1990 version, when the name was changed
to Fortran, you can have local (non-COMMON, non-SAVEd) arrays with
size determined at routine entry, much like the VLA types added to C
in C99, somewhat confusing called 'automatic'; and also 'allocatable'
arrays which are dynamically allocated to a runtime-computable size,
and deallocated etc., like C malloc&friends except that the bounds are
automatically remembered for you and used, and it never leaks (since
some minor fixes in F95 IIRC), although there are some contexts you
can't use allocatable until post-F95 (a TR to F95, folded into F03).

<snip rest>
- formerly david.thompson1 || achar(64) || worldnet.att.net
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
c plus plus code comparator furqan shaikh C++ 6 11-12-2008 06:14 AM
Invoking c function in a c plus plus function... Rahul C++ 9 03-25-2008 05:24 PM
C plus plus vs C Sharp The LoxFather C Programming 23 08-14-2003 03:51 AM
C plus plus vs C Sharp The LoxFather C++ 23 08-14-2003 03:51 AM



Advertisments