| olcott <NoOne@NoWhere.com>: Sep 17 08:06PM -0500 On 9/17/2020 1:10 AM, Chris M. Thomasson wrote: >>> C++ does and none that fix this issue with sequencing IO operations. >> You wouldn't write IO in that way in C, so the problem goes away. > Have to admit that I prefer printf over cout in a lot of cases. It didn't occur to me until my other recent post that my use of printf over cout is not merely laziness, printf is simply better at formatted output. -- Copyright 2020 Pete Olcott |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 17 08:56PM -0700 On 9/17/2020 6:06 PM, olcott wrote: > It didn't occur to me until my other recent post that my use of printf > over cout is not merely laziness, printf is simply better at formatted > output. Actually, using printf can sometimes be more "difficult" to use. However, I still try to employ it when I can. |
| Juha Nieminen <nospam@thanks.invalid>: Sep 18 06:35AM > For those types, reading from an iterator pair and writing to an > output iterator would be no less performant, and provide > more flexibility. The iterator idiom is certainly very flexible and adds a lot of possibilities that a "hard-coded" (so-to-speak) non-iterator based solution like from_chars() and to_chars() can't offer. For example, if the output would be specified with an iterator, you could use something like a back_insert_iterator, or a ostream_iterator, or whatever you want. Likewise for input, iterators wouldn't force you to have the input string being in an actual array, but be eg. generated on the fly. That being said, there could potentially be some efficiency benefits in taking char*'s directly, rather than iterators: It opens the possibility for the implementation to do things more efficiently than forward iterators would allow, such as traversing the string backwards, or random-accessing it. (You could make the iterator-based version require random access iterators, but that would immediately cut off a lot of the benefits of the iterator-based solution in the first place.) > And support char8_t, char16_t and char32_t too. I suppose the functions could be overloaded with versions taking those types of pointers... |
| Juha Nieminen <nospam@thanks.invalid>: Sep 18 06:43AM > It didn't occur to me until my other recent post that my use of printf > over cout is not merely laziness, printf is simply better at formatted > output. Its major problem (besides not being type-safe) is that it's not extensible with custom types and formatting. Sure, you could write things like: std::printf("a=%i, b=", a); printMyCustomType(b); std::printf(", c=%f\n", c); but that's not very practical in all situations. It's also not very generic: template<typename T> void debugPrint(const T& value) { std::printf("... uh ...", value); // ??? } You could add overloads for every type supported by printf, but with std::ostream you don't have to because it already defines those overloads: template<typename T> void debugPrint(const T& value) { std::cout << value; } Also, a printf-based version would be more awkward when it comes to defining formatting parameters. With a generic ostream-based version nothing stops you from using its own formatting elements, like: debugPrint("a=", std::hex, a); (You can even implement that debugPrint() function in such a manner that it restores the formatting flags of std::cout before it returns, so any formatting changes don't linger afterwards.) |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 18 12:52PM +0200 > The problem was operator error: it helps if you change the compiler > settings for the build configuration you are actually building. Aside the compiler is actually right: I think calling f2() and then f1() before cout without -std:c++ is because the return of f2 is pushed first on the stack and then f1, which fits to the topmost position which is required for the first cout::operator << call. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 18 01:39PM +0200 > because the return of f2 is pushed first on the stack and then f1, > which fits to the topmost position which is required for the first > cout::operator << call. Sorry, I missed that operator << doesn't take a string-object. There isn't even an overload that takes a string-reference. So how does this work that you can output a string object to an ostream ? |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 18 01:44PM +0200 I missed the global overloads. |
| Bo Persson <bo@bo-persson.se>: Sep 18 01:50PM +0200 On 2020-09-18 at 13:39, Bonita Montero wrote: > There isn't even an overload that takes a string-reference. So > how does this work that you can output a string object to an > ostream ? There *is* an overload, but in the <string> header, not in the <ostream> header. https://en.cppreference.com/w/cpp/string/basic_string/operator_ltltgtgt Bo Persson |
| Paavo Helde <eesnimi@osa.pri.ee>: Sep 18 03:42PM +0300 18.09.2020 09:43 Juha Nieminen kirjutas: > std::printf("a=%i, b=", a); > printMyCustomType(b); > std::printf(", c=%f\n", c); Sure it is extensible. The custom types must just be capable to produce a string representation of themselves: std::printf("a=%i, b=%s, c=%f", a, b.ToString().c_str(), c); Considering that file output is slow anyway, constructing a "superfluous" temporary string does not even affect performance. Formatting parameters can be easily passed as arguments to ToString(). The only problem with std::printf() is the lack of type safety, but one can create typesafe equivalents in C++, retaining the general printf interface. There are many such solutions. I like my personal one which overloads operator(). |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 18 02:47PM +0200 On 17.09.2020 09:11, Juha Nieminen wrote: > Implementing such a function is perfectly possible, even easy. But > it's easy only if you use std::cout in its implementation. Not so easy > if you wanted to use std::printf instead. I prefer a common solution for basic string composition, writing the above as e.g. d_print( ""s << "The value of a is " << a << ", that of b is " << b << ", and str is "" << str << "".\n" ); This way the function only needs a `const string_view&` parameter, or the like, and the work of handling composition of umpteen args of different types, does not have to be repeated in every such function. I guess with the Fmt library in C++20 the specific syntax I use will change, but same concept: centralize basic string composition, centralize getter of filename and line number (well, that's almost solved in C++20, all one needs is to leverage the standard library to make an exception safe solution), and so on. Centralization, yay! Uh... - Alf |
| Juha Nieminen <nospam@thanks.invalid>: Sep 18 01:56PM > Sure it is extensible. The custom types must just be capable to produce > a string representation of themselves: > std::printf("a=%i, b=%s, c=%f", a, b.ToString().c_str(), c); Extending std::ostream to support your custom type would usually not require such temporary string buffers. Moreover, it grants you access to the std::ostream object itself, giving you the option of *how* to output the data (for example you could use std::ostream::write() instead of the regular operator<<'s). With that scheme you propose you don't have access to the FILE* where you are outputting, and thus you don't have, for example, the option of using std::fwrite() if you so wanted. Also, somewhat ironically, in some cases you would need to resort to stringstreams in order to create the string to be printed. > can create typesafe equivalents in C++, retaining the general printf > interface. There are many such solutions. I like my personal one which > overloads operator(). Not the only problem. I mentioned the other one: printf() is not generic enough. You can't use it when the type of the value to print is abstracted away (eg. it's a template type parameter). At least not even nearly as easily as with std::ostream. |
| Richard Damon <Richard@Damon-Family.org>: Sep 18 10:20AM -0400 On 9/17/20 9:06 PM, olcott wrote: > It didn't occur to me until my other recent post that my use of printf > over cout is not merely laziness, printf is simply better at formatted > output. printf can be easier for fundamental types (of known type). It is very hard to use for 'class' objects, particularly for polymorphic types. It does give more concise formatting the fundamental types. iostreams can be easier in generic code, as << will 'do the right thing' for the type. Since it lets the type decide how to output itself, it does make it harder to control the output at the point of use. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Sep 18 03:16PM > iostreams can be easier in generic code, as << will 'do the right thing' > for the type. Since it lets the type decide how to output itself, it > does make it harder to control the output at the point of use. Isn't it that printf can be now implemented in type safe manner? -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Paavo Helde <eesnimi@osa.pri.ee>: Sep 18 06:29PM +0300 18.09.2020 16:56 Juha Nieminen kirjutas: > operator<<'s). With that scheme you propose you don't have access to the > FILE* where you are outputting, and thus you don't have, for example, the > option of using std::fwrite() if you so wanted. I thought we were talking about formatted output, that's what fprintf() and streams are all about. I'm curious, how many times have you used std::ostream::write() in your operator<< ? Also, I consider it a good thing to modularize the program. Why should the code formatting the object content know or care about streams or FILE* pointers? Moreover, this way my output may easily become broken if the stream or FILE happens to use a strange locale. > Also, somewhat ironically, in some cases you would need to resort to > stringstreams in order to create the string to be printed. So what? This is an implementation detail. > enough. You can't use it when the type of the value to print is abstracted > away (eg. it's a template type parameter). At least not even nearly as > easily as with std::ostream. How comes? If everything supports conversion to strings, it's trivial to use in templates. Since C++11 we also have std::to_string() for primitive types, so they could be easily incorporated as well if needed. I mean, using C++ streams for formatted output is fine, I do not intend to attack it in any way. I just objected the claim "printf-like interface is not extensible with custom types and formatting". |
| Manfred <noname@add.invalid>: Sep 18 05:39PM +0200 On 9/17/2020 10:10 PM, Jorgen Grahn wrote: > Also, I've never (at home or at work) had any use for any of it. > Customers have never wanted a user interface not in English, and so > on. It's not just that. I have got customers that explicitly wanted non-english UIs, but that kind of customers systematically want GUIs. So, the point of localizing printf or std::cout is really non-existing. It should have been left to application libraries, not in the standard, same as GUI libraries. > last). I can get that with LC_COLLATE="sv_SE". But then I get > things I probably /don't/ want too, such as case-insensitive sort. > It's a blunt instrument. That's a good point. > especially if they're programmers, or have any international contacts > at all[1]. So you can't always use it in a localized user interface, > either. Not without annoying people. Even worse: most non-english keyboards still have a dot in the keypad instead of a comma (although I have seen some having it in there), so even for a French user typing 12345,67 is just painful. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 18 04:40PM +0100 On 18/09/2020 16:29, Paavo Helde wrote: >> easily as with std::ostream. > How comes? If everything supports conversion to strings, it's trivial to use in templates. Since C++11 we also have std::to_string() for primitive types, so they could be easily incorporated as well if needed. > I mean, using C++ streams for formatted output is fine, I do not intend to attack it in any way. I just objected the claim "printf-like interface is not extensible with custom types and formatting". Neither (f)printf nor iostreams are suitable for formatted output if such formatting is to include localization support; C++20 fmt should fix this inadequacy. /Flibble -- ¬ |
| Paavo Helde <eesnimi@osa.pri.ee>: Sep 18 08:15PM +0300 18.09.2020 18:40 Mr Flibble kirjutas: > Neither (f)printf nor iostreams are suitable for formatted output if > such formatting is to include localization support; C++20 fmt should fix > this inadequacy. So far all my locale-related efforts have been directed to *avoiding* any locale-specific formatting. Surprisingly difficult at times... |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 18 06:33PM +0100 On 18/09/2020 18:15, Paavo Helde wrote: > 18.09.2020 18:40 Mr Flibble kirjutas: >> Neither (f)printf nor iostreams are suitable for formatted output if such formatting is to include localization support; C++20 fmt should fix this inadequacy. > So far all my locale-related efforts have been directed to *avoiding* any locale-specific formatting. Surprisingly difficult at times... It is an unavoidable fact that different languages have varying grammars resulting in words (nouns, verbs etc) appearing in different relative positions in sentences; this is why (f)printf and iostreams simply do not work; not everyone uses English. /Flibble -- ¬ |
| Paavo Helde <eesnimi@osa.pri.ee>: Sep 18 09:06PM +0300 18.09.2020 20:33 Mr Flibble kirjutas: > resulting in words (nouns, verbs etc) appearing in different relative > positions in sentences; this is why (f)printf and iostreams simply do > not work; not everyone uses English. I know that :-) Changing the locale to non-English should work like Babel fish, but somehow it doesn't. And even if it worked like Babel fish it should not be used when writing data which will be read by some other software only, not by a human being. Our software is aimed at PhD level and there have not been any requests to translate it, even when sold in China. That's just fortunate because doing a correct translation seems to be a mission impossible (or at least many times more expensive than the original project) these days, even if printf or iostreams are not involved. Recent advent of translation AI seems to make things worse, not better. |
| scott@slp53.sl.home (Scott Lurndal): Sep 18 06:41PM >>> Neither (f)printf nor iostreams are suitable for formatted output if such formatting is to include localization support; C++20 fmt should fix this inadequacy. >> So far all my locale-related efforts have been directed to *avoiding* any locale-specific formatting. Surprisingly difficult at times... >It is an unavoidable fact that different languages have varying grammars resulting in words (nouns, verbs etc) appearing in different relative positions in sentences; this is why (f)printf and iostreams simply do not work; not everyone uses English. Which is why gettext[*], in combination with printf argument position flags (e.g. %2$u), is so useful for i18n. [*] and/or the often proprietary versions in other unix flavors. |
| olcott <NoOne@NoWhere.com>: Sep 17 07:41PM -0500 On 9/17/2020 1:57 PM, Ben Bacarisse wrote: > Ding! Ding! Ding! We have a winner! We now know what the scam you > planned on pulling is. Shame on you. Don't bother to post any code. > You have tipped your hand at last. I see three possibilities: (1) You are just bluffing (that would be dishonest). (2) You did not figure out my method but believe that you did. (3) You did figure out my method yet it did not fully sink in that this method really does refute the halting problem proofs because your mind is hard-wired to denial mode. -- Copyright 2020 Pete Olcott |
| ijw wij <wyniijj@gmail.com>: Sep 18 12:40AM -0700 olcott 在 2020年9月18日 星期五上午8:41:54 [UTC+8] 的信中寫道： > is hard-wired to denial mode. > -- > Copyright 2020 Pete Olcott I'm interested in the 'halt deciders programs'. Suppose two TM's, one is computing and printing 1/3=0.333... another is pi=3.1415... Will the decoder halt? So I can investigate the reason? |
| ijw wij <wyniijj@gmail.com>: Sep 18 12:48AM -0700 ijw wij 在 2020年9月18日 星期五下午3:40:23 [UTC+8] 的信中寫道： > I'm interested in the 'halt deciders programs'. Suppose two TM's, one > is computing and printing 1/3=0.333... another is pi=3.1415... > Will the decoder halt? So I can investigate the reason? Will the decoder terminate? So I can investigate the reason? |
| Juha Nieminen <nospam@thanks.invalid>: Sep 18 01:42PM > I'm interested in the 'halt deciders programs'. Suppose two TM's, one > is computing and printing 1/3=0.333... another is pi=3.1415... > Will the decoder halt? So I can investigate the reason? Usually when talking about the halting program, the problem is if there's a way to tell from a given program whether it will ever terminate or not. I suppose the same can be applied to merely an algorithm description or task description. If the task is: "Compute and print all the decimals of 1/3", then it's rather obvious that it will not halt. If the program has been implemented correctly, it will never halt. The problem is whether it's possible to create a program or algorithm that tells you from any given other program whether it will eventually halt or continue forever. And this has nothing to do with debugging. |
| olcott <NoOne@NoWhere.com>: Sep 18 12:58PM -0500 On 9/18/2020 8:42 AM, Juha Nieminen wrote: > that tells you from any given other program whether it will eventually > halt or continue forever. > And this has nothing to do with debugging. If the halt decider executes its test program in debug step mode then it will see the very first line-of-code indicating non halting behavior. -- Copyright 2020 Pete Olcott |
| 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