- mixing compilers (g++ but Intel others)? - 19 Updates
- std::move_iterator is not a member of 'std'? - 5 Updates
- cout slower than printf - 1 Update
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 11:47PM -0400 On 4/26/2016 4:35 PM, Gareth Owen wrote: > Sun CC (multiple versions), clang, gcc, DEC Alpha CC, DEC f77 and f95. >> Only if both were created with the same compiler. > Wrong. And you were able to link Sun CC object files with DEC Alpha CC programs? If so, the rest of the world would love to know how you did it. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 11:48PM -0400 On 4/26/2016 4:43 PM, Ian Collins wrote: > mix of gcc and Sun cc. Any C compiler on a UNIX or UNIX like system > that didn't use the platform standard ABI would be considered seriously > broken. I never argued about libraries being usable across compilers - they have to be. My comment was restricted to object files. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 11:50PM -0400 On 4/26/2016 5:04 PM, Cholo Lennon wrote: > manufacturers provide similar information): > https://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx > Regards They document part of the information. But they also include this: "Note: This document is provided to aid in the development of tools and applications for Windows but is not guaranteed to be a complete specification in all respects. Microsoft reserves the right to alter this document without notice." And the undocumented parts can be very important. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 11:56PM -0400 On 4/26/2016 5:26 PM, Gareth Owen wrote: > Here are Sun CC's > http://docs.oracle.com/cd/E19683-01/817-3677/6mj8mbtc7/index.html > (surprise! It's ELF) Why should that surprise you when it was Sun which owned the copyright for Unix, and developed the ELF spec? But then they had an ulterior motive for documenting it - they weren't trying to sell a compiler, they were trying to sell an OS. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Apr 27 04:55PM +1200 On 04/27/16 15:48, Jerry Stuckle wrote: >> broken. > I never argued about libraries being usable across compilers - they have > to be. My comment was restricted to object files. So you didn't write "Ah, but the format of the objects in the library are standard. Otherwise you would not be able to call the system libraries from C, PASCAL, FORTRAN, or any of the other languages." Above? -- Ian Collins |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 08:32AM -0400 On 4/27/2016 12:55 AM, Ian Collins wrote: > are standard. Otherwise you would not be able to call the system > libraries from C, PASCAL, FORTRAN, or any of the other languages." > Above? Yes, the format of the object files IN THE LIBRARY are standard. That does not mean they were not changed when being inserted into the library. In fact, they have to be as, among other things external references need to be satisfied. But some people are SO DENSE. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Cholo Lennon <chololennon@hotmail.com>: Apr 27 10:17AM -0300 On 04/27/2016 12:50 AM, Jerry Stuckle wrote: > specification in all respects. Microsoft reserves the right to alter > this document without notice." > And the undocumented parts can be very important. You're right, "due to its history, no one can trust on what Microsoft says" (TM) ;-) Also I have to say that the last document update was on December 29th, 2015 and IMHO it is very complete (The download page is a bit outdated, it refers to version 8.3, but the download link refers to the last version, 9.3) -- Cholo Lennon Bs.As. ARG |
| scott@slp53.sl.home (Scott Lurndal): Apr 27 01:36PM >> library container format. >How many compilers other than gcc have you used on *nix? gcc is not the >only one (and never has been). Let's see: Diab Data, SVR4 CCS, GCC, Intel Compiler, Portland Compiler Group just off the top of my head. |
| scott@slp53.sl.home (Scott Lurndal): Apr 27 01:42PM >> Microsoft has chosen not to support ELF. That's their problem. >But they're supposed to be 32-bit and 64-bit intel standards - not *nix >standards. No, they're Unix standards. Always have been. You can't possibly expect object files to be interoperable between different operating systems, do you? That's never been the case in the history of computing. If microsoft can't be bothered to create a standard for their operating system, that's not their problem. >And what other compilers (non-gcc based, that is) have you used on *nix? V6 C V7 C PCC (w/ cfront 2.1) SVR4 ccs Diab Data C++ and F77 Portland Compiler Group compilers (C, C++, F77) Intel compiler (C++, F77) Gnu compiler (C, C++, F77, ADA) Clang (C++) All of which created compatible, interoperable and interlinkable object files. |
| scott@slp53.sl.home (Scott Lurndal): Apr 27 01:43PM >I never argued about libraries being usable across compilers - they have >to be. My comment was restricted to object files. You continue, perhaps willfully, to misunderstand that libraries _are_ object files on *nix. Period. |
| scott@slp53.sl.home (Scott Lurndal): Apr 27 01:44PM >does not mean they were not changed when being inserted into the >library. In fact, they have to be as, among other things external >references need to be satisfied. You clearly don't know what LIBRARY means in the context of *nix. >But some people are SO DENSE. Irony, thy name is Jerry. |
| David Brown <david.brown@hesbynett.no>: Apr 27 03:57PM +0200 On 26/04/16 22:34, Jerry Stuckle wrote: >> older systems such as the INT calls in DOS, so that each tool vendor >> made their own calling conventions. > So your "standard" is not really a standard, is it? /My/ standard? What do you mean by that? In the *nix world, each different processor ISA has an ABI that covers things like calling conventions, register usage, stack framing, etc. All reasonable compilers for *nix for that target will follow that ABI for their basic function calls and data (i.e., C-like functions and data). The conventions will also cover any necessary data tables or relocation information. When generating externally linkable object files (as distinct from purely internally linkable ones, which might be used for link-time optimisation in compilers), the compiler and/or assembler and/or linker will follow those conventions and formats. When these object files are combined into libraries, the object file format is preserved and some indexing information is added to the archive (following the ABI). In this way, libraries and object files from different compilers can be used together. Note that not everything from object files or libraries is directly usable by different compilers. Of particular relevance for this group, with C++ you get name mangling, class layouts, and so on. That is why most compiled languages have some sort of interface for creating and calling external "C" functions, because those form the standard. Also note that many compilers in the *nix world don't generate object files or executable files - they generate assembly files that are assembled by the /system/ assembler, and the object files are linked by the /system/ linker. They all work together. On Windows, it's a different matter - there is no standard for static linking (only for dynamic linked libraries). So if by "your standard", you mean the *nix ABI's for different targets, then yes, those are /real/ standards. Microsoft, Windows, and many tools on Windows don't follow those standards, and have their own ABI's. That does not make the standards any less real - it just makes Windows a poorer choice for a development platform, especially if you want to combine code from different sources and different tools. > They definitely are. I've used development libraries on Windows which > were created by manufacturers. I don't necessarily know which compiler > was used - but I've used the libraries with different compilers. Usually when I have dealt with development libraries on Windows, they are delivered in DLL format - /dynamic/ libraries, not static libraries. Dynamic libraries follow a fixed format on Windows. >> between Linux and FreeBSD or Solaris on the same target cpu. > But you said it was a 32-bit intel and 64-bit intel standard. If that > were the case, they would be compatible. So obviously that is not true. No, I said no such thing. There is a *nix standard for 32-bit x86 ABI and one for 64-bit x86 ABI (AMD was the main author, not Intel). Non *nix systems on these targets may not follow the same ABI - in particular, Windows does not. |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 11:35AM -0400 On 4/27/2016 9:36 AM, Scott Lurndal wrote: >> only one (and never has been). > Let's see: Diab Data, SVR4 CCS, GCC, Intel Compiler, Portland Compiler > Group just off the top of my head. And you've been able to link object files generated by Diab Data with Portland Compiler generated objects? And other combinations? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 11:37AM -0400 On 4/27/2016 9:44 AM, Scott Lurndal wrote: >> library. In fact, they have to be as, among other things external >> references need to be satisfied. > You clearly don't know what LIBRARY means in the context of *nix. Oh, I do. It looks like better than you do. >> But some people are SO DENSE. > Irony, thy name is Jerry. ROFLMAO! Now you start with the ad hominem attacks. Just like a troll who runs out of legitimate arguments. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 11:38AM -0400 On 4/27/2016 9:43 AM, Scott Lurndal wrote: >> to be. My comment was restricted to object files. > You continue, perhaps willfully, to misunderstand that libraries _are_ > object files on *nix. Period. No, libraries are NOT object files on *nix. But you don't understand the difference. It's like saying object files are just C code. No, the source code is not the same as the object file - although the source code is used to *create* the object file. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 11:51AM -0400 On 4/27/2016 9:57 AM, David Brown wrote: >>> made their own calling conventions. >> So your "standard" is not really a standard, is it? > /My/ standard? What do you mean by that? You're the one who called it a standard. > is preserved and some indexing information is added to the archive > (following the ABI). In this way, libraries and object files from > different compilers can be used together. Sure, the have the same calling conventions, register usage, etc. I never argued that. But the object files do not necessarily have to all follow the same format. And object files are not just placed into library files - there is a significant amount of work which is required besides just copying a.o+b.o+c.o into d.a. The formats are NOT the same (although they may be similar in gcc). > with C++ you get name mangling, class layouts, and so on. That is why > most compiled languages have some sort of interface for creating and > calling external "C" functions, because those form the standard. I didn't say anything about name mangling, class layouts, or anything else along those lines. I am specifically talking about object file formats. You seem to think that object files must have the same format as library files. That is where you are wrong - there is no such requirement (although gcc may do it that way). > files or executable files - they generate assembly files that are > assembled by the /system/ assembler, and the object files are linked by > the /system/ linker. They all work together. ALERT! ALERT! RED HERRING ALERT! This is a whole different story. If they all generate assembler files, then the object files are all created by the same assembler. Please learn to stay on subject. > On Windows, it's a different matter - there is no standard for static > linking (only for dynamic linked libraries). Wrong again. Statically linked libraries are also standard. And that's a good thing, because if you don't want to run through a lot of gyrations loading the dynamic library in your code, you need to link the associated static library (which contains pointers to the dynamic library entry points) into your program. > That does not make the standards any less real - it just makes Windows > a poorer choice for a development platform, especially if you want to > combine code from different sources and different tools. You're the one who said they were 32-bit intel, 64-bit intel, etc. standards, which means they should be applicable to any 32-bit intel OS, 64-bit intel os, etc. So I guess they really aren't "standard". But Windows does fine with linking libraries from multiple different compilers. But once again you show how little you know. > Usually when I have dealt with development libraries on Windows, they > are delivered in DLL format - /dynamic/ libraries, not static libraries. > Dynamic libraries follow a fixed format on Windows. Yes, and they have a static library with them to satisfy your linker. And those also follow a fixed format. > There is a *nix standard for 32-bit x86 ABI and one for 64-bit x86 ABI > (AMD was the main author, not Intel). Non *nix systems on these targets > may not follow the same ABI - in particular, Windows does not. That was not your original statement. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 11:55AM -0400 On 4/27/2016 9:42 AM, Scott Lurndal wrote: >> But they're supposed to be 32-bit and 64-bit intel standards - not *nix >> standards. > No, they're Unix standards. Always have been. That's not what you claimed above. > You can't possibly expect object files to be interoperable > between different operating systems, do you? That's never > been the case in the history of computing. Why not? You claimed they were. > If microsoft can't be bothered to create a standard for their > operating system, that's not their problem. Oh, Windows has standards, and libraries created by one compiler are completely compatible with libraries created by another compiler. But you also have shown your ignorance even on basic compilation and library usage on Windows. > Gnu compiler (C, C++, F77, ADA) > Clang (C++) > All of which created compatible, interoperable and interlinkable object files. I'm not familiar with all of these. but at least two of them are gcc derivatives. And you're saying you can take an object file created with Portland and link it with a program created by Diab? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| scott@slp53.sl.home (Scott Lurndal): Apr 27 05:37PM >> object files on *nix. Period. >No, libraries are NOT object files on *nix. But you don't understand >the difference. You can say that as many times as you wish. Doesn't make it true. All ELF files are object files of one form or another, whether relocatable or not. Even the final executable is an object file, with some (but not all) interobject references resolved. Believe that I've been writing unix /unix-like operating systems for a long, long time and am well aware of how they work. I also sat on the Xopen/Open Group base standards committee for close to a decade as well as on the Unix International committee that specified the DWARF section of the object file standard. And yes, I've linked together objects generated by all the compilers listed in other posts. |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 01:42PM -0400 On 4/27/2016 1:37 PM, Scott Lurndal wrote: >> No, libraries are NOT object files on *nix. But you don't understand >> the difference. > You can say that as many times as you wish. Doesn't make it true. And you can say they are the same as many times as you wish. Doesn't make it true. > All ELF files are object files of one form or another, whether > relocatable or not. Even the final executable is an object file, > with some (but not all) interobject references resolved. Sure. And they are the output of compiled programs - which means they are the same as the source code. Except they aren't. > the Xopen/Open Group base standards committee for close to a decade as well > as on the Unix International committee that specified the DWARF > section of the object file standard. Believe I've been working with unix for probably a lot longer than you have - back around 1979 (although not continuously since that time). As for being on the standards committees - what do you want - an award? They say nothing about your competence. In fact, I've seen several people on these committees I wouldn't hire if they paid me to work for me. > And yes, I've linked together objects generated by all the compilers > listed in other posts. Then there are a lot of programmers in the world who would like to see how you did it. Millions of programmers haven't been able to do so. But then you're the great and powerful OZ. Nothing is impossible for you. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: Apr 27 04:04PM +0200 Hallo, I was searching for a way to move an iterator to a position in a vector and found: move_iterator. E.g.: <http://www.cplusplus.com/reference/iterator/move_iterator/> So I included: #include <iostream> #include <string> #include <vector> #include <iterator> // move_iterator And in a function I wrote: int main(){ typedef std::vector <std::string> tdVec; tdVec::iterator it; tdVec vec; vec.push_back("Hallo"); vec.push_back("ich"); vec.push_back("bin"); vec.push_back("ein"); vec.push_back("Beispiel"); it = vec.begin(); std::move_iterator<it>(2); return 0; } But this gives me an error: 'move_iterator' is not a member of 'std' What can I do? Regards Heinz-Mario Frühbeis |
| Cholo Lennon <chololennon@hotmail.com>: Apr 27 11:23AM -0300 On 04/27/2016 11:04 AM, Heinz-Mario Frühbeis wrote: > But this gives me an error: > 'move_iterator' is not a member of 'std' > What can I do? 'move_iterator' has been available since C++11. Just use a compiler that at least support C++11. Regards -- Cholo Lennon Bs.As. ARG |
| jt@toerring.de (Jens Thoms Toerring): Apr 27 02:32PM > But this gives me an error: > 'move_iterator' is not a member of 'std' > What can I do? std::move_iterator is a C++11 feature and the error message indicates that you tried to compile the progra, without C++11 support enabled. If you're using gcc try to add '-std=c++11' to the compiler options. But then you'll get some further error messages: you can't use 'it' as a template argument, this has to be a type, not some class instance. And then that's not a function call. Moreover, a move iterator isn't something that "moves" an iterator. If you want an iterator to the third element of the vector 'vec' the just use it = vec.begin() + 2; No need for any special kind of object for that - just add or subtract from an iterator to position it to some- where else in the object it's iterating over. Regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
| "Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: Apr 27 04:37PM +0200 Am 27.04.2016 um 16:23 schrieb Cholo Lennon: >> What can I do? > 'move_iterator' has been available since C++11. Just use a compiler that > at least support C++11. Ok, thanks so far! But I do not get it work. :( Here I'm using QT Creator and the 'About QT Creator' shows: QT Creator 3.0.1 Based on QT 5.2.1 (GCC 4.8.2, 64 bit) And I made changes in my pro-file like described here: <http://stackoverflow.com/questions/16948382/how-to-enable-c11-in-qt-creator> CONFIG += c++11 What else do I have to do? Regards Heinz-Mario Frühbeis |
| "Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: Apr 27 04:41PM +0200 Am 27.04.2016 um 16:32 schrieb Jens Thoms Toerring: > Heinz-Mario Frühbeis <Div@earlybite.individcore.de> wrote: [...] > But then you'll get some further error messages: you can't > use 'it' as a template argument, this has to be a type, not > some class instance. And then that's not a function call. Ok, please have a look on my answer to Cholo. > No need for any special kind of object for that - just > add or subtract from an iterator to position it to some- > where else in the object it's iterating over. Works well. Fine and OK! Thank you very much... Regards Heinz-Mario Frühbeis |
| Dombo <dombo@disposable.invalid>: Apr 27 01:19PM +0200 Op 25-Apr-16 om 0:56 schreef Mr Flibble: >> [snip] And awaiting >> a better solution I am stuck with printf so far. > Boost.Format mate. Has anyone tried cppformat (https://github.com/cppformat/cppformat)? It looks promising, but so far I've only seen the authors claims. |
| 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