- mixing compilers (g++ but Intel others)? - 4 Updates
- cout slower than printf - 17 Updates
- preprocessor and the hash character - 4 Updates
| pedro1492@lycos.com: Apr 24 07:01PM -0700 I was mucking around with an open-source omni-shambles, which uses Fortran, C and C++. It has a lot of makefiles for different platforms, which are a little inconsistent. I can only get it to work if Intel compilers are used for Fortran and C but gnu g++ for C++. Now I was told in undergrad programming class that mixing brands of compilers like this is not recommended. (I did engineering and we had a "computer programming for physical sciences" module of 26 class hours total). |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 25 11:41AM +0300 > of compilers like this is not recommended. > (I did engineering and we had a "computer programming for physical sciences" > module of 26 class hours total). C has defined binary interface (ABI) on each platform, so using a C library compiled by another compiler should be fine. C++ on the other hand does not have defined ABI, so mixing C++ code from different compilers in general does not work (unless all the communication happens over the C interfaces (functions declared as extern "C")). But if all your C++ code is compiled by the same compiler, there should be no problem. Not sure what is the state with Fortran. HTH Paavo |
| FredK <fred.l.kleinschmidt@gmail.com>: Apr 25 07:01AM -0700 On my RHEL Linux, Fortran object files compiled using the Intel compiler are not compatible with object files compiled using the GNU gfortran compiler. |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 25 11:48AM -0400 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. Fortran libraries compiled using the Intel compiler should be compatible with files compiled with the GNU Fortran compiler (and vice versa). -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 24 10:15PM -0400 On 4/24/2016 6:40 PM, Marcel Mueller wrote: > Don't misunderstand. I like C++. Actually I prefer it - except for > iostreams. > Marcel So how do you output a class, i.e. class MyClass {...}; MyClass my; cout << my; Can you do this with printf()? Or how to you output to stdout, a file, or a string, in one method? Have you looked at manipulators for formatting? Speed is not the only factor involved - in fact, when it comes to I/O, it is generally the LEAST important factor. Physical I/O will take much more time than the function being called. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 24 10:16PM -0400 On 4/24/2016 7:05 PM, Marcel Mueller wrote: >> Boost.Format mate. > Unfortunately Boost is not supported on some of my platforms. > Marcel That's not iostream's fault... -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Daniel <danielaparker@gmail.com>: Apr 24 08:21PM -0700 On Sunday, April 24, 2016 at 10:15:22 PM UTC-4, Jerry Stuckle wrote: > MyClass my; > cout << my; > Can you do this with printf()? Of course. It's just as easy to implement a to_string function as it is << > Or how to you output to stdout, a file, or a string, in one method? fprintf covers stdout, to_string covers string > Have you looked at manipulators for formatting? manipulators were never a good idea, too inflexible. For example, a common output format of a double is show decimal point, minimally one trailing zero after the decimal point, and no more than one trailing zero. That can't even be expressed with the built in C++ manipulators. The right way to handle formatting is with format strings, there's a lot of prior art behind that, from COBOL on. The C++ streams do have one advantage over the C functions in that they can be associated with local versions of locales, that's a defect with the printf, put, et all function signatures. > Speed is not the only factor involved - in fact, when it comes to I/O, > it is generally the LEAST important factor. Physical I/O will take much > more time than the function being called. In open source projects involving text serialization, where benchmarks are published and affect how many users a project gets, people do anything to avoid using C++ streams, or go to herculean efforts to get around the inefficiencies of streams. They shouldn't have to do that. Daniel |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 24 11:35PM -0400 On 4/24/2016 11:21 PM, Daniel wrote: >> Can you do this with printf()? > Of course. It's just as easy to implement a to_string function as it is << Which means you can't use to_string for any different formatting. >> Or how to you output to stdout, a file, or a string, in one method? > fprintf covers stdout, to_string covers string Which means you can't use to_string for any different formatting. > can't even be expressed with the built in C++ manipulators. The right way > to handle formatting is with format strings, there's a lot of prior art > behind that, from COBOL on. Yes, COBOL has another way to do it. But whether YOU think they are a good idea or not, millions of programmers have been using them for over a quarter century, with good results. > The C++ streams do have one advantage over the C functions in that they can > be associated with local versions of locales, that's a defect with the > printf, put, et all function signatures. Yes, that is one advantage. Another is their ability to use manipulators to control formatting of the data. And, of course, you don't need to tie up to_string just for I/O. And BTW - to_string doesn't work well on input. > avoid using C++ streams, or go to herculean efforts to get around the > inefficiencies of streams. They shouldn't have to do that. > Daniel Text serialization is not the only use for input/output. In fact, very little of my C++ I/O work includes text serialization. Much more of it has had to do with object serialization. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Juha Nieminen <nospam@thanks.invalid>: Apr 25 06:11AM > *printf is still part of the C++ standard, so why > not to use it, unless something better exists? Modern compilers do type > checking with reasonable warnings for printf like functions. Use it if it suits the situation. But sometimes it doesn't. That's because printf is not generic. If you have a generic type (eg. a template type, or just a typedeffed name) you have no way of knowing what its format string has to be. The printf family is unsuitable in this situation. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Juha Nieminen <nospam@thanks.invalid>: Apr 25 06:14AM > Of course. It's just as easy to implement a to_string function as it is << Perhaps the day that C++ supports introspection, but until then, it doesn't work. template<typename T> void foo(const T& value) { std::cout << value; } Good luck determining there whether you need to call a to_string() method of the parameter or not. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 25 08:50AM +0200 Le 24/04/2016 22:58, Mr Flibble a écrit : > Why not use old inferior language features you ask? Of course. Using C, that old "inferior" language is faster... but that is not so important of course. > The same question > could be why use 'new' when you could use 'malloc'? Exactly. > Why use classes > when you can not use classes? Exactly. Why everything must fit into a class hierarchy? > Apparently you are unaware of the concept > of progress. Progress, as defined by some C++ heads, means complexifying everything till simple things like printing a number becomes slow and utterly complicated. |
| Christian Gollwitzer <auriocus@gmx.de>: Apr 25 08:54AM +0200 Am 25.04.16 um 04:15 schrieb Jerry Stuckle: > MyClass my; > cout << my; > Can you do this with printf()? Write a virtual print/serialize function in your class. You rarely need to "just print" it. Maybe even printf("%s", my.repr()) can be an easy solution. > Or how to you output to stdout, a file, or a string, in one method? stdout and file works with fprintf. string is different, but you can always print to a string first and then output to the target. The real problem with sprintf is that you need to have the (limited) buffer first. > Have you looked at manipulators for formatting? How do you do i18n with iostreams? printf has positonal parameters, so that you can change "This apple costs 18 dollars" into "18 dollars for this apple" by the translator. I don't see a solution with iostreams. > Speed is not the only factor involved - in fact, when it comes to I/O, > it is generally the LEAST important factor. Physical I/O will take much > more time than the function being called. Often, yes. But iostreams are really slow. Try writing a large file and you'll see. Christian |
| Ian Collins <ian-news@hotmail.com>: Apr 25 07:58PM +1200 On 04/25/16 18:54, Christian Gollwitzer wrote: > Often, yes. But iostreams are really slow. Try writing a large file and > you'll see. I really don't know why people keep bringing up this old chestnut: unformatted iostream output is no slower and can be faster than stdio. With iostreams we have full control of the underlying streambuf and therefore any buffering. You won't hear any arguments from me if you claim formatted output is cumbersome, but unformatted is a different kettle of fish. -- Ian Collins |
| Daniel <danielaparker@gmail.com>: Apr 25 05:13AM -0700 On Monday, April 25, 2016 at 2:15:09 AM UTC-4, Juha Nieminen wrote: > > Of course. It's just as easy to implement a to_string function as it is << > Perhaps the day that C++ supports introspection, but until then, it doesn't > work. In C++, both to_string and the stream insertion operator<< require custom implementations for MyClass. I think you know that, so I'm not quite sure what your point is. Daniel |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 25 08:27AM -0400 On 4/25/2016 2:54 AM, Christian Gollwitzer wrote: > Write a virtual print/serialize function in your class. You rarely need > to "just print" it. Maybe even printf("%s", my.repr()) can be an easy > solution. Or, just use an iostream. > stdout and file works with fprintf. string is different, but you can > always print to a string first and then output to the target. The real > problem with sprintf is that you need to have the (limited) buffer first. Exactly- the string is different. No buts. > How do you do i18n with iostreams? printf has positonal parameters, so > that you can change "This apple costs 18 dollars" into "18 dollars for > this apple" by the translator. I don't see a solution with iostreams. I don't see a solution for to_string. > Often, yes. But iostreams are really slow. Try writing a large file and > you'll see. > Christian I've written huge files over the years. No, iostreams are not as fast. But the biggest delay has not been in the software. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 25 08:28AM -0400 On 4/25/2016 2:50 AM, jacobnavia wrote: > Progress, as defined by some C++ heads, means complexifying everything > till simple things like printing a number becomes slow and utterly > complicated. Why even use a HLL at all? Just write everything in assembler (or machine language). -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Daniel <danielaparker@gmail.com>: Apr 25 05:39AM -0700 On Sunday, April 24, 2016 at 11:35:47 PM UTC-4, Jerry Stuckle wrote: > Which means you can't use to_string for any different formatting. True. Do you use manipulators for that, I mean for formatting a complex object? I tend to use to_json, to_xml, pretty_print(thing, format_options), etc. > Yes, COBOL has another way to do it. But whether YOU think they are a > good idea or not, millions of programmers have been using them for over > a quarter century, with good results. For some definition of "good results". But if you want to format a double to show the decimal point and one and only one trailing zero, you can't do it 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. In computer languages, C++ style manipulators are an evolutionary dead end, no newer language outside the family has picked them up, nor will ever be likely to. I agree with Marcel Mueller, C++ needs better abstractions for input and output. Daniel |
| Christian Gollwitzer <auriocus@gmx.de>: Apr 25 04:15PM +0200 Am 25.04.16 um 14:27 schrieb Jerry Stuckle: >> that you can change "This apple costs 18 dollars" into "18 dollars for >> this apple" by the translator. I don't see a solution with iostreams. > I don't see a solution for to_string. to_string is not needed. printf does it: printf("This %1$s costs %2$s %3$d\n", "computer", "$", 18); => This computer costs $ 18 The printf string will then be read from a file and translated e.g. into German, using different word order: printf("%3$d %2$s für den %1$s bitte\n", "computer", "$", 18); => 18 $ für den computer bitte (yes, "computer" should be uppercase, but still...) In reality, the printf string is read from a config file (GNU gettext does this. A similar example at https://www.gnu.org/software/gettext/manual/html_node/c_002dformat-Flag.html ). This is not a theoretical use case, it happens every day many times when I use the localized computer. But iostreams don't provide any solution here. I'm not saying it's perfect, but here printf (or, more 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. Serializing complex objects using iostreams seems an academic case to me, but it might simply not have occured to me yet. Christian |
| Cholo Lennon <chololennon@hotmail.com>: Apr 25 12:05PM -0300 On 04/24/2016 07:56 PM, Mr Flibble wrote: >> [snip] And awaiting >> a better solution I am stuck with printf so far. > Boost.Format mate. I like Boost.Format, I use it in production code, but it is slower than iostreams :-( -- Cholo Lennon Bs.As. ARG |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 25 11:40AM -0400 On 4/25/2016 8:39 AM, Daniel wrote: > True. Do you use manipulators for that, I mean for formatting a complex > object? I tend to use to_json, to_xml, pretty_print(thing, format_options), > etc. Definitely. It works quite well. But also, there are many times I don't necessarily want the data in a human-readable format. It might go into a file, for instance. I can see why you think iostreams are so slow, though. I would never 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. > 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. Good enough tat millions of programmers around the world have been happy with them. But as for the format mask - you're still thinking procedural code, not object oriented. > In computer languages, C++ style manipulators are an evolutionary dead end, > no newer language outside the family has picked them up, nor will ever be > likely to. Possibly, but not for decades. Too many programs are using them for them to be removed from the standards. > I agree with Marcel Mueller, C++ needs better abstractions for input and > output. > Daniel No language will ever be perfect for everyone. What's important is if it meets the needs of a major majority of the users. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 25 11:46AM -0400 On 4/25/2016 10:15 AM, Christian Gollwitzer wrote: > Serializing complex objects using iostreams seems an academic case to > me, but it might simply not have occured to me yet. > Christian Sure, printf can do it. But you're still thinking in procedural terms, not object oriented. The object can easily do such things in C++. And printf is not object aware - you cannot, for instance, say printf("%some user-defined formatting string\n", myObject); You can say cout << myObject <<\n; And cout can be replaced with any ostream-derived object with no other change. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Christof Warlich <christof.warlich1@gmail.com>: Apr 25 03:24AM -0700 Hi, the following (complete) example prints #define HELLO HELLO is defined when executed: #include <iostream> #define PRINT(x) std::cout << #x << std::endl int main() { #define HELLO PRINT(#define HELLO); #ifdef HELLO std::cout << "HELLO is defined" << std::endl; 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment