- cout slower than printf - 1 Update
- Reading C++ error messages - 4 Updates
- Seems like the double * and double ** are put on stack in reverse order expected - 1 Update
- "Introducing the C++ Core Guidelines" - 1 Update
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 23 12:22AM +0100 Why are implementers of C++ stdlibs such lazy fuckers? Just noticed that libstdc++ creates a separate temporary sprintf format string for EACH number you want to output and then uses that string in an internal call to sprintf (or its equivalent) for each number. Yes code-reuse is good in general but here using the C stdlib in a C++ LIBRARY implementation resulting in poor performance is just not on. This isn't a problem with C++ iostreams per se it is a problem with the quality of their implementation. C++ iostreams could easily outperform the C alternatives if a bit of effort was put in to leverage argument types. /Flibble |
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 22 01:57PM +0200 Undefined reference to: "std::__1::ios_base::getloc() const", referenced from: ServerMain(int, char**, bool) in libdatabaselibrary.a(ServerMain.o) std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequ ence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char > >&, char const*, unsigned long) in libdatabaselibrary.a(ServerMain.o) (etc) Now, the letter sequence "getloc" does NOT appear in the file ServerMain.cpp. How could I figure out what is wrong and where? Thanks in advance for any hints. jacob |
| Victor Bazarov <v.bazarov@comcast.invalid>: Apr 22 08:25AM -0400 On 4/22/2016 7:57 AM, jacobnavia wrote: > Now, the letter sequence "getloc" does NOT appear in the file > ServerMain.cpp. > How could I figure out what is wrong and where? I can only speculate that the 'getloc' resides in a template implementation (of '__put_character_sequence') which in turn is pulled in by the compiler when you call some function (like a member of the 'basic_ostream') in 'ServerMain'. Make sure to include all the relevant libraries for the use of 'basic_ostream'. Since it is likely implementation-specific, RTFM. V -- I do not respond to top-posted replies, please don't ask |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 22 05:33PM +0300 On 22.04.2016 14:57, jacobnavia wrote: > Now, the letter sequence "getloc" does NOT appear in the file > ServerMain.cpp. > How could I figure out what is wrong and where? By googling of course! http://stackoverflow.com/questions/19521398/linker-error-while-building-clang-using-makefile-with-a-checker HTH Paavo |
| woodbrian77@gmail.com: Apr 22 03:56PM -0700 On Friday, April 22, 2016 at 9:33:21 AM UTC-5, Paavo Helde wrote: > > ServerMain.cpp. > > How could I figure out what is wrong and where? > By googling of course! I like Duckduckgo as an alternative to Google. https://duckduckgo.com Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| 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 ================== |
| legalize+jeeves@mail.xmission.com (Richard): Apr 22 01:44AM [Please do not mail me a copy of your followup] Kate Gregory is awesome. -- "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> |
| 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