- mixing compilers (g++ but Intel others)? - 16 Updates
- C++ Middleware Writer - 1 Update
- Difference between array and pointer - arguments - 6 Updates
- Inheriting from a template class - 2 Updates
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 28 03:28PM -0400 On 4/27/2016 9:33 PM, Öö Tiib wrote: >> Yup, when you use the gcc compiler and tools. > Jerry, you go too far here in that denial. The 'ar' is Unix utility > (pretty much like 'tar') and not some sort of gcc tool. Which does not mean that other tools can't include their own versions of library creation tools. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 28 03:29PM -0400 On 4/28/2016 12:21 AM, Ian Collins wrote: >>> incompatibilities. >> It does if you use the ar from the appropriate toolkit. > The only "toolkit" ar comes from is the operating system. Which does not prohibit another toolkit from having their own version. I find it interesting that Linux programmers, who spend virtually all their time with one OS and one compiler, think the entire world works that way. It doesn't, as people who work on multiple OS's and with multiple compilers understand. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 28 03:32PM -0400 On 4/28/2016 9:57 AM, Scott Lurndal wrote: >> Believe I've been working with unix for probably a lot longer than you >> have - back around 1979 (although not continuously since that time) > 1977. Very interesting, since Unix had very limited usage in 1977 - mainly in the educational world. Not even AT&T was using it very much for production. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 28 03:48PM -0400 On 4/28/2016 4:13 AM, David Brown wrote: > calling conventions for libraries? How would printf work? (Variable > argument functions are easily handled with C calling conventions, but > not with Pascal conventions.) Functions like printf are part of the C library, so of course they use C calling conventions. You don't call them from PASCAL or COBOL, for instance. But non-C derived languages such as FORTRAN and COBOL do not use C calling conventions. And BTW - Windows is written in C, also. So are the Windows libraries. But the calling convention into the system libraries is not C. > world (and its DOS predecessor) where there is a jumble of local > conventions, often designed specifically for vendor lock-in rather than > cooperation. Yes, there are many different OS's. But if you want to be able to use languages such as Fortran and Cobol, the OS libraries need to use calling conventions supported by those languages. > Yes, there have been other Pascals. But the users of Delphi and its > predecessors Borland Pascal and Turbo Pascal probably outweigh the > combined number of users for every other Pascal by a factor of a hundred. Once again, your ignorance shows. For one thing, there were millions of students around the world using UCSD Pascal in the late 70's and early 80's - ling before Delphi, Borland Pascal, and so on. It was a common language taught in many universities. But beyond that, large and medium companies (including IBM) used Pascal extensively in the 1980's. But they were using enterprise grade products, not Delphi. > calling conventions. I don't know what calling conventions were used on > UCSD P-code systems - I was perhaps 9 or 10 when I used that on a VAX, > and did not get far beyond a "Hello, world" program. The calling conventions were similar, for those machines which had a hardware stack. For those without one, values were placed in a "parameter passing area" and the address of that area placed in a register. > a total confidence even when your claims are pure fantasy, and everyone > around you is laughing. I am sure you would make an excellent poker > player, but I am very glad I don't have to deal with you professionally.) No, the difference is your "knowledge", AFAICT, is based pretty much on one set of tools on one OS. And you think the rest of the world works that way. > way to do it - but that would only give you limited capabilities. In > particular, to be really useful, you need the endianness to be testable > in the preprocessor. Just a question - a problem similar to what consultants have to solve on a regular basis. Just seeing if you really knew what you were talking about. I see you don't. > Certainly I will publicise your success in c.l.c and c.l.c++, and it > will be seen even by the many people who have killfiled you. If not, > then your reputation - low as it is - will drop further. Yes, I raised the challenge. It's up to you to solve it. I have (actually did several years ago). Come on, David, give it a go. Or do you need someone to hand feed you everything? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Apr 29 08:11AM +1200 On 04/29/16 07:29, Jerry Stuckle wrote: >>> It does if you use the ar from the appropriate toolkit. >> The only "toolkit" ar comes from is the operating system. > Which does not prohibit another toolkit from having their own version. Name one. > I find it interesting that Linux programmers, who spend virtually all > their time with one OS and one compiler, think the entire world works > that way. I'm not a Linux programmer. -- Ian Collins |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 28 11:28PM +0300 On 28.04.2016 22:48, Jerry Stuckle wrote: > Just a question - a problem similar to what consultants have to solve on > a regular basis. I think we really do have a highly-paid consultant here! And he routinely solves the unsolvable problems! Why don't we just sit all back in awe and watchen das blinkenlights? As for solving the endianness problem, the practical solution (as opposed to "complete, portable and standard-conforming solution") is indeed really simple: #include <boost/detail/endian.hpp> #if defined(BOOST_LITTLE_ENDIAN) const bool bigEndian = false; #elif defined(BOOST_BIG_ENDIAN) const bool bigEndian = true; #else #error Unsupported platform. 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment