- mixing compilers (g++ but Intel others)? - 3 Updates
- cout slower than printf - 9 Updates
- preprocessor and the hash character - 1 Update
| scott@slp53.sl.home (Scott Lurndal): Apr 25 05:23PM >On 4/25/2016 10:01 AM, FredK wrote: >> On my RHEL Linux, Fortran object files compiled using the Intel compiler are not compatible with object files compiled using the GNU gfortran compiler. >Object files are not the same as libraries. Perhaps in Z/OS, that's true. In unix (and unix-like systems or even VMS) libraries are simply collections (archives) of object files. |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 25 04:20PM -0400 On 4/25/2016 1:23 PM, Scott Lurndal wrote: > Perhaps in Z/OS, that's true. > In unix (and unix-like systems or even VMS) libraries are simply > collections (archives) of object files. Yes, but even on unix, object files are not the same as libraries. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| scott@slp53.sl.home (Scott Lurndal): Apr 25 10:43PM >> In unix (and unix-like systems or even VMS) libraries are simply >> collections (archives) of object files. >Yes, but even on unix, object files are not the same as libraries. You'll have to explain that in further detail. A .a and a .o are interchangable and almost indistinguishable from the perspective of the linker. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 25 06:04PM +0100 On 25/04/2016 13:39, Daniel wrote: > with the built-in manipulators, you have to strip the rest of the trailing > zeros yourself. Also, since the manipulators are expressed in code, you > can't easily put a format mask into configuration storage, which is something we frequently want to do. Nonsense, trailing zeros are quite easy to achieve; the following program outputs 1.0000: #include <iostream> #include <iomanip> int main() { std::cout << std::fixed << std::setprecision(4) << 1.0 << "\n"; } /Flibble |
| Daniel <danielaparker@gmail.com>: Apr 25 10:07AM -0700 On Monday, April 25, 2016 at 11:41:09 AM UTC-4, Jerry Stuckle wrote: > I can see why you think iostreams are so slow, though. Always nice to see that ah hah moment in our friends and acquaintances on usenet. > use to_json, to_xml, etc. to write data unless it had to be in a format > compatible with many applications across a network or something similar. > That's what these formats were made for. Using my own modest attempt at a json library for parsing and serialization (published as open source), on my Dell Precision notebook, it takes a little under 10 seconds to read a gigabyte of json text, and a little under 2 seconds to write it, with insertion to an ostream and extraction from an istream. Those numbers require some optimizations within the library when reading and writing to the stream, without them, using stream io simplistically, read would be about 5 times slower, and write 4 times slower (there are other open source json libraries that are faster, but they have their own issues.) Generally, I find these times acceptable for reading and writing a gigabyte of text, and usually the amount of data I work with is somewhat smaller. Typically, if I push a button on a python app which sends a json request to C++ server to simulate some data and transfer it back as json over a socket, the resulting 3D plot in the python app appears close to instantaneous. So in most cases, I'm not particularly motivated to transfer anything except text, given text's other advantages. In those other cases, I use Google protocol buffers. > >>> manipulators were never a good idea, too inflexible. > Good enough tat millions of programmers around the world have been happy > with them. But perhaps not very, very happy. A little Google search will show you much wailing and gnashing of teeth, many hacks and workarounds, and not a few alternative toolkits for formatting. > But as for the format mask - you're still thinking > procedural code, not object oriented. You weren't one of those who subscribed to JOOP, were you :-) In any case, the substance of OO, abstract interfaces, is silent about whether I want to keep the format of a number, date, currency, phone number etc. as a string representation in a data store, where my users can configure it without having to recompile a computer application. Best regards, Daniel |
| scott@slp53.sl.home (Scott Lurndal): Apr 25 05:32PM >cout << myObject <<\n; >And cout can be replaced with any ostream-derived object with no other >change. As I must have an overloaded operator << in any class to leverage your object formatting, I could as easily have written a "dump" method in the class that outputs to a supplied ostream or a "format" method that produces a std:string which can be supplied to snprintf. I would recommend that sprintf _never_ be used - 'snprintf' is more secure. |
| Daniel <danielaparker@gmail.com>: Apr 25 10:36AM -0700 On Monday, April 25, 2016 at 1:04:37 PM UTC-4, Mr Flibble wrote: > > zeros yourself. > Nonsense, trailing zeros are quite easy to achieve; the following > program outputs 1.0000: My dear Mr Flibble, if something seems like nonsense to you, you should read a little more carefully, and had you done that, you would have seen that the requirement is to print 1.0, not 1.0000. (Generally, json and xml libraries want to preserve as much precision in the output as possible, subject to other requirements including round-trip, economical use of space, and when there are a number of equivalent floating point representations, the shortest one. So these libraries never use fixed precision output.) Best regards, Daniel |
| scott@slp53.sl.home (Scott Lurndal): Apr 25 05:38PM >{ > std::cout << std::fixed << std::setprecision(4) << 1.0 << "\n"; >} I cannot see how that's better than 'printf("%4.1f\n", 1.0)'. (note that Daniel specified only 1 trailing zero). And you completely ignored his final point. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 25 06:43PM +0100 On 25/04/2016 18:36, Daniel wrote: > My dear Mr Flibble, if something seems like nonsense to you, you should read > a little more carefully, and had you done that, you would have seen that the > requirement is to print 1.0, not 1.0000. (Generally, json and xml libraries want to preserve as much precision in the output as possible, subject to other requirements including round-trip, economical use of space, and when there are a number of equivalent floating point representations, the shortest one. So these libraries never use fixed precision output.) Don't be a fucktard mate. std::cout << std::fixed << std::setprecision(1) << 1.0 << "\n"; outputs 1.0 /Flibble |
| Daniel <danielaparker@gmail.com>: Apr 25 11:13AM -0700 On Monday, April 25, 2016 at 1:43:22 PM UTC-4, Mr Flibble wrote: > std::cout << std::fixed << std::setprecision(1) << 1.0 << "\n"; > outputs > 1.0 If all of the numbers were "1", I would agree with you. But usually I have other numbers. >> space, and when there are a number of equivalent floating point >> representations, the shortest one. So these libraries never use fixed >> precision output.) But I do accept your gentle remonstrance for a "fucktard" moment, as my last sentence is incorrect, I should have said, these libraries never use fixed number of decimal places. They typically do use fixed precision, either 15 (for simple round trip), 16 (if preserving the precision of the input floating point numbers, and thus round trip) or 17 (if the double to text algorithm is Grisu2) Best regards, Daniel |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 25 04:26PM -0400 On 4/25/2016 1:07 PM, Daniel wrote: >> I can see why you think iostreams are so slow, though. > Always nice to see that ah hah moment in our friends and acquaintances on > usenet. I see the sarcasm went "whoosh". > stream io simplistically, read would be about 5 times slower, and write 4 > times slower (there are other open source json libraries that are faster, > but they have their own issues.) And reading/writing binary files would be even faster. > in most cases, I'm not particularly motivated to transfer anything except > text, given text's other advantages. In those other cases, I use Google > protocol buffers. That's fine. What happens when you use iostreams and optimize the buffer usage? > But perhaps not very, very happy. A little Google search will show you much > wailing and gnashing of teeth, many hacks and workarounds, and not a few > alternative toolkits for formatting. YOU might not be happy, but those programmers are. Sure, you 'll see wailing and gnashing of teeth, etc. But it's only the people who don't like it who are posting. And that's a pretty small number of the total C++ programmers in the world. >> But as for the format mask - you're still thinking >> procedural code, not object oriented. > You weren't one of those who subscribed to JOOP, were you :-) No, but I've been doing OO for over a quarter century, and taught it to corporations for about 1/2 that time. > configure it without having to recompile a computer application. > Best regards, > Daniel Sure, you are free to store the data in any format you wish. But the key here is the object defines its own storage format and is responsible for that format. And why would they need to "configure it without having to recompile a computer application"? And if they do, how do they do it with printf? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 25 04:29PM -0400 On 4/25/2016 1:32 PM, Scott Lurndal wrote: > written a "dump" method in the class that outputs to a supplied > ostream or a "format" method that produces a std:string which > can be supplied to snprintf. Sure. The object is responsible for its own formatting. The object being responsible for itself is one of the basic premises of object oriented programming. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Christof Warlich <christof.warlich1@gmail.com>: Apr 25 08:02AM -0700 Thanks ... I see the issue that the preprocessor would need at least a second pass to accomplish what I need, which is why it can't work that way. Honestly, I already guessed that answer, but I was still hoping that I might have missed some smart (and / or even non-standard) macro hackery: After all, some macro magic is sometimes really stunning (thinking of e.g. Boost Preprocessor). |
| 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