----- Original Message ----- From: "Tim Peters" <tim.one@comcast.net> > > Include/objimpl.h:275: double dummy; /* force worst-case alignment */ > > One branch of a union, forces enough padding in the gc header so that > whatever follows the gc header is "aligned enough". This is sufficient for > all core gc types, but may not be sufficient for user-defined gc types. I'm > happy enough to view it as a restriction on what user-defined gc'able types > can contain. As I read the code, it affects all types (doesn't this header begin every object, regardless of its GC flags?) and I think that's a very unhappy circumstance for your numeric community. Remember, the type that raised the alarm here was just a long double. > > At first glance, there appear to be different assumptions at work > > here about what constitutes maximal alignment on any given platform. > > Only the objimpl.h trick might benefit from maximal alignment. I'm not actually after maximal alignment; I look for a minimally-sized/aligned type whose alignment is a multiple of the target type's alignment. In any case, I was just using the assumption that double was maximally aligned since I was linking with Python code and the EDG front-end was too slow to handle the metaprogram -- I figured that if the assumption was good enough for Python and my clients were depending on it anyway, it was good enough for my code (not!). > If you ever compile on a KSR machine, you'll discover there's no std C type > that captures maximal alignment. I was aware that this was a theoretical possibility, but not that it was a practical one. What's KSR? > You'd have to guess it's an extension type > named "_subpage". I'm not sure that even C++ template metaprogramming could > manage that bit of channeling <wink> Nope; we can only look through a list of likely candidates to try to find a match. We're hoping to address this for the next standard -- I'm pushing for allowing non-POD types in unions, leaving construction/destruction up to the user. > (FYI, _subpage required 128-byte > alignment). I guess that strictly speaking, requiring maximal alignment wouldn't be appropriate for objimpl ;-) > Stupid trick: If you can compute this at run time, do malloc(1) a few > times, count the number of trailing 0 bits in the returned addresses, and > take the minimum. Since malloc has to return memory "suitably aligned so > that it may be assigned to a pointer to any type of object and then used to > access such an object or an array of such objects", you'd soon discover you > always got at least 7 trailing zero bits back from KSR malloc(), and > presumably at least 4 under Tru64. Sounds like a good candidate for your autoconf script. Seriously, though, I think it would be reasonable to stick to aligning the standard builtin types, in which can you can do the test without calling malloc, FWIW. > there's-the-standard-and-then-there's-real-life<wink>-ly y'rs - tim in-theory-theory-and-practice-are-the-same-and-to-hell-with-what-happens-in- practice-ly y'rs -Dave
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4