- Inheriting from a template class - 1 Update
- cout slower than printf - 2 Updates
- mixing compilers (g++ but Intel others)? - 12 Updates
- Seems like the double * and double ** are put on stack in reverse order expected - 1 Update
| Christopher Pisz <nospam@notanaddress.com>: Apr 26 06:31PM -0500 I don't user templates often, so here I am sucking at it. I am trying to make an interface that uses a generic type and inherit from it to make a concrete class whose methods return that type. Basically I am gonna have a bunch of XML parsers specific to what files they parse all having one interface pointer type I can use. Can someone help me with the syntax? --- The object I am dealing with in "DailyData.h" // Project Includes #include "Configuration.h" namespace Domain { namespace Focus { //------------------------------------------------------------------------------ class DailyData { public: const Configuration & GetConfiguration() const; void SetConfiguration(const Configuration & configuration); protected: Configuration m_configuration; }; //------------------------------------------------------------------------------ } } --- The generic interface in "IXmlParser.hpp" namespace XMLParsing { template <T> class IXmlParser { /// <summary> /// Parses XML a string /// </summary> /// <typeparam name="T"></typeparam> /// <param name="xml"></param> /// <returns></returns> T FromString(string xml); /// <summary> /// Parses XML from a file /// </summary> /// <typeparam name="T"></typeparam> /// <param name="path"></param> /// <returns></returns> T FromFile(string path); }; } --- The concrete type in "FocusXMLReader.h" // Project Includes #include "IXmlParser.hpp" // Domain Inludes #include "DailyData.h" // Standard Includes #include <string> namespace XMLParsing { // Intellisense complains here about the type in <> class FocusXmlReader : IXmlParser<Domain::Focus::DailyData> { public: T FromString(const std::string & xml); T FromFile(const std::string & path); }; } -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| Robert Wessel <robertwessel2@yahoo.com>: Apr 26 02:11PM -0500 On Mon, 25 Apr 2016 16:15:24 +0200, Christian Gollwitzer >likely, sprintf() in a GUI program), is the clear winner. There are >still problems, e.g. printf strings reading past the end of the >arguments, which might pose a security risk. Unless I missed where this thread was restricted to only POSIX compliant systems, positional parameters are not actually a standard feature of printf format strings. And so the ordering problem is not actually any better for printf than for iostreams. |
| "Öö Tiib" <ootiib@hot.ee>: Apr 26 04:20PM -0700 > compliant systems, positional parameters are not actually a standard > feature of printf format strings. And so the ordering problem is not > actually any better for printf than for iostreams. Yes they perhaps mix up GNU gettext, POSIX extensions, standard 'printf' and 'boost::format'. Actually reordering of words solves only one trivial difference in languages. Most others remain. All those grammatical cases, conjugations, counted plurals etc. English example: achieve that "1st", "2nd", "3rd", "4th", "5th" is written correctly with whatever of those 'printf's. |
| 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> |
| David Brown <david.brown@hesbynett.no>: Apr 26 10:26PM +0200 On 26/04/16 18:37, Scott Lurndal wrote: >>> by MS) before ELF was developed in the late 80's. >> So why aren't compilers able to link each others object files? > In my experience, they do. Usually they manage fine on *nix systems, but not on Windows where tools often have different formats and calling conventions. Even on *nix, it gets complicated with C++ as there are many versions of the C++ ABI (for good reasons, as the language and the tools have gained new features). But for straight extern "C" functions and native C data types, different compilers on *nix can normally mix object files (and therefore also static libraries). |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 04:30PM -0400 On 4/26/2016 2:43 PM, Gareth Owen wrote: > Well, mostly that part about the fact that *on Unix its not true*. > The format of the object files is not modified when stored within the > library container format. How many compilers other than gcc have you used on *nix? gcc is not the only one (and never has been). > If a Pascal program can link to foo() in libfoo.a, then it can just as > easily link to foo() in foo.o Only if both were created with the same compiler. >> with the others. > And this refers to Ian's statement - which is clearly, unambiguously and > explicitly talking about Unix - how, exactly? And the other comments here have indicated it applies to all x86 systems. But what other compilers have you used? Ones that are not gcc based, that is. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 04:34PM -0400 On 4/26/2016 4:12 PM, David Brown wrote: > 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. So your "standard" is not really a standard, is it? > 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. 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. > 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. 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. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Gareth Owen <gwowen@gmail.com>: Apr 26 09:35PM +0100 > 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. > Only if both were created with the same compiler. Wrong. |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 04:35PM -0400 On 4/26/2016 12:41 PM, Scott Lurndal wrote: > Microsoft PECOFF object format (which was the old, inefficient, > unix object format until superceded by the superior ELF format). > 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. And what other compilers (non-gcc based, that is) have you used on *nix? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 04:38PM -0400 On 4/26/2016 4:22 PM, David Brown wrote: > You might also want to re-write the entire Wikipedia page on x86 calling > conventions: > <https://en.wikipedia.org/wiki/X86_calling_conventions> There is the truth, and there is Wikipedia. SOMETIMES they coincide. PASCAL, FORTRAN, etc. use an entirely different calling convention than C. They push left to right, and the called function pops the stack. C 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. stdcall is just a variation of the PASCAL calling convention. >>> https://refspecs.linuxfoundation.org/elf/gabi41.pdf (chapter 4) >>> http://www.x86-64.org/documentation/abi.pdf (chapter 4) >> Then please explain why I can't do the above. No explanation? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 04:41PM -0400 On 4/26/2016 12:37 PM, Scott Lurndal wrote: >>> may not follow the standard means little. >> The fact that multiple compilers do not follow this standard means a lot. > Citation required. How many non-gcc based compilers have you used on *nix? Compiler manufacturers do not normally document object file formats. If you want a citation, go out and buy one. Then try to link in other compiler .o files. My "citation" is previous experience with different compilers. >>> by MS) before ELF was developed in the late 80's. >> So why aren't compilers able to link each others object files? > In my experience, they do. Which non-gcc based compilers have you used? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Apr 27 08:43AM +1200 On 04/27/16 02:29, Jerry Stuckle wrote: >> archive of object files" did you miss? > What part of object file formats being compiler dependent and library > file formats being defined by the operating system did you miss? None, I even mentioned it: "The format of the archive may be standard, but the format of the archived object files is not". You appear to be confusing the archive format with the format of its contents. >> issue with system libraries which are either written in C or have C >> linkage. > Maybe not with gcc - but that is NOT the only compiler in the world. The system libraries on one of my usual platforms (Solaris) aren't built with gcc. The system libraries on the other (Illumos) are built with a 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. -- Ian Collins |
| Cholo Lennon <chololennon@hotmail.com>: Apr 26 06:04PM -0300 On 04/26/2016 05:41 PM, Jerry Stuckle wrote: > Compiler manufacturers do not normally document object file formats. Microsoft at least has this document (I have no idea if other manufacturers provide similar information): https://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx Regards -- Cholo Lennon Bs.As. ARG |
| Gareth Owen <gwowen@gmail.com>: Apr 26 10:26PM +0100 >> Compiler manufacturers do not normally document object file formats. > Microsoft at least has this document (I have no idea if other > manufacturers provide similar information): Here are Sun CC's http://docs.oracle.com/cd/E19683-01/817-3677/6mj8mbtc7/index.html (surprise! It's ELF) |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 22 09:30AM -0400 On 4/19/2016 8:40 PM, Robert Wessel wrote: > XPLink, for example, you can pass several parameters in registers, you > don't need two areas to manage, there's no forward chain, and the > number of registers saved is usually considerably less. Sure, just as you have to allocate space for a stack from someplace. No difference there. And passing parameters via R1 may be "painful" to you - but it is standardized and very flexible - any number of any types of parameters can be passed, for instance. Linkage isn't hard at all - backward pointers, no forward pointers required (although you can use one - a single instruction). As for "storing too many registers" - it's one statement to store 15 registers (stm 14, 12, 12(13)). Even easier than having to push multiple registers onto a stack individually. But XPLink requires potentially different linkage for every function, different register usage and even storing individual registers instead of all at once. And then you need to keep track of registers which haven't been saved - and ensure those aren't used. Not so with the R13 convention - all registers are available (with only R13 reserved to point to the save area). > necesary (for example, if a routine is only called from inside a > program). And that true even though most platforms "standard" ABI are > not nearly as painful as the S/360 one. Actually, that is not at all true. We did it all the time at IBM. We even had macros that would do the whole works for us. And our customers used the convention, also. As for COBOL and FORTRAN - I don't know about other compilers, but the IBM compilers used it. It was one of the internal standards IBM expected to be followed by all programmers - because it's good and it works. > the PL/I modification of the standard OS convention, etc.) The point, > however, is that the notion that the S/360 R13 convention is most > common inside C or C++ programs is wrong. Yes, it's a relatively new standard. I don't know what IBM has changed internally since I left many years ago. But you still haven't proven XPLink is any more or less used than R13. Only what you have seen, which is just a small part in the world of programming. I haven't seen that much more than you have - but I do have the benefit of years of programming experience with IBM, and know what their standards were at the time, anyway. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| 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