Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #71288
Show key headers only | View raw
Tiib writes: > On Friday, 29 November 2019 01:45:04 UTC+2, Tim Rentsch wrote: > >> Tiib <ootiib@hot.ee> writes: >> >>> On Monday, 18 November 2019 08:52:27 UTC+2, Bonita Montero wrote: >>> >>>>>>> Nonsense. What is aligned or misaligned is up to compiler >>>>>>> itself to decide. >>>>>> >>>>>> Wrong. If you pack your members tighter than alignof(membertype) >>>>>> allows this is not conforming. >>>>> >>>>> That is a bald and groundless assertion. >>>> >>>> "Object types have alignment requirements (6.9.1, 6.9.2) which place >>>> restrictions on the addresses at which an object of that type may be >>>> allocated. ... >>> >>> ... >>> The alignment required for a type might be different when it is used >>> as the type of a complete object and when it is used as the type of >>> a subobject. >>> ... >> >> No it cannot. Refer to n4659, section 6.11, paragraph 1. Note >> in particular the last sentence, which says in part (with my >> emphasis added): >> >> An object type imposes an alignment requirement on EVERY >> OBJECT of that type >> >> There is no provision for the alignment varying according to >> whether the object is a complete object or a subobject. > > Very next paragraph #2 says that: > "The alignment required for a type might be different when it is used > as the type of a complete object and when it is used as the type of > a subobject." So it does. Interesting. (It happens that in the document I consulted, these two paragraphs were split by a page boundary, which makes the second paragraph easy to miss. It would be better to have the two conflicting statements be in a single paragraph.) I note that the example relies on virtual base classes. This explains why the special case is there. ISTM that having the two cases be different is poorly thought out, as it makes the notion of alignment be almost meaningless. But, that's C++ for ya.
Back to comp.lang.c++ | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:44 -0800
Re: std::atomic<T>::is_lock_free() Öö Tiib <ootiib@hot.ee> - 2019-11-28 16:43 -0800
Re: std::atomic<T>::is_lock_free() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 06:41 -0800
csiph-web