Kai-Uwe Bux
10/16/2008 8:58:00 AM
James Kanze wrote:
> On Oct 15, 11:14 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
>> acehr...@gmail.com wrote:
>> > On Oct 15, 4:10 am, Sam <s...@email-scan.com> wrote:
>> >> Gernot Frisch writes:
>> >> > the program below workes w/o problems on a GP2X and on
>> >> > the PC, but my PocketPC (using GCC 3.3.3) crashes. Very
>> >> > dissapointing, since I expect some speed boost from it.
>> >> > Thnak you for your help.
>
>> >> > int dx=..; // number of pixels width to draw
>> >> > // one pixel is one unsigned short
>
>> >> > // Get some pointer to the screen to draw a rect
>> >> > unsigned short* pScreen = getColorBuffer(x,y);
>
>> >> There is no "getColorBuffer()" function in the standard C++
>> >> library. Try asking for help on a newsgroup for your
>> >> hardware platform.
>
>> > How about dx, x, y, etc. Should the poster go elsewhere
>> > because they are not in the standard as well? Do you have
>> > problems with people using foo()? Is that standard?
>
>> >> You did not specify your platform-specific word sizes.
>
>> > Why is that needed for the question? If the poster new that
>> > the platform-specific word sizes had anything with it, he
>> > wouldn't be surprised.
>
>> >> Assuming sizeof(short)=2, and sizeof(long)=4, the above
>> >> math does not add up. Again, has nothing to do with C++,
>> >> the language.
>
>> > Do you know much about the C++ language? Are you claiming
>> > that sizeof applied to types or their comparisons are not
>> > on-topic here?
>
>> I did not read that in that part you quoted.
>
>> > Your releasing steam is off-topic here.
>
>> Hm, the posting from Sam does not sound very aggressive, as
>> opposed to yours.
>
> His posting was presumptuous, and just noise, and of no help to
> anyone.
>
>> >> You can get a more definitive answer on a more appropriate
>> >> newsgroup.
>
>> > This is an appropriate newsgroup. Why seek more?
>
>> Because the topical answer to the OP is that the cast
>
>> unsigned long* pScLong = (unsigned long*)pScreen;
>
>> and the following usage of pScLong is undefined behavior. That
>> answer is clearly not helpful
>
> Isn't it? It's certainly a necessary starting point: the code
> was illegal, and if it worked on some platforms, it was just by
> accident.
The "accident" is probably what is important.
> One might also point out why it was decided that this should be
> undefined behavior. General considerations about alignment,
> etc., are also on topic here.
That was is Sam's posting.
> Presumably, of course, the problem is due to the fact that on
> some platforms, long requires more strict alignment than short,
> and that his original short* didn't meet those requirements. On
> an Intel processor, this will slow things up considerably, but
> the code will stil run; on most processors, alignement errors
> will result in a hardware trap, which the system maps into a
> core dump or something similar.
>
>> but all that the standard has to say about his program.
>> Therefore, looking for answers elsewhere is a good idea.
>
> No. His problem is pure C++,
I beg to differ. His problem, the way I understand it, is to write code that
works on the target platform. If that involves undefined behavior, so be
it. Why the particular code he proposes breaks is a matter of how the
platform defines the behavior left undefined by the standard. Also, what
possible fixes there are (to improve the speed) is platform specific.
> and I don't know where else he should look.
Neither do I. But that does not imply that there is no better place.
> The fact that he gets the original pointer from a
> function which is not in the standard is completely irrelevant
> (but the names do help us understand the context, and why he is
> trying to do this).
True. But what the OP is trying to do with that pointer gives us a clue that
alignment is probably at the heart of the matter. What alignment
requirements he actually has, is platform specific.
Best
Kai-Uwe Bux