experchange > fortran

dave_thompson_2 (12-15-18, 12:55 AM)
On Mon, 29 Oct 2018 23:42:56 -0600, Louis Krupp
<lkrupp> wrote:

> To the best of my knowledge, C has always had fixed-size arrays ...
> An equivalent Fortran declaration would be: ...
> In C, it's also possible to declare an array of three pointers:
> int (*c)[3];
> and assign values to each one. For example, each element of c could
> point to its own newly-allocated one-dimensional array of four ints:
> c[0] = (int*)malloc(4 * sizeof(int));
> ...

int (*c)[3]; declares _one_ pointer to a clump of 3 ints, or one of
several such clumps, e.g. a row in an Nx3 (row-major) array.

int * c [3]; // declares three pointers, usable like array rows
c[0] = malloc(4 * sizeof(inf));
/* standard (C>=89) malloc returns void* so no cast */
c[1] = similar; c[2] = similar;
/* should check for null=failed and handle */

or you _can_ use parts of a single large block:
int * c [3];
c[0] = malloc (3*4 * sizeof(int));
c[1] = c[0] + 4 /* implicitly scaled by sizeof(int) */;
c[2] = c[1] + 4;
or somewhat terser with a temporary:
int * c[3], * t = malloc(3*4 * sizeof(int));
c[0] = t; t += 4; c[1] = t; t += 4; c[2] = t;
dave_thompson_2 (12-15-18, 12:57 AM)
On Mon, 29 Oct 2018 03:18:31 -0700 (PDT), Arjen Markus
<arjen.markus895> wrote:

> VLAs in C are comparable to automatic arrays in Fortran: ...


> From the post I understand that VLAs are also used in structures

- how that works out I do not know, but I can imagine that that causes
a lot of overhead: the position of elements from such a structure in
memory then depends on the actual size and thus can not be determined
at compile-time.

Actually they aren't; the article is either lazy or wrong.

C>=99 structs have a similar but distinct feature: Flexible Array
Member (FAM) which is declared with _nothing_ for dimension (unlike
VLA which is declared with runtime-computed expression for dimension)
and, to your point, must be the last member in the struct, so all
member offsets are still fixed at compiletime. Thus:

struct packet { // very simple example
int type, flags, len;
char data [ ]; // no dimension in the brackets
}; // maybe add a typedef'ed name for it if you prefer

can be used to (explicitly) allocate and then access chunks of memory
that vary in size from 3 int's and 0 char's to 3 int's and as many
char's as you want (subject to limits on how much memory or address
space you have, of course). This is like FORTRAN assumed-size: it can
be any size but you are responsible for keeping track of what size it
actually is and not accessing outside that.

Even sizeof (FAMstruct) is fixed at compiletime, to the size with 0
elements in the FAM, so declaring a variable of this type is almost
never what you want. To get the actual size of a FAM struct (and e.g.
malloc it) you must compute explicitly, in this case something like
offsetof(struct packet, data) + data_length_in_chars .
gah4 (12-15-18, 01:30 AM)
On Friday, December 14, 2018 at 2:57:03 PM UTC-8, dave_th...@comcast.net wrote:
> On Mon, 29 Oct 2018 03:18:31 -0700 (PDT), Arjen Markus
> <arjenmarku> wrote:


> > VLAs in C are comparable to automatic arrays in Fortran: ...


> > From the post I understand that VLAs are also used in structures

> - how that works out I do not know, but I can imagine that that causes
> a lot of overhead: the position of elements from such a structure in
> memory then depends on the actual size and thus can not be determined
> at compile-time.


> Actually they aren't; the article is either lazy or wrong.


> C>=99 structs have a similar but distinct feature: Flexible Array
> Member (FAM) which is declared with _nothing_ for dimension (unlike
> VLA which is declared with runtime-computed expression for dimension)
> and, to your point, must be the last member in the struct, so all
> member offsets are still fixed at compiletime. Thus:


> struct packet { // very simple example
> int type, flags, len;
> char data [ ]; // no dimension in the brackets
> }; // maybe add a typedef'ed name for it if you prefer


> can be used to (explicitly) allocate and then access chunks of memory
> that vary in size from 3 int's and 0 char's to 3 int's and as many
> char's as you want (subject to limits on how much memory or address
> space you have, of course). This is like FORTRAN assumed-size: it can
> be any size but you are responsible for keeping track of what size it
> actually is and not accessing outside that.


In C<99, it was not unusual to have char data[1] at the end.

I remember one graphics package that did this with many of
its structs. Maybe with sizes and scale factors at the beginning,
and the graphics bitmap at the end.

> Even sizeof (FAMstruct) is fixed at compiletime, to the size with 0
> elements in the FAM, so declaring a variable of this type is almost
> never what you want. To get the actual size of a FAM struct (and e.g.
> malloc it) you must compute explicitly, in this case something like
> offsetof(struct packet, data) + data_length_in_chars .


I would have thought malloc(sizeof(struct packet)+data_length_in_chars).

If the data was declared length one, then subtract 1, or else don't
worry about one wasted byte.

Declaring the length 1 reminds me of the popular Fortran
convention, before (*) for assumed size arrays, of dimensioning
the array (1). That worked well until compile time bounds checking
came along and caught them. It also didn't work with WATFIV, one
of the few in Fortran 66 days with non-optional run-time bounds test.
dave_thompson_2 (01-06-19, 03:13 AM)
On Fri, 14 Dec 2018 15:30:43 -0800 (PST), gah4 wrote:

> On Friday, December 14, 2018 at 2:57:03 PM UTC-8, dave_th...@comcast.net wrote: ....
> In C<99, it was not unusual to have char data[1] at the end.

Not unusual, but never standard, as FAM is.


> > Even sizeof (FAMstruct) is fixed at compiletime, to the size with 0
> > elements in the FAM, so declaring a variable of this type is almost
> > never what you want. To get the actual size of a FAM struct (and e.g.
> > malloc it) you must compute explicitly, in this case something like
> > offsetof(struct packet, data) + data_length_in_chars .

> I would have thought malloc(sizeof(struct packet)+data_length_in_chars).

sizeof(struct packet) may include padding. Although often you can
afford to waste a little memory sometimes, and that is simpler.

> If the data was declared length one, then subtract 1, or else don't
> worry about one wasted byte.
> Declaring the length 1 reminds me of the popular Fortran
> convention, before (*) for assumed size arrays, of dimensioning
> the array (1). That worked well until compile time bounds checking
> came along and caught them. It also didn't work with WATFIV, one
> of the few in Fortran 66 days with non-optional run-time bounds test.


Same idea, yes.
brooksj631 (01-14-19, 07:16 PM)
CONTACT US FOR Pain Pills,Nembutal,Seconal ,Oxycotin, Dilaudid,Valium,Hydrocodone & Ritalin Online.
call or text +1(405)500-0724
website :
email me at cliffbudman237
Hello, we are suppliers of assorted pain killers and anxietay pain relief meds, and other research chemicals. Discount are also applicable for bulk buyers.The shipping is meticulously planned; packaging is done with professionalis.
We have the following meds below available in stock now for auction;
Pain/ Anxiety Pills
Seconal
Nembutal (Powder,Pills and Liquid form)
Oxycotin / Oxycodone 10,20 a,40 and 80 mg
Actavis Promethazine Codeine Purple Cough Syrup (16oz and 320z)
Hydrocodone 10500, 10325 ,7.5750 mg
Valium 10,15 and 20 mg
Xanax 1 and 2 mg
Dilaudid 2,4 and 8 mg
Ritalin 5,10, 20 mg
Percocet 7.5mg,5mg and 10mg
Opana 20mg and 40mg
Lorcet - (Hydrocodone Bitartrate/Acetaminophen) 10 mg/650 mg
Midazolam 3mg
Motrin 400mg and 600mg
Norco - ( Hydrocodone Bitartrate/Acetaminophen ) 5 mg/325 mg
Soma 350mg
Tramadol (Ultram) 50mg
Valium 2mg,5mg and 10mg
Valium Roche Brand 10mg
Voltaren 50mg and 100mg
Adderall,Anaprox,Ansaid,Acephen
Bupren , ex,Butrans
Percocet,Phrenilin,Percodan
Soma, , Subutex
Cataflam,Celebrex
Flexeril, Fentora ..,
Demerol,Daypro,Dilaudid
Endocet
Lorcet, L, ortab
Ibudone
Methadone,Morphine
Naprosyn , ,Norco
Oxycontin, Opana
Ritalin, Roxicodone®

Similar Threads