- mixing compilers (g++ but Intel others)? - 22 Updates
- efficiency of std::vector versus std::map - 3 Updates
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 01 12:38AM +0100 > sizeof(long) in our supposed case. Sizes of integers must be multiples > of sizeof(char), so it seems to me to be highly improbable that padding > is an issue. You are confusing padding bytes (which are not relevant here) and padding bits which are. By the way, sizeof(char) is always 1 so all types have a size which is a multiple of sizeof(char). > type, the bytes of the object representation that do not correspond to > that member but do correspond to other members take unspecified > values". That's about padding bytes which are not relevant here. There is no question that the char array exactly overlaps the bytes that make up the other member. That has never been in doubt. Although even a union can have padding bytes these must be at the end and will therefore not play any role in either version of this code. All three of (void *)&u, (void *)u.bytes and (void *)&u.value must compare equal. This issue is with padding bits -- these are bits that are part of the integer type itself but that do not contribute to the value. For example, some (old) Unisys machines have sizeof(unsigned) == 6 (48 bits since CHAR_BIT was 8) but the range of values is 0 to 2^39-1. That's 9 bits that are part of the type but which don't contribute to the value. You can't ever be sure what these bits are, and you can't set them by setting the value. Setting u.value to 1 might set some or all or none of the non-value bits, and if any of these happen to be where u.bytes[0] is, the reported endianess (using Jerry's version) could well be wrong. Setting the representation and then printing the value avoids this problem though not the one of trap representations. <snip> -- Ben. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 01 12:53AM +0100 On Sun, 01 May 2016 00:38:38 +0100 > Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes: [snip] > version) could well be wrong. > Setting the representation and then printing the value avoids this > problem though not the one of trap representations. OK, thanks for the interesting explanation, which seems to be consistent with §6.2.6.2/1 (I think). Making this undefined behaviour as in the case of C++ may be the easier option. Chris |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 01 01:17AM +0100 > consistent with §6.2.6.2/1 (I think). > Making this undefined behaviour as in the case of C++ may be the easier > option. Why is it undefined in C++? (I'm, not that familiar with the C++ standard.) -- Ben. |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 30 10:52PM -0400 On 4/30/2016 12:05 PM, Chris Vine wrote: > The sizeof operator references the size of char, not the size of an > octet (8 bits). sizeof(char) is required to evaluate to 1 in both the > C and C++ standards. The sizeof operator references the number of bytes in whatever you are referencing. Since a char is defined as one byte, sizeof also returns the number of characters, and the size of the array will contain the same number of bytes as the short variable. > majority of systems. You ought to put a -std=c99 or -std=c11 compiler > flag in though, as reading a different union member than the one last > stored gives undefined behaviour with C89 (but not C99/C11). A short could be 2, 4, 8 or 42 bytes. But please show me ANY compiler where the sizeof(short) is only one bytes. Even on the 8088 it was 2 bytes. Maybe the 8008? Nope, even that was 2 bytes long. In fact, I can't find ANY compiler/hardware where the sizeof(short) is less than 2 bytes. And you're correct - I probably should have used -std. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 30 10:53PM -0400 On 4/30/2016 3:31 PM, David Brown wrote: > But Jerry's program would not work since sizeof(short) == 1, and of > course it would not work for cross-platform development and embedded > targets. Ah, David. Once again you try to change the rules rather than admit you are wrong... It doesn't work. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 30 11:01PM -0400 On 4/30/2016 3:21 PM, David Brown wrote: >> } > That is runtime only - it does not generate a constant expression. And > it is not portable to systems where sizeof(short) == 1. And it is used in the compile of the desired program. And name ONE system where sizeof(short) == 1. Of course, even if you could, you can replace short with int, long, long long... The fact is the concept works. And you said it couldn't be done. > That is entirely dependent on the definition of BIGENDIAN or > LITTLEENDIAN in the compiler and/or <stdio.h> on the system, and > therefore does not qualify. Not at all. But you didn't read very well. > etc. > But while that is very practical, and covers most of /my/ needs, it is > not portable and not based solely on the requirements of the C standards. Ah, but that's not portable, is it? > Similarly, operating systems and C libraries may also define symbols for > endianness, but again they are not portable and defined by the C standards. Exactly. This one is portable. The worst you might have to do is recompile endian.c on the target system. > of a simple problem, and are far more interesting in making yourself > sound important by insulting and patronising others than you are in > dealing with the issues at hand. The requirement was to determine at compile time whether the system is big endian or little endian. There were no other restrictions placed on it. This satisfies that requirement. But I knew you wouldn't admit you are wrong. > time at IBM was around the period when IBM was known as one of the most > inefficient organisations on the planet - and with consultants with your > attitudes, it's no surprise. It's a common type of problem that consultants have to solve because employees just say "it can't be done". > would explain why it cannot be done, but how we could instead find an > acceptable change in the requirements that would lead to a simple and > reliable solution. Once again you are changing the rules. It doesn't work. > But thank you for confirming our suspicions here. I haven't read the > rest of the group's replies to your post here, but it will be fun trying > to see you wiggle out of this piece of blatant nonsense. Yes, thank you for confirming my suspicions. You are a complete idiot who is totally unable to admit you are wrong. And you obviously did NOT understand the solution - which works according to YOUR ORIGINAL RULES. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 30 11:03PM -0400 On 4/30/2016 5:36 PM, Chris Vine wrote: > shell command for the purpose. > His solution was unix specific and (so far as concerns the -D option) > dependent on a compiler such as gcc or clang which supports it. Every compiler supports some method of defining precompiler constants in the command line. With gcc, it is -D. That's common in others, also. And while the $(./endian) is *nix specific, there are similar ways to do it in other OS's. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| David Brown <david.brown@hesbynett.no>: Apr 26 10:12PM +0200 On 26/04/16 16:33, Jerry Stuckle wrote: > Then why aren't Microsoft generated object files compatible with Watcom > generated object file, and neither were compatible with Borland > generated object files? But all of the libraries were. Perhaps this is because Microsoft and their OS's have always gone their own way - they don't use the ABI's that the *nix world usually agrees on for different processors. In fact, MS has generally failed to define a decent ABI at all, outside the context of shared libraries (DLL's) and older systems such as the INT calls in DOS, so that each tool vendor made their own calling conventions. I am not convinced that static libraries created by different compilers such as Watcom and Borland tools on Windows /are/ compatible - I certainly won't take your word alone on it. But I have not tried mixing such libraries, so neither can I say that it is not the case. > And why can't you use a Linux object file on a Windows machine, and vice > versa? They have a different object file format, and different ABIs, obviously. But you would have a fair chance of getting object file compatibility between Linux and FreeBSD or Solaris on the same target cpu. |
| David Brown <david.brown@hesbynett.no>: Apr 26 10:22PM +0200 On 26/04/16 16:39, Jerry Stuckle wrote: > the C calling convention is only usable by a few languages, the most > common being C and C++. > That's why system libraries use the PASCAL calling convention - on all OS's. System libraries on all OS's use PASCAL calling convention, do they? I am sure a lot of *nix developers will be surprised to hear about that. You might also want to re-write the entire Wikipedia page on x86 calling conventions: <https://en.wikipedia.org/wiki/X86_calling_conventions> |
| Ian Collins <ian-news@hotmail.com>: May 01 04:58PM +1200 On 05/01/16 14:52, Jerry Stuckle wrote: > A short could be 2, 4, 8 or 42 bytes. But please show me ANY compiler > where the sizeof(short) is only one bytes. Plenty of DSPs. -- Ian Collins |
| Christian Gollwitzer <auriocus@gmx.de>: May 01 10:11AM +0200 Am 30.04.16 um 23:29 schrieb Chris Vine: > [...] > I also filed it away in my mind for the future because > I thought it was quite clever. It is similar to using autoconf for setting up the buid environment, howver autoconf is more elaborate (unsurprisingly). > There are configuration macros available on most systems which will > give you endianness and they wouldn't work either when cross-compiling, http://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/c.m4#n1536 This method also works for crosscompilers. First, a number of known macros is checked. If that does not lead to conclusion, and no cross-compilation, a program like Jerry's is executed http://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/c.m4#n1638 with reference to Harbison&Steele. If cross-compiling, a string is embedded as a constant and the object file is analysed. > so I didn't particularly want to hold that one against him: on this > point I thought he dug himself out of a hole quite well. It is a practical method in the sense that it will work under many circumstances, but it doesn't solve the challenge as such. Christian |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 01 10:44AM +0100 Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> > referencing. Since a char is defined as one byte, sizeof also returns > the number of characters, and the size of the array will contain the > same number of bytes as the short variable. <snip> > A short could be 2, 4, 8 or 42 bytes. (As you probably know, other numbers are possible -- is that what the 42 at the end is saying? I know of C compilers were sizeof(short) == 1 and sizeof(short) == 6.) > But please show me ANY compiler > where the sizeof(short) is only one bytes. Why are you ignoring the examples you have been given? The link I posted was to the C compiler's user guide direct from TI -- the manufacturer of the chip. Do you doubt its veracity? But even if it could be proved that there never was such a C compiler, why assume that there never will be? <snip> -- Ben. |
| David Brown <david.brown@hesbynett.no>: May 01 03:58PM +0200 On 01/05/16 05:03, Jerry Stuckle wrote: >> dependent on a compiler such as gcc or clang which supports it. > Every compiler supports some method of defining precompiler constants in > the command line. With gcc, it is -D. That's common in others, also. While most compilers have such support, and -D is probably the most common method, I don't believe it is correct to say all compilers have such a method. I certainly know of two compilers I have used that don't have such support. > And while the $(./endian) is *nix specific, there are similar ways to do > it in other OS's. The challenge - as clearly stated in an earlier post - was to handle this in a completely compile-time and implementation-independent manner. Using a separate program is not compile-time, and using features of certain implementations - even if those features are very common - is not implementation-independent. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 11:19AM -0400 On 5/1/2016 12:58 AM, Ian Collins wrote: >> A short could be 2, 4, 8 or 42 bytes. But please show me ANY compiler >> where the sizeof(short) is only one bytes. > Plenty of DSPs. Yes? Name one. I don't know of any DSP's where a short is 1 byte. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 11:20AM -0400 On 5/1/2016 5:44 AM, Ben Bacarisse wrote: > But even if it could be proved that there never was such a C compiler, > why assume that there never will be? > <snip> Why do you insist on throwing up red herrings? You just can't admit I showed you something you didn't think could be done. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 11:24AM -0400 On 5/1/2016 9:58 AM, David Brown wrote: > common method, I don't believe it is correct to say all compilers have > such a method. I certainly know of two compilers I have used that don't > have such support. And exactly which compilers don't? > Using a separate program is not compile-time, and using features of > certain implementations - even if those features are very common - is > not implementation-independent. The syntax can change, but the concept works with any compiler. In fact, I dare you to show ANY compilation which is completely independent. Not every one uses "gcc" as the compiler command, for instance. And not all of them use -o for output. So once again you are trying to change the rules rather than admit you are wrong. It doesn't work. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Gareth Owen <gwowen@gmail.com>: May 01 07:30PM +0100 >>> where the sizeof(short) is only one bytes. >> Plenty of DSPs. > Yes? Name one. I don't know of any DSP's where a short is 1 byte. Numerous people have named many already. The TI C2000 Micro is the most commonly cited. It's certainly true of the Piccolo DSP with TI's CCS compiler suite. |
| Gareth Owen <gwowen@gmail.com>: May 01 07:42PM +0100 > Numerous people have named many already. > The TI C2000 Micro is the most commonly cited. > It's certainly true of the Piccolo DSP with TI's CCS compiler suite. And here's TI's docs for you to pretend don't exist: http://processors.wiki.ti.com/index.php/Byte_Accesses_with_the_C28x_CPU "The TMS320C28x byte is 16 Bits. By ANSI/ISO C definition, the sizeof operator yields the number of bytes required to store an object. ANSI/ISO further stipulates that when sizeof is applied to char, the result is 1. Since the TMS320C28x char is 16 bits (to make it separately addressable), a byte is also 16 bits. This yields results you may not expect; for example, size of (int) == 1 (not 2). It should also be noted that contrary to common usage, a byte is not defined as 8 bits. A byte is defined as the unit of data capable of holding a single character on any given machine. Hence, if the term "byte" is used on C2000 it refers to 16 bits. In summary: TMS320C28x bytes and words are equivalent (16 bits)." |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 01 07:42PM +0100 >> why assume that there never will be? >> <snip> > Why do you insist on throwing up red herrings? I keep bringing up these issues because you won't address them. If they are indeed red-herrings, just say that you don't care about these problems. Whilst it's fine to say that don't care about padding bits or systems with odd sizes for types like short, you seem to think that padding bits are something to do with union or struct padding, and you still seem to think there are no systems with sizeof(short) == 1, despite the evidence. > You just can't admit I > showed you something you didn't think could be done. Of course what you posed can be done. It's a common technique (for example see[1] where I posted almost exactly the same code in 2011). What's hard is to do it without making implementation dependent assumptions. [1] Message-ID: <0.0167e5347a17543f93aa.20110617120946BST.87k4ck7lz9.fsf@bsb.me.uk> -- Ben. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 03:23PM -0400 On 5/1/2016 2:30 PM, Gareth Owen wrote: > Numerous people have named many already. > The TI C2000 Micro is the most commonly cited. > It's certainly true of the Piccolo DSP with TI's CCS compiler suite. So, if it's a single byte, then there is no difference between big endian and little endian, is there? They're the same thing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 03:28PM -0400 On 5/1/2016 2:42 PM, Ben Bacarisse wrote: > padding bits are something to do with union or struct padding, and you > still seem to think there are no systems with sizeof(short) == 1, > despite the evidence. No, they are nothing more than red herrings. In the future there could be a 42 bit char, for instance. Or a 93 bit short. Either will break numerous current programs. If you can predict what will happen in the future, you should be playing the lottery. > What's hard is to do it without making implementation dependent > assumptions. > [1] Message-ID: <0.0167e5347a17543f93aa.20110617120946BST.87k4ck7lz9.fsf@bsb.me.uk> There are no implementation dependent assumptions. It is a technique which works. But you just can't admit I showed you something you said couldn't be done. It doesn't matter what you showed 5 years ago. But I've seen the same thing from several people in this newsgroup. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| David Brown <david.brown@hesbynett.no>: May 01 09:45PM +0200 On 01/05/16 05:01, Jerry Stuckle wrote: > And it is used in the compile of the desired program. And name ONE > system where sizeof(short) == 1. Of course, even if you could, you can > replace short with int, long, long long... Others have already mentioned such systems - but as usual, you are unaware of any processors outside your limited experience. > The fact is the concept works. And you said it couldn't be done. Within its limitations, your concept will work. Unfortunately, those limitations render it totally useless (since whenever you have these limitations, there are other ways to figure out endianness). And you failed to solve the stated problem. >> But while that is very practical, and covers most of /my/ needs, it is >> not portable and not based solely on the requirements of the C standards. > Ah, but that's not portable, is it? That is why I wrote "it is not portable". I can appreciate that you are unable to remember what was written a few posts back, but hopefully you can read a couple of lines before losing track. And your suggestion is not portable either. A great deal of C programming - perhaps most C programming these days - is cross-compilation for embedded systems. Clearly your suggestion fails there. Checking __BYTE_ORDER__ works on a fair number of practical systems, and many compilers that don't have that particular pre-defined macro have similar ones. > The requirement was to determine at compile time whether the system is > big endian or little endian. There were no other restrictions placed on > it. This satisfies that requirement. Read again. > But I knew you wouldn't admit you are wrong. As I said, I would have liked to have had a real solution - but a limited form of autoconfig is not particularly useful to anyone. (Admittedly your solution is a lot easier to use that autoconfig!) >> attitudes, it's no surprise. > It's a common type of problem that consultants have to solve because > employees just say "it can't be done". It's a problem that can't be solved as stated - but perhaps that won't stop some consultants from selling their "services" nonetheless. >> acceptable change in the requirements that would lead to a simple and >> reliable solution. > Once again you are changing the rules. It doesn't work. Again, please re-read the requirements. > who is totally unable to admit you are wrong. > And you obviously did NOT understand the solution - which works > according to YOUR ORIGINAL RULES. Again, please re-read the requirements. Of course I was already aware of methods like yours - both the run-time detection, and using a host program to find the endianness of the host, and of using a program to affect the compilation of other programs. I admit that I had not considered your particular method - generating an output that is then used as a command-line define for other compiles. But that is because it is inefficient, non-portable, and interacts badly with other tools such as editors. But it certainly was not an innovative or imaginative solution - it's just that /if/ that had been at all useful, then it would have been better to have the first program generate an include file for the second program. |
| Lynn McGuire <lmc@winsim.com>: Apr 30 10:17PM -0500 On 4/28/2016 8:48 PM, Daniel wrote: > entries. Make sure that the time to reallocate isn't spent doing copies > rather than moves. > Daniel Thanks, Lynn |
| Lynn McGuire <lmc@winsim.com>: Apr 30 10:18PM -0500 On 4/29/2016 12:31 AM, Paavo Helde wrote: > profile it first to find out bottlenecks. > HTH > Paavo Thanks, Lynn |
| Lynn McGuire <lmc@winsim.com>: Apr 30 10:18PM -0500 On 4/29/2016 1:06 AM, Marcel Mueller wrote: > 127) outperform std:map by far. Unfortunately there is no B-Tree in the > std:: namespace. > Marcel Thanks, Lynn |
| 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