Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Can I tab[-1] ? (http://www.velocityreviews.com/forums/t955679-can-i-tab-1-a.html)

fir 12-20-2012 06:25 AM

Can I tab[-1] ?
 
Can I use c arrays in such way tab[-1] or tab[-1][-1] (I mean when index is below zero)?

Also - I think if try to use some way of optimization
where instead of checking some edge values like

if(x>=0 && x<500 && y>=0 && y<500)
tab[y][x] = 1;

alloc some edge ram and do not bother about x=-1 or x=tab_max_x+1

but here it would be convenient to cast some pointer ot type tab[500][500] 'into' wider_tab[502][502]
in such way that tab[0][0] wolul correspond to wider_tab[1][1] (and tab[-1][-1] to wider_tab[0][0])

Can I get something like that? (If not I am sad)







glen herrmannsfeldt 12-20-2012 07:43 AM

Re: Can I tab[-1] ?
 
fir <profesor.fir@gmail.com> wrote:
> Can I use c arrays in such way tab[-1] or tab[-1][-1]
> (I mean when index is below zero)?


> Also - I think if try to use some way of optimization
> where instead of checking some edge values like


> if(x>=0 && x<500 && y>=0 && y<500)
> tab[y][x] = 1;


> alloc some edge ram and do not bother about x=-1 or x=tab_max_x+1


Not with actual arrays, but you can with pointers and arrays
of pointers.

> but here it would be convenient to cast some pointer ot type
> tab[500][500] 'into' wider_tab[502][502] in such way that
> tab[0][0] wolul correspond to wider_tab[1][1]
> (and tab[-1][-1] to wider_tab[0][0])


> Can I get something like that? (If not I am sad)


There is much discussion about pointers outside the allocated
space, such that the offset is inside. In this case, though,
the pointer is inside the allocated space, such that adding -1
is still inside.

-- glen

fir 12-20-2012 08:06 AM

Re: Can I tab[-1] ?
 
W dniu czwartek, 20 grudnia 2012 08:43:49 UTC+1 użytkownik glen herrmannsfeldt napisał:
> fir <profesor.fir@gmail.com> wrote:
> > Can I use c arrays in such way tab[-1] or tab[-1][-1]
> > (I mean when index is below zero)?

>
> > Also - I think if try to use some way of optimization
> > where instead of checking some edge values like

>
> > if(x>=0 && x<500 && y>=0 && y<500)
> > tab[y][x] = 1;

>
>
>
> > alloc some edge ram and do not bother about x=-1 or x=tab_max_x+1

> Not with actual arrays, but you can with pointers and arrays
> of pointers.
>
>
>
> > but here it would be convenient to cast some pointer ot type
> > tab[500][500] 'into' wider_tab[502][502] in such way that
> > tab[0][0] wolul correspond to wider_tab[1][1]

>
> > (and tab[-1][-1] to wider_tab[0][0])

>
>
>
> > Can I get something like that? (If not I am sad)

>
>
>
> There is much discussion about pointers outside the allocated
> space, such that the offset is inside. In this case, though,
> the pointer is inside the allocated space, such that adding -1
> is still inside.
>
>


you sure i cant do it with some static array[][] cast? I want such syntax tab[][] and also
i need natural coordinates 0-500 for centre plus -1 and 501 for additional border, also I wnt efficiency - adequate simple casting would be the best, though i do anderstand that i should cast on something like tab[502][502]
with somme offset (not tab[500][500]) and then
used it in tab[-1 to 501 included] so I just need recast tab[502][502] a 503 fields further

as to array of pointers with same syntax of usage t[j][i] - is it more efficient or less
(it is very important question and i still not sure)




Philip Lantz 12-20-2012 08:28 AM

Re: Can I tab[-1] ?
 
fir wrote:
> Also - I think if try to use some way of optimization
> where instead of checking some edge values like
>
> if(x>=0 && x<500 && y>=0 && y<500)
> tab[y][x] = 1;
>
> alloc some edge ram and do not bother about x=-1 or x=tab_max_x+1
>
> but here it would be convenient to cast some pointer to type
> tab[500][500] 'into' wider_tab[502][502] in such way that
> tab[0][0] would correspond to wider_tab[1][1] (and tab[-1][-1]
> to wider_tab[0][0])


int wider_tab[501*501+1];
int (*tab)[500] = (int (*)[500])&wider_tab[500+1];

tab[0][0] is wider_tab[501]
tab[1][0] is wider_tab[1001]
tab[500][500] is wider_tab[501*501]
tab[-1][-1] is wider_tab[0]

There is a caveat: It's possible that the standard allows (int [500]) to
have a stricter alignment requirement than (int [502*502]), which would
mean that the cast isn't guaranteed to behave. I'm not convinced that
it's allowed, and even if it is, I am confident that no implementation
actually has such a requirement.

It's also possible that an implementation for x86 in huge model (where
arrays can span multiple segments), or similar architectures, could have
trouble with this, if the compiler was doing some very sophisticated
optimizations based on knowledge of how the array boundaries line up
with with segment boundaries. The normal brute force approach to huge
model shouldn't have any problem with it, though.

glen herrmannsfeldt 12-20-2012 08:59 AM

Re: Can I tab[-1] ?
 
fir <profesor.fir@gmail.com> wrote:
>> fir <profesor.fir@gmail.com> wrote:
>> > Can I use c arrays in such way tab[-1] or tab[-1][-1]
>> > (I mean when index is below zero)?


(snip)

>> > alloc some edge ram and do not bother about x=-1 or x=tab_max_x+1


(snip, then I wrote)
>> Not with actual arrays, but you can with pointers and arrays
>> of pointers.


>> > but here it would be convenient to cast some pointer ot type
>> > tab[500][500] 'into' wider_tab[502][502] in such way that
>> > tab[0][0] wolul correspond to wider_tab[1][1]


>> > (and tab[-1][-1] to wider_tab[0][0])


(snip)

> you sure i cant do it with some static array[][] cast?
> I want such syntax tab[][] and also i need natural coordinates
> 0-500 for centre plus -1 and 501 for additional border,
> also I wnt efficiency - adequate simple casting would be the best,
> though i do anderstand that i should cast on something
> like tab[502][502] with somme offset (not tab[500][500]) and then
> used it in tab[-1 to 501 included] so I just need recast
> tab[502][502] a 503 fields further


In the 1D case, you set a pointer to element 1, then all will
be off by one.

int tab1[503];
int *tab=tab+1;

Now tab[-1] through tab[501] exist. In most cases, the speed should
be the same.

> as to array of pointers with same syntax of usage
> t[j][i] - is it more efficient or less
> (it is very important question and i still not sure)


In the 2D case, you have an array of pointers to arrays, which
you can either generate pointers to existing arrays, or dynamically
allocate them:

int **tab2;
tab2=malloc(503*sizeof(*tab2))+1;
for(i=-1;i<502;i++) tab2[i]=malloc(503*sizeof(**tab2))+1;

Often it is done this way to allow for dynamic allocation, and
not for efficiency reasons. It is a little hard to say which is
more efficient, as it depends much on the processor, memory cache,
and instruction overlap.

(Note that -1 through 501 is 503 elements, not 502.)

-- glen


glen herrmannsfeldt 12-20-2012 09:13 AM

Re: Can I tab[-1] ?
 
Philip Lantz <prl@canterey.us> wrote:

(snip)

>> alloc some edge ram and do not bother about x=-1 or x=tab_max_x+1


>> but here it would be convenient to cast some pointer to type
>> tab[500][500] 'into' wider_tab[502][502] in such way that
>> tab[0][0] would correspond to wider_tab[1][1] (and tab[-1][-1]
>> to wider_tab[0][0])


(snip)

> int wider_tab[501*501+1];
> int (*tab)[500] = (int (*)[500])&wider_tab[500+1];


> tab[0][0] is wider_tab[501]
> tab[1][0] is wider_tab[1001]
> tab[500][500] is wider_tab[501*501]
> tab[-1][-1] is wider_tab[0]


> There is a caveat: It's possible that the standard allows (int [500]) to
> have a stricter alignment requirement than (int [502*502]), which would
> mean that the cast isn't guaranteed to behave. I'm not convinced that
> it's allowed, and even if it is, I am confident that no implementation
> actually has such a requirement.


Sometimes it is nice to have something aligned higher than the
normal alignment, such as when using SSE modes that require 16 byte
alignment. In most cases, though, it is up to the programmer to keep
things aligned, not the compiler.

> It's also possible that an implementation for x86 in huge model (where
> arrays can span multiple segments), or similar architectures, could have
> trouble with this, if the compiler was doing some very sophisticated
> optimizations based on knowledge of how the array boundaries line up
> with with segment boundaries.


Yes, but in that case an array of large model pointers is a better choice.

> The normal brute force approach to huge model shouldn't have any
> problem with it, though.


Besides, since the 80386 segments are up to 4GB, and pretty much no
systems support even large model in 32 bit mode.

(Yes, I did much work on the 80286 using arrays of far pointers.)

-- glen

glen herrmannsfeldt 12-20-2012 09:16 AM

Re: Can I tab[-1] ?
 
Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip)

> I'm less confident that using a -1 as an index is guaranteed to work,
> but I think it might be.


I believe it pretty much has to work. The other way around, subtracting
from a pointer to allow the low end of an array to be 1 is not
guaranteed to work, but was used in "Numerical Recipes in C" to make
translation from Fortran to C easier.

> I'm less convinced that it's a good idea, though...


Hard to say.

-- glen

Shao Miller 12-20-2012 09:35 AM

Re: Can I tab[-1] ?
 
On 12/20/2012 03:28, Philip Lantz wrote:
>
> There is a caveat: It's possible that the standard allows (int [500]) to
> have a stricter alignment requirement than (int [502*502]), which would
> mean that the cast isn't guaranteed to behave. I'm not convinced that
> it's allowed, and even if it is, I am confident that no implementation
> actually has such a requirement.
>


Confidence: Agreed.

C11's 6.2.8p4 seems to suggest that possible alignments are really
derived from fundamental types.

It'd seem odd if 'malloc(sizeof (int[502 * 502]))' had to worry about
satisfying the possibility that you might be overallocating, but really
interested in using the storage for an 'int[500]' with a stricter
requirement than an 'int[502 * 502]'.

- Shao Miller

fir 12-20-2012 09:44 AM

Re: Can I tab[-1] ?
 
W dniu czwartek, 20 grudnia 2012 10:16:48 UTC+1 użytkownik glen herrmannsfeldt napisał:
> Robert Wessel <robertwessel2@yahoo.com> wrote:
>
>
> > I'm less convinced that it's a good idea, though...

>
>
> Hard to say.
>


not to much hard to say ;-) it is good

can be usefull as in my example of :

x, y are random coordinates from x: -10 to 650, y: -10 to 500, there are large amounts of them only some are out of 0-640 0-480

you dont want to if(x>=0 && x<640 && y>=0 && y<480) ... on thousands ofthem just need to alloc little more and if you can 'recast' it
you can use natural coordinates (same as with pure method with if() checking/clipping,

so imo it is welcome in c




Shao Miller 12-20-2012 10:11 AM

Re: Can I tab[-1] ?
 
On 12/20/2012 01:25, fir wrote:
> Can I use c arrays in such way tab[-1] or tab[-1][-1] (I mean when index is below zero)?
>


I'd say it depends on the declaration. It is not clear from this
question what the types of 'tab[-1]' or 'tab[-1][-1]' are expected to be.

> Also - I think if try to use some way of optimization
> where instead of checking some edge values like
>
> if(x>=0 && x<500 && y>=0 && y<500)
> tab[y][x] = 1;
>
> alloc some edge ram and do not bother about x=-1 or x=tab_max_x+1
>


I don't see any allocation. Could you share the bit of code that does
the allocation?

> but here it would be convenient to cast some pointer ot type tab[500][500] 'into' wider_tab[502][502]
> in such way that tab[0][0] wolul correspond to wider_tab[1][1] (and tab[-1][-1] to wider_tab[0][0])
>
> Can I get something like that? (If not I am sad)
>


I'd say it depends on the declarations involved. It is not clear if you
are working with an array of pointers or not, for example.

You might or might not be interested in "Multi-Dimensional Array
Simulator" at http://www.iso-9899.info/wiki/Code_snippets

- Shao Miller


All times are GMT. The time now is 02:08 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.