This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> why does this happen? Well, map::value_type (f.i, to) calls > pair<int, int>::pair (L const &, R const &); > which implicitly takes the address of f.i, and loses the unalignedness > information. This can lead to bus errors or silently reading the wrong > memory locations. Ugh. Insert standard complaints about extensions here. > solution0) > do nothing. I think this is unacceptable. In C, it is more obvious when > you are taking the address of something, in C++ it happens much more > quietly. Agreed. > solution1) > packed fields have an unaligned type, and that is propagated through > the type system just as cv-qualifiers are. This will also work for > C, and give allow the user to specify when unaligned objects might be > pointed to. Template deduction will probably have to start deducing > attributes -- bleah! Arguably, this is the best solution -- from a pure language design point of view. I've argued before that alignment attributes should be part of the type, and that "int i" is a subtype of "unaligned int i"; the former can do everything the latter can do, but also supports the "read aligned" and "write aligned" operations. However, I agree that trying to do this in C++ is a mistake -- the language is certainly complex enough as it is. You're entirely correct that figuring how these new types would interact with templates is complicated at best. > solution2) > packed fields are like bitfields. Thus they cannot have their address > taken and they can bind to 'T const &' parameters by invoking > the copy constructor. If they cannot have their address taken, do > we want offsetof (M, packedField) to work or not? I think this is a good solution, at least for now. I think offsetof should still work -- but that requires the offsetof magic that we don't have yet, so, for now, it won't work. That's OK. -- Mark Mitchell <mark@codesourcery.com> CodeSourcery, LLC
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |