The exact choice of memory_order_* is hard, and even for versions that
seem to work on x86_64 TSAN complains like crazy.
TODO: a version that, instead of blocking if another thread is updating,
also does the computation, with suitable protection to ensure that
pruning the tree cannot happen while anyone is computing on it.
TODO: try having AT in Lazy instead of Lazy_rep (i.e. not shared) to
avoid the indirection. We can possibly choose one or the other depending
on the type.
Freie Universitaet Berlin (Germany), Martin-Luther-University Halle-Wittenberg
(Germany) and RISC Linz (Austria) as they transfer the copyright to other
sites.
by namespace CGAL { and } //namespace CGAL. in all .h and .cpp files
in a directory.
Apply it to all packages in the trunk
Remove macro definition from the config.h file.
Laurent Rineau (GeometryFactory) wrote:
> On Wednesday 29 July 2009 14:05:41 Sylvain Pion wrote:
>> Laurent Rineau (GeometryFactory) wrote:
>>> One GF customer reported the following issue:
>>>
>>> "For 64bit compilation, we get the disturbing warning
>>>
>>> ..\Third_Party_Libraries\CGAL\include\CGAL/Handle.h(90) : warning C4311:
>>> 'reinterpret_cast' : pointer truncation from 'CGAL::Rep *const ' to
>>> 'unsigned long'
>>>
>>> which looks like a real 64bit issue."
>>>
>>> and he is right. Here is the code:
>>>
>>> inline
>>> bool
>>> identical(const Handle &h1, const Handle &h2)
>>> { return reinterpret_cast<unsigned long>(h1.PTR) ==
>>> reinterpret_cast<unsigned long>(h2.PTR); }
>>>
>>>
>>> "unsigned long" is not the right type! On 32 bits machine, that type is
>>> too long, and on x64 under Windows, that type is too short!
>> Indeed...
>>
>>> See http://en.wikipedia.org/wiki/LLP64#Specific_data_models
>>>
>>> We need uintptr_t from C99, because that type is defined as the fastest
>>> unsigned integral type that is convertible from void pointers and
>>> comvertible to void pointers, without truncation.
>>>
>>> However, that type is not yet in the C++ norm, and some platforms may not
>>> have it. We will probably need some macro stuff:
>>> - use C++0x if possible,
>>> - fallback to plain C99 headers,
>>> - then fallback to platform specific typedefs.
>>>
>>> Is that the correct solution?
>> For the identical() function above, why don't we simply compare
>> the pointers without doing the casts to unsigned long at all ?
>>
>> Nevertheless, the problem exists in the id() function (and this
>> function is probably less useful...).
>> What about returning std::ptrdiff_t with {return h.PTR -
>> static_cast<Ref*>(0);} ?
>
> Yes. That might be a good cross-platform solution for id(). I will commit that
> in the trunk. And identical() will be a.id()==b.id().
Why not just h1.PTR == h2.PTR for identical() ?
So, let's go and break the trunk! ;-)
I have a least compiled and run test/Kernel_23/Lazy_kernel.cpp
Laurent Rineau
Giles Bathgate
Marc Glisse
Andreas Fabri
Sébastien Loriot
Guillaume Damiand
Sébastien Loriot
Fernando Cacciola
Laurent Rineau
Sylvain Pion