- mixing compilers (g++ but Intel others)? - 18 Updates
- Initialize POD base class with constexpr constructor - 2 Updates
- std::move_iterator is not a member of 'std'? - 1 Update
- Inheriting from a template class - 1 Update
| Gareth Owen <gwowen@gmail.com>: Apr 27 07:44PM +0100 > And you were able to link Sun CC object files with DEC Alpha CC programs? No because they were different architectures. Nobody ever suggested that. It was merely asser But I could link SunCC .o objects with native gcc .o objects on the Sun machine. And I could link DEC Fortran .o objects with native gcc objects on the DEC machine. > If so, the rest of the world would love to know how you did it. Glad to see even you are no longer what you originally asserted. |
| Gareth Owen <gwowen@gmail.com>: Apr 27 07:47PM +0100 > 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. So your assertion is that building .a files by running "ar" on Unix .o files fundamentally changes the layout of those files, rather than being mostly concatentation? That assertion is false. |
| Robert Wessel <robertwessel2@yahoo.com>: Apr 27 02:12PM -0500 On Wed, 27 Apr 2016 11:51:04 -0400, Jerry Stuckle >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). But they are. A *nix .a file is just a bunch of .o's run through ar, the predecessor of tar. There is no processing done to the contents of those, although a (minimal) header is added to each file in the archive (name, size, timestamp, a few other things), and a tiny header for the entire archive file. In fact you create a .a library with something like: ar rcs lib.a obj1.o obj2.o obj3.o The .la format from libtool is different. |
| David Brown <david.brown@hesbynett.no>: Apr 27 09:23PM +0200 On 26/04/16 22:38, Jerry Stuckle wrote: > pushes right to left, and the caller pops the stack. The two are not > compatible. C can use the PASCAL calling convention; PASCAL cannot use > the C calling convention. Please point me to the part of the C standard that explains how it supports "PASCAL calling convention". In fact, feel free to show me where it refers to any sort of calling conventions at all. You might find that /some/ C compilers support what you refer to as "PASCAL calling convention". In particular, some C compilers for Windows will support it - because that was the calling convention used by 16-bit Windows APIs. Similarly, 32-bit C compilers for Windows will support "stdcall", because that is the convention used for 32-bit Windows API. gcc also provides support for a range of calling conventions on x86 even for *nix targets - it's flexible that way. But it would not surprise me if *nix only compilers such as Sun's compiler only support their native calling convention. As for the calling conventions Pascal can use, there has only been one serious Pascal compiler - Delphi (for Windows, with a brief foray into the Linux world), and it supports a range of calling conventions including "cdecl". >>> Then please explain why I can't do the above. > No explanation? I have no idea why you can't do whatever it was you couldn't do "the above" - I've forgotten what you are referring to here. My first guess is that since you say you can't do "the above", and you seem to get almost everything wrong (until you change your mind without admitting it), you probably /could/ do "the above". My second guess is that just because /you/ can't do it, does not mean other people can't do it. But maybe, by sheer fluke, you are right and "the above" cannot be done. What is certain, however, is that there is no point in my going back in the thread to figure out what "the above" is, and trying to explain things to you - experience shows it is more efficient to assume you are wrong, and unable and unwilling to think or learn from anything anybody else says. This is your queue to make comments about teaching pigs to sing because you think it is such a clever and witty remark that we will all bow to your obvious knowledge and experience (after all, you worked for IBM!). |
| legalize+jeeves@mail.xmission.com (Richard): Apr 27 07:40PM [Please do not mail me a copy of your followup] Gareth Owen <gwowen@gmail.com> spake the secret code >> How many compilers other than gcc have you used on *nix? gcc is not the >> only one (and never has been). >Sun CC (multiple versions), clang, gcc, DEC Alpha CC, DEC f77 and f95. I'm surprised not to see MIPSpro C++/FORTRAN compilers in there :) -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 03:42PM -0400 On 4/27/2016 3:23 PM, David Brown wrote: > Please point me to the part of the C standard that explains how it > supports "PASCAL calling convention". In fact, feel free to show me > where it refers to any sort of calling conventions at all. It's not required by the C standard - but it is required by the OS for language-neutral libraries. > conventions on x86 even for *nix targets - it's flexible that way. But > it would not surprise me if *nix only compilers such as Sun's compiler > only support their native calling convention. That's because the OS libraries use it for its libraries. That way those libraries can be called by any language. And although I hate to use Wikipedia as a reference, it is somewhat accurate in this case: https://en.wikipedia.org/wiki/X86_calling_conventions > serious Pascal compiler - Delphi (for Windows, with a brief foray into > the Linux world), and it supports a range of calling conventions > including "cdecl". Wrong again. There have been a number of "serious" Pascal compilers. I was using one even back in 1982 - long before Delphi. Even UCSD had a Pascal compiler for CPC in the late 70's. It never caught on big, but was used by a lot of companies (and taught in the universities) in the 70's and 80's. But companies went away from it for a number of (valid) reasons. > it), you probably /could/ do "the above". My second guess is that just > because /you/ can't do it, does not mean other people can't do it. But > maybe, by sheer fluke, you are right and "the above" cannot be done. Nope, you have a habit of skipping answers which conflict with your limited knowledge, and then claim you don't know what someone is talking about. > things to you - experience shows it is more efficient to assume you are > wrong, and unable and unwilling to think or learn from anything anybody > else says. Of course not. It would conflict with your limited knowledge. > This is your queue to make comments about teaching pigs to sing because > you think it is such a clever and witty remark that we will all bow to > your obvious knowledge and experience (after all, you worked for IBM!). Did you ever figure out how to determine at compile time whether a program was being built on a big endian or a little endian machine? I thought not. So much for your "expertise". -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 03:44PM -0400 On 4/27/2016 2:44 PM, Gareth Owen wrote: >> And you were able to link Sun CC object files with DEC Alpha CC programs? > No because they were different architectures. Nobody ever suggested > that. It was merely asser So that wasn't an answer to my question, was it. Just another red herring. > DEC machine. >> If so, the rest of the world would love to know how you did it. > Glad to see even you are no longer what you originally asserted. No change on this end at all. But you just keep throwing out red herrings as "proof". It doesn't work. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 03:45PM -0400 On 4/27/2016 2:47 PM, Gareth Owen wrote: > files fundamentally changes the layout of those files, rather than being > mostly concatentation? > That assertion is false. Wrong answer, Gareth. There is much more that needs to be done than just concatenating files. Otherwise, why would you even need ar? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 27 03:47PM -0400 On 4/27/2016 3:12 PM, Robert Wessel wrote: > something like: > ar rcs lib.a obj1.o obj2.o obj3.o > The .la format from libtool is different. Yes, but it is those *few other things* and the fact they are placed in a standard format that is important. .o files need not be in the same format, and a different compiler may very well have an equivalent to ar for their files. Nothing prevents it - in fact, compilers generally *do* have utilities such as ar included. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Gareth Owen <gwowen@gmail.com>: Apr 27 08:48PM +0100 >> No because they were different architectures. Nobody ever suggested >> that. It was merely asser > So that wasn't an answer to my question, was it. Just another red herring. Huh? |
| Gareth Owen <gwowen@gmail.com>: Apr 27 09:00PM +0100 >> That assertion is false. > Wrong answer, Gareth. There is much more that needs to be done than > just concatenating files. Otherwise, why would you even need ar? It's concatenating with the addition of headers for locating the objects within the archive. There is no change to the structure of the objects. But I don't need to convince you. I can confirm my beliefs with a simple experiment: gowen@felix:~$ cat foo.c int foo(int x, int y) { return x-y; } gowen@felix:~$ cc -c foo.c -o foo.o gowen@felix:~$ ar rcs foo.a foo.o gowen@felix:~$ ls -l foo.[ao] -rw-rw-r-- 1 gowen gowen 1380 Apr 27 20:52 foo.a -rw-rw-r-- 1 gowen gowen 1240 Apr 27 20:52 foo.o gowen@felix:~$ cat foo.o | md5sum adb30c5f32e1dccb926beee7faca54a5 - gowen@felix:~$ tail -c 1240 foo.a | md5sum adb30c5f32e1dccb926beee7faca54a5 - So, that'll be 140 bytes of header, followed by the object file, unmodified in its entirety. |
| Christian Gollwitzer <auriocus@gmx.de>: Apr 27 10:02PM +0200 Am 27.04.16 um 21:45 schrieb Jerry Stuckle: >> That assertion is false. > Wrong answer, Gareth. There is much more that needs to be done than > just concatenating files. Otherwise, why would you even need ar? If you doubt that, look into the source code of ar. ar can even compile any old file, it doesn't need to be a valido object file in any sense. If you have some Linux handy, try: Apfelkiste:artest chris$ echo This is file one > f1.txt Apfelkiste:artest chris$ echo "rubbischöäü" >f2.txt Apfelkiste:artest chris$ ar cr mylibfile.a *.txt Apfelkiste:artest chris$ ls -lh total 24 -rw-r--r-- 1 chris staff 17B 27 Apr 22:00 f1.txt -rw-r--r-- 1 chris staff 15B 27 Apr 22:00 f2.txt -rw-r--r-- 1 chris staff 162B 27 Apr 22:00 mylibfile.a Apfelkiste:artest chris$ cat mylibfile.a !<arch> f1.txt 1461787213 501 20 100644 17 ` This is file one f2.txt 1461787222 501 20 100644 15 ` rubbischöäü As you can clearly see, the ar file format is extremely simple. All this is valid for the Unix world only, which is why Scott is constantly talking about "*nix" Christian |
| Robert Wessel <robertwessel2@yahoo.com>: Apr 27 03:06PM -0500 On Wed, 27 Apr 2016 15:47:35 -0400, Jerry Stuckle >a standard format that is important. .o files need not be in the same >format, and a different compiler may very well have an equivalent to ar >for their files. The (complete) list of the "few other things" is (in addition to the file name, timestamp and size): owner ID, group ID, file mode and a magic value of 0x60, 0x0a. There's nothing in a standard .a the relates to the contents being object files. There are a few minor variants of the ar format, mostly different extensions for handling long filenames. >Nothing prevents it - in fact, compilers generally >*do* have utilities such as ar included. In neither *nix or Windows is it necessary for the "standard" for object files and libraries to be followed, so long as the resulting executable ends up in the format expected by the loader (and even that can be worked around to some extent if you want to provide a stub loader). But if you don't, you end up not being able to use all of the various tools and that can normally interoperate because they use the same object file format. Again, more common on Windows. |
| Christian Gollwitzer <auriocus@gmx.de>: Apr 27 10:07PM +0200 Am 27.04.16 um 19:42 schrieb Jerry Stuckle: > 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. It's true that you can't link two object files of arbitrary compilers, noone said that. But on Unix, *contemporary* compilers produce compatible object files. On Linux you can have gcc, clang, Intel C++ and tcc (the simple compiler), and they all are compatible with each other. If you search long enough, you'll find some compiler with an incompatible format, say a gcc with a.out backend would do. But the ones I list above are the important players today, and those are compatible. Christian |
| Gareth Owen <gwowen@gmail.com>: Apr 27 09:20PM +0100 > If you search long enough, you'll find some compiler with an > incompatible format, say a gcc with a.out backend would do. And even then, if you had an incompatible .o file, running "ar" on it would not, as Jerry seems to suggest, magically fix up those incompatibilities. |
| Ian Collins <ian-news@hotmail.com>: Apr 28 08:20AM +1200 On 04/28/16 00:32, Jerry Stuckle wrote: > 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. It looks like the night shift has already disproved this. > But some people are SO DENSE. and you have ably demonstrated this... -- Ian Collins |
| legalize+jeeves@mail.xmission.com (Richard): Apr 27 09:50PM [Please do not mail me a copy of your followup] Ian Collins <ian-news@hotmail.com> spake the secret code >On 04/28/16 00:32, Jerry Stuckle wrote: >> But some people are SO DENSE. >and you have ably demonstrated this... Reading through the hilarious replies to Jerry Stuckle on this thread have only confirmed my judgement to *plonk* him some time ago... -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Ian Collins <ian-news@hotmail.com>: Apr 28 09:52AM +1200 On 04/28/16 09:50, Richard wrote: >> and you have ably demonstrated this... > Reading through the hilarious replies to Jerry Stuckle on this thread > have only confirmed my judgement to *plonk* him some time ago... Then you miss out on the fun :) -- Ian Collins |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 27 11:07PM +0200 I have a POD structure that should be initialized at compile time. For this purpose I created a derived type with a constructor. This seems to be impossible with C++11. At least I did not find a trick so far. I get an error "constexpr constructor does not have an empty body". The base type must be POD because it is also part of unions. Performance and memory footprint count because of ARMV7. Almost everything is polymorphic here but I need to avoid runtime polymorphic types (i.e. vtables) because of the large overhead for ten thousands of small instances and first of all the costly static initialization code. Any hints? #include <inttypes.h> // Pack or unpack struct rPUp { uint8_t Mode; bool isUnpack() const { return (Mode & 0x80) != 0; } // other member functions... }; enum Pack : uint8_t { P_16a , P_16b //... }; enum Unpack : uint8_t { U_8a //... }; // Helper class to keep rPUp a POD and init dispatch table struct mkPUp : rPUp { constexpr mkPUp(Pack pack) { Mode = pack; } constexpr mkPUp(Unpack unpack) { Mode = unpack|0x80; } constexpr operator int() const { return Mode; } }; class Parser { struct opExtEntry { char Name[16]; // Parser function to call, receives an arbitrary argument. void (Parser::*Func)(int); // Argument to the parser function int Arg; }; void addPUp(int param) { //... } void addIf(int param) { //... } // other parser functions static const opExtEntry extMap[]; }; enum Cond { C_NZ //... }; // Dispatch table const Parser::opExtEntry Parser::extMap[] = { { "ifnz", &Parser::addIf, C_NZ } , { "pack16a", &Parser::addPUp, mkPUp(P_16a) } , { "pack16b", &Parser::addPUp, mkPUp(P_16b) } , { "unpack8a", &Parser::addPUp, mkPUp(U_8a) } //... }; |
| Ian Collins <ian-news@hotmail.com>: Apr 28 09:45AM +1200 On 04/28/16 09:07, Marcel Mueller wrote: > to be impossible with C++11. At least I did not find a trick so far. > I get an error "constexpr constructor does not have an empty body". > The base type must be POD because it is also part of unions. Do you need pod, or just standard layout? If the latter, you could skip the helper and give rPUp constexpr constructors, something like enum Pack : uint8_t { P_16a , P_16b //... }; enum Unpack : uint8_t { U_8a = 0x80 //... }; struct rPUp { uint8_t Mode; constexpr rPUp(Pack pack) : Mode{ pack } {} constexpr rPUp(Unpack unpack): Mode {unpack|0x80} {} constexpr bool isUnpack() const { return (Mode & 0x80) != 0; } constexpr operator int() const { return Mode; } // other member functions... }; -- Ian Collins |
| David Brown <david.brown@hesbynett.no>: Apr 27 09:25PM +0200 On 27/04/16 16:37, Heinz-Mario Frühbeis wrote: > <http://stackoverflow.com/questions/16948382/how-to-enable-c11-in-qt-creator> > CONFIG += c++11 > What else do I have to do? Try the correct flag: -std=c++11 or -std=gnu++11 (The later form gives you easy access to gcc extensions.) |
| jt@toerring.de (Jens Thoms Toerring): Apr 27 08:39AM > namespace XMLParsing > { > template <T> class IXmlParser This should be template<typename T> class IXmlParser > /// <param name="xml"></param> > /// <returns></returns> > T FromString(string xml); This might better be T FromString(const std::string & xml); or do you really need to pass a copy of the string? > /// <param name="path"></param> > /// <returns></returns> > T FromFile(string path); and this T FromFile(const std::string & path); > { > // Intellisense complains here about the type in <> > class FocusXmlReader : IXmlParser<Domain::Focus::DailyData> There's nothing wrong about this, at least as far as I can see. At least not with the namespaces you have shown above. Perhaps it's due to the missing 'typename' in the template class defi- nition? > public: > T FromString(const std::string & xml); > T FromFile(const std::string & path); Now, these two lines make no real sense. First, there's no type T anywhere (except as a template argument in some other file). And then, these functions are defined in your base class as Domain::Focus::DailyData FromString(string xml); and Domain::Focus::DailyData FromFile(string path); Do you really want to overload the functions from the IXmlParser class? Otherwise simply drop these two dec- larations. Regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
| 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