unsigned char pointer

[wallacej]

Does anybody know why

unsigned char myImage[512*480]; works but

unsigned char myImage[1004*1001]; does not?

I think its because the second line is a value too big for unsigned
char, is this correct?

If so:

How do I create this pointer for the size 1004*1001? I have tried
using long, int etc but the image processing function that I pass the
pointer to does not accept this. The function requires me to cast the
unsigned char into a long when I pass the pointer, I don't know if this
is making a difference; as your probably confused heres some code:

unsigned char myImage[512 * 480]; //Size for Halcon image
//unsigned char myImage[1004 * 1001]; //Size for Halcon image ///does
not work////////


//create a Halcon Image to receive output from edge detection
::gen_image1(&imgIPPCannyOut, "byte", dev->nBufferWidth,
dev->nBufferHeight, (long)myImage);

Thank You

 

[Victor Bazarov]

Does anybody know why

unsigned char myImage[512*480]; works but

unsigned char myImage[1004*1001]; does not?

I think its because the second line is a value too big for unsigned
char, is this correct?

No.

<compilerspeicific>
If this is an automatic array, your _stack_ is probably too small to
accommodate that large of an array.
</compilerspeicific>

Try a dynamic one:

unsigned char *myImage = new unsigned char[1004*1001];

just don't forget to dispose of it when you don't need it any longer:

delete[] myImage;

V

 

[Mike Wahler]

Does anybody know why

unsigned char myImage[512*480]; works but

unsigned char myImage[1004*1001]; does not?

Please describe 'work' and 'not work'. How does
your program's behavior (or success/failure of compile)
differ when using each of those definitions?

I think its because the second line is a value too big for unsigned
char, is this correct?

No. The range of a type has no bearing at all upon how
large an array can be. Without more specific description
of 'does not work', I can only make a few guesses:

- Your implementation's type 'size_t' range does not include the
value 1004 * 1001.

- Your arrays above are defined with automatic storage duration
(i.e. at block scope), and 1004 * 1001 is larger than the number
of bytes alloted for automatic objects (can cause many implementations
to issue a 'stack overflow' message.


- Your arrays above are defined with static storage duration
(i.e. at file scope, or at block scope with the 'static' qualifier),
and 1004 * 1001 is larger than the number of bytes alloted for static
storage.

- The moon is in the wrong phase.

If so:

How do I create this pointer for the size 1004*1001?

What pointer? There is no pointer in your example code.
Only arrays.

I have tried
using long, int

It seems to me you're simply guessing, 'shooting in the dark'.
I strongly recommend some books and study/practice time.

etc but the image processing function that I pass the
pointer to does not accept this.

What function? What are its argument types and return type?

The function requires me to cast the
unsigned char

What unsigned char?

into a long

Why? Is one of its paramters type 'long'? If so, why
are you passing an unsigned char?

when I pass the pointer,

What pointer? (Yes, when passed to a function, an array
is converted to a pointer to its first element, but we
cannot know if you're doing things correctly without
some description of the function you're calling (esp.
its signature)).

I don't know if this
is making a difference; as your probably confused heres some code:

unsigned char myImage[512 * 480]; //Size for Halcon image
//unsigned char myImage[1004 * 1001]; //Size for Halcon image ///does
not work////////

Yes, your description does confuse me as to what you're
really asking. And no, that code doesn't help, it's exactly
the same as that near the top of your message. Again, saying
'does not work', helps us help you not at all.

//create a Halcon Image to receive output from edge detection
::gen_image1(&imgIPPCannyOut, "byte", dev->nBufferWidth,
dev->nBufferHeight, (long)myImage);

It's almost certainly a mistake to cast 'myImage' to type long.
What does such a value *mean*?

I suspect you need to do more reading about how to correctly
use the 'gen_image1' function (which part of course isn't topical
here).

-Mike

 

[Default User]

No. The range of a type has no bearing at all upon how
large an array can be.

I'm not sure you said what you meant to say there. The range of a type
is usually closely tied to the size of the type. The size of the type
can affect how large of an aggregate can be created by the
implementation.

The fact that the index can't be contained in the type is of no
consequence, because the array isn't indexed with the base type of the
array.




Brian

 

[Mike Wahler]

I'm not sure you said what you meant to say there.

Perhaps not. Happens to me all the time with women.

The range of a type
is usually closely tied to the size of the type. The size of the type
can affect how large of an aggregate can be created by the
implementation.

Agreed. I suppose I meant to say, rather than (total) 'size
of an array', was 'number of elements in an array' (which is
of course governed by the range of type 'size_t'.)

The fact that the index can't be contained in the type is of no
consequence, because the array isn't indexed with the base type of the
array.

Right. Thanks for trying to help divert any possible misunderstandings
my poor wording may have caused anyone.

-Mike

 

[wallacej]

thanks for your help guys. I have read all of your suggestions and
learnt a great deal, you'll have probably guessed that I'm a bit of an
amateur at C++.

I started working through the list of suggestions in this topic in an
effort to solve my problem and the first suggestion seems to be
working. I created a dynamic array which does the job nicely.
However, my imaging system stops detecting particles after a certain
amount of time/images/particles. I have a feeling I've got a memory
leak somewhere. Anyhow, I'll rig the system up to a controlled test
and if the problem is relevant to this group i'll get back to you guys.

Thanks again

Wallace