- how to specify an 8 byte bool ? - 9 Updates
- attempt to dereference a singular iterator - 1 Update
| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 05 07:16PM -0500 On 10/5/2022 5:27 PM, Scott Lurndal wrote: >> I don't understand your comment, unless you're using byte offsets >> intead of normal fortran indexing. > Ah never mind, I see your aliasing the same storage four ways. Yup. Thanks, Lynn |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Oct 05 06:45PM -0700 On Wednesday, October 5, 2022 at 5:20:09 PM UTC-4, F.Zwarts wrote: > So, I would probably go for an array of unions. Where each union is a > union of a double, integer, bool and char[8]. The bool would then > automatically use the space of the largest type in the union. I think it would be undefined behaviour to use a C++ union for a FORTRAN EQUIVALENCE statement. C++ (unlike C) does not permit type pruning. Daniel |
| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 05 09:05PM -0500 > I think it would be undefined behaviour to use a C++ union for a FORTRAN > EQUIVALENCE statement. C++ (unlike C) does not permit type pruning. > Daniel I assume that you mean type punning ??? https://en.wikipedia.org/wiki/Type_punning Lynn |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Oct 05 07:07PM -0700 On Wednesday, October 5, 2022 at 10:05:48 PM UTC-4, Lynn McGuire wrote: > I assume that you mean type punning ??? > https://en.wikipedia.org/wiki/Type_punning > Lynn Just so :-( Daniel |
| "Fred. Zwarts" <F.Zwarts@KVI.nl>: Oct 06 10:39AM +0200 >> automatically use the space of the largest type in the union. > I think it would be undefined behaviour to use a C++ union for a FORTRAN > EQUIVALENCE statement. C++ (unlike C) does not permit type pruning. I did not read that type punning was used in this Fortran program. |
| David Brown <david.brown@hesbynett.no>: Oct 06 02:14PM +0200 >> automatically use the space of the largest type in the union. > I think it would be undefined behaviour to use a C++ union for a FORTRAN > EQUIVALENCE statement. C++ (unlike C) does not permit type pruning. I think "type pruning" sounds more fun than mere "type punning". It sounds like a way to clear up a mess of too many types, leaving only the pretty ones :-) I guess the answer here is a class which has a single storage unit (uint64_t) with constructors and conversion operators to the different types, using memcpy() to make it all legal. A decent compiler will optimise away the memcpy(). Alternatively, if you can limit yourself to gcc, clang, icc, and other compilers that copy gcc's attributes, the "may_alias" attribute on a type lets you use it for type punning (it gives the type the superpowers of a character type for accesses). #include <cstdint> #include <cstring> #include <array> class DIBC { private : uint64_t storage; template <class T> constexpr uint64_t toUint64_t(const T x) { static_assert(sizeof(x) == 8); uint64_t y; std::memcpy(&y, &x, 8); return y; } template <class T> constexpr T fromUint64_t(uint64_t x) { static_assert(sizeof(T) == 8); T y; std::memcpy(&y, &x, 8); return y; } public : using char8 = std::array<char, 8>; constexpr DIBC() : storage(0) {} constexpr DIBC(uint64_t x) : storage(x) {} constexpr DIBC(int64_t x) : storage(x) {} constexpr DIBC(bool x) : storage(x) {} constexpr DIBC(char8 x) : storage(toUint64_t(x)) {} constexpr operator uint64_t() const { return storage; } constexpr operator int64_t() const { return storage; } constexpr operator bool() const { return storage; } constexpr operator char8 const () { return fromUint64_t<char8>(storage); } }; |
| David Brown <david.brown@hesbynett.no>: Oct 06 02:16PM +0200 On 05/10/2022 21:10, Lynn McGuire wrote: > I forgot to mention that this is how I handle the 8 byte logical*8 right > now: > typedef long long logical8; You should prefer the sized types here - int64_t or uint64_t. People can - and have - argue endlessly about the pros and cons of different types. But when you know you need a precise size, and anything else would be wrong, then it is best to specify that. |
| scott@slp53.sl.home (Scott Lurndal): Oct 06 02:03PM >> automatically use the space of the largest type in the union. >I think it would be undefined behaviour to use a C++ union for a FORTRAN >EQUIVALENCE statement. C++ (unlike C) does not permit type pruning. In theory, but not necessarily in practice. It works just fine with g++. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 06 03:07PM -0500 On 10/6/2022 7:16 AM, David Brown wrote: > can - and have - argue endlessly about the pros and cons of different > types. But when you know you need a precise size, and anything else > would be wrong, then it is best to specify that. Yeah, I have been thinking about changing f2c to use that. Since it uses its own definitions in f2c.h, anything can be easily changed. f2c is a fairly old software so it has dated types in it. typedef long int integer; typedef unsigned long int uinteger; typedef char *address; typedef short int shortint; typedef float real; typedef double doublereal; typedef struct { real r, i; } complex; typedef struct { doublereal r, i; } doublecomplex; typedef long int logical; typedef short int shortlogical; typedef char logical1; typedef char integer1; typedef long long longint; /* system-dependent */ typedef long long logical8; /* system-dependent */ typedef unsigned long long ulongint; /* system-dependent */ #define fstring fem::str Lynn |
| Juha Nieminen <nospam@thanks.invalid>: Oct 06 06:55AM > I have a problem with preparing minimal complete program: I extracted > problematic code to new test project and I simplified Makefile, but test > project works fine. In that case what you should do is to take the code where the problem happens and start removing small parts of it, checking every time if the problem still happens. If at some point the problem disappears you may have found the problematic code. If that still doesn't help understanding what's going on, continue removing other parts of the code until you can't remove anything without making the problem disappear. Anything that doesn't affect the problem, remove, until you have the minimal amount of code that still exhibits the problem. We don't need any makefile. Just C++ code ought to be enough. (At most you could tell which compiler and compiler options you are using.) |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment