mirror of
https://gitlab.kitware.com/vtk/vtk-m
synced 2024-09-16 17:22:55 +00:00
Slight comment changes
This commit is contained in:
parent
647bc94fed
commit
6ccb32d27b
@ -216,16 +216,18 @@ struct AllTriviallyDestructible<T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11
|
|||||||
// reinterpret_cast. However, doing that leads to undefined behavior. The C++ compiler assumes that
|
// reinterpret_cast. However, doing that leads to undefined behavior. The C++ compiler assumes that
|
||||||
// 2 pointers of different types point to different memory (even if it is clear that they are set
|
// 2 pointers of different types point to different memory (even if it is clear that they are set
|
||||||
// to the same address). That means optimizers can remove code because it "knows" that data in one
|
// to the same address). That means optimizers can remove code because it "knows" that data in one
|
||||||
// type cannot affect data in another type. To safely change the type of an std::aligned_union,
|
// type cannot affect data in another type. (See Shafik Yaghmour's excellent writeup at
|
||||||
// you really have to do an std::memcpy. This is problematic for types that cannot be trivially
|
// https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8 for more details.) To safely
|
||||||
// copied. Another problem is that we found that device compilers do not optimize the memcpy
|
// change the type of an std::aligned_union, you really have to do an std::memcpy. This is
|
||||||
// as well as most CPU compilers. Likely, memcpy is used much less frequently on GPU devices.
|
// problematic for types that cannot be trivially copied. Another problem is that we found that
|
||||||
|
// device compilers do not optimize the memcpy as well as most CPU compilers. Likely, memcpy is
|
||||||
|
// used much less frequently on GPU devices.
|
||||||
//
|
//
|
||||||
// Part of the trickiness of the union implementation is trying to preserve when the type is
|
// Part of the trickiness of the union implementation is trying to preserve when the type is
|
||||||
// trivially constructible and copyable. The trick is that if members of the union are not trivial,
|
// trivially constructible and copyable. The trick is that if members of the union are not trivial,
|
||||||
// then the default constructors are deleted. To get around that, a non-default constructor is
|
// then the default constructors are deleted. To get around that, a non-default constructor is
|
||||||
// added, which we can use to construct the union for non-trivial types. Working with types with
|
// added, which we can use to construct the union for non-trivial types. Working with types with
|
||||||
// non-trivial destructors are particularly trick. Again, if any member of the union has a
|
// non-trivial destructors are particularly tricky. Again, if any member of the union has a
|
||||||
// non-trivial destructor, the destructor is deleted. Unlike a constructor, you cannot just say to
|
// non-trivial destructor, the destructor is deleted. Unlike a constructor, you cannot just say to
|
||||||
// use a different destructor. Thus, we have to define our own destructor for the union.
|
// use a different destructor. Thus, we have to define our own destructor for the union.
|
||||||
// Technically, the destructor here does not do anything, but the actual destruction should be
|
// Technically, the destructor here does not do anything, but the actual destruction should be
|
||||||
|
@ -156,16 +156,18 @@ struct AllTriviallyDestructible<$type_list(max_expanded), Ts...>
|
|||||||
// reinterpret_cast. However, doing that leads to undefined behavior. The C++ compiler assumes that
|
// reinterpret_cast. However, doing that leads to undefined behavior. The C++ compiler assumes that
|
||||||
// 2 pointers of different types point to different memory (even if it is clear that they are set
|
// 2 pointers of different types point to different memory (even if it is clear that they are set
|
||||||
// to the same address). That means optimizers can remove code because it "knows" that data in one
|
// to the same address). That means optimizers can remove code because it "knows" that data in one
|
||||||
// type cannot affect data in another type. To safely change the type of an std::aligned_union,
|
// type cannot affect data in another type. (See Shafik Yaghmour's excellent writeup at
|
||||||
// you really have to do an std::memcpy. This is problematic for types that cannot be trivially
|
// https://gist.github.com/shafik/848ae25ee209f698763cffee272a58f8 for more details.) To safely
|
||||||
// copied. Another problem is that we found that device compilers do not optimize the memcpy
|
// change the type of an std::aligned_union, you really have to do an std::memcpy. This is
|
||||||
// as well as most CPU compilers. Likely, memcpy is used much less frequently on GPU devices.
|
// problematic for types that cannot be trivially copied. Another problem is that we found that
|
||||||
|
// device compilers do not optimize the memcpy as well as most CPU compilers. Likely, memcpy is
|
||||||
|
// used much less frequently on GPU devices.
|
||||||
//
|
//
|
||||||
// Part of the trickiness of the union implementation is trying to preserve when the type is
|
// Part of the trickiness of the union implementation is trying to preserve when the type is
|
||||||
// trivially constructible and copyable. The trick is that if members of the union are not trivial,
|
// trivially constructible and copyable. The trick is that if members of the union are not trivial,
|
||||||
// then the default constructors are deleted. To get around that, a non-default constructor is
|
// then the default constructors are deleted. To get around that, a non-default constructor is
|
||||||
// added, which we can use to construct the union for non-trivial types. Working with types with
|
// added, which we can use to construct the union for non-trivial types. Working with types with
|
||||||
// non-trivial destructors are particularly trick. Again, if any member of the union has a
|
// non-trivial destructors are particularly tricky. Again, if any member of the union has a
|
||||||
// non-trivial destructor, the destructor is deleted. Unlike a constructor, you cannot just say to
|
// non-trivial destructor, the destructor is deleted. Unlike a constructor, you cannot just say to
|
||||||
// use a different destructor. Thus, we have to define our own destructor for the union.
|
// use a different destructor. Thus, we have to define our own destructor for the union.
|
||||||
// Technically, the destructor here does not do anything, but the actual destruction should be
|
// Technically, the destructor here does not do anything, but the actual destruction should be
|
||||||
|
Loading…
Reference in New Issue
Block a user