search for: n4527

...much agreement on the matter, so … here again :D LoopDeletion and infinite loops … Currently LoopDeletion bails if non-detectable trip count loops are encountered and that’s fine, there are languages where infinite loops without side effects cannot be removed. If I read the C++ spec right though N4527 (sec 1.10) point 27 says: 27 The implementation may assume that any thread will eventually do one of the following: 27.1 — terminate, 27.2 — make a call to a library I/O function (27.3)— read or modify a volatile object, or (27.4)— perform a synchronization operation or an atomic operation...

...re again :D > > LoopDeletion and infinite loops … > > Currently LoopDeletion bails if non-detectable trip count loops are > encountered and that’s fine, there are languages where infinite loops > without side effects cannot be removed. > > If I read the C++ spec right though N4527 (sec 1.10) point 27 says: > > 27 The implementation may assume that any thread will eventually do one of > the following: > > 27.1 — terminate, > > 27.2 — make a call to a library I/O function > > (27.3)— read or modify a volatile object, or > > (27.4)— perform a...

...Deletion and infinite loops … >> >> Currently LoopDeletion bails if non-detectable trip count loops are >> encountered and that’s fine, there are languages where infinite loops >> without side effects cannot be removed. >> >> If I read the C++ spec right though N4527 (sec 1.10) point 27 says: >> >> 27 The implementation may assume that any thread will eventually do one of >> the following: >> >> 27.1 — terminate, >> >> 27.2 — make a call to a library I/O function >> >> (27.3)— read or modify a volatile...

...loops … >>> >>> Currently LoopDeletion bails if non-detectable trip count loops are >>> encountered and that’s fine, there are languages where infinite loops >>> without side effects cannot be removed. >>> >>> If I read the C++ spec right though N4527 (sec 1.10) point 27 says: >>> >>> 27 The implementation may assume that any thread will eventually do one of >>> the following: >>> >>> 27.1 — terminate, >>> >>> 27.2 — make a call to a library I/O function >>> >>> (...

C 6.3.2.3p7 (N1548) says: A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned) for the referenced type, the behavior is undefined. C++ [expr.reinterpret.cast]p7 (N4527) defines pointer conversions in terms of conversions from void*: An object pointer can be explicitly converted to an object pointer of a different type. When a prvalue v of object pointer type is converted to the object pointer type “pointer to cv T”, the result is static_cast<cv T*>(...

...g>> wrote: > C 6.3.2.3p7 (N1548) says: > A pointer to an object type may be converted to a pointer to a > different object type. If the resulting pointer is not correctly > aligned) for the referenced type, the behavior is undefined. > > C++ [expr.reinterpret.cast]p7 (N4527) defines pointer conversions in terms > of conversions from void*: > An object pointer can be explicitly converted to an object pointer > of a different type. When a prvalue v of object pointer type is > converted to the object pointer type “pointer to cv T”, the result > is...