On 26 January 2011 08:46, Pierre Stirnweiss <pstirnwe...@googlemail.com> wrote:
> Hi Dag,
>
> sorry to nag you again. I have some questions related to the external (made
> internal) dependency for the scheduler (librcps). Was there a reason to copy
> the code inside our repository instead of linking to it as an external lib?
> I have a couple of problems with it. The first problem, which is now solved
> is that the files have a .c extension, although they are c++. I (locally)
> renamed them. However, that fix might not be desirable, the code being from
> external source. In that case I think there is the possibility to add a flag
> to the CMakeList.txt. Tell me what you think is best.
>
> The problem I am now stuck at is coming from this:
>
> 537 int job_compare(const void *a, const void *b) {
> 538 return a - b;
> 539 }
>
> MSVC tells me that the size of const void* is unknown. On looking on the
> web, I see people explaining that since the object type, and therefore size
> is unknown you cannot (at least in msvc) do pointer math on these. There are
> actually some quite heated discussions on the merit of msvc/gcc spawning
> from this, funny.
> Basically it seems that the consensus is to cast the pointer to a char* if
> you want to do pointer arithmetic.
> Now, I am not actually completely sure I understand what is wanted here, but
> I assume this code is basically a: if(job a == job b) return 0 else return
> !0. I guess then that casting the pointers to char* wouldn't affect the
> logic, would it?
That should be the goal here, so return a==b?0:1 would be enough.
I do not know all the context for the question but doing pointer
arithmetic when we dont know how memory pointed by a and b was
allocated, would be risky (is it known that if a was allocated before
b, then a < b?).
--
regards / pozdrawiam, Jaroslaw Staniek
http://www.linkedin.com/in/jstaniek
Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
KDE Software Development Platform on MS Windows (windows.kde.org)
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
